| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 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 | nicolasbock | The usage should be updated automatically? | |
| 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: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 | |
| 21:31:34 | mriedem | after picking a host, need to update the instance mapping with the cell of the selectd host | |
| 21:31:44 | mriedem | else you are rescheduling https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L738 | |
| 21:32:04 | melwitt | I see that, but we need to update instance mapping for cells v1? | |
| 21:32:32 | mriedem | what we need to do is delete cells v1 | |
| 21:32:38 | melwitt | yes we do | |
| 21:33:01 | mriedem | for cells v1 i assume the instance mapping is updated for the same reason as v2 - to know where to pull the instance information on a GET | |
| 21:33:17 | mriedem | because if it's not in the mapping, we'd pull from the top level API DB i geuss which has the synced info | |
| 21:33:23 | melwitt | yeah, because code path is the same? yeah, guh | |
| 21:33:42 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2449 | |
| 21:33:49 | mriedem | we don't look at the mapping in that case | |
| 21:34:02 | mriedem | so idk | |
| 21:34:05 | melwitt | ok. just going through this realizing I'm not going to have a "populate instance mapping user_id" opportunity during a reschedule, at least not from any already existing instance mapping update | |
| 21:34:08 | mriedem | maybe it's for the v1 -> v2 transition | |
| 21:34:33 | mriedem | why would you need to update the user_id during a reschedule? | |
| 21:34:35 | melwitt | yeah, must be | |