20:03:22 <ttx> #startmeeting tc
20:03:23 <openstack> Meeting started Tue Nov 15 20:03:22 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:26 <openstack> The meeting name has been set to 'tc'
20:03:38 <ttx> Hi everyone! Sory for lateness
20:03:45 <joehuang> hi
20:03:47 <ttx> Our agenda for today:
20:03:49 <jroll> \o
20:03:50 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:54 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:04:01 <ttx> #topic Add project Tricircle to OpenStack big-tent
20:04:06 <ttx> #link https://review.openstack.org/338796
20:04:14 <ttx> Last week we reviewed this proposal and decided to give it one more week comments
20:04:21 <ttx> Especially to get the Neutron point of view
20:04:36 <joehuang> one second
20:04:47 <joehuang> To the concern on core_plugin which is used for Tricircle Local/Central plugin,
20:04:50 <joehuang> It's ok according to Neutron stadium evolution spec(mechnism driver not enough
20:04:53 <joehuang> for Tricircle need):(https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst)
20:04:54 <stevemar> o/
20:05:03 <thingee> o/
20:05:10 <joehuang> " Although some plugins still use the core plugin interface to provide
20:05:12 <ttx> yes, armax commented on the review, and raised /some/ concerns in terms of integration and collaboration
20:05:13 <joehuang> end-to-end solutions,the criterion to enforce the adoption of ML2 and
20:05:15 <joehuang> service plugins for Neutron Stadium projects does not invalidate, nor
20:05:18 <ttx> I interpreted those concerns as not being showstoppers that should prevent this experimentation to continue, though
20:05:18 <joehuang> does make monolithic solutions deprecated. It is simply a reflection
20:05:20 <joehuang> of the fact that the Neutron team stands behind composability as one
20:05:23 <joehuang> of the promise of open networking solutions. During code review the
20:05:25 <joehuang> Neutron team will continue to ensure that changes and design implications
20:05:28 <joehuang> do not have a negative impact on out of tree code irrespective of whether
20:05:31 <joehuang> it is part of the Stadium project or not. "
20:05:32 <flaper87> ttx: ++ I interpreted those the same way
20:05:47 <ttx> But they definitely point to the need for increased collaboration between Tricircle and Neutron in the future
20:05:52 <joehuang> yes, I just found reference in the neutron stadium spec on how to cooperate
20:05:57 <ttx> My hope is that being in the tent will help that collaboration, so I maintain my +1
20:06:02 <dhellmann> yes, I agree. it's not ideal, but we have had similar situations in the past. IIUC, even some existing official drivers do this.
20:06:58 <dtroyer> joehuang: given the current state of the stadium, getting direct confirmation on those documents from Neutron might be a good idea
20:07:08 <dims> dhellmann ttx : at this time we are expecting a "promise" to cooperate fully with neutron folks and jointly workout disagreements. is it?
20:07:29 <ttx> dims: not really as far as I'm concerned
20:07:44 <ttx> I hope that they will work together rather than in parallel
20:07:52 <dims> right
20:07:55 <flaper87> ++
20:07:55 <dhellmann> I think all teams implicitly make the promise to work together.
20:08:04 <ttx> yes
20:08:04 <dhellmann> Otherwise, what's the point?
20:08:15 <mordred> ++
20:08:16 <joehuang> it's already guide how to deal with  core-plugi in the neutron stadium spec
20:08:28 <dhellmann> flaper87 : maybe that's another principle for the list: "We collaborate"
20:08:28 <joehuang> https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst
20:08:33 <dims> dhellmann ++
20:08:42 <ttx> OK, objections to immediate approval ?
20:08:43 <joehuang> I just copied/paste above
20:08:44 <flaper87> dhellmann: mmh, I thought it was tehre already
20:08:48 <dhellmann> oh, maybe
20:08:51 <flaper87> will check and add it to the to-write list
20:08:53 <dhellmann> ttx: none here
20:08:56 <dims> ttx : let's do it
20:09:02 <ttx> maybe it's within the "one openstack"
20:09:14 <ttx> alright, approved
20:09:20 <ttx> joehuang: welcome!
20:09:25 <joehuang> thank you
20:09:39 <dhellmann> we should make sure it's called out clearly
20:09:42 <joehuang> thank you all
20:09:46 <ttx> dhellmann: ++
20:09:57 <dims> dhellmann : flaper87 : we need one for "Trust", seems many teams struggle with that
20:10:03 <ttx> #agreed would be good to add "We collaborate" to the principles list
20:10:18 <ttx> #topic Revisit list of governed neutron projects
20:10:20 <fungi> yeah, it seems like a good addition
20:10:25 <dhellmann> dims : yes, we may have similar trouble with that like with the good faith item so we'll have to work on wording
20:10:29 <ttx> #link https://review.openstack.org/392010
20:10:32 <stevemar> joehuang: welcome :)
20:10:35 <dims> ack dhellmann
20:10:36 <joehuang> continue to sleep, have a good day, everyone
20:10:41 <dims> congrats joehuang
20:10:46 <ttx> I raised this one at the last meeting, and we discussed it briefly then
20:10:49 <mordred> joehuang: sleep well - and welcome!
20:10:52 <joehuang> thank you, bye
20:10:55 <joehuang> :)
20:10:57 <ttx> The potential issue here is the unofficialization of neutron-vpnaas, which was covered by our standard deprecation policy
20:11:08 <ttx> That policy is pretty clear when it comes to removing features from a service, but here it's a bit more fuzzy
20:11:22 <ttx> because (1) vpnaas inherited the policy from when it was a part of neutron deliverable, and was then split out
20:11:33 <ttx> (2) the feature is not completely removed, just the repo is being made unofficial (but probably left to bitrot)
20:11:43 <ttx> (3) if nobody is working on it anyway, it's not as if the TC mandating anything would help
20:12:00 <ttx> I think at the very least we should raise a thread on the -operators ML to check how many people actually rely on this
20:12:11 <mordred> so - our governance is supposed to be orthogonal to git repository organization (or supposed to help the two not be in lockstep)
20:12:13 <stevemar> maybe armax can answer, but what was the neutron criteria that vpnaas did not meet ?
20:12:14 <ttx> If there is a big crowd maybe some of them will raise to maintain it in a new project team
20:12:29 <mordred> if we had never split it into its own repo and it had just been in the neutron repo with only 2 cores who cared about it
20:12:33 <mordred> and those 2 cores left
20:12:37 <mordred> I don't think this would be a discussion
20:12:50 <dhellmann> mordred : which way do you think that conversation would have gone?
20:12:51 <armax> stevemar: a few
20:12:52 <mordred> it would be a feature in neutorn that needed to go through deprecation
20:13:00 <ttx> mordred: yes
20:13:01 <dhellmann> mordred: yes, ok, I agree
20:13:04 <mordred> and the remaining neutron cores would wince any time a patch came in for it
20:13:05 <fungi> stevemar: there's a spec listed as a dep of the governance change
20:13:05 <armax> stevemar: testing coverage is probably the main one
20:13:25 <dougwig> there have been several ML posts on vpnaas, and yes, they have been inactive for several cycles.
20:13:28 <mordred> I'm not saying that's a no - just pointing out the difference in thinking we'd have if it wasn't in its own git repo
20:13:31 <fungi> #link https://review.openstack.org/383882 "Ocata: Assessment for neutron-vpnaas" change
20:13:33 <armax> stevemar: but ultimately the problem is the team is no longer there to be involved on a daily basis to keep the project afloat
20:13:35 <cdent> mordred: that sounds to me like a vote in favor of repo decomposition
20:13:41 <dhellmann> armax: you mentioned sending signals, what were those?
20:13:42 <cdent> (to reify things)
20:14:06 <mordred> cdent: it's not every day someone uses the word reify ... nicely done
20:14:21 <armax> dhellmann: discussions on the demise of vpnaas have happened at least during the past 3 cycles
20:14:27 <ttx> armax: we could mark it as deprecated and let it bitrot but within neutron team
20:14:40 <ttx> mordred: is that what you have in mind ?
20:14:53 <mordred> it's a theory - I'm more in favor of just pulling the trigger on this one
20:15:03 <mordred> but it's a thing I tihnk we should consider more strongly as we decompose things
20:15:16 <armax> ttx: what does that mean?
20:15:22 <ttx> Personally I think we should check with ops how much they care
20:15:25 <dougwig> i think letting it rot sends a bad message.
20:15:26 <armax> ttx: if it bitrots, who is going to fix it?
20:15:40 <dhellmann> armax : were there the usual deprecation processes? adding release notes, whatever?
20:15:46 <dhellmann> armax : the neutron team owns the code for now. You've committed to a specific deprecation process.
20:15:47 <dtroyer> it sounds as if the deprecation mark been placed here a couple fo cycles ago this would not be an issue at all…   pending giving ops a chance to speak up, I am also ok with just pulling it now
20:15:57 <ttx> dtroyer: right
20:16:07 <stevemar> dtroyer: good point
20:16:07 <dtroyer> dougwig: ++
20:16:11 <dougwig> we warned of this being removed for three summits running.
20:16:15 <mordred> I think the reality is that it's dead - and no matter how we arrived here - it's a dead parrot
20:16:19 <flaper87> dougwig: ++
20:16:19 <thingee> dougwig what about the operators ML ?
20:16:22 <mordred> dougwig: ++
20:16:36 <flaper87> poor parrot :(
20:16:43 <stevemar> dougwig: what mechanism was used to warn? mailing list? summit hallway talk? release notes?
20:16:51 <dhellmann> dougwig : right, the question is just whether that notification has been done in a way that is going to reach everyone that needs to know, or if someone's going to be surprised in february that these things are not in the neutron release.
20:16:54 <dougwig> operators ML got two notices, with only a few replies.
20:17:02 <ttx> dougwig: Ah, that's good
20:17:04 <armax> dhellmann: there were none
20:17:05 <mordred> but - it's potentially a learning case even for adding fringe features to projects that only a few of the cores care about - that we should make sure people think about moving forward
20:17:08 <dougwig> summit fishbowls, dev ML, ops ML.
20:17:10 <ttx> I missed them somehow
20:17:16 <thingee> dougwig thanks. with that I'm fine with pulling the trigger.
20:17:40 <dhellmann> mordred : ++
20:17:44 <dougwig> ttx: hmm, were they not phrased in a way that would make folks take notice? that's a touch disturbing.
20:17:53 <armax> dhellmann: the project code is there, it’s been used but it’s no longer maintained adequately
20:17:54 <fungi> one of the arguments i saw made in an ops ml post earlier in the year is that vpnaas has been "experimental" this entire time, and only got somewhat working as of liberty
20:17:54 <dhellmann> armax : have you done a "last" release?
20:18:09 <armax> dhellmann: yes, newton being the latest
20:18:19 <ttx> dougwig: no, I failed to find them in the ops ml archive -- I don't doubt they were phrased correctly
20:18:27 <fungi> #link http://lists.openstack.org/pipermail/openstack-operators/2016-May/010295.html
20:18:30 <dhellmann> ok, I meant has there been a release that had release notes saying "this is the last release"
20:18:34 <fungi> is one from may
20:18:40 <armax> dhellmann: buy why?
20:18:54 <dhellmann> armax : because not everyone reads email, but the packagers will look at those release notes.
20:18:57 <armax> dhellmann: there’s nothing fundamentally wrong with the project per se
20:19:09 <armax> if not lack of people who maitain and care about it on a continuous basis
20:19:39 <dhellmann> do you think there's someone waiting to pick up the maintenance?
20:19:42 <armax> dhellmann: I can see your point though
20:19:48 <armax> dhellmann: that’s what I was hoping for
20:20:04 <armax> but in lieu of that, if you guys are ok I can make the executive decision to kill the project
20:20:13 <armax> keep it alive for ocata and retire it in pike
20:20:22 <dtroyer> sometimes it takes the actual (removal in this case) to trigger the pick-up
20:20:23 <ttx> OK, so I'd say we have two options here... (1) approve the patch as-is, (2) split the patch and give vpnaas another final round of warning on the Ops ML before removal.
20:20:41 <dhellmann> armax : I don't think you necessarily need to keep it the whole cycle. We could do a final release tomorrow.
20:20:58 <fungi> it's not as if this is killing vpnaas, it's just becoming unofficial because it has no team taking care of it. i don't see a problem with that
20:20:58 <flaper87> I'm ok with #1
20:21:01 <dims> ttx : i am comfortable with (1)
20:21:05 <armax> I honestly don’t believe it’s the right thing to do, but as dtroyer says, it’s possibly the loudest signals of all :)
20:21:23 <mordred> I'm comfortable with either
20:21:36 <dtroyer> fungi: ++   it'll still be there, just not in Ocata release
20:21:39 <dhellmann> fungi : are you suggesting we just make the governance change, and not add a release note that it's likely the final release?
20:21:49 <fungi> also, a follow-on step to retire the repo seems fine. it's very easy to un-retire a repo and even readd it to an official team
20:22:19 <ttx> I'm fine with either as long as there is yet another notification on the -ops list
20:22:25 <dougwig> the biggest thing they lose is co-gates with neutron, which i don't think they have anything.
20:22:39 <fungi> i'm not opposed to having a release that refers to itself as the final release, though i don't think we've done that for other repos in the past (i'm probably wrong about that but it seems uncommon anyway)
20:22:51 <dims> so let's do #1 and request armax to post a notification to ops list
20:23:02 <ttx> maybe "final one by the neutron team"
20:23:05 <ttx> dims: ++
20:23:09 <fungi> and also it would be disingenuous if the repo got resurrected back out of retirement later. how many final releases does a repo get? ;)
20:23:12 <armax> sorry, #1 being?
20:23:20 <mordred> maybe we shold add a debian-like RFA thing ...
20:23:24 <mordred> to our process
20:23:26 <dims> "(1) approve the patch as-is"
20:23:34 <mordred> or ITO - or what is it fungi
20:23:35 <mordred> ?
20:23:46 <ttx> ITP is intent to package
20:23:52 <armax> dims: thanks
20:23:53 <fungi> "o" is what you're thinking of mordred
20:24:02 <fungi> for "orphaned"
20:24:04 <mordred> yah
20:24:08 <ttx> anyway
20:24:16 <armax> I can send an email on the ops list, it’s possible that it was send a similar one in the past, but I can’t recall
20:24:27 <mordred> I was thinking "request for adoption" - for people to signal they're moving on and want to solicit people taking over
20:24:38 <fungi> right
20:24:43 <ttx> armax: that one would be "we just remove neutron-vpnaas from neutron team
20:24:44 <armax> I am sure there are ops affected
20:24:49 <ttx> removed*
20:25:05 <armax> ttx: do you want me to draft it and send it over to you first to check the wording?
20:25:26 <ttx> armax: I'm fine reviewing the wording if you want, but feel free to send it directly too
20:25:31 <armax> ok
20:25:39 <ttx> Objections to immediate approval of the patch ?
20:25:39 <fungi> thinking more about the "final" release idea, that sends a signal that neutron doesn't want anyone to pick it up and continue working on it, so i'm unconvinced it's wise
20:25:48 <armax> fungi: right
20:25:55 <armax> fungi: that’s my sentiment too
20:26:00 <dhellmann> fungi : ok, I see your point and agree on that
20:26:16 <armax> if someone picked it up and put it in the right shape I’d be happy to work with anyone to make that happen
20:26:30 <fungi> this is mor of an orphaning/abandoning situation
20:26:33 <armax> I feel reluctant to kill something that has a perfectly reasonable use case
20:26:38 <ttx> OK, approving now
20:26:42 <flaper87> ttx: go go go go
20:27:00 <ttx> armax: thanks for helping us figure it out
20:27:12 <ttx> #topic Rearrange presentation of Principles
20:27:18 <ttx> #link https://review.openstack.org/394786
20:27:30 <armax> ttx: thank you, I’ll follow up on the MLs
20:27:44 <ttx> clayg proposed a reordering of the principles, johnthetubaguy rebased it
20:27:45 <fungi> looks like clayg wasn't going to be around to discuss this one and has left a -1 on it
20:28:05 <armax> and the rest of the things required to reflect the governance change, like project-config patches etc.
20:28:16 <ttx> ok, let's skip this one
20:28:25 <ttx> looks like we can use another round
20:28:34 <ttx> as he wants a positive ending note
20:28:46 <dhellmann> ++
20:29:18 <ttx> #agreed let's defer to next week since it's not ready yet
20:29:22 <ttx> #topic Make tc managed tag names consistent
20:29:32 <ttx> #link https://review.openstack.org/393185
20:29:43 <flaper87> o/
20:29:44 <ttx> This suggests basically mandating that every tag have a category
20:29:54 <fungi> johnthetubaguy makes a good point about this being incomplete
20:30:03 <ttx> not incomplete, there are extra changes now
20:30:06 <dhellmann> is anyone else having trouble with gerrit?
20:30:07 <fungi> looks like it still needs some tweaking for the starter-kit bit
20:30:10 <fungi> oh?
20:30:16 <ttx> we would keep starterkit:compute as-is
20:30:20 <dims> dhellmann : seems to be working for me
20:30:27 <flaper87> fungi: I did that in preivous patch sets
20:30:33 <dhellmann> dims, thanks
20:30:35 <flaper87> and the feedback was to keep it as-is for now
20:30:46 <ttx> flaper87: but you kept some tc:starterkit-compute changes in
20:31:01 <fungi> flaper87: you have starter-kit:compute renamed to tc:starter-kit-compute in some places there but not others (latest patchset that i see)
20:31:01 <ttx> line 656 for example
20:31:13 <flaper87> oh, crap
20:31:17 <flaper87> missed that one
20:31:23 <dtroyer> 2407
20:31:25 <flaper87> sorry, I can fix quickly
20:31:25 <fungi> it was unclear to me which way you were going with that tag
20:31:37 <ttx> 2911
20:31:46 <ttx> etc... use grep :)
20:31:57 <dtroyer> ya, there are 4 or 5
20:32:01 <ttx> flaper87: we are in a holding pattern, circling around the landing strip
20:32:20 <fungi> i'm fine with the intent, once the implementation is cleaned up
20:32:28 <ttx> yes, me too
20:32:32 <thingee> circle back?
20:32:46 <flaper87> done
20:33:24 <ttx> flaper87: should be starterkit:compute, no ?
20:33:32 <fungi> now some of them are starter-kit-compute rather than
20:33:34 <fungi> yeah
20:34:05 <ttx> :%s/starterkit-/starterkit:/g
20:34:18 <ttx> err :%s/starter-kit-/starter-kit:/g
20:34:38 <thingee> I believe flaper87 uses emacs.
20:34:42 <dims> lol
20:34:48 <ttx> thingee: that would explain
20:34:54 <thingee> ouch
20:34:59 <dims> hahaha
20:35:02 <smcginnis> :D
20:35:03 <dhellmann> sed -i ...
20:35:03 <ttx> he uses tabs, too
20:35:13 <stevemar> :)
20:35:22 <dims> no pressure flaper87
20:35:34 <flaper87> hahahaha
20:35:36 <ttx> none at all
20:36:05 <flaper87> ok, I think it's done
20:36:21 <ttx> looks like a winner
20:36:23 <dtroyer> looks good to my tired eyes
20:36:28 <flaper87> phew
20:36:33 <ttx> Please pile on
20:36:39 <dhellmann> flaper87 : I think you'll get a warning from sphinx because the legacy file isn't in a toctree, but we can fix that separately
20:36:40 <ttx> Will approve once it passes tests
20:36:58 <ttx> dhellmann: I actually like that it's not in the toctree
20:37:12 <flaper87> dhellmann: I kept it out on purpose so it wouldn't be listed in the index
20:37:20 <flaper87> dhellmann: is there a way to silence that warning ?
20:37:24 <ttx> dhellmann: I suspect there is a magic bypass
20:37:34 <stevemar> +1
20:37:39 <dhellmann> ttx: we can put it in so it's hidden and doesn't generate a warning
20:37:46 <ttx> ooooo
20:37:51 <ttx> shiny
20:38:02 <ttx> stevemar: not as shiny as the magic arrow in Gerrit
20:38:06 <ttx> but still shiny
20:38:09 <stevemar> ;)
20:38:14 <ttx> #topic Remove release team tags
20:38:17 <dhellmann> flaper87 : see the "hidden" option in http://www.sphinx-doc.org/en/1.4.8/markup/toctree.html?highlight=toctree
20:38:21 <ttx> #link https://review.openstack.org/396360
20:38:25 <ttx> dhellmann: Want to introduce it, or should I ?
20:38:29 <flaper87> dhellmann: thanks, had no idea
20:38:30 <dhellmann> I can
20:38:33 <flaper87> will propose a follow-up patch
20:38:41 <stevemar> ttx: good enough for a meeting mention but not a like on twitter?!
20:38:46 <dhellmann> this patch is a bit of cleanup for data that is now managed in the openstack/releases repository
20:38:55 <dhellmann> when we started these tags, we thought they would be relatively stable
20:39:03 <dhellmann> over the last 2 releases we've been proven wrong on that
20:39:10 <ttx> stevemar: I'm not a "like" person
20:39:40 <dhellmann> so we need a way to track the values for a given deliverable over time
20:39:42 <dhellmann> the releases repo is organized around release series, and is the primary consumer of the tags, so we thought it would be simplest to just move them there
20:39:59 <ttx> Also those are only used for release management and have little to do with governance
20:40:00 <dhellmann> we've added the data to the existing files in the releases repo already, so this is just removing old data to avoid confusion about which is the source of truth
20:40:11 <dhellmann> yes, that, too
20:40:24 <ttx> they also tend to change over time, while the governance repo only has one branch
20:40:27 <dhellmann> moving the data to the other repo makes it easier for teams to make adjustments
20:40:39 <stevemar> fwiw the release team has been doing a wonderful job, so the more ownership they have over this stuff i'm all for it
20:40:53 <dhellmann> I suspect this patch will need to be rebased after flaper87's lands
20:40:54 <smcginnis> stevemar: +1
20:41:05 <ttx> dhellmann: probably yes + Tricircle too
20:41:15 <fungi> it's definitely a rebase-magnet
20:41:39 <ttx> dhellmann: ideally we would fix-and-land in meeting
20:41:39 <dhellmann> ah, yes, true
20:41:41 <dhellmann> ttx: if we can get approval here, then we can use the house rule to land it tomorrow after I've rebased it
20:41:48 <dhellmann> if the patches are landing we can do that
20:41:56 <ttx> dhellmann: patches are landed already
20:42:05 <stevemar> pressure is on dhellmann now
20:42:12 <dims> go dhellmann !
20:42:37 <ttx> nobody can beat the patchmachine
20:42:51 <ttx> Any objection/comment on this one ?
20:42:59 <ttx> while dhellmann livepatches it ?
20:43:42 <dhellmann> ok, updated
20:43:43 <fungi> *crickets*
20:44:18 <dims> +1
20:45:07 <stevemar> +1
20:45:12 <ttx> my Gerrit UI hangs reviewing
20:45:22 <stevemar> only conflits with 7 patches
20:45:24 <fungi> mine merely queues
20:45:34 <fungi> ;)
20:45:39 <dims> i see 4 +1's
20:45:40 <dhellmann> mine is very slow again, too
20:45:41 <dhellmann> it was doing that on the other patches, too
20:45:54 <dims> dhellmann : weird
20:45:58 <stevemar> fine for me
20:46:12 <dhellmann> I missed tricircle, new version
20:46:40 <stevemar> and he buckles under the pressure!
20:46:42 <fungi> yeah, gerrit doesn't look like it's struggling based on the monitoring we have, so may be something more generally internet-related
20:46:46 <dhellmann> PS6 should be it
20:46:54 <mordred> the internet. we've broken the internet
20:47:06 * mordred hands the internet a nice fluffy bunny rabbit
20:47:07 * dhellmann pulls out the plug and blows on it
20:47:14 <ttx> https://review.openstack.org/gitweb?p=openstack/governance.git;a=commitdiff;h=fb8a0bd4cd26ca11563a1bde533811c1d87cafedif you want to review it off-Gerrit
20:47:14 * mtreinish curses dst
20:47:24 <stevemar> mtreinish: lol
20:47:31 <fungi> i +1'd but i'm not rereviewing that massive change, just taking dhellmann's word for it
20:47:35 <mordred> mtreinish: it's the worst isn't it?
20:47:40 <dims> fungi : y me too
20:47:52 <dhellmann> https://review.openstack.org/#/c/396360/5..6/reference/projects.yaml
20:48:11 <mordred> in case you use google for the calendars - you can set the meeting time to be in Iceland and it's a surrogate for UTC
20:48:13 <mtreinish> so I did have a question for this change, some of the release tags do indicate what a repo is (the plugin tags)
20:48:15 <stevemar> we've got 6
20:48:28 <mtreinish> I'm wondering if that has value independent of the release use case
20:48:39 <ttx> mtreinish: I don't think that's a governance thing
20:48:46 <dhellmann> mtreinish : so far we've only used those (and only a few  of them) to organize releases.openstack.org
20:48:58 <ttx> as far as governance goes, we only care about which repos are attached to which team
20:49:03 <dhellmann> I would prefer to have a short description in text to explain what a deliverable is in governance, if we want that
20:49:22 <mtreinish> dhellmann: sure, but I've had people tell me it's useful for them to have that in the governance list
20:49:35 <mtreinish> dhellmann: a description works, although it isn't easily parsable
20:50:10 <dhellmann> true
20:50:12 <mtreinish> ttx: sure, I get that POV. I'm just saying I know people have found value in having it in the list of repos in projects.yaml
20:50:26 <ttx> mtreinish: I can relate to that, yes
20:50:39 <fungi> mtreinish: i believe there are general use cases for joining datasets between governance and releases, and we talked about maybe a post job to publish a merged dataset
20:50:52 <dhellmann> ah, yes, that
20:51:01 <ttx> yeah, we could redirect people to that
20:51:30 <mtreinish> fungi: is that a thing yet? or something coming soon?
20:51:35 <fungi> i'd rather keep data closest to where it's used, and unduplicated, and then render reference materials that make sense from well-organized data rather than the other way around
20:51:37 <ttx> Should we defer the change ?
20:51:40 <dhellmann> we were going to publish something from openstack/releases in a format that makes it easy to import into the project navigator
20:51:41 <dhellmann> the release team will coordinate with the foundation staff on that
20:52:45 <dhellmann> I'd like to get rid of the duplicated release tag info asap
20:52:53 <ttx> descriptions aren't a bad idea though
20:53:12 <ttx> anyway, let's approve this one while it's current and fix the gap ?
20:53:22 <ttx> shouldn't take long
20:53:22 <fungi> wfm
20:53:29 <dtroyer> ++
20:53:33 <ttx> definitely before Ocata-2
20:53:36 <dims> ++
20:53:44 <ttx> mtreinish: ?
20:53:47 <stevemar> yes plesase
20:54:01 <mtreinish> ttx: wfm
20:54:09 <ttx> alright it is in
20:54:13 <ttx> #topic Open discussion
20:54:19 <ttx> * New neutron subnet pool support breaks multinode testing (https://bugs.launchpad.net/neutron/+bug/1629133)
20:54:19 <openstack> Launchpad bug 1629133 in Magnum "New neutron subnet pool support breaks multinode testing." [Undecided,In progress] - Assigned to Spyros Trigazis (strigazi)
20:54:25 <ttx> mordred: want to talk about that one ?
20:54:33 <ttx> In other news, I could use an extra code review on https://review.openstack.org/#/c/391588/ so that I can approve it under the "code changes" house rule
20:54:51 <ttx> oh, fungi did review it
20:54:56 <ttx> I'll approve now
20:54:57 <fungi> i did indeed
20:55:02 <mordred> yah - this is mostly an fyi for folks - armax and kevinbenton are on top of it for now
20:55:10 <mordred> but it sits in an awkward space in terms of ownership
20:55:52 <mordred> essentially, there is a currently default behavior in devstack when neutron is enabled that does not use the FIXED_RANGE value that the gate feeds into the config ... there are valid semantic reasons for not doing so
20:56:05 <flaper87> w000h000000000  badges o/ \o \o/
20:56:06 <fungi> i'd still like to see a portable registry of network offsets in devstack, but i don't have the bandwidth to write that myself
20:56:08 <jroll> mordred: reading that bug again, I think I can prove that it's still broken, if you would like me to do that thing
20:56:13 * amrith pulls up chair to listen to mordred
20:56:21 <mordred> but ignoring it means that routing on the host gets hosed so subsequnet internet accesses do not work
20:56:26 <fungi> otherwise this is just going to come up again and again in the future
20:56:35 <amrith> that issue is vile; it has trove in pieces on the floor and someone is dancing on it with hobnailed boots.
20:56:37 <mordred> this has wound up breaking several project's gates
20:56:42 <mordred> yah. that
20:57:08 <jroll> ironic has patched over it with configs
20:57:16 <mordred> in any case - kevinbenton has the task and is running with it at the moment - but it's a thing that sits on the intersection of devstack, neutron and devstack-gate - so it's in that lovely cross-project sweet spot that makes things hard
20:57:35 <fungi> right, several projects i believe have workarounds in their jobs to fix ipv4 global network access when running in osic
20:57:37 <mordred> so I though ti was worth making sure everyone was aware of - and that it's important that we all get to an actual solution
20:57:41 <dhellmann> don't we usually revert changes like this to unbreak other projects while a real fix is put into place?
20:57:44 <ttx> yes, we should support him however we can
20:57:46 <amrith> mordred, which review is this?
20:57:49 <dhellmann> ++
20:58:00 <mordred> amrith: don't know if there is a review yet - kevin took the actoin in the neutron meeting yesterday
20:58:14 <ttx> Oh. While reviewing https://review.openstack.org/#/c/365590/ I wondered out loud whether we should have a "we prefer 10 nice people to a 10x rockstar that happens to be abusive" principle ?
20:58:26 <amrith> ok, this is my lame, half-arsed, solution to get things moving for now. https://review.openstack.org/#/c/397368/
20:58:26 <mtreinish> dhellmann: iirc a straight revert would break projects who depended on the feature being enabled
20:58:28 <mordred> there is also a devstack-gate patch up to theoreically work around it ... although that did not work for you right amrith?
20:58:36 <mordred> mtreinish: ++
20:58:40 <mtreinish> dhellmann: but it's been a while since I looked at it
20:58:40 <clarkb> mtreinish: yes that is correct
20:58:46 <amrith> mordred, I didn't do it in devstack gate
20:58:52 <amrith> I did it in the two jobs that I cared about
20:58:53 <clarkb> many projects already depend on subnet pools existing
20:58:54 <amrith> and yes it worked
20:59:06 <amrith> but my 'workaroud' is to go back to nova networking
20:59:10 <amrith> the 'fix' isn't working
20:59:25 <amrith> right now nova appears to puke and says no valid hosts are found when we try to launch a guest db
20:59:26 <mordred> https://review.openstack.org/#/c/379521 is the devstack-gate workaround
20:59:38 <mordred> or, the theoretical workaround
20:59:47 <fungi> right, this was less obvious before the subsequent change went in to make neutron the default in devstack jobs
20:59:50 <amrith> yes, that one didn't work for us. we need more magic layered on top of that if anything.
21:00:10 <jroll> amrith: ironic was able to use USE_SUBNETPOOL=False to get around for now, fwiw, maybe that can help trove out
21:00:18 <ttx> we are running out of time, I propose that people continue that discussion on #openstack-dev
21:00:28 <ttx> since that sounds like a good venue for that
21:00:28 <amrith> jroll, will try that as well
21:00:29 <mtreinish> jroll: I thought trove was the project that required subnet pools
21:00:34 <amrith> thx ttx, wilco
21:00:36 <mtreinish> or was it a different one
21:00:36 <mordred> ttx: yah - thanks - mostly just wanted to make sure everyone knew it was ongoing important work
21:00:40 <amrith> mordred, catch you there or -infra
21:00:43 <amrith> thx jroll
21:00:45 <dims> thanks mordred
21:00:46 <ttx> mordred: thank you for that
21:00:49 <flaper87> thanks mordred
21:00:55 <ttx> #endmeeting