16:00:48 <Sukhdev> #startmeeting ironic_neutron
16:00:50 <openstack> Meeting started Mon Sep 28 16:00:48 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:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:53 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:12 <Sukhdev> Good morning folks
16:01:19 <lazy_prince> 0/
16:01:58 <Sukhdev> #topic: Agenda
16:02:00 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_September_28.2C_2015
16:02:23 <Sukhdev> please have a look at the agenda and feel free to add anything
16:02:34 <Sukhdev> jroll: are you here?
16:02:38 <jroll> morning :)
16:02:50 <Sukhdev> #topic: Announcements
16:03:19 <Sukhdev> We have a new sheriff in town
16:03:34 <Sukhdev> jroll is new PTL for Ironic
16:03:47 <jroll> :)
16:04:04 <Sukhdev> Welcome and congratulations to jroll and thanks for his great to devananda
16:04:14 <lazy_prince> Congrats jroll
16:04:18 <jroll> thanks :D
16:04:56 <cragusa> congratulations!!
16:05:07 <Sukhdev> jroll: would you like to announce anything?
16:05:31 <jroll> ironic is open for mitaka development
16:05:42 <jroll> as such, I removed my -2 on the patches for this project
16:06:13 <Sukhdev> does this mean Liberty is done and out?
16:06:33 <jroll> well, we released 4.2.0 and cut stable/liberty branch from there
16:06:55 <jroll> liberty final is in a couple of weeks, if we have any backports between now and then we'll release 4.2.x and that will be liberty final
16:07:32 <Sukhdev> cool - thanks for the update
16:07:38 <jroll> but as far as the neutron/ironic integration things are concerned, development is wide open
16:08:07 <Sukhdev> got it
16:08:11 <Sukhdev> anybody has any other announcement?
16:08:36 <Sukhdev> Lets dive into the agenda then
16:08:46 <Sukhdev> #topic: Integration Status
16:09:02 <Sukhdev> I added additional like at the bottom of the etherpad -
16:09:29 <Sukhdev> I noticed that create_port() request to Neutron does not have device_id and device_owners
16:09:36 <Sukhdev> ML2 drivers needs this
16:09:50 <jroll> ah
16:09:58 <Sukhdev> this is usually set by nova - now ironic has to do it
16:10:06 <jroll> so I think device_id should probably be the ironic node uuid, without knowing what device_id is actually for :)
16:10:29 <Sukhdev> jroll: yes, that is correct - that is what I have set it to
16:10:39 <jroll> and device_owner I presume would be the admin user ironic runs with
16:10:45 <lazy_prince> okay.. will update it as needed..
16:10:58 <Sukhdev> and device_owner is compute:none
16:11:06 <Sukhdev> where none is zone -
16:11:13 <jroll> oh.
16:11:17 <jroll> maybe baremetal:?
16:11:28 <jroll> since the bare metal service owns it, really
16:11:30 <Sukhdev> we can replaced with actual zone
16:11:39 <Sukhdev> I thought about baremetal as well -
16:12:20 <jroll> I'm not sure what to do with the zone; ironic doesn't really have that concept today
16:12:31 <Sukhdev> with this modification, I was able to see ML2 drivers pushing the Ironic config to the HW
16:12:44 <jroll> \o/
16:12:56 <Guest4568> Hi Sukhdev,
16:13:04 <Sukhdev> Guest4568: hi
16:13:13 <Guest4568> I'm am siva
16:13:30 <Sukhdev> in that case we can use "compute:none"
16:13:40 <Guest4568> Were you able to pass binding profile information for port aggregation as well?
16:14:32 <jroll> Sukhdev: is there any reason not to use 'baremetal:none' there?
16:14:36 <Sukhdev> Guest4568: no - I am not testing port aggregation yet - single port test so far
16:14:55 <Guest4568> what about LLDP?
16:15:14 <lazy_prince> lldp was not planned for the first cut..
16:15:15 <Sukhdev> jroll: Ironic is compute as well - hence, it has to start with compute
16:15:15 <jroll> LLDP isn't in the scope of this
16:15:32 <Guest4568> ah ok
16:15:39 <Sukhdev> we can use the second part as baremetal  - i.e. "compute:baremetal" or compute:none
16:15:42 <jroll> Sukhdev: ironic is the openstack baremetal service, nova is the openstack compute service, baremetal makes sense to me from that perspective
16:15:50 <jroll> "the owner of this port is the baremetal service"
16:16:01 <jroll> keep in mind I'm not sure what this is used for in a neutron context :)
16:16:50 <Sukhdev> this represents in neutron the port owner - such as compute, dhcp , router
16:17:11 <jroll> hm
16:17:17 <devananda> Sukhdev: ironic is "compute" in as much as openstack has three kinds of resources (compute, network storage) -- but it does not register with keystone as "compute" service
16:17:17 <Sukhdev> neutron does not have concept of baremetal  - it know compute
16:17:18 <lazy_prince> well.. I am fine with compute:baremetal
16:17:36 <jroll> we can go with compute at the moment and check with neutron folks later if compute or baremetal makes sense
16:18:05 <Sukhdev> jroll: makes sense - I can bring it up in neutron core meeting for a comment
16:18:14 <jroll> perfect, ty
16:18:40 <Sukhdev> for now - just to make forward progress, I am using compute:none
16:19:13 <Sukhdev> Others have any update on the integration?
16:19:51 <Sukhdev> devananda: thanks for clarifyining that distinction
16:20:12 <Sukhdev> I have one more new item on the agenda to discuss
16:20:21 <Sukhdev> this is related to integration as well
16:20:50 <Sukhdev> #topic: Tenant IDs for networks
16:21:32 <Sukhdev> I noticed during integration that different tenant ID(s) are moved around in the create_port() requests
16:21:41 <Sukhdev> I thought we discuss and get it clarified
16:21:45 <Sukhdev> for example -
16:21:58 <Sukhdev> Provisioning network is created under admin
16:22:36 <Sukhdev> when a port_create() request comes to add port to this provisioning network, the tenant ID is "service tenant" - not admin
16:22:58 <Sukhdev> ML2 driver was acting up and rejecting it
16:23:33 <jroll> hmm, I wonder if we need to escalate to admin context in the code that creates that port?
16:23:58 <jroll> I should say, I know we need to, I wonder if that code doesn't do it
16:24:22 <lazy_prince> hmm.. probably, i need to look into it..
16:25:14 <Sukhdev> I was not sure what is the correct deployment scenario - hence, I thought we discuss it here
16:26:17 <Sukhdev> To keep ML2 drivers happy, I am hacking in neutron to swap the tenant ID from service to admin
16:26:42 <Sukhdev> but, I know that is not correct - but, wanted to see ML2 driver plumb the HW correctly :-)
16:26:53 <jroll> the provisioning/cleaning networks should definitely be owned by the admin in this case
16:27:35 <lazy_prince> https://review.openstack.org/#/c/139687/23/ironic/networks/neutron_plugin.py L34
16:27:39 <Sukhdev> in that case, Ironic driver needs to set the correct tenant ID in the request
16:28:02 <lazy_prince> Thats where admin context is being picked up.. not sure if its the right approach..
16:29:44 <Sukhdev> lazy_prince: I think that helps with the authentication of the API  - which seems to work, right?
16:30:11 <jroll> lazy_prince: that code looks right to me
16:30:18 <Sukhdev> however, we should check if the admin's tenant ID is present/available in that context
16:30:34 <lazy_prince> yup.. actually... it worked for me in my env.. not sure why it is not working for Sukhdev
16:30:43 <jroll> yeah, this sounds like an environment issue
16:31:17 <Sukhdev> lazy_prince: do you use tenant ID in  the ML2 driver?
16:31:19 <lazy_prince> may be we can take a look at it post meeting..
16:31:33 <jroll> ++
16:32:00 <Sukhdev> lazy_prince: will be great if you can stick around after the meeting - we can dig into this
16:32:01 <lazy_prince> yes.. I used different tenants to create the networks.. and then provisioned instances.. the prov and clean network were in admin tenant..
16:33:45 <Sukhdev> That is it from me regarding the integration effort
16:34:12 <Sukhdev> I am still waiting on the updated patch from lazy_prince to test the cleaning and switching to tenant network
16:34:54 <Sukhdev> lazy_prince: any ETA on when will you be able to push it?
16:35:41 <lazy_prince> I did push a patch today around 15mins back.. but It still has some issues.. and some were pointed by Sukhdev as device_id and device owner.. will fix them and push in a while..
16:36:11 <lazy_prince> sorry.. had some family issues last week.. hence delays..
16:36:20 <Sukhdev> lazy_prince: cool - thanks - will check it out
16:37:01 <Sukhdev> lazy_prince: with the updated patch, you are able to delete the ports, and switch to the networks, right?
16:37:56 <lazy_prince> okay.. so on that.. Sukhdev: what drivers were you using during your testing..?
16:38:20 <lazy_prince> drivers as in ironic drivers for the baremetal nodes..
16:39:03 <Sukhdev> lazy_prince: don't remember from the top of my head - is there a specific one I should be using?
16:39:44 <Sukhdev> lazy_prince: I have to file away my VM to look - but, most likely ssh pxe
16:39:46 <lazy_prince> na.. just checking if you are using agent ones or pxe ones with bash deploy images..
16:40:15 <Sukhdev> s/file/fire
16:40:22 <lazy_prince> got it.. So that part wasnt taken care of.. probably the latest patch should help..
16:41:42 <Sukhdev> lazy_prince: will send out a shout once I get to play with the latest patch
16:42:04 <lazy_prince> sure..
16:42:18 <Sukhdev> lazy_prince: do you have anything to share regarding your testing?
16:42:31 <Sukhdev> cragusa that goes for you as well
16:43:04 <lazy_prince> i believe the pxe_ssh uses iscsi based deployment.. which was missing from the patch..
16:43:15 <cragusa> uhm, I only did the documentation
16:43:21 <lazy_prince> I have added it today.. so that should help..
16:43:36 <Sukhdev> lazy_prince: cool thanks
16:43:51 <Sukhdev> cragusa:we'll cover it in next topic
16:44:10 <Sukhdev> Lets move on...
16:44:20 <Sukhdev> #topic: Action Items from previous week
16:44:41 <Sukhdev> cragusa, lazy_prince, and Sukhdev  - we all had one item each
16:45:07 <Sukhdev> I have no update - I have been busy testing ML2 inegration - did not have time to look into documentation yet
16:45:40 <cragusa> I committed my earlier on
16:45:42 <lazy_prince> I did my part to some extent.. will do rest in a bit..
16:46:02 <cragusa> let me know if that's what you were thinking
16:46:39 <Sukhdev> cragusa: can you share the link?
16:47:23 <Sukhdev> cragusa: Also, if you can add it to the etherpad - create a new section for documentation - https://etherpad.openstack.org/p/ironic-neutron-mid-cycle
16:47:38 <cragusa> sure
16:48:30 <Sukhdev> cragusa: you were going to look into this - https://review.openstack.org/#/c/206163
16:49:01 <Sukhdev> Any update on this? Do we need this? etc..
16:49:29 <jroll> why wouldn't we need that
16:49:44 <jroll> nova will need to know about the MACs for the portgroup to create the ports no?
16:50:30 <Sukhdev> jroll: probably yes - but, the logic is not correct - does not match with our design. If we need it, we need to correct it
16:50:41 <Sukhdev> somebody needs to own/take over this -
16:51:03 <Sukhdev> I have not been testing port-groups, hence, have not been hit with this yet :-):-)
16:51:38 <jroll> Sukhdev: well, we did say we were only going to support (# of networks) <= (# of port/portgroups) to start
16:51:47 <jroll> right?
16:52:39 <Sukhdev> I have to jolt my memory to answer this correctly
16:52:53 <Sukhdev> :-)
16:53:28 <Sukhdev> I think the answer to your question is - yes
16:53:45 <Sukhdev> need to refer to the spec - which Laura wrote
16:54:55 <Sukhdev> We need a new owner for this patch - as Laura is not available anymore - and clean it as appropriate
16:55:28 * Sukhdev 5 min left - I need to cover couple of items quickly
16:55:35 <Sukhdev> #topic: Open Discussion
16:56:02 <Sukhdev> jroll: A question for you - Should we have design session topic for this in Tokyo
16:56:14 <jroll> Sukhdev: is there something to design? :)
16:56:38 <Sukhdev> jroll: the next phase - discoverdd - lldp, integration etc...
16:57:01 <jroll> Sukhdev: oh, that. :) you're welcome to propose something: https://etherpad.openstack.org/p/mitaka-ironic-design-summit-ideas
16:57:37 <Sukhdev> cragusa are you up for it? I can work with you on this?
16:57:43 <jroll> Sukhdev: please do be specific as to what you want to cover, the discovery stuff may be less important to the larger ironic team
16:57:50 <Sukhdev> and anybody else who wants to join in
16:58:20 <Sukhdev> jroll: basically - automate the whole thing for the end-users
16:58:45 <Sukhdev> jroll: let me think about it - perhaps we can discuss in next week's meeting
16:58:48 <jroll> Sukhdev: not all end users use inspector :)
16:58:55 <jroll> but yes, please do outline your thoughts on the 'pad
16:59:06 <Sukhdev> jroll: another question for you -
16:59:22 <jroll> you have 30 seconds :P
16:59:32 <Sukhdev> jroll: now that mitaka is open - we need blueprint for nova so that we can get the code merged
16:59:40 <jroll> Sukhdev: yes, we do
16:59:46 <Sukhdev> jroll: can you take an action on it?
17:00:09 <jroll> Sukhdev: I can, going to be very busy the next couple of weeks though
17:00:30 <Sukhdev> Any volunteers?
17:00:50 <Sukhdev> jroll: I can do it - but, you will have to help - I am not familiar with nova policies
17:01:02 <jroll> Sukhdev: ok, let's chat later on it
17:01:06 <Sukhdev> we are out of time -
17:01:15 <Sukhdev> thanks folks - great discussion
17:01:18 <Sukhdev> bye
17:01:19 <cragusa> \query Sukhdev:  yhvh's messages have been ignored somehow this whole session
17:01:22 <lazy_prince> bye..
17:01:29 <Sukhdev> #endmeeting