16:01:32 <Sukhdev> #startmeeting ironic_neutron
16:01:33 <openstack> Meeting started Mon Jan 25 16:01:32 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:37 <openstack> The meeting name has been set to 'ironic_neutron'
16:02:12 <Sukhdev> Good morning folks
16:02:42 <Sukhdev> #topic: Agenda
16:02:49 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_January_25.2C_2016
16:02:58 <jroll> morning
16:03:05 <vsaienko> morning
16:03:12 <Sukhdev> I kept the same agenda as last week - as we ran out time last week
16:03:18 <sambetts> o/
16:03:35 <Sukhdev> #topic: Announcements
16:03:45 <davidlenwell> o/
16:03:55 <Sukhdev> Anybody has anything they would like to share with the team before we get started?
16:03:55 <jroll> so before we dive in, just making a note that I've updated the last nova patch: https://review.openstack.org/#/c/206163
16:04:11 <jroll> we may need to apply for FFE on that, I need to bug john about it
16:04:35 <Sukhdev> jroll : cool thanks
16:04:38 <jroll> np
16:05:12 <Sukhdev> jroll : timing is great - I am in the middle of updating my test setup - will upload it and test it
16:05:22 <jroll> cool
16:05:33 <Sukhdev> Any other announcement?
16:05:35 <jroll> here's the weird part;
16:05:42 <jroll> that's going to depend on an ironicclient release
16:05:51 <devananda> o/
16:06:03 <Sukhdev> oh - any specific version?
16:06:05 <jroll> so landing it might get weird, because that code is still way down the road
16:06:12 <jroll> also will depend on the api changes landing
16:06:23 <jroll> the version that's released with the portgroup code...
16:06:33 <devananda> ugh, right. and the API changes in ironic do not look right to me yet
16:06:37 <devananda> that's something i wanted to talk about today
16:06:39 <jroll> so we need to review all the things asap
16:06:41 <jroll> cool
16:06:48 <jroll> just wanted to point that out, we can move on :)
16:07:15 <vsaienko> I also have a question about portgroup and port UUIDs
16:07:22 <Sukhdev> jroll : I will ping you off-line if I need help in getting this tested
16:07:36 <jroll> ok
16:07:41 <vsaienko> As Ruby mentioned https://review.openstack.org/#/c/206245/ we could have a problem
16:08:06 <vsaienko> because we do not guarantee that portgroup/port uuids are unique
16:08:08 <Sukhdev> vsaienko: I wanted to cover that as well - thanks for brining it up
16:08:55 <Sukhdev> vsaienko : I was not very clear about the comment - and was bit confused
16:09:15 <Sukhdev> vsaienko: if you understand the issue, can you elaborate?
16:10:00 <jroll> I don't see a reason not to change the return format, fwiw
16:10:28 <jroll> and I think that's the clearest path forward
16:10:45 <vsaienko> jroll, but how we should identify it is a neutron port for port or portgroup in case portgroup.uuid == port.uuid
16:11:09 <jroll> vsaienko: sure, return {portgroups: {uuid: vif_id}, ports: {uuid: vif_id}}
16:11:30 <devananda> jroll: changing the return format => affecting drivers
16:12:00 <jroll> devananda: no
16:12:07 <jroll> this is used in ironic.dhcp.neutron
16:12:12 <devananda> oh, cool
16:12:35 <devananda> you're right
16:12:37 <jroll> we *may* affect out of tree dhcp things, but we don't guarantee the ironic.common.network interface
16:12:50 <jroll> I'm inclined to not worry too much
16:12:50 <devananda> yah, i'm fine with that. I was thinking of a different call
16:12:53 <jroll> mhm
16:13:25 <devananda> and typed before grepping to confirm ...
16:14:52 <Sukhdev> make sense
16:14:59 <jroll> I replied on the diff and changed my vote
16:15:47 <vsaienko> jroll, I will change return format there.
16:15:53 <jroll> cool
16:15:57 <jroll> thanks
16:16:35 <vsaienko> jroll, what about vifs in update_dhcp_opts () https://github.com/openstack/ironic/blob/06d39ed5ca398540b587d41a16d1572cb085727f/ironic/dhcp/neutron.py#L144
16:16:52 <vsaienko> should we use the same format {portgroups: {uuid: vif_id}, ports: {uuid: vif_id}} for it?
16:18:18 <jroll> vsaienko: those come from the method we're talking about...
16:18:20 <jroll> https://github.com/openstack/ironic/blob/06d39ed5ca398540b587d41a16d1572cb085727f/ironic/dhcp/neutron.py#L165
16:18:28 <jroll> so yes it will affect that method
16:19:48 <devananda> k
16:19:54 <devananda> (wrong window)
16:20:01 <Sukhdev> :-)
16:21:01 <Sukhdev> Do we need to discuss any further on this? or shall we move on to API issue that devananda brought up earlier
16:21:56 <Sukhdev> I will take silence as - lets move on :-)
16:22:19 <Sukhdev> devananda : what did you want discuss about API changes?
16:23:14 <devananda> Sukhdev: the API changes and new REST resources, eg /portgroups/ -- they aren't being encapsulated for backwards compat
16:24:08 <Sukhdev> devananda : I thought portgroups did not exist before (not expert on the ironic side of this)
16:24:17 <devananda> correct
16:24:30 <Sukhdev> so, no bacward compat issue :)
16:24:43 <devananda> and after this change lands, if an old client invokes GET /v1/NNNN/portgroups/
16:24:46 <devananda> it should not see it
16:25:19 <jroll> right, so we need to 404 on old api versions, yes?
16:25:28 <devananda> jroll: I think so
16:25:31 <jroll> is there a larger problem here or does the patch just need extra work?
16:26:06 <devananda> jroll: I don't offhand know how to do that in wsme - it may be easy. or not.
16:26:11 <devananda> because it's part of hte root controller
16:26:17 <jroll> ooo. fun.
16:26:21 <devananda> we haven't added any new root objects before :)
16:26:23 <Sukhdev> wait a minute - the old client won't know about portgroups - why would it invoke?
16:26:29 <jroll> there's probably a hack we can do
16:26:50 <jroll> Sukhdev: not old ironicclient versions, rather api clients talking to older versions
16:27:08 <jroll> devananda: worst case, in the controller, we could raise some 404 error if api version isn't high enough
16:27:12 <Sukhdev> oh I see
16:27:18 <devananda> jroll: hm. that might work
16:28:56 <devananda> that was it for me. sounds like jroll and I have a little experiment to run
16:29:06 <devananda> and then we'll leave feedback on the API patch
16:29:24 <jroll> +1
16:29:39 <Sukhdev> sounds good
16:29:50 <Sukhdev> Anything else on the patches?
16:30:01 <Sukhdev> I noticed updated version of the patches got pushed -
16:30:21 <Sukhdev> I will be uploading them all today - timing is just perfect
16:30:32 <jroll> uploading theM?
16:30:38 <Sukhdev> will test them all out and post the issue, if I see
16:30:57 <jroll> ah ok
16:31:29 <Sukhdev> Anything more to discuss on the patches?
16:32:06 <jroll> I have nothing
16:32:14 <Sukhdev> Moving on to the next topic - we ran out time last time
16:32:50 <Sukhdev> #topic: Ironic Inspector and format of switch-id
16:33:04 <jroll> sambetts: you here?
16:33:07 <sambetts> yup
16:33:10 <jroll> ah cool
16:33:15 <Sukhdev> sambetts : we could not finish the discussion last time
16:33:53 <Sukhdev> so, the idea behind using switch-id format as mac was
16:34:26 <Sukhdev> that the mac address is tied to the chassis and will not change - but, any other identifier can change - e.g. IP, hostID, etc
16:34:53 <Sukhdev> yhvh- : are you here as well?
16:34:56 <yhvh-> yup
16:34:59 <Sukhdev> good
16:35:22 <jroll> so while I do understand that, I don't think mac address is a useful identifier as it's difficult to find a switch in a datacenter by mac address, whether you are a human or a computer
16:35:24 <sambetts> I see that, but in ML2 our driver identifies switches by mgnt ip
16:35:45 <Sukhdev> sambetts : if you see - https://etherpad.openstack.org/p/liberty-ironic-network-isolation
16:35:55 <sambetts> so forcing it to mac address will mean our ml2 driver will simply have to ignore that field
16:36:07 <Sukhdev> lines 14 - we discussed that during the summit
16:36:29 <Sukhdev> sambetts : one does not have to use all three fields -
16:37:10 <sambetts> it would be nice not to ignore a top level field though, because other wise we might as well remove switch_id and have switch info only
16:37:12 <Sukhdev> those three fields are for vendors - as long as the vendor is producer and consumer - there is no issue (
16:37:29 <jroll> sambetts++
16:38:22 <Sukhdev> sambetts : switch-info is for vendor to pack anything they want - IP, model number, etc...
16:38:52 <Sukhdev> for example : you may have 3K and 9K chassis - you can use switch-info to identify
16:39:12 <Sukhdev> so that you can use appropriate ML2 driver (if you have different for 3k and 9k)
16:39:22 <Sukhdev> to provision the HW
16:39:36 <sambetts> but why can't I use switch_id to identify... I don't see a reason to restrict it
16:39:52 <jroll> I don't think mac address is a useful identifier as it's difficult to find a switch in a datacenter by mac address, whether you are a human or a computer
16:39:56 * jroll repeats himself
16:40:42 <Sukhdev> I thought about it a bit after our meeting last week - what if we make those as strings
16:40:59 <sambetts> I think that would provide the most flexablity
16:41:02 <Sukhdev> i.e. both switch-id and switch-info becomes strings -
16:41:36 <Sukhdev> yhvh-: your thoughts on this?
16:41:48 <sambetts> jroll mentioned the use of host names in there too so that would provide for that case too
16:42:03 <jroll> right, we use host names downstream
16:42:15 <yhvh-> I'd need to check all uses of switch_id, anyone else have insight?
16:42:42 <jroll> again, my problem is that a mac address doesn't say anything about how to connect to the switch
16:44:07 <Sukhdev> jroll : this is how I was thinking - lldp provides the mac address. when an operator plumbs the HW wiring it says it connected port X to switch Y
16:44:37 <Sukhdev> switch Y (Y may be IP or hostid, etc, which goes into the switch-info)
16:44:41 <jroll> which forces every ML2 driver to have something in switch_info
16:44:41 <jroll> rather than switch_info being used for fancy things
16:45:09 <sambetts> jroll++
16:45:13 <jroll> I mean, I understand why we did it this way
16:45:35 <Sukhdev> and then switch-id can be used by topology cross check to make sure switch Y is what is reported by lldp
16:46:38 <Sukhdev> I can see how this could create confusion - if we made them all strings, then it is free-for-all - use it the way it works for you
16:47:13 <jroll> yeah, now that I think more I think switch_id just isn't useful as its own field :)
16:47:59 <sambetts> yeah I think that works best for switch-id, I thought switch_info was going to be a more complex structure than a string, like a dict, I guess it can be json.dumped
16:48:16 <jroll> I'd almost rather kill switch_id and have switch_info: {mac_addr: foo, hostname: foo, ...{
16:48:54 <sambetts> for our ml2 case, we only need the mgnt IP to identify a switch, because all other info is stored in the ml2 .ini config file
16:50:23 <Sukhdev> sambetts : that is very specific - we discover everything dynamically - and do not rely on config stuff (as it is subject to human errors) :-)
16:51:42 <sambetts> how do you deal with authentication? because we could discover everything we need to plumb a BM via lldp, except usernames and passwords we still need the config file for that
16:52:30 <Sukhdev> sambetts: for that you need to read Arista's CloudVision - it will tell you how the magic happens :-)
16:53:02 <jroll> sambetts: so, switch_id being a mac address doesn't block you, it's just annoying right?
16:53:09 <Sukhdev> sambetts : there are several ways to deal with it - but, that is a discussion of some other meeting :)
16:53:34 <sambetts> jroll: pretty much, just means we'll end up using switch_info for everything and ignoring switch_id
16:53:53 <Sukhdev> sambetts : that would work
16:54:31 <jroll> sambetts: I say we just keep moving forward for now then, the validation is just in code, not in db yeah?
16:54:31 <Sukhdev> sambetts : in our case, we do not rely much on switch_info (we just stuff model info, etc) - in other words, we use only two fields as well -
16:54:54 <yhvh-> There are knock on effects, it would be nice to have a common usage for these fields, for example, for the inspector additions in IPA would require HW managers to pack the info as the ml2 driver expects
16:54:59 <Sukhdev> but, we wanted to provide both - as some people had made a case during the summit discussion that both were needed
16:55:18 <jroll> we can always make this less restrictive later, I'd prefer to just roll forward
16:55:33 <Sukhdev> jroll +1
16:55:38 <yhvh-> +1
16:56:49 * Sukhdev time check - 4 min left
16:56:55 <sambetts> ok as long as there is a consensus, is it possible for someone to write up something that tells us the restrictions/validations of the local-link-info field so that we can program around them?
16:57:14 <sambetts> the spec isn't very clear on them
16:57:27 <jroll> sambetts: maybe leave that comment on the docs patch
16:57:54 <sambetts> good shout, I'll go do that
16:57:56 <jroll> I have to run, thanks for the good meeting yall
16:58:12 <Sukhdev> sambetts : its been a while since I looked at this - see, if this addresses it - https://review.openstack.org/#/c/228496/2/doc/source/deploy/install-guide.rst
16:58:37 <Sukhdev> jroll : thanks - will catch you later
16:59:22 <sambetts> Sukhdev: thats ok from the ironic side, but I'm thinking about more from the neutron dev side I would be nice to know what to expect in the binding_profile
17:00:09 <Sukhdev> sambetts : oh I was suppose to push a patch for documenting that - completely forgot :-)
17:00:26 <sambetts> Sukhdev: oh great! I look forward to seeing it
17:00:31 <Sukhdev> sambetts : I had started it - will look for it, complete it, and push it
17:00:45 <Sukhdev> sambetts : no worries
17:00:52 <Sukhdev> Folks, we are out of time -
17:00:56 <Sukhdev> thanks for attending -
17:00:57 <sambetts> thanks for having this discussion
17:01:04 <sambetts> o/
17:01:05 <Sukhdev> bye
17:01:09 <Sukhdev> #endmeeting