Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-23
18:39:21 melwitt oh wait
18:39:30 melwitt mriedem: user error, my bad
18:40:30 edleafe cdent: ^^ Got all the tests passing locally \o/
18:40:43 edleafe doh! fat fingers ^^
18:41:14 melwitt I want to create an e-r query and I'm rusty
18:41:29 mriedem well, there are specs to be reviewed if you wanted to do that instead :)
18:41:43 melwitt I'm doing that too
18:42:25 melwitt I thought this would be quicker than it's being
18:49:17 melwitt bah, there's already a query for this. just e-r hasn't posted anything on it
18:51:18 mriedem jroll: you might want to take a gander at this ironic volume-backed resize/cold migrate spec https://review.openstack.org/#/c/449155/
18:51:25 mriedem i haven't been through it in quite awhile
18:51:37 mriedem but i'm also not very ironically inclined
18:52:30 mriedem seems that tuba guy would also care about this
18:53:24 pvc so sad
18:53:24 pvc sean-k-mooney suddenly root@test-vgpu:/home/ubuntu# nvidia-smi No devices were found
19:01:01 cfriesen since it's spec review day, I'd appreciate some eyes on https://review.openstack.org/#/c/571111/
19:01:14 cfriesen (the emulated TPM spec)
19:02:32 pvc nervermind me
19:04:03 cfriesen I think the open questions are whether we want to support CRB at this point (and if so how to ask for it), and whether we need to explicitly call out what happens for non-x86 architectures or leave that for the implementation.
19:58:00 mriedem jaypipes: are there any plans for this? https://review.openstack.org/#/c/529135/
20:02:47 sean-k-mooney mriedem: by the way sorry to be so negitive on https://review.openstack.org/#/c/612500 i understand why huawei and zte wants this but i really dont think its a viable option
20:03:17 cdent any particularly exciting specs to look at?
20:04:23 sean-k-mooney i dont know is https://review.openstack.org/#/c/600016/ worth reading ?
20:05:26 cdent sean-k-mooney: jay likes it, eric's less sure. I think if I update it to include the use case that eric's describing, it's a useful feature, but not likely to happen in stein
20:05:29 jaypipes mriedem: that's another one I tired of fighting about.
20:05:35 artom Wouldn't that be more or a placement spec at this point?
20:06:17 jaypipes mriedem: would be nice to get a real solution for it. apparently Oath has a whole code series for that backported against Ocata that I am supposed to figure out what is wrong with. :(
20:06:41 sean-k-mooney cdent: i have not read it yet but my first reaction to "GET /resource_providers?having=VCPU" was thats not already a thing?
20:07:12 sean-k-mooney e.g. i just assumed there was an effiect way to say give me all there resouce provierd with X resouce class
20:07:14 cdent nope, you can't easily list _any_ resource provider that has a particular class of resource, as it will leave out providers that are full
20:07:54 sean-k-mooney ah so its the and are not full bit that is missing right
20:08:08 sean-k-mooney well and may or maynot be full
20:08:24 mriedem sean-k-mooney: it's not my spec
20:08:27 sean-k-mooney e.g. just list all the RPs that have X regarless of there fullness
20:08:45 cdent exactly
20:09:15 cdent artom: placement specs is not a thing yet
20:09:19 sean-k-mooney mriedem: ya i kindof assumed you jsut repoposed after the spec repo rebase
20:09:37 sean-k-mooney mriedem: but did you not say huawei wanted this back in dublin
20:09:48 mriedem huawei wants sriov bond yes
20:09:58 mriedem *huawei's customers want sriov bond
20:10:08 sean-k-mooney mriedem: ya thats want i ment rather then that spec specifcally
20:11:32 mriedem but i can't get the network product guys internally to clearly describe the requirements they have against nova
20:11:40 artom cdent, oh. Um, should it be, with the split and everything?
20:11:43 mriedem so i can't really compare what they want, or their proposed solutions, to the zte spec
20:12:20 mriedem except they all say "something has to do the bond within the guest" hand wave hand wave
20:12:33 sean-k-mooney mriedem: ya i know that feeling. the zte solution is very non cloudy
20:12:36 cdent artom: the idea is that it will likely happen once the split is deemed complete. We have a list of things to complete before we declare that
20:13:41 mriedem jaypipes: you need to get your build request user metadata scheduler filter thing done first
20:13:44 artom cdent, fair enough, thanks :) And reading the commit message, you just wanted to stash https://review.openstack.org/#/c/600016/ somewhere
20:13:44 sean-k-mooney mriedem: what is often missed is sure you can do the bond in the guest but unless you tell neutron about it so it can confiugre the top of rack switch you screwed if you want to use lacp
20:14:00 jaypipes mriedem: yep.
20:14:03 cdent artom: yup
20:14:19 jaypipes mriedem: right after I shoot myself in the head from looking at Chef recipe bullshit.
20:17:34 melwitt mriedem: just so I'm clear, does the initial allocation ratios spec cover the ability to set per aggregate allocation ratios? https://review.openstack.org/552105 I mean, I know it's not called out in the spec, but does the spec allow it to work as a side effect?
20:18:11 melwitt or is there more work or another spec we would need to restore per aggregate allocation ratio abilities?
20:19:38 sean-k-mooney melwitt: i think that would be a different spec. but if the desire for aggragate allocation ratios was just to be able to set it via an api then plament does that
20:20:43 melwitt yeah, that's what I mean, if it's already possible to set allocation ratio per aggregate in placement, then I guess after the spec I linked is implemented, users will have what they need to do it
20:21:56 sean-k-mooney melwitt: well no thats not possible but you can prgramtclly set an allocation via the api. you would have to loop over the RPs in the placement aggreate to set them via the placemetn api to get the same effect as nova old aggreate allocation ratios
20:22:15 mriedem melwitt: no
20:22:29 mriedem melwitt: you're looking for https://review.openstack.org/544683
20:22:32 mriedem which doesn't have an owner
20:22:38 mriedem and is contentious in implementation
20:22:45 melwitt urgh
20:23:07 sean-k-mooney cdent: misusing your spec to help with ^
20:23:42 sean-k-mooney any opion on /resource_providers?having=VCPU&member-of=Y
20:24:26 sean-k-mooney so that in osc-placement we could say somthing like " set allocation ration for all resocue class X in aggreate Y"
20:24:55 mriedem t aggregates, this would build on that for mirroring the allocation ratios as well if *_allocation_ratio was set on a compute host aggregate in nova.
20:24:55 mriedem melwitt: i think the summary on https://review.openstack.org/#/c/544683/ is that it's all possible outside of nova; adding it within nova was desirable as a proxy since we have a host aggregates API already with rbac, which placement didn't have until rocky. in dublin we said a simple meta CLI could be added to osc-placement to do this for people, but that didn't happen. but since we mirror the compute host aggregates to plac
20:27:03 melwitt ok, so that's what the "proxy" talk was about. so the proxy would still have to set a ratio per RP, there's no concept of an aggregate spanning ratio
20:27:06 sean-k-mooney mriedem: the meta cli being somting like "openstack placement allocation ratio set 1.0 --class VCPU --mem-of <my aggreate>"
20:27:38 mriedem melwitt: correct
20:27:53 mriedem resource provider aggregates in placement are just a group of linked providers, there is no metadata about the aggregate
20:27:53 openstackgerrit Merged openstack/nova-specs master: Add .idea folder to .gitignore https://review.openstack.org/581611
20:28:36 mriedem so the upside to nova doing the proxy is you get back to what we had before we broke this, and you only have to set aggregate allocation ratios in one place, rather than both nova and placement separately.
20:28:37 melwitt hm. trying to think how the old filters worked, how did operators express the per aggregate ratio /me looks for it
20:28:42 mriedem the downside is it's more proxy stuff in the comptue API
20:28:54 mriedem they do it with metadata on the host aggregate
20:29:12 melwitt ok, I understand now
20:29:17 mriedem https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateramfilter
20:29:51 mriedem "If the host is in more than one aggregate and thus more than one value is found, the minimum value will be used."
20:29:56 mriedem i don't know if jay's spec deals with that
20:32:11 melwitt thinking...
20:32:46 melwitt if you're only interested in per aggregate ratios, then you'd only need to set them in placement and not nova, I think
20:33:30 melwitt so maybe the scenario of "set them in both nova and placement separately" would be a rare one
20:34:12 jaypipes melwitt: as long as nova doesn't overwrite them over and over again..
20:34:35 melwitt you're either going to be setting them in nova, or in placement, depending on whether you want to do it per compute (or via conf) or per aggregate (or via API)
20:34:38 mriedem right, so if you manage this via the api you don't set the config overrides (iweb case)
20:34:44 mriedem if you're cern, you only use config and not the api
20:34:48 mriedem but we don't support both
20:34:52 mriedem if set, config takes precedence
20:34:57 melwitt right. and if you're oath, you'd use only the api and not the conf
20:35:06 jaypipes mriedem, melwitt: my light at the end of this tunnel is that jules is making kielbasa and cabbage for dinner, which is one of my favorites. yum.
20:35:17 mriedem i can smell your house from here
20:35:29 jaypipes mriedem: you'll be able to smell it in the morning too.
20:35:29 melwitt ok, I see. based on this, I think maybe we shouldn't try to proxy. it doesn't seem like it would buy much even for users
20:35:34 mriedem hi-o
20:35:37 jaypipes lol
20:35:54 mriedem melwitt: well you probably want to run that by mgagne
20:36:06 melwitt and penick
20:36:43 melwitt yeah, I'm just speculating here. will definitely want to talk to them and see if they would be ok with a placement CLI that can fan out to aggregate RPs

Earlier   Later