19:05:48 #startmeeting infra 19:05:49 Meeting started Tue May 2 19:05:48 2017 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:05:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:05:52 The meeting name has been set to 'infra' 19:05:56 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:06:01 #topic Announcements 19:06:09 fungi: mordred will arrive in a few mins 19:06:10 #info If you still haven't yet, let fungi know whether you hope to attend the PTG in Denver this September so he can get a rough head count 19:06:16 thanks jeblair! 19:06:22 as always, feel free to hit me up with announcements you want included in future meetings 19:06:35 #topic Actions from last meeting 19:06:42 #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-04-25-19.02.html 19:06:47 fungi put forth proposal to flatten git namespaces 19:06:51 #link https://review.openstack.org/461878 Goodbye Git Namespaces 19:06:56 don't all gasp in surprise at once now 19:07:04 much of it was lifted from the etherpad ttx started 19:07:09 #link https://etherpad.openstack.org/p/repo-name-shortening-impact Impact of shortening repository names 19:07:14 it's sort of a straw man, i have a feeling the eventual list of changes needed to be so daunting/scary as to put us off our lunch anyway 19:07:49 i'm sure there's a ton of stuff i missed under the needed changes, so feel free to comment/update with whatever you think should be there 19:07:59 pabelanger Open an Ubuntu SRU for bug 1251495 19:07:59 bug 1251495 in mailman (Ubuntu Trusty) "Lists with topics enabled can throw unexpected keyword argument 'Delete' exception." [High,Triaged] https://launchpad.net/bugs/1251495 19:08:01 any luck? 19:08:32 yes, I have an ubuntu xenial chroot running locally now. I did bubblewrap this morning, I can switch to mailman now 19:09:04 I'll be in good shape for our next meeting I believe 19:09:32 cool. well the (veritably ancient) action item was about requesting an sru from the package maintainers but i guess we could consider maintaining our own backport ppa of it instead 19:09:58 I think an sru should be put in place regardless? seems like other people using trusty may want working mailman 19:10:26 yes, I plan on pushing up the SRU first depending how slow, we could PPA it also 19:10:30 yeah, it's mostly (if i recall correctly) a matter of fillinh out a text template with the argument for wanting teh fix backported to an lts 19:10:41 s/fillinh/filling/ 19:10:50 * mordred waves 19:10:52 yes, I'm going to show up with backport in hand too 19:11:00 excellent 19:11:00 that should help move along the SRU 19:11:11 #action pabelanger Open an Ubuntu SRU for bug 1251495 19:11:11 bug 1251495 in mailman (Ubuntu Trusty) "Lists with topics enabled can throw unexpected keyword argument 'Delete' exception." [High,Triaged] https://launchpad.net/bugs/1251495 19:11:19 ++ to ppa 19:11:24 clarkb to add citycloud to nodepool 19:11:25 also - sorry I reported that ppas were broken before ... 19:11:46 Still waiting on them to tell us what region(s) to use 19:11:55 also how they want us to ramp up usage. 19:12:07 fungi: do you know if they will be at summit? might be easiest to just have a conversation irl 19:12:21 i don't know, but wouldn't be surprised. i guess we can ask them 19:12:34 #link https://review.openstack.org/458621 Update citycloud to non demo accounts 19:12:36 #link https://review.openstack.org/458622 Add citycloud to nodepool 19:12:39 clarkb: could just pick one and then they might respond. :) 19:12:51 the accounts are configured and the passwords file is updated 19:13:04 jeblair: they wanted to make sure we didn't go crazy and impact their customers so I was trying to avoid that 19:13:24 well, we could pick one and set the quota to 10 and then let them know what we picked 19:13:37 then they can check the impact at their leisure 19:13:39 thats true we could start super small and do our best to avoid issues 19:13:58 ++ 19:14:02 #action clarkb to add citycloud to nodepool 19:14:13 #topic Specs approval 19:14:14 I have a feeling that if we just sit down with them (maybe even over the phone) and have synchronous conversation we could work through ti quickly though 19:14:20 #undo 19:14:21 Removing item from minutes: #topic Specs approval 19:14:42 yeah, probably. maybe their op we've been e-mailing is in irc? 19:15:04 thats a good question. I'll send a followup email and ask about synchronous comms 19:15:12 cool, thanks! anything else? 19:15:27 nope 19:15:31 #topic Specs approval 19:15:34 we don't seem to have anything new up this week 19:15:40 #topic Priority Efforts 19:15:43 nothing called out specifically here 19:15:53 #topic Move dib bugs to storyboard? (mordred) 19:16:00 this was held over from last week 19:16:08 (we ran out of time if memory serves) 19:16:28 ah - yes, this 19:16:44 it was mostly that I noticed that dib was still in launchpad for bugs 19:16:51 their bug tracker is also quite active 19:16:55 I don't have a particular burning need to move/change anything 19:16:59 #link https://bugs.launchpad.net/diskimage-builder 19:17:00 but figured I'd bring it up 19:17:17 64 open currently 19:17:43 yes, occasionally we purge it, hasn't happened for a while 19:18:29 maybe we can start by reaching out to the diskimage-builder-core team and gauging their interest in migrating to sb now 19:19:28 sounds like a good plan to me 19:19:37 SpamapS, devananda, cinerama and greghaynes are in channel, though not sure how many of them are around at the moment 19:19:53 nor how many of them are still active on dib 19:20:23 we could take ianw's temperature on it now at least, i guess ;) 19:20:48 is there an advantage other than being more infraish? 19:21:00 does dib have a lot of cross-project bugs? 19:21:12 tbh i just see it as being a bit confusing for people who use launchpad for other things 19:21:38 right, infra switched to using sb mainly so we could dogfood it (and to try and encourage us to pitch in on making it better) 19:21:50 yes-ish ... bugs mostly come in from people using it in other contexts 19:21:58 bugs from infra usually come in via irc or reviews :) 19:22:36 right, i think that's been a bit of an faq/known issue (sb could stand to have a dedicated interface themed specifically for defect reporting) 19:22:43 ianw: but could that be a symptom of being on storyboard? 19:23:55 ohai 19:24:05 fungi: yes, dib does tend to have a lot of cross project bugs 19:24:11 anyway, i'm content for the dib contributors continue on lp for now if they want, no pressure on my part 19:25:08 and having lots of cross-project bugs shared with, say, tripleo or other teams still using lp is plenty of reason to not move unless/until they also move 19:25:22 that'd be my big concern, we get a lot of bugs from ironic, octavia, etc 19:25:33 agreed 19:25:34 yep, makes sense 19:26:22 anyway, since mordred raised the question, i'll leave it up to him to get wider feedback if he's still interested 19:27:03 mtreinish: you mean that we don't file bugs in infra? i dunno ... I think we just get straight to it and send up reviews generally, i don't recall ever needing much out-of-band discussion/investigation in bugs 19:27:37 ianw: yeah, that's my argument people just assume there isn't a bug tracker because it's on storyboard. So they just push reviews and talk on irc 19:27:43 because they don't have another mechanism 19:27:58 i don't like paperwork, no matter what color the paper is. 19:28:01 not sure i count that as a problem :) 19:28:17 especially if they've been working in the community for long enough from when storyboard didn't support email or paging... 19:28:28 as alan cox said at a LCA many years ago, quickest way to get something fixed is an obviously incorrect patch 19:28:30 we mostly create stories for tracking tasks on our specs, and even that feels a little like something we never got around to leveraging most of the time 19:29:14 (zuulv3 being an obvious counterexample) 19:30:11 anyway, this is drifting off-topic a bit and we have some other topics to cover in the remaining 30 minutes 19:30:58 did anybody else have anything specific to the possibility of dib moving their bugs to storyboard before i move on? 19:31:35 no, i think "sufficiently cross-project to say in lp" is good answer, atm 19:32:03 thanks greghaynes and ianw for weighing in from the diskimage-builder-core seats! 19:32:13 anytime :) 19:32:15 #topic Skip next week's IRC meeting due to Summit? (fungi) 19:32:33 many of us are going to be at the summit/forum next week 19:32:51 I think I may even be leading a forum session during this meetings scheduled runtime 19:32:52 including me 19:33:03 are there enough not attending the summit that someone wants to chair in my absence? 19:33:11 ++. also, i will not be available the tuesday after either. 19:33:40 i get home on the sunday after the summit, but skipping the next two meetings might still be a good idea 19:33:58 not sure how much steam i'll have by tuesday 19:34:09 oh ya I will be in a plane the next tuesday 19:34:13 (tuesday following is my summit return travel day) 19:34:44 no objection for skipping 19:35:07 ++ skip 19:35:13 okay, so seems there's some agreement for skipping the next two (may 9 and 16)? 19:36:08 #info The Infra team will not be holding a weekly IRC meeting for the next two weeks (skipping May 9 and 16) on account of there's a Summit afoot 19:36:45 any objections before i move on? 19:37:44 #topic Import ancient LP archive of general ML (fungi) 19:38:08 #link https://etherpad.openstack.org/p/lists.o.o-openstack-archive-import General "openstack" ML Launchpad Archive Import 19:38:44 after some discussion last week wherein dhellmann was particularly interested in getting his hands on a copy of the ml posts from before we moved it off lp, i drafted the above plan 19:38:55 * dhellmann perks up his ears 19:39:31 i was originally going to propose having a brief mailman outage this week to put it into effect, and coordinating to make sure sufficient people are on hand to test so we know whether it worked or needs a rollback 19:39:53 but i'm not feeling it, what with talk/travel prep going on, and i have a feeling most of the rest of you are pretty distracted too 19:39:58 i've looked that over and it seems reasonable, though i am not so completely versed in the archive scripts to provide an unconditional money-back guarantee. 19:40:23 so maybe i'll round some people up later week after next once we're all rested up a little 19:40:31 thanks for reviewing that, jeblair 19:40:45 fungi: i'd be happy to help during either timeframe 19:40:45 fungi : I can definitely wait 19:41:13 I do intend to start using the data once it's up, but I don't think there's a need to rush 19:41:14 well, i'm flying out in two days and don't feel like doing it _from_ boston if i can help it ;) 19:41:20 ++ 19:41:38 also if anyone else has any input on it, feel free to update the etherpad i linked 19:42:02 I definitely defer mail related things to those that know better 19:42:09 but am happy to help out week after next 19:42:22 cool, seems like we can probably make that happen pretty comfortably 19:42:26 same, happy to help where I can 19:42:33 #link Zuulv3 git repo for opentack-infra jobs (pabelanger) 19:42:44 #undo 19:42:45 Removing item from minutes: #link Zuulv3 19:42:49 wrong tag ;) 19:42:53 #topic Zuulv3 git repo for opentack-infra jobs (pabelanger) 19:42:57 you're up 19:43:14 something something config projects, something something untursted repo 19:43:15 also is the dest path for the zcat correct? its openstack.mbox/openstack.mbox? 19:43:21 So, this came up today in #zuul. I think we might be ready to discuss a new repo we'd use for zuulv3 jobs. 19:43:27 clarkb: yep, strange i know 19:43:28 oh sorry we switched topics, 19:43:45 today, project-config is considered a config-project, but we don't have untrusted-project repo for our jobs yet 19:43:48 mordred, SpamapS: ^ topic-of-interest courtesy ping 19:44:04 maybe something like openstack-zuul-jobs is where out openstack-infra jobs would like, like tox for example 19:44:18 this is outside of the stdlib we are thinking of creating in zuul 19:44:53 and the reason they wouldn't live in project-config is so that changes to them could be self testing? 19:45:00 to (maybe) clarify: a config-project is especially trusted by zuul, and as such, does not recognize dynamic configuration 19:45:06 clarkb: exactly ^ 19:45:09 yes, thanks you 19:45:47 it is also nice to have dynamic configuration, it allows for fast iteration of jobs 19:46:01 what sorts of jobs do you expect would be defined there? our puppet integration testing maybe? 19:46:21 so we're probably going to want to put things like "publish to pypi" in config-projects. we could put as much other stuff as we want there as well, but we may find it more fun to put more job definitions in regular untrusted projects to increase the amount of self-testing available to them. 19:46:27 for example, I would like to move http://git.openstack.org/cgit/openstack-infra/zuul/tree/playbooks/tox?h=feature/zuulv3 into this new repo. These are tox jobs specific to openstack-infra today 19:46:58 and you wouldn't want them in the zuul repo since that's what they're testing? 19:47:03 pabelanger: by specific to 'openstack-infra' you mean 'specific to the zuul instance run by openstack-infra for the openstack project' yeah? 19:47:30 pabelanger: (as opposed to, specific to openstack-infra repos like zuul or nodepool or gear or ...) 19:47:32 yes, we our tox jobs today in feature/zuulv3 still depend on our jenkins slave scripts 19:48:01 right, zuul instance run by openstack-infra 19:48:06 so you're talking about a common repo for the infra team's integration tests for their deliverables 19:48:45 common repo for all our openstack project integration tests 19:48:53 s/integration// ? 19:48:53 obviously (maybe not obviously?) if a job is specific to testing changes for, say, the bindep tool then we'd put the job definitions for that in the bindep repo 19:49:10 jeblair: yes 19:49:14 fungi: that seems obvious to me, yes. 19:49:53 basically this would be a place for py27 job to live as well as pep8/linters etc. They are common across much of what we run but aren't necessarily integration tests either 19:49:58 okay, so the common repo pabelanger is talking about then would be broader than just infra team deliverable integration tests, like say devstack-gate stuff? 19:50:12 and yes eventually devstack-gate I imagine 19:50:16 py27 and linters wouldn't just be in teh stdlib? 19:50:18 fungi: i'd avoid d-g as an example since i think d-g stuff can probably live in d-g. 19:50:39 fungi: no, I think people feel like the way we run tox is too openstacky 19:50:47 okay, fair enough 19:50:50 because we do things to make tox suckless 19:50:55 fungi: maybe? but today they depend on /usr/local/jenkins scripts 19:51:51 right, got it. we don't just run tox 19:51:53 (which assume either nose or testr for example) 19:52:01 my guess as to how that will play out: zuul.stdlib has a tox role and a tox job. but we only use the tox role. we use it inside of a custom openstack tox job which does all the other openstacky stuff. that job will go in the repo pabelanger is proposing. 19:52:30 (that's just one of many possibilities, but it's the assumption i'm currently working from) 19:52:38 (subject to change :) 19:52:54 yeah, i guess run_tox.sh has grown far beyond the handful of lines i remember it being long ago 19:53:17 okay, my confusion is dispelled now 19:53:23 sounds like people are generate okay with the idea then? 19:53:35 generally* 19:53:59 i'm in favor of trying whatever sounds sensible until we collect enough data that convinces us we should do something different 19:54:04 maybe, just maybe, we find that those are all sensible things for all tox users to be doing, and we can just use the zuul.stdlib job. even if that's the case, i'm certain we'll have more 'openstack-wide general job definitions' that should go in that repo. 19:54:18 this seems fine to me 19:55:09 okay, I'll propose a patch for openstack-zuul-jobs then 19:55:16 so openstack-zuul-jobs or openstack-zuul-roles would be our "extended library" of roles other job could build on 19:55:41 yes, that sounds right 19:56:16 I think it could also be a staging area before we moved something into zuul.stdlib too 19:56:21 and act as the catch-all for whenever someone needs some shared mechanism in jobs used by multiple repos and doesn't already have a better place to put it 19:56:21 a note on naming: it's tempting to call these 'zuul-jobs', but since we're in the position of hosting not only our own instance of zuul, but also zuul itself, i think it's better to reserve '^zuul-.*' names for future zuul-related repos (like the stdlib) 19:56:50 openstack-ci-jobs? 19:57:15 * fungi just fell into the bikeshed trap 19:57:24 i meant that in support of 'openstack-zuul-jobs'. but i'm not opposed to openstack-ci-jobs if folks don't like it. 19:57:28 putting the panitbrush down and backing away slowly 19:57:48 not sure i've ever seen fungi holding a paintbrush 19:57:52 * clarkb still thinks all painting can be avoided with uuids 19:57:59 +1 for openstack-zuul-jobs 19:58:00 we'll of course need a uuid tracker wallet thing 19:58:10 jeblair: i just finished removing wallpaper from our master bath. paintbrush is next :/ 19:58:31 clarkb: '/nick 09a34680' is the command you're looking for 19:58:54 jeblair: yes exactly, but need that wallet first 19:59:05 pabelanger: go forth and repo 19:59:11 what nick does fungi have again? 19:59:13 #topic Open discussion 19:59:46 as mentioned earlier, i'll be travelling starting thursday (may 4) for the summit 19:59:55 I'm on a plane early friday 19:59:57 taking a couple days to visit friends so don't expect to be around much 20:00:03 so effectively tomorrow is my last day work working I think 20:00:17 anyway, we're officially holding up the tc meeting now. thanks everyone! 20:00:23 #endmeeting