Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-03
16:54:03 gibi wait are there three options?!
16:54:25 gibi /o\
16:54:25 stephenfin Yes. I should have delineated that better :-D
16:54:44 gibi I see now
16:55:20 gibi so I definitely dont like option B) as it changes from the big table outpot of server show to a small specific table
16:55:34 stephenfin Okay, we're on the same page there
16:55:54 stephenfin The only reason I considered it was because we have a '--diagnostics' flag that essentially does that
16:56:07 stephenfin (totally changes the content and meaning of the output based on a single flag)
16:56:10 gibi then I don't like --diagnostics either :D
16:56:15 frickler so why do you need the --tags option at all for c)? can't you just include the tags in the output if the api version supports it?
16:56:31 stephenfin frickler: Quite possibly. It's a second API call though
16:56:40 stephenfin Why, I don't know. Possibly change for a future microversion
16:56:46 frickler oh
16:56:48 stephenfin *possible
16:57:53 mnasiadka gibi: thanks!
16:58:00 gibi both a) and c) works for me, we can even have both
16:58:10 frickler then a) doesn't sound so bad any longer
16:59:15 stephenfin I'm tempted to go with (c) because we have '--tag' parameters for multiple other commands now
16:59:42 stephenfin i.e. 'openstack server create --tag TAG ...', 'openstack server set --tag TAG ...'
17:00:15 gibi stephenfin: how -c and --tag will interact in the server show case?
17:01:13 stephenfin that's a good point. I suspect we'll have to do something like https://review.opendev.org/741181
17:01:41 stephenfin It all depends on whether we want OSC to exactly mirror the API, or to smooth out some of its wrinkles
17:02:14 frickler mostly the latter I'd say
17:02:25 frickler can "openstack server list" show tags?
17:02:31 stephenfin me too
17:02:38 frickler or only filter on them?
17:02:57 stephenfin only filter afaik (it's done server-side)
17:11:01 frickler hmm, from the api-ref, both list-servers-detailed and show-server-details should contains tags. so no additional api call for c) and no need for an extra "--tags" option IMO
17:11:26 frickler also a good reason to be able to include tags in "server list", too
17:13:17 stephenfin frickler: gdi :D
17:13:41 stephenfin with zero changes on http://paste.openstack.org/show/799663/
17:13:48 stephenfin *OSC master
17:14:13 stephenfin okay, so we need to clean up that output but otherwise no changes necessary. phew
17:15:47 frickler stephenfin: one thing to look at would be how the output is formatted as yaml. there was someone having a hard time fixing the output for multiple addresses. or was it sec gps?
20:19:30 openstackgerrit Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Only ask tpool.Proxy to autowrap vir* classes https://review.opendev.org/761222
20:19:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Only ask tpool.Proxy to autowrap vir* classes https://review.opendev.org/761223
20:20:07 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Only ask tpool.Proxy to autowrap vir* classes https://review.opendev.org/761224
21:34:20 openstackgerrit Merged openstack/nova stable/pike: Follow up for cherry-pick check for merge patch https://review.opendev.org/761024
#openstack-nova - 2020-11-04
00:25:39 brinzhang_ artom: ack, thanks
01:14:43 openstackgerrit Jorhson Deng proposed openstack/nova-specs master: Add instance_state to ensure volume attachment successful https://review.opendev.org/758920
02:57:06 openstackgerrit Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264
03:19:39 openstackgerrit Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264
03:23:37 openstackgerrit Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264
03:27:33 openstackgerrit Brin Zhang proposed openstack/nova stable/victoria: optimize the shelve code flow https://review.opendev.org/761268
05:53:57 Jorhson lyarwood: Hi, i think we should better to add task state, because that can avoid conflicting with other tasks.
05:55:22 Jorhson lyarwood: and change the code with minimal cost.
05:58:32 Jorhson lyarwood:https://review.opendev.org/#/c/758920/ @75
06:01:04 Jorhson lyarwood:https://review.opendev.org/#/c/758920/11/specs/wallaby/approved/ensure-volume-attachment-successful.rst@75
06:05:42 brinzhang_ lyarwood: jorhson's mean your point in PS9 in this specification
07:46:08 openstackgerrit Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264
09:14:44 openstackgerrit Elod Illes proposed openstack/nova stable/pike: Lowercase ironic driver hash ring and ignore case in cache https://review.opendev.org/723055
09:24:29 lyarwood johanssone / brinzhang_ ; morning
09:34:06 brinzhang_ lyarwood: good morning
09:34:22 brinzhang_ jorhson^
09:36:49 lyarwood johanssone / brinzhang_ ; sorry just as I started replying here I had to jump offline and help with childcare
09:36:54 lyarwood argh
09:36:59 lyarwood Jorhson: sorry
09:37:26 lyarwood Jorhson / brinzhang_ ; so my main issue still with the spec is the change of behaviour in the API that it's introducing
09:38:18 lyarwood Jorhson / brinzhang_ ; before multiple requests would be queued within the computes, with this change callers will have to retry if there's already a request in-flight against the instance
09:38:47 lyarwood Jorhson / brinzhang_ ; that's at least a microversion IMHO
09:39:05 Jorhson lyarwood: if in this way, should we add the task state for this option?
09:39:27 lyarwood Jorhson: this is if you add a task state
09:39:51 lyarwood Jorhson: n-api will start rejecting attach volume requests if the task_state is already ATTACHING, instead of allowing n-cpu to queue things
09:40:26 Jorhson lyarwood: yeah, this is conflicting
09:40:54 lyarwood Jorhson: this all comes down to the RPC call to reservice_block_device_name
09:41:38 lyarwood Jorhson: and I honestly think we can just drop device_name from the APIs and remove this, again with a microversion
09:42:03 Jorhson lyarwood: but i also think it's need for this options, because attaching volume is independent option
09:42:25 lyarwood Jorhson: true but that's why we queue things in the compute with the various locks
09:43:01 Jorhson lyarwood: there will be conflicting if we do others task while the attching task is not over
09:43:02 lyarwood Jorhson: we'd be changing the semantics of the API here pretty drastically and forcing the callers to retry by introducing these task_states
09:43:22 brinzhang_ jorhson: agree with lyarwood, add a microversion to remove the device, and in order to avoid the conflict, we also need to add the task_state as current description in your spec
09:43:47 lyarwood well we have the instance.uuid lock to avoid conflicts
09:44:03 lyarwood most compute operations should be taking that IMHO
09:44:15 lyarwood I know it's not the case for everything at the moment
09:46:33 lyarwood so what if we didn't reject the request if the task_state was attaching and queued it in the API somehow?
09:46:39 lyarwood Jorhson / brinzhang_ ; ^
09:47:46 Jorhson lyarwood: yeah, for the users, there are less probability to attach multiple volumes, and i agree with your sheme, but i think it's important to solve the option's conflict
09:48:18 lyarwood Jorhson: it's a pretty common usecase with k8s running on OpenStack IMHO
09:54:38 brinzhang_ lyarwood: ok, I understand what you mean, agree
09:55:28 brinzhang_ lyarwood: Jorhson will update this spec later, this way it's better for k8s on OpenStack scenario
09:59:36 lyarwood brinzhang_: ack many thanks both, I'm going to be AFK again this afternoon UK time but I'll review the spec this evening once I'm back.
10:00:34 brinzhang_ lyarwood: ack, thanks too
10:01:52 aarents Hi nova
10:02:22 aarents lyarwood: there is some progress on that q35 bug: https://bugs.launchpad.net/nova/+bug/1832248 , if it is a qemu bug, what is the suitable status for this bug Fixed_in_relsease or invalid?
10:02:22 openstack Launchpad bug 1832248 in OpenStack Compute (nova) "tempest.api.volume.test_volumes_extend.VolumesExtendAttachedTest.test_extend_attached_volume failing when using the Q35 machine type" [Medium,Triaged] - Assigned to Alexandre arents (aarents)
10:07:26 lyarwood aarents: awesome sleuthing! :)
10:08:04 lyarwood aarents: erm, invalid I guess? gibi ^ any thoughts, looking to close a Nova bug that was actually a QEMU bug that has already been fixed
10:09:11 gibi lyarwood: if it is fixed in QEMU and no need for any nova change then Invliad it is
10:09:20 gibi Invalid even
10:09:25 lyarwood cool thanks
10:15:38 aarents cool, I just hope it will fix also my downstrem bug regarding interface attach!
11:56:55 sean-k-mooney do we need to enable the new qemu from the cloud arcive on ussuri and below to ensure we dont hit that bug
12:04:23 openstackgerrit Wenping Song proposed openstack/nova-specs master: Support vGPU management by Cyborg https://review.opendev.org/750116
13:04:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent starting services with older than N-1 computes https://review.opendev.org/738482
13:04:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add upgrade check about old computes https://review.opendev.org/760520
13:19:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent starting services with older than N-1 computes https://review.opendev.org/738482
13:21:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add upgrade check about old computes https://review.opendev.org/760520
13:23:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use _evacuate_server helper in func test https://review.opendev.org/758210
13:27:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reproduce bug 1897528 https://review.opendev.org/756696
13:27:17 openstack bug 1897528 in OpenStack Compute (nova) "32bit pci domain number is not supported" [High,In progress] https://launchpad.net/bugs/1897528 - Assigned to Balazs Gibizer (balazs-gibizer)

Earlier   Later