| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-01 | |||
| 17:38:04 | sean-k-mooney | osa also copied the ooo trick https://bugs.launchpad.net/openstack-ansible/+bug/1902914 | |
| 17:42:00 | masterpe[m] | We are using osa. I will look into that. | |
| 17:42:34 | sean-k-mooney | masterpe[m]: what release did you say you were using? | |
| 17:44:21 | sean-k-mooney | masterpe[m]: oh and to you orignal question you can change the policy for the endpoint by defining a custom policy nova's policy.json or policy.yaml file | |
| 17:44:27 | sean-k-mooney | masterpe[m]: however you should not do that | |
| 17:45:13 | sean-k-mooney | the external events api is intended for interservice comumnication https://docs.openstack.org/api-ref/compute/#create-external-events-os-server-external-events | |
| 17:45:59 | sean-k-mooney | masterpe[m]: not even normal admin should actully call that manually as its very easy to break things and it might even be a secuirty issue in some cases. | |
| 17:46:43 | sean-k-mooney | so the only way to adress your issue is to ensure that cinder uses an admin token to talk to that endpoint | |
| 17:47:00 | masterpe[m] | My question was directly related to the error. But if there are better solution to the problem then .... | |
| 17:47:19 | sean-k-mooney | masterpe[m]: yes that is a generic policy error message | |
| 17:47:34 | sean-k-mooney | in some case adjusting policy would be valid in this case its not | |
| 18:24:49 | opendevmeet | Launchpad bug 1902914 in openstack-ansible "cinder extend "Policy doesn't allow os_compute_api:os-server-external-events:create to be performed"" [Medium,Fix released] - Assigned to Dmitriy Rabotyagov (noonedeadpunk) | |
| 18:24:49 | frickler | masterpe[m]: you need to configure cinder to use an admin user acc to talk to nova, see e.g. https://bugs.launchpad.net/openstack-ansible/+bug/1902914 | |
| 18:25:49 | frickler | oh, that's the same one as cited above | |
| 18:26:55 | frickler | fwiw we also copied that solution into openstack-chef, though | |
| 19:06:03 | opendevreview | Lee Yarwood proposed openstack/nova stable/ussuri: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793958 | |
| 19:33:50 | opendevreview | Merged openstack/nova master: Replace getargspec with getfullargspec https://review.opendev.org/c/openstack/nova/+/790405 | |
| 20:50:34 | opendevreview | Lee Yarwood proposed openstack/nova stable/train: Replace 'fake' with a real project ID https://review.opendev.org/c/openstack/nova/+/794041 | |
| 20:50:35 | opendevreview | Lee Yarwood proposed openstack/nova stable/train: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/794042 | |
| 20:50:36 | opendevreview | Lee Yarwood proposed openstack/nova stable/train: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/794043 | |
| 22:31:15 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Rollback live migraiton if cancelled while queued https://review.opendev.org/c/openstack/nova/+/794048 | |
| 22:31:15 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 22:31:31 | artom | That func test ^^ is disgusting h4xx | |
| #openstack-nova - 2021-06-02 | |||
| 00:57:12 | melwitt | gmann: I added a very late reply on https://review.opendev.org/c/openstack/nova/+/762013 if you could look at your convenience this week | |
| 00:58:18 | gmann | melwitt: sure, will check tomorrow. | |
| 00:59:02 | melwitt | cool thx | |
| 01:34:20 | opendevreview | norman shen proposed openstack/nova master: Saving security group to info_cache https://review.opendev.org/c/openstack/nova/+/786348 | |
| 06:11:58 | opendevreview | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | |
| 06:11:59 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | |
| 06:12:01 | opendevreview | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | |
| 06:12:02 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | |
| 06:12:02 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | |
| 07:24:20 | yonglihe | Hi, gibi, alex_xu, sean, smartnic patch set is revised, to make your day easy, here is a change list since last review: | |
| 07:24:35 | yonglihe | current change set: 1) drop one unnecessary cyborg call(get_arq_device_rp_uuid) | |
| 07:24:43 | yonglihe | 2) clean up arq: there is possible arq not bind to instance or port. | |
| 07:24:50 | yonglihe | addressed in both compute and conductor stages | |
| 07:25:32 | yonglihe | * functional tests | |
| 07:25:32 | yonglihe | * clean up code logic for 2 kind of ARQ: port requested ARQ and flavor reqeust ARQ. | |
| 07:25:32 | yonglihe | * add cyborg ARQ clean up for all sorts of failure | |
| 07:25:32 | yonglihe | * put the device_profile into reqeust_net(API stage), then we elimate one neutron call. | |
| 07:25:32 | yonglihe | previous change set1: | |
| 07:25:33 | yonglihe | * reject create smatnic port attached server while migration in progress | |
| 07:25:33 | yonglihe | * bump compute service version number | |
| 07:26:46 | alex_xu | yonglihe: planning to review next around | |
| 07:38:45 | nightmare_unreal | is there a way to check hypervisor kernel version through openstack | |
| 08:13:45 | bauzas | nightmare_unreal: please ask your question on the new OFTC channel | |
| 08:14:12 | bauzas | we moved the community IRC channels to OFTC last weekend | |
| 08:14:14 | nightmare_unreal | can you poing to the name what's the #tag of that channel ? | |
| 08:14:22 | bauzas | same than here | |
| 08:14:26 | bauzas | s/freenode/oftc | |
| 08:14:32 | nightmare_unreal | thanks :) | |
| 08:14:36 | nightmare_unreal | s/freenode/oftc | |
| 08:15:03 | bauzas | you'll find the exactly same rooms in the OFTC network but you'll need to register your nick again | |
| 08:15:59 | nightmare_unreal | I see , we are moving away from freenode | |
| 08:18:05 | bauzas | yup | |
| 08:18:27 | bauzas | I stick here for redirecting folks that haven't seen it yet | |
| 08:18:41 | bauzas | EOF. | |
| 09:17:41 | opendevmeet | Launchpad bug 1930406 in OpenStack Compute (nova) "parallel volume-attachment requests might starve out nova-api for others" [Undecided,New] | |
| 09:17:41 | lyarwood | melwitt: https://bugs.launchpad.net/nova/+bug/1930406 - btw when you're around later can we chat about this and any workarounds you're aware of? | |
| 09:18:21 | lyarwood | but tbh I've wanted to drop the offending RPC call for a while and this might be the report that finally pushes me to remove it | |
| 09:18:31 | lyarwood | behind a microversion | |
| 09:18:49 | lyarwood | as it changes what we return to the caller | |
| 10:09:07 | sean-k-mooney | lyarwood is it just doing the rpc for the device name which we dont even garentee inside the guest | |
| 10:09:36 | lyarwood | yeah we also create the bdm during the same call | |
| 10:09:48 | lyarwood | via the conductor so it takes a little longer | |
| 10:10:48 | sean-k-mooney | should we make this an async api and just make it a cast | |
| 10:12:33 | sean-k-mooney | we have been talking about rpc version compatiablity downstream for a while on an off | |
| 10:12:45 | lyarwood | we need the BDM creation to be sync to avoid races but we can do that on the api | |
| 10:12:53 | lyarwood | and then move this device assignment behind the already async part | |
| 10:13:20 | sean-k-mooney | one thing i have been debating in my mind is shoudl we be removing all direct calls to the compute from the api | |
| 10:13:56 | lyarwood | casts are still fine right? | |
| 10:14:06 | lyarwood | or move everything behind conductor tasks | |
| 10:14:18 | lyarwood | the latter is lots of work | |
| 10:14:34 | sean-k-mooney | i was thinking evenutally everything goes though conductor but cast might be ok | |
| 10:15:04 | sean-k-mooney | the reasonign was so that the api does not need to speak the compute node rpc version | |
| 10:15:32 | sean-k-mooney | but ya thats a larger change then you need | |
| 10:16:12 | sean-k-mooney | having the api create the bdms and then cast to do the rest async shoudl be fine in this case | |
| 10:17:32 | gibi | melwitt: when you are up, I managed to make CI green on https://review.opendev.org/c/openstack/nova-specs/+/788243 (and get bauzas +2) | |
| 10:25:14 | opendevreview | Elod Illes proposed openstack/nova stable/wallaby: [stable-only] Fix ceph install in live migration hook https://review.opendev.org/c/openstack/nova/+/794000 | |
| 10:26:24 | sean-k-mooney | melwitt: gibi: quick question about consumer types. will there be an api that allows me to list all allocation by consumer types and optionall filter that | |
| 10:27:55 | sean-k-mooney | for filtering i was thinking by host, project and maybe consumer/vm id | |
| 10:28:52 | sean-k-mooney | the reason im asking is the mailing list thread related to premptible instnaces. | |
| 10:29:35 | sean-k-mooney | one of the suggtions i had was to explore using a "premptible" consumer type for premtiable instances | |
| 10:30:29 | sean-k-mooney | initally if we had a query api it would allow and external service to esaisly determing what instance could be killed via a placment query | |
| 10:31:42 | sean-k-mooney | but i coudl imaging later extending plamcnet so that it coudl optionalling include the capsity used by preamtiable instance in its allocation candates set with a new micorverion and query arg | |
| 10:33:15 | sean-k-mooney | not that im going to work on that any time soon but i just taught that would enable and intersting desgin direction to explore | |
| 10:37:14 | jkulik | lyarwood, sean-k-mooney: wouldnt "having the api create the bdms" mean, that we need distributed locking between the apis, so we don't run into races while creating those? | |
| 10:38:07 | sean-k-mooney | jkulik: we are creating them in the db so we can do a db level lock if we needed too | |
| 10:38:07 | lyarwood | We'd need rely on the DB ensuring there's only ever one active BDM for a given instance UUID and volume ID combo | |
| 10:38:42 | jkulik | is multi-attach possible for the same VM? | |
| 10:38:50 | lyarwood | not for the same instance no | |
| 10:38:57 | sean-k-mooney | jkulik: within the same vm no | |
| 10:39:54 | sean-k-mooney | if we need a lock we can take a row level lock on the instance uuid or instance and volumne uuid pair | |
| 10:40:20 | lyarwood | tbh a constraint should be enough | |
| 10:40:44 | lyarwood | at least that's what was agreed on in the past when this came up | |
| 10:41:05 | lyarwood | but that was in the context of us creating duplicate BDMs on failure | |
| 10:41:15 | lyarwood | *failure to attach | |
| 10:41:20 | lyarwood | that hasn't been an issue for a while now | |
| 10:41:36 | sean-k-mooney | ya there is no index in the bdm that we need to worry about is there | |
| 10:41:44 | jkulik | lyarwood: "for a while" - which version do I need to upgrade to? :D | |