19:03:25 <fungi> #startmeeting infra
19:03:26 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:29 <openstack> The meeting name has been set to 'infra'
19:03:39 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:51 <fungi> #topic Announcements
19:03:54 <fungi> #info Seeking volunteers to help present Infra "On-Boarding" at Forum
19:04:05 <fungi> it looks like we're subdividing a slot with qa, relmgmt, requirements and stable
19:04:12 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114121.html Project On-Boarding Rooms
19:04:28 <fungi> 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 <fungi> #link https://docs.openstack.org/infra/publications/
19:04:47 <fungi> if you're interested in pitching in, get in touch with me
19:05:17 <fungi> #info Submit Forum topics before April 2
19:05:21 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114399.html
19:05:37 <fungi> i think the main benefit we provide to the forum sessions is being there as high-profile users and operators
19:05:43 <fungi> but if you have ideas for topics people should be discussing there please add them before sunday!
19:05:57 <fungi> #info Volunteer needed to chair Infra team meeting on April 11
19:06:00 <clarkb> sorry am here got nerd sniped by pkg_resources
19:06:03 <fungi> 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 <fungi> get up with me if you want to fill in
19:06:28 <fungi> as always, feel free to hit me up with announcements you want included in future meetings
19:06:35 <fungi> #topic Actions from last meeting
19:06:39 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-03-21-19.03.html Minutes from last meeting
19:06:50 <fungi> ianw try booting a Xenial-based replacement for planet.openstack.org
19:06:54 <fungi> did you have a chance to give that a try?
19:07:00 <ianw> yes, a couple of issues
19:07:10 <ianw> #link https://review.openstack.org/450534
19:07:10 <ianw> #link https://review.openstack.org/450526
19:07:10 <ianw> #link https://review.openstack.org/450529
19:07:38 <ianw> xenial hosts require python2 for ansible ... i presume that's not going to be controversial
19:07:50 <ianw> i think a python3 only system is interesting but not a priority
19:08:08 <fungi> yeah, not a problem as far as i'm concerned
19:08:32 <ianw> 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 <mordred> I think mnaser is a wonderful API
19:09:02 <jeblair> that's not that much more difficult than the rax interface, tbh.
19:09:04 <fungi> those changes all look nicely straightforward
19:09:06 <jeblair> possibly better
19:09:11 <ianw> so yes, the host is up and on vexxhost, but not puppeted yet (450534)
19:09:11 <mordred> jeblair: ++
19:09:22 <fungi> mnaser probably has as well-defined a public api ;)
19:09:29 <ianw> yeah, i'll put in something to launch-node because it spews some very wrong info in the dns section
19:09:40 <jeblair> ianw: i bet you didn't even need an mnaser-specific virtualenv.
19:09:44 <fungi> i have no doubt about that
19:10:08 <fungi> thanks for putting that together ianw!
19:10:09 <ianw> so, yeah, in progress, but good to sort out those little xenial issues now
19:10:14 <ianw> <end>
19:10:18 <fungi> #action fungi put forth proposal to flatten git namespaces
19:10:20 <mordred> fungi: the one API call starts with "mnaser:" and everything after that is schemaless
19:10:24 <fungi> i haven't gotten started on that yet, though ttx put this awesome impact study together:
19:10:42 <fungi> #link https://etherpad.openstack.org/p/repo-name-shortening-impact Impact of shortening repository names
19:10:44 <fungi> if anybody thinks of anything which should also be on there, please add it!
19:11:01 <fungi> mordred: sounds a lot like glance tasks? ;)
19:11:20 * fungi shouldn't poke fun
19:11:50 <fungi> #topic Specs approval
19:12:05 <fungi> we don't seem to have anything new up this week
19:12:10 <fungi> #topic Priority Efforts
19:12:25 <fungi> 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 <fungi> #link http://eavesdrop.openstack.org/#Zuul_Meeting A weekly meeting to discuss Zuul development
19:12:29 <mordred> fungi: :)
19:13:16 <fungi> #topic Planning to upgrade lists.openstack.org to Ubuntu 14.04 LTS (fungi, jeblair)
19:13:22 <fungi> #link https://etherpad.openstack.org/p/lists.o.o-trusty-upgrade Trusty upgrade steps for lists.openstack.org
19:13:35 <fungi> jeblair ran through this last week and wrote up a very detailed maintenance plan there
19:13:58 <jeblair> i think it's basically repeatable but we'll want to remove the old kernels beforehand to save time
19:14:03 <fungi> i think you estimated a 90-minute outage we should announce as 3 hours?
19:14:20 <jeblair> yeah, i'm comfortable with that
19:14:22 <fungi> "messages bound for the list will queue..."
19:14:29 <fungi> et cetera
19:14:43 <fungi> you suggested we pick a friday soon
19:14:59 <fungi> does anyone think this friday is "too soon"?
19:15:02 <jeblair> 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 <jeblair> s/bonkers/non-rfc-compliant/
19:15:30 <pabelanger> friday seems fine
19:15:36 <jeblair> works for me.
19:16:18 <clarkb> also works for me
19:16:31 <fungi> 20:00 start?
19:16:45 <jeblair> 2000 also works for me
19:17:01 <clarkb> I'm fine with earlier if it helps people in more eastern timezones
19:17:02 <mordred> wfm
19:17:13 <fungi> that gets you after west coast lunch and i don't mind eating my dinner a couple hours early
19:18:13 <pabelanger> same
19:18:26 <fungi> #info The Mailman listserv on lists.openstack.org will be offline for an upgrade
19:18:37 <fungi> er, i have a stray newline on that
19:18:41 <fungi> #undo
19:18:42 <openstack> Removing item from minutes: #info The Mailman listserv on lists.openstack.org will be offline for an upgrade
19:19:03 <fungi> #info The Mailman listserv on lists.openstack.org will be offline for an upgrade
19:19:10 <fungi> gah
19:19:12 <fungi> #undo
19:19:13 <openstack> Removing item from minutes: #info The Mailman listserv on lists.openstack.org will be offline for an upgrade
19:20:20 <fungi> #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 <fungi> there we go. anybody disagree with that?
19:20:41 <jeblair> fungi: ^5
19:21:00 <fungi> i can get an announcement worked up later today for that unless someone else wants to
19:21:13 <fungi> probably should go to the openstack-announce ml i guess?
19:21:30 <clarkb> and maybe even -ops and general?
19:21:37 <fungi> seems questionable to send it to every ml we host
19:21:49 <clarkb> don't want to overspam but those likely represent a large subset of users
19:22:06 <fungi> i mean, -dev is by far the highest volume of list traffic
19:22:47 <fungi> 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 <jeblair> i'm not sure we should include -announce?
19:24:16 <fungi> 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 <fungi> i was trying to figure out the best place to announce it without announcing to multiple lists
19:24:38 <jeblair> that's my thinking.  also, likely least interested.
19:24:48 <jeblair> (different story if there were an impacting change)
19:24:58 <fungi> but maybe i just accept the evils of cross-posting in this case
19:25:08 <clarkb> I think -dev -ops and general represents the largest cross section. However sending to those 3 is not one :)
19:25:17 <fungi> so -dev, -ops and the general list. anything else?
19:25:22 <jeblair> -infra
19:25:33 <jeblair> people who care about the availability of infrastructure systems maybe ought to subscribe to -infra :)
19:25:44 <fungi> yeah, that's a great point
19:26:02 <fungi> okay, i'll send the announcement to those four
19:26:14 <fungi> anything else we need to discuss on this topic?
19:26:31 <jeblair> nak
19:26:49 <fungi> 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 <fungi> #topic Shade proposal for a new TC-recognized project team (fungi, mordred)
19:28:12 <fungi> #link https://review.openstack.org/446426 Move shade into its own top-level team
19:28:31 <fungi> putting this on the agenda since it's also on the tc agenda immediately after this
19:29:14 <fungi> 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 <mordred> and I was afk for the surprise
19:29:47 <fungi> mainly curious if there are objections so i can weigh those
19:30:11 <fungi> and yeah, mordred was absent last week so nobody had a chance to tell him he's crazy
19:30:20 <mordred> I mean, like I don't already know taht
19:30:26 * ttx waves from Berlin
19:30:30 <jeblair> 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 <jeblair> i think that based on the expanding use of shade, in some cases it's becoming a "face" of openstack
19:31:22 <jeblair> and that seems very appropriate to be an official openstack project
19:31:45 <fungi> 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 <jeblair> it's certainly evolved beyond "utility library for nodepool" :)
19:31:55 <clarkb> 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 <clarkb> 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 <mordred> clarkb: I do think it is something we shoud look more broadly
19:33:02 <clarkb> this will be an issue for dib too with the proposed move into infra btw
19:33:06 <clarkb> so its not a one off thing we are running into
19:33:08 <mordred> there are definitely some very strange perceiption issues floating around out there
19:33:23 <greghaynes> heh, I was just noticing how interesting the timing is there
19:33:33 <fungi> i wouldn't expect the actual set of developers on shade or requestsexceptions to actually change as a result of this
19:33:34 <mordred> and figuring out how to address them over time would be beneficial
19:33:41 <mordred> fungi: me neither
19:34:00 <jeblair> 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 <fungi> 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 <clarkb> 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 <jeblair> 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 <clarkb> but thats more something to be aware of and not a deal breaker either
19:35:24 <fungi> the github pr in question did include an agreement to the dco, which the board has agreed we can switch to
19:35:31 <mordred> 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 <fungi> we just haven't had the cycles to finish things that need doing to be able to make that transition
19:35:58 <mordred> fungi: ++
19:36:00 <fungi> on a mass scale i mean
19:36:25 <fungi> 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 <mordred> 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 <clarkb> signed off by doesn't ahve any real weight in our setup does it?
19:37:34 <clarkb> because we don't assert the dco anywhere
19:37:36 <jeblair> 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 <mordred> not at the moment
19:37:41 <clarkb> (it doesn't hurt either but doesn't mean anything)
19:37:46 <mordred> jeblair: ++
19:38:13 <fungi> clarkb: it had weight for that commit, but it doesn't have weight in gerrit insofar as being enforced (yet)
19:38:14 <jeblair> clarkb: https://docs.openstack.org/infra/manual/developers.html#using-signed-off-by
19:38:29 <jeblair> (but the repos should really have that in a file too)
19:38:37 <fungi> and yeah, we have russellb's excellent writeup there in the infra manual
19:38:42 <clarkb> oh neat didn't realize that was there
19:39:24 <russellb> i do it for most of my patches now, habit
19:39:37 <russellb> since it's required for some other projects i'm contributing to
19:40:26 <clarkb> 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 <clarkb> we may need to reconcile that
19:41:31 <jeblair> 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 <clarkb> (I'm happy for both moves to happen as proposed just we may need to clean up the messaging)
19:41:42 <jeblair> me too
19:41:57 <fungi> 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 <fungi> the openstack-infra git namespace
19:42:03 <jeblair> 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 <jeblair> fungi: i catagorically deny #1
19:42:34 <jeblair> if someone has said that, we need to talk about it
19:42:49 <clarkb> jeblair: thats how I read the shade move commit message
19:42:55 <jeblair> (i mean, that's ridiculous -- openstack depends on all sorts of things that aren't written by openstack)
19:43:09 <clarkb> yes exactly :)
19:43:21 <jeblair> clarkb: what sentence says that so we can remove it? :)
19:43:35 <fungi> i can sort of see it between the lines there if i squint
19:43:38 <mordred> 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 <clarkb> the middle of the first paragraph
19:44:08 <jeblair> "to use adjacent to or as a part of OpenStack things" i guess?
19:44:14 <clarkb> "people view it as 'separate' so maybe not appropriate for use adjavent to or as openstack things"
19:44:16 <clarkb> jeblair: yes
19:44:52 <greghaynes> I'd be interested to know - has that happened already or is there just a fear of that potentially happening?
19:45:12 <greghaynes> (people seeing it as not appropriate for use with openstack)
19:45:59 <greghaynes> Since the big question seems to be whether that would also likely happen to dib
19:46:14 <fungi> 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 <mordred> 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 <fungi> #link https://governance.openstack.org/tc/reference/licensing.html
19:47:13 <jeblair> 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 <mordred> c) is being handled by fixing code, but we've still had a couple of years of habit for folks
19:47:48 <fungi> 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 <clarkb> 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 <clarkb> because to me those two things are orthogonal and unrelated
19:48:22 <jeblair> 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 <jeblair> clarkb and i say similar things i think
19:48:59 <clarkb> jeblair: ya
19:49:01 <mordred> 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 <fungi> i agree, the release management argument is far stronger than the licensing exceptions one
19:49:37 <jeblair> fungi: what's the release management argument?
19:49:54 <fungi> "separately managed versions of common deps"
19:49:57 <jeblair> gotcha
19:50:02 <jeblair> fungi: agreed
19:50:29 <fungi> aka requirements tracking, stable branches, following the same release process as other openstack-the-product pieces
19:50:57 <mordred> 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 <fungi> 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 <fungi> i want to get to the dib topic too, since it's also up for tc vote today
19:52:40 <mordred> fungi: ++
19:52:43 <clarkb> 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 <fungi> cool, that makes a great segue
19:53:26 <fungi> #topic Diskimage Builder proposal to join Infra (fungi, greghaynes)
19:53:30 <fungi> #link https://review.openstack.org/445617 Move DIB from TripleO to Infra
19:54:02 <fungi> 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 <fungi> 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 <EmilienM> o/
19:55:24 <greghaynes> Yep, I've also made #link https://etherpad.openstack.org/p/dib-infra-move-deets to gather some finer grained details
19:55:40 <fungi> 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 <EmilienM> (in same position as fungi fwiw)
19:56:35 <ianw> personally i see that as a lot of overhead with no benefits i can see
19:56:38 <greghaynes> Right, I've been trying to find anyone who might have a strong desire for that and was unable to
19:56:54 <greghaynes> For the same reasons as ianw says
19:56:54 <fungi> 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 <fungi> 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 <fungi> and seems like i'm hearing none. we can move to open discussion for the last couple minutes
19:58:24 <ianw> just join #openstack-dib as sometimes things come up in there
19:58:25 <EmilienM> (indeed, we're going to vote it during the TC meeting)
19:58:34 <fungi> #topic Open discussion
19:59:10 <clarkb> as a heads up I think I got one of our barcelona demo clouds to donate resources
19:59:26 <fungi> YES!
19:59:29 <clarkb> 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 <pabelanger> I'm looking for help with directory hashing for rubygems-mirror. I might be pinging some people
19:59:42 <cmurphy> 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 <clarkb> cmurphy: maybe we can take that over to -infra as we are running out of time?
20:00:06 <EmilienM> I'm still waiting for feedback on infracloud/ocata patch https://review.openstack.org/#/c/436503/
20:00:11 <cmurphy> clarkb: sure
20:00:20 <fungi> okay, thanks everyone--time for teh tc meeting
20:00:25 <fungi> #endmeeting