Thursday, 2018-11-29

scasgmail is not very appropriate for participating, indeed. it likes to do "stuff"00:00
clarkbfwiw gmail will show them as separate too since it seems to only rely on subject for grouping00:00
clarkbI noticed this with the way storyboard sends notifications00:01
scasi have issues handling my mail in most desktop clients, though, even through imap00:01
scasthunderbird has ground a laptop with 16gb of ram and a ssd to a dead stop. my workstation isn't much better despite more resources00:02
clarkbscas: is that due to the indexing? you can disable that00:03
clarkbmight affect your ability to do full text search on all the emails though00:03
zanebit's certainly true that every email client has its own set of heuristics for identifying what is and is not part of the same thread00:05
scasas far as threading goes, gmail breaks occasionally, but it doesn't seem to be any different than in, say, thunderbird00:06
zanebout of curiosity I checked gmail and can confirm that that subthread shows up as a separate thread00:08
*** mriedem has quit IRC00:13
fungizaneb: d'oh, for some reason i thought you said you were using gmail, but now i see you did not ;)00:25
fungiand yes, i've heard reports that gmail threads by subject and ignores in-reply-to references00:26
zanebfungi: maybe you just assume that anyone complaining about mailing list headers is probably using gmail ;)00:26
fungiso the reverse of what you said00:26
fungiheh, well, odds are it's an accurate guess! ;)00:26
zanebtechnically it's both because thunderbird is in fact fetching via IMAP from a gmail account00:27
fungiahh00:27
fungiwell, at any rate, suggestion heard and i'll try making it in no way a reply next round00:27
zanebbut each uses it's own set of heuristics for determining what a thread is00:28
zanebits00:28
fungiyep, maddening00:29
fungimutt shows them as part of the same thread but indicates where subject lines change, fwiw00:29
*** tosky has quit IRC00:50
*** zaneb has quit IRC01:10
*** dklyle has joined #openstack-tc01:32
*** ricolin has joined #openstack-tc02:21
*** jamesmcarthur has joined #openstack-tc03:00
*** jamesmcarthur has quit IRC03:04
*** diablo_rojo has quit IRC03:11
*** jamesmcarthur has joined #openstack-tc03:14
*** jamesmcarthur has quit IRC03:30
*** dklyle has quit IRC03:58
*** diablo_rojo has joined #openstack-tc04:17
*** jamesmcarthur has joined #openstack-tc04:20
*** jamesmcarthur has quit IRC04:25
*** whoami-rajat has joined #openstack-tc04:47
*** Luzi has joined #openstack-tc06:59
*** e0ne has joined #openstack-tc07:10
*** diablo_rojo has quit IRC08:29
*** dims has quit IRC08:32
*** dims has joined #openstack-tc08:33
*** tosky has joined #openstack-tc09:03
*** ricolin has quit IRC09:07
*** jpich has joined #openstack-tc09:15
*** cdent has joined #openstack-tc09:39
*** purplerbot has quit IRC11:32
*** purplerbot has joined #openstack-tc11:33
*** jamesmcarthur has joined #openstack-tc12:00
*** jamesmcarthur has quit IRC12:04
cdentare we low on nodes again12:48
*** e0ne has quit IRC12:53
fungilooks like we have >800 actively running jobs: http://grafana.openstack.org/d/rZtIH5Imz/nodepool?orgId=113:03
fungitripleo still accounts for nearly half our utilization, though they've been steadily decreasing over the past month according to clarkb's most recent analysis13:04
fungihard to know the impact of their efforts exactly with holidays and conferences underway13:04
*** whoami-rajat has quit IRC13:19
fungi(note that's not >800 jobs, but rather >800 nodes actively in use by running jobs, in case my phrasing was unclear)13:24
cdentI got it, thanks for the link. I always forget about the url for some reason13:25
fungiwe are down ~10% capacity because we were getting complaints about jobs running slow/timing out in one ovh region. after confirming with them that they're running a 2:1 cpu oversubscription ratio in our dedicated host aggregate i've tried halving our max in that region to see if it resolves the performance issues13:26
cdentI was trying to run a 2:1 over sub in my home testing rig and it completely tanked13:27
*** e0ne has joined #openstack-tc13:31
cdentI guess that can work if you're sparse, but not otherwise13:32
*** jamesmcarthur has joined #openstack-tc13:48
fungiright, in the case of a diverse user population it can be an effective means of utilizing all your resources13:51
fungiin this particular case it's a host aggregate dedicated to our ci system, so when our amplitude peaks it's akin to overdriving a waveform amplifier13:52
* cdent feedback solos13:53
* fungi breaks into a rousing bit of air guitar13:54
EmilienMfungi: anything we can do in tripleo to help? (like stopping to approve patches or anything)13:58
EmilienM(hi btw)13:58
* cdent waves13:59
* cdent stops crying13:59
*** jamesmcarthur has quit IRC14:04
fungiEmilienM: i think the efforts so far have been great, just more of the same (make jobs more efficient, combine jobs which are mostly redundant, et cetera)14:06
fungidiscourage unwarranted rebasing, encourage people to look into failures before blindly rechecking...14:07
EmilienMack14:09
*** mriedem has joined #openstack-tc14:29
scasi know i'm not the cause of the elevated usage. i had someone join the channel recently and mentioned that 'people' at the summit were saying chef is for-reals dead14:31
scasi have somewhat of the opposite effect happening, it seems14:31
fungisaying chef the configuration management ecosystem is dead, or the chef-openstack project specifically?14:33
fungii recall it coming up a couple times in conversation and i was sure to mention that you were doing an admirable job of keeping it going with the help of some other occasional contributors14:34
fungiand that it's definitely not dead, even if you were unfortunately unable to make it to the conference this time14:35
smcginnisI do recall Chef being mentioned at least once. Nothing about its health though.14:36
scasappreciate it. i probably heard something that came in through the hallway track. chef-openstack itself was apparently mentioned to a new-to-openstack person as being 'dead'14:37
scasin my head, that's a sign for me to actually finish writing some blog content14:39
dhellmannlbragstad : o/14:41
scassabbaticals have a way of making people think things :)14:41
lbragstaddoes anyone know if there is a document floating around for project-initiated leadership changes?14:41
lbragstadcc dhellmann ^14:41
cdentlbragstad: can you translate that to other words?14:42
lbragstadi know we just went through this with hodepodge and loci14:42
dhellmannyeah, the loci team is going through a change right now14:42
dhellmannI don't think we have a document per se, so that may be a good outcome of this new change14:42
lbragstada PTL wants to hand things over mid-cycle and they want to know if there is anything the TC expects in that transition14:42
lbragstadas far as crossing T's and dotting I's14:42
dhellmannthe transition should be announced on the ML, and then a governance patch proposed with the change14:42
lbragstadok - cool14:43
dhellmannI don't think we have any formal requirements about timing for new elections to replace PTLs like we do for TC members14:43
cdentthanks lbragstad, I thought you meant something like that but wasn't quite sure14:43
* lbragstad wonders if that should be written down14:43
lbragstadcdent np14:43
lbragstadi'm also not through my first cup of coffee, so... words are even harder at the moment14:44
dhellmannlbragstad : yeah, we should document it. I think we've always handled it as a "TC confirmation" thing so it should be a minimal update to the charter https://governance.openstack.org/tc/reference/charter.html14:44
dhellmannmaybe have some coffee and then see about a patch? :-)14:44
lbragstadyeah - i'll get something proposed this morning14:45
dhellmannlbragstad : maybe also make a note of this in the health tracker in the wiki under the section for this team. It's not serious if they have a new candidate now, but it's relevant if it turns into part of a trend (either with this team, or across teams)14:46
lbragstadgood point14:47
lbragstadnoted14:47
evrardjpdhellmann: that's interesting I didn't want to write anything in the health tracker while there were activities -- it seems the data can be quickly outdated14:56
evrardjpby activities I meant leadership discussions and changes.14:56
evrardjpbecause I'd say things changes with new leadership14:57
evrardjpbut writing the fact there is a new leadership is important14:57
evrardjpIMO14:57
dhellmannwriting something like "during stein changed PTLs due to $reason" seems ok, doesn't it?14:57
evrardjpyeah14:57
evrardjpon that I agree :)14:57
dhellmannthe idea is to use that page as a shared set of status notes14:59
dhellmannwith interpretation left up to the reader14:59
lbragstadi don't expect to update it with changed due to normal election process, though?14:59
fungishhh! it's time for another office hour15:00
fungi;)15:00
gmanno/15:00
ttxI'm around in case of questions, and have a canned one in case nobody says anything15:01
cdentthrilling15:01
* smcginnis takes his chair in the corner15:01
ttxAs previously announced, we/OSF are coordinating a regular (biweekly is the plan) newsletter for people who want to keep up with what's happening with our project(s) but are not ready (or don't have the time) to engage on ML.15:02
ttxThere should be a "openstack project news" section in there, let me know if you have anything significant to mention15:02
ttxWe already have a couple of items:15:03
dhellmannlbragstad : no, if there's an election everything is going normally15:03
ttx“Vision for OpenStack clouds” document published15:03
ttxopenstack mailing list merge15:03
ttxNew Autoscaling SIG15:03
scasjust wanted to mention it again that i appreciate what folks have heard through the grapevine about chef-openstack. it's not something i anticipate, but i can see where having a written policy regarding project lead succession out-of-cycle would be of benefit. i presume it would be a 'special election' type thing15:03
gmannttx: and what is target audience for that. operator, developer , end user ?15:04
*** Luzi has quit IRC15:04
ttxgmann: I'd say potential user / not directly engaged yet15:04
fungiscas: in the past there's basically been consensual appointment of an interim ptl until the next regularly-scheduled election15:04
ttxgmann: in Berlin we have talked about using that newsletter as the step 0 of community engagement15:05
fungiscas: we reelect ptls with great enough frequency that a <=6mo appointment isn't a huge concern15:05
*** cosss_ has joined #openstack-tc15:05
*** openstackgerrit has joined #openstack-tc15:06
openstackgerritLance Bragstad proposed openstack/governance master: Update charter to include PTL appointment  https://review.openstack.org/62092815:06
ttxWe'll likely put in place some etherpad for people to regularly drop OpenStack-news bullet points, but for the first one we are winging it a bit15:06
lbragstadopen for feedback ^15:06
gmanni see, that was my next question15:06
gmannthanks15:06
ttxOnce we have one out it will be clearer to replicate :) Fungi, diablo_rojo and myself should be on point to collect openstack bits15:07
scasi think arch is trolling me with fonts. i almost thought i had a dead pixel, but it was an accent mark15:07
ttxȧ15:08
ttx15:08
gmannttx: will you announce it on ML also for PTL or team to know about it ?15:09
dhellmannttx: I'm glad to hear the newsletter is taking off15:09
cdentttx: I think it is a great initiative. The thing I most worry about with those sorts of things is that if they are contribution driven, rather than reporting, its hard to get the _right_ contnet15:09
ttxgmann: there is a bit of chicken and egg -- will be much easier to talk about it once we have one out. It was announced on ML posts already15:09
gmannk15:10
*** ricolin has joined #openstack-tc15:10
ttxcdent: yeah, and making it _too_ crowdsourced usually fails (if past experiences are to be learned from)15:10
cdenton the flip side, reporting is time consuming15:10
ttxwhich is why it's a OSF newsletter... sourcing content from community15:11
gmannmain point is we cover all projects/sig to get it sourced from not the key projects only.15:12
ttxwe are still going back and forth on right length/content/frequency, but we'd like to push one out soon. Which is why I ask if tehre is anything critical to mention, beyond the 3 things already mentioned15:12
gmannThis is something i got feedback from blazar team also to have their things also publish, announce etc15:12
ttxobviously there is an editorial aspect to it too -- some "news" might not make the cut15:13
ttxalthough I'd rather worry of the opposite :)15:14
fungibut conversely, things may fail to get included if not brought to the attention of those assembling the newsletter15:14
ttxanyway, I did not want to abuse the office hour to talk about that, just something to keep in mind if you see newsworthy bits pass15:15
fungiif blazar or any other team is concerned that they're not getting their news isn't getting the visibility of the news for other things, they need to start supplying it15:15
fungier, that was a terrible sentence. i blame too much multitasking15:15
scasa while back, we mentioned not flying the help flag too hard. upstream, there is a library in chef itself that chef-openstack depends on. its future is even more precarious than chef-openstack, but i wasn't sure if it'd be too forward to have a mention in my next ml update. much like other roll-up updates, it'd be a bulletpoint15:16
dhellmannscas : I think that conversation was about communicating with the board, rather than discussions on our mailing list15:16
scasit's partly one reason why there hasn't been a chef ml update in a few months15:16
scasfair enough. things blur over time15:17
* dhellmann nods15:17
gmannfungi: +1, i told the same and there are few things which get not responded to them. example is user survey which i want to bring next15:17
fungiscas: explaining what bits of the project would be most effective/useful to get additional contribution on is great, in my opinion. just don't phrase it in an overly alarming doom-n-gloom sort of way15:17
gmannthat came from  Blazar health checking and my discussion with PTL in summit.15:17
openstackgerritMerged openstack/governance master: update chair guide reference to closed mailing list  https://review.openstack.org/62065615:17
openstackgerritMerged openstack/governance master: clarify chair responsibility for managing chair selection process  https://review.openstack.org/62065715:18
gmannBlazar is not in user survey and it was requested by PTL but no response or fixed.15:18
scasof course. i wanted a quick sanity check before i did send something out15:18
dhellmanngmann: that's good info to have, thanks15:18
gmannmay be ttx fungi ^^ can help to get them involve in user survey15:18
dhellmanndid you put that in the health-tracker wiki page?15:18
fungigmann: did their ptl not get contacted by aprice last time project-specific survey questions were solicited?15:18
dhellmannI would have thought the user survey would include all of the official projects15:18
fungigmann: that's been fairly standard process in the past15:19
dhellmannyeah, we should have all of that down pat by now :-)15:19
gmannfungi: i think no, he mentioned theyr requested but not heard back15:19
scasthe current maintainer did a good enough job at explaining the gloom on their end, if one looks through bug reports. i simply like for people to be aware, much like how fog-openstack caused some ruckus for some a while back15:19
fungigmann: it's possible they were overlooked, though what usually happens in these cases is that the ptl was e-mailed for input and never responded to those working to assemble the survey updates. that only happens periodically (yearly now i think)15:21
dhellmannyeah, we're only doing the user survey once a year now15:21
apricegmann: apologies for the oversight. we actually just kicked off the 2019 version at the Berlin Summit so it's an easy addition15:21
*** whoami-rajat has joined #openstack-tc15:21
openstackgerritMerged openstack/governance master: Retire openstack-ansible-os_monasca-ui  https://review.openstack.org/61732215:22
apricewe are reaching out to the PTLs in December for the project-specific questions that are asked at the end of the survey. We are planning to update all of these in January15:22
gmannfungi: aprice great, that will help. i can tell priteau to wait for that.15:23
dhellmanntc-members: how do folks feel about my proposed plan for landing our various resolutions for tracking python 3 release? http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000144.html15:23
scasappreciate the responses and feedback so far. i have something to work with15:23
dhellmannare we ready to move ahead with zaneb's bit in https://review.openstack.org/#/c/613145/ as it is or do we need updates?15:24
fungidhellmann: sounds great, i was waiting to rebase mine into place per that plan until the one which would go ahead of it is updated15:24
apricegmann: ok, great. It should be added to the project list shortly in the meantime. Happy to help with any other questions there may be15:24
gmannaprice: thanks again.15:25
smcginnisdhellmann: I'm good with moving ahead with it.15:25
dhellmannlet's get some votes lined up, then :-)15:25
dhellmannoh, smcginnis has already voted15:25
smcginnisI made some updates to how my declaration patch was done. Would appreciate any input if that is more clear.15:26
smcginnisMore betterer.15:26
*** mriedem is now known as mriedem_afk15:29
evrardjpfor https://review.openstack.org/#/c/611080/ I thought the addition of champions later would do15:30
smcginnisWhat champions though?15:30
smcginnisevrardjp: We are the champions, my friends. :)15:31
dhellmannsmcginnis : that new version looks good15:31
* fungi will certainly keep on fighting till the end (just like freddie!)15:31
evrardjpsmcginnis: I think you're watching too much sports, listening to music, and watch some recent movies.15:31
smcginnis:)15:32
evrardjpon top of that I think that latest version of smcginnis can be easily followed up by the reader wanting to know 'which version of python do I need for openstack version x'15:33
smcginnisThat was my hope.15:33
smcginnisI think it would be worth adding older release pages so there is a record of what was targeted at the time.15:33
dhellmannthat would be interesting info to track down for sure15:34
evrardjpfair.15:34
smcginnisAnother research project.15:34
ttxdhellmann: do you expect a new patchset on Zane's python3 review?15:34
evrardjpdhellmann: I am not sure the last iteam of the plan you sent on the ML does still apply15:34
ttxor more of a followup patch?15:34
evrardjpitem*15:34
dhellmannttx: maybe a follow-up to clear up the wording on setting the goal but the more I thought about it the more I like the slightly vague wording for the deadline section15:35
dhellmannevrardjp : do you think smcginnis' patch encompasses fungi's?15:36
evrardjpyes15:36
evrardjpwell15:36
evrardjpit doesn't really, but I think it has clarified enough, and for the reader, the rest of the pages are not referring to any version of python, which sounds good enough for me15:37
evrardjps/referring/explicitly hardcoding/15:37
dhellmannyeah, I guess I'd need to see them rebased together to tell for sure but you might be right15:37
fungias long as it drops the explicit python3.5 mention from reference/pti/python.rst i'm fine abandoning mine15:38
* fungi checks15:38
fungiyeah, looks like it basically incorporates the same changes from mine now15:40
evrardjpit gives an example, and points IIRC15:40
evrardjpok15:40
evrardjpthat is clarified then :)15:40
fungihis original version didn't alter reference/pti/python.rst (mainly i think because mine was the first to be proposed and the other two changes grew out of the subsequent discussions about it)15:41
dhellmannmakes sense15:42
evrardjpI might be the cause of that, but that sounded more intertwined in smcginnis 's patch, anyway...15:42
cdentnice progress all round I'd say15:43
fungithey were initially sort of written to be complimentary to each other, but subsequent revisions resulted in overlap15:43
* evrardjp whistles15:43
evrardjpsorry!15:43
fungino need to apologize. it's not as if i need more patches to my credit ;)15:44
fungiwe probably could have done this as revisions to my original but the different pieces were being kept separate so that their impact could be discussed independently15:45
dhellmannafter that lands, the next thing to take up is the list of LTS platforms. evrardjp, are you leading that set of changes?15:45
evrardjpyeah I'd like to. I am currently preparing something about that internally, and will use said time to come with a proper argument about what makes part of this list in governance15:46
dhellmannfungi : yeah, I think coming at it from several directions at once helped clarify what needed to change, so thank you for triggering the discussion and being gracious about the resolution15:47
dhellmannevrardjp : ok15:47
* fungi is always glad to incite others to heated debate15:47
cdentno you're not15:48
smcginnisI agree with cdent about the ideal being one platform, but since that is not likely I would be glad to see some version of SUSE added to the list of distros.15:48
cdent++15:48
evrardjplet's see how this pans out in the review :)15:48
dhellmannI'm not sure I see the point of focusing dev and testing upstream on the least used platform. It very much ignores the fact of how this project is used, not to mention backed.15:49
fungikeep in mind that at the moment we say ubuntu lts and centos, but we're vague enough about what it is we're testing that in practice it's mostly just devstack on ubuntu and tripleo on centos15:49
dhellmannif we're going to use that list of platforms to determine language version support, I'm comfortable extending it to include some other names, as long as we update our description of what the least means at the same time15:50
fungiand if it weren't for tripleo being an rh-centric project, we wouldn't really be living up to our claims to do integration testing on centos15:50
scaschef-openstack tests on centos and ubuntu. anything else is considered to be best effort, but i'm pretty sure chef-openstack could even dredge up the actually-dead freebsd implementation of openstack and get most of the way with it15:51
evrardjpsame applies within openstack-ansible15:51
fungiback when this was still sitting in a wiki article, in the before-time, the expectation was that we'd have devstack jobs exercising both ubuntu lts and centos, but the centos devstack jobs were poorly-maintained and often broken/disabled for months or years15:52
fungiso in actuality most of the time it was just ubuntu lts consistently, and occasionally some centos, until tripleo shifted their focus to rdo15:53
evrardjpclarification is indeed needed, I am tackling this, and I will probably come for help a little later :)15:53
scasi'm considering updating chef-openstack docs to clarify platform support. i mentioned freebsd only because i was following the progress before the implementer publicly gave up and it came to mind in context15:54
fungievrardjp: what integration testing is happening on opensuse these days? any devstack+tempest jobs? or is it mainly osad? or something else?15:55
cmurphydevstack itself tests on opensuse, looks like non-voting though15:56
fungii note that in the pti we don't actually say integration testing for those platforms, just "functional tests" which... could be interpreted in a lot of ways15:57
gmannyeah we have few job on n-v or experimental on opensuse15:57
gmannexample - https://github.com/openstack/nova/blob/8c318d0fb20fdfe0ae8e203245e4d4d6668c8a44/.zuul.yaml#L25415:57
gmannbut its experimental job15:58
* fungi suddenly realizes we've monopolized the office hour mostly for discussion between tc members, and feels guilty15:59
mnaser:<16:00
scasi've balanced it out with some non-tc noise!16:00
mnaseronly 2 non-tc participants unfortunately16:01
fungiscas: yes, thank you!!!16:01
*** dklyle has joined #openstack-tc16:01
cmurphyI don't think it's a problem for TC members to chat during the TC office hours, especially when it would most likely otherwise be quiet16:01
mnaserfungi: openstack ansible does CI for centos and its fully supported :)16:01
cmurphyif people have thoughts on the topic (which scas did) they can chime in16:02
fungithere was an assertion that non-tc lurkers are hesitant to speak up in this channel when they see us discussing something that looks important16:02
scashonestly, tc office hours is probably the one time that people know they'll have high bandwidth responses. it makes sense that it's largely tc members talking to tc members, in lieu of physical/video/voice interaction16:02
cmurphyI think most people in the community are trained to know that if there is an important community-wide topic they want input on, they use the mailing list16:03
cmurphythe office hour feels like it's more for chatting than about bringing up important issues16:04
evrardjpfungi: cmurphy gmann interesting you're busy doing what I was doing today -- a real map of what the project are actually gating :p16:04
scasit can also be hard to jump in at times, at the times of day if folks are particularly incensed16:04
evrardjpofc it's no surprise16:04
scasmuch like a group of people engaged in deep conversation with one another, the casual observer wants to let them be16:04
*** jamesmcarthur has joined #openstack-tc16:05
scasknowledge workers are also particularly engaged at this time of morning. many commute during this time of day, or they're in other high bandwidth interactions16:06
scasin PST, it's barely after 0800. the 5 is a parking lot, i'm certain16:07
*** jamesmcarthur has quit IRC16:10
*** mriedem_afk is now known as mriedem16:22
*** e0ne has quit IRC16:26
*** ricolin has quit IRC16:26
*** e0ne has joined #openstack-tc16:38
*** e0ne has quit IRC16:48
*** david-lyle has joined #openstack-tc17:04
*** dklyle has quit IRC17:05
*** jamesmcarthur has joined #openstack-tc17:24
*** cosss_ has quit IRC17:24
*** jpich has quit IRC17:29
*** david-lyle has quit IRC18:15
*** jamesmcarthur has quit IRC18:24
*** diablo_rojo has joined #openstack-tc18:31
*** dklyle has joined #openstack-tc18:45
*** dklyle has quit IRC19:07
*** jamesmcarthur has joined #openstack-tc19:37
*** jamesmcarthur has quit IRC19:50
*** jamesmcarthur has joined #openstack-tc19:52
*** whoami-rajat has quit IRC19:56
*** jamesmcarthur has quit IRC20:00
*** e0ne has joined #openstack-tc20:20
*** jamesmcarthur has joined #openstack-tc20:25
*** jamesmcarthur has quit IRC20:29
*** e0ne has quit IRC20:30
*** jamesmcarthur has joined #openstack-tc20:53
*** dklyle has joined #openstack-tc21:10
openstackgerritSean McGinnis proposed openstack/governance master: Add openstack/arch-design repo for Ops Docs SIG  https://review.openstack.org/62101321:34
*** dklyle has quit IRC21:39
*** cdent has quit IRC21:40
*** jamesmcarthur has quit IRC21:48
*** jamesmcarthur has joined #openstack-tc21:48
openstackgerritLance Bragstad proposed openstack/governance master: Update charter to include PTL appointment  https://review.openstack.org/62092821:50
*** jamesmcarthur has quit IRC22:03
*** dklyle has joined #openstack-tc22:19
*** dklyle has quit IRC22:24
*** dklyle has joined #openstack-tc22:32
*** mriedem is now known as mriedem_afk22:33
*** dklyle has quit IRC22:44
clarkbhello TC I know it isn't office hours, but this is sort of on my mind recently due to gate behavior and compounding factors from the underlying clouds that we dogfood openstack through. In berlin I brought up quality as a goal we should have in the goals session. I think we all agreed that this doesn't quite fit the goals framework but there also seemed to be agreement that it would be worthwhile22:49
clarkbIn concrete terms the infra team has been watching various gate queues struggle to merge code due to flaky tests/software, but also flaky clouds (that run our software). Things like duplicate IP addresses fighting each other with ARP leading to jobs that have ssh host key verification errors, networking just straight up breaking in multiple clouds making our mirrors unreliable/unresponsive, port leaks22:51
clarkbin neutron leading to quota limits being hit, and I'm sure I could dig up a bunch of other things if I went looking22:51
clarkbwhile I don't have hard data to support this, it feels like this is sort of a snowballing feedback loop. We've effectively lowered our standards upstream, downstream deploys said software, and then we get to feel the results in the form of flakyness22:51
clarkbany thoughts on how we can make quality a goal/objective? and hopefully reverse the direction this snowball is rolling in and produce software that works better for our clouds leading to more reliable testing?22:52
mnaserclarkb: i agree with this a lot22:54
mnaserunfortunately i think not a lot of people look/care about gate problems22:55
mnaserlet me just put "recheck" and we're good22:55
mnaserbit of a bummer too, because infra donations really aren't cheap.22:55
clarkbyup I think that definitely feeds into it. I think we've also abstracted the gate enough where people don't perceive gate failures as future production failures22:55
clarkbwhen the reality is they very likely are/will be22:55
mnaserim not really sure what we can do to help this other than make changes to zuul to prioritize jobs that pass more often to run before those that faila ll the time22:56
clarkbmnaser: and ya it would also be good to be better stewards of the resource we are given (by treating the output of that system as valuable)22:56
mnaser"want your jobs to run faster and be ahead? make sure your jobs are stable"22:57
clarkbmnaser: one concern I have with that approach is the trivial way to fix jobs is to delete tests22:57
clarkband then we are arguably in a worse spot becaus the jobs pass but don't cover things we know are broken22:57
clarkbone (admittedly less practical idea) I had was to encourage a sort of "sdague/jogo/mtreinish" rotation. Basically have a group of people that can take on the tasks they did in the past, but be explicit that it shouldn't be a full time thing to help avoid burn out but also ensure more than one person knows what to do23:03
clarkba lot of that work is/was categorize failures with elastic-recheck, then when identification rate is high dig into the most problematic issues23:04
clarkbeventually you brun down the list and things get stable23:04
clarkbthe trick is to not stop at that point23:04
mnaserclarkb: I agree. It is important to do this type of initiative.23:06
mnaserFor example in OpenStack Ansible world we don’t really use elastic recheck which isnt great but sometimes we have failures which occur in tempest that are kinda out of our scope23:07
mnaserclarkb: I’m almost tempted to say that maybe weshould introduce another “tier” in the review before code review23:08
mnaserOnce a commit has a core who gives an initial +2, then we start running tests on it23:08
clarkbmnaser: if were honest cores are just as bad as anyone else :P23:08
mnaserThat won’t improve on quality of code but at least reduce the amount of churn we have. I dunno.23:08
mnaserAt least if something is glaring bad it doesn’t have to undergo CI to get a -1 anywys23:09
mnaserNot bad, wrong rather23:09
clarkbI'm not sure a mechanical change will help much. The issue (from where I sit) is we undervalue quality23:09
clarkbwe overvalue JFDI23:09
mnaserIt’s a lot easier to type recheck than debug an issue23:11
clarkbyup23:11
clarkbbut chances of your code actually merging if the issue is debugged is way higher23:11
clarkband that seems to be the piece we miss out on23:11
*** dhellmann_ has joined #openstack-tc23:26
*** dhellmann has quit IRC23:26
*** dhellmann_ is now known as dhellmann23:30

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!