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