| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 20:46:58 | mriedem | but, that's probably because we change that in the api | |
| 20:47:03 | mriedem | i bet the rebuild actually fails on the compute | |
| 20:47:06 | mriedem | because we can't detach the root disk | |
| 20:49:41 | mriedem | also, unrelated, i just updated an approved change and removed something in the commit message, and it re-applied the +W on the patch | |
| 20:49:46 | mriedem | which seems like odd new behavior | |
| 20:49:58 | mriedem | https://review.openstack.org/#/c/507816/5..6 | |
| 20:50:27 | sdague | if it's litterally exactly the same patch, I though all the votes come back | |
| 20:50:54 | sdague | https://review.openstack.org/#/c/507816/1..6 | |
| 20:51:01 | sdague | because you +W PS1 | |
| 20:51:15 | sdague | and 6 is the same as 1 bit for bit, the votes pop back | |
| 20:51:30 | melwitt | I had thought commit messages counted as part of the patch in the past | |
| 20:51:43 | sdague | message contents | |
| 20:51:47 | sdague | not metadata | |
| 20:52:06 | sdague | the commit message is also the same | |
| 20:52:47 | melwitt | mriedem changed the commit message in PS6 | |
| 20:53:03 | melwitt | oh, you're saying it's the same as PS1 | |
| 20:53:18 | melwitt | I see now | |
| 20:59:22 | openstackgerrit | Merged openstack/nova-specs master: Libvirt: Native LUKS decryption by QEMU https://review.openstack.org/490824 | |
| 20:59:27 | melwitt | I put up a spec for counting instances, CPU, RAM from placement https://review.openstack.org/#/c/509042 and it seems like we'd need a new query in placement to be able to figure out "instances" | |
| 20:59:38 | melwitt | unless I'm missing something | |
| 20:59:39 | mriedem | melwitt: we have the consumers table | |
| 20:59:43 | mriedem | s/table/api/ | |
| 20:59:58 | mriedem | although, that's going to contain migration records now too... | |
| 21:00:16 | melwitt | oh, I was wondering about that. it's not merged yet right? I didn't find anything in the code or the placement api-ref | |
| 21:00:37 | mriedem | consumers is in the api-ref for placement | |
| 21:00:56 | mriedem | oh nvm it's not | |
| 21:00:59 | mriedem | there must be a change up for that | |
| 21:01:04 | mriedem | avolkov probably knows | |
| 21:01:45 | dansmith | mriedem: and anything else that isn't an instance | |
| 21:01:48 | melwitt | I hadn't seen anything about consumers in https://github.com/openstack/nova/tree/master/nova/api/openstack/placement/handlers either | |
| 21:02:14 | dansmith | like, anything could claim some space on a cinder provider that isn't an instance | |
| 21:02:22 | exarr | Anyone able to offer a decent link to multi-regions for ocata? (Ubuntu) | |
| 21:02:32 | exarr | (as in to learn) | |
| 21:03:00 | melwitt | okay, that's what I was wondering, whether we could assume consumers are instances. so apparently not | |
| 21:03:04 | dansmith | nope | |
| 21:03:15 | dansmith | that's why they're called consumers and not instances :P | |
| 21:03:42 | melwitt | well, yeah. I thought someone had said we could derive it from allocations and I guess I didn't know how else other than consumers | |
| 21:04:05 | dansmith | well same deal, allocations could be for other things | |
| 21:04:07 | melwitt | instance mappings would work but they will also contain deleted instances | |
| 21:04:13 | dansmith | yeah | |
| 21:07:45 | melwitt | my initial thought was, put a deleted column on instance mapping. but that comes with the challenge of "if delete fails, don't set it." maybe if we hooked it up to instance.destroy() and set the flag from there it would work | |
| 21:17:46 | jaypipes | cfriesen: yeah, no way around that (supporting both for a release or two). | |
| 21:22:17 | efried | jaypipes Where do we stand on specs like https://review.openstack.org/#/c/485522/ which include a) enhancements to the existing PCI manager code; which also talk about b) new trait- or inventory-ish additions to the [pci]passthrough_whitelist in same ? | |
| 21:23:41 | efried | jaypipes There's a kind of push for (a) to do stuff we want sooner than it would be possible under NRP/GDM. And (b) is compounding a problem we're explicitly getting rid of... but getting rid of *later*; i.e. it'll all go away at once, so does it matter that we add to it now? | |
| 21:23:59 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add ScaleIO ephemeral storage backend https://review.openstack.org/495922 | |
| 21:28:46 | cfriesen | jaypipes: pretty much what I figured. I'll try and respin along the lines of your suggestion. Also, could you take a look at https://review.openstack.org/#/c/339715/ ? | |
| 21:29:10 | dansmith | melwitt: deletes are finished on compute nodes, which can't access that bit | |
| 21:29:32 | dansmith | melwitt: and we also said we weren't going to do soft deleted stuff in the api db, because it will only get _more_ out of sync than it does today | |
| 21:30:24 | melwitt | dansmith: if it's in Instance.destroy wouldn't that happen in conductor? or you're saying cell conductor not supposed to access API DB | |
| 21:31:23 | dansmith | melwitt: cell conductor can't talk to the api db right | |
| 21:31:30 | melwitt | yeah, just brainstorming. AFAIK there's no way to determine instances from placement. I guess could count allocations of "CPU" or something like that? | |
| 21:31:46 | dansmith | except if something outside of nova has allocations for your tenant, | |
| 21:31:51 | dansmith | like bifrost or mogan :) | |
| 21:32:30 | melwitt | would they not use a different resource class than our canned ones? | |
| 21:32:39 | dansmith | it's not NOVA_CPU, it's CPU | |
| 21:32:52 | dansmith | and MEMORY_MB and DISK_GB | |
| 21:33:07 | dansmith | (actually VCPUS, but you get the idea) | |
| 21:33:29 | openstackgerrit | Merged openstack/nova-specs master: Add a spec for minimal cache headers in placement https://review.openstack.org/496853 | |
| 21:34:25 | melwitt | so we should abandon the idea of trying to count resources in placement? if something outside nova can consume CPU and RAM, then we wouldn't want to compare those against nova quota | |
| 21:34:38 | dansmith | I guess that's a good point | |
| 21:35:31 | dansmith | at ptg we were talking about using placement to make sure that nova and straight ironic uses don't step on each other's compute nodes | |
| 21:36:03 | dansmith | and this'd be a similar thing if mogan or zun or something like that was in the picture | |
| 21:36:07 | mriedem | dansmith: another fun paging spec https://review.openstack.org/#/c/506030/3 | |
| 21:36:28 | dansmith | we could just say that you have to have different tenants, but that's not always going to work and counting usage by other services as quota in nova is just not right at all | |
| 21:36:46 | melwitt | yeah | |
| 21:36:57 | openstackgerrit | Merged openstack/nova-specs master: Add ScaleIO ephemeral storage backend https://review.openstack.org/495922 | |
| 21:37:18 | dansmith | mriedem: ah yeah that one has to legit be cells aware | |
| 21:40:09 | mriedem | so begins my great recheckaning | |
| 21:41:16 | dansmith | mriedem: so do I just get all future pagination specs to review? | |
| 21:41:18 | dansmith | I'm so thrilled. | |
| 21:41:40 | mriedem | dansmith: you are mr multi-cells | |
| 21:41:41 | mriedem | so yes | |
| 21:41:58 | mriedem | to be fair, these were all approved back in newton apparently, but never merged | |
| 21:42:12 | mriedem | oh yeah, on that migrations paging one, | |
| 21:42:17 | mriedem | i noted that the marker they propose won't work | |
| 21:42:25 | dansmith | yep | |
| 21:45:14 | melwitt | I know, we could have consumer classes in a class column! "nova_instance" | |
| 21:45:31 | mriedem | consumer_type=instance | |
| 21:45:32 | mriedem | :) | |
| 21:45:38 | mriedem | it would be like osc | |
| 21:45:41 | dansmith | so, I thought at one point about having each instance consume one instance type | |
| 21:45:50 | dansmith | it's breaking the model though | |
| 21:46:03 | dansmith | what we need, IMHO, is the thing I suggested back in bristol when we were talking about this, | |
| 21:46:16 | dansmith | which is a service type on a consume (and maybe resource provider too), | |
| 21:46:29 | dansmith | so we know "this consumer is an instance" and "this provider is a compute node" | |
| 21:46:34 | dansmith | but jaypipes shot me down | |
| 21:46:59 | melwitt | yeah, on the surface I think it makes sense to be able to have some more info about consumers | |
| 21:48:00 | dansmith | IMHO, doing quotas in placement isn't critical and probably not worth that much trouble, at least at the moment | |
| 21:48:35 | dansmith | if people actually start deploying multiple cells and hit dead cells and perf issues, then we might do this to fix that, or we might have to do something totally differently | |
| 21:48:42 | dansmith | depending on what that data tells us | |
| 21:48:51 | melwitt | yeah, I didn't expect it to be this complex when I proposed it, so I'm cool with punting it for later | |
| 21:49:55 | dansmith | yeah, I should have thought of the other-things-consume-stuff thing earlier | |
| 21:49:57 | dansmith | so blame me | |
| 21:50:50 | melwitt | heh | |
| 21:59:21 | jaypipes | efried: I believe I already commented on that particular spec? | |
| 21:59:43 | jaypipes | dansmith: actually it's VCPU, not VCPUS :) | |
| 22:00:38 | dansmith | jaypipes: yeah yeah | |
| 22:01:02 | jaypipes | dansmith: I originally had the can_host attribute of the resource_providers table but edleafe shot me down and said we could just use a trait to indicate a sharing provider. | |
| 22:01:16 | jaypipes | edleafe is now under the bus that jaypipes was under. | |
| 22:01:26 | dansmith | jaypipes: yeah can_host was wrong | |