Earlier  
Posted Nick Remark
#openstack-nova - 2019-08-07
14:40:07 sean-k-mooney dansmith: we decided to allow operators to specify resouce request in the flavor extra specs
14:40:16 sean-k-mooney that is the sole legacy use of this
14:40:28 dansmith sean-k-mooney: I'm not sure what you mean
14:40:38 dansmith resource requests take precedence over the base flavor values
14:40:40 dansmith that's new behavior
14:40:45 dansmith and critical for things like ironic
14:40:55 sean-k-mooney dansmith: no its not
14:41:05 mriedem yes...it is
14:41:08 dansmith where we "display" a value to the user via the flavor, but ask for something different from placement based on the overrides
14:41:10 mriedem as of pike
14:41:13 sean-k-mooney resouce request have always had precedece over the flavor value
14:41:15 dansmith sean-k-mooney: not what?
14:41:33 mriedem sean-k-mooney: you just said the same thing as dan
14:41:33 stephenfin there's a lot of drivers using the flavor.vcpus field
14:41:36 dansmith sean-k-mooney: right, which is the new behavior
14:42:11 sean-k-mooney dansmith: i was saying its not new it has been that way since we added resouces: in the flavor extra spec
14:42:27 mriedem anything new in nova in <3 years is "new"
14:42:35 mriedem :)
14:42:39 sean-k-mooney hehe :)
14:42:40 dansmith and new since the introduction of that thing
14:42:50 stephenfin including the libvirt driver
14:42:51 mriedem stephenfin: yes, and it's going to be a big problem for that pcpu stuff
14:43:08 stephenfin I mean, couldn't you request 'resources:VCPU=1' and 'flavor.vcpus=1000' ?
14:43:10 sean-k-mooney mriedem: not really
14:43:19 sean-k-mooney unless you ask for less
14:43:21 stephenfin and placement would be screwwwwed
14:43:36 mriedem you could add a property to the Flavor object that proxies the extra spec override when getting Flavor.vcpus
14:43:43 sean-k-mooney stephenfin: we allow it but i agree its not ideal
14:43:46 stephenfin especially if placement is thing that enforces proxies now
14:44:33 sean-k-mooney one of the origial usecase was to allow yo to do flavor.vcpu=4 resouce:vcpu=0 for ironic but we ended up going a different route
14:44:59 stephenfin sean-k-mooney: It feels slightly DDoS'y, at least if placement does quotas. I guess the thing that would prevent that is that flavor creation is admin-only but still
14:45:47 sean-k-mooney e.g. so we could discribe the resouce an ironic flavor would have and then set the value to 0 and use the custome_resouce_class=1 internally
14:46:17 efried # If any of the three standard resources above was explicitly given in
14:46:17 efried # the extra_specs - in any group - we need to replace it, or delete it
14:46:17 efried # if it was given as zero.
14:46:20 dansmith sean-k-mooney: what "different route" did we go?
14:46:23 mriedem stephenfin: read this for context https://docs.openstack.org/ironic/stein/install/configure-nova-flavors.html
14:46:31 efried regardless of the reason, we definitely coded it so that extra specs would override base amounts.
14:46:52 sean-k-mooney dansmith: we went with setting the flavor vlaues to 0 and just useing the custom resouce class
14:46:58 dansmith sean-k-mooney: no we didn't
14:47:07 dansmith sean-k-mooney: see that doc mriedem just posted
14:47:19 mriedem i think sean-k-mooney means the flavor values via the extra spec,
14:47:25 mriedem not the actual top-level flavor properties
14:47:30 dansmith I don't think he does :)
14:47:39 stephenfin sean-k-mooney: We don't touch the flavor properties. We just ignore them
14:47:45 dansmith because he described what we *are* doing as the original plan that we abandoned
14:47:55 mriedem i'm not sure you can even create a flavor with 0 vcpus or ram
14:48:25 mriedem https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/flavor_manage.py#L33
14:48:27 sean-k-mooney no https://docs.openstack.org/ironic/stein/install/configure-nova-flavors.html is exactly the use case i though this was for but i though we ended up not doing it
14:48:44 sean-k-mooney ok good to know that actully was done
14:48:52 mriedem stephenfin: you didn't realize this 6 months ago?
14:48:53 efried What we need is to start over with a flavorsv2
14:49:09 efried How long could it possibly take to deprecate and remove cellsv1, I mean flavorsv1?
14:49:26 dansmith efried: not helping
14:49:38 stephenfin mriedem: I knew it was bad but not this bad /o\ I'd estimate a solid 80% of the code I've written has been tech debt-related
14:50:06 mriedem the base flavor values for vcpu/ram/disk are *everywhere* and in *everything* in nova, as far as resource accounting is concerned
14:50:12 mriedem so changing the meaning of one of those has huge implications
14:50:20 dansmith yup
14:50:23 sean-k-mooney ya
14:50:23 mriedem the only one that was ever sort of special was disk for bfv
14:50:29 mriedem which dansmith finally fixed in i think rocky
14:51:02 mriedem by fixed i mean don't claim disk usage if you're bfv
14:51:14 mriedem and don't report to the hypervisors API that we're consuming disk for a bfv instance
14:51:14 mriedem ec
14:51:16 mriedem *etc
14:51:41 sean-k-mooney i personally am not sure why we still allow bfv with root_gb !=0 i get the upgrade impact of that but it would be nice to fully lock that down
14:52:04 sean-k-mooney but that is a differnet hill to die on
14:52:32 sean-k-mooney anyway for the vcpu stuff we never generate xml from the resouce:* values
14:52:32 cdent so many hills. so many deaths.
14:52:44 sean-k-mooney we only use thos for placmenet
14:53:01 mriedem unless i'm mistaken,
14:53:08 mriedem until this pcpu hullabaloo,
14:53:18 mriedem the only time you'd ever override vcpu/ram/disk with extra specs is for ironic flavors
14:53:26 mriedem for which the driver doesn't look at those anymore anyway
14:53:42 sean-k-mooney no wiht the pcpu stuff we still dont plan to generate the xml form resouce: we plan to use the extra_specs
14:53:57 mriedem resource: *is* extra specs
14:54:09 stephenfin Yeah, my life has been made significantly harder by having to care about 'resources:VCPU' and 'resources:PCPU'
14:54:09 sean-k-mooney but yes i think you are right the only time you would override them is ironic
14:54:49 stephenfin I'm seriously considering a big "this isn't doing anything unless you're ironic" warning and moving on
14:54:51 stephenfin efried: ^
14:54:54 mriedem https://review.opendev.org/#/c/637217/
14:55:05 stephenfin There's edge case after edge case
14:55:13 sean-k-mooney mriedem: it is but i mean we have hw:cpu_policy to determin if we translate flavor.vcpu to resouce:vcpu or resouces:pcpu
14:55:26 sean-k-mooney stephenfin: the proably is how do you know its an ironic flavor
14:55:38 mriedem sean-k-mooney: if you're talking about things in the plan in the spec, i haven't read it so don't know
14:56:09 efried stephenfin: what specifically? resources:VCPU/PCPU in extra specs?
14:56:17 sean-k-mooney mriedem: we knew trying to supprot resouces: for influncing the xml generation and assignment woudl be a paid soe we are not supporting it
14:56:18 stephenfin mriedem: tl;dr: if you specify 'hw:cpu_policy=dedicated', you now get 'PCPU' inventory, but we need to care about 'resources:PCPU' in addition
14:56:28 stephenfin efried: yup
14:56:29 sean-k-mooney *pain
14:57:14 sean-k-mooney efried: i would expand it to all resocues generated form flavor.* but the problem is we have no way to know if its an ironic flavor or not
14:57:17 mriedem umm, couldn't you just bork if you have hw:cpu_policy=dedicated and resources:VCPU?
14:57:18 sean-k-mooney so we cant
14:57:51 sean-k-mooney we would still request resocue:PCU=flavor.vcpus in addtion to resources:VCPU
14:57:54 mriedem technically any ironic flavor is hw:cpu_policy=dedicated by default yeah?
14:58:13 stephenfin mriedem: Yup, and that's what I'm doing (ditto for explicit PCPU too). The top issue is flavor.vcpus != resources:PCPU
14:58:15 mriedem i mean you do'nt specify that, it's just implied b/c it's baremetal
14:58:37 sean-k-mooney stephenfin: there is one case where its not equal by design
14:58:38 mriedem you know, mogan wouldn't have this problem....
14:58:56 sean-k-mooney which hw:emulator_threads_policy=isolate

Earlier   Later