| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 15:05:58 | stephenfin | gibi: Yup, and for those cases we stick a note at the top saying "this has been removed in foo" and update the return codes to include HTTP 410 | |
| 15:06:02 | sean-k-mooney | lpetrut: we will be going to livbirt 6.0.0 and qemu 4.2.0 this cycle | |
| 15:06:11 | stephenfin | https://docs.openstack.org/api-ref/compute/#ping-instances-os-fping | |
| 15:06:16 | stephenfin | "This API only works with nova-network which is deprecated. It should be avoided in any new applications. These will fail with a 404 starting from microversion 2.36. It was removed in the 18.0.0 Rocky release." | |
| 15:06:32 | sean-k-mooney | lpetrut: dcapone2004 so at that point we coudl enable all of them | |
| 15:07:22 | lpetrut | I think all the above mentioned flags should be supported by qemu 4.0.0, not sure if libvirt needs to be aware of those as well | |
| 15:07:36 | sean-k-mooney | https://libvirt.org/formatdomain.html#hypervisor-features | |
| 15:07:44 | sean-k-mooney | the versions are listed there | |
| 15:08:48 | gibi | stephenfin: OK, then what to do with this https://review.opendev.org/c/openstack/nova/+/765311/1/api-ref/source/parameters.yaml#396 | |
| 15:09:24 | stephenfin | we should keep it but not update it | |
| 15:09:48 | gibi | stephenfin: keep it as we cannot update the already deleted code | |
| 15:09:50 | gibi | is it? | |
| 15:09:55 | lpetrut | sean-k-mooney: nice, then I guess Nova could set those flags. I'm still not 100% if that should be the default or if it should be opt-in | |
| 15:09:56 | stephenfin | yes | |
| 15:10:03 | stephenfin | it's just documentation | |
| 15:10:13 | gibi | stephenfin: OK, thanks. it is clear now | |
| 15:10:52 | dcapone2004 | ipetrut: an enable_hyperv_support property maybe? | |
| 15:12:01 | lpetrut | dcapone2004: yep, that would probably be the way to go unless it becomes the default for Windows guests | |
| 15:13:42 | lpetrut | we could take another look at qemu, maybe even ask the qemu guys if they think there's any potential issue (e.g. affecting perf, stability or older guests) in using those flags by default | |
| 15:15:19 | dcapone2004 | ipetrut: if you discuss, all fo the othe rflags are already added, the only ones that were added in addition were these 4: hv-vpindex,hv-runtime,hv-synic,hv-reset I know I mentioned that earlier, but figured I would just bring that up again | |
| 15:15:26 | lpetrut | I assume most of those features are related to Hyper-V VMBus (virtio equivalent), so older guests might not support those enlightments | |
| 15:16:16 | lpetrut | dcapone2004: right, this list is very helpful | |
| 15:16:21 | sean-k-mooney | so what we bacially will want is an image proerty | |
| 15:16:27 | sean-k-mooney | that is a list of enum values | |
| 15:16:47 | sean-k-mooney | and the image could declare what it supports | |
| 15:16:58 | sean-k-mooney | we can add the current allways on enlighemtn as the defualt for the value | |
| 15:17:29 | sean-k-mooney | the other way is to use traits | |
| 15:17:43 | lpetrut | sean-k-mooney: sounds good. fwiw, new hyper-v enlightments might be added in the future so it's probably important to be able to pick the ones that the image supports | |
| 15:18:52 | lpetrut | while having some safe defaults | |
| 15:19:08 | sean-k-mooney | dcapone2004: so this is basically evolving form a potenial bug to a feature request | |
| 15:19:09 | noonedeadpunk | hi! Any idea why I might be seing this http://paste.openstack.org/show/800707/ when `backend` is set to `oslo_cache.memcache_pool` in [cache]? | |
| 15:19:30 | sean-k-mooney | is this something you would have capsity to work on or just soemthjing you would like to see added | |
| 15:20:28 | sean-k-mooney | noonedeadpunk:that proably more of an oslo question | |
| 15:20:32 | lpetrut | sean-k-mooney: I can't remember, does the libvirt nova driver allow you to set arbitrary cpu flags? | |
| 15:21:21 | sean-k-mooney | noonedeadpunk: https://github.com/openstack/oslo.cache/blob/master/oslo_cache/backends/etcd3gw.py#L17 | |
| 15:21:30 | sean-k-mooney | lpetrut: cpu flags yes but these are not cpu flags | |
| 15:21:41 | sean-k-mooney | lpetrut: and only via the nova config | |
| 15:21:59 | sean-k-mooney | noonedeadpunk: it look like it does an unconditonal import | |
| 15:22:02 | noonedeadpunk | it feels it tries to load all modules possible... so nova just passes [cache] section just directly to oslo? (I'm not very common with codebase still - it's huge) | |
| 15:22:38 | sean-k-mooney | noonedeadpunk: these config option are actully adde by oslo.cache | |
| 15:23:54 | noonedeadpunk | I'm jsut not sure why it loads etcd3gw backend at all... | |
| 15:26:05 | sean-k-mooney | im guessing its usign the stevado extention manager to load it unconditonally | |
| 15:26:11 | sean-k-mooney | looking for that currently | |
| 15:29:16 | sean-k-mooney | noonedeadpunk: where is that being raised | |
| 15:30:05 | noonedeadpunk | found it here https://zuul.opendev.org/t/openstack/build/0af9364cc9094b5096899ed7693a9f60/log/logs/host/nova-conductor.service.journal-10-50-46.log.txt#2431 | |
| 15:31:55 | sean-k-mooney | we are not using sevedor to load this in oslo cache or in nova | |
| 15:32:33 | noonedeadpunk | um..... | |
| 15:32:56 | sean-k-mooney | im wondering if this is coming form oslo.config | |
| 15:33:22 | noonedeadpunk | can hardly imagine path of the imports tbh | |
| 15:33:54 | noonedeadpunk | But I think it appeared only in V since in U haven't seen that message | |
| 15:33:57 | sean-k-mooney | we are using oslo cache | |
| 15:34:20 | sean-k-mooney | but i dont see it directly using sevedor in its code | |
| 15:34:48 | noonedeadpunk | ah, yes, might be oslo.config that using it, right | |
| 15:34:54 | sean-k-mooney | https://codesearch.opendev.org/?q=stevedore&i=nope&files=&excludeFiles=&repos=openstack/nova,openstack/oslo.cache,openstack/oslo.config,openstack/oslo.privsep | |
| 15:34:58 | sean-k-mooney | that is what im looking at | |
| 15:35:44 | sean-k-mooney | we use stevador for 3 things in nova, extra spec validator, schudler dirvers and metric monitors | |
| 15:36:10 | sean-k-mooney | oslo cache and oslo privsep dont use it at all it just in ther lower constraits | |
| 15:36:20 | sean-k-mooney | because they depend on oslo.config which does use it | |
| 15:37:41 | sean-k-mooney | it might be https://github.com/openstack/oslo.cache/commit/308f49aaaad554573aeff8ddc68c39ff7fe57438 | |
| 15:37:50 | noonedeadpunk | seem like https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2152-L2154 | |
| 15:37:53 | noonedeadpunk | yeah | |
| 15:38:31 | sean-k-mooney | ya | |
| 15:40:26 | sean-k-mooney | anyway this seams to be an oslo issue in one form or another | |
| 15:41:02 | noonedeadpunk | yeah, agreed - thanks for helping out - will go and chase oslo folks | |
| 15:57:13 | gibi | nova weekly meeting starts in 3 minutes on #openstack-meeting-3 | |
| 15:57:29 | gmann | gibi: sean-k-mooney we need to put API patch changes at the end which bump the microversion and all code cleanup as first in the series. and rebase is so hard for microversion race i think we end up doing this in every cycle. brin is not online I will check with him on policy stuff help | |
| 15:57:57 | gmann | ypo. * rebase is *not* so hard for microversion | |
| 15:59:55 | gibi | gmann: most of the changes needed for the tenant_id bp is actually changes in the API code so we cannot frontload tha backend change as there is none | |
| 16:00:50 | gmann | gibi: yeah but i think code cleanup also there which i suspect a large chunk but need to grep and see. | |
| 16:01:31 | gmann | I think having all changes up and zuul +1 then we can start merging. | |
| 16:01:36 | gibi | gmann: I thin the majority of the change line vise is api sample changes and test code, and both need to have the microversion bump already in place | |
| 16:02:02 | gibi | gmann: yes, that would be ideal, but Brin noted that this will be a lot of patches | |
| 16:02:22 | gmann | humm | |
| 16:02:23 | gibi | so we talked about options | |
| 16:02:38 | gibi | but at the end we found no viable option other than having all the patches | |
| 16:02:55 | gibi | (if we want to keep them in a single microversion) | |
| 16:03:29 | gmann | and base patch with -W until all are ready ? | |
| 16:13:07 | gibi | yeah, basically | |
| 16:13:54 | gibi | if we could merge every other API impacting changes accepted to W then maybe we can consider merging some of the tenant_id stuff or at least reconsider it | |
| 16:14:14 | gibi | so now it is all or nothing | |
| 16:17:47 | gmann | gibi: +1 | |
| 16:21:06 | gibi | sean-k-mooney: if you are around we need you in #openstack-meeting-3 | |
| 16:37:38 | dcapone2004 | sean-k-mooney: sorry, I had a meeting I needed to attend...I was always thinking about it as a feature request .... and I wish I had the capacity to contribute way more than I do....I know python, but I have never done formal software development, so the whole submitting patches, code review process escapes me :-( | |
| 16:42:21 | kashyap | dcapone2004: FWIW, it's actually gotten significantly simpler; OpenStack Gerrit also provides a "sandbox" to practise your workflow | |
| 16:42:46 | kashyap | (https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html) | |
| 16:43:05 | dcapone2004 | nteresting...I will take a look at that | |
| 16:43:15 | sean-k-mooney | dcapone2004: thats ok. can you file a blueprint for this https://blueprints.launchpad.net/nova/+addspec | |
| 16:43:55 | sean-k-mooney | dcapone2004: basically like a bug but descibing your use case, what we have learns and what we your are trying to do | |
| 16:44:03 | dcapone2004 | sean-k-mooney: that I can do | |
| 16:44:33 | sean-k-mooney | if you can include the 4 enlightments that were need in your case that will helpt o document them | |
| 16:44:38 | dcapone2004 | kashyap: The part that more eludes more than the simple checkout check in or review process is the whole multiple people working on the same thing at once and how that all gets merged | |
| 16:46:00 | kashyap | dcapone2004: It takes some time getting used to, but it's not as complex - if you're focusing on one small part of the code | |
| 16:46:40 | kashyap | dasp: If someone modified the same area of code that you're working on and that got merged; you'll need to do a bit of conflict/rebasing -- which can be worked out with more experienced contributors :-) | |
| 16:46:48 | kashyap | Err, I meant dcapone2004 --^ | |
| 16:47:27 | dcapone2004 | I will definitely take a look and play around...would love to contribute and by doing so, I know I would indirectly learn a whole bunch more about openstack in general | |
| 16:58:39 | stephenfin | sean-k-mooney: gibi: bauzas: (fore after the meeting) before I send this email, are we sure we want to strip everything after the first period as opposed to replacing periods with dashes? | |
| 16:58:47 | stephenfin | *for | |
| 16:59:21 | sean-k-mooney | either of those i coudl be ok with | |
| 16:59:58 | sean-k-mooney | periods to dashes is the recommend transformation in the RFS and docs for /etc/hostname and systemd-hostnamed | |
| 17:00:25 | sean-k-mooney | just using the first segment is acutlly striping the domain and using the hostname for the host name field | |