| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 19:25:36 | mriedem | twizzlers really needs to rethink their packaging because the smashed together brick of licorice that you have to destroy the bag to get 1 rope from is frustrating | |
| 19:26:07 | jroll | you need fresher twizzlers yo | |
| 19:26:16 | mriedem | does not exist | |
| 19:26:53 | mriedem | and by destroying the bag, you guarantee staleness within 48 hours | |
| 19:27:20 | temka | Solution: eat the whole bag. | |
| 19:27:25 | mriedem | in progress | |
| 19:28:08 | dansmith | lol | |
| 19:39:05 | melwitt | lol, it's so timely that you said that. I got the SAME problem earlier this week | |
| 19:39:37 | melwitt | and their "resealable" bag design cannot be opened without destroying the bag | |
| 19:40:01 | sean-k-mooney | its a secret conspiacy to get you to get them allin in one go so you have to buy more | |
| 19:40:19 | melwitt | probably | |
| 19:40:56 | melwitt | I put the tattered bag and brick into a gallon size ziplock freezer bag. nailed it | |
| 19:50:41 | nicolasbock | Hi, I am trying to understand the concept of quotas and limits. I don't quite see how they differ. | |
| 19:56:20 | melwitt | nicolasbock: lots of people use the words interchangeably. but there is quota usage (amount of resources being used) and quota limits (configured limit for the amount of a resource) | |
| 19:56:43 | melwitt | when people say "quotas" they usually mean quota limits | |
| 19:57:18 | nicolasbock | Ah, what I was thinking of are `openstack quota list` and `openstack limits show` | |
| 19:58:04 | melwitt | ah, ok. 'openstack limits show' is probably for showing keystone unified limits (which we are not yet leveraging in nova) | |
| 19:58:11 | melwitt | let me double check | |
| 20:00:02 | nicolasbock | Ok | |
| 20:00:30 | nicolasbock | So historically, limits came first and is now being unified under Keystone? | |
| 20:00:33 | melwitt | looks like I'm wrong. I'm looking for what it's calling underneath | |
| 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 | |