Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-09-10
16:57:54 gibi bauzas: thanks
16:58:06 elodilles thanks o/
17:05:15 opendevreview Merged openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928355
17:08:04 opendevreview Dmitriy Rabotyagov proposed openstack/nova master: Respect supplied arguments in novncproxy_base_url https://review.opendev.org/c/openstack/nova/+/928839
17:08:33 noonedeadpunk sean-k-mooney: this is what we were discussing yesterday ^
17:10:06 sean-k-mooney ya so either parsing it like that or a sperate config option just for the extra query args
17:10:23 sean-k-mooney that does not look unreasonabel to me at a glance
17:11:00 sean-k-mooney although im not a fan of puting each arg on its own line like this https://review.opendev.org/c/openstack/nova/+/928839/1/nova/tests/unit/objects/test_console_auth_token.py#103
17:11:19 sean-k-mooney that proably a trivial specless bluepirnt
17:11:39 sean-k-mooney so we will need to put it on the adgenda for next week
17:11:42 sean-k-mooney bauzas: ^
17:12:21 sean-k-mooney anyway for a 30 second review i think its ok over all but ill need to loop back to that properly later
17:14:57 sean-k-mooney noonedeadpunk: would you mind filing a specless bluepint and updating the commit message with implements: blueprint <name>
17:15:08 sean-k-mooney and queing that up for next week adjenda
17:19:08 noonedeadpunk regarding tests - I was pretty much following the pattern from `_test_authorize`
17:19:47 sean-k-mooney ya we are kind of inconsitentent
17:19:52 noonedeadpunk ah, sorry
17:20:00 noonedeadpunk I thought about different line
17:20:21 noonedeadpunk all args in one line were exceeding the 80l
17:20:38 sean-k-mooney yep so we normally put them all on the next line
17:20:53 sean-k-mooney that allow you to reclaim all the indent space
17:21:02 noonedeadpunk ++
17:21:41 sean-k-mooney so like this https://peps.python.org/pep-0008/#indentation
17:22:51 sean-k-mooney so "Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest."
17:23:09 noonedeadpunk yeah, I got it :)
17:23:20 sean-k-mooney to be fair i want to just automate this
17:23:30 sean-k-mooney but we have never got agreement on how
17:23:53 sean-k-mooney but im very tempeted to review my black serise with line lenght 79
17:24:09 sean-k-mooney i dont like black but i disliek discussion formatign with humans more :)
17:24:26 sean-k-mooney let the bots/tools fight that out instead
17:25:06 whoami-rajat sorry everyone, i wasn't around for the meeting, but would like to address a few of the concerns
17:25:11 whoami-rajat bauzas, it's a challenge to figure out where we want to log it, customer deployments don't enable DEBUG by default and there are multiple failure scenarios where we would need to log this in case of an exception
17:25:11 whoami-rajat bauzas, also I'm not sure why it is not reliable? the multipath_id or WWID is the ID assigned to the volume (LUN) so it is persistent throughout the life of the volume across multiple attach/detach cycles
17:25:11 whoami-rajat dansmith, So for fibre channel connections, we already store the multipath_id in the connection_info field, my patch is just adding it for iSCSI connections, not sure if it still counts as a DB change, more of filling a missing value for one type of attachments (iSCSI)
17:25:12 whoami-rajat Also I've found this value being used in the LUKS encryptor, https://github.com/openstack/os-brick/blob/master/os_brick/encryptors/luks.py#L89-L98
17:25:35 sean-k-mooney whoami-rajat: they do not for 18 but historically yoru correct
17:25:40 sean-k-mooney *the do now
17:26:02 noonedeadpunk sean-k-mooney: about specless blueprint - so it's just a record on launchpad with description?
17:26:13 sean-k-mooney noonedeadpunk: yep exactly
17:26:16 dansmith whoami-rajat: another field in a json blob is not what I mean by "a db change"
17:26:29 sean-k-mooney noonedeadpunk: like this https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated
17:26:50 whoami-rajat sean-k-mooney, yep, but you know how long it will take for all the customers to move from 16.2 and 17.1 to 18 when there are customers still using 13 :D
17:26:59 noonedeadpunk ++
17:27:26 sean-k-mooney whoami-rajat: right but we are not going to backport this so is that relevent :)
17:28:15 sean-k-mooney whoami-rajat: i was not aware this was already there for fiber channel
17:28:36 sean-k-mooney but there its presumable also used for nova in the xml generation or similar
17:28:39 dansmith also discussion of any default configurations of OSP versions has no bearing on what we're going to do upstream :)
17:29:38 whoami-rajat +1, that's why i found it's usage in the os-brick encryptors where the field is relevant irrespective of the debugging use case
17:30:19 whoami-rajat sean-k-mooney, if it's not supposed to be backported then i am less motivated to pursue this
17:31:06 sean-k-mooney upstream it would not qualify i dont think and im not sure it woudl dowstream but for diffent reasons
17:31:39 sean-k-mooney its not addressing a bug so unless this is an operator painpoint today it would be out of scope fo stable backports
17:33:53 sean-k-mooney whoami-rajat: i dont think anyone really object ot adding a debug or maybe even info level log for this
17:34:02 sean-k-mooney woudl that be useful for you
17:34:48 sean-k-mooney there is nothign actionalable here so warning and error woudl not be approate but info woudl likely be ok
17:36:24 whoami-rajat sean-k-mooney, yeah, given the current discussion, i feel that would be a better path to pursue, thanks
17:36:31 whoami-rajat honestly i thought it would be a trivial change to get in and backported since currently the BDMs for FC and iSCSI are just inconsistent
17:36:47 whoami-rajat but looks like the efforts will outweigh the usefulness of the change
17:37:05 whoami-rajat so I'm good with a DEBUG or INFO level logging message
17:37:40 sean-k-mooney the normalisation level argument can be made, im just not sure if that is commpeling enough but its worth considering at least
17:38:04 sean-k-mooney s/level//
17:39:00 sean-k-mooney dansmith: gibi ^ is that more appealign to ye? just a new info level log?
17:39:16 opendevreview Dmitriy Rabotyagov proposed openstack/nova master: Respect supplied arguments in novncproxy_base_url https://review.opendev.org/c/openstack/nova/+/928839
17:40:24 whoami-rajat gibi, basically sean-k-mooney is proposing to add a INFO level log message to print the multipath_id and volume_id for the correlation, if that's OK for the nova team
17:41:16 noonedeadpunk do you have some specific topic during the meeting for blueprint discussion? or just open discussion?
17:41:28 sean-k-mooney noonedeadpunk: just open discussion
17:42:28 gibi whoami-rajat, sean-k-mooney: yeah adding info level logs sounds good to me
17:43:38 noonedeadpunk awesome, thanks!
17:46:10 whoami-rajat thanks gibi and sean-k-mooney , i will pursue that path then
18:27:35 opendevreview Merged openstack/nova master: Update compute rpc alias for dalmatian https://review.opendev.org/c/openstack/nova/+/928661
18:36:02 opendevreview sean mooney proposed openstack/nova master: Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310
18:36:02 opendevreview sean mooney proposed openstack/nova master: only saftey check bootable files created form glance https://review.opendev.org/c/openstack/nova/+/928829
18:36:03 opendevreview sean mooney proposed openstack/nova master: adapt to vfat support in oslo.utils https://review.opendev.org/c/openstack/nova/+/928462
18:38:20 sean-k-mooney bauzas: dansmith i think https://review.opendev.org/q/topic:%22bug/2079850%22 should work. its passing unit/functional tests at least
18:38:37 sean-k-mooney but i have not had time to test it in devstack so we will see what the ci thinks
19:04:36 opendevreview sean mooney proposed openstack/nova master: Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310
19:06:33 sean-k-mooney ill respin thoes in the morning if anything fails. im debating if i should add a release note to the second patch but since we have not released yet i dont htink its needed
19:06:53 sean-k-mooney if other disagree i can add it tomorrow
19:14:01 opendevreview Merged openstack/placement master: Update 2024.2 reqs to support os-traits 3.1.0 as min version https://review.opendev.org/c/openstack/placement/+/928663
#openstack-nova - 2024-09-11
00:54:01 opendevreview sean mooney proposed openstack/nova master: Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310
00:54:51 opendevreview sean mooney proposed openstack/nova master: only saftey check bootable files created form glance https://review.opendev.org/c/openstack/nova/+/928829
00:55:06 opendevreview sean mooney proposed openstack/nova master: adapt to vfat support in oslo.utils https://review.opendev.org/c/openstack/nova/+/928462
01:27:55 opendevreview sean mooney proposed openstack/nova master: only saftey check bootable files created form glance https://review.opendev.org/c/openstack/nova/+/928829
01:27:55 opendevreview sean mooney proposed openstack/nova master: adapt to vfat support in oslo.utils https://review.opendev.org/c/openstack/nova/+/928462
07:58:57 sahid o/
07:59:18 sahid quick question guys, when we have a host ins maintenance, is there a way tp schedule VM on it?
07:59:22 sahid I mean as admin
07:59:35 sahid that to valid the behavior of the host
08:34:00 tobias-urdin we usually create a instance then live migrate it to the host to test it out without enabling it for scheduling
10:03:32 sahid tobias-urdin: interesting workaround thank you
10:03:46 sahid btw it may be useful for an admin to have this priviledge
10:06:01 tis_at_teuto Hi, not shure if this is the right place to ask but currently we have a problem mit oom-kill pcpu-instances. They got oom-killed with `oom-kill:constraint=CONSTRAINT_MEMORY_POLICY`. We use pinned cpus and nova-compute sets the the libvirt numatune.memory and numatune.memnode statically to `mode=strict` https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2812 . Is it possible to get this configurable or
10:06:04 tis_at_teuto use preferred instead like mentioned in https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/virtualization_tuning_and_optimization_guide/sect-virtualization_tuning_optimization_guide-numa-allocation_policy#sect-Virtualization_Tuning_Optimization_Guide-NUMA-Allocation_Policy
11:40:04 opendevreview Merged openstack/osc-placement stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/osc-placement/+/928358
11:45:13 sean-k-mooney tobias-urdin: sahid if you have disabeld the compute you cannot live migrate to it by defualt. to do so you have to use the old microversin and force the migration
11:45:27 sean-k-mooney sahid: we intentionally do now allow this to work by defualt
11:45:48 sean-k-mooney when a comptue service is disabeld you shuld be able to move instance away form it but not to it
11:46:09 opendevreview Merged openstack/osc-placement stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/osc-placement/+/928359
11:46:40 sean-k-mooney tis_at_teuto: my initall gues is that you have not defied hw:mem_page_size in your pinned instance
11:47:16 sean-k-mooney tis_at_teuto: when using cpu pinnign either you need to request numa aware memory usign hw:mem_page_size or you need to configure the host for file backed memroy
11:47:48 sean-k-mooney if you dont do one of those two then we expect OOM issue for the vms, its an unsupproted configuraiton.

Earlier   Later