16:01:09 <Sukhdev> #startmeeting ironic_neutron
16:01:10 <openstack> Meeting started Mon Dec  5 16:01:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:14 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:24 <Sukhdev> sambetts: are you here?
16:01:35 <Sukhdev> #topic: Agenda
16:01:39 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_December_5.2C_2016
16:02:04 <Sukhdev> The agenda is pretty much same from last week
16:02:32 <Sukhdev> #topic: Announcements
16:02:46 <Sukhdev> jroll : anything to announce?
16:02:58 <jroll> nope!
16:02:59 <sambetts> o/
16:03:11 <sambetts> Nothing new from me
16:03:23 <Sukhdev> #topic: Security Groups
16:04:06 <Sukhdev> I rebased the documentation patch - but, missed picking up updated names for variables
16:04:24 <Sukhdev> will push another update later today
16:04:55 <Sukhdev> that should take care of the comments on the patch
16:05:25 <Sukhdev> sambetts : do we want to add anything else in the documentaiton patch?
16:05:42 * sambetts still needs to re-review sorry
16:06:39 <Sukhdev> NP
16:06:49 <Sukhdev> Anything else on this?
16:07:20 * jroll does not
16:07:29 <Sukhdev> #topic: Port Groups
16:08:03 <Sukhdev> It seems pretty much in the same state -
16:08:21 <joanna> o/
16:08:32 <Sukhdev> https://review.openstack.org/#/q/topic:bug/1618754
16:09:03 <jroll> yeah, getting close
16:09:06 <vsaienk0> we can land ironiclient patches, if they are reviewed
16:09:43 <Sukhdev> +1
16:09:46 <jroll> awesome
16:10:13 <vsaienk0> Please check if we are ok with the following testing approach - https://review.openstack.org/#/c/381743
16:10:52 <vsaienk0> create nodes with portgroups and without portgroups in same environment and use nova flavors for scheduling
16:12:24 <Sukhdev> vsaienk0 : nova flavors may or may not have anything to do with port groups - just an FYI
16:13:31 <Sukhdev> but, I think your approach is correct
16:14:10 <vsaienk0> Sukhdev it just for tests, to use multitenant environment for portgroup and non-portgroup tests
16:14:57 <Sukhdev> vsaienk0 : Understood
16:15:05 <jroll> ya, it's probably fine, need to look in more detail though
16:16:19 <Sukhdev> Anything else on this?
16:17:01 <Sukhdev> #topic: Interface attach APIs
16:17:14 <Sukhdev> sambetts pushed updates on Friday
16:17:20 <Sukhdev> https://review.openstack.org/#/q/topic:+bug/1582188
16:17:37 <sambetts> yeah, these patches when super weird during that push
16:17:40 <vsaienk0> the patches needs to be rebased, thay are in merge conflict, and the last version wasn't worked I got 500 from API
16:18:09 <sambetts> I had some terrible merge conflcits and all the files got messed up
16:18:40 <sambetts> I have fixed it and I'm just resolving all the comments
16:18:59 <Sukhdev> cool - thanks sambetts
16:19:30 <Sukhdev> will look for the updates
16:19:54 <Sukhdev> anything else on this?
16:20:41 <sambetts> Nothing right now from me
16:20:57 <Sukhdev> #topic: VLAN aware servers
16:21:17 <Sukhdev> I added few more comments on the spec
16:21:28 <Sukhdev> And noticed more comments this morning as well
16:21:30 <sambetts> there were a bunch of comments on the RFE over the weekend, I'm going to try to resolve them tomorrow
16:21:51 <Sukhdev> but, I think most of the juice is in place
16:21:59 <vsaienk0> I've left a comments in the spec https://review.openstack.org/#/c/277853/10/specs/approved/VLAN-aware-baremetal-instances.rst@35
16:22:19 <vsaienk0> I doubt that we need to change anything on ironic side to made it working
16:23:15 <vsaienk0> neutron allows to group ports to trunks https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms and https://review.openstack.org/#/c/361776/15/doc/networking-guide/source/config-trunking.rst
16:23:37 <sambetts> my spec takes all of this into account already
16:24:07 <vsaienk0> Do we need to made any automatic decisions on Ironic side (ie create a trunk on the fly) when user requested instance with more ports that hardware server has, because user image may not support trunking at all
16:24:09 <Sukhdev> vsaienk0 : I just saw your comment - I think it is covered
16:26:15 <Sukhdev> vsaienk0 : what do you mean when you say user may not support trunking at all -
16:26:29 <Sukhdev> do you mean the TOR?
16:26:41 <vsaienk0> no I mean the image that user trying to deploy
16:26:45 <jroll> the OS
16:27:49 <vsaienk0> also I think that number of nic should be somehow mentioned in the flavor, so user always know hardware capabilities
16:27:49 <Sukhdev> Think of a use case when one runs a service on the BM sever -
16:28:27 <vsaienk0> and if needed user may create a trunk in neutron manually and pass it to nova boot
16:28:56 <vsaienk0> just wandered why we need to made this decision automatically on Ironic side is it right place?
16:30:31 <Sukhdev> vsaienk0 : I think this info is needed by (at least) the ML2 drivers when vnic_type == baremetal
16:30:36 <sambetts> so the reason for doing this may now have been solved by the attach/detach spec, but originally it was so that a user requesting 4 nics in nova could be given any baremetal server regardless of number physical ports
16:30:56 <vsaienk0> Sukhed ML2 is neutron thing it should pick trunk info from port metadata
16:31:29 <Sukhdev> never mind my comment - as soon as I hit send, I realized that :-)
16:31:38 <vsaienk0> there is an example how trunk port looks like http://paste.openstack.org/show/591426/
16:31:41 <joanna> @sambetts - could you send me the link to this spec?
16:31:45 <vsaienk0> it has trunk_details
16:31:59 <vdrok> joanna:  https://review.openstack.org/#/c/277853
16:32:06 <joanna> thanks!
16:33:39 <vsaienk0> sambetts: trying to pick any server is not right, we shouldn't convert user request and create trunks on the fly, we don't know if user image will work with it
16:34:23 <vsaienk0> user should know how many nics are available via flavor info, and based on that made decision to create trunks or not by his own
16:35:27 <Sukhdev> vsaienk0 : If my memory serves me right, there are two use cases
16:35:49 <Sukhdev> 1) when the admin creates trunked port - this is what you are talking about
16:36:07 <Sukhdev> 2) when it is implicitly created on behalf of user
16:36:24 <Sukhdev> We can debate if 2) is needed or not
16:36:37 <sambetts> Sukhdev: users, not just admins, can create a neutron trunk
16:37:06 <sambetts> basically the argument is whether --nic net-id should result in an implict creation
16:37:07 <Sukhdev> sambetts : right - that is what I said in 1)
16:37:24 <Sukhdev> in 2) it is implicitly created
16:37:28 <sambetts> yeah
16:38:23 <vsaienk0> Sukhdev: user may create a trunk port and use --nic port-id=<trunk-port-id>
16:38:39 <sambetts> vsaienk0: that isn't broken by my spec
16:39:02 <vsaienk0> sambetts: I see, but what if user image doesn't support trunks
16:39:13 <vsaienk0> are we going to handle that case somehow?
16:39:46 <sambetts> right now we don't have any way for images to state what they support
16:39:47 <Sukhdev> vsaienk0 : I think that is where flavor-id comes into play
16:40:30 <sambetts> for anything, bonding, trunks, cloud-init even
16:41:06 <Sukhdev> vsaienk0 : So, when admin creates nova flavors for BM selection, I think that is where all these come into play
16:41:13 <vsaienk0> so creating trunk on the fly will break cases when user image doensn't support trunks
16:41:18 <sambetts> right now Ironic basically assumes the images support them all, and more or less assumes the images are provided not self created by users
16:41:37 <sambetts> jroll: ^
16:42:07 <jroll> yeah, it's hard/impossible to detect this
16:42:11 <vsaienk0> sambetts: I can't say that user image supports vlan if we don't know it for sure
16:43:22 <vsaienk0> in my understanding if user do --nic net-id multiple times, it means that user want hardware server with number of hardware nics that were specified in request
16:43:46 <vsaienk0> if user want trunk, he create a trunk and use --nic port-id <trunk>
16:44:09 <vsaienk0> if want mixed env that --nic net-id ... --nic port-id <trunk>
16:44:19 <jroll> the problem is that in a cloudy world, you just connect networks
16:44:21 <sambetts> IMO if you request --nic net-id multiple times it means I want a NIC connected to this network
16:44:30 <jroll> you shouldn't need to know the physical ccharacteristics of the cloud
16:44:41 <sambetts> sub-interfaces are NICs IMO
16:45:11 <vsaienk0> sambetts: but if user image doesn't support vlans, converting --nic ... --nic and creating trunk will lead to active instance without network access
16:45:23 <jroll> the ultimate goal here is to make baremetal act cloudy, like a VM, imo
16:45:35 <sambetts> vsaienk0: or no instance at all
16:45:55 <vsaienk0> sambetts: we can't check if instance is accessible
16:46:10 <sambetts> I mean, it won't even get scehduled
16:46:19 <sambetts> which isn't want we want
16:47:03 <Sukhdev> sambetts : that is the way I thought it works - but, vsaienk0 does bring up an interesting angle
16:47:56 <Sukhdev> vsaienk0 : in general, if there is no way to know what does instance image support - this is a bigger problem, no?
16:48:39 <sambetts> +1
16:48:40 <Sukhdev> I mean regardless of trunked i/f, it is an issue, no?
16:49:03 <vdrok> is it going to be at least possible to say "I want this exact configuration, do not assume anything"?
16:49:08 <vsaienk0> might be use vlan_support flag in image metadata with default = True
16:50:46 <Sukhdev> vdrok : I thought that will play into the flavor creation process - so that a specific BM is selected or not selected
16:51:21 * Sukhdev time check 9 min
16:51:42 <Sukhdev> to summarize - there are really two orthogonal issues here
16:51:59 <vdrok> Sukhdev: well, with the planned switch to resource providers, the single resource class field might be encoding too much info in it, if we include enabling/disabling features there too
16:52:00 <vsaienk0> I don't have anything to add, I think we can discuss it in the spec :)
16:52:33 <Sukhdev> 1) do we support implicit creation of trunk port or not
16:53:29 <Sukhdev> 2) Do we tie-in the image capabilities into the flavor creation - so that appropriate BMS are selected or not
16:54:08 <Sukhdev> anybody sees anything else?
16:55:22 <sambetts> also do we include nic number in the flavor/resources to aid scehduling
16:55:33 <Sukhdev> sambetts : perhaps you can mention these in the spec
16:56:51 <Sukhdev> sambetts : right - perhaps a paragraph on the flavor creation guidelines :-)
16:57:23 <sambetts> Sukhdev: right now flavors don't include anything regarding networking, so its a larger issue
16:58:25 <Sukhdev> sambetts : we can keep networking out - but, use parameters such as image capabilities, Hw capabilities, etc - that should cover everything we discussed here
16:58:31 <sambetts> I'll try to expand on these issues when I update the spec
16:59:00 <Sukhdev> sambetts : thanks
16:59:07 <vsaienk0> sambetts: thanks
16:59:11 <Sukhdev> anything else - we are down to 1 min
16:59:54 <Sukhdev> sambetts : BTW, if you need any help with this, feel free to ping me
17:00:10 <sambetts> sure thanks :D and thanks for all the reviews :D
17:00:19 <Sukhdev> OK - folks, we are out of time
17:00:23 <vdrok> moving to meeting-3
17:00:25 <vdrok> :)
17:00:29 <Sukhdev> thanks for attending - was a great discussion
17:00:30 <Sukhdev> byt
17:00:33 <Sukhdev> bye
17:00:38 <vdrok> thanks!
17:00:41 <Sukhdev> #endmeeting