Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-29
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.
17:43:48 sean-k-mooney mriedem: you could see if a depends on would override it. e.g. make a noop patch to xenapi-os-testing then depend on it to force the unpatched version?
17:44:39 jaypipes sean-k-mooney: that would assume the xenserver CI is honouring depends-on, no?
17:45:04 sean-k-mooney true
17:45:17 mriedem i'm pretty sure they do,
17:45:25 mriedem i'll just revert that change and depends-on the nova logging patch
17:46:49 sean-k-mooney is https://bugs.launchpad.net/nova/+bug/1789654 only happenign with the xen driver by the way?
17:46:49 openstack Launchpad bug 1789654 in OpenStack Compute (nova) rocky "placement allocation_ratio initialized with 0.0" [High,Confirmed]
17:47:16 mriedem no,
17:47:23 mriedem zigo is hitting it on rocky with libvirt
17:48:51 melwitt mriedem: I'm unsure whether to +1 this rocky final releases patch given the regression you're investigating. I assume we are too late to fix it for GA, but not 100% sure https://review.openstack.org/597529
17:49:48 mriedem melwitt: i assume the GA ship has sailed
17:50:15 mriedem given we aren't hitting this in the 'normal' gate and we don't have root cause, i don't think we can hold anything up
17:51:18 melwitt ok. I wasn't clear whether the latest find in xenserver CI yielded a root cause or not. thanks
17:53:02 sean-k-mooney mriedem: strange just looking at my devstack install everything looks fine on libvirt.
17:53:36 sean-k-mooney mriedem: do you know how to reproduce or is that what your currently investiaging
17:53:58 mriedem ...
17:54:04 melwitt in the past, the 0.0 was supposed to be a signal for the scheduler to use different default values, which I always found confusing
17:54:06 mriedem what about "don't know root cause" is ....
17:54:23 mriedem yes it should read from hard-coded values in the compute node

Earlier   Later