16:00:42 <Sukhdev> #startmeeting ironic_neutron
16:00:42 <openstack> Meeting started Mon Jun  1 16:00:42 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:45 <yushiro> Hi, all
16:00:47 <openstack> The meeting name has been set to 'ironic_neutron'
16:00:48 <lauramoore> hi Sukhdev
16:00:54 <BertieFulton> Hi folks
16:00:56 <Sukhdev> Hello everybody
16:01:01 <jlvillal> o/
16:01:02 <rameshg87> o/
16:01:18 <jroll> \o good morning
16:01:22 <lazy_prince> o/
16:01:23 <Sukhdev> #topic: Agenda
16:01:28 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron
16:01:44 <Sukhdev> #topic: Announcements:
16:02:04 <Sukhdev> Welcome to our first kick off meeting for Neutron-Ironic Integration
16:02:04 <viveknarasimhan> good morning everybody
16:02:10 <sambetts> o/
16:02:28 <dtantsur> o/
16:02:28 <Sukhdev> I would like to kick start with introduction -
16:02:41 <clif_h> o/
16:02:48 <mariojv> o/
16:02:53 <Sukhdev> I am Sukhdev - have been very active in the neutron side
16:03:11 <Sukhdev> I have jroll with me who is active on the Ironic/Nova side
16:03:20 <jroll> ohai
16:03:39 <jroll> devananda won't make this one, correct?
16:03:39 <Sukhdev> devananda is traveling and will not be joining us today - but, he will be regular as well
16:04:10 <rsacharya> This is Srinivas, interested in bare-metal networking. My team works on Ironic.
16:04:38 <Sukhdev> rsacharya: welcome and thanks for the intro
16:04:43 <viveknarasimhan> I am viveknarasimhan
16:04:54 <viveknarasimhan> have been active in Neutron for juno and kilo
16:05:03 <viveknarasimhan> interested in ironic-neutron integration
16:05:06 <jlvillal> I am the Ironic liaison to Nova.  Want to hear if anything impacts Nova as far as Ironic is concerned.  But will defer to jroll for most of it.
16:05:07 <lazy_prince> I am lazy_prince from HP and I have some interest in this. I have little exp with Neutron but I was able to port ironic neutron plugin to ML2 extension driver..
16:05:32 <rameshg87> this is ramesh, i work on the ironic side for HP. interested in ironic-neutron integration too :)
16:06:04 <Sukhdev> Thanks folks
16:06:05 <stendulker> stendulker: This is Shiv, I work on the ironic side of HP
16:06:23 <dtantsur> this is Dmitry, I am working on ironic-inspector (former discoverd) which may be of use for figuring out network properties
16:06:33 <Sukhdev> I m sure we have lot more people here - don't be shy, please introduce yourself to the team
16:06:47 <yushiro> I am Yushiro at Fujitsu and work in neutron and fwaas.  We're very interested in integrating neutron and ironic.
16:06:55 <lauramoore> I am Laura Moore, have been working with Bertie Fulton and Sukhdev on the Ironic-Neutron ML2 integration, but rather new to OpenStack contributions
16:07:14 <BertieFulton> Bertie from SAP here. I've been working with Sukhdev on initial PoCs of Ironic/ML2 integration. Also working on a draft spec for some of this.
16:07:16 <mitchj> I'm Mitchell, I work at Arista with Sukhdev
16:07:51 * Sukhdev waiting for the intros to be over
16:08:06 <jroll> clif_h and morgabra are here from my team at rackspace; morgabra has done a ton of awesomeness in our downstream version of all of this, and clif_h is going to be jumping in to help with all of this as well
16:08:25 <jroll> Sukhdev: let's timebox to 16:10?
16:08:52 <Sukhdev> jroll: 16:10?
16:09:06 <jroll> Sukhdev: be done with intros at 16:10
16:09:08 <jroll> UTC
16:09:20 <jroll> e.g. 30 more seconds by now :P
16:09:24 <Sukhdev> jroll: Oh I see
16:09:39 <jroll> or just move on now :P
16:09:50 <Sukhdev> #topic: Discuss team Goals
16:10:12 <Sukhdev> Folks I am sure you have had a chance to look at the wiki that I put together
16:10:34 <Sukhdev> I tried to list three main goals under the team charter
16:10:35 <lazy_prince> yup...
16:11:10 <Sukhdev> BertieFulton and lauramoore are working on spec for the physical connectivity
16:11:38 <Sukhdev> I was Hoping to have that release before this meeting - but, it needs some more work
16:11:49 <jroll> "initial charter will not cover: Automated discovery of the ports physical connectivity" -- I think we can do this in parallel, if we let it just be covered by discoverd^Winspector
16:11:58 <Sukhdev> BertieFulton: do you want to mention when do you think it will be ready?
16:12:01 <jroll> Sukhdev: BertieFulton I'd love to see the work-in-progress version of that
16:13:33 <dtantsur> jroll ++ I can keep an eye on it
16:13:37 <Sukhdev> jroll: correct, we are not including discovered as part of this team's charter - but, anybody with the expertise in that area, feel free to work in parallel with us
16:13:41 <BertieFulton> Should be able to oblige. It is missing some of the many sections but I'm working on it
16:14:00 <jroll> dtantsur: I figure once we define where the data lives, you can just do it. IPA has lldp code you can steal :)
16:14:09 <dtantsur> cool, will do
16:14:14 <Sukhdev> BertieFulton: Look forward to WIP version of the patch
16:14:48 <BertieFulton> jroll: would you rather it was up and (very) incomplete to get feedback on the ideas? Or had some more depth?
16:15:09 <Sukhdev> The second goal is to figure out the network flip logic
16:15:56 <Sukhdev> We want to do it with as little impact to nova as possible
16:15:57 <jroll> BertieFulton: I would look at a very incomplete version, yes :)
16:16:19 <viveknarasimhan> <Sukhdev> the spec by BertieFulton would detail changes to the Port resource that Neutron will consume?
16:16:24 <lazy_prince> I think the network flip logic has been put up by rackspace guys as ironic bp.. right..
16:16:35 <Sukhdev> viveknarasimhan: yes
16:16:42 <viveknarasimhan> Thanks Sukdhev
16:16:55 <jroll> lazy_prince: yes, but it needs to be redone and made better
16:17:21 <jroll> lazy_prince: e.g. move from kilo -> liberty and fix some things
16:17:24 <viveknarasimhan> jroll:  Let us put out a WIP and improvise
16:17:41 <lazy_prince> +1
16:17:48 <jroll> sure thing
16:18:00 <Sukhdev> jroll: will you be willing to work with the author to bring it up-to-date?
16:18:09 <Sukhdev> jroll: shall I assign you an action?
16:18:13 <jroll> Sukhdev: the author is a bit of a jerk
16:18:18 <jroll> (I'm the author)
16:18:27 <jroll> yes, assign away!
16:18:27 <Sukhdev> jroll: ha ha -
16:19:00 <Sukhdev> #action: jroll to bring the network flip logic spec up-to-date and publish the new version
16:19:12 <jroll> Sukhdev: I want to see BertieFulton's ironic spec and see what sort of overlap etc is happening
16:19:38 <jroll> so we don't write the same thing
16:19:56 <Sukhdev> jroll: BertieFulton is specifying the contents of the physical connectivity dict - your spec will discuss the flip logic
16:19:57 <BertieFulton> jroll: I'm trying to avoid overlap for the flip and reference your spec.
16:20:03 <jroll> awesome.
16:20:13 <jroll> sounds good
16:20:26 <Sukhdev> The third item is CI -
16:20:51 <lazy_prince> jroll: If you need a hand on to complete the network flip spec, you can put me there..
16:20:56 <Sukhdev> It is bit early for that, but, want to shout out for the experts in this area - so that we can kick off work in this regard as well
16:21:17 <Sukhdev> lazy_prince: that is nice - thanks
16:21:20 <jroll> lazy_prince: cool, ty
16:21:55 <jroll> so for CI -- I see us needing an ovs implementation of this stuff
16:22:01 <Sukhdev> If anybody wants to jump in and offer help - we are all ears :-)
16:22:37 <jroll> and I think we can make this model the default; just use the same network for provisioning and tenant etc. once that all lands we can update CI to actually use different networks
16:23:08 <Sukhdev> jroll: that is a good way to go
16:23:15 <lazy_prince> would that mean updating the ovs mech driver..?
16:23:22 <Sukhdev> jroll: Build as you go -
16:23:38 <Sukhdev> lazy_prince: probably not
16:24:15 <lazy_prince> so you mean the existing ovs mech driver itself will work..? i am not sure..
16:24:38 <viveknarasimhan> lazy_prince : existing ovs mech driver won't work
16:25:00 <viveknarasimhan> lazy_prince:  we need to enhance OVS to handle the additional port attributes passed in by Ironic
16:25:05 <Sukhdev> lazy_prince: not sure - just guessing we may have to build logic around it
16:25:08 <lazy_prince> i am unable to look at the full picture in absence of a bp...
16:25:33 <viveknarasimhan> Sukhdev: is it necessary to support OVS for CI
16:25:58 <Sukhdev> lazy_prince: perhaps we can delay this discussion until we have a little better picture -
16:26:00 <jroll> viveknarasimhan: yes, unless someone is going to donate real switches :)
16:26:24 <jroll> (which still might be a good thing as a second step)
16:26:38 <Sukhdev> I wanted to bring this up so that experts in CI area can start to think
16:26:51 <lauramoore> so maybe seeing the specs together will help in this regard
16:27:06 <lauramoore> sukhdev, have you also been working on the neutron spec?
16:27:11 <lazy_prince> lauramoore: +1
16:27:27 <viveknarasimhan> Sukhdev:  we will discuss CI strategy for this change with armax and kyle
16:27:49 <Sukhdev> lauramoore: no we decided neutron spec may not be needed
16:28:05 <Sukhdev> viveknarasimhan: we can use all the help :-)
16:28:20 <Sukhdev> Lets move on
16:28:22 <viveknarasimhan> Sukhdev:  a neutron spec would be helpful
16:28:51 <viveknarasimhan> Sukhdev: and might be required , since they may consider this as API change for Port entity
16:29:09 <Sukhdev> viveknarasimhan: neutron proposal as was presented at the summit - which everybody approved, does not require any change to the neutron core
16:29:24 <Sukhdev> viveknarasimhan:hence, we felt there was no need to write a spec
16:29:40 <viveknarasimhan> Sukhdev: I agree with what we discussed, but still capturing it as a spec would be useful
16:29:45 <BertieFulton> Sukhdev: so because of the binding:profile I agree we need no API changes - is there no need to specigy in a spec what will be in the binfing profile?
16:29:54 <BertieFulton> *specify
16:30:04 <BertieFulton> *binding
16:30:14 <Sukhdev> If you review the proposal in the etherpad, we are using binding.profile - which is not an API change
16:30:24 <BertieFulton> Sukhdev: or is the Ironic spec sufficient?
16:30:35 <lazy_prince> we need to specify so that there is consistency...
16:30:55 <viveknarasimhan> BertieFulton:  yes we should specify what goes in binding.profile
16:31:04 <Sukhdev> BertieFulton: yes, we should specify in the spec -
16:31:10 <jroll> ironic spec seems sufficient to me -- there may end up being a small nova spec but am not sure
16:31:18 <Sukhdev> BertieFulton: we can refer to the etherpad as well
16:31:42 <viveknarasimhan> Sukhdev: i concur if you all feel so
16:32:06 <Sukhdev> jroll: depending upon the network flip logic - i.e. how we decide to do, may require nova spec - but, I do not believe at this moment that we need one
16:32:11 <Swami> Sukhdev: if there is a dependency to nova, should we not capture it in a spec.
16:32:40 <viveknarasimhan> rsacharya: do you have concerms?
16:32:48 <Sukhdev> Swami: let jroll update the spec - I think this can be specified in ironic spec itself
16:32:55 <jroll> Sukhdev: right, I've been chatting with dansmith about it. will probably depend on the changes. we'll need some solid doc to point at, at the very least, ironic spec may be enough
16:33:07 <lazy_prince> if we could get access to the early version of the spec, that would make things move fast and bring everyone on the same page...
16:33:16 <Swami> ok, just making sure that the dependency should be captured in one or the other spec.
16:33:38 <Sukhdev> jroll, BertieFulton : when do you think will be in a position to post the updated spec?
16:33:59 <jroll> Sukhdev: I'll try to get something by the end of the week
16:34:30 <lauramoore> we will aim for end of the week too
16:34:34 <Sukhdev> cool - in that case, lets review both of these specs and we can decide in next meeting - if we need additional specs to not
16:34:56 <lazy_prince> by nova change, do we also mean change in ironic virt driver in nova..?
16:35:06 <jroll> yes
16:35:17 <jroll> (if it's needed, may not be)
16:35:55 <lazy_prince> probably, it will be needed if we want to take full control of networking in ironic..
16:36:08 <jroll> agree
16:36:50 <Sukhdev> anything else on the spec issue?
16:37:27 <BertieFulton> Sukhdev: I have a technical question to throw out there if it is a suitable time?
16:37:45 <viveknarasimhan> Sukhdev:  so 2 specs , one for Ironic Port API (with phys conn) and other is network flip
16:37:46 <Sukhdev> BertieFulton: go ahead please
16:37:56 <jroll> viveknarasimhan: correct
16:38:01 <Sukhdev> viveknarasimhan: yes
16:38:06 <viveknarasimhan> Thanks
16:38:46 <BertieFulton> Do we want to bring any of these concepts into a flavor for node selction on the first pass of this?
16:39:18 <BertieFulton> for example - aggregating ports gives us certain redundancy capabilities or extra bandwidth
16:39:48 <BertieFulton> my initial thoughts were to aim for connectivity first but Laura said there may have been some discussion around flavors at the summit
16:40:38 <jroll> BertieFulton: my inclination is not in the first version, but I could be persuaded otherwise. I vote connectivity first and go from there
16:40:51 <Sukhdev> BertieFulton: This is a good point, but, I would like to limit the charter to get first pass working first
16:41:09 <BertieFulton> jroll +1 Sukhdev +1
16:42:00 <viveknarasimhan> jroll +1
16:42:01 <lazy_prince> +1.  we need to make it work for a single net first..
16:42:03 <Sukhdev> I will put this on the wiki - so that we do not forget about it - for the long term
16:42:47 <Sukhdev> Anything else, before we move on?
16:43:12 <Sukhdev> #topic: Nova/Neutron interaction discussion
16:43:37 <Sukhdev> jroll: posted a poc patch - https://review.openstack.org/#/c/186855/
16:43:51 <Sukhdev> to elaborate a thought process -
16:43:54 <jroll> right, so backing up a bit.
16:44:03 <jroll> there's basically two options we have here:
16:44:26 <Sukhdev> #link: https://review.openstack.org/#/c/186855/
16:44:49 <jroll> 1) modify the neutron api to have a parameter do declare whether or not to plumb the network immediately. default to true. set it to false when provisioning bare metal ports during the build process, so we don't connect them until the build is done
16:45:36 <jroll> (and when build is done, port-update from ironic to set that to true)
16:46:20 <jroll> 2) modify the nova build process to not send enough info to plumb the networks. port goes into binding failed state. send the info later from ironic to allow the port to bind correctly.
16:46:29 <jroll> both take some work
16:46:41 <jroll> (1) is what we do today at rackspace, via an extension
16:47:14 <BertieFulton> jroll: Does 1) need an update? We will be specifying an ironic port in the binding:profile, no?
16:47:32 <Sukhdev> jroll: I reviewed the patch and posted my comments on it
16:47:49 <Sukhdev> BertieFulton: not in 1)
16:47:54 <jroll> BertieFulton: ironic would only call port-update to flip that bit, to tell neutron to plumb the things
16:48:02 <jroll> BertieFulton: unless you mean something else by 'update'
16:48:13 <BertieFulton> I mean an update to the API
16:48:22 <jroll> Sukhdev: I responded in that patch, the other patch you reference posts extra info, but doesn't remove the binding info
16:48:40 <BertieFulton> but yes agreed it needs to flip something
16:48:53 <jroll> which api?
16:49:13 <jroll> it requires an update to the neutron api to accept a parameter that says "don't plumb this through yet"
16:49:57 <jroll> but I don't believe it requires ironic api updates
16:50:00 <viveknarasimhan> jroll:  the flag you mention is 'commit' in your review
16:50:03 <Sukhdev> if we go with 1) neutron has to be changed, if we go with 2) neutron does not require any changes
16:50:12 <Sukhdev> viveknarasimhan: yes
16:50:13 <jroll> probably will need to modify plug_vifs in the virt driver
16:50:27 <jroll> Sukhdev: yes, but (2) is much more invasive nova-side
16:50:44 <jroll> morgabra: would love your eyes on all of this ^
16:50:46 <BertieFulton> jroll: I think it could use the binding:profile - but I think it needs an update to tell it to go plumb it after - so I think I'm in agreement
16:51:07 <viveknarasimhan> Sukhdev: If (1) is a low hanging fruit, we can go for it for now
16:51:09 <jroll> BertieFulton: oh! not a bad idea
16:51:22 <jroll> BertieFulton: and then the update you mention could just be in the ML2 thing, right?
16:51:31 <viveknarasimhan> Sukhdev: and then work out (2) since (2) is changes to nova mostly and not neutron
16:51:46 <jroll> BertieFulton: I like your thinking
16:51:49 <BertieFulton> jroll: possibly - I'll defer to Sukhdev
16:51:53 <viveknarasimhan> yes BertieFulton
16:52:17 <BertieFulton> jroll: I'm slightly scared of making definitive statements on Neutron :)
16:52:25 <jroll> indeed :)
16:53:06 <jroll> I like the sound of {binding_profile: {bind: False, ...}}
16:53:10 <Sukhdev> jroll, BertieFulton: The way i was thinking is that we use binding.profile - if the connectivity information is passed, it will plumb the network, if the information is not passed, it will not plumb the network
16:53:13 <jroll> or something like that
16:54:16 <Sukhdev> we are all essentially meaning the same thing, but, using different semantics :-)
16:54:24 <jroll> indeed, I think so :)
16:54:37 <lazy_prince> my opinion is to use a flag rather than not passing info..
16:54:56 <jroll> I think I like a mix of both.
16:54:57 <Sukhdev> We can keep neutron out of picture by using binding.profile - one less approval level to worry about :-)
16:55:06 <jroll> nova passes the info nova knows, tells neutron don't bind it yet
16:55:11 <jlvillal> 5 minutes left
16:55:15 <jroll> ironic passes the rest of the info, that only ironic knows
16:55:18 <jroll> and tells neutron to bind it
16:55:36 <morgabra> I prefer passing a flag in binding:profile as well
16:55:40 <lazy_prince> jroll: +
16:55:42 <Sukhdev> jlvillal: thanks for heads up
16:55:43 <lazy_prince> 1
16:55:46 <morgabra> because if you rely on bind_failed state, you don't know if it's actually broken
16:56:00 * jroll nods
16:56:38 <jroll> is anyone against a flag in binding:profile, nova passes what it knows, ironic passes what it knows (switchport etc)?
16:56:49 <Sukhdev> I think we can make it work by adding a flag, along with connectivity information as well - so, mix of both
16:57:11 <Sukhdev> This puts the work on ML2 driver (instead of neutron core) - which will be easy to get approved
16:57:16 <jroll> yep
16:57:17 <BertieFulton> jroll: I'm happy with a flag for clarity
16:57:58 <Sukhdev> BertieFulton jroll : can you specify this flag in your specs?
16:58:03 <jroll> of course
16:58:07 <jroll> and I'll update that poc
16:58:08 <Sukhdev> we are running out of time
16:58:10 <BertieFulton> yep
16:58:19 <lazy_prince> if time permits, would like to discuss about switch details within/outside neutron db
16:58:22 <Sukhdev> #topic: Open Discussion
16:58:32 <Sukhdev> anything on anybody's mind?
16:58:34 <jroll> lazy_prince: shoot
16:59:19 <lazy_prince> to me, it makes more sense to keep the switch info (creds etc ) within neutron db..
16:59:50 <Sukhdev> lazy_prince: there will be no creeds - only physical connectivity info
17:00:00 <lazy_prince> this way, we could follow a uniform way for all mech drivers..
17:00:02 <Sukhdev> lazy_prince: switch id, port id, etc
17:00:18 <jroll> Sukhdev: somehow the mechanism will need to be able to configure the switch
17:00:19 <viveknarasimhan> Sukhdev: lazy_prince is quoting information about Switch stored out of band
17:00:35 <jroll> we're out of time... perhaps move to neutron channel?
17:00:56 <BertieFulton> thanks everyone
17:00:56 <jroll> or ironic channel should be free, ironic meeting is now
17:01:00 <jroll> thank you everybody!
17:01:04 <lazy_prince> or next meeting.. we dont have to finalize everything in this meeting only..
17:01:09 <Sukhdev> Thanks folks, this was very good discussion -
17:01:13 <Sukhdev> #endmeeting