| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-29 | |||
| 16:26:46 | sean-k-mooney | mlavalle: cells is a nova only ting. neutron has availablity zones. if you had a different neutron availableity zone per cell can a netowrk span neutron availablity zones | |
| 16:27:53 | mriedem | i would think, | |
| 16:28:02 | sean-k-mooney | mlavalle: well we are talking about cross cell cold migration so jsut like the live migration case we will have multiple port bindings so from a neutron point of view it should be identical | |
| 16:28:03 | mriedem | when we have an attached port, bound to the source host, | |
| 16:28:09 | mriedem | nova puts the az on the port binding information, | |
| 16:28:19 | mriedem | and neutron would be relying on that to know if we can bind to another host in another a | |
| 16:28:21 | mriedem | *az | |
| 16:28:24 | mlavalle | sean-k-mooney: that is what I say | |
| 16:28:24 | jaypipes | mriedem: I have a sneaking suspicion this patch is the cause: https://github.com/openstack/nova/commit/c9b74bcfa09d11c2046ce1bfb6dd8463b3a2f3b0 | |
| 16:28:37 | mriedem | jaypipes: that's only in master | |
| 16:28:41 | mriedem | zigo is hitting this in rocky | |
| 16:28:49 | sean-k-mooney | mlavalle: yep i am agreeing :) | |
| 16:28:59 | mlavalle | sean-k-mooney: LOL | |
| 16:29:16 | mriedem | btw, is it strange we don't have a cross_az_attach=False thing for nova/neutron like we have for nova/cinder? | |
| 16:29:17 | mlavalle | sean-k-mooney: will you be in Denver? | |
| 16:29:21 | sean-k-mooney | mriedem: neutron does not use the nova AZ as part of port bininging just the hostname | |
| 16:29:40 | sean-k-mooney | mlavalle: yes i will | |
| 16:29:43 | mriedem | so why do we set the device_owner on the port? | |
| 16:29:46 | mlavalle | Great! | |
| 16:29:47 | mriedem | using the instance az? | |
| 16:30:42 | mlavalle | because you want to keep track of where it is, on the Nova side, but I am just speculating | |
| 16:30:43 | sean-k-mooney | mriedem: that is a good question to which i do not know the answer | |
| 16:30:54 | mriedem | it might be used by the neutron callback code | |
| 16:31:10 | jaypipes | mriedem: oh... I thought you said this only recently occurred.. | |
| 16:31:26 | mriedem | jaypipes: it is only recently reported | |
| 16:31:35 | mriedem | but i also thought about that _update change but it's master only | |
| 16:31:39 | mriedem | and zigo said he's hitting it on rocky | |
| 16:31:55 | sean-k-mooney | mriedem: im pretty sure its not used by neutron at all. my geuess is this might be from nova networks and we just kept doing it | |
| 16:32:08 | sean-k-mooney | the AZ that is | |
| 16:32:16 | jaypipes | mriedem: ack | |
| 16:32:18 | mriedem | nova net doesn't have any kind of device_owner thing | |
| 16:32:41 | mlavalle | yeah, the device_owner stuff is a Neutron port concept | |
| 16:32:45 | sean-k-mooney | mriedem: oh i was going to specalte we might of needit to do the nova-net multhost thing | |
| 16:32:52 | mriedem | bingo http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py#n77 | |
| 16:32:57 | mriedem | it's what i said it was | |
| 16:33:44 | mriedem | among apparently a lot of other things | |
| 16:33:59 | sean-k-mooney | mriedem: i dont see why we need the az form that | |
| 16:34:05 | mriedem | we probably dont | |
| 16:34:18 | mlavalle | there we only use the compute prefix | |
| 16:34:46 | mlavalle | as we do in other places of the code | |
| 16:35:19 | mriedem | probably explains why https://launchpad.net/bugs/1759924 isn't that big a deal | |
| 16:35:19 | openstack | Launchpad bug 1759924 in OpenStack Compute (nova) "Port device owner isn't updated with new host availability zone during unshelve" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 16:35:22 | mriedem | except it causes confusiong | |
| 16:35:24 | mriedem | *confusion | |
| 16:35:38 | sean-k-mooney | mriedem: silvanb is still on pto but i was discussing this with him a few weeks ago about should we remove setting it or not | |
| 16:35:56 | mriedem | bauzas you mean? | |
| 16:36:05 | sean-k-mooney | mriedem: yes | |
| 16:36:26 | mriedem | if there is one thing sylvain loves to talk about more than cheese and skiing, it's AZs | |
| 16:36:48 | mlavalle | LOL | |
| 16:36:54 | jaypipes | mriedem: zigo's using libvirt, right? | |
| 16:36:58 | mriedem | yup | |
| 16:37:00 | jaypipes | k | |
| 16:37:01 | sean-k-mooney | there was concern over is allowing livemigation across availablity zones breaking the contract with a user. | |
| 16:37:23 | mriedem | well that reminds me of another bug fix https://review.openstack.org/#/c/567701/ | |
| 16:37:44 | sean-k-mooney | there are some open bugs where instances with floating ips break if you do this. | |
| 16:38:08 | mriedem | with neutron dvr? | |
| 16:38:11 | mriedem | or just in general? | |
| 16:38:45 | sean-k-mooney | i think it was in general. i should find out i will check when i have my live migration setup running again | |
| 16:40:35 | sean-k-mooney | mriedem: mlavalle actully while ye are both here i added some talking points to the nova neutron cross project session since it was blank | |
| 16:40:47 | sean-k-mooney | https://etherpad.openstack.org/p/nova-ptg-stein line 147 | |
| 16:41:12 | sean-k-mooney | cross cell migration should proably be there | |
| 16:41:39 | mriedem | cross-cell migratoin is in the cells section | |
| 16:41:43 | mriedem | but sure | |
| 16:42:10 | melwitt | cross-cell migration will apply to the cells section, the cinder section, and the neutron section, I think | |
| 16:42:28 | mlavalle | yesterday I asked rubasov, | |
| 16:42:52 | sean-k-mooney | mlavalle: so just so we can confim does neutron allow neutron networks to span neutron availablitiy zones | |
| 16:42:56 | mlavalle | who asked gibi, whether we needed to discuss bandwidth based scheduling, and the answer was no | |
| 16:43:33 | mlavalle | sean-k-mooney: I think it does but i'll confirm | |
| 16:44:17 | jaypipes | mriedem: hmm, I've gone through all patches to the nova source tree in the rocky branch in the last three months and don't see anything at all that hits the code paths involved in setting allocation ratios... I'm a little stumped, to tell the truth. | |
| 16:44:29 | stephenfin | jaypipes: Are you planning to work on that "move CPU tracking to placement" spec this cycle? | |
| 16:44:46 | jaypipes | mriedem: unless this is a super latent but is just recently rearing its head... perhaps.. | |
| 16:45:08 | sean-k-mooney | mlavalle: i geuss if it does not and it causes port binding to fail when then that will be enough for nova to know not to schduler to that node | |
| 16:45:08 | jaypipes | stephenfin: yeah, I guess I have to. I'd RATHER shove hot pokers in my eyeballs, though. | |
| 16:45:38 | mlavalle | sean-k-mooney: yes, that's whaat I would say | |
| 16:48:10 | mlavalle | sean-k-mooney: I left a comment in the etherpad, L166 regarding whther we need to discuss bandwidth based scheduling | |
| 16:49:58 | sean-k-mooney | mlavalle: cool well it was more of a what is the current state of this and should we be planning to schduler review time to get this finish in stein topic. | |
| 16:50:40 | mlavalle | sean-k-mooney: ping them tomorrow, they are closer to your tz | |
| 16:50:54 | mlavalle | now it is very late for them | |
| 16:51:04 | sean-k-mooney | mlavalle: sure will do | |
| 16:51:10 | mlavalle | and maybe it is getting late for you as well | |
| 16:52:16 | gibi | mlavalle, sean-k-mooney: I and rubasov can give a status of the bandwidth work on the PTG if needed | |
| 16:53:49 | mlavalle | gibi: thanks | |
| 17:02:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Resource provider - request group mapping in allocation candidate https://review.openstack.org/597601 | |
| 17:03:34 | gibi | mlavalle: ^^ this spec is only impacting placement (and or Nova) but connected to the bandwidth work. I think we will discuss it in the placement related sessions rather than in the nova-neutron cross session. | |
| 17:03:50 | gibi | mlavalle: but you might be interested still | |
| 17:04:38 | mlavalle | gibi: ack, thanks for the heads up | |
| 17:13:56 | sean-k-mooney | mlavalle: i tend to start late and work late. | |
| 17:14:21 | mriedem | i work hard and i play hard | |
| 17:14:24 | mriedem | mtreinish: | |
| 17:15:24 | sean-k-mooney | gibi: sure if you want to cover that in the placement sessions then that works too. just wanted to make sure it did not slip through the cracks | |
| 17:16:06 | gibi | sean-k-mooney: at the moment the resource mapping does not affect Neutron it either affect placement and nova or nova only. | |
| 17:16:47 | gibi | sean-k-mooney: neutron will get the nework device RP uuid from nova during the port binding anyhow | |
| 17:17:44 | openstackgerrit | Matt Riedemann proposed openstack/nova master: (Re)start caching scheduler after starting computes in tests https://review.openstack.org/597606 | |
| 17:18:04 | sean-k-mooney | gibi: previded we modify nova to pass them to you :) | |
| 17:18:48 | sean-k-mooney | gibi: looking at the spec this looks pretty familar to what we discussed back in dublin | |
| 17:19:30 | gibi | sean-k-mooney: code is up that does passes the RP from nova to neutron https://review.openstack.org/#/c/569459/26/nova/network/neutronv2/api.py@3129 | |
| 17:19:46 | gibi | sean-k-mooney: it only works for the simple cases | |
| 17:20:08 | gibi | sean-k-mooney: I can make it work for the general case but it won't scale | |
| 17:20:22 | gibi | sean-k-mooney: so I proposed the spec to do the mapping in placement | |
| 17:21:17 | gibi | sean-k-mooney: I have to leave for today I happy to continue the discussion tomorrow, or on the review, and eventually on the PTG | |