| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-03 | |||
| 13:17:52 | mnasiadka | gibi: commented in the ticket | |
| 13:20:03 | gibi | mnasiadka: thanks | |
| 13:23:17 | gibi | mnasiadka: I cannot open the links you posted in the bugreport | |
| 13:23:25 | gibi | I get e.data.info is undefined (Unable to fetch URL, check your network connectivity, browser plugins, ad-blockers, or try to refresh this page) | |
| 13:23:35 | mnasiadka | gibi: let me check, I'll update to raw links maybe | |
| 13:23:45 | gibi | yeah, raw links would be better, thenks | |
| 13:23:47 | gibi | thanks | |
| 13:24:30 | artom | brinzhang_, yeah, I mean the cpu_dedicated_set config option | |
| 13:25:11 | artom | brinzhang_, https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_dedicated_set this one | |
| 13:26:19 | artom | If they're different on source and destination, we would expect the vcpupin elements (https://libvirt.org/formatdomain.html#cpu-tuning) in the XML to change | |
| 13:28:34 | mnasiadka | gibi: should be better now ;) | |
| 13:30:07 | gibi | mnasiadka: thanks, links are working now. I will check the content after my afternoon meetings | |
| 14:19:12 | spatel | sean-k-mooney: morning | |
| 14:19:39 | spatel | I have question about dpdk so thought you will be right person to ask :) let me know if you have time. | |
| 15:50:45 | artom | spatel, he's on PTO today I believe | |
| 15:52:20 | spatel | artom: thanks for reply, no worry. | |
| 15:52:49 | spatel | My question was why CentOS 8.2 remove dpdk support from OpenVSwitch :) | |
| 15:53:15 | spatel | anyway i am re-compiling from source and packaging to see if that works | |
| 16:33:46 | gibi | mnasiadka: I found the root cause of the bug. It is a kombu and amqp package version bump that is not compatible with oslo.messaging. Details are in: https://bugs.launchpad.net/oslo.messaging/+bug/1902696 | |
| 16:33:46 | openstack | Launchpad bug 1902696 in oslo.messaging "nova-compute fails with Unhandled error: TypeError: _wrap_socket_sni() got an unexpected keyword argument 'ca_certs'" [Undecided,New] | |
| 16:43:55 | gibi | mnasiadka: pushed a requirement pin to avoid ^^ https://review.opendev.org/#/c/761194/ | |
| 16:50:47 | stephenfin | artom, gibi, (others): When listing server tags, what's more intuitive http://paste.openstack.org/show/799661/ ? | |
| 16:52:48 | gibi | stephenfin: openstack server show already makes the second proposal more natural as it is how the output of server show look like in other cases | |
| 16:53:02 | gibi | I mean server show is a big table | |
| 16:53:25 | stephenfin | option (a) is what's proposed at https://review.opendev.org/756019. option (b) mirrors what we do for diagnostics (openstack server show --diagnostics). option (c) simply enhances the existing 'server show' command | |
| 16:54:03 | gibi | wait are there three options?! | |
| 16:54:25 | stephenfin | Yes. I should have delineated that better :-D | |
| 16:54:25 | gibi | /o\ | |
| 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? | |