Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-08-17
16:29:39 gibi the BOCHS trait probably needs kashyap answer as stephenfin had some feedback on https://review.opendev.org/c/openstack/os-traits/+/794807
16:29:44 sean-k-mooney as in the host can boot in uefi mode not that it can virtualise it
16:30:10 sean-k-mooney so i think HW_FIRMWARE_UEFI shoudl be COMPUTE_FIRMWARE_UEFI
16:30:34 gibi ohh, that is a good point
16:30:45 gibi stephenfin: ^^ :)
16:30:53 sean-k-mooney the bosh trait looks correct but ill read stpehns commnets
16:31:04 gibi sean-k-mooney: thanks
16:31:15 gibi anything else about the coming lib feature freeze?
16:32:36 gibi #topic PTG Planning
16:32:40 gibi every info is in the PTG etherpad #link https://etherpad.opendev.org/p/nova-yoga-ptg
16:32:48 gibi If you see a need for a specific cross project section then please let me know
16:33:03 gibi s/section/session/
16:34:22 gibi any question about the PTG?
16:35:09 gibi #topic Stable Branches
16:35:14 gibi stable/queens is blocked (tempest-full-py3 @ "Starting Horizon", probably due to queens-eol of horizon)
16:35:18 gibi all the other branches' gate look OK
16:35:21 gibi EOM from elodilles
16:35:56 elodilles i've proposed a quick fix for queens gate: https://review.opendev.org/c/openstack/devstack/+/804889
16:36:13 gibi elodilles: thanks
16:36:19 gibi any other news from stable-land?
16:36:48 elodilles nothing from me
16:37:19 gibi OK moving on
16:37:32 gibi I'm skipping libvirt subteam as bauzas_away is on PTO
16:37:39 gibi #topic Open discussion
16:37:43 gibi (melwitt): unified limits series is ready for review (https://blueprints.launchpad.net/nova/+spec/unified-limits-nova) https://review.opendev.org/q/topic:bp/unified-limits-nova
16:37:59 gibi I started on that ^^ and will continue tomorrow
16:38:10 opendevreview Merged openstack/nova stable/wallaby: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/796258
16:38:10 gibi but one more core is needed
16:38:40 gibi who feels the power?
16:39:00 melwitt yeah just wanted to give a quick heads up that this is up-to-date, as some know it was stalled for awhile. it's a "tech preview" status where the legacy quota APIs are read-only and there are no quota migration tools, it is DIY for operators to try out
16:39:20 sean-k-mooney dansmith: lyarwood do ye have time to review the unified limits series
16:39:30 melwitt I have added some tempest test coverage that Depends-On it that can be looked at to see it working
16:39:44 dansmith do I? no. should I? yes. Will I? I'll try :)
16:39:53 sean-k-mooney :)
16:39:58 melwitt hehe ++
16:40:41 gibi :)
16:40:42 melwitt thanks all for listening, we can move on I think
16:40:46 gibi ok
16:41:06 gibi there is one more topic on the wiki
16:41:07 gibi (gibi): PTL nomination is open. As I noted in my Xena nomination, I will not run for the 4th time as Nova PTL.
16:41:50 gibi if you have questions about the role as you consider running for it then feel free to ask me
16:43:37 gibi nothing else on the agneda
16:43:47 gibi is there anything else to discuss today?
16:44:56 gibi if not then thanks for joining
16:45:08 ganso gibi: I will do more testing with the hostname config and /etc/hosts later today and I will mark that bug as invalid if successful (probably will be) =)
16:45:18 gibi ganso: cool, thanks
16:45:20 gibi #endmeeting
16:45:20 opendevmeet Meeting ended Tue Aug 17 16:45:20 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:45:20 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-08-17-16.01.html
16:45:20 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-08-17-16.01.txt
16:45:20 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-08-17-16.01.log.html
16:46:05 sean-k-mooney gibi: ganso so i looked at https://review.opendev.org/c/openstack/nova/+/804303 in parallel
16:46:20 sean-k-mooney it looks ok to me modulo some nits
16:47:25 ganso sean-k-mooney: thank you very much! I will address them this afternoon!
16:52:41 melwitt dansmith: tangentially related, I updated the oslo.limit caching patch a couple of weeks ago to address your comments if you wanted to take another look https://review.opendev.org/c/openstack/oslo.limit/+/802814
16:52:56 gibi ganso, sean-k-mooney: I also checked and it seems in the non tap case vcpu=1 and multiqueue works today
16:53:39 dansmith melwitt: ack
17:04:33 sean-k-mooney gibi: ya it weird i expect it to work and just configure 1 queue
17:17:45 ganso gibi: thanks! so the patch looks good?
17:18:39 gibi ganso: yapp
17:53:20 melwitt johnthetubaguy[m]: not sure if you would be able to take a quick look, but are you opposed to the idea of putting global limits in keystone as well, instead of setting them in config? https://review.opendev.org/c/openstack/nova/+/712142/14#message-76a84195c59afe78a2a26cbfd8d710bb2ad10165
18:03:13 opendevreview Rodrigo Barbieri proposed openstack/nova master: Fix 1vcpu error with multiqueue and vif_type=tap https://review.opendev.org/c/openstack/nova/+/804303
18:17:37 ganso sean-k-mooney: I had tested nova.instances.vcpus doing resizes and seeing that the value in that variable has the same content as the new flavor. I also think nova.instances.vcpus is more performant where it does not need to join tables to get that value
18:17:53 sean-k-mooney melwitt: e.g. having global_vcpu_limit or sometihng in keysotne and then useing that
18:18:30 sean-k-mooney ganso: its a copy of the flaovr value
18:18:37 sean-k-mooney we likely should remove it in the future
18:18:47 sean-k-mooney and make it a property that just gets it form the flaovr
18:19:06 sean-k-mooney ganso: but the the xml generation exctra will never use instance.vcpus
18:19:14 ganso sean-k-mooney: what if the flavor is edited? where will the original value be saved?
18:19:32 sean-k-mooney ganso: the in the instnace_extra table
18:19:44 ganso sean-k-mooney: oh I see, so it is not directly from the flavors table
18:19:46 sean-k-mooney we make a copy of the flavor per instance
18:19:58 sean-k-mooney ganso: no its not form the api db
18:20:23 sean-k-mooney instance.flavor.vcpu is comming form the copy of the flaovr created when the instance was created
18:20:35 sean-k-mooney instnace.vcpu is identical
18:20:47 sean-k-mooney ganso: if other are ok with it it should work
18:21:03 sean-k-mooney ganso: i just tought we had deprecated instance.vcpus already
18:21:34 sean-k-mooney along with instance.memory_mb and the other thngs that are in the flavor
18:23:09 ganso sean-k-mooney: I probably would need to retest a resize to see if instances.get_flavor().vcpus gets the old or the new flavor
18:23:36 sean-k-mooney well for resize we have seperate flavors
18:23:59 ganso sean-k-mooney: I was happy that instances.vcpu was consistent for resizes
18:24:26 sean-k-mooney ganso: i dont know if we have testing that enforces that which is why i was nervous with using it
21:01:01 opendevreview Rodrigo Barbieri proposed openstack/nova master: Fix 1vcpu error with multiqueue and vif_type=tap https://review.opendev.org/c/openstack/nova/+/804303
#openstack-nova - 2021-08-18
06:29:34 ctay Hello, I'd like to ask if anyone of you had to deal with something similiar as me. For the OS cluster we use, we wrote our custom weigher for nova scheduler and we would like to simulate/test how it would effect the placement of new virtual machines in time from the current state of the cluster before we deploy the change...The main objective of this weigher is to reduce the amount of wasted resources.
06:30:13 ctay Is there any framework for this kind of testing? Or anything else? I've checked the testing tools mentioned in the docs, but none of them seems to do the thing.
06:30:27 ctay It would be good if we could determine the impact of the new weighter on the scheduling before we deploy it, so we can be sure it'll actualy waste less resources.
08:07:38 lyarwood https://review.opendev.org/c/openstack/nova/+/804230 - if any cores have time today reviews on this bugfix series and trivial fup's would be appreciated
08:08:51 lyarwood ctay: so rally might be able to help with this and/or our functional test framework could also assert the behaviour for you
08:10:57 lyarwood https://github.com/openstack/nova/blob/370830e9445c9825d1e34e60cca01fdfe88d5d82/nova/tests/functional/test_scheduler.py but it's pretty limited
08:45:40 ctay lyarwood: from the quick look at the functional test framework for scheduler, it just checks whether it does what it should...that doesn't help us, as we'd like to "predict" how the changes in scheduling will affect the distribution of VM's in the cloud from the current state.
08:45:40 gibi ctay: If I were you I would try to build someting top of the existing functional test env as lyarwood suggested. That env allows you to simulate a huge amount of computes and schedule huge amount of VMs on them without having to provide the real hardware for it.
08:46:24 gibi ctay: you can simply build up a many compute many VM scenario in the func test env and see how the scheduler distribute the VMs with and without your weigher
08:48:51 lyarwood ctay: yeah as gibi said, you can assert the behaviour of the weigher in a similar sized env to your own, we don't have anything that could simulate things on an existing env
08:49:09 lyarwood ctay: using our func framework that is
08:54:55 opendevreview Fabian Wiesel proposed openstack/nova master: VMWare: Use WithRetrieval to get all results https://review.opendev.org/c/openstack/nova/+/804968
08:56:02 ctay okay, thanks for the advices ... it seems like building upon the existing func framework is a way to go then
09:19:11 gibi lyarwood: I have a question in https://review.opendev.org/c/openstack/nova/+/804230/3/nova/compute/manager.py#8215
09:23:57 lyarwood gibi: https://review.opendev.org/c/openstack/nova/+/804299/2/nova/tests/functional/compute/test_live_migration.py - ack yeah I added this later in the series after artom asked, it's also covered elsewhere in a regression test iirc
09:25:50 gibi lyarwood: ohh cool
09:26:21 lyarwood https://review.opendev.org/q/topic:bug/1899835 was the regression test but the fix isn't complete yet

Earlier   Later