| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 20:00:40 | nicolasbock | Ok | |
| 20:01:59 | melwitt | limits show calls a compute api https://github.com/openstack/python-openstackclient/blob/4bde9af89251431791fc8d69fe09d5e17a8fba8f/openstackclient/common/limits.py#L90 | |
| 20:02:38 | fried_rice | dansmith: ack, looking. | |
| 20:03:06 | melwitt | nicolasbock: which is this one, which is the old school rate-limiting api https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/limits.py#L85 | |
| 20:03:38 | mriedem | dansmith: remind me, is a compute node for vcenter still 1:1 with the compute service host? or 1:M like ironic? | |
| 20:03:52 | mriedem | is the compute node the vcenter cluster, or is a compute node an esxi host in that cluster? | |
| 20:04:02 | melwitt | nicolasbock: hah, it's actually for both. nice https://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#limits-limits | |
| 20:04:15 | nicolasbock | Thanks melwitt | |
| 20:04:29 | melwitt | so that's showing quota limits and the old rate limit part is empty | |
| 20:04:47 | melwitt | now, what does 'openstack quota list' do | |
| 20:04:50 | dansmith | mriedem: yeah I think the compute node is a cluster, which is multiple machines | |
| 20:05:18 | mriedem | but all instances on the same compute service host point at the same compute node... | |
| 20:05:20 | dansmith | mriedem: so it looks 1:1 like libvirt, not 1:N like ironic, but the 1 is actually N | |
| 20:05:31 | mriedem | yeah ok | |
| 20:06:55 | melwitt | nicolasbock: ok, so that one does this https://developer.openstack.org/api-ref/compute/?expanded=show-a-quota-detail#show-a-quota | |
| 20:07:27 | melwitt | nicolasbock: two different APIs that do nearly the same thing. the 'openstack limits show' will show the quota limits and quota usage, the 'openstack quota list' will show the quota limits only | |
| 20:07:52 | nicolasbock | Ok | |
| 20:07:57 | nicolasbock | Thanks! | |
| 20:08:05 | melwitt | np | |
| 20:08:06 | nicolasbock | Now to the next question :) | |
| 20:08:22 | melwitt | uh oh | |
| 20:08:24 | nicolasbock | If I understand this correctly, then the usage is not updated by default | |
| 20:08:43 | nicolasbock | For Pike I found `max_age` in the `[Quota]` section | |
| 20:08:53 | nicolasbock | Which defaults to `0` | |
| 20:09:03 | melwitt | ok, that's for the old quota syncing mechanism | |
| 20:09:27 | nicolasbock | I also found https://github.com/openstack/nova/blob/c8926feb2675c754048f8c7398747e3c29bfadaf/releasenotes/notes/remove-quota-options-0e407c56ea993f5a.yaml | |
| 20:09:28 | melwitt | in pike, we changed the way we do quota usage and count resources directly instead of tracking them in a separate table | |
| 20:09:33 | nicolasbock | Which suggests that it's deprecated | |
| 20:09:58 | nicolasbock | Ok. Does that mean that I don't have to worry about this setting? | |
| 20:10:04 | melwitt | yes, the use of the separate table (which could get out-of-sync with actual resource consumption) and the syncing related options are deprecated and removed | |
| 20:10:04 | nicolasbock | The usage should be updated automatically? | |
| 20:10:14 | melwitt | right | |
| 20:10:40 | nicolasbock | Ok. Let me rephrase this to make sure I understand this correctly: | |
| 20:10:43 | melwitt | actual resource usage is counted per quota check since pike. going out-of-sync is no longer possible, so quota syncing is no longer possible | |
| 20:11:03 | nicolasbock | I should look only at `openstack limits show` | |
| 20:11:11 | nicolasbock | And it should show me the quota and the usage | |
| 20:11:25 | nicolasbock | And it's automatically kept up to date? | |
| 20:11:39 | nicolasbock | Does that summarize the situation somewhat accurately? | |
| 20:11:40 | melwitt | yes, anything the API is showing was accounted for when things were changed | |
| 20:12:08 | nicolasbock | Cool | |
| 20:12:10 | melwitt | you'll always see "reserved=0" because we no longer do the two-step reserve + commit quota dance | |
| 20:12:16 | nicolasbock | Wow, that's a lot easier than I thought :) | |
| 20:14:25 | melwitt | you can look at either 'openstack limits show' or 'openstack quota list'. limits show seems more useful since it shows the usage too | |
| 20:15:01 | melwitt | I notice that quota list has some limits that are not in limits show, but those are all deprecated by now I think | |
| 20:15:06 | nicolasbock | Yes, that's true | |
| 20:15:29 | nicolasbock | I find that listing a quota without also showing usage less helpful ;) | |
| 20:15:30 | melwitt | but they pull data in the same way, so they should match where they are the same | |
| 20:51:33 | fried_rice | mriedem: Flushing oldymoldys, are you happy with the reno verbiage etc. on https://review.openstack.org/#/c/564193/ at this point? | |
| 21:00:08 | mriedem | ech idk | |
| 21:00:15 | mriedem | they should also update the image properties docs https://docs.openstack.org/glance/latest/admin/useful-image-properties.html | |
| 21:00:21 | mriedem | but that's in glance so a follow up | |
| 21:00:28 | mriedem | i haven't looked at that change in forever though | |
| 21:01:05 | mriedem | if you're happy with it go ahead | |
| 21:01:24 | fried_rice | well, I was happy with it before you ripped into it. | |
| 21:01:33 | mriedem | you can be happy once again | |
| 21:01:38 | fried_rice | k | |
| 21:01:50 | mriedem | i'm currently very unhappy with most everything so don't hold for me | |
| 21:02:41 | fried_rice | done, I suppose anything egregious can be handled in a fup. | |
| 21:05:59 | mriedem | so on this same host resize bug, i started down the path of, from conductor, just trying to PUT allocations for the max of the old/new flavor to see if that can fit the host, | |
| 21:06:13 | mriedem | but then remembered, oh yeah the new flavor can have required/forbidden traits which could filter out the same host | |
| 21:06:24 | mriedem | f me right in the eye | |
| 21:06:32 | mriedem | leakypipes: ^ | |
| 21:07:46 | mriedem | i basically have to do a GET /a_c call from conductor and see if the same host provider is in the results | |
| 21:08:07 | mriedem | and then not swap allocations | |
| 21:08:33 | edleafe | mriedem: that sounds like the same problem Watcher had | |
| 21:08:50 | mriedem | the ol scheduler dry run | |
| 21:09:49 | fried_rice | mriedem: You can use ?in_tree with microversion 1.31 | |
| 21:10:18 | mriedem | that's not a thing in stein right | |
| 21:10:29 | fried_rice | Could be | |
| 21:10:44 | fried_rice | I mean, it's not merged yet, and we agreed not to use it from nova if it does merge. | |
| 21:11:12 | mriedem | this change isn't making stein anyway | |
| 21:11:14 | fried_rice | We could end up resizing to same-host-but-different-providers, couldn't we. | |
| 21:11:20 | mriedem | sure can | |
| 21:11:30 | mriedem | if there are nested providers in the new flavor then it's all f'ed either way | |
| 21:12:00 | fried_rice | I don't know about f'ed. Just have to be pretty careful about which ones we allow to move and which we don't. | |
| 21:12:19 | fried_rice | Like, I can see moving numa nodes, as long as all the affined resources move together. | |
| 21:12:31 | fried_rice | But I can't see moving FPGAs probably. | |
| 21:12:51 | fried_rice | for now I wouldn't remotely object to "fail if any nested/sharing in play". | |
| 21:12:53 | mriedem | i think i would put a big fat "don't go down this side path if you have complex allocations" condition | |
| 21:13:01 | fried_rice | yeah, that. | |
| 21:13:13 | fried_rice | bbiab | |
| 21:21:03 | mriedem | this would also bypass anything that has limits to claim in the resource tracker, like numa | |
| 21:21:11 | mriedem | so no numa, no complex allocations | |
| 21:27:15 | melwitt | hm, I wonder why we populate the instance mapping with a cell in build_instances when it is _not_ a reschedule. build_instances method + not a reschedule = cells v1, I thought. so why update instance mapping | |
| 21:28:02 | mriedem | we do'nt know the cell in that case until the scheduler tells us the host right? | |
| 21:28:05 | leakypipes | mriedem: don't forget ye old aggregate image properties filter too. :) | |
| 21:28:16 | mriedem | leakypipes: image doesn't change on resize | |
| 21:28:18 | mriedem | thank f | |
| 21:28:50 | leakypipes | ah, yes, was thinking rebuild/evac | |
| 21:29:03 | mriedem | image doesn't change on evac either | |
| 21:29:04 | mriedem | silly pants | |
| 21:29:28 | mriedem | we need a jump to conclusions mat for these operations | |
| 21:29:34 | mriedem | new host? yes/no/maybe | |
| 21:29:38 | mriedem | new flavor? yes/no/maybe | |
| 21:29:43 | mriedem | new image? yes/no/maybe | |
| 21:30:01 | mriedem | aneurysm? definitely. | |
| 21:30:31 | melwitt | there's a note in the code saying that if it's a reschedule, it's already been set to a cell on the first schedule attempt https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L717-L718 | |
| 21:30:57 | melwitt | so how can the first schedule attempt in a cells v2 env ever be calling build_instances (and not schedule_and_build_instances) | |
| 21:30:58 | mriedem | melwitt: right, so that if is False | |
| 21:31:26 | mriedem | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L721 is the first time through for cells v1 | |