Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-09-13
17:04:53 gibi but I have to drop now
17:04:59 gibi ping me tomorrow if the comment is not clear
17:05:04 gibi o/
17:05:38 sean-k-mooney afck
17:05:40 sean-k-mooney ack
17:06:11 elodilles sean-k-mooney: if the original fix did not merge into yoga, then how is it causing failing tests? :-o or is that only some part of the fix?
17:07:04 elodilles sean-k-mooney: sorry, it seems i'm a bit lost there o:)
17:07:42 sean-k-mooney we proposed it in yoga but then realised that there is a branch overried
17:07:47 sean-k-mooney so emmas patch is not needed
17:07:58 sean-k-mooney even though the sdk is branched
17:08:08 elodilles sean-k-mooney: oh, i see! as sdk is taken from master branch
17:08:11 sean-k-mooney the sdk jobs always use master sdk on any stable branch
17:08:15 sean-k-mooney yep
17:08:22 sean-k-mooney so that is why a mager change broke stable
17:08:24 elodilles sean-k-mooney: sorry :S now i get it o:)
17:11:58 sean-k-mooney so we might want to drop https://review.opendev.org/c/openstack/openstacksdk/+/857471/1/openstack/block_storage/v3/_proxy.py but https://review.opendev.org/c/openstack/openstacksdk/+/857471/1/openstack/tests/functional/cloud/test_project_cleanup.py is the flaky test that we should revert out
17:12:16 sean-k-mooney ill do that and rebase it to the tip of master
17:14:52 elodilles sean-k-mooney: thanks!
17:20:07 sean-k-mooney https://review.opendev.org/c/openstack/openstacksdk/+/857471
17:20:15 sean-k-mooney ok so that is just removing the test cases now
17:20:45 sean-k-mooney the retry they added is preserved to not regress https://storyboard.openstack.org/#!/story/2010217
17:23:10 elodilles sean-k-mooney: ++
17:30:24 sean-k-mooney bauzas: by the way while im going to attent the ptg i dont plan on addign any topics this time to the adgenda
17:32:38 sean-k-mooney dansmith: by the way does your n-2 greade job still work
17:33:13 sean-k-mooney if so we should likely add that to the check pipline or the perodic pipelien one RC1 is out using yoga as a base
17:33:43 sean-k-mooney so weekly at a minium but we could run it on each patch if we wanted too
17:34:09 sean-k-mooney thats proably a ptg topic i guess
17:34:55 sean-k-mooney i.e. how and what level of testing we wil do in A as part of the dress rehersal for C
17:36:08 sean-k-mooney is it the grenade-skip-level: jobs
17:36:17 sean-k-mooney https://github.com/openstack/nova/blob/master/.zuul.yaml#L705-L706
17:37:38 sean-k-mooney ya it is https://opendev.org/openstack/grenade/src/branch/master/.zuul.yaml#L377
17:38:19 sean-k-mooney so we wil need a variant for tha tthat is based on yoga as the base and master as the target for A
17:38:42 sean-k-mooney its proably best to do that in hte grenade repo
17:42:20 dansmith sean-k-mooney: we won't know until we start running it again, but it's supposed to
17:42:38 dansmith but we shouldn't be running it on zed-rc right? just on master (antelope) right?
17:42:46 dansmith oh, "once rc1 is out" yeah
17:42:47 sean-k-mooney yep
17:42:57 sean-k-mooney so from friday or next week
17:43:03 sean-k-mooney we can trun it back on on master
17:43:08 sean-k-mooney and pin to yoga
17:43:12 sean-k-mooney as teh from branch
17:43:24 sean-k-mooney its currently wallaby
17:43:38 sean-k-mooney for xena
17:43:49 sean-k-mooney sorry for yoga
17:44:10 sean-k-mooney letters are hard hehe
17:44:20 dansmith yeah
18:27:42 opendevreview Merged openstack/python-novaclient master: Update master for stable/zed https://review.opendev.org/c/openstack/python-novaclient/+/856790
#openstack-nova - 2022-09-14
07:38:47 obre Hi all! I wonder if it is possible for me to propse a small change to nova? In short I would like to add a config-option allowing us to specify the value nova-compute reports to placement for VCPU:max_unit. The use-case is to avoid having instances consuming all CPU's of a compute-node (ex: I do not want instances using 24 cores to end up on my hypervisor with 24 cores; Id
07:38:50 obre rather want them on larger hypervisors). Does it make sense?
07:40:13 obre I am able to write the changes needed in nova/virt/libvirt/driver.py and nova/conf/compute.py, I just wonder if this is something that makes sense for me to try push upstream; or if there are obvious blockers I dont see?
07:40:56 gibi obre: I'm wondering. it might be already possible with a provider.yaml file https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html
07:41:16 gibi but if not, then I would enhance that facility to configure max_unit
07:41:21 obre gibi: Only for resources named CUSTOM_*
07:41:28 obre gibi: AFAIK
07:41:50 gibi could be. so I would suggest to extend that for non CUSTOM_ resources too
07:42:21 gibi so if somebody wants to do the max_unit on memory tomorrow then we have a generic solution
07:43:21 obre I think the reason for only allowing CUSTOM is to avoid having conflicts within nova; as nova already reports values for VCPU, MEMORY_MB and DISK_GB in its virt drivers.
07:44:28 obre So I guess that if we extend the provider.yaml to also allow setting these we need to do major work to ensure that it does not create conflicts?
07:45:13 obre Thats why I am basicly thinking that something similar to reserved_host_memory_mb, reserved_host_cpus and reserved_host_disk_mb is tempting for min/max_unit for these values.
07:47:55 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193
07:47:56 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194
07:47:56 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401
07:47:57 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830
07:47:57 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090
07:47:58 opendevreview ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500
07:47:58 opendevreview ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499
07:47:59 opendevreview ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501
07:48:00 opendevreview ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029
07:48:00 opendevreview ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028
07:48:02 opendevreview ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278
07:48:02 opendevreview ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084
07:48:04 opendevreview ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086
07:48:04 opendevreview ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085
07:48:06 opendevreview ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823
07:48:06 opendevreview ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087
07:48:08 opendevreview ribaudr proposed openstack/nova master: Change microversion to 2.94 https://review.opendev.org/c/openstack/nova/+/852088
07:48:08 opendevreview ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824
08:16:16 obre gibi: I am unable to find the real reason to only allow specifying CUSTOM inventories/traits through provider.yaml, but I guess there is a reason for this limitation? And that you not really want me to create a patch simply removing the check that traits/inventories specified in provider.yaml starts with "CUSTOM_"?
08:17:03 gibi obre: good point about the possible conflict.
08:17:24 gibi obre: I think max_unit will not be a conflict as nova never specify that other than 1
08:18:10 gibi obre: as of why we have the limitation today, I think we wanted to avoid thinking through all the possible conflict scenarios when we first introduced the provider.yaml to limit the scope of that first step.
08:19:07 gibi obre: I agree that defining VCPU.total via provider.yaml needs thinking and some agreement what does that mean, which input has higher priority the virt driver or the provider.yaml one
08:19:29 gibi but I don't think you need VCPU.total you only need RC.max_unit to be allowed for your use case
08:20:56 obre Yes; it is basiclu max_unit which is relevant; but the driver sets that to the same value as "total" quite explicitly:
08:22:20 obre https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8797-L8804
08:23:56 obre And since we have the CONF.reserved_host_cpus, it seemed like a similar solution for max_unit (and even min_unit) would make sense, and be consistent with something that already exists.
08:50:08 opendevreview Amit Uniyal proposed openstack/nova master: Adds check if blk_dev_info has correct flavor.swap https://review.opendev.org/c/openstack/nova/+/857339
09:05:21 gibi obre: I'm not saying having a dedicated CONF is not a valid alternative. I think both direction worth thinking.
09:05:43 gibi obre: there are couple of ways to get a bit wider input for the ideas
09:07:09 gibi i) try to put it on the agenda of the next nova meeting https://wiki.openstack.org/wiki/Meetings/Nova 2) try to file a blueprint and a spec describing the alternatives https://specs.openstack.org/openstack/nova-specs/#process 3) raise this as a Project Team Gathering topic in https://etherpad.opendev.org/p/nova-antelope-ptg
09:12:20 auniyal_ O/
09:12:29 opendevreview Eigil Obrestad proposed openstack/nova master: Config parameters for min/max cpu/memory allocation. https://review.opendev.org/c/openstack/nova/+/857595
09:12:30 auniyal_ please review this -https://review.opendev.org/c/openstack/nova/+/852737
09:13:14 auniyal_ https://review.opendev.org/c/openstack/nova/+/857339
09:14:54 obre gibi: I submitted a change to illustrate what I consider to be the simplest solution. Ill have a look at your three alternatives in a little while. First I need to eat and do a little bit of other work.
09:15:23 gibi obre: sure :)
09:25:54 opendevreview Ghanshyam proposed openstack/osc-placement master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/osc-placement/+/856787
09:28:53 opendevreview Ghanshyam proposed openstack/os-vif master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/os-vif/+/856783
09:29:18 opendevreview Ghanshyam proposed openstack/python-novaclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-novaclient/+/856791
10:15:22 obre gibi: To "try to put it on the agenda of the next nova meeting"; is that simply updating the agenda on the wikipage?

Earlier   Later