| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-22 | |||
| 15:58:52 | mriedem | it might be in tempest...checking | |
| 15:59:06 | mriedem | oh nvm, we don't expose it today | |
| 15:59:08 | gmann | we only expose 'lock' as string in API response | |
| 15:59:09 | dansmith | it says admin or owner | |
| 15:59:12 | mriedem | right | |
| 15:59:16 | gmann | we do not expose 'locked_by' | |
| 15:59:22 | mriedem | tempest is the only thing that would have a response schema check | |
| 15:59:25 | dansmith | mriedem: right the thing she's adding says "admin or owner" | |
| 15:59:39 | mriedem | i know, but that's just the possible values in the db schema today | |
| 15:59:42 | dansmith | so I assumed that meant a schema enum | |
| 15:59:44 | mriedem | tempest could just allow 'string' | |
| 15:59:56 | mriedem | nova doesn't have any response schema | |
| 16:00:01 | dansmith | well let's be clear about it then because it looks like those are the only two values | |
| 16:00:05 | dansmith | I mean in the spec | |
| 16:00:06 | mriedem | sure | |
| 16:01:27 | mriedem | 11am and i forgot what i was actually going to try and get done today... | |
| 16:04:48 | mriedem | need a stable core to hit this https://review.openstack.org/#/c/633493/ | |
| 16:05:01 | mriedem | https://review.openstack.org/#/c/640116/ is also trivial on queens | |
| 16:05:05 | mriedem | for fast approval | |
| 16:05:23 | mriedem | and https://review.openstack.org/#/c/637391/ | |
| 16:05:38 | mriedem | once we get those we could probably release queens | |
| 16:07:48 | mriedem | thanks dansmith | |
| 16:08:39 | dansmith | uar | |
| 16:24:37 | mdbooth | https://bugs.launchpad.net/nova/+bug/1821373 | |
| 16:24:38 | openstack | Launchpad bug 1821373 in OpenStack Compute (nova) "Most instance actions can be called concurrently" [Undecided,New] | |
| 16:25:33 | melwitt | dansmith: want to hit these release bot changes? https://review.openstack.org/645461 and https://review.openstack.org/645463 | |
| 16:25:45 | sean-k-mooney | mdbooth: i assume you are going to remove the logic that shortcircuts if the value is set the same value and have it hit the db | |
| 16:26:14 | mdbooth | sean-k-mooney: Probably, but I'll have to meditate carefully on the safety of whatever. | |
| 16:26:29 | mdbooth | sean-k-mooney: And right now I'm a bit hungry and a bit checked out for the weekend :) | |
| 16:26:59 | sean-k-mooney | mdbooth: fixing db curuptions is definetly not a firday evning activity | |
| 16:27:11 | mdbooth | Don't try to fix db races on an empty stomach :) | |
| 16:27:47 | dansmith | melwitt: I think you're safe to fast-approve things like that :) | |
| 16:27:57 | melwitt | can't be too careful | |
| 16:28:30 | melwitt | (joke) | |
| 16:31:06 | dansmith | mdbooth: hmm, check_instance_state has a task state to try to prevent some of what you describe, not sure why that's not being used (although it won't close it entirely) | |
| 16:31:59 | dansmith | but I agree, I think either doing a dedicated task_state check in the db if we're going to punt due to no-updates will retain as much of the optimization as possible and close that window | |
| 16:32:13 | dansmith | letting it all go through even if no updates is an option, but it's heavy | |
| 16:32:21 | dansmith | (i.e. what we were doing before) | |
| 16:40:43 | mdbooth | dansmith: Yeah. I started thinking about whether we can safely bypass the trip to the db, but that's not a Friday afternoon thought-train. | |
| 16:41:13 | dansmith | I don't think we can entirely based on your reasoning, but we can make it efficient | |
| 16:41:22 | dansmith | but yes, a tuesday conversation | |
| 16:44:03 | dansmith | fried_rolls: are you not approving this because of your comment or for sequencing reasons? https://review.openstack.org/#/c/644625/5 | |
| 16:44:20 | dansmith | fried_rolls: if the former, I'll just add it to unblock progress, but it seems entirely duplicative to me | |
| 16:52:16 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 17:26:43 | gibi | mriedem_afk: could you hit the bandwidth spec update when you are back https://review.openstack.org/#/c/644810/ ? | |
| 17:33:22 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec https://review.openstack.org/645814 | |
| 17:34:44 | gmann | dansmith: mriedem_afk i think we should expose project_id in locked_by field which can be easily fetched for 'owner' case (based on DB enum value and context) but not sure how to fetch the admin project-id when server is locked by admin and GET by owner | |
| 17:35:01 | gmann | we need to change the locked_by DB from enum to UUID ? | |
| 17:35:01 | dansmith | gmann: yeah that's the obviously difficult one | |
| 17:35:46 | gmann | should we change DB schema also in this spec so that we always store project-id in locked_by while lock API | |
| 17:35:48 | dansmith | we could just start throwing a locked_by_uuid in sysmeta too, and maybe just add "id" to the enum, | |
| 17:36:07 | mnaser | kashyap: regarding your arm change to support 'virt' machine type, does that ship in as specific release of qemu? | |
| 17:36:08 | dansmith | but since it's an enum in the schema, it's not easy to just convert it to a freeform string | |
| 17:36:12 | elbragstad | mriedem_afk just catching up | |
| 17:36:22 | kashyap | mnaser: Hi | |
| 17:36:26 | mnaser | under centos 7 with qemu-kvm, i can't find a 'virt' machine type (this is the rhel shipped one) | |
| 17:36:37 | gmann | dansmith: ok. | |
| 17:36:41 | kashyap | mnaser: Which change do you refer to? | |
| 17:36:51 | mnaser | kashyap: https://github.com/openstack/nova/commit/e155baefb0bbaa0aa78e54fe9e0f10c12336c01a | |
| 17:37:06 | kashyap | (/me is dazed due to death-by-meetings; and is almost ready to check out) | |
| 17:37:08 | elbragstad | migrating from enum in the schema is pretty disruptive, isn't it? | |
| 17:37:19 | dansmith | elbragstad: yes | |
| 17:37:28 | mnaser | i'm assuming this controls the resulting `-M` parameter in the qemu-kvm command which is the machine type | |
| 17:37:39 | elbragstad | we hit that with something in keystone's database once, it was a total pain | |
| 17:37:40 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 17:37:52 | kashyap | mnaser: Top off my head, I need to check which version introduced the 'virt' board for ARM/AArch64 | |
| 17:37:52 | mnaser | to which I don't see the `virt` option available under centos 7.6 right now | |
| 17:38:09 | kashyap | mnaser: Are you checking with the right QEMU binary? | |
| 17:38:27 | mnaser | okay, i was curious at seeing how `virt` works for x86 machines too but just noticed it's missing. | |
| 17:38:33 | mnaser | kashyap: on a centos 7 machine => /usr/libexec/qemu-kvm -M help | |
| 17:38:48 | mnaser | gets me this: http://paste.openstack.org/show/748268/ | |
| 17:38:53 | kashyap | mnaser: That is referring to x86. | |
| 17:39:10 | mnaser | kashyap: let me check an arm box quickly | |
| 17:39:14 | kashyap | mnaser: You need to pull in the AArch64 binary; `dnf search` for it | |
| 17:39:28 | mnaser | i thought virt was a generic qemu-kvm machine type available for all architectures | |
| 17:39:41 | kashyap | mnaser: No. Only for AArch64/ARM | |
| 17:39:44 | kashyap | mnaser: But ... | |
| 17:39:59 | mnaser | kashyap: ok, you're right, i see it under aaarch64 on an arm box | |
| 17:40:02 | elbragstad | mriedem_afk re: your first question - i would probably write that policy check string to be something like "(role:admin and system_scope:all) or rule:owner)" | |
| 17:40:03 | kashyap | mnaser: ... there has been some talk at last year's KVM Forum about adding a similar 'virt' board for x86 | |
| 17:40:19 | gmann | dansmith: elbragstad so we can just extend the current enum to store 'id' also (do not modify column from enum->string)and that we expose in API, right ? | |
| 17:40:22 | mnaser | kashyap: ok, cool, sorry for the firedrill, misinformed on my side then :) | |
| 17:40:22 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 17:40:23 | kashyap | (Also "Kata Containers" folks, who forked QEMU, also want it) | |
| 17:40:30 | kashyap | mnaser: No worries :-) | |
| 17:40:41 | elbragstad | gmann enum definitions are kind of immutable i think | |
| 17:40:48 | dansmith | gmann: we could, but I'm not sure how important this really is, and it's not fair to saddle the other effort with too much I think | |
| 17:40:52 | mnaser | kashyap: yeah, i saw NEMU which seems like it is better solved by adding a virt machine type. | |
| 17:40:59 | dansmith | elbragstad: I think adding one thing to an enum isn't bad | |
| 17:41:26 | dansmith | elbragstad: they're stored as an int, IIRC, so adding one doesn't cause too much disruption as long as you're not removing one or adding one that causes you to need the next size up of int | |
| 17:41:32 | dansmith | but some database person should config | |
| 17:41:35 | dansmith | *confirm | |
| 17:41:40 | elbragstad | aha | |
| 17:41:52 | gmann | dansmith: but current string 'admin' will be confusing for case of scope_type as system and proejcts | |
| 17:41:53 | mnaser | kashyap: aha, from the NEMU readme "NEMU also introduces a new QEMU x86-64 machine type: virt. It is a purely virtual platform, that does not try to emulate any existing x86 chipset or legacy bus (ISA, SMBUS, etc) and offloads as many features to KVM as possible. This is a similar approach as the already existin AArch64 virt machine type and NEMU will only support the two virt machine types." | |
| 17:41:58 | mnaser | that's where i saw it from. | |
| 17:42:03 | kashyap | mnaser: There are several issues with "NEMU", and "better solved" is also debatable :-). Upstream QEMU folks are working with them to abandon the idea of a fork | |
| 17:42:07 | kashyap | And to work with upstream. | |
| 17:42:15 | gmann | i mean from API response side | |
| 17:42:24 | dansmith | gmann: you mean for the proposed spec to expose it? | |