16:01:16 <Sukhdev> #startmeeting ironic_neutron
16:01:17 <openstack> Meeting started Mon Jun 13 16:01:16 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:22 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:24 <sambetts> o/
16:01:46 <Sukhdev> lets give a minute or so for others to join
16:02:03 <amotoki> hi
16:02:12 <hshiina> o/
16:02:46 <Sukhdev> #topic: Agenda
16:02:51 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_June_13.2C_2016
16:03:01 <Sukhdev> jroll : are you here?
16:03:14 <jroll> hi!
16:03:38 <Sukhdev> #topic: Announcements
16:03:51 <Sukhdev> Anybody has any announcements for the team?
16:04:14 <Sukhdev> lets dive into the agenda -
16:04:38 <Sukhdev> #topic: Security Groups update
16:05:00 <Sukhdev> 1) I have captured the details based upon our discussion last week
16:05:16 <Sukhdev> see here - https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Security_Groups_support_for_Baremetal_Deployments
16:05:28 <Sukhdev> Feel free to update/correct
16:05:55 <jroll> quick question on this
16:06:07 <Sukhdev> jroll : sure
16:06:09 <jroll> is this going on top of the current changes, or are they being reworked to include this?
16:06:36 <Sukhdev> There will be enhancement on top of one of the patches
16:06:50 <jroll> ok cool
16:07:05 <amotoki> I think so too.
16:07:07 <jroll> who's writing the RFE? :)
16:07:32 * devananda comes in, a bit late
16:07:38 <Sukhdev> jroll : I did not know if we needed an RFE, but, I can do it -
16:07:49 <sambetts> read the update this morning, looks good :)
16:08:00 <jroll> Sukhdev: new features always need one :) thanks
16:08:06 * jroll not sure if this needs a spec or not
16:08:46 <Sukhdev> jroll : most of the work is done in the neutron side - very little on the Ironic side - which I will get into in a sec
16:09:10 <jroll> sure
16:09:26 <Sukhdev> jroll : I will write up an RFE and ping you with the pointer
16:09:30 <sambetts> we need to ensure that the doc impact of the new config options is covered
16:09:41 <jroll> thanks Sukhdev
16:09:46 <Sukhdev> sambetts : good point
16:10:13 <Sukhdev> sambetts : As a part of this modification, we can update it as well
16:10:24 <amotoki> do we need the doc impact for a new config option? the config guide is generated automatically.
16:10:44 <sambetts> amotoki: what about the install guide?
16:10:58 <amotoki> sambetts: we need the flag
16:11:11 <jroll> we should document this in the install guide, yes
16:11:23 <jroll> let's not spend precious meeting time arguing about docs :)
16:11:29 <sambetts> heh true :)
16:11:39 <Sukhdev> I meant update to this - https://review.openstack.org/#/c/228496/
16:11:44 <sambetts> I just was thinking that specs document that sort of stuff
16:11:53 <Sukhdev> this spec covers the documentation - right?
16:12:16 <jroll> sambetts: yeah, the RFE can call it out too though
16:12:21 <sambetts> Sukhdev: are we putting the sec group stuff into that spec?
16:12:58 <Sukhdev> sambetts : I was thinking - we can add a step to describe in there - yes
16:13:09 <jroll> yes, those are the docs we will update, whether it's a separate patch or not
16:14:09 <jroll> "if you wish to firewall your provisioning network, blablabla"
16:14:29 <jroll> not a big deal, can we move on to the interesting parts?
16:14:38 <Sukhdev> jroll : right - that makes sense
16:14:46 <Sukhdev> Now the update on the second part - which amotoki and I worked last week (from the neutron side)
16:15:27 <Sukhdev> When I tried pass the SG port-create from Ironic driver, neutron rejected it - "not found"
16:15:56 <Sukhdev> amotoki and I worked on it and discovered that the issue with the tenant-id
16:15:56 <amotoki> more precisely "SG not found"
16:16:32 <Sukhdev> The way devstack sets things up is as follows:
16:16:51 <Sukhdev> It creates a tenant "service"
16:17:12 <Sukhdev> when I was testing this thing, I was creating networks and SG as admin
16:17:58 <Sukhdev> and later Ironic driver sends the port-create as service tenant - hence, neutron does not find SG for service,
16:18:06 <Sukhdev> hence, the failure
16:18:18 <Sukhdev> Now, we have a question for the team -
16:18:18 <sambetts> so we need to document that the SG is created in the right tenant?
16:18:25 <devananda> Sukhdev: I've been looking at the devstack configuration around ironic's service user lately, and I think we should change a few things
16:18:28 <amotoki> the point is that security groups are only visible to a same tenant.
16:19:16 <devananda> amotoki: that makes complete sense, and implies that devstack setup should be creating a SG on both accounts
16:19:22 <jroll> sambetts: creating the networks/SGs as the user ironic runs as seems common sense, but yeah probably worth documenting
16:19:52 <amotoki> it is completely worth documented
16:20:16 <devananda> yea, we will need to document this
16:20:18 <devananda> and upate devstack
16:20:36 <devananda> fwiw, here is the change I'm proposing to our devstack plugin to adjust the service account: https://review.openstack.org/#/c/325599/5/devstack/lib/ironic
16:20:40 <Sukhdev> This is how ironic config looks - http://paste.openstack.org/show/508516/
16:22:32 <Sukhdev> #link: https://review.openstack.org/#/c/325599/5/devstack/lib/ironic
16:23:15 <Sukhdev> devananda : so, in real life deployments, I assume admins will create these n/w and SG and users will use them
16:23:23 <devananda> amotoki: IIUC, we would need to create security groups on the tenant that ironic uses to communicate with neutron, and another SG on the tenant that will run the actual "nova boot" command
16:23:53 <devananda> Sukhdev: yes. we should give them examples of how to do that
16:24:23 <Sukhdev> devananda : SG for tenant n/w works just fine - I have already tested it
16:24:23 <sambetts> Sukhdev: users shouldn't be using the SG and networks that we've setup right? they should be using their own
16:24:54 <Sukhdev> devananda : only for the provisioning n/w is the issue - as Ironic driver sends this information - for tenant n/w it comes from nova
16:25:09 <jroll> sambetts++
16:25:13 <amotoki> devananda: yes. IIUC the provisioning network is owned by 'service' tenant, so i think so.
16:25:38 <devananda> to be specific, the cloud admin will need to create a service user for Ironic, and create the provisioning & cleaning neutron networks, as well as appropriate SG on those, from within that ironic service user
16:26:05 <amotoki> that's my understanding
16:26:32 <devananda> we'll need to do that in devstack, and we also need to document it
16:26:47 <Sukhdev> devananda +1
16:26:48 <devananda> and we *also* should set up the default end-user SG in devstack, too
16:27:01 <sambetts> and those networks and sec groups shouldn't affect the nova user at all
16:27:35 <amotoki> do we need to create a default end-user SG too in devstack?
16:27:49 <sambetts> those SG are setup for us already as i understand it, it should be the same as in a VM env right
16:28:01 <amotoki> in my understanding it is a normal SG which nova uses.
16:28:05 <Sukhdev> sambetts : yes
16:28:06 <devananda> if it's the same SG that already exist -- great
16:28:50 <Sukhdev> amotoki devananda : the normal (default) SG will not work for BM servers
16:28:52 <amotoki> the 'default' SG exists by default.
16:29:07 <amotoki> Sukhdev: could you elaborate more?
16:29:46 <Sukhdev> amotoki : default SG deny everthing for ingress and allow everything on egress
16:29:55 <Sukhdev> this prevents the booting of the BM server
16:30:10 <sambetts> Sukhdev: we don't boot via network in the tenant network
16:30:52 <Sukhdev> when we issue port-create, if a default SG is used, the behavior I described above applies
16:31:07 <sambetts> we don't issue prt create for the tenant network
16:31:30 <devananda> sambetts: nova does that, right?
16:31:40 <sambetts> devananda: up
16:31:43 <sambetts> yup*
16:32:08 <amotoki> yes (or a user can create a port in advance before launching an instance)
16:32:13 <Sukhdev> sambetts : as I expained earlier - tenant n/w SG works fine (nova boot --security-group <id>)
16:32:46 <Sukhdev> amotoki : thanks for the reminder
16:33:46 <Sukhdev> just to wrap it up - the default SG will not work - we need one for provisioning n/w which allows ingress and egress premissions so the BM can PXE boot from TFTP server
16:34:33 <Sukhdev> and for tenant n/w user can define and specify in nova boot - which works just fine - when the BM boots up and is available for use
16:34:35 <amotoki> Sukhdev: confirmation: what you talk about are provisioning/cleaning networks. I think the default SG works for users.
16:35:06 <Sukhdev> amotoki : right - we are in sync
16:35:17 <amotoki> Sukhdev: yeah
16:35:46 <Sukhdev> Does this make sense to everybody? are we good with this?
16:35:56 <sambetts> and we don't need to create a custom tenant SG in devstack? the existing ones should be fine?
16:36:19 <Sukhdev> sambetts : no - we need to address that
16:36:28 <jroll> sambetts: for tenants, we'll need 'allow ssh' but I think that's default in devstack
16:36:46 <sambetts> jroll: cool, thats what I thought :)
16:36:51 <jroll> for provisioning/cleaning, we'll need allow dhcp/tftp/tcp6385
16:37:07 <Sukhdev> jroll +1
16:37:19 <amotoki> +1
16:37:19 <sambetts> *thumbs up*
16:37:27 <jroll> I really wish we'd focus on the existing work though, before we focus on security groups, etc
16:37:52 <Sukhdev> jroll : moving on to the real work - which is the next one on the agenda
16:38:15 <Sukhdev> #topic: update on integration/testing of patches
16:38:40 <Sukhdev> I have updated my test setup last week with all new patches -
16:38:44 <jroll> so as a note, grenade testing is now non-voting in the check queue as of last week - which was the major thing we wanted to block on here \o/
16:39:06 <sambetts> \o/
16:39:18 <devananda> :-D
16:39:43 * devananda is eager to revisit testing this work, now that grenade is up
16:39:45 <jroll> as a :( note, nearly everything is in merge conflict status now https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526403
16:40:02 <vsaienko> jroll, Sukhdev: I'm going to rebase patches tomorrow if you do not mind
16:40:08 <jroll> vsaienko: ++
16:40:16 <devananda> vsaienko: +1 here
16:40:19 <Sukhdev> vsaienko :+1
16:40:26 <jroll> I will review them tomorrow, this is once again highest priority for ironic now
16:40:35 * sambetts plans on pushing a new version of the nova PG patch tomorrow
16:40:45 <mjturek1> sambetts: I was actually working on that
16:40:49 <jroll> sambetts: nice, thank you
16:40:58 <mjturek1> at least rebasing it and handling the comments
16:41:07 <Sukhdev> vsaienko : I noticed couple of issues - let me explain - if we can address as part of rebase
16:41:29 <sambetts> mjturek1: Oh cool, if your on top of it then +1 I'll get reviewing then, are you handling the config_drive stuff?
16:41:50 <mjturek1> looking into it, sambetts could I ping you later about it?
16:42:03 <Sukhdev> vsaienko : so, the order in which the patches are applied has become important now
16:42:05 <sambetts> mjturek1: Sure
16:42:09 <mjturek1> thx :)
16:42:59 <Sukhdev> like I mentioned, the order in which these patches are applied has become important now
16:43:30 <Sukhdev> I ran into the issue with "network_interface" vs. "network_provider"
16:43:51 <jroll> do we still have the old one somewhere?
16:44:05 <Sukhdev> and then after spending many cycles and bugging devananda, later realized that one patch deprecates it
16:44:19 <Sukhdev> jroll : right
16:44:40 <jroll> Sukhdev: did you leave a comment on the patch?
16:44:46 <Sukhdev> vsaienko : when you rebase, can you please mark the ones that are not valid as abandoned
16:45:32 <Sukhdev> jroll : no - wanted to check with the team to make sure I was not making mistake - hence, I am bringing it up here - so, that no body else wastes time the way I did
16:45:34 <jroll> Sukhdev: which patch has the wrong value?
16:45:39 <jroll> er, wrong variable name?
16:46:28 <vsaienko> Sukhdev: I think that we moved to network_interface everywhere
16:46:38 <Sukhdev> one of these - https://review.openstack.org/#/c/317390/4/ironic/dhcp/neutron.py and https://review.openstack.org/#/c/285852/53/ironic/dhcp/neutron.py
16:47:53 <Sukhdev> So, what I was going to ask the team is that lets take out the one's are no valid anymore and mark them abandoned
16:48:24 <jroll> vsaienko: I assume https://review.openstack.org/#/c/285852/53 isn't needed, that got split up, right?
16:49:29 <sambetts> vsaienko: that looks like it still covers a large chunk of the actual logic additoon
16:49:33 <sambetts> jroll: ^
16:49:50 <jroll> sambetts: I think this is the replacement: https://review.openstack.org/#/c/285852/53
16:50:00 <vsaienko> jroll: it is needed
16:50:02 <jroll> er
16:50:06 <jroll> those are the same, wtf
16:50:08 <sambetts> ? thats the same patch
16:50:19 <jroll> ignore me :)
16:50:24 <sambetts> heh :-P
16:50:32 <sambetts> I think its just the earlier PSs
16:50:43 <sambetts> aren't broken out
16:51:07 * jroll is unclear where Sukhdev is seeing network_provider
16:51:18 <sambetts> I would like to ensure that this patch gets high priorty because it affects the nova driver work: https://review.openstack.org/#/c/325197/
16:51:36 <jroll> Sukhdev: you have this patch? https://review.openstack.org/#/c/297895/2/nova/virt/ironic/driver.py
16:51:57 <Sukhdev> jroll : to be honest, now I am confused as hell as well :-):-)
16:52:29 <jroll> good, not just me
16:52:34 <jroll> anyway, that'll get picked up in review
16:52:59 <Sukhdev> So, I was going to make a suggestion -
16:53:37 <Sukhdev> as vsaienko is going to rebase these patches, if we can mark the ones that are needed as abandoned
16:53:45 <amotoki> I think sambetts's one 325197 is important. it is related to nova work.
16:53:48 <jroll> yes, you mentioned that :)
16:54:05 <Sukhdev> and if the order matters, if we can update the comments on the patches, it will help others
16:54:58 <devananda> if the order matters, that should be reflected in the commit dependency order
16:55:06 <devananda> also, please ensure all relevant patches share the same gerrit topic
16:55:26 <devananda> I see the one by zhenguo niu that jroll just linked has the topic "master"
16:55:45 <jroll> sam linked that, but yeah
16:55:47 <sambetts> after a correct rebase you should just be able to apply the top of the tree of commits for ironic, python-ironicclient and nova and everything should then be correct
16:56:01 <devananda> sambetts: exactly
16:56:13 <sambetts> #link I would like to ensure that this patch gets high priorty because it affects the nova driver work: https://review.openstack.org/#/c/325197/
16:56:13 <Sukhdev> Lastly, I have been trying to keep the list of updated patches in the agenda of this meeting wiki - please update it as well
16:56:36 <jroll> if we keep the same topic on them, it's only one link :)
16:56:45 <devananda> jroll: bah. yes. I fail at reading :)
16:56:55 <amotoki> Sukhdev: are they listed in the order of priority?
16:57:13 <Sukhdev> amotoki : not really
16:57:52 <amotoki> nova non-priority feature freeze is two weeks away, so dependencies should be prioritize I think from the project management perspective.
16:58:43 <sambetts> ++ I've proposed a session to the ironic midcycle in 1 week which is a group review lets get these things merged session
16:59:06 <jroll> we need nearly all of the ironic and ironicclient patches to make the nova stuff work, it's mostly in a single chain, prioritize in the order of the chain :)
16:59:19 <jroll> sambetts: my goal is to undermine you and get them merged before the midcycle :D
16:59:27 <sambetts> ;) all the better
16:59:39 <jroll> 20 second warning
16:59:51 <Sukhdev> jroll : thanks
17:00:02 <Sukhdev> we are almost out of time -
17:00:17 <jroll> thanks y'all
17:00:24 <Sukhdev> thanks for attending folks
17:00:27 <Sukhdev> bye
17:00:28 <sambetts> thanks everyone
17:00:30 <amotoki> thanks
17:00:32 <Sukhdev> #endmeeting