| *** tosky has quit IRC | 00:02 | |
| *** mriedem has quit IRC | 00:15 | |
| *** mriedem has joined #openstack-tc | 00:17 | |
| *** edmondsw has quit IRC | 00:17 | |
| fungi | tc election ballots are all out now | 00:21 |
|---|---|---|
| diablo_rojo | I voted! | 00:22 |
| fungi | as did i | 00:22 |
| fungi | even though it's all a convenient fiction ;) | 00:22 |
| diablo_rojo | Already had 26 votes :) | 00:24 |
| *** jamesmcarthur has joined #openstack-tc | 00:47 | |
| *** mriedem has quit IRC | 00:47 | |
| *** lbragstad has quit IRC | 00:59 | |
| *** jamesmcarthur has quit IRC | 01:01 | |
| *** jamesmcarthur has joined #openstack-tc | 01:02 | |
| fungi | and it's office hour once more | 01:03 |
| smcginnis | o/ | 01:03 |
| gmann | o/ | 01:07 |
| fungi | pretty sure we're all talked out after the past week | 01:09 |
| smcginnis | Everyone is thoroughly rereading all the ML responses before casting their votes. | 01:10 |
| gmann | +1 | 01:11 |
| gmann | btw do we have next board meeting planned(invitation ) ? i would like to join as I am in same TZ now. | 01:12 |
| mnaser | invites dont go out apparently anymore | 01:13 |
| mnaser | also | 01:14 |
| mnaser | welcome to the coldest place on earth :) | 01:14 |
| gmann | :), thanks | 01:14 |
| smcginnis | gmann: The next board meeting is March 5 - https://wiki.openstack.org/wiki/Governance/Foundation#OpenStack_Board_of_Director_Meetings | 01:15 |
| gmann | thx. | 01:16 |
| clarkb | mnaser: not automatically from webex since no more webex but jbryce is appare tly going to try to se d out future invites | 01:17 |
| mnaser | cools | 01:18 |
| mnaser | that's nice clarkb thanks | 01:18 |
| jbryce | I actually sent an email to Alan earlier to see if he wanted to send it or if I should. If I don't hear back by tomorrow I'll just send something out (didn't want to preempt him if he had a different plan) | 01:36 |
| jbryce | Question for that: did any of you add the calendar invites from webex or just read the email | 01:37 |
| fungi | i always just read the e-mail | 01:38 |
| gmann | jbryce: thanks. email read most of time. | 01:39 |
| *** edmondsw has joined #openstack-tc | 01:43 | |
| mnaser | jbryce: email automatically popped up an invite in my calendar which was neat | 01:46 |
| *** lbragstad has joined #openstack-tc | 01:58 | |
| *** whoami-rajat has joined #openstack-tc | 02:01 | |
| *** jamesmcarthur has quit IRC | 02:18 | |
| *** jamesmcarthur has joined #openstack-tc | 02:20 | |
| *** jamesmcarthur has quit IRC | 02:25 | |
| *** jamesmcarthur has joined #openstack-tc | 02:55 | |
| *** jamesmcarthur has quit IRC | 03:01 | |
| *** spsurya has joined #openstack-tc | 04:15 | |
| *** jamesmcarthur has joined #openstack-tc | 04:46 | |
| *** jamesmcarthur has quit IRC | 05:19 | |
| *** ricolin has joined #openstack-tc | 05:21 | |
| *** ricolin has quit IRC | 05:35 | |
| *** Luzi has joined #openstack-tc | 06:47 | |
| *** jamesmcarthur has joined #openstack-tc | 06:49 | |
| *** jamesmcarthur has quit IRC | 06:54 | |
| *** e0ne has joined #openstack-tc | 07:09 | |
| *** e0ne has quit IRC | 07:16 | |
| *** jamesmcarthur has joined #openstack-tc | 07:51 | |
| *** jamesmcarthur has quit IRC | 07:55 | |
| *** e0ne has joined #openstack-tc | 07:57 | |
| *** lbragstad has quit IRC | 08:01 | |
| *** zbr|ssbarnea has joined #openstack-tc | 08:21 | |
| *** zbr|ssbarnea is now known as zbr | 08:22 | |
| *** tosky has joined #openstack-tc | 08:41 | |
| *** jamesmcarthur has joined #openstack-tc | 08:51 | |
| *** jamesmcarthur has quit IRC | 08:56 | |
| *** e0ne has quit IRC | 08:57 | |
| *** jpich has joined #openstack-tc | 09:04 | |
| *** bsilverman has quit IRC | 09:09 | |
| *** cdent has joined #openstack-tc | 09:25 | |
| *** Luzi has quit IRC | 09:36 | |
| *** Luzi has joined #openstack-tc | 09:51 | |
| *** jamesmcarthur has joined #openstack-tc | 09:52 | |
| *** jamesmcarthur has quit IRC | 09:57 | |
| *** e0ne has joined #openstack-tc | 11:16 | |
| bauzas | zaneb: sorry, I tried to reply without hitting the end of campaign | 11:40 |
| bauzas | zaneb: so my thoughts is that if we want to discuss about architectural concerns, we just need to discuss with the community, not only us | 11:41 |
| bauzas | hence the 'reality wall' | 11:41 |
| *** jamesmcarthur has joined #openstack-tc | 11:54 | |
| *** jamesmcarthur has quit IRC | 11:59 | |
| *** Luzi has quit IRC | 12:00 | |
| *** Luzi has joined #openstack-tc | 12:02 | |
| *** tbarron has joined #openstack-tc | 12:08 | |
| aspiers | hi folks, where should I ask about a PTG discount code which stopped working? | 12:49 |
| aspiers | "Sorry, the promotional code you entered is not valid." | 12:50 |
| aspiers | It worked fine a week or two ago when I started to register, but I did not complete the process at the time | 12:51 |
| jroll | aspiers: probably summitreg@openstack.org | 12:52 |
| aspiers | yeah I've just mailed them | 12:52 |
| gmann | aspiers: hope deadline is not over | 12:53 |
| aspiers | it is not | 12:53 |
| mugsie | bauzas: we can still "campaign" in this time - just not all people who vote will be able to take it into account | 12:53 |
| mugsie | that is how it was before we had the campaign period (2 or 3 elections ago) | 12:54 |
| aspiers | gmann: it closes in ~18 hours | 12:54 |
| jroll | zaneb: +1000 on "stop stifling ideas" | 12:54 |
| *** jamesmcarthur has joined #openstack-tc | 12:55 | |
| gmann | aspiers: yeah 11:59pm PT on Wednesday, February 27 | 12:55 |
| *** jamesmcarthur has quit IRC | 12:59 | |
| aspiers | seems there may be a wider problem with the codes | 12:59 |
| aspiers | cmurphy has an issue too | 13:00 |
| cmurphy | probably have to wait for event staff in the US to wake up | 13:01 |
| aspiers | yeah | 13:01 |
| mugsie | jroll: :) | 13:04 |
| *** mriedem has joined #openstack-tc | 13:44 | |
| *** jamesmcarthur has joined #openstack-tc | 13:48 | |
| bauzas | mugsie: jroll: I think I was misunderstood unfortunately | 13:49 |
| bauzas | mugsie: jroll: I don't want to veto any idea | 13:50 |
| bauzas | mugsie: jroll: just the fact that we should discuss ideas with UC and contributors | 13:50 |
| *** e0ne has quit IRC | 13:50 | |
| bauzas | because an idea needs an owner | 13:51 |
| bauzas | and a usecase | 13:51 |
| bauzas | that's it | 13:51 |
| bauzas | I'm a bit sad to see this torn by the last hour *after* the campaign deadline, but meh :) | 13:51 |
| jroll | bauzas: I understand what you mean. the discussion we were having there is "what would you like to see changed", not "what idea do you want to force on the community". :) | 13:55 |
| cmurphy | aspiers: et al someone pointed me to the write email describing which combination of 2 out of my 3 codes to apply and how so all good :) | 13:56 |
| jroll | bauzas: it's like me and you talking about ideas over lunch or a drink. obviously we can't just do it without the rest of the community, but we can still talk about it :) | 13:56 |
| bauzas | jroll: yeah and I replied on this http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002965.html | 13:57 |
| * bauzas loves hallways discussions btw. ;) | 13:58 | |
| jroll | bauzas: I think we're talking past each other, sorry :/ | 14:02 |
| bauzas | jroll: and just in case, here are my architectural points I'd love to have thanks to a magic hand : 1/ make sure we can scale *every* project from 0 to the infinity, 2/ have API microversions for each project, 3/ have smooth rolling-upgrades for every service project | 14:02 |
| bauzas | jroll: heh, no worries | 14:02 |
| * jroll wrote 5 different messages trying to explain what zane was saying and didn't like any of them | 14:02 | |
| bauzas | we all have opinions, it's fair to say it, and we all also have architectural concerns | 14:03 |
| jroll | yes, this | 14:03 |
| bauzas | so we need some way to respect all of us by having a large consensus about the direction we want to go | 14:04 |
| *** e0ne has joined #openstack-tc | 14:04 | |
| jroll | what zaneb was saying is it's fair to say opinions, let people do it without talking about project managers and user community and so on :) | 14:04 |
| bauzas | getting this consensus is the hardest thing we can do, it's like football game strategies : everyone has an opinion about what we *could* do | 14:04 |
| bauzas | jroll: maybe talking of PMs was a strawman but I'm a very pragmatic folk and I don't want to run for a TC seat by having ideas I can't see them happening | 14:06 |
| bauzas | and I just wanted to clarify this | 14:06 |
| bauzas | i apologize if my message was somehow scrambled | 14:06 |
| bauzas | hence my reply to lance clarifying things | 14:06 |
| jroll | sure, that's fair | 14:07 |
| jroll | the question was explicitly about ideas that may not be pragmatic :P | 14:07 |
| jroll | I assume to get to know the candidates as a person, since most questions are about the candidate as a tc member | 14:08 |
| bauzas | yup, and I love this campaign | 14:09 |
| cdent | Yes, it was a way of seeing into the minds of the candidates, from one of many angles. | 14:09 |
| bauzas | hard questions that were requiring more than a single thought before writing | 14:09 |
| cdent | But I have to admit that part of the goal was to see how willing people were to really express their true feeling about what they want | 14:10 |
| cdent | To get a guage of how aspirational the canidate is | 14:10 |
| evrardjp | cdent: +1 | 14:10 |
| bauzas | I hope my personal opinions were correctly explained, thanks to cdent, evrardjp and dhellmann | 14:10 |
| smcginnis | Really good discussions this time around. | 14:10 |
| bauzas | I can be a dreamer hence being a pragmatic person | 14:11 |
| bauzas | I just don't want to be disappointed by my influence on the TC if I have large aspirational goals that can't be achieved in a reasonable timeframe | 14:12 |
| bauzas | so I prefer to somehow be more pragmatic when I answer (as the answer is not only directed to the readers, but also to me) | 14:12 |
| jroll | totally fair | 14:12 |
| jroll | fwiw, I don't expect any of the things I mentioned can be completed in a year, no matter the method or how many people agree :P | 14:13 |
| *** jamesmcarthur has quit IRC | 14:14 | |
| *** Luzi has quit IRC | 14:17 | |
| bauzas | jroll: you also know me and I hope you remember I'm not a controversial person in terms of gamechanging projects | 14:18 |
| bauzas | but I like people who do this | 14:18 |
| jroll | yep :) | 14:19 |
| bauzas | anyway, back to work, I also like discussing here | 14:19 |
| bauzas | I barely follow the #-tc channel, my bad | 14:19 |
| jroll | no worries :) enjoy | 14:20 |
| *** lbragstad has joined #openstack-tc | 14:20 | |
| fungi | aspiers: jroll: cmurphy: kendall waters who does event coordination on the osf staff is awake and looking at messages for the summitreg alias now. apparently the ptg attendee discount codes expired early, so if someone thinks they might be running into that they can reach out to the summitreg address mentioned in their invite e-mail to get it sorted out | 14:32 |
| aspiers | fungi: thanks! yeah it seems kendall has already renewed mine :) | 14:33 |
| jroll | ++ thanks fungi | 14:33 |
| aspiers | fast work | 14:33 |
| fungi | she both amazing and efficient, yes | 14:34 |
| fungi | er, she is | 14:34 |
| aspiers | like everyone at osf :) | 14:34 |
| fungi | oh, i just hide my inherent laziness behind a mask of efficiency, that's all | 14:40 |
| *** jamesmcarthur has joined #openstack-tc | 15:03 | |
| zaneb | bauzas: so context here is that I have personally raised one of the ideas that mugsie mentioned as being worthy of discussion on multiple occasions | 15:36 |
| zaneb | on no occasion has anybody with technical knowledge of the details explained to me what we would lose by doing that | 15:36 |
| zaneb | but on every occasion somebody has angrily told me to STFU and stop interfering | 15:37 |
| zaneb | TBH it took me a long time to send that email because I was trying to figure out the right tone, given that you were *not* one of those people | 15:37 |
| mugsie | yeah, it is also worth noting that my list was based on being an operator of OpenStack | 15:39 |
| zaneb | bauzas: anyhow, it's fine to continue the discussion now that voting has opened. it's better to discuss earlier before anyone has voted but unfortunately I was travelling at the end of last week and had to compress my reply time | 15:40 |
| mugsie | and, like zaneb points out ^, when people do suggest things, there is a high risk of getting shouted down. | 15:43 |
| mnaser | i dunno | 15:44 |
| mugsie | the only reason I didn't stop was I can be quite stubborn, but for a lot of people, when they see what happens to people who do suggest things, they decide it is not worth it and move on. | 15:44 |
| mnaser | sometimes i do feel we're pretty behind on some fundamental things | 15:44 |
| evrardjp | mnaser: go on? | 15:44 |
| mnaser | and looking at these nice ideas is fun but it feels like we need to play catch up on that | 15:44 |
| mnaser | i.e.: one of our contributors in OSA works at the BBC RD, he's been contributing a ton, he has convinced his org to get developers on-board and he's been adding more efforts from their side | 15:45 |
| mugsie | mnaser: sure - but I think some of the ideas would enable a lot of the other issues to be fixed along the way | 15:45 |
| mnaser | they have a *strict* admin/public/internal network structure, a project hasn't been following it very strictly and it breaks them | 15:46 |
| mnaser | they've been digging through that project source code, trying to figure out a fix, sent ML posts that go unanswered.. essentially our whole model of admin/internal/public is broken and not tested properly | 15:46 |
| zaneb | mnaser: I'm gonna look into that more today btw | 15:47 |
| mugsie | mnaser: so they don't want any of the admin functions to be exposed on the admin endpoints? or just having 3 endpoints breaks the project? | 15:47 |
| zaneb | mugsie: the latter | 15:47 |
| mnaser | i suggested that we improve devstack/devstack-gate to add 3 networks so we actually properly test this in our gates | 15:47 |
| mugsie | yeah - we had that for a while as well. we had to enable parsing the Host header to fix it | 15:48 |
| mnaser | in his case, the networks don't even communicate with each other | 15:48 |
| mugsie | mnaser: the guidence for the last while was that the 3 URLs were legacy, and everything should be on public | 15:48 |
| mnaser | so projects start breaking | 15:48 |
| mugsie | and it was only for network separation - but it caused people to stop worrying about it as much | 15:49 |
| mugsie | having devstack test it is a good idea | 15:49 |
| smcginnis | Not test == broken, right? | 15:49 |
| mugsie | exactly | 15:49 |
| mnaser | imho we should have these 'best practice' documents that we work on as tc to come up with to help answer those questions | 15:50 |
| mnaser | should you run 3 endpoints, should they all work, do we drop that model, consistency across openstack | 15:50 |
| mugsie | yeah - we did hand off a lot of that to the API SIG - http://specs.openstack.org/openstack/api-sig/ | 15:53 |
| mugsie | endpoints are not documented there though | 15:53 |
| * mugsie makes a note | 15:54 | |
| fungi | just to be clear, let's please not extend devstack-gate at all. it's legacy cruft which, if gmann's plan succeeds, will eventually die with the stable/rocky branch and its predecessors | 16:02 |
| cdent | mugsie: as I recall, back when the sig was a wg, the concept of multiple-endpoints was considered outside the domain of "what makes a good api". It's layer above | 16:02 |
| dhellmann | I had no idea there was such a plan | 16:02 |
| fungi | devstack-gate is a remnant of our zuul v2 design for devstack jobs | 16:02 |
| dhellmann | (at least not before this week) | 16:02 |
| cdent | mugsie: I recall many a design summit discussion about killing the split and letting "the network do it" | 16:03 |
| fungi | well, the qa team has, at least, not committed to finding ways to make the "legacy" (devstack-gate using) devstack jobs work on ubuntu bionic | 16:03 |
| fungi | so if we want to stop running integration jobs on xenial for the stein release, then that means devstack-gate becomes unnecessary for stable/stein and later | 16:04 |
| gmann | fungi: dhellmann with first and fast way to move legacy job to bionic not converting them to zuulv3. once we do zuulv3 then, devstack-gate can go away | 16:05 |
| gmann | converting them to zuulv3 which automatically move them to bionic can take time for many of the projects and might be difficult to finish in steni | 16:05 |
| dhellmann | that all makes sense. did I miss a mailing list thread explaining it? (that's likely, I haven't been doing a good job of keeping up with the list this cycle) | 16:05 |
| fungi | ahh, well also the infra team (who has been maintaining the devstack-gate repo up to this point) has considered it basically frozen since zuul v3 went into production, so would likely be looking for new maintainers if it needs any updating | 16:06 |
| gmann | so first i want to achieve the target of running all integration jobs to bionic by stein | 16:06 |
| fungi | if devstack-gate works fine as is on bionic, then switching the legacy jobs to run on bionic for stein is probably an okay interim solution, even if disappointing | 16:07 |
| gmann | fungi: +1 on freeze, if anyone want update then we ask them to move to zuulv3 | 16:07 |
| gmann | fungi: yeah, i am giving that a try first. | 16:07 |
| fungi | curious to hear how it goes | 16:08 |
| fungi | i do strongly suspect that projects with a lot of in-repo devstack-gate hook scripts and devstack plug-ins may have trouble | 16:08 |
| fungi | but i guess it's up to them to work that out | 16:08 |
| gmann | yeah, i am tracking that on this etherpad - https://etherpad.openstack.org/p/legacy-job-bionic | 16:09 |
| gmann | not many projects started yet. I will add another reminder by friday. | 16:10 |
| *** openstackgerrit has joined #openstack-tc | 16:12 | |
| openstackgerrit | Merged openstack/governance master: Update WSGI goal status for Manila https://review.openstack.org/637891 | 16:12 |
| gmann | dhellmann: mailing list thread you mean for legacy job moving to bionic or for d-g future plan ? | 16:12 |
| dhellmann | gmann : explaining the future plans and the deprecation of devstack-gate | 16:12 |
| gmann | i am not aware of that . may be fungi knows if there is any | 16:14 |
| smcginnis | I think the suggestion is to start a ML thread explaining what the plan and goal is there. | 16:15 |
| fungi | yeah, the infra team has considered devstack-gate deprecated ever since the official devstack jobs switched to the zuul v3 native playbooks in the openstack-dev/devstack repo, since only auto-converted zuul v2 jobs with "legacy" in their names use it | 16:17 |
| fungi | i don't think the infra team has any specific sunsetting pipeline for the repo itself | 16:18 |
| fungi | er, sunsetting timeline | 16:18 |
| fungi | it's just been basically frozen for over a year waiting for projects to replace their legacy jobs | 16:19 |
| gmann | fungi: is there any deadline for projects to move to zuulv3 ? | 16:20 |
| smcginnis | Yeah, and I don't think the projects are really aware that there's any kind of urgency to do anything about those legacy jobs. | 16:20 |
| fungi | gmann: no deadline as far as i know | 16:20 |
| fungi | i mean, projects are already using zuul v3, but if you mean to move off legacy auto-converted job definitions from zuul v2 there's no deadline | 16:21 |
| gmann | ok | 16:21 |
| tbarron | gmann: dhellmann: for cinder and manila (and neutron?) an additional challenge for converting jobs are the third-party jobs that were built on zuul v2 | 16:22 |
| tbarron | smcginnis: ^^ correct if I mis-speak for cinder | 16:22 |
| tosky | fungi: re auto-converted zuul jobs: I think I have seen legacy jobs being imported without the "legacy" keyword in their name | 16:22 |
| gouthamr | either that, or at some point we had a change that removed the word -legacy- from the job names | 16:23 |
| tbarron | fungi ^^ | 16:23 |
| tosky | gouthamr: whyyyy :) | 16:23 |
| fungi | tosky: sure, but if they likely still use the "legacy" playbooks in the openstack-infra/openstack-zuul-jobs repo | 16:23 |
| gmann | yeah or in-tree playbook | 16:24 |
| tosky | fungi: right, probably searching for zuul-cloner would do the trick | 16:24 |
| fungi | specifically the ones at https://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy | 16:24 |
| smcginnis | tbarron: True | 16:24 |
| clarkb | gouthamr: tosky people have added new jobs on legacy tooling without legacy in the names | 16:24 |
| clarkb | we've complained about it, but with jobs living in projects there isn't much we can do | 16:25 |
| clarkb | the jobs that the infra team converted should all have started out with the legacy nomenclature | 16:25 |
| tbarron | smcginnis: herding cats**2 | 16:25 |
| smcginnis | ++ | 16:25 |
| dhellmann | smcginnis : we should, but I was honestly assuming I had missed it | 16:32 |
| smcginnis | I may have as well. | 16:34 |
| gouthamr | fwiw tosky clarkb, we still have a legacy playbook folder in manila and all these legacy jobs inherit from "legacy-dsvm-base" | 16:34 |
| clarkb | gouthamr: cool so those are labeled properly? | 16:36 |
| gouthamr | clarkb: yeah, not apparent in the job names though, i.e, the job name is "manila-grenade" instead of "legacy-manila-grenade" (if that's what it should be) | 16:37 |
| tbarron | gouthamr: I at least missed the 'do not rename' directive though I have no problem adhering to it (and renaming these back) | 16:37 |
| gouthamr | tbarron: https://docs.openstack.org/infra/manual/drivers.html#consistent-naming-for-jobs-with-zuul-v3 was cited in the review that renamed the jobs.. | 16:39 |
| gouthamr | and it does suggest the "legacy-" be dropped from the name | 16:40 |
| fungi | i don't think anyone was told not to rename jobs. the infra team just said they're not going to update the legacy playbooks in openstack-zuul-jobs (or make changes of significance to tools like devstack-gate and zuul-cloner which are remnants of zuul v2) | 16:40 |
| tosky | gouthamr: when creating the native Zuul v3 job, sure :) | 16:40 |
| clarkb | gouthamr: it suggests you drop legacy- from the name when you rewrite the job to be zuulv3 natve iirc | 16:40 |
| tbarron | well I think the *main* point here is that using the name to find the legacy jobs isn't a reliable method | 16:40 |
| clarkb | the legacy jobs are shim jobs from the zuulv2 conversion and not zuulv3 native | 16:41 |
| tbarron | we'll name the jobs however there is guidance | 16:41 |
| clarkb | tbarron: yes I would agree with that | 16:41 |
| gouthamr | tosky clarkb: yes, lost in translation for me :) | 16:41 |
| fungi | those are basically frozen in time and exist to support auto-converted job definitions, with an expectation that if people need their converted jobs to do something new they need to replace them | 16:41 |
| tbarron | fungi: and as you know I have no problem with that policy but do think it would help to re-iterate/emphasize it | 16:42 |
| tbarron | and I think the third-party jobs are an extra wrinkle b/c we already face a challenge keeping vendors involved and maintaining these | 16:43 |
| tbarron | much less converting them | 16:43 |
| tosky | tbarron: do you have an inventory of which of your base jobs are used/inherited by 3rd-party jobs? | 16:44 |
| gmann | or directly "legacy-dsvm-base" ? | 16:45 |
| *** gouthamr_ has joined #openstack-tc | 16:46 | |
| tbarron | tosky: I don't have those jobs definitions, could study their logs I guess | 16:46 |
| clarkb | re third party jobs we've never been directly responsible for those. We can keep code and repos up (and probably even hand over control to interested parties), but I don't think we should be expected to ensure that third party test jobs work indefinitely | 16:47 |
| tbarron | clarkb: agree with the principle - smcginnis think about implications though ^^^ | 16:48 |
| tosky | tbarron: even if they are not going to disclose them, maybe you can ask for the output of a (git) grep with "parent:" as argument | 16:48 |
| *** gouthamr has quit IRC | 16:48 | |
| tosky | on their repository | 16:48 |
| tbarron | tosky: it's not that they refuse to disclose, I just said that I don't *have* the info to answer your question | 16:48 |
| tosky | oh | 16:49 |
| clarkb | the zuul jobs api may expose thsi for us too | 16:49 |
| clarkb | in theory you can do a webcral of all listed jobs and lookup their parent hierarchy | 16:49 |
| clarkb | then for any with the legacy dsvm job as a parent add them to the list? | 16:49 |
| tosky | but they may inherit from manila jobs | 16:50 |
| fungi | yeah, it's more that we didn't design their systems. some third-party ci operators banded together over time to work out solutions amongst themselves and used a lot of the same tooling we do. we can continue to make that tooling available but we lack the resources to continue updating it and also manage our more modern solution | 16:50 |
| *** gouthamr has joined #openstack-tc | 16:50 | |
| *** gouthamr_ has quit IRC | 16:50 | |
| fungi | lots of the third-party ci operators are in fact still using jenkins and jjb configs | 16:51 |
| tosky | tbarron, gouthamr : if I remember correctly the discussion during last PTG, you can actually port the jobs to zuul v3, as long as you don't remove the existing post/pre gate hook scripts in the repository | 16:51 |
| tosky | the risk is that those script may get out of sync with the changes applied to the zuul v3 jobs | 16:51 |
| fungi | i also see plenty to this day setting up jenkins with the gerrit-trigger plugin, no zuul whatsoever | 16:51 |
| smcginnis | I think there's still more documentation and guidance out there around setting up Jenkins for third party CI than there is for setting up Zuul. | 16:52 |
| clarkb | smcginnis: thats fine | 16:52 |
| smcginnis | I can't blame them for just going with what appears to be the easiest approach, even if running zuul and sharing that steup knowledge would be better. | 16:53 |
| gouthamr | tosky: you're right, i've not heard of third party CIs depending on in-tree manila job definitions to inherit from... so our transition shouldn't affect them as long as we don't remove pre-test and post-test hook scripts that we currently have | 16:53 |
| tbarron | to be clear I wasn't saying that we can't convert manila first party jobs to zuulv3 b/c of third-party jobs | 16:55 |
| tbarron | we can and should | 16:55 |
| tbarron | there are some challenges there for us but those are independent of 3rd party jobs | 16:55 |
| gouthamr | +1 | 16:56 |
| tbarron | i was just saying that if the goal is to get rid of the old infra that we need to take the 3rd party jobs into account too | 16:56 |
| tbarron | and figure some plan for their eventual conversion | 16:56 |
| clarkb | worth noting that the rules set out for third party ci systems are fairly basic. We require they provide enough info back to us that a failed job can be reasonably debugged and provide meanginful input. We don't require the the jobs use any particular ci system or test framework or that they run on any particular platform | 17:00 |
| *** e0ne has quit IRC | 17:00 | |
| clarkb | all that to say we shouldn't assume they will ever be converted. But at the same time we can't be responsible for what they do run. If they would like to care for existing tools we are moving beyond then we can hand over control of those | 17:01 |
| *** mriedem is now known as mriedem_away | 17:01 | |
| tbarron | clarkb: so we're going to need to over-communicate with the third party CI folks | 17:06 |
| tbarron | clarkb: not because that's fair or required in some abstract sense | 17:06 |
| fungi | yeah, the relationship there is a bit antagonistic at times. when projects first started to decide that they would require in-tree driver vendors to perform testing and report back on proposed changes, the vendors in turn expected those teams to tell them how to do it. and to some extent that expectation got punted to the infra team since we manage the code review system they report into and happen to | 17:06 |
| fungi | run a ci system which is interfacing with it already | 17:06 |
| tbarron | clarkb: but rather because their continued constructive involvement is critical to openstack | 17:06 |
| clarkb | tbarron: sure I just want to be careful the message isn't "you must all convert to zuulv3" | 17:07 |
| clarkb | because running a zuul has never been a requirement | 17:07 |
| smcginnis | Not that "you must convert", but "if you are running your CI this way, please be aware of these changes" I would think. | 17:08 |
| tbarron | clarkb: yup, but using zuul might be the smart thing to do, more like that ... | 17:08 |
| fungi | the first third-party ci system in openstack which reported back on changes was smokestack. it was written entirely independent of any tools we run and merely coded to the interfaces we provide in the code review system | 17:08 |
| tbarron | might be *a* smart thing to do :) | 17:08 |
| fungi | the early expectation was that's what driver vendors would do too | 17:08 |
| smcginnis | fungi: I ran mine as a set of python scripts for years. Worked great. | 17:08 |
| fungi | but when the flood of third-party ci started later, many of them came to openstack asking us to tell them how to build and manage one | 17:10 |
| smcginnis | There still exists a need for *someone* to provide that guidance, but it shouldn't be just dumped on infra. I've tried to encourage third party CI operators to work together to collect recommendations and best practices, but haven't seen that go anywhere. | 17:11 |
| fungi | the infra team mostly pushed back and said "here's documentation for how we run our upstream ci system, you can probably make something work similarly" and from that a number of third-party ci operators wrote blog posts about how they did it which others copied. eventually some of them attempted to curate a set of instructions and, later, some configuration management shims, and got them integrated into | 17:12 |
| fungi | the upstream infra team's configuration management and documentation | 17:12 |
| fungi | but infra's ci system is fast-moving and under heavy development at all times, so expecting them to all adjust their ci systems at the same pace is untenable | 17:13 |
| *** jamesmcarthur_ has joined #openstack-tc | 17:14 | |
| tbarron | and I'm not saying it's *infra's* job to help third-party CI stay current, just noting that we have a challenge | 17:15 |
| tbarron | in the old days vendors were banging on the doors to get in so we could put the onus on them | 17:15 |
| tbarron | even if they then put it on infra as best they could | 17:15 |
| tbarron | now we have a challenge to keep their involvement in CI | 17:16 |
| *** jamesmcarthur has quit IRC | 17:17 | |
| tbarron | I personally work on a 100% open source back end, we work to keep it up-to-date and will convert it to use zuulv3 | 17:20 |
| tbarron | but as manila PTL I want a healthy diversity of back ends running CI | 17:20 |
| tbarron | otherwise the postion of manila (or cinder) as an abstraction layer that effectively virtualizes all these is eroded | 17:21 |
| *** jpich has quit IRC | 17:30 | |
| *** dims has quit IRC | 17:35 | |
| *** dims has joined #openstack-tc | 17:48 | |
| *** mriedem_away is now known as mriedem | 18:50 | |
| *** e0ne has joined #openstack-tc | 18:58 | |
| clarkb | mnaser: gmann looks like the board meeting invitation was sent out | 19:00 |
| gmann | clarkb: yeah, saw the mail. | 19:02 |
| *** lbragstad has quit IRC | 19:39 | |
| *** lbragstad has joined #openstack-tc | 19:41 | |
| *** spsurya has quit IRC | 19:52 | |
| *** e0ne has quit IRC | 19:59 | |
| *** e0ne has joined #openstack-tc | 20:09 | |
| *** e0ne has quit IRC | 20:17 | |
| diablo_rojo | cmurphy, kinda short, but I wrote a forum propsal based on the fc sig meeting last night: https://etherpad.openstack.org/p/FC_SIG_Denver_forum_topics | 20:20 |
| *** jamesmcarthur_ has quit IRC | 20:20 | |
| cdent | diablo_rojo: that reminds me am I on the hook to do anything, yet, with regard to forum selection stuff? | 20:21 |
| diablo_rojo | cdent, not yet :) Once the submissions close, thats when we'll need your input. | 20:22 |
| cmurphy | diablo_rojo: lgtm | 20:22 |
| cdent | roger con aye, ten degrees down bubble | 20:22 |
| diablo_rojo | cdent, I will talk to Jimmy about getting a meeting scheduled sooner rather than later so that we are prepared. | 20:22 |
| cdent | cool, thanks | 20:23 |
| diablo_rojo | cdent, no problem :) | 20:23 |
| *** cdent has quit IRC | 20:24 | |
| *** e0ne has joined #openstack-tc | 20:30 | |
| *** e0ne has quit IRC | 20:33 | |
| *** e0ne has joined #openstack-tc | 20:35 | |
| *** tosky has quit IRC | 20:36 | |
| *** AlanClark has joined #openstack-tc | 20:41 | |
| mnaser | fungi: when i mentioned devstack-gate, i think 'devstack base job' | 20:56 |
| mnaser | i guess i need to upgrade my terminology to say 'the zuulv3 devstack base job' | 20:57 |
| *** jamesmcarthur has joined #openstack-tc | 20:57 | |
| fungi | ahh, easy mistake yes | 20:59 |
| fungi | we said "devstack-gate" for so many years that to some it ceased to be the name of a git repository ;) | 20:59 |
| openstackgerrit | Alex Litvinov proposed openstack/governance master: adding cinder-backup-swift charm and interface https://review.openstack.org/639825 | 21:06 |
| *** jaosorior has quit IRC | 21:08 | |
| openstackgerrit | Alex Litvinov proposed openstack/governance master: adding cinder-backup-swift charm and interface https://review.openstack.org/639836 | 21:23 |
| *** jamesmcarthur has quit IRC | 21:24 | |
| *** jamesmcarthur has joined #openstack-tc | 21:24 | |
| *** e0ne has quit IRC | 21:54 | |
| *** jamesmcarthur has quit IRC | 22:36 | |
| *** jamesmcarthur has joined #openstack-tc | 22:36 | |
| *** AlanClark has quit IRC | 23:04 | |
| *** jamesmcarthur has quit IRC | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!