Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-08-17
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-08-17-16.01.log.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 Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-08-17-16.01.html
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 gibi #endmeeting
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 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: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: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
09:42:29 gibi lyarwood: there is a bugfix that needs a second set of eyes https://review.opendev.org/c/openstack/nova/+/803603
09:42:44 lyarwood ack looking
09:42:49 gibi thanks
09:45:12 gibi and if you are on fire then there is a second one here https://review.opendev.org/q/topic:bug/1939193
09:55:10 gibi lyarwood: as per https://review.opendev.org/c/openstack/nova/+/804275 regarding the 2.88 support in novaclient I think that was landed here https://github.com/openstack/python-novaclient/commit/54d4da112a6e84db5bda497364a49b9debfc2904
09:55:41 gibi lyarwood: the patch that is open in novaclient for 2.88 is acutally for a feature that havent landed yet in nova
09:55:41 lyarwood weird, the tree I was working on only had 2.87
09:55:59 lyarwood ack I did wonder
09:56:07 lyarwood okay let me try to rebase/pull things again
09:56:18 lyarwood and I'll push what I have for 2.89 shortly
09:56:26 gibi OK cool
11:07:48 opendevreview Vadym Markov proposed openstack/nova master: Fix for concurrent DB update issue https://review.opendev.org/c/openstack/nova/+/804985
11:08:04 opendevreview Vadym Markov proposed openstack/nova master: Fix for concurrent DB update issue https://review.opendev.org/c/openstack/nova/+/804985
12:47:56 gibi \o/ alembic integration is on the gate
12:48:35 lyarwood oh is that what the burning smell is
12:48:47 lyarwood stephenfin++
12:48:54 sean-k-mooney :)
12:51:30 opendevreview Rodrigo Barbieri proposed openstack/nova master: Fix 1vcpu error with multiqueue and vif_type=tap https://review.opendev.org/c/openstack/nova/+/804303
12:54:46 opendevreview Merged openstack/nova master: db: Unify 'nova.db.api', 'nova.db.sqlalchemy.api' https://review.opendev.org/c/openstack/nova/+/799524
12:55:01 opendevreview Merged openstack/nova master: db: Exclude the 'use_db_reconnect' option https://review.opendev.org/c/openstack/nova/+/803778
12:55:15 opendevreview Merged openstack/nova master: db: Move remaining 'nova.db.sqlalchemy' modules https://review.opendev.org/c/openstack/nova/+/799525
12:55:28 opendevreview Merged openstack/nova master: db: Post reshuffle cleanup https://review.opendev.org/c/openstack/nova/+/799526
13:01:50 opendevreview Fabian Wiesel proposed openstack/nova master: VMWare: Use get_hardware_devices throughout https://review.opendev.org/c/openstack/nova/+/805017
13:14:40 yonglihe hello, nova
13:18:21 yonglihe gibi, thanks your review, and the first one still be in +1, https://review.opendev.org/c/openstack/nova/+/771362/38
13:18:54 gibi yonglihe: hi! fixed it
13:19:31 yonglihe cool!
13:23:49 mgariepy hello, is there a way to add a quota on pci devices or vgpus with nova?
13:25:37 sean-k-mooney not yet
13:25:45 sean-k-mooney it will be supported with unified limits
13:25:49 sean-k-mooney in the future
13:25:56 mgariepy is there a BP ?
13:26:45 sean-k-mooney https://review.opendev.org/q/topic:%22bp%252Funified-limits-nova%22+(status:open%20OR%20status:merged)
13:27:07 mgariepy awesome :D thanks
13:27:08 sean-k-mooney this is the spec https://review.opendev.org/c/openstack/nova-specs/+/789585 ^ is the full set of patches
13:27:58 lyarwood sean-k-mooney: forgot to say that I have that all open for review at somepoint today or tomorrow btw
13:28:34 mgariepy Target release is X or Z i guess ?
13:28:39 lyarwood sean-k-mooney: apologies for not replying last night, got stuck in traffic on the way back from nursery
13:29:01 sean-k-mooney no worries
13:31:28 opendevreview Lee Yarwood proposed openstack/python-novaclient master: Microversion 2.89 - Add attachment ids to os-volume_attachments GETs https://review.opendev.org/c/openstack/python-novaclient/+/805022
13:47:24 opendevreview Fabian Wiesel proposed openstack/nova master: VmWare: Fix deprecation warning in unit tests https://review.opendev.org/c/openstack/nova/+/805024
14:07:28 opendevreview Merged openstack/nova master: db: Avoid use of ALTER in initial migration https://review.opendev.org/c/openstack/nova/+/800076
14:09:43 opendevreview Takashi Kajinami proposed openstack/nova stable/victoria: Fix request path to query a resource provider by uuid https://review.opendev.org/c/openstack/nova/+/803550
14:10:13 opendevreview Takashi Kajinami proposed openstack/nova stable/ussuri: Fix request path to query a resource provider by uuid https://review.opendev.org/c/openstack/nova/+/805004

Earlier   Later