15:30:43 <mestery> #startmeeting neutron-drivers
15:30:43 <markmcclain> hi
15:30:44 <openstack> Meeting started Wed Nov 26 15:30:43 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:48 <openstack> The meeting name has been set to 'neutron_drivers'
15:30:48 <mestery> nice timing markmcclain ;)
15:30:54 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda
15:30:56 <mestery> We have a short agenda
15:31:04 <mestery> And amotoki cannot make it today.
15:31:13 <mestery> #topic Sub-Team Charter Review
15:31:14 <mestery> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters
15:31:19 <mestery> Has anyone looked at these yet?
15:31:34 <armax> I did, sir
15:31:44 <mestery> Any early thoughts armax?
15:31:57 <markmcclain> I was waiting on the sub-team for sub-teams to organize
15:32:02 <mestery> rofl
15:32:09 <dougwig> lol
15:32:14 <armax> :)
15:32:23 <mestery> I like what carl_baldwin has done for L3 there.
15:32:34 <mestery> He has specific BPs/specs he's tracking for Kilo
15:32:46 <mestery> dougwig, you also have a clear charter for LBaaS
15:33:01 <mestery> Although no unicorns dougwig :(
15:33:04 <mestery> Only rainbows
15:33:08 <dougwig> ha
15:33:08 <armax> we’d need to monitor how this page evolves, as it looks the list is potentially not complete yet
15:33:19 <mestery> armax: Yes, agreed.
15:33:33 <mestery> Mostly just wanted an early look today, and to make sure drivers were looking at it :)
15:33:41 <armax> but I think it makes sense to be explicit upfront about the fact that subteams are not lifelong teams
15:33:54 <mestery> ++
15:34:40 <mestery> #info Continue tracking Sub-Team Charter page for another week
15:34:52 <markmcclain> I am concerned about adv svcs.. not sure what they're actually setting out to accomplish
15:34:54 <mestery> #info Ensure people are aware sub-teams are not lifelong teams
15:35:05 <armax> one thing that’s not clear
15:35:11 <mestery> That one stood out for me too markmcclain
15:35:21 <markmcclain> also the edge vpn… should that be something that starts out in stackforge?
15:35:33 <armax> is what we do if as a drivers team does not feel a subteam should exist
15:35:39 <mestery> Well, either stackforge or in the new vpnaas repo
15:35:48 <armax> or cannot be supported effort-wise by the core team
15:36:01 <mestery> armax: Move it to stackforge?
15:36:01 <salv-orlando> markmcclain: my guess it that the adv svcs charter is a stub at the moment
15:36:09 <markmcclain> yeah… I still think we need to better scope the barbican interaction since it seems necesarry
15:36:21 <armax> right, but that might still need help by the core
15:36:27 <markmcclain> salv-orlando: ok if it is a stub then we should prob ask for clarity
15:36:42 <mestery> armax: Agreed, but maybe we encourage iteration in stackforge while the cores have no time?
15:36:45 <armax> what if for instance
15:36:54 <armax> I want to come up with my own subgroup
15:37:06 <armax> but drivers team feels there’s no scope for it in Kilo at all
15:37:14 <salv-orlando> markmcclain: I don’t know if they want to commit to that… it’s so vague that makes me wonder what the team is there for
15:37:15 <armax> the charter is per-cycle after all
15:37:29 <armax> the subteam can still work indepently and locally
15:37:38 <markmcclain> right folks can still self organize
15:37:44 <mestery> Right, we're not preventing that
15:37:45 <armax> but at one point there would be an interaction point with the core
15:38:01 <markmcclain> but this is really to say these teams are doing tracked work for Kilo
15:38:05 <mestery> ++
15:38:08 <armax> what if the core can’t commit to it by Kilo. Do we even have to worry about it?
15:38:09 <mestery> That's the real gist there
15:38:20 <mestery> These teams should be tracking actionable work for Kilo
15:38:27 <mestery> OR whatever release we're currently on
15:38:36 <salv-orlando> yeah that’s pretty much it for me. I think we aim at tracking sub-teams that do stuff which has to be part of the deliverable of this release cycles
15:38:59 <salv-orlando> if other groups of people do stuff more or less related to neutron in stackforge, we don’t have a need to keep track of them.
15:39:06 <armax> ok, but if the team produces deliverables in stackforge
15:39:14 <armax> why would we even track it here?
15:39:14 <salv-orlando> even though obviously they can “interact” with neutron core
15:39:24 <mestery> Right
15:39:24 <mestery> We're not saying we'll ignore them
15:39:31 <mestery> Just that if they are doing work for Kilo we can track it in a sub-team
15:39:31 <salv-orlando> it’s not like we tell them “sorry, you’re stackforge I won’t talk to you. Go away!"
15:39:41 <mestery> armax: Makes sense?
15:39:51 <salv-orlando> mestery: yes, that’s pretty much it in my opinion
15:39:58 <armax> ok
15:40:05 <armax> not sure what’s the value in that, but ok
15:40:46 <armax> for instance the edge vpn team
15:40:51 <salv-orlando> it’s funny no subteam stated an endgoal
15:41:00 <salv-orlando> jusrt lbaas has “exit criteria"
15:41:08 <armax> their charter is pretty clear
15:41:19 <kevinbenton> What is the drivers team endgoal?
15:41:26 <marun> lol
15:41:30 <armax> is the core gonna do any anthing about it this cycle?
15:41:41 <salv-orlando> kill the other teams
15:41:56 <mestery> rofl
15:41:59 <markmcclain> haha
15:42:17 <mestery> The drivers team can go away when people stop proposing specs for neutron kevinbenton.
15:42:22 <mestery> Since our goal is to approve specs :)
15:43:00 <marun> not really
15:43:03 <amuller> So lbaas subteam is done when there's no more bugs and RFEs?
15:43:18 <dougwig> if we need to be a sub team after v2, i'll ask for another charter.
15:43:19 <kevinbenton> mestery: so wouldn't the L3 team exist for an also undefined amount of time?
15:43:28 <salv-orlando> maybe the rest of the teams can indict the drivers team and ask for its suppression :)
15:43:39 <markmcclain> dougwig: right that's the correct way to do it
15:43:41 <mestery> salv-orlando: I'd prefer a revolt personally, there's more bloodshed that way
15:43:59 <markmcclain> I also think a valid charter is to be dedicated to the ongoing stable maintenance of a feature
15:44:00 <mestery> kevinbenton: If the L3 team has things to accomplish in "L", then it can re-charter
15:44:06 <dougwig> otherwise, bugs get folded into whichever team is involved (neutron), and we're not going anywhere.
15:44:15 <markmcclain> especially if that sub area requires SME
15:44:31 <salv-orlando> I think at some point we can consider the L3 team complete… once DVR-related items are complete, BGP is introduced, and it scales to a point that it won’t be a concern in large deployments
15:44:41 <kevinbenton> mestery: ok
15:44:43 <salv-orlando> frankly I expect the L3 team to be done either for Kilo or L
15:44:57 <mestery> My guess would be L, not sure BGP lands in Kilo at this point, but maybe
15:45:07 <kevinbenton> salv-orlando: l3 is not done until I see ISIS support
15:45:08 <markmcclain> salv-orlando: agreed.. I was guessing M
15:45:31 <salv-orlando> kevinbenton: that is an acronym you can’t use anymore on IRC unfortunately. It’s been hijacked.
15:45:39 <salv-orlando> and now you’ve got CIA and NSA on your back
15:45:57 <kevinbenton> salv-orlando: that just occurred to me :)
15:46:09 * mestery thinks we're all being watched anyways
15:46:12 <kevinbenton> IS-IS
15:46:12 <dougwig> salv-orlando: it's not like kevinbenton is going to bomb an airport and kill the president.
15:46:13 <armax> kevinbenton: try IS-IS
15:46:23 <mestery> dougwig: Now we're in trouble
15:46:33 <armax> oh my
15:46:36 <dougwig> come on wiretaps.
15:46:38 <dougwig> :)
15:46:38 * markmcclain awaits knock on his door from three letter agents
15:46:38 <armax> I am gonna leave this room
15:46:51 <kevinbenton> What's a letter agent?
15:47:07 <salv-orlando> markmcclain knows that even mentioning agencies puts them on your back ;)
15:47:16 <mestery> OK, lets focus again.
15:47:37 <mestery> Sub-Teams: We'll keep waiting for more people to add charters and re-review next week. Sound good?
15:47:52 <salv-orlando> sounds good to me.
15:47:54 <markmcclain> mestery: I'm intrigued about Kevin's holiday plans with a now frozen bank account :p
15:48:02 <mestery> lol
15:48:12 <mestery> As if on queue ...
15:48:12 <kevinbenton> So IIUC each sub team justifies its existence at the start of each cycle
15:48:15 <salv-orlando> markmcclain: I think he’s going to cuba.. the easternmost tip
15:48:17 <mestery> #topic Service Split BP
15:48:20 <mestery> #link https://review.openstack.org/#/c/136835/
15:48:27 <mestery> Wanted to make sure the drivers are getting in on the fun with this one.
15:48:32 <mestery> We almost had 80 comments for revision one
15:48:44 <dougwig> 84, i thought
15:48:55 <mestery> Right dougwig, we did cross 80, apologies :)
15:48:57 <dougwig> sorry, 82
15:49:54 <mestery> I think dougwig has done a good job with most of the technical details here
15:49:59 <mestery> But I wanted to highlight we're now proposing per-service repositories
15:50:00 <dougwig> the three biggest hot areas are: governance (which isn't even covered by the spec), whether extensions move before they're refactored, and the notion of making the services auto-install somehow with neutron in the kilo cycle.
15:50:10 <mestery> This will let each services team iterate at their own pace
15:50:12 <mestery> Thoughts?
15:50:19 <salv-orlando> mestery: that maes more sense.
15:50:28 <marun> auto-install?
15:50:30 <markmcclain> mestery: +1
15:50:42 <mestery> #info For the services split, we will have a per-service git repository, letting teams iterate at their own pace.
15:51:11 <dougwig> marun: you install neutron, you get lbaas v1, fwaas, vpnaas automatically, so your upgrade doesn't break any existing deployments.  in mark's email to the TC, it was stated as neutron having a dependency on the services project.
15:51:45 <marun> Isn't that up to the distros/packagers?
15:51:46 <markmcclain> backwards compatibility makes it a bit messy
15:52:00 <markmcclain> marun: the master much follow deprecation cycles
15:52:05 <markmcclain> s/much/must/
15:52:12 <marun> I'm saying it doesn't necessarily matter for distros/packagers.
15:52:21 <marun> We don't have the same backwards compatibility requirements as upstream.
15:52:53 <markmcclain> correct the distros can work with their customers to meet their needs
15:53:18 <dougwig> so can we strike that as a technical issue and just work with the distros on packaging?
15:53:33 <marun> maybe not
15:53:48 <salv-orlando> dougwig: so are the services splitting or cloning? And in the latter case, the “original” ones in neutron will go in the deprecation path?
15:54:04 <dougwig> splitting. the goal is to get some code out of neutron.
15:54:24 <marun> is the idea that neutron would reference the new distributions of the services as explicit dependencies?
15:54:25 <mestery> For LBaaS, the new neutron-lbaas project will also take lbaasv1 with it
15:54:26 <mestery> right dougwig ?
15:54:39 <dougwig> mestery: right
15:54:56 <salv-orlando> mestery: so when you talk about backward compability we’re talking about it from a deployer perspective, not consumer, is that right?
15:55:05 <dougwig> marun: if necessary, yes.  something that makes packaging implicit to the outside world, though i don't like the circular requirements.txt dependency
15:55:28 <marun> dougwig: yeah, that would be messy
15:55:32 <mestery> salv-orlando: Yes
15:55:59 <marun> dougwig: at least in the case of the vendor decomposition there's only one explicit dependency
15:56:06 <salv-orlando> cool thanks. It seems to me we’re having a discussion we should have in gerrit.
15:56:17 <markmcclain> dougwig: yeah working through how we can make the deps unidirectional
15:56:39 <marun> salv-orlando: because chatting via comments is so much better than irc?
15:56:54 <mestery> salv-orlando: ++
15:57:08 <salv-orlando> marun: it’s just that I think the meeting is over soon :)
15:58:12 <salv-orlando> dougwig: have you tried to play a bit with the code to see how the spin off for lbaas for instance would work?
15:58:15 <dougwig> markmcclain: right now i've got it specified as a circular dependency with a hacking check in neutron to prevent it being used circularly.  which is barely palatable because i know the circle gets broken in a cycle or two.  but i'd love to hear a better way.
15:58:38 <mestery> I am good with a 30 minute meeting today :)
15:58:58 <markmcclain> dougwig: yeah… I keep thinking if there is a way have a weak dep
15:59:07 <markmcclain> mestery: ++ to short meeting
15:59:07 <dougwig> salv-orlando: i have played with the also git script and experimented with two repos.
15:59:10 <dougwig> oslo
16:00:06 <armax> perhaps we need a third repo
16:00:24 <armax> to break the circular deps?
16:01:06 <marun> oy
16:01:26 <marun> make neutron depend on the repos, because it has to
16:01:32 <dougwig> like a networking umbrella repo?  i had thought of that, but it won't solve the "pip install -U neutron" case, so to speak.
16:01:36 <marun> make the services not depend on neutron and require an explicit install
16:01:59 <markmcclain> marun: eventually yes, but we'll have to tackle to short term operator impact
16:02:12 <marun> markmcclain: which operator is not going to install neutron?
16:02:33 <marun> it's only the folks that want to try to install services without neutron that have to do an extra step
16:02:50 <marun> i.e. not people with an existing install
16:03:23 <dougwig> the services repos are spec'ed to include neutron as a library dependency in kilo, so separate service installs aren't in the cards right now.
16:03:57 <mestery> Yes, for Kilo, lets keep it that way dougwig.
16:04:10 <marun> dougwig: but doesn't that imply that the services have an explicit dependency on Neutron?
16:04:35 <marun> dougwig: Given the compat requirements the explicit dep would seem more necessary for Neutron, and unless I"m missing something there can only be one.
16:04:37 <kevinbenton> So we have a circular dependency issue if we want neutron to auto install services
16:04:50 <dougwig> they do right now, since they have to import neutron to reach under the covers.
16:05:04 <marun> dougwig: They can import Neutron without having the explicit dep
16:05:07 <dougwig> kevinbenton: hence the messiness.  :)
16:05:10 <marun> dougwig: It just requires an explicit install step.
16:05:25 <marun> i.e. pip install neutron-lbaas neutron
16:05:46 <kevinbenton> marun: that's just a temporary hack, right?
16:05:58 <kevinbenton> Because that's exactly the opposite of the real dependency
16:06:06 <dougwig> just import and pray in kilo?   hmm, that's a possibiility
16:06:06 <marun> kevinbenton: Sure, for however long we need backwards compat
16:06:09 <salv-orlando> I believe that what marun is suggesting is acceptable, but I’m no operator
16:06:50 <marun> salv-orlando: I would hope documenting this requirement would be sufficient for any given operator.
16:06:54 <mestery> Also +1 to marun's idea, seems like it would work
16:06:55 <dougwig> the only place it really bites you is if you install a service in a way that would process requirements.txt, and have an older neutron, and then you'll import weirdness.  but i don't think that's a real scenario.
16:06:55 <marun> I like to think they have brains
16:06:59 <mestery> lol
16:07:33 <marun> dougwig: It will probably happen, but again, docs :)
16:07:53 <salv-orlando> I also understand markmcclain’s point. But if I had to choose between a circular dependency and requiring operators to do an additional manual step after pkg upgrade, I’d vote for the manual step
16:08:09 <salv-orlando> still, if you have a 3rd option which will give us the best of both worlds, the we’ll go for that
16:08:31 <marun> (pony!)
16:08:33 <kevinbenton> Nobody reads docs
16:08:40 <dougwig> i'll go with marun's idea unless someone pulls some magic out of a hat.
16:08:54 <marun> kevinbenton: true.  it's more a 'get out of jail free' card
16:09:06 <marun> kevinbenton: 'something went wrong?  did you read the docs?'
16:09:24 <kevinbenton> Yeah
16:09:30 <armax> what about hte usual RTFM
16:09:30 <armax> ?
16:09:49 <marun> trying to avoid channeling linus
16:09:53 <kevinbenton> That's what people say when they have bad UX :)
16:09:54 <marun> but that would work too
16:09:58 <armax> :)
16:10:04 <dougwig> linus strikes me as more of a PEBKAC kind of guy.
16:10:07 <salv-orlando> oh you don’t say RTFM in openstack. We simulate respect for others
16:10:09 <marun> hah
16:10:52 <kevinbenton> Dougwig made a good point though. This will just be a weird corner case
16:11:13 <mestery> lol
16:11:31 * mestery thinks we've ratholed deep enough
16:11:42 <salv-orlando> ok… can you guys remind me why are we worrying about that if it’s a weird corner cases that can be easily documented and distros don’t really care about it?
16:11:56 <mestery> salv-orlando: See rathole comment above
16:11:58 <mestery> ;)
16:12:00 <dougwig> we're not, we're just dribbling into IRC.
16:12:00 <salv-orlando> indee
16:12:03 <armax> either way we go, people need to be aware that something in Kilo changed
16:12:11 <dougwig> continue rathole in gerrit.  i want to break 100 comments on this rev.
16:12:13 <armax> so they need to document themselves of the potential pitfalls
16:12:24 <mestery> I think it's safe to assume people can read, now whether they do that is harder to predict
16:12:33 <armax> right
16:12:44 <mestery> "Hey, new shiny thing!" <Throws manual away and starts playhing>
16:12:52 <armax> our job should stop at ‘documenting'
16:12:54 <salv-orlando> dougwig: it’s like you win a teddy bear if you reach 100 comments on a single patchset… you win that if you reach 100 patchsets!
16:13:07 * dougwig writes down his new goal.
16:13:29 <dougwig> i'll just submit PS1 as ruby, and let people review it as python.
16:13:33 * mestery pulls us back out of the hole
16:13:41 <mestery> OK, make sure to review dougwig's spec if you haven't.
16:13:44 <mestery> Good stuff in there.
16:13:59 <mestery> And it's important, we need to be moving forward on this next week if we want to make progress before the holidays
16:14:04 <salv-orlando> mestery: I think they’ll go back to the manual immediately after upgrade once their neutron server won’t start because it does not find the lb service plugin
16:14:04 <mestery> #topic Open Discussion
16:14:06 <mestery> Anything else?
16:14:15 <mestery> salv-orlando: If they can find the manual ;)
16:14:24 <kevinbenton> Ihar has made a point on the vendor pl
16:14:32 <kevinbenton> Vendor split*
16:14:49 <armax> kevinbenton: I am actually pushing another revision shortly
16:14:56 <kevinbenton> That Red Hat will likely not create packages for the vendors
16:15:01 <kevinbenton> Unless they are partners
16:15:14 <armax> ihar’s point is well taken, but I think that makes quite a bit of sense
16:15:29 <marun> Unless a vendor has zero extra dependencies, I'm not sure that's really a problem.
16:15:33 <mestery> I'll I'm going to say here is that the only way to make that possible (packages by distros) is if we have a single, shared repo for all the plugins and drivers, not in neutron itself.
16:15:34 <dougwig> so?  where the packages stop, pypi takes over.
16:15:38 <mestery> And that presents a whole host of other issues
16:15:58 <kevinbenton> It's a problem for our code
16:16:00 <marun> mestery: The problem of having extra non-Neutron deps is common to pretty much any solution.
16:16:00 <kevinbenton> Because we have no other deps
16:16:07 <mestery> marun: Ack
16:16:15 <armax> we can always figure out ways to make everyone happy, but all things considered, potential lack of packaging is not the real stopper to adoption of a specific vendor solution IMO
16:16:18 <marun> mestery: So if we solve some of it, they still have work to do.
16:16:26 <marun> i.e. install contrail is not our job.
16:16:30 <mestery> marun: Exactly
16:16:37 <mestery> I agree marun
16:16:46 <mestery> Frankly, the plugin/driver is the easy part
16:16:48 <marun> So pretty much any vendor has to be able to package and distribute extra deps.
16:16:54 <mestery> The controllers are likely way harder to install
16:17:05 <marun> Either with a distro's help or otherwise.
16:17:14 <kevinbenton> Marun we don't now
16:17:16 <salv-orlando> I think we already had this discussion about packaging and we reached a consensus that it was the plugin maintainer interest to ensure it was packaged properly?
16:17:24 <marun> kevinbenton: You don't have software to install?
16:17:28 <kevinbenton> No
16:17:39 <marun> kevinbenton: just hardware?
16:17:40 <salv-orlando> I am sure I bored you for about 20 minutes last week with this packaging story
16:17:45 <kevinbenton> Yes
16:17:58 <kevinbenton> Perhaps we are a corner case
16:18:09 <kevinbenton> But there are no extra python libs for big switch
16:18:20 <marun> kevinbenton: Hmmm... I'm not sure why I assumed bigswitch was primarily a software solution, my bad.
16:18:36 <kevinbenton> Or code on the openstack nodes
16:18:47 <salv-orlando> marun: you’re so 2012!
16:18:51 <kevinbenton> Marun: we have an optional vswitch
16:19:19 <kevinbenton> But it is optional precisely because we had some pushback from installing extra stuff
16:20:01 <salv-orlando> anyway, let’s leave the controllers aside, and focus on another comment from the hyper-v team that they’re concerned of being neglected because their plugin has a smaller user base.
16:20:02 <kevinbenton> Oh well, I don't think I need to waste more of this meetings time
16:20:18 <salv-orlando> what should we answer them to reassure they won’t end up being forgotten?
16:20:23 <marun> I guess offline discussion is suggested then.
16:20:47 <kevinbenton> Salv-orlando by who?
16:20:54 <dougwig> we have ten minutes, unless there's another topic...
16:20:57 <marun> That we want to focus our efforts on benefiting as large a part of the community as possible?
16:21:06 <natarajk> Does the vendor code decomposition scope include vendor L3 service plugins also ?
16:21:12 <mestery> dougwig: Now you've jinxed us :(
16:21:19 <alexpilotti> salv-orlando: it’s not because of the user base size
16:21:45 <salv-orlando> ah see hear it from alexpilotti. I did not want to offend you saying you’ve got a small user base ;)
16:21:47 <mestery> natarajk: Not for stage one, but I defer to armax. Those will be spun into the respective service repositories.
16:21:59 <armax> natarajk: I would think so
16:22:01 <alexpilotti> salv-orlando: np, and thanks for raising this up :-)
16:22:20 <kevinbenton> armax +1
16:22:27 <natarajk> armax: Thanks. I didn't see any mention of vendor of L3 service plugins in the spec. That's why the question
16:22:42 <armax> I am sure there was, I’ll make the extra effort to emphasize
16:22:50 <alexpilotti> salv-orlando: we definitely agree on getting the drivers out of Neutron
16:23:28 <alexpilotti> our main concern is that if the drivers will land out of core (e.g. devstack), there will be different perceptions
16:23:47 <mestery> So, for devstack, have folks seen this?
16:23:48 <mestery> https://review.openstack.org/#/c/137054/2
16:23:53 <kevinbenton> alexpilotti: that's why all are being separated
16:23:54 <mestery> That spec proposes pluggable devstack
16:23:54 <salv-orlando> alexpilotti: did you mean devstack or stackforge?
16:24:04 <mestery> And I think devstack will push to get rid of a lot of things upstream with regards to drivers :)
16:24:11 <mestery> alexpilotti: Your conversation made me think of that
16:24:13 <alexpilotti> salv-orlando: stackforge, horrible lapsus, sorry :-)
16:24:50 <alexpilotti> the docs team already agreed in documenting only fully end to end open source stacks
16:24:51 <dougwig> alexpilotti: well, they will have different perceptions because there are different realities.  you're trading in-tree code for a healthier core project and more flexibility with your own code.  that's the crux of agreeing to the split.
16:25:36 <alexpilotti> dougwig: the way you put it, it sounds like you guys are kicking us out for Neutron’s benefit
16:25:43 <salv-orlando> I think the “stackforge is a terrible place to be” discussion has come often. My answer in short is that it’s as good as any other place to keep your code public, but work is needed at the community level to communicate that if you go to stackforge is not because you’ve been booted out
16:25:55 <alexpilotti> not caring about what actually happens with the plugins as it’s not your responsability anymore :-)
16:26:23 <alexpilotti> my question is: since the plugin today is core code, why can’t we still be core?
16:26:46 <alexpilotti> I mean, teh people writing and maintaining that code are the same
16:27:05 <alexpilotti> so I don’t get why we should go back to the starting port (aka StackForge purgatory)
16:27:06 <kevinbenton> alexpilotti: it's consuming community resources
16:27:14 <dougwig> if we're cold-blooded, that is one of the net advantages.  but i don't think the intent is to "kick out" or to lose the community aspect; merely to change the interface by which that happens.  that's far from not caring.  (i'm not a core, and i am a vendor, btw, so this is just my opinion.)
16:27:40 <armax> alexpilotti: core of what?
16:27:46 <armax> stackforge is no purgatory
16:27:48 <alexpilotti> teh plugins are a community asset, of course they consume community resources!
16:28:11 <armax> I think people should refrain from making such statements
16:28:12 <marun> alexpilotti: 'community asset'?
16:28:13 <alexpilotti> armax: of cours it is: you have to wait to cycles before asking to be admitted in core “heaven”
16:28:17 <mestery> communit assett?
16:28:27 <mestery> We can't even test most of htem because they require proprietary controllers or HW
16:28:31 <mestery> How are they community assetts?
16:28:40 <alexpilotti> the plugins are
16:28:41 <marun> alexpilotti: core heaven is a process-heavy development environment that I wouldn't wish on anyone that didn't absolutely require it
16:28:44 <armax> alexpilotti: there will no longer be a core heaven, and let me tell you, today the core is far from being heaven, perhaps hell if you ask me
16:28:54 <mestery> armax: ++
16:28:57 <alexpilotti> the  underlying technology not
16:28:58 <mestery> marun: ++
16:29:24 <mestery> All the effort we've done to try to get people to test their code, run CI systems, all of that takes cycles from cores and other people upstream
16:29:24 <mestery> It's a huge effort
16:29:25 <kevinbenton> I think an analogy would be the way Linux drivers are a community asset
16:29:29 <alexpilotti> armax: sure, nova for example for us is the closest thing to hell we’ve been in
16:29:52 <marun> alexpilotti: neutron in it's current state is worse than nova
16:29:55 <alexpilotti> mestery: we run our own CI
16:30:03 <mestery> alexpilotti: You guys do a good job with that, but others ...
16:30:05 <marun> alexpilotti: are you saying you find that productive?
16:30:14 <alexpilotti> marun: trust me: you guys are angels in comparison ;-)
16:30:32 <marun> alexpilotti: I guess our standards differ.
16:30:37 <alexpilotti> mestery: yeah, but why do we have to pay the price for others?
16:30:38 <salv-orlando> alexpilotti: but still, we won’t be able to list any driver-specific item in kilo priorities, just like nova
16:30:41 <mestery> OK we're at time
16:30:46 <mestery> Thanks for a productive discussion folks.
16:30:48 <mestery> #endmeeting