Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-22
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?
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 dansmith at least lets us push the refactoring of the data store away from the current spec
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:40 mriedem granted, i wouldn't expect policy to change often
18:04:01 mriedem the 'can i unlock' is a policy check
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: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
18:05:27 elbragstad ++
18:05:29 openstackgerrit Merged openstack/nova stable/queens: Avoid BadRequest error log on volume attachment https://review.openstack.org/640116
18:05:55 dansmith the fact that it could change between check and attempt is pretty much the case for everything :)
18:05:56 elbragstad "admin" is kinda confusing, what is locked by a project admin, a domain admin or a system admin?
18:06:11 elbragstad s/what/was/
18:06:17 mriedem in this case project admin == 'owner'
18:06:24 mriedem same as if the owner of the instance locked it themselves
18:06:28 mriedem it's the system admin case that is wonky
18:07:00 elbragstad i'm missing the part why the system-admin case is wonky
18:07:26 mriedem i mean the case where the locked_by is 'admin' today is if someone outside the project that owns the instance locks the instance
18:07:38 mriedem project admin locking the instance treats locked_by as 'owner'
18:08:18 elbragstad ... interesting
18:08:26 mriedem idk how i feel about returning an at-the-time-of-request policy check boolean saying if you can or cannot unlock it with a subsequent unlock call, i don't think we have anything else like that in the api
18:08:27 elbragstad someone outside the project?
18:08:53 dansmith I totally don't understand the concern over the policy thing
18:09:01 dansmith we return data (or not) based on policy
18:09:32 mriedem for faults and event traceback yeah

Earlier   Later