| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-22 | |||
| 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 | dansmith | gmann: yeah that's the obviously difficult one | |
| 17:35:01 | gmann | we need to change the locked_by DB from enum to UUID ? | |
| 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 | mnaser | to which I don't see the `virt` option available under centos 7.6 right now | |
| 17:37:52 | kashyap | mnaser: Top off my head, I need to check which version introduced the 'virt' board for ARM/AArch64 | |
| 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 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 17:40:22 | mnaser | kashyap: ok, cool, sorry for the firedrill, misinformed on my side then :) | |
| 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? | |
| 17:42:26 | mnaser | kashyap: absolutely, what i meant was instead of creating nemu, we upstream all that stuff into a custom machine type :) | |
| 17:42:49 | gmann | dansmith: in current spec- https://review.openstack.org/#/c/638629/3/specs/train/approved/add-locked-reason.rst@117 | |
| 17:42:50 | kashyap | mnaser: Yep, that is a good idea; and x86 will "soon" get it. There have been some mind-showering sessions on QEMU usptream list | |
| 17:42:53 | dansmith | gmann: if you're really concerned about that and are willing to do the work underneath to make it not have to, then okay | |
| 17:42:54 | gmann | yeah | |
| 17:43:31 | kashyap | mnaser: So expect to see a "virt" board for x86 (that is expressely designed for guests, including of course Nova instances). | |
| 17:43:44 | mnaser | kashyap: cool, that would be super neat | |
| 17:44:24 | gmann | because this is the only API we say 'admin' or 'owner' in response. and 'admin' will be extended in scope_type system-admin or project-admin | |
| 17:44:58 | dansmith | gmann: ack, well, raise that on the spec I guess | |
| 17:47:26 | mnaser | is "urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='198.72.124.41', port=443): Read timed out. (read timeout=60)" under tempest.scenario.test_shelve_instance.TestShelveInstance a common failure? | |
| 17:47:34 | elbragstad | i think i stumbled across an article like this a while ago when we were trying to add an attribute to an enum http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/ | |
| 17:56:27 | elbragstad | mriedem i thinking keeping the `admin` or `owner` details out of the database would be a good think moving forward | |
| 17:57:05 | elbragstad | a lot of the work we're doing with scope types introduces different types of "admins", so we can't necessarily assume "admin" is always the cloud administrator/operator | |
| 18:01:40 | dansmith | elbragstad: right, that's why we're talking about this: | |
| 18:01:48 | dansmith | it's already in the db, but not exposed to the user | |
| 18:02:00 | dansmith | the spec is proposing exposing that admin|user notion to the api user | |
| 18:02:28 | dansmith | so we either need to make the api sufficiently generic or change a bunch of stuff before we can do the other part, which is locked reason | |
| 18:02:50 | elbragstad | so a user would be able to see who locked an instance? | |
| 18:02:52 | dansmith | gmann_afk: elbragstad mriedem: What if instead of exposing the person that locked it for now, we just expose a boolean which is "can I unlock it?" | |
| 18:02:56 | dansmith | elbragstad: right | |
| 18:03:11 | dansmith | but we could paper over a lot of details by just saying "you can unlock this" or "you can not unlock this: | |
| 18:03:15 | elbragstad | dansmith the "can I unlock it" bit seems like a good middle ground? | |
| 18:03:22 | dansmith | right | |
| 18:03:35 | mriedem | dansmith: that depends on policy though, which could change between the time they have that response and when they try to unlock | |
| 18:03:38 | elbragstad | as a user - i probably care less about who locked my stuff and i just want to know if i can lock it | |
| 18:03:38 | dansmith | at least lets us push the refactoring of the data store away from the current spec | |
| 18:03:40 | mriedem | granted, i wouldn't expect policy to change often | |
| 18:04:01 | dansmith | mriedem: sure, but same for exposing admin|user .. you have to now what the policy is to know whether it matters | |
| 18:04:01 | mriedem | the 'can i unlock' is a policy check | |
| 18:04:31 | elbragstad | well - to calculate that boolean you'd just need to run the context through that policy check - then populate that accordingly in the data model (and response?) | |
| 18:04:43 | dansmith | right | |
| 18:04:54 | mriedem | not the data model, but the response yes | |
| 18:04:55 | dansmith | but if you don't use the boolean, and expose "locked_by: admin" | |
| 18:05:07 | dansmith | the user has to know whether policy considers them an admin or not right? | |
| 18:05:16 | dansmith | whereas "no you can't unlock this" is pretty clear | |
| 18:05:20 | openstackgerrit | Merged openstack/nova stable/queens: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/628726 | |