21:05:02 <kevinbenton> #startmeeting networking 21:05:03 <openstack> Meeting started Mon Aug 31 21:05:02 2015 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:05:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:05:07 <openstack> The meeting name has been set to 'networking' 21:05:12 <armax> thre you go! 21:05:13 <armax> go kevinbenton 21:05:16 <regXboi> and now it is all on record 21:05:17 * pcm_ kevin beat me to it. 21:05:20 <blogan> kevinbenton the powerful 21:05:26 <Sukhdev> way to go kevinbenton 21:05:30 <kevinbenton> #topic open discussion 21:05:36 <blogan> lol 21:05:38 <salv-orlando> HRM kevinbenton 21:05:40 <kevinbenton> ok, amuller go 21:05:44 <regXboi> oh come oh 21:05:45 <armax> the gate is screwed 21:05:50 <emagana> I like it.. just to the end of the agenda 21:05:51 <amuller> As everyone probably know, Friday there was a gate fire 21:05:54 <armax> stop approving until further notice 21:05:54 <amuller> And today one as well 21:05:57 <Sukhdev> kevinbenton: I have a question - please let me know when to go? 21:05:58 * kevinbenton goes to look for any other scheduled items 21:06:00 <ihrachys> armax: ok, as if it's news 21:06:12 <amuller> I would like to talk about our functional job 21:06:17 <amuller> It's... Not in a good state 21:06:20 <kevinbenton> Sukhdev: after amuller finishes 21:06:20 <pcm_> #link https://wiki.openstack.org/wiki/Network/Meetings 21:06:23 <amuller> I had to remove it from the gate queue 21:06:28 <amuller> it's still voting in the check queue 21:06:37 <armax> ihrachys: I know, I am so last year 21:06:43 <amuller> I need help getting it in to order. It has many different failures, all with a low failure rate, together causing a high failure rate 21:06:44 <kevinbenton> amuller: is it still quite unstable? 21:06:47 <amuller> Here is the list: https://bugs.launchpad.net/neutron/+bugs?field.tag=functional-tests 21:06:48 <dougwig> O/ late 21:06:50 <amuller> kevinbenton: yes, nothing has changed 21:06:57 <amuller> I whipped launchpad in to order 21:07:04 <amuller> reported new bugs, prioritized, etc 21:07:15 <HenryG> amuller: should we have a mini code-sprint? 21:07:20 <kevinbenton> amuller: ok, i got your email, sorry I didn't have a chance to help with that 21:07:23 <kevinbenton> amuller: i can help fix 21:07:33 <amuller> now I'm working on elastic search queries, but apart from the bureaucracy, I need people that can fix stuff 21:07:43 <amuller> kevinbenton: I appreciate it 21:08:07 <amuller> I'm currently working on enabling oslo rootwrap daemon mode to log to syslog, so we have some more info to go on 21:08:14 <amuller> I need warm bodies that can take a bug off that list and hunt it down 21:08:18 <amuller> That is all 21:08:27 <kevinbenton> ack 21:08:30 <rossella_s> amuller I can help 21:08:40 <amuller> rossella_s: I would certainly appreciate it :) 21:08:42 <kevinbenton> #info the functional job is unstable and needs volunteers to work on bug fixes 21:08:46 * ihrachys heads to grab one 21:08:56 <armax> kevinbenton: I’ll chime in where I can 21:08:58 <kevinbenton> #info link to functional issues https://bugs.launchpad.net/neutron/+bugs?field.tag=functional-tests 21:09:16 <armax> so to be clear: the functional job is only working in the check queue, correct? 21:09:17 <kevinbenton> Sukhdev: ok, you go now. then i'll go through the agenda on the wiki really quick 21:09:22 <kevinbenton> armax: yes 21:09:42 <Sukhdev> I want to know the release alignment strategy for the repo's 21:09:51 <Sukhdev> for vendors as well L2 GW 21:10:15 <kevinbenton> IIUC, it depends on if you are release independent or not 21:10:17 <Sukhdev> when Liberty release goes out - how are we suppose to align these repos? 21:10:30 <Sukhdev> kevinbenton: release independent 21:10:30 <kevinbenton> but this is not my area of expertise 21:10:47 <armax> Sukhdev: the story hasn’t changed 21:10:49 <ihrachys> Sukhdev: I would say, you should branch at the time when neutron is branched, and make sure you test against proper neutron branch. 21:10:53 <carl_baldwin> amuller: I could lend a hand and maybe scare up some others. 21:10:55 <kevinbenton> Sukhdev: if you are 'release independent' it means you release on your own schedule 21:11:02 <armax> Sukhdev: you can realease the same way/the same time of Neutron or you don't 21:11:12 <armax> it’s entirely up to the project release dude 21:11:12 <russellb> release independent is not aligned ... most got created that way, just by copying the rest 21:11:15 <amuller> carl_baldwin: Fear is a wonderful tactic 21:11:42 <Sukhdev> got it - thanks for clarification folks 21:11:49 <neiljerr`> amuller: I will try to help too. 21:11:51 <ihrachys> not aligned in release dates - yes, but I believe they should still be aligned in branches 21:12:00 <HenryG> amuller: create an etherpad to align on common problems/quesions? 21:12:17 <salv-orlando> the only thing worth stating should be that the project dudes that decide to release with neutron should pick consistent tags 21:12:23 <ihrachys> I would be surprised if someone manages to maintain code that is compatible with multiple major neutron versions 21:12:30 <salv-orlando> but probably that's so trivial it's not even worth mentioning 21:13:01 <ihrachys> some related info 21:13:03 <ihrachys> #link http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html 21:13:12 <salv-orlando> ihrachys: it is possible, if your plugin or driver is pretty much a cookiecutter template 21:13:28 <amuller> HenryG: I think people can collaborate on specific bugs with launchpad/IRC? I don't think we have something linking those bugs together 21:13:37 <carl_baldwin> amuller: took me a minute to get that. By “scare up” I didn’t mean to actually cause fear to anyone. :) 21:13:43 <kevinbenton> salv-orlando: the issue is that internal neutron stuff isn't super stable, we like to move code around to see how people react :) 21:14:07 <amuller> carl_baldwin: Oh, that's disappointing 21:14:12 <kevinbenton> ok 21:14:19 <kevinbenton> i want to run through this agenda really quick 21:14:25 <kevinbenton> then we can go back to open discussion 21:14:31 <kevinbenton> the open discussion sandwich 21:14:46 <kevinbenton> #topic announcements 21:15:15 <kevinbenton> #info liberty feature freeze this week 21:15:26 <kevinbenton> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 21:15:41 <Sukhdev> kevinbenton: does the FF apply to the documents? 21:15:52 <kevinbenton> Sukhdev: no, i don't think so 21:16:12 <Sukhdev> So, I can push the patch for documenting things after the FF, right? 21:16:16 <kevinbenton> it also doesn't apply to tests 21:16:18 <kevinbenton> Sukhdev: yes 21:16:27 <Sukhdev> kevinbenton: cool - thanks 21:16:32 <ihrachys> kevinbenton: what does it imply for those who have a patch or two remaining to merge to claim a blueprint done? 21:16:34 <kevinbenton> so we can continue fixing functional issues after the freeze 21:16:34 <rmoats> kevinbenton: nor bug fixes 21:16:43 <kevinbenton> rmoats: right 21:16:57 <kevinbenton> ihrachys: i think we need to get them in this week 21:16:59 * rmoats apologies - major network outage so not on as regXboi right now 21:17:03 <kevinbenton> ihrachys: or they will need an exception 21:17:21 <ihrachys> kevinbenton: ack. hopefully all fires are fought and we will have several days to merge. 21:17:49 <kevinbenton> ihrachys: right, i image exceptions will be easy for patches that were already approved but got hung up in the gate issues 21:18:02 <armax> ihrachys, ajo: I was wondering about the qos blueprints 21:18:17 <armax> https://blueprints.launchpad.net/neutron/+spec/ml2-qos and https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api 21:18:31 <ihrachys> armax: specifically?.. 21:18:45 <armax> is there anything outstanding to mark both ‘completed’? 21:19:08 <ihrachys> armax: I believe it's now mostly bug fixes + one refactoring in review 21:19:14 <armax> ok 21:19:18 <armax> ihrachys: tag me on thos? 21:19:21 <armax> those? 21:19:26 <ihrachys> I believe the latter would belong under the blueprints, but bugs are ... bugs 21:19:46 <ihrachys> refactroring: https://review.openstack.org/214218 21:19:54 <armax> but the point is that it’s functionally complete? 21:20:11 <ihrachys> and all qos bugs: https://bugs.launchpad.net/neutron/+bugs?field.tag=qos 21:20:11 <Sukhdev> What is the criteria to call blueprint complete? 21:20:13 <armax> client, server, agent, the whole end to end thingy is there? 21:20:19 <ihrachys> armax: it is long ago complete 21:20:26 <armax> right, just confirming 21:20:32 <ihrachys> yes, client is in 21:20:32 <amuller> many, many days ago, like at least 5 =D 21:20:35 <armax> docs are also being tracked? 21:20:42 <armax> 5 days? 21:20:48 <ihrachys> we miss fullstack tests yet, but that's not limited for feature freeze 21:20:52 <armax> OMG, where was I? under a rock? 21:21:02 <amuller> was going to ask about release note, and any work on official docs 21:21:21 <ihrachys> amuller: I reported a bug, and ajo said he reached someone from docs team 21:21:28 <kevinbenton> #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Liberty_Release_Notes 21:21:32 <ihrachys> the doc bug: https://bugs.launchpad.net/neutron/+bug/1489825 21:21:33 <openstack> Launchpad bug 1489825 in neutron "Document QoS feature in user guide" [Undecided,New] - Assigned to Miguel Angel Ajo (mangelajo) 21:21:34 <kevinbenton> ^release notes 21:21:42 <emagana> I can help on tracking that bug on the Docs 21:22:00 <ihrachys> emagana: that would be great. I am a bit off qos now, so better check with ajo 21:22:20 <emagana> ihrachys: I will.. and it is better to keep in the networking guide 21:22:51 <ihrachys> emagana: if ajo is not in contact with you in days, I will back him up 21:23:18 <emagana> I just left a comment to him on LP 21:23:31 <emagana> I will prepare the networking guide ToC to simplify his work... 21:23:52 <kevinbenton> ok 21:23:59 <kevinbenton> next topic? 21:24:06 <kevinbenton> #topic bugs 21:24:19 <kevinbenton> 10 bugs listed here: https://wiki.openstack.org/wiki/Network/Meetings 21:24:26 <kevinbenton> anyone want to bring up one in particular? 21:25:11 <armax> salv-orlando: any thoughts on this one? 21:25:12 <armax> https://bugs.launchpad.net/neutron/+bug/1488282 21:25:13 <openstack> Launchpad bug 1488282 in neutron "Gate failures with 'the resource could not be found'" [High,Confirmed] - Assigned to Salvatore Orlando (salvatore-orlando) 21:25:18 <ihrachys> sc68cal: do we close linuxbridge parity issues in L? 21:26:42 <kevinbenton> ihrachys: i think sc68cal is off today 21:26:51 <salv-orlando> armax: see comments in the bug 21:27:33 <salv-orlando> bottom line: not a neutron bug imho. waiting for confirmation from the nova side 21:27:38 <armax> well I meant besides those 21:27:39 <armax> ok 21:28:06 <salv-orlando> armax: then my answer should have been "I am stil waiting for somebody from the nova team to review the bug" 21:28:32 <armax> salv-orlando: sounds good 21:29:00 <kevinbenton> ok, emagana, any docs info? 21:29:03 <kevinbenton> #topic docs 21:29:25 <emagana> kevinbenton: The net docs team could not meet last week 21:29:46 <kevinbenton> ok 21:29:53 <emagana> I noticed new members contributing to docs.. so we are getting some traction finally 21:30:04 <kevinbenton> awesome! 21:30:09 <emagana> but nothing from my side but what i posted in the wiki 21:30:17 <kevinbenton> ack 21:30:19 <armax> woot? 21:30:35 <kevinbenton> #topic on demand agenda 21:31:04 <kevinbenton> pecan 21:31:13 <armax> walnut 21:31:18 <salv-orlando> armax: w∞t 21:31:19 <kevinbenton> salv-orlando: what do you think about merging this cycle? 21:31:37 <dougwig> is it the main server if it merges, or optional? 21:31:45 <kevinbenton> salv-orlando: i'm not particularily a fan of the feature branch because it seems to slow things down 21:31:48 <kevinbenton> dougwig: optional 21:32:01 <salv-orlando> kevinbenton: I think we don't have yet anything users can try even in non-prod environment to give us feedbakc 21:32:05 <ihrachys> kevinbenton: how well isolated is the new code from the experimental? 21:32:08 <salv-orlando> kevinbenton: I see your point too 21:32:12 <kevinbenton> ihrachys: very isolated 21:32:19 <kevinbenton> ihrachys: in it's own folder 21:32:23 <armax> kevinbenton: ship it 21:32:30 <kevinbenton> let's see where it is towards the end of the week 21:32:44 <salv-orlando> developing in a feature branch is good for one aspect, but requires more frequent sync with master 21:32:47 <armax> kevinbenton: surely the gate will be broken again, so don’t worry 21:32:49 <ihrachys> kevinbenton: I mean, is it enabled somehow with no config changes? 21:32:54 <kevinbenton> if we can get extensions loading for service plugins fixed and bulk operations 21:33:03 <kevinbenton> salv-orlando: will that be enough ^^? 21:33:10 <salv-orlando> kevinbenton: I am doing the former 21:33:13 <kevinbenton> salv-orlando: also the todos i left for notifications 21:33:15 <salv-orlando> you can do the latter 21:33:21 <kevinbenton> ihrachys: yes 21:33:31 <salv-orlando> kevinbenton, also ensure at least RPC notifications work 21:33:32 <kevinbenton> ihrachys: it will just be a different binary to run 21:33:41 <kevinbenton> salv-orlando: ack 21:34:00 <ihrachys> kevinbenton: oh, ok. so I would say, we should not have feature branches at all for stuff that is completely isolated. 21:34:05 <dougwig> have we reached a point where it being on a feature branch is slowing things down? 21:34:24 <kevinbenton> dougwig: yes, i think it actually discourages wider reviews 21:34:41 <kevinbenton> dougwig: and then it seems to break every other week by being behind master 21:34:53 <ihrachys> kevinbenton: I feel your pain 21:34:55 <salv-orlando> kevinbenton, armax: anyway for me, even if we merge back the feature branch, I would mark this feature definetely as "experimental, untested, use at your own risk, likely to not work" feature 21:35:18 <kevinbenton> salv-orlando: +1 21:35:18 <dougwig> then is there harm in merging it to master and letting it finish there, since it's not in the main path? 21:35:23 <ihrachys> salv-orlando: or better, don't even advertise it? :) 21:35:25 <dougwig> and salv-orlando +1 21:35:38 <armax> salv-orlando: aye 21:35:38 <kevinbenton> salv-orlando: yeah, i think we can just pretend it's not there 21:35:40 <salv-orlando> kevinbenton: actively discouraging review is not necessarily a bad thing. A feature branch is indeed supposed to be a branch where only a small subset of contributors work 21:35:55 <salv-orlando> however, for the pecan branch, it's just 3 of us occasionally there 21:36:01 <kevinbenton> salv-orlando: true, but then the merge back into master is terrible because gerrit doesn't let anyone actually review it 21:36:12 <armax> armax pats salv-orlando on the shoulder 21:36:18 <kevinbenton> +0 -0 change, LGTM! 21:36:29 <kevinbenton> :) 21:36:30 <ihrachys> kevinbenton: well, if reviewers actually want to review, they will manage (amuller did it for qos) 21:36:44 <kevinbenton> ihrachys: right, but that feedback isn't captured in a central place 21:37:08 <ihrachys> the problem is that no one wants (== everyone trusts your judgement) 21:37:28 <salv-orlando> let's also say that this is probably not perceived as a burning issue too. Rather than force-raising its priority we should take stock of that. 21:37:40 <ihrachys> kevinbenton: we had an etherpad for feedback advertised in the commit message for the merge-back patch. not that it was extremely helpful. 21:38:01 <dougwig> i feel like we're all talking hypotheticals. does anyone here actually object to merging it back onto master and continuing there? 21:38:11 <armax> I’m good 21:38:25 <ihrachys> dougwig: no objections assuming it won't break us (== it's completely isolated) 21:38:27 <salv-orlando> dougwig: I have no objection. There's plenty of broken stuff anyway in master 21:38:34 <ihrachys> salv-orlando: :) 21:38:37 <armax> salv-orlando: AMEN 21:38:43 <kevinbenton> ok 21:38:43 <salv-orlando> dougwig: let's only seek amuller's opinion 21:38:48 <salv-orlando> he's the testing general. 21:38:57 <amuller> I dont like feature branches 21:38:59 <armax> and there’s plenty of broken stuff outside master too 21:39:01 <armax> aka netaddr? 21:39:15 <salv-orlando> and we'd need to hear from him how comfortable he is around having code which is mostly not covered in tunk 21:39:17 <salv-orlando> trunk, sorry 21:39:38 <salv-orlando> and "not covered" == not covered by any sort of testds 21:39:42 <amuller> salv-orlando: I'll start bothering you when you start making noises about changing pecan to the default 21:39:42 <armax> I thought amuller was admiral? 21:39:48 <salv-orlando> meh tonight my finfers are fatter than suaul 21:39:56 <kevinbenton> well there are some tests 21:40:06 <kevinbenton> and i can put up some more if amuller wants before the merge 21:40:08 <salv-orlando> amuller: so I take your comment as saying "as long as you don't run that code I don't care about it" 21:40:13 <amuller> salv-orlando: for now yes 21:40:16 <salv-orlando> which I'm ok with 21:40:18 <dougwig> i was thinking drill seargent. amuller, does your dislike of feature branches translate into agreeing to merge this and continuing dev on master? 21:40:25 <amuller> dougwig: yes 21:40:35 <ihrachys> I guess it's ok to be liberal to get rid of the branch and tough when it will come to actual enablement 21:40:40 <amuller> salv-orlando: sadly I only care about fires that burn directly below my feet these days 21:40:42 <salv-orlando> so I guess all the people that could veto the merge back have been queried 21:40:55 <kevinbenton> #info merge pecan at the end of the week after folder rename and major issues fixed 21:41:00 <salv-orlando> amuller: you're entering the perennial firefighting cycle 21:41:12 <armax> kevinbenton: try a couple of days eearlier 21:41:18 <armax> for fear of gate turmoil 21:41:20 <salv-orlando> amuller: it's like crossing a black-hole horizon event 21:41:23 <kevinbenton> armax: ack 21:41:29 <armax> besides we’re going to cut a release in the next couple of days 21:41:38 <armax> do you want it in liberty or not? 21:41:44 <ihrachys> kevinbenton: I hope we'll have a day or two to look at the patch before it will be ninja merged though 21:41:45 <amuller> salv-orlando: that's beautiful :) your way with words is inspirational 21:41:52 <kevinbenton> salv-orlando: stuff in the queue now is actually going to merge in mitaka :) 21:41:58 <dougwig> armax: i don't think it matters if it's in liberty. 21:42:01 <armax> or the one after that 21:42:02 <salv-orlando> armax: release or "release candidate" 21:42:14 <dougwig> salv-orlando: or "guaranteed broken release candidate" 21:42:24 <salv-orlando> fwiw the pecan branch can merge now too. Maybe just merge that api action patch, kevinbenton 21:42:32 <kevinbenton> dougwig: i don't want to carry a feature branch across a release 21:42:33 <armax> dougwig: agreed 21:42:53 <kevinbenton> salv-orlando, armax: ok. i'll try to do this by the end of the day then 21:42:54 <armax> let’s not wait then 21:43:09 <kevinbenton> salv-orlando: i need feedback on what we should call the folder 21:43:16 <kevinbenton> salv-orlando: but let's discuss that after meeting 21:43:21 <kevinbenton> next topic! 21:43:28 <armax> kevinbenton: noname? 21:43:31 <kevinbenton> #topic vendor decomp 21:43:48 <kevinbenton> what should we do with vendors that haven't started decomposing? 21:43:53 <Sukhdev> kevinbenton: I have a question on vendor deocomp 21:43:55 <armax> HenryG and I will find time to clear the log during feature freeze 21:44:08 <armax> we’ll have a plan and communicate to the world 21:44:12 <kevinbenton> Sukhdev: go ahead 21:44:16 <kevinbenton> armax: ok 21:44:20 <Sukhdev> I have this patch - https://review.openstack.org/#/c/207654/ 21:44:21 <HenryG> We now have many examples that the stragglers can refer to 21:44:29 <armax> HenryG: my bad for not being very present lately 21:44:43 <Sukhdev> which merged long time ago - I used the main blueprint for it - not a bugID 21:44:51 <HenryG> armax: NP, the situation is not bad 21:44:52 <Sukhdev> Is this going to be included in Libery? 21:45:15 <armax> Sukhdev: yes, I think so 21:45:26 <ihrachys> Sukhdev: ? if it's in master, yes, it's in L 21:45:28 <Sukhdev> kevinbenton: I do not see this in the release content list 21:46:00 <Sukhdev> I see bunch of vendor decamp patches in the release content list - but, not this one - 21:46:07 <ihrachys> what is 'release content list'? 21:46:11 <Sukhdev> want to make sure this does not misses the release 21:46:24 <armax> Sukhdev: you mean the whiteboard content on the bp page? 21:46:28 <kevinbenton> Sukhdev: well it merged, there isn't a way to not release it unless it's reverted :) 21:46:32 <Sukhdev> ihrachys: Kyle posted it last week 21:46:51 <armax> Sukhdev: you’re good 21:46:59 <Sukhdev> OK - in that case I am cool - 21:47:03 <kevinbenton> ok 21:47:05 <ihrachys> you are ;) 21:47:10 <Sukhdev> thanks for clarification folks 21:47:16 <kevinbenton> #topic open discussion 21:47:19 <armax> I propose we have ‘random chair to neutron irc meeting’ once a month…it adds drama and excitement to the calendar…people will turn up waiting in awe to see who runs the meeting 21:47:24 <salv-orlando> anyway, how to deal with vendors that do not decompose? 21:47:25 <armax> :) 21:47:31 <salv-orlando> use a stronger acid? 21:47:31 <kevinbenton> #undo 21:47:31 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa560110> 21:47:41 <kevinbenton> salv-orlando: +1 21:47:45 <salv-orlando> kevinbenton: that was a joke 21:47:49 <armax> salv-orlando: they will encounter medioeval pain 21:47:49 <salv-orlando> no need to undo 21:47:50 <armax> ? 21:48:04 <Sukhdev> ihrachys, armax: this is the list that I referred to - https://launchpad.net/neutron/+milestone/liberty-3 21:48:04 <kevinbenton> armax: what is the plan for vendors that haven't done anything? 21:48:12 <salv-orlando> medieval like Marcellus Wallace's way? 21:48:21 <armax> salv-orlando: maybe? 21:48:25 <emagana> armax: I like the proposal of sharing the IRC chair 21:48:47 <armax> salv-orlando: I was re-watching pulp fiction just the other day 21:49:05 <armax> emagana: well….it might not be a bad idea after all 21:49:12 <salv-orlando> honestly since emagana is one of the few with a constant spot on the meeting - we can even make him vice-chair when kyle is not around 21:49:12 <armax> kevinbenton has been doing a great job 21:49:43 <kevinbenton> #topic open discussion 21:49:46 <kevinbenton> anything else? 21:49:48 <pcm_> kevinbenton: Bug https://bugs.launchpad.net/neutron/+bug/1484148 is no longer critical, VPN tests are skipped right now. However need decision on how to handle jobs. 21:49:49 <openstack> Launchpad bug 1484148 in neutron "neutronclient gate broken following VPNaaS infra changes" [Critical,Confirmed] - Assigned to Paul Michali (pcm) 21:50:04 <armax> kevinbenton: to your point, I think they are going to be removed in mitaka 21:50:09 <pcm_> I posted a Q to ML #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072772.html 21:50:17 <dougwig> reminder to check CI failures, not just recheck. if you don't see a bug, file one, and let amuller know. 21:50:23 <armax> kevinbenton: it’s a year they had time to react 21:50:37 <ihrachys> armax: will we kill database tables too? 21:51:02 <armax> ihrachys: I don’t think that’s necessary, but we can 21:51:24 <kevinbenton> pcm_: thanks. i'll need to read more about it to offer an opinion 21:51:29 <xgerman> I think they should move into their own schema 21:51:34 <kevinbenton> pcm_: the issue is how to handle service tests in neutron gate? 21:51:48 <pcm_> kevinbenton: For the neutronclient 21:52:01 <emagana> salv-orlando: I dont want the super power! 21:52:01 <ihrachys> well, if we do kill them, it means that we leave no way for those vendors to put the effort in M and get something released to support smooth migration 21:52:16 <ihrachys> smooth == without loosing user data 21:52:16 <kevinbenton> pcm_: i see 21:52:21 <pcm_> kevinbenton: Can have one job with plugins, one job for core and one for adv svc, or one for each adv service. 21:52:40 <armax> ihrachys: any patch proposed to deal with the plugin will have to be reviewed by the original plugin maintainer 21:52:45 <pcm_> I just need to know what we want to do, and I can update the commits. 21:52:49 <salv-orlando> emagana: try and tell that to the radioactive spider that just bit you ;) 21:52:51 <kevinbenton> pcm_: maybe just one for all advanced services 21:52:52 <emagana> emagana: feeling slow typing today! 21:52:58 <dougwig> has anyone unicast reached out to the folks with non-decomp'ed code? 21:53:10 <salv-orlando> emagana: also. Talking to yourself. 21:53:23 <armax> ihrachys: and we’ll solicit feedback 21:53:30 <ihrachys> armax: cool 21:53:34 <pcm_> kevinbenton: sure. dougwig is that OK with you? 21:53:36 <armax> ihrachys: if none is received then we can kill the schema 21:53:50 <armax> ihrachys: if there is, then we can adjust the course of action 21:54:05 <kevinbenton> does killing the schema really gain us anything? 21:54:19 <armax> kevinbenton: no 21:54:20 <dougwig> pcm_: sorry, context? is this client tests? server tests won't work well as one job for all services. 21:54:20 <kevinbenton> seems like a big risk to pissing off users 21:54:22 <HenryG> dougwig: not that I know of. I was thinking about doing it 21:54:28 <armax> well 21:54:31 <emagana> salv-orlando: :-) 21:54:36 <pcm_> dougwig: neutron client 21:54:38 <dougwig> HenryG: i don't think we should yank until we've tried reaching out. 21:54:40 <ihrachys> kevinbenton: I think it's fine to kill it a cycle later. 21:54:46 <armax> they are not going to be pissed 21:54:58 <pcm_> dougwig: Today we have one test, doesn't enable plugins and VPN is commented out. 21:55:06 <armax> because if there are users who care ($$) then the plugin would have already been decomposed 21:55:15 <armax> so the point is moot IMO 21:55:29 <Sukhdev> armax: +1 21:55:30 <armax> or if they do care, they don’t care of being on a fork 21:55:32 <kevinbenton> armax: well there may be an out of tree plugin that is kept up to date for some of these 21:55:39 <dougwig> pcm_, kevinbenton: it's fine, though in the ideal world, we'd move the services client code into extensions in the services repo, and test it directly there instead. 21:55:40 <pcm_> dougwig: I could make an adv services job that enables the VPN plugin and reenable the test. 21:56:07 <dougwig> pcm_: but as long as it's all munged into the monolithic client, i'm even fine with one job. 21:56:08 <armax> eitehr way I think we can make the case on each individual extension 21:56:19 <kevinbenton> armax, ihrachys: if we add a migration that drops tables, we could break something that someone has been using out of tree 21:56:20 <armax> I would lean towards ‘leave the schema alone' 21:56:23 <amuller> dougwig: pcm_: aye one job for all *aaS is a fine start IMO 21:56:36 <amuller> we can expand on it later if it's necessary 21:56:43 <armax> but I don’t mind if we go all ‘Marcellus Wallace’ on them 21:56:45 <ihrachys> kevinbenton: I don't remember the moment when we claimed db schema as part of public API 21:56:49 <armax> to quote salv-orlando 21:56:52 <pcm_> #action pcm_ to create one job for all adv svcs, and existing job will be used for core. 21:57:11 <kevinbenton> ihrachys: are plugins not allowed to access the DB? 21:57:21 <Sukhdev> kevinbenton: time check 3 min left 21:57:29 <kevinbenton> Sukhdev: thx 21:57:54 <salv-orlando> armax: that would imply they first tried and succeeded to do you things that cannot be mentioned on a logged IRC channel 21:58:38 <kevinbenton> ok 21:58:38 <armax> salv-orlando: ok, I take that back 21:58:43 <ihrachys> kevinbenton: I believe thru db_plugin only, but I may be wrong. also, in neutron, it's always hard to say what is public and what is private. but I believe models are too tightly coupled with neutron itself to be safely used from outside. but it may work sometimes, yes. 21:59:02 <armax> ihrachys: if it does, it works by accident 21:59:06 <armax> ...sadly 21:59:10 <kevinbenton> ihrachys: well the entire decomp relies on vendors being able to access the database 21:59:26 <HenryG> dougwig is going to give us a nice modular neutron-lib real soon now! 21:59:33 <ihrachys> kevinbenton: their own database tables, not core. 21:59:57 <kevinbenton> ihrachys: right, there are lots of vendor tables in our schema now 21:59:59 <armax> ihrachys: right…no-one is asking to remove core tables 22:00:01 <ihrachys> but yeah, we talk about vendor tables. I don't know, maybe HenryG will have better answer. 22:00:09 <kevinbenton> ihrachys: which out of tree plugins may be relying on 22:00:11 <kevinbenton> ok 22:00:14 <hichihara> we must end 22:00:14 <kevinbenton> #endmeeting