16:02:06 <rkukura> #startmeeting networking_ml2
16:02:07 <openstack> Meeting started Wed Feb 18 16:02:06 2015 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:10 <openstack> The meeting name has been set to 'networking_ml2'
16:02:35 <rkukura> #link agenda https://wiki.openstack.org/wiki/Meetings/ML2
16:03:08 <rkukura> #topic Announcements
16:03:59 <rkukura> Please be sure to vote for summit presentations
16:04:10 <rkukura> Anyone have the link handy?
16:05:04 <rkukura> #link https://www.openstack.org/vote-vancouver
16:05:05 * Sukhdev looking
16:05:11 <rkukura> Any other announcements?
16:05:56 <rkukura> #topic ML2 Drivers decomposition discussion
16:06:07 <Sukhdev> https://www.openstack.org/vote-vancouver/presentation/scaling-neutron-with-ml2-hierarchical-networks
16:06:56 <Sukhdev> if you do not mind, can I share couple of more links for you to vote?
16:07:22 <rkukura> #undo
16:07:23 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x9f9ca10>
16:07:32 <Sukhdev> thanks
16:07:34 <rkukura> #redo
16:07:37 <Sukhdev> https://www.openstack.org/vote-vancouver/presentation/panel-the-future-of-neutron-plugin-and-driver-innovation
16:07:51 <Sukhdev> https://www.openstack.org/vote-vancouver/presentation/bringing-provider-networks-into-openstack-using-l2-gateway
16:08:10 <Sukhdev> please vote on all three of those - will appreciate it...
16:09:04 <Sukhdev> sorry - just woke up - hence, bit slow :-)
16:09:12 <banix> There is a talk proposed similar to the first one
16:09:13 <rkukura> note that markmcclain also proposed a talk similar to https://www.openstack.org/vote-vancouver/presentation/scaling-neutron-with-ml2-hierarchical-networks - we should consider merging them
16:09:33 <rkukura> banix: right
16:09:45 <banix> rkukura: right
16:09:48 <sadasu> Sukhdev: you've been busy :-)
16:10:02 <Sukhdev> rkukura: i have not browsed through all the presentations yet
16:10:08 <Sukhdev> sadasu :-)
16:10:13 <rkukura> I’ve also got a proposal for a GBP lab session, but that’s kind of off-topic
16:10:15 <sadasu> rkukura: +1
16:10:30 <banix> Merging sounds reasonable
16:10:56 <Sukhdev> rkukura: you can ask for votes - paste the link :-)
16:11:18 <Sukhdev> rkukura: we are a small family here - so, its OK
16:11:35 <rkukura> https://www.openstack.org/vote-paris/presentation/group-based-policy-hands-on-lab
16:11:55 <rkukura> Any other submissions we should conisider voting for???
16:12:20 <rkukura> OK, lets move on…
16:12:25 <moshele> rkukura: I would like the raise the issue of out of tree vendor plugins/MD packaging for distro  like rhel, Ubuntu. I would like to know how other vendors plan on handling it.
16:12:43 <rkukura> moshele: I was just going to mention that
16:12:51 <moshele> :)
16:13:23 <Sukhdev> moshele: can you articulate the issue?
16:13:44 <rkukura> Do we know whether distros will be dropping the decomposed drivers, including just the in-tree code in their packages, or also packaging the out-of-tree libraries?
16:14:28 <Sukhdev> moshele: I brought up this issue with armax
16:15:04 <Sukhdev> moshele: he mentioned he is working on this - I had similar concern
16:15:17 <rkukura> marun: Do you know how Red Hat plans to handle decomposed ML2 drivers in RDO and RHEL OSP?
16:15:24 <armax> Sukhdev: distros are working on this as far as I can tell
16:15:58 <rkukura> otherwiseguy: ^^^
16:16:05 <moshele> Sukhdev: I talked to redhat and they say they will only package odl which is out of tree
16:16:07 <Sukhdev> armax: do you have any thing additional you can share on this issue
16:16:29 <rkukura> moshele: Do you mean that this is the only out-of-tree backend library they plan to package?
16:16:59 <marun> rkukura: I don't know, but I'll try to get someone here that can.
16:17:03 <otherwiseguy> rkukura: I probably should know, but don't. Ihar might.
16:17:10 <armax> I’ll be ready for the next Neutron IRC meeting
16:17:32 <ihrachyshka> o/
16:17:40 <marun> rkukura: can you ask again for ihrachyshka?
16:17:41 <rkukura> marun, otherwiseguy: Thanks!
16:17:41 <ihrachyshka> can anyone repeat the question on rhos?
16:18:13 <moshele> my understanding was they are not going to package vendor specific plugin
16:18:26 <rkukura> ihrachyshka: If you have any insight into how Red Hat plans to handle decomposed ML2 drivers in RDO and RHEL OSP, please let us know
16:19:22 <rkukura> marun, otherwiseguy, ihrachyshka: Is my understanding correct that “pip install …” is frowned upon from a RHEL OSP support perspective?
16:19:31 <ihrachyshka> moshele, rkukura, so the short answer is RH is going to walk thru the list of actual vendor plugins decomposed and decide case by case whether it's worth the effort (worth not being decided purely on economic merits)
16:20:01 <ihrachyshka> rkukura, pip is a bad idea to ship your code to users in any case
16:20:12 <moshele> do you know what other distro plan?
16:20:19 <ihrachyshka> rkukura, but vendors are always free to create their own yum repos and ship them to users
16:20:29 <ihrachyshka> and that's independent of what Red Hat or RDO decides
16:20:40 <ihrachyshka> moshele, no, I haven't checked with anyone
16:20:49 <rkukura> ihrachyshka: Thanks very much!
16:21:01 <ihrachyshka> shipping vendor repos is one thing that is now available for vendors but was not before - a good option actually
16:21:18 <Sukhdev> ihrachyshka, armax : Can we put this on agenda for next Neutron core meeting ?
16:21:23 <ihrachyshka> so we will definitely consider packaging stuff like odl, maybe opencontrail, maybe nsx...
16:21:36 <ihrachyshka> not sure about other stuff, I'm not to decide
16:22:13 <moshele> ihrachyshka
16:22:13 <moshele> shouldn't all the plugin/md be in one repo?
16:22:17 <ihrachyshka> and also, we would be very pleased if vendors hop in and package their stuff for fedora ;)
16:22:27 <Sukhdev> ihrachyshka: for vendors who have certification program in place with RH (for example), I will assume they will be picked up automatically
16:22:31 <ihrachyshka> and then we'll make sure we import it to RDO
16:22:37 <rkukura> ihrachyshka: Was going to mention that option
16:23:08 <ihrachyshka> moshele, not at all, you will just ship vendor library and instruct users to install it in addition to neutron pacakge
16:23:22 <ihrachyshka> Sukhdev, cert program is per cycle I guess
16:23:35 <ihrachyshka> Sukhdev, so this is to be revisited
16:23:39 <ihrachyshka> or so I think
16:23:51 <ihrachyshka> note that I'm an engineer, not a product manager, so be cautious
16:24:17 <moshele> ihrachyshka: can we add it to epel?
16:24:17 <moshele> shouldn't all the plugin/md be in one repo?
16:24:53 <ihrachyshka> moshele, epel? no way, epel packages are supported for a really long time
16:25:01 <rkukura> moshele: RDO covers Fedora and EPEL
16:25:04 <ihrachyshka> moshele, and since we don't have neutron in epel (and won't ever...)
16:25:13 <ihrachyshka> rkukura, right, RDO is the way to go
16:25:49 <ihrachyshka> moshele, multiple repos are fine, it's just that neutron side won't automatically fetch dependency from vendor repo, but that's a minor thing
16:26:00 <rkukura> ihrachyshka: If a vendor library gets into Fedora and then RDO, can the RDO yum repo be used with RHEL OSP?
16:26:15 <ihrachyshka> in brave new rpm 4.12 world, we may even consider Recommends:'ing vendor libs
16:26:31 <moshele> what it the process to add it to RDO?
16:26:48 <ihrachyshka> rkukura, no, you don't mix RDO repos with RHEL-OSP repos. Or an atomic blast will occur.
16:26:50 <rkukura> At some point it may be worth seeing if the neutron puppet modules can pull in dependencies based on which drivers are enabled
16:26:59 <ihrachyshka> rkukura, it's safer to ship a repo with just vendor lib
16:27:11 <ihrachyshka> moshele, https://openstack.redhat.com/packaging/rdo-packaging.html
16:27:25 <ihrachyshka> rkukura, that's another option, right
16:28:09 <Sukhdev> #link: https://openstack.redhat.com/packaging/rdo-packaging.html
16:28:23 <ihrachyshka> so, all in all, we are not evil and would like to ship stuff, so if vendors do part of packaging in Fedora/RDO, we will be glad to consider shipping stuff in RHOSP too (though again, I'm not an official person to say that)
16:28:41 <rkukura> #action rkukura and Sukhdev to include followup on disto packaging of drivers in next week’s agenda
16:28:43 <shivharis> i would think that is would be nice if there is consitency in the process for all drivers
16:29:13 <moshele> +1
16:29:17 <shivharis> splitting along recomended etc is technically not right
16:29:39 <Sukhdev> ihrachyshka, armax: It will be nice to document the process so that all vendors are the same page on this process
16:29:53 <ihrachyshka> shivharis, we would be glad to see patches to add new packages to fedora and RDO ;)
16:30:01 <rkukura> ihrachyshka: Sounds like the driver situation isn’t that different than with add-on projects like GBP - see https://openstack.redhat.com/Neutron_GBP
16:30:12 <ihrachyshka> rkukura++
16:30:13 <armax> Sukhdev: I’ll sync up with ihrachyshka on the matter
16:30:37 <Sukhdev> armax: cool - thanks
16:30:46 <ihrachyshka> RDO project is willing to see more participants from outside, and would be glad to see more stuff in. we just don't have enough hands for everything. openstack is too rapid.
16:31:03 <rkukura> OK, anything else on decomposition before we move onto the next agenda item?
16:32:22 <rkukura> As a Fedora packager, I’m happy to help review any packages for ML2 drivers.
16:33:04 <rkukura> #topic ML2 Sync and error handling (Task Flow)
16:33:29 <rkukura> Do we have an update on this? I don’t see manishg.
16:34:09 <rkukura> OK, lets try to review the WIP patch and supply feedback
16:34:23 <rkukura> #topic ML2 Extension Driver API enhancements
16:34:31 <yamahata> hello
16:34:40 <yamahata> Is shwetaap1 there?
16:34:46 <shwetaap1> yea i am here
16:34:52 <rkukura> There are now two different patches with modifications to the extension driver API - care to summarize?
16:35:22 <yamahata> Sure, I split out the patch https://review.openstack.org/#/c/152759/ into
16:35:23 <rkukura> Note - these are important in getting the portsecurity BP into kilo-3
16:35:32 <yamahata> two
16:35:39 <yamahata> the 152759 and https://review.openstack.org/#/c/129178/
16:35:59 <yamahata> Eventually they may be consolidate one again, but I did for discussion
16:36:10 <yamahata> The first one is to add context,
16:36:33 <rkukura> yamahata: That’s plugin_context, right?
16:36:40 <yamahata> the latter one is to add db object argument to extension driver of extend_xxx_dict
16:36:42 <yamahata> rkukura: right.
16:36:52 <yamahata> shwetaap1: anything to comment?
16:37:03 <yamahata> There are two points of discussion.
16:37:21 <yamahata> should we introduce ExtensionDriverContext intead of plugin_context.
16:37:32 <rkukura> yamahata: And is the goal of the 2nd to allow navigation the sqlalchemy relationship between the base resource model and the extension model?
16:37:54 <yamahata> rkukura: Correct.
16:38:15 <yamahata> Another discussion point is to drop session argument from extend_xxx_dict
16:38:28 <rkukura> yamahata: I’m wondering if all EDs would do that, or if they also need the DB context so they can do their own queries?
16:39:26 <yamahata> portsecurity ED doen't need DB query in extend_xxx_dict
16:39:32 <yamahata> doesn't
16:40:09 <shwetaap1> Yeah if there isnt a backref while creating the extension attribute db model to the main resource, in those cases the session attribute maybe required
16:40:12 <rkukura> I’ve suggested passing an ExtensionContext class to the ED methods so that additional attributes can be added later without breaking existing ED code.
16:40:59 <yamahata> rkukura: Okay, so let's introduce ExtensionDriverContext.
16:41:09 <rkukura> So should we create and ExtensionContext that has attributes for the DB session, the plugin_context, the resource model, etc?
16:41:27 <yamahata> Right.
16:41:53 <yamahata> But extend_xxx_dict can't receive extension context.
16:42:06 <rkukura> And if so, can we use the same ExtensionContext class for the create, update and extend methods?
16:42:24 <yamahata> No for extend methods, yes for create, update
16:42:39 <yamahata> extend methods are called by base db plugin class as hook.
16:42:49 <rkukura> yamahata: What’s not available from this hook?
16:44:05 <yamahata> The hook is called as extend_xxx_dict(self=plugin, result, db_entry)
16:44:19 <yamahata> common_db_mixin._apply_dict_extend_functions
16:45:28 <rkukura> The extend_<resource>_dict() methods are currently called with self, session, and result.
16:47:05 <rkukura> Let’s follwup-up on the gerrit reviews so we can cover the rest of the agenda
16:47:14 <rkukura> Anything else on these patches first?
16:47:20 <yamahata> Okay.
16:47:40 <rkukura> #topic Bugs
16:47:47 <rkukura> shivharis: you are up
16:47:54 <shivharis> hi
16:48:15 <shivharis> regarding bugs k3 deadline is Mar 19 (about a month away)
16:48:35 <shivharis> We need all the high priority bugs fixed by this time
16:49:14 <shivharis> as regards movings bugs from medium to high (change prio) i dont see any pressing issues
16:49:24 <rkukura> shivharis: Do you feel the ml2 bugs are all prioritized correctly?
16:49:37 <rkukura> shivharis: you are ahead of me :)
16:49:38 <shivharis> rkukura: correct me on that one... I have scanned the bug list
16:50:32 <shivharis> actually we should be focusing on the medium bugs as well
16:50:55 <shivharis> i will have a list of these by next meeting
16:51:08 <shivharis> Any questions from others regarding bugs?
16:51:43 <shivharis> thats all from me
16:51:48 <rkukura> shivharis: Thanks!
16:51:59 <rkukura> any questions regarding bugs?
16:52:14 <rkukura> #topic Open Discussion
16:52:57 <rkukura> anything to discuss?
16:53:08 <Sukhdev> Please vote on all the presentation links provided
16:54:00 <banix_> wondering how important the votes are but that is a different topic....
16:54:06 <banix_> yes please do vote
16:54:51 <Sukhdev> banix_: I thought they picked the topics based upon votes, no?
16:54:52 <rkukura> yamahata, shwetaap1: Did you want to cover anything else regarding extension drivers and portsecurity today?
16:55:15 <banix_> Sukhdev: that is part of the selection process not the only part
16:55:26 <Sukhdev> banix_: do you have any insight to the process?
16:55:27 <shwetaap1> the updated patch is available, would be great to get more reviews on it
16:55:36 <rkukura> banix: My understanding is the votes are a consideration, but not the only one
16:55:41 <yamahata> We'll respin the patches soon. So please review it after upload.
16:55:52 <banix_> Sukhdev: i decide based on the position os starts and such :)
16:55:57 <Sukhdev> yamahata: sounds good - thanks
16:56:33 <shivharis> i want to thank folks for the review of bug fixes
16:57:00 <rkukura> shivharis: I 2nd that - we’ve got a lot of good work in review right now, so lets get it merged
16:57:01 <banix_> Sukhdev: i think a group (not sure who) will decide
16:57:38 <Sukhdev> banix_: you mean based upon the gold/platinum membership, etc..?
16:58:01 <banix_> Sukhdev: not really…. based on one hope relevance to the summit etc
16:58:30 <Sukhdev> banix_: Oh I see
16:58:32 <banix_> noticed more than 100 submissions on networking track
16:59:17 <rkukura> OK, our time is about up - thanks everyone!!!
16:59:37 <rkukura> #endmeeting