| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-07 | |||
| 14:05:30 | sean-k-mooney | perhaps it could be broken out at somepoint and shared between kolla-ansible, tripleo and osa | |
| 14:05:41 | yonglihe | sean-k-mooney: i reply melwitt but not sure is that what he concern. but thanks your review. | |
| 14:20:26 | dansmith | sean-k-mooney: you did not just say "it synergies" ... | |
| 14:21:41 | sean-k-mooney | for once im using it an example of its usage in a non marketing bs context | |
| 14:22:32 | dansmith | heh | |
| 14:24:43 | sean-k-mooney | the config file per service per host design works realy well with the config override system kolla-ansible has. i think it was the config override desigin goals that acttuly motivated that approch initally so i guess its not suprising they work well together | |
| 14:36:01 | noonedeadpunk | And does that make sense to create nova-conductor.conf and place db credentials only there? | |
| 14:36:49 | dansmith | noonedeadpunk: devstack does a nova-cell1.conf for all the non-compute services that need to talk to the database, but yeah | |
| 14:37:17 | dansmith | nova.conf has everything, and is used by the control services, api, etc. nova-cell1 is no api, just cell db creds, and nova-compute.conf is the bare minimum for compute | |
| 14:37:27 | stephenfin | efried, gibi: What's the expected behavior here? http://paste.openstack.org/show/755623/ | |
| 14:37:43 | stephenfin | Maybe dansmith and sean-k-mooney too, idk ^ | |
| 14:37:51 | noonedeadpunk | dansmith: thanks | |
| 14:38:14 | sean-k-mooney | stephenfin: for legacy reasons that shoudl be 2 | |
| 14:38:27 | sean-k-mooney | e.g. we have alway allowed that | |
| 14:38:39 | sean-k-mooney | but i dont like that you can change it | |
| 14:39:01 | sean-k-mooney | if we block it it could break existing flavors | |
| 14:39:13 | sean-k-mooney | so there would be an upgrade impact | |
| 14:39:39 | dansmith | sean-k-mooney: why for legacy reasons? | |
| 14:39:41 | mriedem | technically devstack has several conf files for nova because of the superconductor mode | |
| 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 | stephenfin | there's a lot of drivers using the flavor.vcpus field | |
| 14:41:33 | mriedem | sean-k-mooney: you just said the same thing as dan | |
| 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 it was given as zero. | |
| 14:46:17 | efried | # the extra_specs - in any group - we need to replace it, or delete it | |
| 14:46:17 | efried | # If any of the three standard resources above was explicitly given in | |
| 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 | mriedem | the only one that was ever sort of special was disk for bfv | |
| 14:50:23 | sean-k-mooney | ya | |
| 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 | ec | |
| 14:51:14 | mriedem | and don't report to the hypervisors API that we're consuming disk for a bfv instance | |
| 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 | cdent | so many hills. so many deaths. | |
| 14:52:32 | sean-k-mooney | anyway for the vcpu stuff we never generate xml from the resouce:* values | |
| 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 | sean-k-mooney | but yes i think you are right the only time you would override them is ironic | |
| 14:54:09 | stephenfin | Yeah, my life has been made significantly harder by having to care about 'resources:VCPU' and 'resources:PCPU' | |
| 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/ | |