Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-03
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
17:00:56 sean-k-mooney striping woudl be using the dns "host name" for the non DNS "hostname"
17:01:39 sean-k-mooney those should generally be the same but are not required to be.
17:01:48 bauzas stephenfin: I'm personnally on the former side
17:02:05 artom bauzas, https://bugzilla.redhat.com/show_bug.cgi?id=1721068#c41 oh yeah we did
17:02:05 openstack bugzilla.redhat.com bug 1721068 in openstack-nova "allocations database is not properly cleaned" [Medium,Closed: errata] - Assigned to sbauza
17:02:16 artom (QE it on Queens, I mean)
17:02:21 bauzas changing periods to dashes is less easy to explain in terms of backportability IMHO
17:02:23 sean-k-mooney gibi: QE is quality engenering basically our test engineeres
17:02:28 gibi thanks
17:02:36 sean-k-mooney gibi: so QE'd just means tested by them
17:02:42 bauzas artom: I know I'm old but I remembered this
17:03:02 stephenfin bauzas: same thing, no? The hostname is going to be different in both cases
17:03:18 sean-k-mooney bauzas: reading the orginal unicode bug i woudl consider the current unicode bhavior to be invalid and actully a bug
17:03:21 gibi as we consider the audit a big win, and we did backported nova-manage commands in the past. I'm OK to take the risk
17:03:27 gibi and merge the backports
17:03:29 artom bauzas, hehe
17:03:33 artom So the train one wasn't so bad: https://review.opendev.org/c/openstack/nova/+/720838
17:03:35 gibi but I don't have +2 on stable :)

Earlier   Later