16:01:38 #startmeeting ironic_neutron 16:01:39 Meeting started Mon Mar 7 16:01:38 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:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:44 The meeting name has been set to 'ironic_neutron' 16:01:54 o/ 16:01:55 o/ 16:01:59 o/ 16:02:04 o/ 16:02:07 #topic: Agenda 16:02:13 #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_March_7.2C_2016 16:02:17 o/ 16:02:36 Feel free to add to the agenda, as we go along 16:02:44 #topic: Announcements 16:03:05 M3 was last week, right? 16:03:27 Sukhdev: Yes 16:03:38 http://releases.openstack.org/mitaka/schedule.html 16:04:01 Anybody has any announcement to make before we dive into the agenda? 16:04:26 lazy_prince : welcome back 16:04:46 #topic: Update on patches 16:05:13 #link: https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 16:05:48 thanks to jroll for the refactor effort 16:06:07 I notice two patches are already merged 16:07:31 devananda : what is the update on the API patches? 16:07:37 Sukhdev: jroll is on vacation for the next few days and has asked me to try to keep his refactor patches going 16:08:44 I'm juggling a few things, but will try to make some progress on that while he's gone 16:09:47 devananda : thanks - what a troop :-) 16:10:16 Is this patch https://review.openstack.org/#/c/206163 likely to make it into Mitaka? 16:10:34 sambetts: I do not think so 16:11:08 So Mitaka == No LAG Support? 16:11:31 sambetts : yes 16:12:05 sambetts : mitaka+portgroup patch = LAG support 16:12:33 it also has a lot of -1's and no updates in a month 16:12:52 devananda : on the API related patches, other than cleaning up of comments - any other major issue? 16:12:53 Sukhdev: sure, does anyone know if Nova does inter releases or is it going to be Newton we see that release? 16:13:38 sambetts : it was held up because of API patches - kind of chicken-n-egg issue 16:13:43 sambetts: Nova does coordinated releases with milestones 16:13:49 sambetts: so yes, that means Newton 16:14:11 Ah I see, ok thanks 16:14:16 Sukhdev: https://review.openstack.org/#/c/285852/ needs reviews 16:14:44 devananda : yes it does - I did review it though 16:15:05 devananda : it is mostly ready to go 16:15:17 lazy_prince : you should look at it as well 16:15:25 Sukhdev: thanks. it also needs reviews from ironic cores. 16:15:28 its on the top of my list too 16:15:32 * lazy_prince looking.. 16:15:47 I will rebuild my local test env to play with it today 16:16:17 I've -1d the driver update patch with regards to it needing rebasing ontop of this one 16:16:19 I have not tested after refactor - anybody else had a chance to test? 16:16:40 I will look into that too 16:16:41 sambetts: I saw it :-) 16:16:49 Unfortunatly not, been focused on CI work 16:17:37 how about ironicclient patch - https://review.openstack.org/#/c/206144 16:17:44 this one is ready to go as well 16:18:55 this one looks ready as well - https://review.openstack.org/#/c/206244/ 16:19:06 yep, but we have to merge portgroups api and network providers before client 16:20:10 and anyway, IIUC ironicclient was released so this won't go in mitaka client even if merged 16:20:53 vdrok : are you serious? 16:21:24 we can cut a client release right after that 16:21:24 Sukhdev, I think so, client for mitaka is 1.2.0, it was released last week 16:22:10 when is mitaka RC1? 16:22:38 Mar 14-18 16:23:24 Final Release for client libs was last week though according to the schedule 16:24:22 I did not realize the clients cut-off deadline is earlier!!! yikes 16:24:37 Sukhdev: it has been posted on http://releases.openstack.org/mitaka/schedule.html since the cycle started 16:25:12 we can cut a 1.3 release of the client and publish it to pypi once the API lands in the server 16:25:30 though openstack's coordinated release will continue to use 1.2 as the basis for Mitaka stable testing 16:26:24 I see - that works. 16:27:45 anything else on the patches? 16:27:59 Lets try to review and push them this week, if possible 16:28:41 #topic: Vlan aware BMs 16:28:55 sambetts : I kept this topic on the agenda for this week as well 16:29:23 Do you want to discuss this any further? 16:29:33 Sukhdev: I added a few links to that topic, and I'd love to see people commenting on them. 16:30:05 Yup, I want to push for a bit of discussion around the comments left on the RFE too 16:31:40 baoli has left some interesting ideas about how we should handle Ironic port to Neutron port mapping instead of storing them in the extra field, and I'd like to see some feedback there 16:32:32 devananda: do you know when the summit session suggestions open so I can write up something for this like you suggested at the midcycle? 16:35:37 sambetts: the newtn design summit is april 25-29. I imagine we'll start discussing the sessions around the first of april 16:35:59 sambetts: the list won't be finalized until shortly before the summit, around april 18th 16:36:24 sambetts: could you post a link to that discussion from baoli? 16:36:31 this will be a good topic for design summit - 16:37:18 devananda: cool, I know jroll was organising the number of sessions last meeting, so I'd guessed it would be once we'd heard back about that 16:37:25 yep 16:37:34 devananda: https://review.openstack.org/#/c/277853/2/specs/approved/VLAN-aware-baremetal-instances.rst I can't link to it directly, but L41 there 16:38:29 oh, that's going to take more time to read 16:39:07 in general, I agree with the sentiment that the ports.extra field should not be used to store anything that affects ironic or neutron behavior in a released feature 16:39:35 it's intended to be an opaque field that Ironic code never introspects or depends on 16:40:28 devananda: +1 16:41:17 anything else on this? 16:41:26 * Sukhdev waiting 16:41:36 not from me 16:41:50 #topic: Open Discussion 16:41:53 I think further dicussion on the spec would be great :) 16:42:31 So another patch has grabbed my attention recently 16:42:33 sambetts: sounds good - I will review baoli 's comment/suggestion as well 16:42:44 its somewhat related 16:42:46 https://review.openstack.org/#/c/284025/ 16:43:27 its an interesting bug in the current virt driver code 16:43:32 #link: https://review.openstack.org/#/c/284025/ 16:45:18 Sukhdev: thanks 16:46:30 sambetts, there is another one touching same code - https://review.openstack.org/#/c/287589/4 16:47:44 Different bugs too, but solving the same issue 16:47:55 I swear I saw another one over the weekend which touched the same code - can't seem to find the link now :-):-) 16:49:36 actually it was the same one - which vdrok posted - sorry 16:49:40 was it https://review.openstack.org/#/c/287589/ 16:50:17 it is the same one 16:50:58 interesting!!! 16:51:27 Yeah its an interesting problem, with a fairly simple solution 16:52:00 Anything else? 16:52:12 * Sukhdev time check 16:52:51 8 mins 16:53:06 I have one question.. 16:53:18 lazy_prince : sure 16:53:53 with the generic switch driver being pursued by the community, are we still going with vendor specific mech driver..? 16:54:13 or will everyone start contributing to the genericSwitch Driver..? 16:55:00 lazy_prince: vendor drivers can not be replaced with genericSwitch driver 16:55:07 HW vs. SW 16:55:14 And is there any plan to support SDN based solutions etc in GenericSwitch Implementation..? 16:55:45 Well.. GenericSwitch has support for Cisco switches as of now.. 16:56:36 lazy_prince: Does Cisco supports it - or stands behind it, if customers hit issues? 16:56:39 I just want to know the direction in which community is moving forward.. 16:56:43 The Cisco nexus ml2 driver has support for the BM binding type too, and that is where we (Cisco) are supporting our hardware 16:57:09 Sukhdev: we've not been involved in the devlopment of that driver as far as I'm aware 16:57:51 I think it was implemented by Mirantis folks 16:57:59 to do some testing 16:58:17 lazy_prince: this can never replace vender drivers - 16:58:31 so correct me if I am wrong.. So the GenericSwitch will be only used and recommended for Gate and Devstack based tests..? 16:58:48 lazy_prince : I will think so 16:58:58 or is it going to be recommended for production env as well.. 16:59:21 generic switch just does ssh into switch and runs some commands. any switch that supports the commands that it runs can be added 17:00:07 one could make it work for their specific environment/use case - but, it is not an answer to all 17:00:10 may be continue this discussion to netxt monday meeting.. since we are out of time.. 17:00:25 yup - I will add to the agenda 17:00:32 Thanks folks 17:00:41 we are out of time and done!! 17:00:43 bye 17:00:49 #endmeeting