16:01:16 <Sukhdev> #startmeeting ironic_neutron
16:01:17 <openstack> Meeting started Mon Oct 19 16:01:16 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:20 <Sukhdev> cragusa: hi
16:01:21 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:43 <jroll> morning
16:02:06 <Sukhdev> #topic: Agenda
16:02:09 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_October_19.2C_2015
16:02:19 <Sukhdev> #topic: Announcements
16:02:53 <Sukhdev> Next week is Summit - will see ya all there in Tokyo
16:03:00 <lazy_prince> o/
16:03:05 <lazy_prince> sorry a bit late..
16:03:15 <Sukhdev> No meeting next week - everybody will be in transit
16:03:19 <Sukhdev> lazy_prince: you are right on time
16:03:24 <lazy_prince> fine with me..
16:04:16 <Sukhdev> The week after Summit - some of us off as well traveling through Japan and others are travelling back home
16:04:36 <Sukhdev> So, I thought we cancel the meeting week after summit as well
16:04:46 <Sukhdev> any body has any objection to that?
16:05:31 * Sukhdev waiting
16:06:15 <Sukhdev> seems like there are no objections - so, next two weeks no meetings
16:06:20 <Sukhdev> we will resume on Nov 9th
16:06:29 <Sukhdev> Moving on with the agenda
16:06:40 <Sukhdev> #topic: Integration Status
16:07:21 <Sukhdev> I have had all kinds of problems after installing the latest set of patches
16:07:42 <Sukhdev> Last week was a big struggle to get a BM to boot
16:07:54 <Sukhdev> It turns out there is an issue with the Image -
16:08:32 <Sukhdev> jroll tried to help with the images, and I am chatting with lucas in the ironic channel with image related issues
16:08:56 <jroll> the prebuilt images should always work, ditto for the coreos builder. those are both CI'd extensively.
16:09:44 <Sukhdev> jroll: the lasted on Friday was that the node will get into the reservation lock as you mentioned
16:10:15 <Sukhdev> and the node will proceed further than wait-callback state
16:10:20 <jroll> Sukhdev: no, that's an edge case that can happen when code is broken, not a normal thing
16:10:29 <jroll> anyway, we can take that stuff offline
16:11:42 <Sukhdev> yes, we can take this after this meeting - need to undestand how to make forward progress on that
16:12:27 <Sukhdev> Other than this, I do not have any additional progress report to present
16:13:04 <Sukhdev> Anybody has anything else to share?
16:13:35 <lazy_prince> Can we ask all driver owners to validate if this works for them..
16:14:05 <lazy_prince> or if some drivers are broken, we can get that addressed in nick of time..?
16:14:24 <lazy_prince> just a thought..
16:14:52 <Sukhdev> lazy_prince: do we know if any other driver is using this other than HP and Arista?
16:15:12 <jroll> lazy_prince: ironic or neutron drivers?
16:15:24 <lazy_prince> I was more particular about ironic drivers..
16:15:36 <jroll> Sukhdev: also of note, I just proposed the Nova spec for this: https://review.openstack.org/#/c/237067/
16:15:56 <Sukhdev> #link: https://review.openstack.org/#/c/237067/
16:16:16 <Sukhdev> jroll: thanks - I'll review it after the meeting
16:16:23 <jroll> lazy_prince: we still don't have instructions for testing :(
16:16:36 <jroll> nor docs for configuration
16:16:56 <jroll> we'll need those before asking people to test it; I'd also like it for my own testing
16:17:39 <Sukhdev> jroll: cragusa has put out the initial version of the doc, we should help him beef it up
16:17:54 <lazy_prince> hmm.. I think we should take some time to complete those docs..
16:18:06 <jroll> Sukhdev: when I saw that it was just how to add portgroups :(
16:18:21 <cragusa> I actually have addressed Sukhdev comments, but need to check it before pushing it
16:18:56 <cragusa> I can do that tomorrow, if that's ok
16:19:02 <Sukhdev> jroll: we should have everything in this spec - so, that this become one "go to" place for all the answers
16:19:23 <Sukhdev> I mean from the ironic side of the documentation
16:19:31 <jroll> right
16:19:37 <lazy_prince> agree..
16:19:41 <jroll> well, everything a deployer needs to know, step by step
16:20:32 <Sukhdev> correct - if you see my comments on cragusa's spec, you will notice that I tried to elude to that - but, am sure I missed many steps
16:20:57 <Sukhdev> so, if we all chip in, we can get this beefed up with information
16:21:14 <cragusa> Sukhdev: tomorrow I'll push the updated version, ok?
16:21:32 <Sukhdev> cragusa: sounds good
16:22:06 <Sukhdev> We should all review Nova spec which jroll just mentioned - make sure we are all good with that as well
16:22:25 <Sukhdev> we should get it ratified before the summit
16:22:35 <jroll> it probably needs some updates, I spent a whole 15 minutes on it :P
16:22:59 <lazy_prince> :) will make sure to review it..
16:23:15 <Sukhdev> I will do it as well
16:23:27 <yhvh> me also
16:24:01 <jroll> thanks
16:24:17 <cragusa> me too
16:24:58 <Sukhdev> So, I think we have covered most of the items on the agenda - anybody wants to discuss anything else?
16:25:25 <yhvh> I answered a few comments on a patch, but I need to ask something
16:25:31 <Sukhdev> I will need help from jroll off-line to get past the issue that I am faced with so that I can make forward progress
16:25:48 <yhvh> it seems we need port/groups uuids to be unique, but how should this be enforced?
16:25:54 <Sukhdev> yhvh: please do
16:26:15 <jroll> why do we need them unique?
16:26:17 <jroll> or rather, where
16:27:13 <yhvh> https://review.openstack.org/#/c/206232/26/ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py
16:27:16 <yhvh> second comment
16:27:39 <yhvh> I also seem to remember a comment on another patch but haven't found yet, possibly neutron side?
16:27:47 <jroll> oh, so we need the mac address to be unique, not the uuid
16:27:55 <yhvh> sorry
16:28:22 <jroll> that's a great question
16:28:44 <jroll> so for the portgroups, is that mac address supplied by the client? (does it need to be?)
16:28:52 <jroll> I'm wondering if we can just generate those for the client
16:29:13 <yhvh> yes, provided by client
16:30:01 <jroll> is there a reason that needs to be sent by the client?
16:30:08 <jroll> or can we just generate them like neutron does
16:30:14 <yhvh> not that I know of
16:30:28 <jroll> I guess that still doesn't help...
16:30:41 <jroll> the only thing I can imagine is a query to check, but that gets racy
16:30:49 <jroll> actually.
16:31:02 <jroll> they don't need to be unique, right?
16:31:15 <jroll> if I have aa:aa and bb:bb, and put them into a portgroup
16:31:22 <jroll> I could have the portgroup mac be aa:aa
16:31:27 <lazy_prince> actually, they need to be . but i could be wron..
16:31:29 <jroll> because neutron will only ever see the group mac
16:31:53 <jroll> now, if I made the portgroup mac cc:cc, and had a port with NO group as cc:cc, that could be problematic
16:31:55 <Sukhdev> <port><mac> combo should be unique
16:31:58 <lazy_prince> say some node have only ports but others could have portgroup//
16:32:07 <jroll> yeah
16:32:30 <lazy_prince> so they could start stepping into each others mac ids..
16:32:53 <jroll> right
16:32:58 <lazy_prince> less likely but practically possible that they could land up in same network too..
16:33:06 <lazy_prince> which could be problematic..
16:33:23 <jroll> as terrible as it is, I'm inclined to think we should check the other table and let races happen if they happen
16:33:26 <jroll> and document it well
16:33:31 <jroll> I don't see a better way to do this
16:33:45 <yhvh> I saw a hack with foreignkeys, then a constraint on that?
16:33:54 <yhvh> just seemed a little ugly
16:34:05 <lazy_prince> or we say, only one of it can be active.. eith port or portgroups..
16:34:13 <jroll> yeesh, yeah I don't love that
16:34:25 <jroll> yhvh: like an intermediate table with macs?
16:34:57 <jroll> it isn't the worst idea, but I'm not a huge fan
16:35:20 <yhvh> like, portgroup has a relation to the address in port, and you can constrain on the values in foreignkey and local column
16:35:31 <jroll> devananda: ^ any thoughts? tl;dr what's the best way to enforce uniqueness of port.mac and portgroup.mac
16:35:58 <jroll> hmm
16:36:27 <jroll> deva used to build really fast databases in exchange for money, so I'd like to leverage his wisdom here
16:36:32 <jroll> whether he appears here or not
16:36:49 <yhvh> well if not I can ml and cc
16:37:31 <jroll> yeah, might be a good idea as others could chime in
16:37:41 <jroll> he'll respond eventually in irc, though
16:38:18 <Sukhdev> so, we deal with this kind of stuff in the switches as well - but, generally, it is user conrolled
16:38:29 <Sukhdev> I mean users configure it -
16:39:25 <baoli> just a thought, does a port group mac use one of the macs from its memebers? and the member macs are hardware macs in this case?
16:39:34 <Sukhdev> by virtue that <Port><mac> combo has to be unique, by defination, you can not screw it up
16:40:33 <lazy_prince> another thing i have is say how do we ensure that the mac ids are uniq across VM and baremetal..? We could still end up with a Mac id on BM allocated to a VM
16:40:33 <jroll> Sukhdev: a portgroup mac could still conflict with a port mac, if the port doesn't have a group
16:41:11 <jroll> lazy_prince: the deployer configures the MAC prefix used by virtual ports, and they should be using a prefix that isn't assigned to a manufacturer
16:41:28 <Sukhdev> I am not expert on this, but, I can go check with our experts to query as to how do we deal with this
16:41:29 <jroll> baoli: it may but is not required, and yes
16:44:14 <devananda> a wild devananda appears in a cloud of smoke
16:44:19 <devananda> jroll: ohhai!
16:44:22 <yhvh> lol
16:44:24 <jroll> haaaai
16:44:32 <Sukhdev> :-)
16:44:45 <Sukhdev> devananda: how wild?
16:44:46 <devananda> what do you mean "uniqueness of ..." ?
16:44:57 <jroll> devananda: https://review.openstack.org/#/c/206232/26/ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py
16:45:10 <jroll> devananda: imagine a port with no group with MAC aa:aa, and a portgroup with MAC aa:aa
16:45:20 <jroll> boom.
16:45:26 <devananda> heh
16:45:29 <devananda> so, unique across tables
16:45:32 <jroll> yah
16:45:44 <jroll> my best shot at it is an intermediate table with the mac addresses
16:45:49 <devananda> can be done. but not in a reasonable or supportable-across-databases kind of way
16:45:59 <devananda> jroll: how do you ensure that table is up to date?
16:46:01 <jroll> or eat the race conditions and validate in code
16:46:12 <jroll> eh?
16:46:31 <jroll> port: id | mac_id  portgroup: id | mac_id  macs: id | mac_addr
16:46:38 <jroll> mac_id fields are fk
16:46:46 <jroll> macs.mac_addr is unique constraint
16:46:57 <devananda> triggers, FKs
16:46:59 <devananda> yah
16:47:16 <devananda> jroll: but how do you know that there isn't a port AND a portgroup with the same MAC ?
16:47:26 <devananda> FK on those two table won't ensure that
16:47:28 <jroll> devananda: oh god
16:47:30 <jroll> yeah
16:47:32 <jroll> lol
16:47:41 <jroll> idk if this is solvable in 12 minutes, but some help would be cool :)
16:47:54 <devananda> right. I'll read the review. lets not try to solve it now
16:47:54 <jroll> 16:46:01          jroll | or eat the race conditions and validate in code
16:48:01 <jroll> ^ I don't love this idea but it will work :P
16:48:17 <devananda> it'll lead to a poor UX
16:48:29 <jroll> right
16:48:40 <devananda> question
16:48:48 <devananda> where does the MAC for a portgroup come from?
16:48:49 <jroll> another option is don't allow clients to supply portgroup.mac, but rather generate it
16:48:54 <devananda> heh
16:48:59 <jroll> reccomend prefixes that definitely aren't HW
16:49:02 <yhvh> devananda: client supplied
16:49:05 <jroll> recommend*
16:49:16 <devananda> can a switch require a specific MAC for a portgroup?
16:49:19 <devananda> or is it totally arbitrary?
16:49:28 <jroll> I have no clue
16:49:33 <jroll> it seems arbitrary
16:49:38 <devananda> what is the requirement within the network environment itself for the MAC address' uniqueness?
16:49:44 <jroll> generally you tell the switch what the MAC is for the MLAG or whatever
16:49:54 <devananda> eg, what happens if there are two switches and each has a portgroup with the same mac ?
16:49:55 <devananda> seems bad
16:49:59 <jroll> and the last question will depend on the deployment, I suspect
16:50:04 <devananda> and seems like a problem that network folks have already solved
16:50:19 <jroll> in our v2 deployment I think it would work as there's L2 -> VXLAN translation in the switch
16:50:25 <devananda> Sukhdev: ^ ?
16:50:40 <Sukhdev> This is a well understood and solved problem by all switch vendors - I can go ask our experts how we deal with this and share with the team next meeting
16:50:43 <jroll> (I think, I don't actually know what the group mac would do there)
16:50:53 <devananda> jroll: ok. so portgroup must be unique withinthe VXLAN
16:50:55 <jroll> Sukhdev: "next meeting" is three weeks from now :P
16:51:06 <devananda> still seems like "just let the client set it" is not a great approach
16:51:09 <jroll> devananda: yeah, I think so
16:51:11 <jroll> right
16:51:14 <jroll> especially if they don't need to
16:51:17 <Sukhdev> jroll: Opps - I can post on the review - as a comment
16:51:24 <jroll> thanks
16:51:37 <devananda> ironic or neutron API could accept a MAC then have it rejected by the switch because oops-not-unique-in-the-VXLAN
16:51:56 <jroll> I think neutron might reject it at that point, but that's still too late
16:52:33 <Sukhdev> devananda: actually, in my Ironic testing, I often see error message saying mac address is already in use
16:52:42 <devananda> Sukhdev: o.0
16:53:07 <Sukhdev> this happens if Ironic driver drive does not clean neutron ports and tries to reuse upon an new launch of VM
16:53:14 <jroll> yeah
16:53:20 <jroll> that's a nova->neutron thing
16:53:28 * jroll has been there
16:53:43 <devananda> ugh
16:53:51 <Sukhdev> yup - so, it is checked somewhere
16:54:02 <devananda> well, feel free to move on. i've got enough now to think about the db side of this, but wont have an answer right away
16:54:04 <jroll> but "deploy time" is too late, regardless.
16:54:24 <jroll> yeah, I need to bounce as well and stretch my legs before next meeting
16:54:55 <jroll> good meeting, thanks Sukhdev
16:55:15 <Sukhdev> Thanks folks this was a great discussion
16:55:23 <yhvh> yes thanks all
16:55:25 <Sukhdev> We will see each other in Tokyo next week
16:55:32 <cragusa> thanks
16:55:45 <Sukhdev> bye
16:55:52 <Sukhdev> #endmeeting