| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 20:31:13 | sdague | we store keypair name | |
| 20:31:13 | dansmith | maybe this was broken before and now isn't | |
| 20:31:18 | dansmith | sdague: no we store the whole thing | |
| 20:31:20 | mriedem | we store the whole gd thing | |
| 20:31:25 | sdague | oh | |
| 20:31:25 | dansmith | sdague: keypairs live in the api db and compute can't get them | |
| 20:31:35 | mriedem | https://github.com/openstack/nova/blob/cfff910b0d1a0d9f24b6c1596ceef8dd6b8b3ac6/nova/api/metadata/base.py#L355 | |
| 20:31:46 | sdague | ok, so yeh, maybe cells v2 did move this around and fix a thing | |
| 20:32:24 | dansmith | um, ya'll'er welcome? | |
| 20:32:52 | sdague | dansmith: so, the use case that people seem to want is because keeping IP and device model (mac address) is useful to folks | |
| 20:33:13 | dansmith | but changing ownership via key, yeah | |
| 20:33:14 | mriedem | you also keep your volumes attached | |
| 20:33:23 | sdague | mriedem: right | |
| 20:33:29 | dansmith | I get why people want that | |
| 20:33:38 | dansmith | I wish they didn't want it, but.. | |
| 20:34:01 | sdague | I'd still like a more detailed set of use cases in the spec. | |
| 20:36:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: add note about rebuild not replacing volume-backed root disk https://review.openstack.org/509282 | |
| 20:37:17 | mriedem | ^ is my answer to the buttload of duplicate bugs | |
| 20:43:50 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient stable/newton: Fix aggregate_update name and availability_zone clash https://review.openstack.org/507816 | |
| 20:44:19 | sdague | mriedem: so rebuild on bfv is just a reboot? | |
| 20:44:28 | sdague | it might be better to actually make that a 400 | |
| 20:44:46 | sdague | because it's not actually doing what the user expects | |
| 20:45:02 | dansmith | sdague: but evacuate (rebuild) on BFV is hiiiiiiighly utilized | |
| 20:45:10 | dansmith | which is a little different, granted, but.. | |
| 20:45:17 | mriedem | can't specify a new image on evacuate | |
| 20:45:19 | dansmith | rebuild on bfv with a key becomes more useful | |
| 20:45:24 | dansmith | right I know | |
| 20:45:25 | mriedem | the issue here is you specify a different image on rebuild | |
| 20:45:29 | sdague | right | |
| 20:45:31 | cfriesen | sdague: you can specify a different personality on rebuild | |
| 20:45:32 | dansmith | ah, if you specify an image sure | |
| 20:45:57 | mriedem | i really need to just get a devstack setup and play with some of this a bit, because a lot of the bug reports are really old and confusing, and mixing issues | |
| 20:46:04 | sdague | mriedem: yeh | |
| 20:46:19 | sdague | I was thinking about doing that tomorrow morning | |
| 20:46:24 | mriedem | the linked bug in there shows a recreate where the rebuild doesn't fail but doesn't change the root disk either | |
| 20:46:26 | sdague | and just mapping out the space a bit | |
| 20:46:39 | mriedem | it does change the instance image ref | |
| 20:46:57 | cfriesen | mriedem: I think we hit that one....was sort of confusing due to the mismatch | |
| 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 | |