Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-22
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?
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

Earlier   Later