16:00:35 <Sukhdev> #startmeeting:  ironic_neutron
16:00:36 <openstack> Meeting started Mon Mar 14 16:00:35 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:40 <openstack> The meeting name has been set to '__ironic_neutron'
16:01:04 <sambetts> o/ Hi all
16:01:11 <Sukhdev> #topic: Agenda
16:01:13 <vdrok> o/
16:01:19 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_March_14.2C_2016
16:01:34 <Sukhdev> #topic: Announcements
16:01:51 <Sukhdev> Folks, anybody has any announcement to make?
16:02:00 <Sukhdev> before we dive into the agenda
16:02:37 <Sukhdev> Mitaka release is fast approaching - we have few patches remaining to merge
16:02:46 <Sukhdev> #topic: Patches under review
16:02:51 <sambetts> jroll is coming
16:02:54 <jroll> hey, sorry I'm late
16:02:56 <killer_prince> 0/
16:03:03 <vdrok> Sukhdev, have you seen jroll's email?
16:03:08 <killer_prince> so am i
16:03:16 <Sukhdev> vdrok : no
16:03:18 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089143.html
16:03:20 <jroll> said email.
16:03:43 <jroll> I'm sorry to say we need to bump this to newton - it isn't complete and very risky code to land at this stage
16:04:04 <jroll> this is all on me; I failed to sufficiently get enough resources on this
16:04:10 <jroll> especially early in the cycle
16:04:24 <jroll> we should totally keep working on it and land it as soon as newton opens
16:04:47 <jroll> without the client or nova code in mitaka, it wouldn't be terribly useful anyway
16:05:41 <Sukhdev> wow!!
16:06:03 <Sukhdev> jroll : I thought we were very close
16:06:16 <Sukhdev> and still had enough time to get it in
16:06:24 <Sukhdev> we have tested it well already
16:06:27 <jroll> Sukhdev: we were, but the refactoring was large and slow-going
16:06:38 <jroll> the tested stuff was not well architected (also my fault)
16:06:47 <jroll> and we didn't catch that until the midcycle a couple weeks ago
16:06:58 <jroll> so again, sorry :(
16:07:41 <Sukhdev> jroll - the refactored code looks good - two patches merged, one to go - we have time
16:07:54 <Sukhdev> why rush the decision to push it to next release?
16:07:57 <jroll> Sukhdev: this code? https://review.openstack.org/#/c/285852/
16:08:16 <Sukhdev> yup -
16:08:34 <Sukhdev> lets work on it clean it and get it done - we have time
16:08:36 <jroll> I haven't looked since the last update, honestly
16:08:54 <Sukhdev> lots of customers/users are waiting for Mitaka for this
16:08:58 <jroll> but given the deadline for release is april 1, I don't see this as rushing
16:09:00 <jroll> I agree
16:09:01 <killer_prince> that was just to get it going.. but lot many things came up on that patch during mid-cycle..
16:09:08 <jroll> I'm very sad to not see it landing
16:09:23 <jroll> this was my top thing I wanted to complete this cycle
16:09:29 <jroll> and I failed to do so, and I'm sorry for that
16:09:48 <killer_prince> Would it be possible to get it early in Newton and then back port for Mitaka..?
16:09:50 <jroll> devananda and I chatted about it and decided it's too risky to land
16:09:57 <Sukhdev> jroll : we still have time until april 1 -
16:09:58 <jroll> we definitely cannot backport it
16:10:39 <jroll> Sukhdev: right, that's not very much time at all, especially when accounting for potential bugs and such
16:11:00 <Sukhdev> jroll : there are customers/users who are waiting for this - we can fix/address bugs as we go along
16:11:12 <jroll> I understand
16:11:14 <jroll> and we've failed them
16:11:19 <Sukhdev> or reduce it to one or two patches
16:11:24 <jroll> this is the decision we've made, you're welcome to join in on the mailing list if you want to discuss further
16:11:44 <Sukhdev> jroll : can I please? when is the meeting?
16:12:08 <jroll> Sukhdev: the ironic meeting is right after this one in #openstack-meeting-3, but I'd prefer the mailing list
16:12:15 <jroll> but you're welcome to join in open discussion too
16:12:45 <Sukhdev> jroll: it conflicts for me, but, will try to pop in
16:12:56 <jroll> Sukhdev: then use the mailing list, please
16:13:07 <Sukhdev> jroll : sure
16:13:37 <Sukhdev> jroll : Just, so that everybody is on the same page - I see 4 patches that need to be merged for this feature to be complete
16:14:00 <Sukhdev> All of them look very close to being ready
16:14:24 <Sukhdev> so, I am wondering if you can highlight what exactly is the risk that you felt?
16:14:34 <jroll> Sukhdev: I see 7 - https://review.openstack.org/#/q/topic:bug/1526403+status:open and https://review.openstack.org/#/c/285852/
16:14:45 <devananda> the doc patches and most of the test patches looked fine to me, last time I reviewed them
16:14:48 <jroll> Sukhdev: not to mention nova/ironicclient changes that will not merge in mitaka
16:15:17 <jroll> Sukhdev: the risk is that we're making a large change to our driver internals to complete this (in 285852)
16:15:48 <devananda> however the API and driver loading patches -- the first two in the chain -- are the key ones. and as jroll already said, these are risky and need to be done right, or they could break compatibility with many users out there
16:15:51 <jroll> not to mention all the other changes
16:16:13 <devananda> and the client and nova changes can't get included in mitaka at this point, so the feature can not be considered "complete" even if we landed everything in ironic
16:16:16 <jroll> I also want to make sure that we get them *right*, and don't end up with tech debt. especially in the API, which we can never fix
16:16:30 <jroll> and any debt in the driver stuff is going to be difficult to unwind as well
16:16:37 <jroll> I don't want to rush those in
16:17:00 <vdrok> for the record - I've tried this with refactoring code today, it seems to work the same way as old code, but I agree that it needs much more testing
16:17:38 <Sukhdev> vdrok : I have been testing on a regular basis as well - and all looks good
16:18:00 <Sukhdev> hence, I am surprised by this announcement
16:18:28 <Sukhdev> lots of people will be disappointed
16:18:39 <jroll> Sukhdev: were you at the midcycle? did you read my midcycle summaries?
16:19:03 <Sukhdev> jroll: I wish I was there :-) no
16:19:35 <jroll> Sukhdev: it's not so surprising if you go back and read those, and especially if you were online when we reviewed these patches
16:20:45 <jroll> anyway, I'd like to continue making progress on this work so we can land it when newton opens up
16:21:01 <Sukhdev> jroll : sounds good -
16:21:34 <Sukhdev> jroll : one thought - do not know if possible -
16:21:57 <Sukhdev> to reduce the number of patches that customers have to deploy over mitaka to start to test this feature
16:22:44 <Sukhdev> I know there are people who are waiting to April to come around to start testing this :-):-)
16:22:54 <jroll> Sukhdev: what are you asking, that we combine all of these patches?
16:23:26 <jroll> Sukhdev: I will not optimize the git tree to make it easier for people to patch on top of upstream
16:23:42 <jroll> I will rather optimize it for ease of review and sensible chunks, as we've always done
16:23:57 <jroll> if we combine everything, it will take exponentially longer to review upstream
16:24:05 <Sukhdev> jroll : I do not think that will be possible - but, if any of these (less risky) to land
16:24:23 <sambetts> we need to rebase the tree of patches on top of the new network interface patches, and abandon the original network provider one right?
16:24:33 <sambetts> then you just need to install the top of the tree to test it
16:24:47 <jroll> Sukhdev: there's really only two patches remaining, both touch the REST API, I'd rather not land either in mitaka
16:24:50 <jroll> sambetts: yes, we do
16:25:54 <devananda> Sukhdev: rather than change the review process / squash patches upstream, if you are going to recommend to customers to patch on top of mitaka, i would suggest the following
16:25:55 <Sukhdev> jroll : understood
16:26:37 <devananda> you maintain a branch somewhere that combines all the patches in the right order, and runs a CI job on them
16:27:57 <Sukhdev> devananda : yup
16:28:18 <Sukhdev> jroll : when will Newton open up for business?
16:29:15 <jroll> Sukhdev: when we release the final version of ironic and create the stable/mitaka branch, which should be around april 1
16:29:23 <jroll> likely before april 1
16:29:25 <jroll> AIUI
16:29:26 <devananda> Sukhdev: to be clear, I'm not actually suggesting that be done for wide use. it's going to potentially break compatibility when we land those patches, eg. if they end up using a different API revision #, or some other change comes in in the meantime.
16:29:47 <jroll> devananda: ++
16:29:53 <devananda> Sukhdev: but I agree with jroll re: not squashing all the patches in the review queue
16:31:01 <Sukhdev> jroll devananda : I am thinking, if we all feel comfortable, the we continue to test eveything with intent to merge them in N some time late april
16:31:11 <jroll> Sukhdev: +1
16:31:15 <devananda> ++
16:31:52 <Sukhdev> cool - so early adapters can pick master in april instead of dealing with all the patches
16:32:03 <jroll> yep
16:32:13 <jroll> and I expect we'll make a release shortly after landing those
16:32:19 <jroll> once we're confident with it
16:32:34 <Sukhdev> this gives us whole release cycle to fix the bugs
16:32:50 <Sukhdev> jroll : I think I can sell that :-):-)
16:33:40 <jroll> :)
16:34:39 <Sukhdev> Any thing else on this?
16:35:35 <Sukhdev> lazy_prince is gone - he wanted to me add a topic on the agenda to discuss
16:36:06 <Sukhdev> killer_prince : oh I see you switched the handle
16:36:34 <Sukhdev> #topic: genric switch discussion
16:36:41 <Sukhdev> killer_prince : You asked this to be added to the agenda
16:36:49 <killer_prince> sorry about switching the handle..
16:36:54 <killer_prince> yes..
16:36:54 <Sukhdev> killer_prince :floor is yours
16:37:17 <killer_prince> okay.. so I wnated to check what is the direction for ironic..
16:37:44 <killer_prince> is the way going forward to use genericSwitch driver for network isolation..?
16:37:56 <jroll> that's an ML2 mechanism, right?
16:38:09 <killer_prince> I see, its being updated for Cisco switches etc..
16:38:13 <killer_prince> yup..
16:38:34 <jroll> so from an ironic perspective, I don't really care what ML2 thing folks use, and ironic shouldn't care either :)
16:38:34 <Sukhdev> jroll : actually it is a more of a switch with ML2
16:38:54 <Sukhdev> #link: https://github.com/jumpojoy/generic_switch
16:38:59 <jroll> Sukhdev: rephrased, "that's a neutron plugin thing, right?"
16:39:02 <devananda> Sukhdev: can you elaborate on what you mean by "a switch with ML2" ?
16:39:24 <devananda> is this an ML2 plugin, or a mech driver that one uses instead of ML2 ?
16:39:37 <jroll> it looks like an ML2 plugin to me
16:39:45 <Sukhdev> I think it uses ML2 driver
16:39:55 <killer_prince> so should all vendors be updating the GenericSwitch driver for supporting their switches..?
16:40:12 <Sukhdev> killer_prince : no
16:40:22 <jroll> killer_prince: I don't think anyone on the ironic side is in a place to say such a thing
16:40:35 <jroll> it's really up to the vendors, as I see it
16:40:47 <Sukhdev> killer_prince : the way I see it is for like devtest type of testing - not for production deployments
16:40:51 <vdrok> btw its in openstack now - https://github.com/openstack/networking-generic-switch
16:40:57 <jroll> I think GenericSwitch is kind of neat, I'd like it if my vendor supported it (though we don't use ML2 downstream anyway)
16:41:32 <devananda> "ML2 Mechanism driver from ML2 plugin" << from the readme. this is very confusing wording
16:41:39 <sambetts> Looking through it real quick it seems like it is basicaly an SSH ML2 Mech driver
16:42:19 <Sukhdev> devananda : ML2 plugin is the core plugin in neutron
16:42:38 <devananda> vdrok: can this work in the same neutron network environment as OVS or OVN virtual networking?
16:42:54 <Sukhdev> Our Ironic-neutron integration is designed to work with ML2 plugin
16:42:59 <devananda> iow, with this GenericSwitch driver, can I mix bare metal and virtual machine tenant networking?
16:43:15 <jroll> sambetts: yeah, that's what it looks like to me, and pluggable with other switch mechanisms
16:43:26 <vdrok> I'm not sure, it's better to ask vsaienko
16:43:36 <jroll> devananda: you can stack ML2 mechanisms and have different mechanisms take action on different requests
16:44:04 <Sukhdev> jroll : +1
16:44:17 <devananda> cool
16:44:34 <Sukhdev> devananda : so, you can use generic switch ML2 driver for BM and OVS diver for VM
16:44:35 <devananda> in the past, I've heard folks use the term "mech driver" to refer to things which can not be used alongside ML2
16:44:52 <devananda> thanks for the clarification here
16:45:07 <Sukhdev> devananda : mech driver is another name for ML2 driver :-)
16:45:33 <selvakumar_s> Sukhdev: but again this driver supports only cisco switches for BM
16:45:34 <Sukhdev> ML2 driver can consist of Type driver + mech driver
16:45:39 <sambetts> We (Cisco) are planning on maintain our own Cisco Mech drivers that will support the baremetal vnic along side our other OpenStack support, we aren't involved with the development of this Generic Driver
16:46:07 <devananda> this looks like a useful tool for testing, and for users who want to hack out support for their switches, if their switch vendor hasn't provided it yet via other means
16:46:14 <killer_prince> is it the same with other vendors as well..?
16:46:25 <Sukhdev> selvakumar_s : I think mirantis folks developed it - It is my understanding that they only had Cisco switches
16:46:31 <jroll> yeah, I think it's valuable, I think vendor-specific ML2 things are also valuable
16:46:43 <devananda> also, this file needs a license header: https://github.com/jumpojoy/generic_switch/blob/master/generic_switch/generic_switch_mech.py
16:46:57 <devananda> *doesnt this file ... ?
16:47:17 <jroll> devananda: https://github.com/openstack/networking-generic-switch/blob/master/generic_switch/generic_switch_mech.py
16:47:17 <vdrok> devananda, https://github.com/openstack/networking-generic-switch/blob/master/generic_switch/generic_switch_mech.py :)
16:47:21 <jroll> heh
16:47:32 <vdrok> :D
16:47:40 <devananda> ah
16:48:02 <Sukhdev> #link: https://github.com/openstack/networking-generic-switch/blob/master/generic_switch/generic_switch_mech.py
16:48:05 <devananda> thanks :)
16:48:10 <jroll> devananda: and the last commit there indicates ovs support
16:49:08 <sambetts> sounds like they are reinventing ML2 underneith ML2
16:49:36 <jroll> plugins all the way down :)
16:50:34 <Sukhdev> folks - I do not see this as a production deployable solution - but, as a testing system - so, buyer be aware :-)
16:51:40 <Sukhdev> killer_prince : hope you are more confused than before :-):-)
16:51:42 <killer_prince> yeah.. so just coz it was meant to help ironic test the code in CI.. should we limit it to that..? or should we try to extend it further for production..?
16:52:01 <selvakumar_s> Sukhdev: I agree with you , it only implements the bind_port . it does not implement rest of the Ml2 Mechanism driver abstract methods..
16:52:02 <killer_prince> or we stop the discussion here only..
16:52:28 <jroll> killer_prince: I don't think any of us can really say whether vendors should contribute to that, honestly
16:52:57 <Sukhdev> killer_prince : It is a tool - if, it helps you, by all means use it - but, telling customers to use it in production, who is going to support it or stand behind it?
16:53:20 <Sukhdev> jroll : +1
16:53:45 <killer_prince> okay.. I thought, it was meant for Ironic and Ironic will decide its future.. guess, I may wrong..
16:54:17 <killer_prince> nm.. we can move on....
16:54:34 <Sukhdev> #topic: Open Discussion
16:54:45 <Sukhdev> selvakumar_s : did you want to discuss anything?
16:55:07 <selvakumar_s> Sukhdev: regarding the VLAN aware BM , just raised HPE comments just now
16:55:09 <Sukhdev> I saw your email indicating that you wanted to contribute to this project
16:55:24 <hshiina> hi. do we need submit a spec for nova's patch in Newton?
16:56:06 <hshiina> i hope nova's patch will be merged early for LAG featrue.
16:56:07 <Sukhdev> hshiina : there is spec in nova and neutron for it already and sambetts submitted one for Ironic
16:56:38 <jroll> hshiina: yeah, we may need to resubmit, but I will take care of that
16:56:51 <hshiina> thanks.
16:56:56 <sambetts> selvakumar_s: Thanks for the comments :)
16:57:12 <selvakumar_s> Sukhdev:yes we have come up with some block diagram for ironic + neutron integration , we thought we can keep in some wiki page
16:57:25 <selvakumar_s> Sukhdev: I will send it to you for review with pdf version
16:57:32 <selvakumar_s> sambetts: Thanks
16:58:05 <Sukhdev> selvakumar_s : can you post on the top of this wiki - https://wiki.openstack.org/wiki/Meetings/Ironic-neutron
16:58:24 <selvakumar_s> Sukhdev: sure I will post it.
16:58:48 * Sukhdev time check 2 min
16:59:02 <Sukhdev> Anything else?
16:59:43 <killer_prince> nothing from me..
16:59:55 <sambetts> nothing from me :)
17:00:00 <jroll> thanks y'all :)
17:00:01 <Sukhdev> looks like we are done - whole one min. ahead of schedule
17:00:07 <killer_prince> :)
17:00:09 <Sukhdev> thanks
17:00:15 <sambetts> Thank everyone
17:00:16 <Sukhdev> bye
17:00:20 <killer_prince> bye all..
17:00:20 <Sukhdev> #endmeeting