| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-29 | |||
| 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 | |
| 17:21:18 | sean-k-mooney | gibi: oh cool i had not seen that series. i will have to pull it down and try it out | |
| 17:21:53 | sean-k-mooney | gibi: no worries have a good evening | |
| 17:21:59 | gibi | sean-k-mooney: same to you | |
| 17:24:44 | mriedem | so my debug logging patch didn't fail xenserver ci since they hard-coded the allocation ratios in nova.conf http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/53/597553/1/check/dsvm-tempest-neutron-network/971ea88/logs/etc/nova/nova.conf.txt.gz | |
| 17:24:52 | mriedem | i need to find their repo to revert that change | |
| 17:26:00 | jaypipes | mriedem: my bad, sorry. | |
| 17:26:27 | mriedem | help me find the repo | |
| 17:26:55 | sean-k-mooney | mriedem: could you just hard code the nova.conf passing code to return none | |
| 17:27:09 | sean-k-mooney | mriedem: or whatever it returns when its not set | |
| 17:29:52 | sean-k-mooney | mriedem: they are hard coding it in the local.conf http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/53/597553/1/check/dsvm-tempest-neutron-network/971ea88/logs/local.conf.txt.gz | |
| 17:30:18 | mriedem | i didn't think git://git.openstack.org/openstack/os-xenapi was it | |
| 17:30:32 | mriedem | yeah it's not | |
| 17:32:07 | cdent | mriedem: did you say that zigo's thing was changed to depends-on your debuggery? | |
| 17:32:16 | mriedem | yeah but i'm not sure it would help | |
| 17:32:22 | dansmith | mriedem: yeah that's the pack of xenapi plugins I think | |
| 17:33:02 | mriedem | https://review.openstack.org/#/c/597175/ but that doesn't actually get the nova change into the nova package | |
| 17:34:33 | mriedem | sean-k-mooney: oh you meant the allocation ratios - yes i knew that | |
| 17:34:40 | mriedem | and yeah i might have to hack the nova code to ignore the config | |
| 17:34:44 | mriedem | but first lunch | |
| 17:35:53 | sean-k-mooney | mriedem: yes i ment hack the nova code to ignore the configs so that you can work around there hack to hard code them :) | |
| 17:36:48 | jaypipes | mriedem: https://review.openstack.org/#/c/597428/ | |
| 17:38:39 | sean-k-mooney | jaypipes: oh you found it. am i the only on that is bothered by the fact the repo is xenapi-os-testing when the other one is os-xenapi | |
| 17:39:33 | sean-k-mooney | jaypipes: that change is not merged however which implies the ci is not running off of master of that repo? | |
| 17:42:46 | mriedem | they might be patching that into all CI runs | |
| 17:43:44 | jaypipes | what mriedem said. | |