16:01:16 <Sukhdev> #startmeeting ironic_neutron
16:01:16 <openstack> Meeting started Mon Jun  6 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:19 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:24 <TheJulia> o/
16:01:27 <mjturek1> o/
16:01:35 <hshiina> o/
16:01:48 <Sukhdev> good morning everybody
16:02:02 <devananda> o/
16:02:09 <jroll> \o
16:02:14 * jroll in another meeting at the same time again :(
16:02:30 <amotoki> o/
16:02:30 <Sukhdev> jroll : no worries - thanks for attending here
16:02:38 <Sukhdev> #topic: Agenda
16:02:44 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_June_6.2C_2016
16:03:13 <Sukhdev> Let me know if anybody would like to add anything to the agenda
16:03:34 <Sukhdev> #topic: Announcements
16:03:46 <Sukhdev> I have no announcements
16:03:55 <Sukhdev> Anybody has any announcements?
16:04:28 <Sukhdev> BTW, I updated my system with the latest patches - will provide update in a bit
16:04:56 <Sukhdev> #topic: Action Items from previous weeks
16:05:23 <Sukhdev> I had an action item to check if neutron is creating a model for the bonded interface
16:05:38 <Sukhdev> based upon this spec - https://review.openstack.org/#/c/182242/14/specs/newton/approved/user-controlled-sriov-ports-allocation.rst
16:06:03 <Sukhdev> I reviewed the patch as well as had discussion with Armando
16:06:30 <Sukhdev> this is a nova patch and there is nothing really being worked on neutron which we can use here for BM servers
16:06:45 <Sukhdev> sambetts : are you here?
16:06:53 <sambetts> Yup
16:07:25 <sambetts> sorry was updating the agenda
16:07:25 <Sukhdev> so, looking at the patch, it seems there is really nothing on the neutron side - it is all nova side of work
16:08:22 <Sukhdev> sambetts : no worries - did you see my comments above?
16:09:11 <sambetts> Yup, cool, thats good news then :)
16:10:03 <sambetts> I wonder if the Nova side changes can/should affect how we handle our bond placement?
16:10:10 <Sukhdev> but, the spec looks good - it requires some clarification - but, it seems nova may be able to deal with this
16:11:06 <Sukhdev> sambetts : from what I see, there is minor change in the restructuring of the models - it is mainly to give flexibility to the uses/operators
16:11:41 <Sukhdev> sambetts : but, yes, there is bond information that can be passed down to the host
16:12:54 <sambetts> ok cool, something to bear in mind from the Ironic nova driver perspective, is there a timescale on the spec? Likely to make it into newton (seems unlikely based on when the feature freeze is)?
16:13:48 <Sukhdev> sambetts : I do not follow nova side of things, I usually rely on jroll for that
16:13:51 <sambetts> I don't see anything list on the BP
16:14:07 <jroll> freeze for nova is end of june
16:14:12 <Sukhdev> I do not believe it is likely - so, we should not rely on it
16:14:28 <jroll> there isn't a large amount of work to do in nova, I think it's possible to get the current work in
16:14:38 <jroll> but not probable, I guess
16:15:32 <Sukhdev> Anything else on this topic?
16:16:08 <Sukhdev> I will add this spec on our agenda going forward so that we can track it
16:16:28 <Sukhdev> #topic: Security Groups support for Baremetal
16:17:00 <Sukhdev> So, I was testing the security group support for BM servers
16:17:53 <Sukhdev> customers really want this to secure the BM deployments
16:18:11 <Sukhdev> So, other than one issue, I got it fully working
16:18:56 <Sukhdev> when we issue neutron port-create, we are not sending the security group ID in the request, which forces neutron to apply default security group
16:19:16 <Sukhdev> which is really deny everything inbound - hence, the server will not boot
16:19:28 <Sukhdev> DHCP will fail and Server will not get IP
16:19:39 <Sukhdev> I tried to fix it two ways -
16:20:08 <Sukhdev> 1) I tried to pass the SG information in the create_port call via port_body
16:20:23 <Sukhdev> neutron did not like it - I have to find a better soulution
16:20:46 <Sukhdev> 2) Add additional rules to the SG before booting the BM
16:20:59 <Sukhdev> 2) worked like a champ
16:21:22 <Sukhdev> and, the SG on the flip works great as well
16:21:41 <devananda> Sukhdev: should we simply be defining default SG on the prov & cleaning networks, then?
16:21:48 <sambetts> I think we should be creating our own an Ironic SG for the provisioning network, and pass it in via port create right?
16:21:54 <Sukhdev> i.e. the SG specified on nova boot --security-group works just fine
16:21:54 <devananda> :)
16:22:22 <Sukhdev> devananda : yes  - we can solve it two ways
16:22:34 <Sukhdev> sambetts : yes - that is what I tried to do -
16:22:42 <devananda> Sukhdev: user should be able to define their own SG for the instance, which may not allow PXE boot, for example
16:22:59 <amotoki> neutron provisions implicit rules which allows DHCP in addition to SG rules.
16:23:08 <devananda> and conversely the user-specified SG should not be able to interfere with ironic's boot/clean phases
16:23:36 <amotoki> i think we can provision rules which are required for BM server provisioning.
16:23:54 <Sukhdev> amotoki : I observed two issues - 1) TFTP failed as well as BM did not get IP address on provisioing network
16:24:14 <Sukhdev> once I added ingress rules to the default SG - all worked just fine
16:24:49 <sambetts> so the problem is that we shouldn't be using the default sec group for provisioning
16:24:57 <devananda> sambetts: ++
16:25:07 <Sukhdev> So, I would like to throw out a question to the team -
16:25:12 <amotoki> Sukhdev: which phase are you talking now? provisioning phase?
16:25:15 <sambetts> we need a [neutron] security_group_id=<uuid> in the config file and should be passing it at port-create
16:25:26 <Sukhdev> amotoki : provisioning only
16:25:40 <amotoki> Sukhdev: got it
16:25:53 <Sukhdev> amotoki : when network flip takes place, everything works fine - as the correct SG is used for the tenant network
16:26:09 <Sukhdev> So, my question to the team is -
16:26:39 <Sukhdev> Do we want to add additional config knob like provisioning_network_uuid for SG ?
16:26:54 <sambetts> +1
16:27:03 <Sukhdev> this will allow operators to create their own SG for provisioning networks
16:27:21 <amotoki> at the moment, +1 to this idea
16:27:59 <Sukhdev> Or are we OK to tell them to add ingress rules to the default SG used for provisioning network
16:28:21 <amotoki> can SG rules for provision vary across operators or deployments?
16:29:03 <Sukhdev> amotoki : good question - I would guess yes
16:29:15 <devananda> I can think of cases where they would, yes
16:29:25 <sambetts> its a possiblity with customised cleaning steps etc that might say download a firmware from somewhere
16:29:33 <sambetts> or other use cases like that
16:29:53 <amotoki> If so, defining a SG for provisioning network makes sense to me.
16:30:46 <sambetts> there is the possiblity that cleaning and provisioning SG rules may also differ I guess
16:30:50 <sambetts> devananda: do you agree ^
16:30:54 <Sukhdev> amotoki : I created a SG for provisioning network and tried to hard-code to make it work
16:31:03 <devananda> sambetts: yea. in my case they wouldn't, but in theory, they could
16:31:15 <amotoki> sambetts: agree
16:32:15 <Sukhdev> So, are we agreeing that we will add two SGs to the ironic config - one for provisioning n/w and other for cleaning?
16:33:06 <sambetts> thats what I'd expect +1
16:33:25 <Sukhdev> jroll devananda : what say you?
16:34:00 <devananda> Sukhdev: +1, with docs / defaults that say "these could be the same network"
16:34:30 <amotoki> +1
16:34:56 <jroll> I haven't been paying attention enough to say
16:35:05 <Sukhdev> while jroll is probably reading the comments, amotoki I have a quesiton for you
16:35:15 <jroll> "yet another config" isn't great, but if it's needed it's needed
16:36:00 <Sukhdev> jroll : this provides flexibility to the operators and SG is a hot button with everybody
16:36:08 <jroll> right, it's probably fine
16:36:41 <Sukhdev> #agreed: We will add two SGs to the ironic config - one for provisioning n/w and other for cleaning
16:36:52 <TheJulia> I think it is okay as long as it can also be defined in the config to none because some oeprators will not use the functionality
16:36:55 <amotoki> have we discussed whether we should provide flexibility or we can achieve the goal with implicit static rules?
16:37:33 <devananda> TheJulia: very good point
16:37:43 <devananda> Sukhdev: we must be able to *disable* this as well
16:37:52 <Sukhdev> amotoki : we have to enhance the implicit rules to allow TFTP in addition to DHCP
16:38:04 <devananda> eg, because the things that work today must continue to work after this feature is added
16:38:18 <amotoki> in my mind, ironic can define implicit required rules for provisioning network.
16:38:30 <amotoki> it is different from a config option.
16:38:54 <TheJulia> Also, not understanding the implementation details, I worry how/where the packet inspection woudl take place, and if it is on a switchport level, then that might have a performance impact based upon the hardware/software in use in the operator environment, but truthfully that is just my lack of context
16:38:55 <Sukhdev> devananda TheJulia : understood - I will add text on the top of our weekly meeting wiki to clarify it - you can review it and correct it
16:39:24 <Sukhdev> amotoki : that is true - if all deployments will use the same rules
16:39:58 <amotoki> Sukhdev: correct. we can start from SG for provisioning network and if it turns out too much flexibilty, we can drop it later.
16:39:59 <Sukhdev> amotoki : if different operators have different rules (will they?) then config option is better
16:40:16 <Sukhdev> amotoki : +1
16:40:54 <Sukhdev> amotoki : I have a different question for you -
16:41:01 <amotoki> Sukhdev: what?
16:41:49 <Sukhdev> amotoki : I tried to hard code the SG ID in the port-body, for neutron port-create and neutron complains in can not find SG
16:42:47 <amotoki> hmm.... does not 'security_gorups: ["SG-ID"]' work?
16:42:55 <amotoki> *security_groups*
16:43:41 <amotoki> Sukhdev: I can test it later. i think we can discuss it separately
16:43:42 <Sukhdev> amotoki : the place where we add binding profile information to the port body (in ironic driver), I tried to add this additional information
16:43:58 <Sukhdev> amotoki : yes, lets take it off-line
16:44:12 <Sukhdev> Anybody has any thing on this?
16:44:34 <Sukhdev> amotoki and I will work out the details of how to make it work - and either one of will push the patch
16:44:54 <sambetts> where is the code right now? Didn't we dicuss in Austin it would require changes to the mech driver API
16:44:57 <sambetts> ?
16:45:00 <devananda> Sukhdev: if I'm following, then this sounds good
16:45:41 <Sukhdev> sambetts : no - no changes to the mech drivers
16:46:14 <Sukhdev> neutron already has full support for SG - all we have to do it is plumb it on the ironic driver to pass correct SG information
16:46:50 <sambetts> Sukhdev: for switch port programming of ingress/egress rules?
16:47:12 <Sukhdev> upon the network flip, it works like a charm - as we use update_port - and neutron port already has correct SG attached to it based upon nova boot parameters
16:47:41 <Sukhdev> sambetts : oh yea, I see what you are asking - yup, that work is needed of course :-)
16:49:22 <sambetts> So we can do SGs on the virtual neutron side, but we can't program the ACLs on the switch yet right?
16:49:53 <Sukhdev> sambetts : yes - thats why customers are not happy
16:50:16 <Sukhdev> Hence, we are addressing this - Arista driver supports it
16:50:23 <sambetts> Ok, whats the plan to get that done on the mech driver API / neutron side?
16:51:22 <Sukhdev> there is nothing special needed in the driver - if your driver support SG for Virtual world, it will work for BM world once we plum what we discussed here
16:51:36 <amotoki> are we talking about generic-switch driver?
16:51:55 <Sukhdev> amotoki: I was talking about of vendor drivers -
16:52:04 <sambetts> I think the problem we disucssed was something along the lines of if I update a SG, that event doesn't make it to the mech driver right now so we can't act on it
16:52:06 <Sukhdev> amotoki : more specifically Arista driver
16:52:26 <Sukhdev> sambetts : correct
16:53:07 <Sukhdev> sambetts : if we plumb it right, it will appear in the port context of the driver (as it does for virtual world) and things will fall in place
16:53:41 <sambetts> does that require changes in neutron?
16:53:41 <Sukhdev> this will bring BM at par with VM servers in terms of SG support - which is what everybody wants
16:53:48 <Sukhdev> sambetts : no
16:54:01 <sambetts> but if the event doesn
16:54:18 <sambetts> t make it to the mech driver, doesn't that need changing
16:55:56 <Sukhdev> sambetts: neutron does not need any change - the port context will now have correct information (which is presently missing) - the drivers can act accordingly then
16:56:09 <amotoki> sambetts: yes and no. no need for change in neutron framework including ML2 plugin. mech driver support is needed.
16:56:49 * Sukhdev lost track of time - 4 min left
16:57:03 <sambetts> Sukhdev: and if I do a neutron sec-group-update it'll propergate to ml2 driver to update the ACLs?
16:57:27 <Sukhdev> sambetts : if you are using neutron callbacks, yes
16:57:50 <Sukhdev> sambetts : a notification is generated
16:58:12 <Sukhdev> sambetts : this is how SG works for Virtual world as well
16:58:28 <Sukhdev> sambetts : ping me off line, I can walk you through the details
16:59:01 <Sukhdev> Anything else on this?
16:59:07 <sambetts> One last question, how do we handle cases where switch hardware only supports a subset of the features of security groups? I've spoken to a couple of people who can only support single direction ACLs
16:59:48 <sambetts> is that down to the mech driver to decide?
16:59:53 <Sukhdev> sambetts: that is very vendor specific thing - you can choose to ignore any event you choose to
17:00:09 <Sukhdev> yes, it is upto vendor driver to decide
17:00:25 <Sukhdev> Folks we are out of time -
17:00:39 <sambetts> thanks guys :)
17:00:42 <Sukhdev> I will keep this on agenda for next week - we can discuss further
17:00:54 <Sukhdev> Thanks for attending - this was a great discussion
17:00:58 <Sukhdev> bye
17:01:05 <Sukhdev> #endmeeting