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