Thursday, 2020-06-18

*** hamalq_ has quit IRC00:06
*** mlavalle has quit IRC00:23
*** hamalq has joined #openstack-nova00:28
*** dlbewley has quit IRC00:30
*** dlbewley has joined #openstack-nova00:31
*** hamalq_ has joined #openstack-nova00:42
*** hamalq has quit IRC00:46
*** dlbewley has quit IRC01:00
*** xiaolin has joined #openstack-nova01:01
*** dlbewley has joined #openstack-nova01:01
*** brinzhang has joined #openstack-nova01:02
*** xiaolin has quit IRC01:14
*** Liang__ has joined #openstack-nova01:21
*** Liang__ is now known as LiangFang01:21
*** hamalq_ has quit IRC01:36
*** hamalq has joined #openstack-nova01:47
*** brinzhang_ has joined #openstack-nova01:59
*** markmcclain has quit IRC02:01
*** brinzhang has quit IRC02:02
*** markmcclain has joined #openstack-nova02:02
*** dlbewley has quit IRC02:02
*** dlbewley has joined #openstack-nova02:03
*** tinwood has quit IRC02:08
*** tinwood has joined #openstack-nova02:10
*** spatel has joined #openstack-nova02:20
*** lbragstad has quit IRC02:21
*** brinzhang0 has joined #openstack-nova02:26
*** brinzhang_ has quit IRC02:29
*** boxiang_ has joined #openstack-nova02:30
*** boxiang has quit IRC02:33
*** xinranwang_ has joined #openstack-nova02:43
*** brinzhang_ has joined #openstack-nova02:47
*** rcernin has quit IRC02:48
*** brinzhang0 has quit IRC02:50
*** hamalq has quit IRC02:50
*** hoonetorg has quit IRC02:51
*** spatel has quit IRC02:55
*** hamalq has joined #openstack-nova02:57
*** rcernin has joined #openstack-nova02:59
*** hamalq has quit IRC02:59
*** hamalq has joined #openstack-nova02:59
*** brinzhang_ is now known as brinzhang03:01
*** rcernin has quit IRC03:05
*** spatel has joined #openstack-nova03:16
*** mkrai has joined #openstack-nova03:17
*** rcernin has joined #openstack-nova03:20
*** rcernin has quit IRC03:22
*** rcernin has joined #openstack-nova03:22
*** hamalq has quit IRC03:29
*** ravsingh has joined #openstack-nova03:30
openstackgerritJinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec  https://review.opendev.org/73642203:37
*** psachin has joined #openstack-nova03:37
*** hamalq has joined #openstack-nova03:52
openstackgerritJinsheng Zhang proposed openstack/nova-specs master:  fix "Line limited" error  https://review.opendev.org/73642504:05
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-nova04:33
*** hoonetorg has joined #openstack-nova04:35
*** hamalq has quit IRC04:40
*** hamalq has joined #openstack-nova04:45
*** hamalq has quit IRC04:50
*** hamalq has joined #openstack-nova04:52
*** spatel has quit IRC04:53
*** hamalq has quit IRC04:57
openstackgerritJinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec  https://review.opendev.org/73642205:07
*** ratailor has joined #openstack-nova05:07
*** ociuhandu has joined #openstack-nova05:21
*** ociuhandu has quit IRC05:26
*** udesale has joined #openstack-nova05:42
openstackgerritJinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec fix document error  https://review.opendev.org/73642205:43
*** hamalq has joined #openstack-nova05:44
*** links has joined #openstack-nova05:46
*** alex_xu has joined #openstack-nova05:47
*** jsuchome has joined #openstack-nova05:50
*** hamalq has quit IRC05:50
*** markvoelker has joined #openstack-nova05:51
*** markvoelker has quit IRC05:55
*** mkrai has quit IRC05:59
*** mkrai has joined #openstack-nova06:04
*** links has quit IRC06:07
*** links has joined #openstack-nova06:12
*** dlbewley has quit IRC06:16
*** dlbewley has joined #openstack-nova06:16
*** rchurch has quit IRC06:19
*** rchurch has joined #openstack-nova06:21
*** maciejjozefczyk has joined #openstack-nova06:22
*** dlbewley has quit IRC06:26
*** dlbewley has joined #openstack-nova06:27
*** links has quit IRC06:32
*** rpittau|afk is now known as rpittau06:43
*** dklyle has quit IRC06:44
*** xek has joined #openstack-nova07:00
*** links has joined #openstack-nova07:01
*** ttsiouts has joined #openstack-nova07:06
*** slaweq has joined #openstack-nova07:07
*** breizhkoala has joined #openstack-nova07:11
*** tesseract has joined #openstack-nova07:14
*** hamalq has joined #openstack-nova07:15
*** ttsiouts has quit IRC07:19
*** ttsiouts has joined #openstack-nova07:19
*** maciejjozefczyk has quit IRC07:19
*** ralonsoh has joined #openstack-nova07:21
*** tosky has joined #openstack-nova07:25
*** elod has quit IRC07:26
*** hamalq has quit IRC07:26
*** LiangFang has quit IRC07:31
*** mkrai has quit IRC07:32
*** elod has joined #openstack-nova07:33
*** Liang__ has joined #openstack-nova07:34
*** maciejjozefczyk has joined #openstack-nova07:37
*** hamalq has joined #openstack-nova07:42
*** Liang__ has quit IRC07:44
*** Liang__ has joined #openstack-nova07:46
*** hamalq has quit IRC07:47
gibisean-k-mooney, melwitt: re: resize without changing the flavor, the context on the PTG was that changing a resource request of a port might also needs a move operation without changing the flavor07:50
*** dlbewley has quit IRC07:50
*** dlbewley has joined #openstack-nova07:51
gibisean-k-mooney, melwitt: I'll try to propose a spec for discussion during this cycle so your input about machine_type change and video mode change being similar use case helps.07:51
gibisean-k-mooney, melwitt: however I think this spec will be targeted to W not V due to time constraints and discussion needs07:52
*** rcernin has quit IRC07:54
*** rcernin_ has joined #openstack-nova07:54
*** ttsiouts has quit IRC07:54
*** ttsiouts has joined #openstack-nova07:58
*** links has quit IRC08:00
*** dlbewley has quit IRC08:00
sean-k-mooneygibi: ah yes i could not recall what it was in relation too08:00
*** dlbewley has joined #openstack-nova08:01
sean-k-mooneygibi: i think there are other usecases too such as recreatign the vm with the same image and flavor but just updating the embeded copy to pick up change to extra_specs and image metadata without actually imaging the disk08:01
*** songwenping_ has joined #openstack-nova08:02
*** songwenping__ has joined #openstack-nova08:03
gibibut still cold migrating the VM if the current host is not good for the updted extra_spec / image metadata?08:03
sean-k-mooneygibi: yes08:03
sean-k-mooneyi would guess in generall it would be a move opertation08:03
gibiOK, that seems like the same operation that I would need for the qos update08:03
sean-k-mooneyit might be vaild to use the same host but likely the schduler would not select the same host08:04
sean-k-mooneyit might but basically the same as same host resize08:04
sean-k-mooneyi guess we could always add a weigher to make it prefer the same host08:05
sean-k-mooneybut thats not really important08:05
*** martinkennelly has joined #openstack-nova08:05
*** songwenping_ has quit IRC08:06
*** hamalq has joined #openstack-nova08:08
gibiyeah, I can imagine that the end user needs an to update these data if it does not cause downtime (cold migration) of the VM08:08
gibi* needs an option to update08:09
gibibut same host resize is still downtime today08:09
sean-k-mooneygibi: currently you need to do a db edit and a hard reboot08:09
*** links has joined #openstack-nova08:10
sean-k-mooneythe downstream issue that melwitt was looking at is related to the fact that in rhel 8.2 the default we use in nova "cirrus" was deprecated08:10
sean-k-mooneyhttps://bugzilla.redhat.com/show_bug.cgi?id=165199408:10
openstacksean-k-mooney: Error: Error getting bugzilla.redhat.com bug #1651994: NotPermitted08:10
sean-k-mooneyoh thats private well that is what it was tracking08:11
sean-k-mooneyanyway 16.0 which is based on train was released on 8.1 16.1 will be on 8.208:11
sean-k-mooneyso customer are now in the situation where the default model that nova will select is deprecaed and there is no way via the api to change this on existing instance other than rebuild08:12
*** ttsiouts has quit IRC08:12
*** hamalq has quit IRC08:12
sean-k-mooneywe wont be able to back port this new command or whatever it will be but it might help in the future08:13
*** ttsiouts has joined #openstack-nova08:13
*** ttsiouts_ has joined #openstack-nova08:16
*** ttsiouts has quit IRC08:17
*** udesale_ has joined #openstack-nova08:19
*** elod has quit IRC08:19
*** ravsingh has quit IRC08:20
*** rcernin_ has quit IRC08:20
*** udesale has quit IRC08:21
*** elod has joined #openstack-nova08:26
*** dtantsur|afk is now known as dtantsur08:29
*** ravsingh has joined #openstack-nova08:33
*** ttsiouts has joined #openstack-nova08:36
*** ttsiout__ has joined #openstack-nova08:37
openstackgerritWenping Song proposed openstack/nova master: delete sub resource provider when delete resource provider  https://review.opendev.org/71916308:39
*** ttsiouts_ has quit IRC08:40
*** ttsiouts has quit IRC08:41
*** ociuhandu has joined #openstack-nova08:42
*** salmankhan has joined #openstack-nova08:46
*** elod has quit IRC09:00
*** jawad_axd has joined #openstack-nova09:09
*** ccamacho has quit IRC09:16
*** vishalmanchanda has joined #openstack-nova09:17
*** elod has joined #openstack-nova09:17
*** elod has quit IRC09:19
*** yaawang_ has quit IRC09:24
*** elod has joined #openstack-nova09:25
*** links has quit IRC09:27
*** links has joined #openstack-nova09:28
*** mkrai has joined #openstack-nova09:28
*** dlbewley has quit IRC09:30
*** dlbewley has joined #openstack-nova09:31
*** martinkennelly has quit IRC09:31
*** martinkennelly has joined #openstack-nova09:32
*** ttsiouts has joined #openstack-nova09:32
*** ttsiout__ has quit IRC09:32
*** martinkennelly has quit IRC09:35
*** martinkennelly has joined #openstack-nova09:36
*** martinkennelly has quit IRC09:38
*** martinkennelly has joined #openstack-nova09:39
*** martinkennelly has quit IRC09:41
*** yaawang_ has joined #openstack-nova09:41
*** martinkennelly has joined #openstack-nova09:43
*** martinkennelly has quit IRC09:49
*** avolkov has joined #openstack-nova09:51
*** ociuhandu has quit IRC09:52
openstackgerritWenping Song proposed openstack/nova master: delete sub resource provider when delete resource provider  https://review.opendev.org/71916309:54
*** ociuhandu has joined #openstack-nova09:59
*** tkajinam has quit IRC10:05
*** dlbewley has quit IRC10:05
*** rpittau is now known as rpittau|bbl10:06
*** dlbewley has joined #openstack-nova10:06
*** Liang__ has quit IRC10:18
*** ravsingh has quit IRC10:32
*** xek has quit IRC10:34
*** xek has joined #openstack-nova10:34
*** dlbewley has quit IRC10:35
*** dlbewley has joined #openstack-nova10:35
arne_wiebalckTheJulia: dansmith sean-k-mooney Sorry, I missed the discussion yesterday.10:38
arne_wiebalckLet me add a little background info: physical instances at CERN are all done via Nova and Ironic. The main user is OpenStack itself and we rely on Ironic's software RAID and standard cloud images10:38
arne_wiebalckto deploy. However, other users (like the Ceph team) want to partition/RAID their physical instances in a specific way as needed for their service. There is no convenient way to express this is via Nova/Ironic at the moment. So, they reinstall these instances after initial deployment through Nova/Ironic once more with kickstart. This double installation is what we'd like to get rid of, and this triggered10:38
arne_wiebalckthe whole discussion.10:38
arne_wiebalckOne of the main points for user adoption probably is that whenever sth needs to change, this should be feasible without having the Ironic admin to re-clean nodes or the Nova admin to add new flavors (with 5000 nodes in Ironic we have around 150 resource classes and hence 150 flavors). This is why we came up with the idea of a "kickstart" driver where Ironic uses a kickstart/preseed file to do the10:38
arne_wiebalckdeployment (and skip the usual image deployment) as it would provide the user with the same flexibility as there is now. But since we would like to keep Nova in the mix (for various reasons), we may need some tooling help on the Nova side.10:38
*** ratailor has quit IRC10:40
*** ratailor has joined #openstack-nova10:40
*** dlbewley has quit IRC10:45
*** dlbewley has joined #openstack-nova10:45
*** rcernin_ has joined #openstack-nova10:48
*** lvdombrkr has joined #openstack-nova11:07
*** udesale_ has quit IRC11:12
*** ccamacho has joined #openstack-nova11:22
*** markvoelker has joined #openstack-nova11:24
*** lvdombrkr has quit IRC11:25
*** dlbewley has quit IRC11:26
*** dlbewley has joined #openstack-nova11:27
*** derekh has joined #openstack-nova11:27
*** markvoelker has quit IRC11:29
*** lvdombrkr has joined #openstack-nova11:29
*** belmoreira has joined #openstack-nova11:33
*** mkrai has quit IRC11:33
*** xiaolin has joined #openstack-nova11:33
*** hamalq has joined #openstack-nova11:39
*** mgariepy has quit IRC11:43
*** hamalq has quit IRC11:45
*** nweinber has joined #openstack-nova11:48
*** ociuhandu has quit IRC11:50
*** raildo has joined #openstack-nova11:50
*** ttsiouts has quit IRC12:06
*** ttsiouts has joined #openstack-nova12:07
*** ttsiouts has quit IRC12:11
*** mgariepy has joined #openstack-nova12:19
*** rpittau|bbl is now known as rpittau12:20
*** ttsiouts has joined #openstack-nova12:28
*** derekh has quit IRC12:33
aarentsHi nova,12:36
aarentssean-k-mooney: dansmith Let me know if it needs further amend on https://review.opendev.org/#/c/736169/ https://review.opendev.org/#/c/734776/ thanks!12:38
openstackgerritAlexandre Arents proposed openstack/nova master: libvirt: ensure disk_over_commit is not negative  https://review.opendev.org/71900812:39
sean-k-mooney^ that should be done by the config option12:39
sean-k-mooneywe set min 0 i think12:39
*** spatel has joined #openstack-nova12:40
*** dlbewley has quit IRC12:40
sean-k-mooneyoh that is not the ratio12:40
*** derekh has joined #openstack-nova12:40
sean-k-mooneyfor that to be negitive the size on disk would have to be larger then the virtual size12:41
*** dlbewley has joined #openstack-nova12:41
aarentssean-k-mooney: yes12:41
sean-k-mooneydoes it being negitive break something12:41
sean-k-mooneyah i see12:43
aarentsIt just mislead calcuation of available_disk_least on which rely disk_filter12:43
*** ttsiouts has quit IRC12:47
*** jawad_axd has quit IRC12:47
sean-k-mooneyya clamping the value shoudl be fine.12:47
*** ttsiouts has joined #openstack-nova12:47
*** bbowen_ has quit IRC12:49
*** bbowen_ has joined #openstack-nova12:49
*** ttsiouts has quit IRC12:52
*** ttsiouts has joined #openstack-nova12:54
*** ratailor has quit IRC12:54
*** dlbewley has quit IRC12:55
*** dlbewley has joined #openstack-nova12:56
*** rmart04 has joined #openstack-nova13:08
rmart04Hey all, I'm wondering if anyone could help me. Not strictly dev specific, but I'm having trouble with NUMA information being passed through to my virtual machines. /sys/bus/pci/devices*/numa_node always = -1. I'm running Rocky on C7, with numa_nodes=2 and cpu_sockets=2.13:12
rmart04and cpu pinning policy set to dedicated13:13
sean-k-mooneyis the -1 on the host or in the guest13:14
sean-k-mooneyif its in the guest that is expected13:14
rmart04In the guest13:14
sean-k-mooneyso we do not currently create a pcie root complex per numa node13:14
sean-k-mooneysince there is only one pci root all devices are childerne of that root13:15
sean-k-mooneywehn we do passthough we dont affiniteis the pci device to the virutal numa node of the guest13:15
sean-k-mooneyso it is reported as -1 meaning no numa affinity in the guest13:15
*** lbragstad has joined #openstack-nova13:16
sean-k-mooneyto change that we would likely have to use the q35 machine type and create a pcie root complete per numa node then add the passthough deivice to the correct pci root13:16
sean-k-mooneythat has other implciation mainliy that on move operation either we have to allow the toploty to change or we have to limit the host we can select to maintain the current toplogy13:17
sean-k-mooneyif we allow the toplogy to change the virtual pci address of the devices in the guest would also change13:18
*** ttsiouts has quit IRC13:18
sean-k-mooneyrmart04: but yes if you have a multi numa node guest this can result in cross numa traffic worse case twice because you dont know the numa affinity of the device13:19
*** ttsiouts has joined #openstack-nova13:19
openstackgerritMerged openstack/nova master: libvirt: Mark e1000e VIF as supported  https://review.opendev.org/73477713:20
*** psachin has quit IRC13:20
rmart04OK, appreciate all the info SeanKMooney. I guess another way around this is to split the host into two guests, one on each numa node with their associated pci-passthrough devices (GPUs). Currently I appear to be blocked on this by my older kernel. 3.10. I bump into an issue allocating memory from the second NUMA node for the second machine. I believe this is fixed in 4.14.13:22
rmart04qq, you mention the q35 machine type, what type do we use by default?13:23
*** ttsiouts has quit IRC13:23
sean-k-mooneyrmart04: if the guest has a numa toploty we do not allow its memory to come form a remote numa node by design13:25
sean-k-mooneyrmart04: we use pc13:26
sean-k-mooneyor pc-i440fx13:26
sean-k-mooneysomething like that13:26
sean-k-mooneyrmart04: what version of openstack are you using13:26
*** ttsiouts has joined #openstack-nova13:26
rmart04Rocky (Stein upgrade this weekend)13:27
sean-k-mooneydo you have gpus on all host numa nodes13:27
sean-k-mooneyor just numa 013:27
rmart04Yep, 2 sockets, 8 GPUs13:27
rmart044 each13:27
sean-k-mooneyok what iw was going to say is you might need to use nuam_policy=preferred in the alias13:28
sean-k-mooneyif you did not have them split13:28
sean-k-mooneyif you do then yes 2 vms with 1 numa each and the default legacy polciy which enforce numa affintiy between cpu/memory and the pci device is what you will want13:28
sean-k-mooneyyou can create a dual numa guest but the limitation is you will know know what numa node in the guest maps to the actull location of the device on the host13:29
sean-k-mooneyrmart04: are your vms using 1 gpu earch or multiple13:29
sean-k-mooneyit wont affect the answer just wondering13:30
rmart04Initial approach was 1VM 8 GPUs, second approach is 2VM's 4 each13:30
sean-k-mooneycool if you can horizontally scale then yes 2 vm with a singel numa node each shoudl give better performance13:31
*** dlbewley has quit IRC13:31
sean-k-mooneysince there will be no corss numa trafic fo the vm cpu memory and gpus13:31
*** dlbewley has joined #openstack-nova13:31
rmart04Thats the plan, but previously I tried this and got a cannot allocate memory issue, which seemed to be related to no dma32 on node1 in /proc/zoneinfo. Which I believe may be due to the older kernel13:32
*** boxiang_ has quit IRC13:32
*** boxiang_ has joined #openstack-nova13:32
sean-k-mooneyrmart04: oh you hit that13:33
sean-k-mooneyso that is not really a kernel issue so much as a kernl/bios/firmware issue that we worked around with a kvm change13:33
sean-k-mooneyrmart04: really there should have been a dma32 region allcoated per numa node13:34
sean-k-mooneythe kvm fix was not to require numa affinity for the dma32 region13:34
rmart04Oh right, interesting. Could you point me at the info for the kvm change?13:34
rmart04ah Ok, is that strict=false or similar13:34
sean-k-mooneykind of but that would have done it for all the vms memory13:35
sean-k-mooneythat was the alternitive workaround13:35
rmart04Please tell me its fixed in Stein? :D13:35
sean-k-mooneyhttps://lkml.org/lkml/2018/7/24/84313:36
sean-k-mooneythis is not an openstack bug13:36
sean-k-mooneyso we did not modify nova13:36
sean-k-mooneywhat distro are you using13:37
rmart04ah OK, Yes this is what I was looking at, I thought it was a Kernel patch13:37
rmart04Centos713:37
rmart043.10 kernel13:37
sean-k-mooneyit is for the kvm kernel module13:37
sean-k-mooneythere might have been another patch too13:38
sean-k-mooneyok i know we backported this in rhel 713:38
sean-k-mooneymay in 7.613:38
sean-k-mooneyso hopefully you have that in the lates centos 7 too13:39
sean-k-mooneylet me see if i have the bz for it in my history13:39
rmart04ah that would be amazing13:39
sean-k-mooneyso this is the nova patch we decied not to go with https://review.opendev.org/#/c/684375/ partly because we could not test it13:43
sean-k-mooneyrmart04: the commit meassage has the links to the relevent bugs and converations13:43
sean-k-mooneyhum it look like https://bugzilla.redhat.com/show_bug.cgi?id=1010885#c2 might also be a workaround but i dont think it is13:45
openstackbugzilla.redhat.com bug 1010885 in libvirt "kvm_init_vcpu failed: Cannot allocate memory in NUMA" [Medium,Closed: errata] - Assigned to mkletzan13:45
*** dlbewley has quit IRC13:50
*** dlbewley has joined #openstack-nova13:51
rmart04Remove cpuset from cgroup controllers?13:52
rmart04Is that what also makes the pinning work?13:53
sean-k-mooneyrmart04: yes but i dont know if that fully disables pinning13:53
sean-k-mooneyso the issue is that the wya libvirt appliees the cgrpus it also confines the allcoations of kernel memory13:53
sean-k-mooneyone of the fixes that was only a partial fix was to move that later so that the dma region could be allocate before the cpus are pinned13:54
sean-k-mooneythat was done in https://libvirt.org/git/?p=libvirt.git;a=commit;h=7e72ac787813:54
sean-k-mooneybut that was backin 2014 so it obviouslyu was not a full fix or it was broken angain later13:55
rmart04OK :/13:56
sean-k-mooneyrmart04: this was the final kernel fix i belive https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee6268ba3a6813:59
sean-k-mooneythat was in 4.1914:00
rmart04ah ok, my bad I said 4.14 earliar14:00
*** dklyle has joined #openstack-nova14:00
rmart04How easy is it to find out whether it was backported in C7?14:01
sean-k-mooneyits in the rhel  kernel-3.10.0-957.26.1.el7 pacakge and needs libivrt ibvirt-4.5.0-13.el7  or higher14:03
rmart04OK thats amazing thank you. I think i'll see how far we are away from those package versions and expidite moving to them14:06
*** rcernin_ has quit IRC14:14
*** dlbewley has quit IRC14:20
*** dlbewley has joined #openstack-nova14:21
*** ttsiouts has quit IRC14:30
*** mlavalle has joined #openstack-nova14:30
*** ttsiouts has joined #openstack-nova14:31
*** ttsiouts has quit IRC14:36
*** boxiang_ has quit IRC14:44
*** boxiang_ has joined #openstack-nova14:45
mordredsean-k-mooney: you remember every conversation we've had about things from the past, right?14:46
*** ttsiouts has joined #openstack-nova14:46
sean-k-mooneymordred: ocourse i was right and you were ....14:46
sean-k-mooneymordred: is there a converstation in partcalar?14:46
mordredsean-k-mooney: what's the story with the api_servers config option for glance - we've asked about deprecating/removing it and getting rid of the idea of being a poor-mans-client-side-load-balancer14:46
mordredbut I can't remember where the discussion got to on that14:47
sean-k-mooneyright we wanted to not do the crappy round robin thing we do in nova anymore14:47
mordred(I'm trying to help cyborg with their glance support, but since it's copied from nova I wnat to make sure anything I do would eventually be transferrable back to nova)14:47
sean-k-mooneyi belive dansmith was onboard with that14:47
sean-k-mooneyi dont know if we have done anything to change it in nova14:47
mordredyeah. I guess I should look to see if we marked the option as deprecated yet14:47
sean-k-mooneymordred: efried did bring it up but then he had to move on14:48
dansmithI was not on board with removing it,14:48
dansmithbut I think I was the only nova person in that position14:48
mordredSupport for image service configuration via standard keystoneauth1 Adapter14:49
mordredoptions was added in the 17.0.0 Queens release. The api_servers option was14:49
mordredretained temporarily to allow consumers time to cut over to a real load14:49
mordredbalancing solution.14:49
mordredthere's the help text- so it implies that post-queens its existence is temporary14:49
mordredbut with no official deprecation story :)14:49
mordredbasically - I would like to either kill this or if we can never kill it support it in ksa so that we can stop it with copying the round-robin code everywhere14:50
sean-k-mooneydansmith: oh i just rememebered you had an opion and i generally rememeber when you dont like something so i assume you were ok with it14:50
*** dlbewley has quit IRC14:50
*** ociuhandu has joined #openstack-nova14:50
efriedI would have deprecated it if I had been allowed to. I may be misremembering, but I think we put out a RFC on the ML and someone put up their hand and said they were still using it. Might even have been dansmith :P14:51
*** dlbewley has joined #openstack-nova14:51
mordredefried: :)14:51
dansmithno, wasn't me,14:51
dansmithbut there are people in redhat, tripleo and edge-related IIRC, that definitely don't want to lose it14:52
sean-k-mooneybecause its used for rabbit mq?14:52
efriedAlso, I think I commented on the cyborg stuff when it went in, saying they really shouldn't be carrying all this warty stuff over from nova -- that is, they *never* should have supported [glance]api_servers. But I think they wound up just merging it for expediency.14:52
mordredI thought all those people thought k8s was super sexy - why is a lb hard?14:52
dansmiththe history is a little dim for me without digging that back up, but basically for a very small number of remote edge machines, a "real load balancer" is not an option and having nova be able to try multiple glance servers is a major win14:53
mordrednod14:53
efriedIf ^ is not an issue for cyborg, I say they kill it, with prejudice.14:53
mordredok - that's fair enough I suppose14:53
sean-k-mooneydansmith: really? ha proxy is pretty light weight14:53
efriedesp if it means they're no longer anchored to ksa and can cut over to sdk14:53
sean-k-mooneyim not sure i by that given it will be handleing very little traffic14:54
dansmithsean-k-mooney: it's not just the haproxy of course, it's the config, the need for shared L2 failover VIP, pacemaker to manage it, etc14:54
dansmithit's all the complexity that comes with deploying that architecture14:54
mordredsure. although I'll again point my fingers at all of the people rushing to install k8s in those contexts so they should have an easier time of it14:55
dansmithI haven't heard any consistent plans about how to do that in a non-toy arrrangement, fwiw.. lots of chest-puffing and hand waving14:55
*** ociuhandu has quit IRC14:55
dansmithnot that it doesn't exist, but just I haven't heard a clear plan14:56
dansmithand all I'm doing is communicating the request14:56
mordreddansmith: fair14:56
efriedIf there really is a need for api_servers, then I guess we should support it in sdk so that's not something that blocks $consumer from cutting over.14:56
mordredI guess from my end I actually don't care other than wanting to mock people who think they can deploy a cloud but can't deploy a load balancer ...14:56
mordredefried: exactly14:56
dansmithpersonally, I do not understand how relying on a centralized (even if HA'd) load balancer is better than the clients knowing the options and being able to help themselves out of a failure to talk to one14:56
mordredif this is a thing that has to stay around14:56
efriedEasy for me to say, I won't be the one doing it.14:56
sean-k-mooneydansmith: ok that more hevy wait then kolla does so i guess that is different in ooo14:57
mordredthen I want to just say screw it and support it in the client layer14:57
efrieddansmith: ftr, api_servers isn't really a load-balancer. I think it's a deafdumbandblind round robin.14:57
mordredit's way too fundamental of a piece of config to stich in in the way it's being done14:57
mordreda very dumb one14:57
mordredit doesn't do retries14:57
efriedor failovers, or anything.14:57
mordredyah14:57
efriedYou simply get the next one on each subsequent api req14:57
mordredit's probalby _less_ HA14:58
efriedheh14:58
efriedindeed14:58
mordredmaybe it's time to one-more-time go to the mailing list14:58
dansmithI understand, but it still gets you 66% success instead of zero if 1/3 is down, and it could be made to do the right thing14:58
mordredmaybe life has changed for peopel since queens14:58
dansmithmordred: this was not queens when we had this discussion, fwiw14:58
sean-k-mooneymordred: for the better?14:58
mordreddansmith: no? that's the release mentioned in the nova config docs14:59
dansmithmordred: anyway, don't use my name in the email, I'm not prepared to argue for it anymore14:59
mordreddansmith: I won't14:59
dansmithmordred: that's when it was deprecated I think, but the concern about removing it was within the last year14:59
mordrednod14:59
dansmithbut also, we were told that it was going to go away regardless so those people are assuming it's going or gone I think14:59
mordredoh - well that's something perhaps15:00
artomstephenfin, did the flavor extra spec validation spec ever go anywhere?15:00
stephenfinartom: it landed last cycle15:00
stephenfinAPI microversion 2.84, I think?15:00
*** dlbewley has quit IRC15:00
*** dlbewley has joined #openstack-nova15:01
*** Luzi has joined #openstack-nova15:01
artomstephenfin, 2.86, but yeah, thanks for the pointer15:01
artomSo we could use that for the cpu_dedicated_mask, right?15:01
efriedDeprecate: https://review.opendev.org/#/c/692227/ (merged)15:02
efriedI don't see a patch (at least owned by me) proposing removing it.15:02
artomContext is my latest comment on https://review.opendev.org/#/c/468203/1515:02
efriedComments in above patch contain ML links mordred15:03
efriedand also refers to some people who wanted to keep it.15:03
stephenfinartom: fair comment. In the middle of something at the moment but I'll get a reply to it15:04
stephenfinwe can't rely on the validation though, mind you, since it's an API change15:04
artomstephenfin, no rush. Today's my "upstream day", trying to do some reviews where I can :)15:04
stephenfin*in an API microversion15:04
*** mlavalle has quit IRC15:05
*** ttsiouts has quit IRC15:07
*** ttsiouts has joined #openstack-nova15:07
mordredefried: ooh! so it is deprecated!15:07
*** breizhkoala has quit IRC15:08
mordredefried: how many releases do we have to wait to remove a deprecated thing? can we remove that now in victoria? or do we have to wait until w?15:08
*** mgariepy has quit IRC15:08
*** ttsiouts has quit IRC15:09
dansmithmordred: should probably ask the ptl15:09
*** mlavalle has joined #openstack-nova15:09
*** ttsiouts has joined #openstack-nova15:09
stephenfinmordred: it's six months or one release, whatever is greater15:10
stephenfinthough that's obviously tempered by impact15:10
dansmithI thought it was two releases for config options15:10
dansmithyou can't remove it in the N+1 release, but you can in the N+2,15:10
dansmithelse we'd break N->N+1 config compatibility15:10
mordredgotcha. so we can remove in W15:11
mordredbut not today15:11
stephenfinyou deprecate in N, and remove in N+115:12
stephenfinif you removed in N, you'd be breaking N-1 -> N compatibility15:12
stephenfinthat gives people the duration of N to get off $deprecatedthing15:13
dansmithisn't N-1->N+1 the same thing I said, but with N->N+2?15:13
*** ttsiouts has quit IRC15:14
dansmithoh, you're saying we deprecated it in U so people in U should know to get off of it so it can be gone in V? I guess technically that's right, but I really thought it was supposed to be two releases15:14
stephenfinyes :) you had me confused there15:15
stephenfindocs say the same https://docs.openstack.org/nova/latest/contributor/process#smooth-upgrades15:15
stephenfini.e. continue to support and test features for at least one release before they are removed15:15
sean-k-mooneyya so 1 release is the miniume we usuall take 2-3 to remove it15:16
*** mlavalle has quit IRC15:16
stephenfindefinitely not black and white15:16
sean-k-mooneydepeneing on how much of a pain it is15:16
stephenfinsean-k-mooney: if we ever remove it :)15:16
dansmithgiven it could break people's glance setup without warning,15:16
dansmithI'd say it's pretty high impact15:16
stephenfin"will be removed in a future release" <-- my boilerplate15:16
sean-k-mooneywe would need  a nova-status check at a minium right15:16
stephenfinI wouldn't say without warning, since we do have a big "this thing is deprecated" warning15:17
sean-k-mooneyalso ooo would have to be modified proably15:17
dansmithsean-k-mooney: for something like this, yeah I'd think so15:17
stephenfinI guess it comes down to how difficult the migration is15:18
stephenfinfrom $old_way to $new_way15:18
stephenfinI don't know about that so I'll defer to others15:18
sean-k-mooneyold way is template a config option. new way is either add the service to a load blancer or deploy a new loadbalncer and add it to that15:25
sean-k-mooneyi think the only thing we use this for in ooo wa rabbitmq but i could be wrong about that15:26
sean-k-mooneyi think in ooo we go to glance vai haproxy15:27
sean-k-mooneybut in general people could have been using this for any of the api endpoint?15:27
*** mgariepy has joined #openstack-nova15:28
*** slaweq has quit IRC15:33
*** huaqiang has joined #openstack-nova15:34
*** mlavalle has joined #openstack-nova15:35
*** hamalq has joined #openstack-nova15:39
*** ociuhandu has joined #openstack-nova15:40
*** links has quit IRC15:44
*** hamalq has quit IRC15:45
gibinova weekly meeting will start in 12 minutes on #openstack-meeting-315:47
mordredsean-k-mooney: well - we wouldnt' be removing this for rabbit15:49
*** bhagyashris is now known as bhagyashris|away15:49
mordredsean-k-mooney: this is only about talkig to openstack api services15:49
mordredit's possible we've not been properly clear about that15:49
*** dlbewley has quit IRC15:50
sean-k-mooneymordred: why would we remove it for one and not the other15:50
*** dlbewley has joined #openstack-nova15:50
sean-k-mooneyits equally bad in both cases15:50
sean-k-mooneyor good depending on your view15:50
mordredsean-k-mooney: "use services from the keystone catalog and via the normal api consumption channels" is the driver15:50
*** gyee has joined #openstack-nova15:50
mordredrabbit doesn't get configured via the catalog nor consumed using a standard set of connection information15:51
*** priteau has joined #openstack-nova15:53
sean-k-mooneymordred: have you tought about a keystone feature to allow the same behavior :P15:53
mordredyes - it was _strongly_ opposed by the keystone team - becaues they did not want to build a bad load balancer15:54
sean-k-mooneybut ok if its the openstack services only im not sure if that changes the edge configuration15:54
mordredyeah - and really, it's ONLY glance15:54
mordredthat's the only place this option exists15:54
*** spatel has quit IRC15:55
mordredso it's not even that there is a generalized mechanism for talking to api services with a list of endpoits in nova -- it's _just_ for glance15:55
*** spatel has joined #openstack-nova15:55
mordredand I'm pretty sure the reason it's special is that way back in the day glance wasn't considered user-facing, so why would you have it in your load balancer15:55
sean-k-mooneywell in the edge configurtion you want your edge site to use a local glance api15:56
sean-k-mooneyand leavge the glance multistore feature15:56
sean-k-mooneynow i dont know if that needs this15:57
sean-k-mooneyor can we configure the glance store seperatly and have multiple endpoints in keystone15:57
sean-k-mooneybut i feel like we would need the later?15:58
sean-k-mooneyyou dont want just one endpoint as you would have to do anycast routing tricks if you wanted to hit the local api15:59
*** Luzi has quit IRC16:01
*** jobewan has quit IRC16:09
mordredsean-k-mooney: well - for those you can totally still use endpoint override16:10
mordredI think the thing is that in general for a consumer the idea is that an openstack service has "an endpoint" - and that concept is pretty baked in to many things16:10
mordredbut it's always possible for a consumer to override "the endpoint" that keystone tells it16:11
sean-k-mooneyisnt that what the config option is for16:11
mordredif we wanted to do a thing like your second case - it's obviously possible - but it would really take a coordinated design and implementation in a few places16:11
sean-k-mooneyi know it can do the loadbalncing tooo16:11
mordredno - the config option that we want to remove is for giving a _list_ of overrides16:12
openstackgerritMerged openstack/nova master: Remove hacking rules for python 2/3 compatibility  https://review.opendev.org/73398716:12
mordredand that concept exists in one and only one place - inside of nova for overriding glance16:12
sean-k-mooneyright but do we have a way to locally override without that16:12
mordredyes16:12
sean-k-mooneyfor glance16:12
sean-k-mooneyok16:12
mordredthat doesn't go away16:12
sean-k-mooneyright i just was not sure if we had two way for glance16:13
mordredthat just gets to use the normal mechanism and nova can remove a pile of special case code and we can go through and simplify several things16:13
sean-k-mooneyon that supports a list and another that is a single url16:13
mordredyup. that's what you have currently16:13
*** sangeet has joined #openstack-nova16:17
*** belmoreira has quit IRC16:17
sangeetI have SSL enabled for keystone. My compute service fails to come up due to SSL 'certificate verify failed'. I am not sure if I am placing the certifcate at the correct place. Where should the certifciate go? I tried to palce it in /etc/nova/certs/ca.crt. it did not work. Then I set CA_CERTS, it still did not work. Any help will be highly apprecaited. I am running Stein16:19
sean-k-mooneysangeet: you need to add it to the openerating systems certificat store16:20
sean-k-mooneyi dont think we support passing a ca directly to nova since now does not realy know anything about tls16:21
sangeetnova-api is working fine for me. I placed the certs in /etc/nova/certs folder16:21
*** songwenping_ has joined #openstack-nova16:22
sean-k-mooneyis the api runnign on the host that generated teh cert16:22
sangeetNo16:23
sangeetBut I converted api to wsgi16:23
sean-k-mooneythe only ca config option i see are related to rabbitmq and we dont mention this in https://docs.openstack.org/nova/latest/admin/security.html16:23
sean-k-mooneyactully we have options for vendor data too16:24
*** bbowen_ has quit IRC16:24
sangeetIssue is compuet is trying to get token from keystone and since keystone supports SSL it faile16:24
sean-k-mooneysangeet: right but thats becasue you have not added the private ca to the operating systsms cert store16:25
*** songwenping__ has quit IRC16:25
sean-k-mooneyyou should be adding the ca cert in /usr/local/share/ca-certificates/ and then do sudo update-ca-certificates16:27
*** jmlowe has quit IRC16:27
*** jmlowe has joined #openstack-nova16:29
*** hamalq has joined #openstack-nova16:31
*** hamalq has quit IRC16:32
*** hamalq has joined #openstack-nova16:33
*** salmankhan has quit IRC16:34
*** hamalq_ has joined #openstack-nova16:44
*** hamalq has quit IRC16:47
*** avolkov has quit IRC16:51
*** bbowen has joined #openstack-nova16:58
*** rpittau is now known as rpittau|afk17:00
*** derekh has quit IRC17:02
*** dlbewley has quit IRC17:02
*** dlbewley has joined #openstack-nova17:02
*** dtantsur is now known as dtantsur|afk17:10
*** tesseract has quit IRC17:21
sangeetsean-k-mooney .. sorry had to run for an appointment. Should the cert be in  /usr/local/share/ca-certificates/ or /var/lib/openstack/lib/python3.6/site-packages/certifi/cacert.pem? certifi.where() shows later. Also name "ca.crt" is the correct name?17:50
mordreddo we not expose the keystoneauth session ssl options?17:53
sean-k-mooneymordred: maybe but that would be documented in keystoneauth17:54
sean-k-mooneynot nova17:54
sean-k-mooneysangeet: it should be in /usr/local/share/ca-certificates/17:54
sean-k-mooneysince they are your own addtional CA certs not one packaged by the distro17:55
mordredsean-k-mooney: that won't necessarily work17:55
*** dlbewley has quit IRC17:55
mordredsean-k-mooney: python requests bundles a CA bundle and doesn;t' use system cas17:55
mordredbecause MONKEYS17:55
*** dlbewley has joined #openstack-nova17:55
sean-k-mooney...17:56
mordreddon't even get me started17:56
sean-k-mooneyok so do we have docs for how to configure keystone with tls somehwere17:56
mordredwhich is why it's important to be able to pass a path to a CA in config - I believe nova is doing a register_conf_options from ksa - so it should be possible to pass cafile in nova.conf ...17:56
* mordred goes looking17:56
sean-k-mooneyits not in the nova security docs17:56
mordredwell - that might be a bug - but let me see what I can find17:56
sean-k-mooneymordred: ya i think we do17:57
*** ralonsoh has quit IRC17:57
sean-k-mooneyi guess it could be in the install docs i just did a google search and didnt find them17:57
mordredregister_ksa_opts17:57
mordredthat's in nova/conf/utils - and calls ks_loading.register_session_conf_options - which will register an option "cafile"17:58
mordredit's going to be per-service - so I think it would be [identity]cafile=/etc/nova/certs/ca.crt - but really it would be best to put it in [networking]cafile= and [image]cafile and [placement]cafile= too ...18:01
mordredI'm not 100% sure what the story would be if keystone and a given service need _different_ ca's18:01
mordredsangeet: ^^18:01
sangeetthanks mordred .. so I onlty need to change the conf file as you suggested and it will be used by  ksa automatically?18:02
mordredsangeet: yes. at least I hope so - that's the theory :)18:02
sangeetLet me try that .. my system is up. Thanks18:03
mordredwoot!18:03
mordredwe should really make a general [session] config section - having those options repeat for each service is a little weird18:03
mordredsean-k-mooney: I feel like I should update the nova docs to include this information - but I'm not really sure where would be a good idea for that18:04
mordredefried: isn't there docs somewhere about the ksa conf options18:06
mordred?18:06
efried...18:06
mordredefried: like - now that you can configure session adapter stuff via service-types-authority names and the ksa options ... do we have docs about that in the nova docs?18:07
* mordred can't find - but doesn't know where to look18:07
*** mriedem has joined #openstack-nova18:07
efriedI think I understand the question, I'm just trying to swap that back in from tape.18:08
efriedmordred: https://docs.openstack.org/nova/latest/configuration/config.html18:09
efriedIf you search for e.g. `cafile` you'll find an entry for each $service that uses ksa.18:09
efriedsix entries for `endpoint_override`18:09
mordredefried: ah - oh, that's probably generated from ksa by sphinx18:09
efriedexactly18:09
mordredso a git grep wasn't finding it - that makes sense18:10
mordredefried: thanks!18:10
efriedyw18:10
efriednot sure about 'sphinx', but generated by doc build, yes.18:10
*** factor__ has quit IRC18:11
efried...and I think it comes in by virtue of the `list_opts()` methods in conf/*, e.g. https://github.com/openstack/nova/blob/master/nova/conf/glance.py#L17318:11
efried...which as you can see uses ksa's methods for generating those18:11
*** factor__ has joined #openstack-nova18:11
mordredefried: yah. \o/ yay18:13
*** rmart04 has quit IRC18:14
sangeetten thousand thansk modred .. it worked. I am so exicted. QQ Do I need to put it under idenity also or neutron, glance and placement is enough?18:19
sangeetSorry *mordred ^^18:19
sean-k-mooneymordred: i was expecting to find it here https://docs.openstack.org/nova/latest/admin/security.html18:21
sean-k-mooneymordred: although the install guide would make sense18:21
sean-k-mooneyefried: mordred i dont think the config guide is really helpful in this case18:22
sean-k-mooneythat is where i started but i did not find it mainly because i was looking for ca_18:22
sean-k-mooneybut it was not obvious18:22
efriedI don't think we should describe the optinos in depth in the security guide, but it would be sane to refer to the config docs from there.18:23
sean-k-mooneyyep that is what i was thinking too altough i think having a secting in the install guide would make sense18:24
sean-k-mooneye.g. how to isntall with tls?18:24
sangeetI agree .. that would be an excellent idea18:27
mordredsangeet: you'll likely need to put it in for each service you're using18:28
mordredsangeet: so - yeah - I'd do identity I think18:29
*** bbowen has quit IRC18:37
*** bbowen has joined #openstack-nova18:37
sangeetThank you mordred18:38
*** songwenping__ has joined #openstack-nova18:41
*** songwenping_ has quit IRC18:44
*** maciejjozefczyk has quit IRC18:52
*** vishalmanchanda has quit IRC18:55
*** songwenping_ has joined #openstack-nova19:00
*** jdillaman has quit IRC19:01
*** songwenping__ has quit IRC19:03
sangeetmordred .. oops now my nova-conductor is not liking it when I try to create a server. I have set cafiles as we discussed above. "OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /etc/nova/certs/ca.crt"19:12
sangeetIt seems conductor is expecting the CA file to be at some other location19:13
mordredsangeet: are those on the same machine?19:17
sangeetdiffernt pods19:17
sangeetthe file exist19:18
mordredhrm. I'm not sure about that one - maybe someone else will know19:18
sangeet sean-k-mooney efried .. please help ^^19:19
efriedI'm no expert here, so this is just a guess:19:20
efriedIf you put this in [identity], it means all the nova services will try to use it when talking to keystone.19:20
sangeetI am up for trying anything19:20
efriedSo you need it on every node that's running any nova service (conductor, compute, scheduler, whatever)19:21
efriedit == the crt fil.19:21
efriedfile19:21
sangeetso put cafile=/etc/nova/certs/ca.crt under identity19:21
efriedeh? I thought that's what you did, and it didn't work19:21
efriedLet's back up.19:22
efriedWhat change did you make that's leading to this error?19:22
sangeetI ut it in compute and not in conductore19:22
sangeetLet me try to put it under identity also19:22
*** gmann is now known as gmann_afk19:22
efriedwaitwait19:22
efriedI haven't been following this conversation, so I don't want to lead you down a rabbit hole.19:22
efriedWhat exactly have you changed so far?19:22
sangeetI have Keystone deployed with SSL. In my nova.conf I set cafile=/etc/nova/certs/ca.crt for [neutron], [glance], [keystone_authtoken], [placement]19:25
efriedHm, okay, I'm not sure about [keystone_authtoken] -- that's to set up the server side of the keystone service.19:26
efriedBut nova talks to some of those services from multiple places -- conductor, scheduler, compute.19:27
efriedI don't remember offhand which ones talk to which ones from where.19:27
efriedAlso note that conductor and compute use different config files by default (unless that's changed, or unless you're on an old release), so if you're running both, you'll want to set up both files.19:29
efriedBut honestly, beyond that, I'm really out of my depth. sean-k-mooney would probably be a better resource. He is EU, so maybe try again "tomorrow".19:29
sangeetI am using stein and I do have different configs as they are running on a different pods19:30
sean-k-mooneyefried: is that a hint i should go get dinner because it should be just cooked :)19:31
efriedsean-k-mooney: yes, you should not be working right now.19:32
efriedsangeet: TL;DR: I suspect you need the crt file available/accessible on the same file system as the nova.conf file you're editing.19:32
efriedsame file system in the same container etc.19:33
sean-k-mooneyefried: hehe if i had started at 11 like i normally do i would argue but since i started at 8am today, night all o/19:33
efriedBut I'm also really not sure what mucking with [keystone_authtoken] did for you.19:33
*** xinranwang_ has quit IRC19:33
*** jsuchome has quit IRC19:34
*** gmann_afk is now known as gmann19:37
*** lvdombrkr has quit IRC19:40
sangeetefried .. yes cafile needed to be set in identity section on conductor. It works now.20:08
efried\o/20:08
efriedNot to confuse things, but is it possible it's *only* required in [identity]?20:09
efriedI don't know whether/where we talk to keystone as an actual client; we may just be using it to set up the connection to the other services. But... I really don't know how that all works.20:10
*** gmann is now known as gmann_afk20:10
*** nweinber has quit IRC20:14
mordredefried: yeah - I'm gonna try to do an audit through of that20:17
efriedcool20:17
mordredefried: cause right now I think it's ... well, if you don't know and I don't know - then likely nobody knows20:17
efriedlbragstad might :P20:18
efriedor cmurphy. Or other people who are no longer stacking.20:18
*** slaweq has joined #openstack-nova20:23
lbragstadi actually didn't realize nova had an identity section *and* a keystone_authtoken section20:24
efriedIIUC, the former is for talking to keystone as a client, and the latter is for setting nova up as a server.20:24
lbragstad(the keystone_authtoken section comes from keystonemiddleware)20:24
efriedtbh, I'm not sure where we're actually using the former from nova. But we must be, or sangeet's change wouldn't have fixed the problem...20:25
lbragstadyeah - iirc (and i'm probably dated here) [keystone_authtoken] is only invoked by keystonemiddleware to fetch information about tokens out of keystone20:27
lbragstadahh - it looks like the [identity] section is used to validate project IDs20:31
efried"used" -- by nova?20:31
efriedor by, like, everyone who has one?20:32
lbragstadhttps://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/identity.py20:32
efriedInteresting.20:33
lbragstadmaybe? i might not be following this properly20:33
lbragstadi think this is what i was looking at https://docs.openstack.org/nova/latest/configuration/config.html#keystone20:34
efriedOh, that's for sure a place where we're using the [identity] section to create a ksa adapter that talks as a client to the keystone service's API.20:34
*** priteau has quit IRC20:34
lbragstadhttps://docs.openstack.org/nova/latest/configuration/config.html#keystone-authtoken is the keystonemiddleware section20:35
efriedYeah, some layer of this translates $service_name to $project_name or vice versa20:35
efriedyes.20:35
lbragstadi don't actually see an [identity] section20:35
lbragstadin the configuration reference20:35
lbragstadi see [keystone] and [keystone_authtoken]20:36
efriedI believe you're allowed to use either [identity] or [keystone] for anything we load up via get_{sdk|ksa}_adapter.20:36
efriedI mean, [$service] or [$project]20:36
lbragstadoh - so service types and service names are interchangable?20:36
lbragstadinterchangeable*20:36
efriedonly if we're using get_{sdk|ksa}_adapter.20:36
efriedWhich I think we are for everything except cinder at this point.20:37
lbragstadok20:37
efriedAnd by "we" I mean "they". I don't work here anymore :P20:37
lbragstad:)20:38
*** haleyb has quit IRC20:47
*** maciejjozefczyk has joined #openstack-nova20:48
*** haleyb has joined #openstack-nova20:55
*** xek has quit IRC20:56
mordredefried: I was about to ask you about cinder21:02
mordredefried: I'm guessing I should put that on my list too21:02
efriedI made several attempts at it over the years, but they never quiiite landed.21:02
mordred(mostly noticed that there's a weird os-region-name option)21:02
efriedI think there's still an open change under my name21:02
mordredefried: cool. maybe I'll finish that - with your name on it it'll have more credibility21:03
efriedThere were significant difficulties with the (in)compatibility between ksa and cinderclient.21:03
efriedhah!21:03
mordredin fact, I might just push up changes for this forging the author to say they're from you21:03
mordredefried: "surprising"21:03
efriedhttps://review.opendev.org/50834521:04
efriedhttps://review.opendev.org/65598521:04
efried(I haven't opened those, they're just the ones on my dashboard with 'cinder' in the title)21:04
*** raildo has quit IRC21:10
*** mloza has quit IRC21:15
*** hamalq has joined #openstack-nova21:16
*** hamalq__ has joined #openstack-nova21:17
*** hamalq_ has quit IRC21:18
*** hamalq has quit IRC21:20
melwittdansmith: left comments on the bottom two rbd multi store patches. bottom one is a docstring update needed, next patch looks to be one small case of missing test coverage and a couple doc-related things21:26
dansmithmelwitt: thanks21:39
openstackgerritDan Smith proposed openstack/nova master: Plumb image import functionality through our glance module  https://review.opendev.org/73155021:45
openstackgerritDan Smith proposed openstack/nova master: Make libvirt able to trigger a backend image copy when needed  https://review.opendev.org/65699821:45
*** hamalq__ has quit IRC21:49
*** spatel has quit IRC21:52
*** rcernin_ has joined #openstack-nova21:54
*** markvoelker has joined #openstack-nova21:58
*** markvoelker has quit IRC22:02
*** gmann_afk is now known as gmann22:04
*** tonyb has joined #openstack-nova22:05
*** eharney has quit IRC22:08
*** rcernin_ has quit IRC22:13
*** slaweq has quit IRC22:13
openstackgerritMarcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64  https://review.opendev.org/71442522:18
*** rchurch has quit IRC22:24
*** tosky has quit IRC22:25
*** dlbewley has quit IRC22:25
*** dlbewley has joined #openstack-nova22:26
*** rchurch has joined #openstack-nova22:27
melwittgmann: is/was there a change yet to make stable/stein grenade n-v? wondering if it's safe to recheck changes yet22:37
melwittalso note that nova-live-migration is failing on stable/stein too22:37
melwittsaying virtualenv missing22:38
gmannmelwitt: i am trying to get working on train with this and tomorrow I am planning for making it n-v on stein - https://review.opendev.org/#/c/736284/922:38
melwittack22:38
gmannnova-live-migration is difficult one as that is legacy job, on devstack, grenade we fixed that error - https://review.opendev.org/#/c/736750/122:39
gmannmelwitt: but there are  multiple updates happening on devstack/grenade and image side. so let's see how it behaves once we get all those in22:41
gmannclark is updating images also which were not present due to disk full.22:41
*** sangeet has quit IRC22:59
*** tkajinam has joined #openstack-nova23:00
*** rcernin_ has joined #openstack-nova23:15
*** rcernin_ has quit IRC23:15
*** rcernin has joined #openstack-nova23:16
*** dlbewley has quit IRC23:32
*** dlbewley has joined #openstack-nova23:33
*** tetsuro has joined #openstack-nova23:47
*** dlbewley has quit IRC23:53
*** dlbewley has joined #openstack-nova23:53

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!