Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-22
15:52:36 mriedem hmm, i wonder if locked_by is still used on unlock https://review.openstack.org/#/c/38196/13/nova/compute/api.py@2490
15:52:51 dansmith it's what gates whether or not you can unlock right?
15:52:54 gmann I am adding lock as [system, project] scope_type in my PoC of scope_type - https://review.openstack.org/#/c/645452/2/nova/policies/lock_server.py
15:53:06 mriedem ah it is
15:53:49 gmann but we have overridden unlock also i think that is for admin to unlock owner server
15:53:52 gmann owner locked server
15:54:11 mriedem os_compute_api:os-lock-server:unlock:unlock_override
15:54:12 mriedem yuck
15:54:23 mriedem baking policy into the db
15:54:44 dansmith ready for friday to be over already?
15:54:44 gmann yeah, we should remove that also. not sure any reason to keep that
15:56:29 gmann are we going to expose 'locked_by' also ? not checked the spec yet
15:57:27 tssurya dansmith: umm you want to add "other" where ? as in locked_by enum schema needs to change ? or just in the response api terminology for future needs ?
15:57:42 dansmith tssurya: just the api schema for the future
15:57:54 tssurya okay
15:58:00 dansmith we should get some agreement on that (and the actual enum value) first though
15:58:06 tssurya yea
15:58:07 mriedem dansmith: i replied to that comment,
15:58:11 dansmith and mriedem is too busy barfing
15:58:13 mriedem Instance.locked_by is just a string
15:58:21 mriedem which will get spewed back out of the api response
15:58:36 mriedem so if we allow storing a user_id in there in the future, it's a db schema change but shouldn't really mean any change to the instance object or api
15:58:41 dansmith oh sorry, I assumed it was an enum in the json schema too
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 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 ...

Earlier   Later