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