Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-02-23
14:19:06 bauzas po_ceph:1001 : sudo apt-key add - 2023-02-23 11:44:24.549476 | controller | Warning: apt-key output should not be parsed (stdout is not a terminal) 2023-02-23 13:13:45.871360 | controller | gpg: no valid OpenPGP data found.
14:19:13 bauzas https://a2777df7406b272e83f9-872af65051a6414dfad04293989b5338.ssl.cf5.rackcdn.com/874515/3/check/nova-ceph-multistore/ba535b5/job-output.txt
14:33:35 dansmith bauzas: surely that's transient
14:33:52 dansmith bauzas: the volume failure mitigation landed over (my) night btw
14:33:56 dansmith hoping that makes a difference today
14:34:33 bauzas dansmith: ah, cross-posted on qa
14:34:50 bauzas dansmith: look at the paste https://paste.opendev.org/show/bTAGi73UfzlvMRU5RxIj/
14:35:00 bauzas we still get those today
14:35:22 bauzas but this looks a transient network issue
14:35:35 bauzas just the ceph website is flakey
15:33:33 opendevreview Sylvain Bauza proposed openstack/nova master: Update min service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932
15:33:54 bauzas gibi: dansmith: a bit of antelope rc1 scrubbing needs
15:33:57 bauzas ^
15:34:18 bauzas dansmith: please look at the change and tell me if I'm wrong, but I don't think so
15:35:09 dansmith bauzas: yeah I think that makes sense
15:35:49 bauzas we had a lot of back-and-forth last cycle with https://review.opendev.org/c/openstack/nova/+/856895
15:36:01 bauzas but I think we're now sold on the pattern
15:37:00 dansmith yeah, download.ceph.com no worky
15:37:15 bauzas yep-ish
17:42:13 bauzas folks, tomorrow is a company-wide PTO day, see you on Monday exceptionnally
17:55:26 opendevreview Merged openstack/placement master: Update 2023.1 reqs to support os-traits 2.10 as min version https://review.opendev.org/c/openstack/placement/+/874080
17:58:10 dansmith bauzas: that mysql memory patch passed the ceph job
17:58:23 dansmith (and all the other ones so finished) so hopefully we'll see that in the gate soon
17:58:32 bauzas all cool !
17:58:44 dansmith I also haven't seen any of those specific volume failures since that patched merged so... fingers crossed
18:11:17 dansmith nope, failed nova-next
18:11:53 dansmith volume shelve test failed
18:15:43 opendevreview Merged openstack/nova stable/ussuri: [stable-only][cve] Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871702
18:50:49 dansmith so that shelve failure was a timeout to get a response from conductor while the compute was trying to save an instance object
19:25:42 opendevreview melanie witt proposed openstack/nova master: doc: Add details about the behavior of server delete https://review.opendev.org/c/openstack/nova/+/874188
#openstack-nova - 2023-02-24
04:19:11 opendevreview Merged openstack/nova master: Use mysql memory reduction flags for ceph job https://review.opendev.org/c/openstack/nova/+/874664
09:19:07 opendevreview Christian Rohmann proposed openstack/placement master: Db: Drop redundant indexes for columns already having unique constraint https://review.opendev.org/c/openstack/placement/+/856770
12:08:35 admin1 hi all .. i have a server that migated from hostA -> hostB and the host is running happily on hostB .. but horizon/nova db did not udpate and it shows server is in hostA.. so cannot do anything from console/horizon ..
12:08:48 admin1 how to update records or have nova correct this error
12:09:37 admin1 nova migration-list shows the migration confirmed normally .. and virsh dumxml uuid all shows the migration went in fine
12:09:50 admin1 there is nothing running in hostA of that uuid
12:26:48 opendevreview Justas Poderys proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377
14:11:39 opendevreview aarefiev proposed openstack/nova master: Doc: update live-migration cmd https://review.opendev.org/c/openstack/nova/+/875043
15:08:59 opendevreview OpenStack Release Bot proposed openstack/os-vif stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875095
15:09:00 opendevreview OpenStack Release Bot proposed openstack/os-vif stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875096
15:09:01 opendevreview OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875097
15:09:08 opendevreview OpenStack Release Bot proposed openstack/osc-placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875098
15:09:09 opendevreview OpenStack Release Bot proposed openstack/osc-placement stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875099
15:09:11 opendevreview OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875100
15:09:22 opendevreview OpenStack Release Bot proposed openstack/python-novaclient stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875101
15:09:23 opendevreview OpenStack Release Bot proposed openstack/python-novaclient stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875102
15:09:25 opendevreview OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875103
15:26:15 opendevreview Takashi Natsume proposed openstack/placement master: Fix a wrong assertion method https://review.opendev.org/c/openstack/placement/+/861489
15:52:39 opendevreview Merged openstack/python-novaclient master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875103
18:38:35 gmann bauzas: sorry I am little late for nova release highlights , should we mention about RBAC new defaults/scope are enabled by default now? This is important for operators to know.
#openstack-nova - 2023-02-25
10:56:46 sean-k-mooney gmann: perhaps it would be better to do that in one place for all project that completed that phase
10:57:10 sean-k-mooney as an overall openstack feature highlight rahter then just for nova
10:57:42 sean-k-mooney there will be a callout for that anyway in teh features/upgrade section form the release note for the feature tooo
10:58:19 sean-k-mooney the other thing that woudl be good to call out at the opesntack level is declaring 2023.1 as the first SLU release
10:59:13 sean-k-mooney so that they know that we plan to supprot upgradign directly to 2024.1 skipping 2023.2
#openstack-nova - 2023-02-27
08:20:08 bauzas good morning Nova
09:52:39 tobias-urdin good morning o/
09:53:28 tobias-urdin let's say I have hyperthreding enabled, is there any logic to schedule an dedicated pCPU instance to use one core and it's thread sibbling? to ensure no two instances are running on the same thread sibbling and shares that
09:53:57 tobias-urdin i can only find that we can select cpu thread policy but not to isolate actual usage of thread sibblings
09:55:02 sean-k-mooney tobias-urdin: only if you are not usign cpu in placement
09:55:10 opendevreview Ilya Popov proposed openstack/nova stable/xena: compute: Update volume_id within connection_info during swap_volume https://review.opendev.org/c/openstack/nova/+/874921
09:55:11 opendevreview Ilya Popov proposed openstack/nova stable/xena: Add regression test for bug #1943431 https://review.opendev.org/c/openstack/nova/+/875374
09:55:15 sean-k-mooney we deprecated that functionality a few release ago
09:55:24 sean-k-mooney ~train ish
09:56:05 sean-k-mooney well actully it depend on what you want
09:56:21 sean-k-mooney if you use thread policy require then we require hyperthread siblings to be used
09:56:52 sean-k-mooney i.e a 4 core vm will use 2 phsyical cores and use both hyperthread form each core to provided the 4 pinned cpus
09:57:00 sean-k-mooney that still works today even with placmeent
09:57:08 sean-k-mooney the isolate poicy is what chagned.
09:57:54 sean-k-mooney without pcpu in placementit made each flavor.vcpu be pinnded to a speerate core (and if it had hyperthreadig it reserved the hyperthread so nothing could use it.)
09:58:09 sean-k-mooney with pcpus in placement isolate means find cores without hyperthread
09:58:15 tobias-urdin sean-k-mooney: hm, so if thread policy=required and using even numbers (4 cores, 8 cores) etc we always assume that thread sibblings for those 2 or 4 cores are assigned to only one instance?
09:58:38 tobias-urdin and that would be honored for live migration as well if we set vcpu_pin_set to same on all nodes?
09:58:40 sean-k-mooney tobias-urdin: yes i belive so
09:59:06 sean-k-mooney well it does not have to be the same
09:59:20 sean-k-mooney we update the pinning on migration as of train
09:59:35 tobias-urdin ah
09:59:43 sean-k-mooney so they can be slightly differnt vcpu_pin_sets
10:00:10 sean-k-mooney just make sure you include both hypertherad siblings in vcpu_pin_set or cpu_dedicated_set
10:00:52 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/numa-aware-live-migration.html
10:01:03 sean-k-mooney ^ that fixed live migration
10:01:11 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/cpu-resources.html
10:01:25 sean-k-mooney and that explains how placement aware cpu pinning works if you use it
10:03:05 tobias-urdin ack, I think you answered my question but will read above! thanks, wanted to make sure that we could safetly have ht enabled if using dedicated
10:03:26 sean-k-mooney tobias-urdin: the old way of doign cpu pinning with vcpu_pin_set has been deprecated for a couple of years now. we will likely delete it in 2023.2 or 2024.1
10:03:42 sean-k-mooney you want to prevent inter tenant side channel attacks
10:04:06 sean-k-mooney if so then yes use required/isolate in all flavors to ensure to vms form different tenants dont overlap
10:04:12 tobias-urdin so i will set cpu_policy=dedicated cpu_thread_policy=required on flavor and make sure cpu_dedicated_set is set and including sibblings
10:04:38 opendevreview Merged openstack/os-vif master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875097
10:04:39 tobias-urdin make sure flavors use even amount of cores, so it gets distributed between core and thread (4 = 2 core, 2 thread, 8 = 4 core, 4 thread etc)
10:04:46 tobias-urdin that sounds reasonable?
10:05:09 sean-k-mooney more or less but read the upgrade section fo the cpu tracking in placemnt doc carefully
10:05:48 tobias-urdin we're on xena moving to yoga in a couple of weeks btw if that makes any difference
10:06:09 sean-k-mooney by the way i generally recommend seting hw:cpu_sockets=<the number of numa nodes> and hw:cpu_thread=2
10:06:57 sean-k-mooney not really just that we planned to delete the old pinning code around wallaby but stephenfin moved team and we just didnt get around to it
10:07:36 sean-k-mooney the upgrade impact is the same regardless of when you actuly do the upgrade form old pining to placment aware pinning
10:08:33 sean-k-mooney with the slight simplifciation that at least you know all your nodes already have support for it in code
10:14:02 tobias-urdin sean-k-mooney: not sure i follow about what is legacy and not
10:14:56 tobias-urdin it should be tracked in placement already but do you we mean we should probably disable the fallback path for pcpu?
10:15:28 tobias-urdin or do you mean you want to get rid of the hw: aliases and use PCPU etc resource directly in flavor properties to affect placement?

Earlier   Later