Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-10-16
18:08:32 gmann dansmith: sean-k-mooney hi
18:08:46 sean-k-mooney o/
18:09:15 gmann bindeps can be installed two way, via flag while installing nova or have file in devstack/file/bindep.txt itself which will be indalled by default
18:09:19 gmann installed
18:09:54 gmann but nova needs to have that in-tree under devstack directory with plugin setup
18:10:13 sean-k-mooney gmann: yep so in this case its a dep for an ansible module we are using in one specific ci job post playbook
18:10:15 gmann I mean here - https://github.com/openstack/nova/tree/master/devstack
18:10:28 sean-k-mooney the dep also happens to be a dep nova has
18:11:01 sean-k-mooney we are assumign that until last week lxml was insallsed transitivly via a weak dep somewhere
18:11:07 sean-k-mooney so the ci playbook worked
18:11:18 sean-k-mooney and that weak dep got lost over the weekend
18:11:43 gmann ohk so we want to have explicit in nova bindep right?
18:12:21 sean-k-mooney well for now we jsut installed it in the job. but then i mentioned bindep to dansmith but that dint work becasue we dont install nova's bindep currently
18:12:35 sean-k-mooney gmann: i was wondering if there was a reason we only do it for specific libs
18:12:48 sean-k-mooney i.e. if we passed the flag for nova would it break things?
18:13:17 dansmith gmann: not sure what changed between last week and today, but this must have been on the system before
18:13:40 dansmith gmann: but yeah, it's really an ansible module requirement, so not sure it should be in nova's bindep to be honest
18:14:20 gmann ohk
18:16:05 gmann not sure if changed in opendev side, I cannot remember/see anything devstack removed on this
18:16:25 sean-k-mooney looking at the commit history i dont see anything obvious on the devstack side
18:16:40 gmann yeah
18:16:44 sean-k-mooney perhaps a chagn ein tempet or shared job config but i think its not realted to the devstack repo
18:17:37 gmann which one?
18:20:05 sean-k-mooney the partent of the job that failed was tempest-multinode-full-py3 so i was wondering if it was in anyway related to https://github.com/openstack/tempest/commit/5c64e3913a1a5a061a6b04b212ce35aaa84f2184
18:20:08 sean-k-mooney but i dont think so
18:20:47 gmann yeah, that is not related
18:21:07 gmann it is just adding stable/2023.2 jobs
18:21:17 sean-k-mooney there is nothing else really that lins up
18:21:28 sean-k-mooney for now we have a solution just isntalling the dep in teh job
18:21:32 sean-k-mooney so we are unblocked
18:21:54 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/898435
18:22:00 sean-k-mooney why it broke is less imporant
18:22:37 gmann someone at door. will be back in 10-15 min
18:22:43 sean-k-mooney am im going to drop in a few mins o/
21:47:33 opendevreview Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439
#openstack-nova - 2023-10-17
02:14:19 opendevreview HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315
05:19:42 opendevreview HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315
05:40:51 opendevreview HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315
08:34:50 opendevreview HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315
08:44:26 opendevreview Pavlo Shchelokovskyy proposed openstack/nova master: Forbid use_cow_images together with flat images_type https://review.opendev.org/c/openstack/nova/+/898229
13:28:52 opendevreview Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439
13:30:10 opendevreview Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439
13:31:05 opendevreview Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439
13:40:38 opendevreview Tobias Urdin proposed openstack/nova master: [WIP] Handle scaling of cputune.shares https://review.opendev.org/c/openstack/nova/+/898326
13:41:22 sean-k-mooney tobias-urdin: thisis not something we can do in nova
13:41:54 sean-k-mooney tobias-urdin: we can discuss it again but we considerd that option and rejected it before
13:42:41 sean-k-mooney tobias-urdin: its not jsut eh cpu_shares that woudl need to be adjusted
14:00:59 opendevreview Tobias Urdin proposed openstack/nova master: [WIP] Handle scaling of cputune.shares https://review.opendev.org/c/openstack/nova/+/898326
14:01:40 tobias-urdin sean-k-mooney: are you thinking about quota:cpu_shares flavor extra spec as well?
14:02:24 sean-k-mooney tobias-urdin: yes
14:02:40 tobias-urdin i don't understand the reasoning for "libvirt broke us let's remove the default completely"
14:02:43 sean-k-mooney so on master (since zed) we nolonger genreate cpu_shares implictly
14:02:52 sean-k-mooney tobias-urdin: it was nto libvirt
14:03:04 sean-k-mooney this was cause by your kernel being compiled with cgroups_v2
14:03:24 sean-k-mooney it was broken by the kernel team changeing the allowed ranges between api versions
14:05:45 sean-k-mooney tobias-urdin: neither nova nor libvirt provided any normalistaion of values menaing the admin is responsible for selecting values that are allowed by there kernel cgroup version
14:09:22 tobias-urdin while that is true and libvirt never normalized the values, i don't agree, libvirt is an abstraction and should've handled it
14:09:50 sean-k-mooney tobias-urdin: we made that argument to the libvirt maintainer and they disagreed
14:12:14 sean-k-mooney tobias-urdin: https://bugs.launchpad.net/nova/+bug/1960840 is related
14:12:33 sean-k-mooney we considerd extneding the flavor validation https://review.opendev.org/c/openstack/nova/+/829064
14:13:00 sean-k-mooney however part of the problem is the range depend on the virtdriver in use and the cgroup version in the libvirt case
14:14:36 sean-k-mooney in that case actully the limit is a tc one rather the cgroup but we considerd deprecting and removing these as a result
14:15:07 sean-k-mooney that simpler to do with the vif quotas since they generally nolonger fucntion
14:15:18 sean-k-mooney and have a neutron replacemnt that does
14:17:24 tobias-urdin as an operator i basically have two options 1) apply patch https://review.opendev.org/c/openstack/nova/+/824048 and just live with the behaviour change and larger instances does not get favored for oversubscription and i have to manually update cpu_shares or backport that patch to yoga to move to zed with live migration or 2) scale the value and
14:17:24 tobias-urdin set correct on all current instances and live migrate them over and make sure new instances also gets a scaled value
14:17:52 tobias-urdin for an operator where touching the code is an issue this might be very messy
14:18:28 tobias-urdin i opted for adding it as a workaround and upon nova-compute startup fix the values, exactly because of the upgrade issue
14:18:39 sean-k-mooney so im not against backporting the disabling of the implict cpu_share request for what its worht
14:18:59 sean-k-mooney tobias-urdin: we have dont this back to wallaby downstream because we considerd it a release blocker for our product
14:19:31 sean-k-mooney tobias-urdin: we dont have any other code that modifes a guest on startup like that and im not sure hta tis a patten we should follow in general
14:21:19 sean-k-mooney tobias-urdin: if we were to backport https://review.opendev.org/c/openstack/nova/+/824048 to yoga would that solve your issue
14:22:41 tobias-urdin it feel like kind of a limbo, if libvirt maintainers indeed informed that this will never change then the only way forward is fix applications or drop it, i'm just surpised we went for drop it for a default value that has been there since years(?)
14:23:33 tobias-urdin personally i would like it backported but i dont know if stable backport policy covers performance impact as well?
14:27:08 opendevreview Amit Uniyal proposed openstack/nova-specs master: WIP: Enforce console session timeout https://review.opendev.org/c/openstack/nova-specs/+/898553
14:29:26 opendevreview Tobias Urdin proposed openstack/nova stable/yoga: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/898554
14:31:41 tobias-urdin i guess ^ and then hope that operators take the proper action to update cpu_shares to default value or live migrate to get rid of it, annoying that nothing with this is optimal
14:33:03 tobias-urdin a shame that libvirt didn't even try by introducing a cputune.cpu_weight, deprecating and scaling the cputune.cpu_shares value if required, like systemd did and took backward compatibility more seriously
14:33:10 tobias-urdin / end of rant :p
14:50:05 bauzas reminder : nova meeting in 1 hour and 10 mins here
15:43:25 opendevreview Takashi Kajinami proposed openstack/nova master: Fix python shebang https://review.opendev.org/c/openstack/nova/+/898594
15:46:59 opendevreview Merged openstack/nova stable/wallaby: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843939
16:01:18 bauzas #startmeeting nova
16:01:18 opendevmeet Meeting started Tue Oct 17 16:01:18 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:18 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:18 opendevmeet The meeting name has been set to 'nova'
16:01:21 bauzas hey folsk
16:01:24 dansmith o/
16:01:27 elodilles o/
16:01:30 bauzas #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:02:38 auniyal 0/\
16:02:52 auniyal o/
16:02:57 bauzas okay, let's start
16:03:02 bauzas #topic Bugs (stuck/critical)
16:03:04 bauzas #info No Critical bug
16:03:09 bauzas #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 47 new untriaged bugs (+1 since the last meeting)
16:03:15 bauzas #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:34 Uggla o/
16:03:38 bauzas artom: you're next in the roster list, fancy trying to look at some upstream bugs ?
16:04:33 bauzas artom seems to be offline, let's move on and we'll see

Earlier   Later