16:01:35 <Sukhdev> #startmeeting: ironic_neutron
16:01:36 <openstack> Meeting started Mon Aug 15 16:01:35 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:39 <openstack> The meeting name has been set to '__ironic_neutron'
16:02:08 <Sukhdev> jroll : are you here?
16:02:23 <sambetts> jroll is not going to make this one
16:02:32 <Sukhdev> #topic: Agenda
16:02:36 <devananda> o/
16:02:44 <sambetts> o/
16:02:47 <TheJulia> o/
16:02:50 <hshiina> o/
16:02:52 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_August_15.2C_2016
16:03:21 <Sukhdev> feel free to add to Agenda anything you like
16:03:41 <Sukhdev> #topic: Annoncements
16:04:01 <Sukhdev> I do not have any announcements - anybody?
16:04:30 <Sukhdev> #topic: Update on the testing
16:04:31 <sambetts> I saw you were asking about the inspector stuff last meeting
16:04:47 <Sukhdev> #undo
16:04:48 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f5bc0bc7a50>
16:05:05 <sambetts> That stuff both IPA side and Inspector side has merged
16:05:10 <Sukhdev> sambetts: yes - good to see you are here
16:05:20 <Sukhdev> we'll cover that in a bit
16:05:56 <Sukhdev> #topic: Update on the testing
16:06:22 <Sukhdev> As you know I have been testing all the merged code for past two weeks
16:06:41 <Sukhdev> Everything seems to be working as expected
16:06:49 <mjturek1> o/ (sorry I'm late)
16:07:23 <Sukhdev> I had filed one bug last week - in case you did not see here it is - https://bugs.launchpad.net/ironic/+bug/1610389
16:07:23 <openstack> Launchpad bug 1610389 in Ironic "IPA fails to pull image after reboot" [Undecided,New]
16:07:56 <Sukhdev> The good news is that it turns out to be a mount issue of swift images
16:08:21 <Sukhdev> Therefore, all is fine
16:08:36 <Sukhdev> I will be wrapping up the testing this week
16:09:08 <Sukhdev> Has anybody else done any testing of the latest code?
16:09:30 <Sukhdev> It will be good to share your experiences
16:10:04 <hshiina> I tested when patches were almost merged.
16:10:14 <hshiina> not yet the latest code.
16:10:44 <hshiina> deploying succeeded with our ml2 driver.
16:11:20 <Sukhdev> cool -
16:11:58 <Sukhdev> I am building auto-test bed, where the testing will run 24x7 - as customers are ready to deploy this soon
16:13:06 <Sukhdev> I have been running tests back-to-back with forced failures to make sure things recover and work as expected
16:13:38 <Sukhdev> moving on.....
16:13:53 <Sukhdev> #topic: Remaining work items
16:14:19 <Sukhdev> we identified three items to complete in this cycle
16:14:30 <Sukhdev> 1) port groups
16:14:33 <Sukhdev> 2) inspector
16:14:41 <Sukhdev> 3) Security groups
16:15:10 <Sukhdev> sambetts : we missed you past few weeks regarding items 1 and 2
16:15:48 <sambetts> So the inspector stuff has merged already
16:15:55 <sambetts> LLDP stuff that is
16:16:14 <sambetts> https://review.openstack.org/#/c/321082/
16:16:31 <sambetts> https://review.openstack.org/#/c/320584/
16:17:09 <Sukhdev> I saw that - that is really cool
16:17:46 <Sukhdev> sambetts: is there anything else left for this?
16:18:01 <Sukhdev> e.g. documentation or anything else?
16:18:29 <sambetts> I need to do docs, and any vendors that have custom switch_info need to add their own processing hooks to process that
16:19:32 <Sukhdev> sambetts: I have not tested this part - If you can provide some guidance in that regard, I will incorporate into my testing
16:19:37 <Sukhdev> and provide feedback
16:20:05 <sambetts> Sure, I'll put together some docs, and push them up for review so you can try it out
16:20:47 <Sukhdev> sambetts : cool - thanks. When you push them, just ping me - in case I miss them
16:21:29 <sambetts> ok :)
16:22:34 <Sukhdev> So, we are down to two items
16:22:43 <Sukhdev> port groups and security groups
16:23:07 <Sukhdev> I plan on working on security groups later this week
16:23:31 <mjturek1> Should we have tempest tests for portgroups before it merges?
16:24:41 <mjturek1> or can that be done after?
16:24:42 <sambetts> Im unsure on the likelyhood of a Nova FFE for the portgroups work
16:27:53 <Sukhdev> we should strive to get the ironic patches
16:28:24 <Sukhdev> even if nova does not allow, we can push nova work in the early O-cycle
16:29:30 <Sukhdev> any thoughts?
16:29:49 <TheJulia> I think that should absolutely be the case
16:29:55 <mjturek1> +1
16:30:56 <Sukhdev> we still have couple of weeks
16:31:03 <sambetts> +1
16:31:56 <mjturek1> are there any glaring holes in the patches?https://review.openstack.org/#/c/347549 https://review.openstack.org/#/c/332177
16:32:29 * sambetts needs to re-review
16:32:43 <Sukhdev> #link: https://review.openstack.org/#/c/347549
16:32:53 <Sukhdev> #link: https://review.openstack.org/#/c/332177
16:32:54 <devananda> https://review.openstack.org/#/c/332177 needs an addition to the api-ref
16:33:11 <mjturek1> devananda: will do
16:34:09 <Sukhdev> I will review these later as well -
16:34:44 <mjturek1> devananda do you mean 347549? 332177 has additions to the doc/source/webapi/v1.rst (not sure what else 332117 would need)
16:34:55 <mjturek1> we can wait for open discussion if it's more appropriate though
16:35:35 <Sukhdev> mjturek1 : this is good time to cover everything on this feature
16:35:40 <devananda> mjturek1: I actually want to delete that page soon :)
16:35:51 <mjturek1> ahhhh
16:36:02 <devananda> mjturek1: http://developer.openstack.org/api-ref/baremetal/
16:36:15 <mjturek1> devananda: oh cool
16:36:15 <devananda> is a much better reference, as this is now in the openstack standard format
16:36:24 <devananda> see ironic/api-ref/source/
16:36:34 <devananda> mjturek1: also, I have a patch up to make api-ref sample generation much easier - https://review.openstack.org/#/c/353117/3/api-ref/regenerate-samples.sh
16:36:44 <mjturek1> nice :)
16:36:54 <mjturek1> alright, I'll work on docs for there
16:38:01 <devananda> I'll take a look at the class changes in https://review.openstack.org/#/c/347549 again today
16:38:21 <mjturek1> thanks :)
16:38:32 * jroll is here now and reads back a bit
16:39:28 <devananda> Sukhdev, mjturek1: if portgroup support lands in ironic but not Nova, a) what functionality will actually work? b) how do we signal that to users?
16:40:21 <Sukhdev> devananda : in that case, in my opinion, we will not declare the feature to be available for general use
16:40:37 <Sukhdev> as soon nova side merges, then we announce the feature available -
16:40:40 <jroll> I agree we won't get nova work done in newton, but should land the ironic side if possible, so we can do the nova bits in nova
16:40:52 <mjturek1> not entirely sure. You'll be able to create/update/etc the resource but not very useful
16:41:03 <mjturek1> +1 for Sukhdev
16:41:32 <devananda> Sukhdev: whether we "declare the feature available" or not doesn't change that this resource would be exposed in the API
16:41:41 <jroll> I agree (a) will be "nothing"
16:41:42 <Sukhdev> This gives us ability to test/bake the feture
16:41:51 <devananda> and the REST API doesn't have a means to signal "this endpoint is non-functional"
16:42:31 * jroll or "nothing" from the POV of booting an instance via nova
16:42:50 <devananda> jroll: right - so, will it have an impact on neutron, or the node's network configuration?
16:43:03 <devananda> if we land this feature, and someone starts creating portgroups in Ironic.... what happens?
16:43:11 <jroll> devananda: I think that's a general problem we have; see also current console work, or the same problem earlier this cycle with local_link_info or network_interface
16:43:31 <devananda> jroll: I agree - and each case is a little different
16:43:50 <jroll> devananda: right, it's a good question. it's probably possible to break things
16:43:59 * jroll needs more coffee for this one
16:44:24 <devananda> Sukhdev: I can wait until opendiscussion for this question - it might be a can'o'worms :)
16:45:02 <Sukhdev> Lets get to Open Discussion - as there is nothing more on the agenda
16:45:09 <Sukhdev> #topic: Open Discussion
16:45:11 <jroll> devananda: I think the actual question is "how do we message that", given we can't land ironic and nova pieces at the same time :)
16:45:59 <Sukhdev> so, we can deal this with two ways:
16:46:03 <mjturek1> would Notes in the documentation and log warnings be enough?
16:46:33 <Sukhdev> 1) document that the feature is not available until O-cycle - and merge the ironic code
16:46:52 <Sukhdev> 2) merge the code and let it fail
16:46:59 <Sukhdev> if somebody tries to use it
16:47:14 <devananda> Sukhdev: I think those are the same option
16:47:16 <sambetts> well it is availible to standalone users right?
16:47:32 <Sukhdev> sambetts: right
16:48:15 <Sukhdev> or the folks who want to test this feature prior to production deployments, this gives them a way to get head start
16:48:19 <devananda> mjturek1: log messages aren't visible to users (only to operators)
16:48:28 <mjturek1> ah true
16:49:37 <devananda> my concern is landing an API that we've been talking about for literally over a year, but that causes 'nova boot' to flat out fail if it is used
16:49:59 <devananda> console is different in that respect - nova may not be taking advantage of it, but it shouldn't (AFAIK) interfere with Nova
16:51:55 <devananda> nova has had similar challenges when introducing experimental features
16:52:53 <devananda> sambetts: is there much use for this feature in our non-Nova use cases?
16:53:10 <jroll> yeah, I think we need to figure out exactly how hard it breaks
16:53:23 <jroll> devananda: LAG/MLAG/bonding? yes
16:55:30 <Sukhdev> jroll devananda : I know one vendor who tried to use it - the instance does not go past the first boot
16:56:12 <devananda> could we land something in Nova that fails fast, with clear messages, if portgroups are in use?
16:56:29 <jroll> Sukhdev: yeah, that's my best guess
16:56:41 <TheJulia> even if it fails fast, would it be visible to an end user aside from scheduling failed?
16:56:42 <devananda> I would be fine with the lack of nova support if the failure mode is clear
16:57:13 <jroll> the sad part is the end user would see the error but can't do anything
16:57:19 <jroll> and the operator would never know
16:57:31 <devananda> jroll: yea - but we could log big bold things for the operator at that point
16:57:39 <jroll> indeed
16:57:42 <devananda> since it is the operator who shouldn't be using portgroups with that nova virt driver
16:58:08 <devananda> so, I think we will need to land something in our virt driver to clearly communicate that it can't deploy to a Node that has portgroups
16:58:21 <devananda> jroll: think nova will let that get in this late?
16:58:45 <devananda> no change in functionality - just a check-and-fail-fast
16:59:19 <jroll> devananda: don't see why not, as it's just a sanity check sort of thing that we'll remove next cycle
16:59:49 <devananda> I think that covers all my concerns about landing this feature in Ironic but not Nova
16:59:51 <jroll> devananda: the weird part is we can't tell it has portgroups until we land these api changes
16:59:54 <devananda> (that and docs, i mean)
17:00:15 <jroll> we're at time
17:00:15 <devananda> jroll: right. and the API version bump
17:00:22 <jroll> y
17:00:24 <jroll> ya*
17:01:22 <Sukhdev> folks, it is time -
17:01:41 <Sukhdev> thanks for attending -
17:01:47 <Sukhdev> bye
17:01:56 <Sukhdev> #endmeeting