19:03:25 #startmeeting infra 19:03:26 Meeting started Tue Mar 28 19:03:25 2017 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:29 The meeting name has been set to 'infra' 19:03:39 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:51 #topic Announcements 19:03:54 #info Seeking volunteers to help present Infra "On-Boarding" at Forum 19:04:05 it looks like we're subdividing a slot with qa, relmgmt, requirements and stable 19:04:12 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114121.html Project On-Boarding Rooms 19:04:28 we could probably just brush up one of our overview presentations and run through that, then do question and answer for a few minutes after 19:04:34 #link https://docs.openstack.org/infra/publications/ 19:04:47 if you're interested in pitching in, get in touch with me 19:05:17 #info Submit Forum topics before April 2 19:05:21 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114399.html 19:05:37 i think the main benefit we provide to the forum sessions is being there as high-profile users and operators 19:05:43 but if you have ideas for topics people should be discussing there please add them before sunday! 19:05:57 #info Volunteer needed to chair Infra team meeting on April 11 19:06:00 sorry am here got nerd sniped by pkg_resources 19:06:03 i'll be at a leadership seminar with some other members of the community most of that week, and so unavailable to chair our meeting 19:06:08 get up with me if you want to fill in 19:06:28 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:39 #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-03-21-19.03.html Minutes from last meeting 19:06:50 ianw try booting a Xenial-based replacement for planet.openstack.org 19:06:54 did you have a chance to give that a try? 19:07:00 yes, a couple of issues 19:07:10 #link https://review.openstack.org/450534 19:07:10 #link https://review.openstack.org/450526 19:07:10 #link https://review.openstack.org/450529 19:07:38 xenial hosts require python2 for ansible ... i presume that's not going to be controversial 19:07:50 i think a python3 only system is interesting but not a priority 19:08:08 yeah, not a problem as far as i'm concerned 19:08:32 the other is just a fyi that for vexxhost, just ping mnaser for rdns as there's no interface for that yet 19:09:00 I think mnaser is a wonderful API 19:09:02 that's not that much more difficult than the rax interface, tbh. 19:09:04 those changes all look nicely straightforward 19:09:06 possibly better 19:09:11 so yes, the host is up and on vexxhost, but not puppeted yet (450534) 19:09:11 jeblair: ++ 19:09:22 mnaser probably has as well-defined a public api ;) 19:09:29 yeah, i'll put in something to launch-node because it spews some very wrong info in the dns section 19:09:40 ianw: i bet you didn't even need an mnaser-specific virtualenv. 19:09:44 i have no doubt about that 19:10:08 thanks for putting that together ianw! 19:10:09 so, yeah, in progress, but good to sort out those little xenial issues now 19:10:14 19:10:18 #action fungi put forth proposal to flatten git namespaces 19:10:20 fungi: the one API call starts with "mnaser:" and everything after that is schemaless 19:10:24 i haven't gotten started on that yet, though ttx put this awesome impact study together: 19:10:42 #link https://etherpad.openstack.org/p/repo-name-shortening-impact Impact of shortening repository names 19:10:44 if anybody thinks of anything which should also be on there, please add it! 19:11:01 mordred: sounds a lot like glance tasks? ;) 19:11:20 * fungi shouldn't poke fun 19:11:50 #topic Specs approval 19:12:05 we don't seem to have anything new up this week 19:12:10 #topic Priority Efforts 19:12:25 nothing called out specifically here for this week, though for the zuulv3 topic i encourage people to attend the zuul-specific meeting on mondays: 19:12:29 #link http://eavesdrop.openstack.org/#Zuul_Meeting A weekly meeting to discuss Zuul development 19:12:29 fungi: :) 19:13:16 #topic Planning to upgrade lists.openstack.org to Ubuntu 14.04 LTS (fungi, jeblair) 19:13:22 #link https://etherpad.openstack.org/p/lists.o.o-trusty-upgrade Trusty upgrade steps for lists.openstack.org 19:13:35 jeblair ran through this last week and wrote up a very detailed maintenance plan there 19:13:58 i think it's basically repeatable but we'll want to remove the old kernels beforehand to save time 19:14:03 i think you estimated a 90-minute outage we should announce as 3 hours? 19:14:20 yeah, i'm comfortable with that 19:14:22 "messages bound for the list will queue..." 19:14:29 et cetera 19:14:43 you suggested we pick a friday soon 19:14:59 does anyone think this friday is "too soon"? 19:15:02 it may be slightly more impactful than the 10-hour mailman outage previously, but only to people with bonkers MTAs which don't retry. 19:15:27 s/bonkers/non-rfc-compliant/ 19:15:30 friday seems fine 19:15:36 works for me. 19:16:18 also works for me 19:16:31 20:00 start? 19:16:45 2000 also works for me 19:17:01 I'm fine with earlier if it helps people in more eastern timezones 19:17:02 wfm 19:17:13 that gets you after west coast lunch and i don't mind eating my dinner a couple hours early 19:18:13 same 19:18:26 #info The Mailman listserv on lists.openstack.org will be offline for an upgrade 19:18:37 er, i have a stray newline on that 19:18:41 #undo 19:18:42 Removing item from minutes: #info The Mailman listserv on lists.openstack.org will be offline for an upgrade 19:19:03 #info The Mailman listserv on lists.openstack.org will be offline for an upgrade 19:19:10 gah 19:19:12 #undo 19:19:13 Removing item from minutes: #info The Mailman listserv on lists.openstack.org will be offline for an upgrade 19:20:20 #info The Mailman listserv on lists.openstack.org will be offline for an upgrade maintenance 20:00-23:00 UTC Friday, March 31; most messages bound for the lists there should queue and retry, so impact is likely minimal 19:20:33 there we go. anybody disagree with that? 19:20:41 fungi: ^5 19:21:00 i can get an announcement worked up later today for that unless someone else wants to 19:21:13 probably should go to the openstack-announce ml i guess? 19:21:30 and maybe even -ops and general? 19:21:37 seems questionable to send it to every ml we host 19:21:49 don't want to overspam but those likely represent a large subset of users 19:22:06 i mean, -dev is by far the highest volume of list traffic 19:22:47 so i guess if we're going to cross-post to multiple lists we should include that one? 19:23:20 * fungi worries he's taken a detour into the bikeshed 19:23:20 i'm not sure we should include -announce? 19:24:16 yeah, i guess the -announce ml, by nature of being almost exclusively a read-only ml, has subscribers who are least impacted 19:24:37 i was trying to figure out the best place to announce it without announcing to multiple lists 19:24:38 that's my thinking. also, likely least interested. 19:24:48 (different story if there were an impacting change) 19:24:58 but maybe i just accept the evils of cross-posting in this case 19:25:08 I think -dev -ops and general represents the largest cross section. However sending to those 3 is not one :) 19:25:17 so -dev, -ops and the general list. anything else? 19:25:22 -infra 19:25:33 people who care about the availability of infrastructure systems maybe ought to subscribe to -infra :) 19:25:44 yeah, that's a great point 19:26:02 okay, i'll send the announcement to those four 19:26:14 anything else we need to discuss on this topic? 19:26:31 nak 19:26:49 it's an in-place upgrade, which is out of the ordinary for us, so everyone keep that in mind i guess 19:28:07 #topic Shade proposal for a new TC-recognized project team (fungi, mordred) 19:28:12 #link https://review.openstack.org/446426 Move shade into its own top-level team 19:28:31 putting this on the agenda since it's also on the tc agenda immediately after this 19:29:14 and since my mention of it in last week's meeting seemed to take some people by surprise i wanted to make sure it's communicated so i can get at least some last minute feedback before i vote on it 19:29:44 and I was afk for the surprise 19:29:47 mainly curious if there are objections so i can weigh those 19:30:11 and yeah, mordred was absent last week so nobody had a chance to tell him he's crazy 19:30:20 I mean, like I don't already know taht 19:30:26 * ttx waves from Berlin 19:30:30 i think the current commit message lays out a reasonable case. 19:30:52 * mordred has updated the commit message since last week - so it might be better/clearer than it was then 19:31:05 i think that based on the expanding use of shade, in some cases it's becoming a "face" of openstack 19:31:22 and that seems very appropriate to be an official openstack project 19:31:45 it's also going to be integral to oaktree, and i expect we don't want to be in the business of maintaining an openstack api service 19:31:50 it's certainly evolved beyond "utility library for nodepool" :) 19:31:55 I am really concerned that people think using software that is appropriately licensed and supported by its developers is not appropriate for usage in openstack 19:32:23 I don't think thats shade's fault nor do I think shade can fix it, so not something to block this. But why does that perception exist and is it something we need to look at more broadly? 19:32:53 clarkb: I do think it is something we shoud look more broadly 19:33:02 this will be an issue for dib too with the proposed move into infra btw 19:33:06 so its not a one off thing we are running into 19:33:08 there are definitely some very strange perceiption issues floating around out there 19:33:23 heh, I was just noticing how interesting the timing is there 19:33:33 i wouldn't expect the actual set of developers on shade or requestsexceptions to actually change as a result of this 19:33:34 and figuring out how to address them over time would be beneficial 19:33:41 fungi: me neither 19:34:00 clarkb: i agree with that concern. and it's interesting that whatever might underly that concern, this does nothing to address that. (as expected -- how could it) 19:34:36 this is more of a means of calling them out as not infra-specific projects (as a class our repos get more latitude to use other licenses, in particular) 19:34:43 the only other thing that came up recently was a pull request was proposed to github which mordred/thingee then pushed up to shade. I think moving into openstack and applying the CLA potentially complicates that in the future 19:34:45 that's part of why i'm happier with this version of the commit message which takes a more positive tone and leaves out most of the vague (and unactionable) "there are problems" bits. 19:35:18 but thats more something to be aware of and not a deal breaker either 19:35:24 the github pr in question did include an agreement to the dco, which the board has agreed we can switch to 19:35:31 clarkb: yup. I agree with that - although for clarity for folks who might not have seen it, the PR in question was a one-word fix 19:35:44 we just haven't had the cycles to finish things that need doing to be able to make that transition 19:35:58 fungi: ++ 19:36:00 on a mass scale i mean 19:36:25 by "we" i mean openstack as a whole (not just infra) 19:36:32 * mordred really should start signed-off-by his patches ... 19:36:55 although all of my patches are gpg signed, so one would hope that implies to people that they are signed-off by him too 19:37:29 signed off by doesn't ahve any real weight in our setup does it? 19:37:34 because we don't assert the dco anywhere 19:37:36 so yeah, in short, i think there is no legit organizational issue that should prompt this, and if folks think there are, we should talk about it. but regardless of that, i think it makes good sense for the openstack project. 19:37:37 not at the moment 19:37:41 (it doesn't hurt either but doesn't mean anything) 19:37:46 jeblair: ++ 19:38:13 clarkb: it had weight for that commit, but it doesn't have weight in gerrit insofar as being enforced (yet) 19:38:14 clarkb: https://docs.openstack.org/infra/manual/developers.html#using-signed-off-by 19:38:29 (but the repos should really have that in a file too) 19:38:37 and yeah, we have russellb's excellent writeup there in the infra manual 19:38:42 oh neat didn't realize that was there 19:39:24 i do it for most of my patches now, habit 19:39:37 since it's required for some other projects i'm contributing to 19:40:26 the only other thing I will say is that I think a lot of what is being said around this shade move is potentially at odds with what is said with the dib move 19:41:00 we may need to reconcile that 19:41:31 clarkb, mordred: yes, if there are folks that only want to package "openstack" projects, then are they going to come back with "issues" regarding dib? 19:41:34 (I'm happy for both moves to happen as proposed just we may need to clean up the messaging) 19:41:42 me too 19:41:57 so anyway, this has a few rough edges... 1. it sets a precedent that if an openstack service wants to depend on an infra deliverable, we have to evict it; 2. tripleo depends on diskimage-builder, which we're about to talk about moving into infra; 3. shade and requestsexceptions may need to get git namespaces changed because this apparently might confuse some people when they're non-infra repos in 19:41:59 the openstack-infra git namespace 19:42:03 since i'm not focused on that -- i think from the pov of who uses/maintains them, they both make a lot of sense. 19:42:25 fungi: i catagorically deny #1 19:42:34 if someone has said that, we need to talk about it 19:42:49 jeblair: thats how I read the shade move commit message 19:42:55 (i mean, that's ridiculous -- openstack depends on all sorts of things that aren't written by openstack) 19:43:09 yes exactly :) 19:43:21 clarkb: what sentence says that so we can remove it? :) 19:43:35 i can sort of see it between the lines there if i squint 19:43:38 yah - and I'm not thrilled with the concept of 3 - and would rather defer doing such a thing until such a time as we decide to flatten or remove namespaces 19:43:43 the middle of the first paragraph 19:44:08 "to use adjacent to or as a part of OpenStack things" i guess? 19:44:14 "people view it as 'separate' so maybe not appropriate for use adjavent to or as openstack things" 19:44:16 jeblair: yes 19:44:52 I'd be interested to know - has that happened already or is there just a fear of that potentially happening? 19:45:12 (people seeing it as not appropriate for use with openstack) 19:45:59 Since the big question seems to be whether that would also likely happen to dib 19:46:14 i suspect a lot of the licensing concern could be fixed by being less team-specific in the governance documentation about licensing exceptions 19:46:42 I _think_ it may have something to do with the fact that shade is a) a library and b) interacts specifically with the openstack apis and at least for now also c) depends on python libraries that openstack depends on at different versions 19:46:50 #link https://governance.openstack.org/tc/reference/licensing.html 19:47:13 i will once again mention that non-openstack projects don't have to adhere to our licensing requests -- in all cases, we have to look at the actual license used by a piece of software before we incorporate it. 19:47:18 c) is being handled by fixing code, but we've still had a couple of years of habit for folks 19:47:48 the spirit there seems to be that the community is allowed to use other free licenses for things which aren't runtime dependencies of "openstack the product" (however you define it), particularly software used for testing and development 19:48:05 mordred: maybe rewrite the commit to specifically talk about how separately managed versions of common deps have created conflict and remove the talk about separate governance? 19:48:13 because to me those two things are orthogonal and unrelated 19:48:22 mordred: yeah, if that's the case, that's an entirely reasonable technical objection for folks to have, and a good technical solution is being implemented (and has no relationship with the openstack project team doing the work) 19:48:53 clarkb and i say similar things i think 19:48:59 jeblair: ya 19:49:01 yup. I agree re: c - however, a and b are the things that are still true and where I'm guessing people are getting themselves flummoxed 19:49:06 i agree, the release management argument is far stronger than the licensing exceptions one 19:49:37 fungi: what's the release management argument? 19:49:54 "separately managed versions of common deps" 19:49:57 gotcha 19:50:02 fungi: agreed 19:50:29 aka requirements tracking, stable branches, following the same release process as other openstack-the-product pieces 19:50:57 yah - as a thing that is related to openstack apis it's not currently participating in OpenStack Release Management like the other things are 19:51:55 okay, so seems like we're more or less in agreement that the spirit of the proposal makes sense, but the commit message might still be reinforcing misconceptions? 19:52:21 i want to get to the dib topic too, since it's also up for tc vote today 19:52:40 fungi: ++ 19:52:43 yes for the sake of the dib move I think we awnt to avoid any of those misconceptions, particukarly if we move them at the same time 19:53:15 cool, that makes a great segue 19:53:26 #topic Diskimage Builder proposal to join Infra (fungi, greghaynes) 19:53:30 #link https://review.openstack.org/445617 Move DIB from TripleO to Infra 19:54:02 this one should be much less of a surprise. greghaynes has communicated it widely first in a lengthy discussion on the -dev ml and then later in the -infr aml 19:54:50 so far the only concern i've seen raised is that if the misconception about infra deliverables being unsuitable as openstack dependencies persists then we've got an issue 19:54:52 o/ 19:55:24 Yep, I've also made #link https://etherpad.openstack.org/p/dib-infra-move-deets to gather some finer grained details 19:55:40 i also just want to make absolutely 100% sure that the current dib devs are entirely disinterested in having their own separate project team. as a tc member i'd also happily support that move 19:55:57 (in same position as fungi fwiw) 19:56:35 personally i see that as a lot of overhead with no benefits i can see 19:56:38 Right, I've been trying to find anyone who might have a strong desire for that and was unable to 19:56:54 For the same reasons as ianw says 19:56:54 but i certainly agree that the work on dib is pretty closely aligned with other things in infra and we have a fair amount of overlap on contributors, so i don't object to the current proposal and i haven't heard anyone else object 19:57:49 i mainly wanted to give an opportunity for last-minute objections from the infra team 19:58:20 * mordred welcomes our existing dib friends in remaining our dib friends 19:58:24 and seems like i'm hearing none. we can move to open discussion for the last couple minutes 19:58:24 just join #openstack-dib as sometimes things come up in there 19:58:25 (indeed, we're going to vote it during the TC meeting) 19:58:34 #topic Open discussion 19:59:10 as a heads up I think I got one of our barcelona demo clouds to donate resources 19:59:26 YES! 19:59:29 once people get back from vacation we should be able to make that concrete with proper accounts and everything (late this week, early next) 19:59:42 I'm looking for help with directory hashing for rubygems-mirror. I might be pinging some people 19:59:42 I pushed up https://review.openstack.org/#/c/450029/ to stop installing root users on nodepool nodes and so far ianw has raised hesitation, does anyone else want to discuss it? 20:00:01 cmurphy: maybe we can take that over to -infra as we are running out of time? 20:00:06 I'm still waiting for feedback on infracloud/ocata patch https://review.openstack.org/#/c/436503/ 20:00:11 clarkb: sure 20:00:20 okay, thanks everyone--time for teh tc meeting 20:00:25 #endmeeting