16:01:23 <Sukhdev> #startmeeting ironic_neutron
16:01:23 <openstack> Meeting started Mon Jan 11 16:01:23 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:27 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:33 <jroll> \o
16:01:41 <vsaienko> \o
16:01:46 <Sukhdev> #topic: Agenda
16:01:52 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_January_11.2C_2016
16:02:00 <devananda> o/
16:02:18 <Sukhdev> Folks have a look at the agenda and feel free to add anything that you would like to include
16:02:27 <Sukhdev> #topic: Announcements
16:02:44 <vdrok> o/
16:02:48 <Sukhdev> I do not have any announcement this morning, If you have one, please do so
16:03:10 <Sukhdev> If none, lets dive into the agenda
16:03:26 <Sukhdev> #topic: Integration Status
16:03:43 <Sukhdev> I started to test the solution as well
16:03:52 <Sukhdev> and noticed one issue with the API version
16:04:14 <jroll> I saw that, you just need to pass --ironic-api-version 1.14
16:04:17 <jroll> (or latest)
16:04:19 <Sukhdev> I have added item 14 at the bottom of the etherpad -
16:04:51 <Sukhdev> jroll : you mean additional parameter to the CLI?
16:04:56 <jroll> Sukhdev: yes
16:05:05 <Sukhdev> oh I see - cool
16:05:21 <Sukhdev> then this is not an issue :-)
16:05:40 <yhvh> excellent :)
16:06:02 <Sukhdev> jroll : How to tell which is the latest version?
16:06:25 <jroll> Sukhdev: the error message tells you - also, passing the string "latest" gives you latest available
16:07:02 <Sukhdev> oh I see - something new I learned this morning
16:07:09 <Sukhdev> Thanks jroll for clarifying
16:07:15 <jroll> np
16:07:46 <Sukhdev> other than that I do not have anything else to report on the integration testing
16:08:12 <devananda> fwiw, I wasn't able to do more testing during the last week
16:09:00 <Sukhdev> I will continue to proceed and will report as I move along
16:09:24 <vdrok> I've tested it in ubuntu and tried in fedora, in ubuntu everything works fine for me
16:09:51 <vdrok> there was one issue in fedora, vsaienko fixed it already
16:10:02 <vdrok> so will try once again
16:11:11 <Sukhdev> vdrok : what issue with fedora?
16:11:33 <Sukhdev> We have been testing with fedora in the past and it was working for us
16:11:34 <devananda> it seems to be working for me with ubuntu w/ devstack and agent_ssh driver. my next step is trying to spin it up on hardware - but that might take a little more time - and reviewing all the code this week
16:11:36 <vdrok> mac address was grepped with HWaddr
16:11:51 <vdrok> which works in ubuntu
16:11:59 <vdrok> but in fedora it is output as ether
16:12:33 <Sukhdev> oh I see
16:12:45 <vdrok> it may have been added in one of more recent vsaienko patches
16:13:36 <vsaienko> sukhdev: I think you have tested patches on hardware servers right?
16:13:48 <devananda> vsaienko: have there been any significant changes t othe patch chain in the last week?
16:13:50 <Sukhdev> vsaienko : correct
16:15:18 <Sukhdev> My most of testing has been keeping the real world deployment scenarios in mind - which means all on real HW
16:15:28 <vsaienko> devananda: almost all changes were done at https://review.openstack.org/#/c/139687
16:16:22 <vsaienko> sukhdev: could you please have look at my comments https://review.openstack.org/#/c/139687/42/ironic/networks/neutron_plugin.py
16:16:39 <devananda> vsaienko: thanks. I will review that later today
16:17:01 <jroll> Sukhdev: can you link me the arista ml2 thing that supports this, in case I get a free day to try this on hw?
16:18:25 <Sukhdev> jroll : you need two things - latest ML2 patch, which is posted on networking_arista repo, and latest EOS image - which is not available
16:18:27 <lazy_prince> well... vsaienko, that is there to help ML2 perform LAG configuration.. although we are not aiming for that in first cut...
16:18:58 <jroll> Sukhdev: what EOS version, in case we do have it around? :)
16:19:05 <lazy_prince> but if someone wants to start early, it will help..
16:19:06 <devananda> jroll: I'd like to propose a plan on how (process-wise) we land all these patches, unless you have one in mind already?
16:19:07 * jroll also curious why switches need code updates to work with this
16:19:07 <Sukhdev> vsaienko : I will review and provide the feedback
16:19:14 <jroll> devananda: fire away
16:19:34 <Sukhdev> jroll : you do not have it - it is not out yet (still under test)
16:19:49 <vsaienko> jroll: we can easily add support of arista switch to generic_switch driver
16:20:12 <jroll> Sukhdev: oh, I think we get test versions sometimes, which is why I ask
16:20:51 <devananda> I'd like to put a procedural -2 on two of the patches: the first one in the portgroup internals https://review.openstack.org/#/c/206232/51 and the first one after that https://review.openstack.org/#/c/139687/44
16:21:09 <Sukhdev> jroll : with this, we are adding native vlan support, which is presently not available
16:21:24 <Sukhdev> jroll : also, it is the CVX that requires updates
16:21:25 <devananda> when all the internal changes have enough +2's, I'll flip the -2 on the first one and land those together
16:21:40 <jroll> Sukhdev: aha, got it. thanks.
16:22:14 <Sukhdev> devananda : that makes sense.
16:22:21 <devananda> and then we focus reviews on the changes after that (eg, the external-facing stuff, docs, devstack support)
16:22:41 <devananda> if at that point we discover that we need to change internals, it's less to rebase
16:22:45 <jroll> devananda: I tend to think the API patch is 'external facing'
16:23:41 <devananda> jroll: definitely agree. can we disable the visibility of that change, or move it to the end of the first set of patches?
16:24:03 <jroll> devananda: yeah, we could switch it with the "net" patch
16:24:17 <devananda> https://review.openstack.org/#/c/139687/44 also has an API change
16:24:48 <jroll> right, but that's part of the 'external' patches you pointed out
16:25:10 <devananda> yah
16:25:14 <devananda> ok, so three phases
16:25:17 <devananda> 1. internal changes
16:25:24 <devananda> 2. API changes
16:25:33 <devananda> 3. devstack changes
16:25:44 <jroll> sounds good
16:25:54 <devananda> vsaienko: can you rebase the patches into that order?
16:25:55 <jroll> though I wouldn't block 3, we should land those quickly
16:26:03 <jroll> also
16:26:10 <vsaienko> devananda: sure
16:26:11 <jroll> 4. docs? or 3. docs 4. devstack?
16:26:19 <devananda> 3. api and docs?
16:26:24 <devananda> er, 2
16:26:26 <yhvh> and client?
16:26:28 <jroll> ++
16:26:46 <jroll> client should land just after api, I guess
16:26:54 <devananda> tempest test support for the API changes is needed too
16:27:01 <killer_prince> or probably together..
16:27:16 <devananda> which, now that we're moving to tempestlib, should get added to ironic (not tempest)
16:28:33 <Sukhdev> M1 is this week some time, right?
16:28:49 <Sukhdev> can we get all the internal patches merged this week?
16:29:06 <jroll> M2 is next week
16:29:21 <Sukhdev> ah good - few more days :-)
16:30:07 <Sukhdev> Anything else we need to discuss about patches or integration testing?
16:30:24 <Sukhdev> Anybody else has anything to share about their testing?
16:30:27 <devananda> we need https://review.openstack.org/#/c/252814/ to land
16:30:38 <devananda> so that we can test the patch chains in the gate prior to landing them
16:30:46 <jroll> +1
16:31:08 <devananda> experimental pipeline is fine for now -- but the job needs to exist and needs to pass
16:31:08 <jroll> devananda: I kind of wanted to get eyes on some of the devstack work, so we don't end up needing to change variables in that patch later
16:31:10 <jroll> [/b 57
16:31:12 <jroll> oops
16:31:32 <devananda> jroll: I agree, except, isn't that moving into ironic's tree?
16:31:39 <jroll> devananda: project-config?
16:31:44 <devananda> devstack work
16:31:50 <jroll> the devstack patches are in our tree
16:31:53 <jroll> but I don't want to add the job
16:31:57 <devananda> oh?
16:32:10 <jroll> and then have someone say "well let's s/NETWORK/NET everywhere"
16:32:20 <jroll> yes, they are proposed to the ironic tree
16:32:28 <devananda> right
16:32:49 <devananda> actually, I was thinking of tempest just now. we're moving ironic to tempest-lib
16:33:04 <devananda> jroll: how soon do you think that migration will be complete?
16:33:30 <jroll> devananda: the patch moving the tests had 2x +2 before I updated for pep8
16:33:40 <jroll> so, today if I can get reviews on it :)
16:33:41 <devananda> let's get thta landed ASAP then. like today
16:33:49 <devananda> and then move the portgroup-api tempest changes into our tree
16:34:02 <jroll> yep
16:34:17 <jroll> we could even put them in the same patch as the api changes \o/
16:34:45 <devananda> wat? :-)
16:35:00 <devananda> but yes, that is what we should do
16:35:04 <jroll> yeah
16:36:37 <Sukhdev> jroll : going back to your earlier comment - just to make sure I understood - in order to land the project-config patch, you need to review devstack patches or get them merged?
16:37:11 <jroll> Sukhdev: we need to review the devstack patches enough to say the variables here won't change https://review.openstack.org/#/c/252814/1/jenkins/jobs/devstack-gate.yaml
16:37:39 <jroll> it's probably fine but I could see someone -1'ing IRONIC_LLC_ENABLED, for example
16:38:02 <Sukhdev> ah I see -
16:38:22 <vsaienko> jroll: I have a question about generic_switch driver
16:38:31 <jroll> yes/
16:38:50 <vsaienko> currently devstack relies on it, is it possible to create a repo at openstack.org for it?
16:39:00 <jroll> yes it's possible
16:39:03 <jroll> that's your repo right?
16:39:11 <vsaienko> right
16:39:17 <jroll> just follow http://docs.openstack.org/infra/manual/creators.html
16:39:28 <vsaienko> jroll: I'll prepare all necessary patches for it
16:40:07 <jroll> vsaienko: cool, thanks
16:40:55 <Sukhdev> yuriy - are you here?
16:42:19 <Sukhdev> vsaienko : do you know if yuriy was able to make progress on the tempest scenario testing patch?
16:43:13 <vsaienko> sukhdev: he told me that patch is working, and he will move it to devstack repo
16:43:34 <Sukhdev> excellent
16:43:36 <Sukhdev> thanks
16:44:17 <Sukhdev> vsaienko : please have him add a link to the etherpad as well (or update it)
16:44:39 <vsaienko> ok
16:44:40 <Sukhdev> #topic: Open Discussion
16:45:04 <Sukhdev> I think we covered all the agenda items - anything else we want to discuss?
16:45:41 <Sukhdev> jroll, devananda : I see +2's on the patches, they need +1 on work flows
16:46:09 <jroll> Sukhdev: re-read devananda's earlier proposal about landing things together
16:46:33 <Sukhdev> perhaps based upon ordering we discussed earlier we start landing them
16:46:39 <Sukhdev> :-)
16:46:58 <sambetts> I wanted to bring up the inspector lldp work thats going on, there are a couple of comments on it that I think need a look in by the rest of the neutron-ironic devs is you've got some cycles
16:47:21 <yhvh> The intern I have working on that has exams this week
16:47:31 <yhvh> he is making decent progress
16:48:35 <Sukhdev> yhvh : are you targeting it for M or N release?
16:49:15 <sambetts> the current logic for it seems to imply that all the switch information set via lldp information will be the same among vendors, are we expecting to have a generic data and let the ml2 driver convert it to vendor specific or process the lldp data into vendor specific data stored in ironic
16:49:35 <yhvh> sambetts: yes I saw this comment, makes sense
16:50:01 <yhvh> Sukhdev: just asap
16:51:38 <Sukhdev> sambetts: the idea is that provide enough flexibility so that vendors can stuff information into these fields in such a way that they have appropriate information their ML2 drivers to provision the switches
16:51:51 <sambetts> I've had a few discussions about the lldp with others and we think that having the ramdisk return the whole lldp packet and having vendor specific lldp inspector processing plugins makes the most sense to us, does this make sense?
16:52:56 <sambetts> then the vendors can put these plugins whereever they want, even store them in networking-* as they are quite closely related to their ml2 drivers
16:53:49 <Sukhdev> sambetts : you are referring to local_link_information, right?
16:54:37 <Sukhdev> lldp is widely deployed, and hence, does provide great automation - hence, we had proposed to use this model -
16:55:10 <Sukhdev> but, only for the mac addresses format for the switch-id, discovered through inspecter
16:55:14 <sambetts> yeah, so switch_id, port_id etc could be different per vendor, e.g. we (Cisco) will most likely be using the management address as the id for the switch
16:55:50 <Sukhdev> sambetts : management address represented in mac address format, right?
16:56:18 <sambetts> no IP address, because thats how our ml2 driver identifies switches
16:57:08 <Sukhdev> sambetts : there are two fields - switch ID and switch Info - the IP address can go into switch info, which does not have to conform to mac address format (it is just a string
16:57:37 <sambetts> but then switch-id is a dead field to us
16:57:43 <Sukhdev> the switch-id is in a mac address format
16:58:04 <Sukhdev> sambetts : oh I see -
16:58:29 <jroll> yeah, mac address as switch id is odd to me
16:58:48 <sambetts> we also talked about using a dns name in that field
16:59:04 <Sukhdev> sambetts : we may have to make one change to accomodate it then
16:59:24 <jroll> sambetts: our downstream networks code uses hostnames there
16:59:33 <Sukhdev> sambetts : we can make both switch id and info as strings
17:00:10 <Sukhdev> sambetts : since we are running out of time, let me put this on agenda Item for next week's meeting
17:00:13 <yhvh> to nitpick switch_id is a mac or openflow datapathID
17:00:33 <Sukhdev> sambetts: lets discuss and get a closure on this in next meeting then
17:00:49 <Sukhdev> Folks, we are out of time -
17:00:50 <sambetts> Ok, thanks this will be a great help
17:01:05 <Sukhdev> I will add this to the agenda for next week and discuss it then
17:01:10 <Sukhdev> Thanks for attending
17:01:12 <Sukhdev> bye
17:01:18 <Sukhdev> #endmeeting