Thursday, 2021-11-04

opendevreviewGhanshyam proposed openstack/nova stable/train: DNM: test tempest train-last tag  https://review.opendev.org/c/openstack/nova/+/81659800:47
*** ministry is now known as __ministry02:26
*** gibi_pto_back_thu is now known as gibi07:56
gibigood morning08:01
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Parse alias from domain hostdev  https://review.opendev.org/c/openstack/nova/+/81648608:03
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Prevent leaked eventlets to send notifications  https://review.opendev.org/c/openstack/nova/+/81648708:07
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Avoid unbound instance_uuid var during delete  https://review.opendev.org/c/openstack/nova/+/81648808:08
gibibauzas: the reno for the pps work has landed so you can marke the 08:09
gibihttps://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate08:09
gibibp as implemented08:09
gibi\o/08:09
opendevreviewBalazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next  https://review.opendev.org/c/openstack/nova/+/81174808:11
lyarwoodgibi++08:15
gibilyarwood: thanks for the reviews yestarday08:16
lyarwoodnp, still catching up08:16
gibiI hope you enjoyed the explanation of the fix for https://launchpad.net/bugs/1946339 . It was a real adventure for me in eventlet/greenlet land.08:20
jpodivinHi everyone. Has anyone ever encountered: "The placement service for 192.168.24.100:regionOne exists but does not have any supported versions." ? 08:21
jpodivinIt's hitting master in rdo, but wallaby somehow avoids it. 08:22
gibijpodivin: hi, could you try to simply send a GET request to the root of you placement service?08:26
gibiyou should see something like https://paste.opendev.org/show/810375/08:26
jpodivingibi: hm, sadly it's a proposed CI job, so the nodes are already down. 08:27
jpodivinalthought I do have the logs stored08:27
gibithen it would be good to check the placement service logs08:27
jpodivingibi: anything specific I should look for? 08:28
gibijpodivin: do you see requests resulting in 404 there?08:28
EugenMayerwhen running nova backup on an image, i see pending operations in the UI. Is there any way to show this tasks and their detailed operations on the cli? glance taks-list and glance image-tasks do not show any pending tasks08:28
gibiwe had an issue with apache config not long ago resulted in wrong proxy config for placement https://review.opendev.org/c/openstack/devstack/+/811389 08:29
jpodivingibi: no, it looks fairly clean, couple of warnings but those seem related to deprecation. https://logserver.rdoproject.org/99/36499/6/check/periodic-tripleo-ci-centos-8-containers-multinode-compute-master-validation/91262ed/logs/subnode-1/var/log/containers/placement/placement.log.txt.gz08:29
jpodivingibi: found another log, that might be what you meant. Lists a bunch of requests but 404 https://logserver.rdoproject.org/99/36499/6/check/periodic-tripleo-ci-centos-8-containers-multinode-compute-master-validation/91262ed/logs/subnode-1/var/log/containers/httpd/placement/placement_wsgi_access.log.txt.gz08:31
jpodivinInteresting thing is: it starts *after* the error occurs, not before.08:32
gibiyeah, these logs seems to indicate your placement service works correctly and some clients (probably nova) was able to communicate with it08:32
gibiif the error happens after the logs ends then it can be that your placement service was simply stopped / crashed08:33
jpodivingibi: looking at the time stamps, it looks like the error occurs a approximately one minute before the placement requests log starts .08:34
jpodivingibi: scrap that. It's actually about 3 seconds before08:34
jpodivinstill, before any communication is recorded .08:35
gibistill it means that the placement server is not running when you client tried to read the supported versions from it08:35
lyarwoodbauzas / melwitt ; https://review.opendev.org/c/openstack/nova/+/807025 - would you mind hitting this and the fups on top this week?08:40
jpodivingibi: yes that does seem to be the case08:45
jpodivingibi: question is: why would that happen on master and not on wallaby. 08:45
gibijpodivin: I have no idea09:06
lyarwoodsean-k-mooney: can you hit https://review.opendev.org/c/openstack/nova/+/811716 again when you get a chance09:34
EugenMayerafter deploying with kolla and tls, it seems like the GUI based TTY console is still behin to http, not https, while anything else is properly behind tls encryption. The point is, horizon tries to load from https:6080 .. but it fails (no socket). http:6080 has a socket, but the token seems to be invalid there. Any hints what could be wrong, i09:35
EugenMayerassume this is related to the nova service?09:35
opendevreviewLee Yarwood proposed openstack/nova master: WIP configdrive: Move mkisofs_cmd default to mkisofs  https://review.opendev.org/c/openstack/nova/+/80892109:36
EugenMayerwhen looking at the nova-compute configuration i see https://gist.github.com/EugenMayer/058499029fbd298600a8efa634687c9209:36
bauzasgibi: done, https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate is now Implemented09:37
gibibauzas: thanks09:37
bauzas(thanks for noticing me)09:38
bauzaslyarwood: ack, will look09:38
EugenMayersoseems like https://bugzilla.redhat.com/show_bug.cgi?id=1722089 is related09:38
opendevreviewLee Yarwood proposed openstack/nova master: DNM/WIP libvirt: Default x86_64 instances to the q35 machine type  https://review.opendev.org/c/openstack/nova/+/81662909:40
kashyaplyarwood: --^ I'm curious too... :)  Thx for posting it09:41
lyarwoodEugenMayer: the downstream Red hat bug isn't related09:41
EugenMayerlyarwood thank you. Not sure what i miss then, reading https://docs.openstack.org/nova/xena/admin/remote-console-access.html09:42
EugenMayera little hard to understand what kolla did and did not09:42
EugenMayerthis is what i have in nova-vnc https://gist.github.com/EugenMayer/82528fcfca6e22b818f865852606f28c - currently kind of double posting since i'am not sure this is a nova 'issue' or a kolla 'configuration' issue or a kolla 'deployment bug'09:45
lyarwoodEugenMayer: I'd think that's a kolla config bug tbh09:47
lyarwoodthe URL returned from n-api is https right?09:47
lyarwoodwhen you do a console url show?09:47
EugenMayerlyarwood how would i do that?09:48
lyarwoodEugenMayer: https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/console-url.html#console-url-show openstack console url show $instance09:51
EugenMayerlyarwood the URL looks good. HTTPS, right fqdn, 6080009:54
EugenMayertelent on that port works, but i assume it talks http09:55
EugenMayerwget returns 'GnuTLS: Error in the pull function.09:56
EugenMayerUnable to establish SSL connection.'09:56
lyarwoodkk then it's the nova-novncproxy service that isn't configured correctly and thus a Kolla bug09:56
EugenMayerlyarwood thank you. Already looking at the configuration. I assume the certificates are not bound properly09:59
EugenMayerlyarwood https://gist.github.com/EugenMayer/fba4eb20a49ccd717ba70f38188a8e1e - i'am using officially signed certificates. Maybe missing https://docs.openstack.org/nova/xena/admin/remote-console-access.html#novnc-proxy-server-configuration /etc/pki/libvirt-vnc/server-cert.pem or something?10:02
lyarwoodthat's to encrypt the connection between the proxy service and libvirtd10:04
lyarwoodI think your issue is between the user and the proxy service right?10:05
EugenMayeryes10:10
EugenMayerlyarwood any hints where to start10:29
lyarwoodEugenMayer: I'm not sure how Kolla configures things tbh but I'd start with the config file associated with the nova-novncproxy service itself10:29
lyarwoodEugenMayer: see if it differs from nova-api etc that are working with tls already10:30
EugenMayerthat's what i posted lyarwood - the problem is, not sure what to expect there10:30
*** lbragstad4 is now known as lbragstad10:33
opendevreviewMerged openstack/nova stable/xena: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81091110:34
lyarwoodEugenMayer: https://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/cmd/baseproxy.py#L48-L87 - so looking at the code it's using configurables like ssl_only and cert10:36
EugenMayerwhich are missing in my case10:37
lyarwoodEugenMayer: iirc from an earlier pastebin websockify couldn't find the cert?10:37
lyarwoodI've lost the gist now but I'm sure it was listing a cert file 10:39
lyarwoodso you must have cert set to something in the config used by the proxy service10:39
lyarwoodit's in the DEFAULT namespace btw, not under vnc10:39
lyarwoodjust grep from ^cert10:39
lyarwoodfor*10:40
*** lbragstad1 is now known as lbragstad10:43
EugenMayersorry i'am lost lyarwood, not sure which you mean https://gist.github.com/EugenMayer/058499029fbd298600a8efa634687c92 or https://gist.github.com/EugenMayer/fba4eb20a49ccd717ba70f38188a8e1e or https://gist.github.com/EugenMayer/82528fcfca6e22b818f865852606f28c - if nothing of this, which on do you need. Happy to hand over anything10:45
lyarwood2021-11-04 09:18:39.933 13300 INFO nova.console.websocketproxy [-] 10.0.1.1: SSL connection but '/self.pem' not found10:45
lyarwood^ that error suggests that the nova-novncproxy hasn't been configured correctly10:46
EugenMayeryes, that is what i saw too. So 'cert' in noproxy under [vnc]10:50
opendevreviewWenping Song proposed openstack/nova master: Support concurrently add hosts to aggregates  https://review.opendev.org/c/openstack/nova/+/81510510:50
lyarwoodEugenMayer: no, it's outside of that in the default namespace AFAICT10:51
lyarwoodEugenMayer: if you grep for self.pem you should be able to find it10:51
lyarwoodEugenMayer: this is definitely a Kolla bug FWIW10:51
lyarwoodEugenMayer: it smells like it hasn't copied that cert into the container for the service or something?10:52
EugenMayerit does copy those and maybe is missing one. Let me clear up my confusion Which part of the configuration is broken / missing ther certs. On the computes the nova-compute or on the controller the novncproxy10:53
lyarwoodEugenMayer: on the contrller, the novncproxy service10:55
lyarwoodEugenMayer: assuming the logs you shared were from the controller10:57
lyarwoodEugenMayer: regarding 2021-11-04 09:18:39.933 13300 INFO nova.console.websocketproxy [-] 10.0.1.1: SSL connection but '/self.pem' not found10:57
lyarwoodYeah actually that can only be from the controller10:58
EugenMayerlyarwood ok so i check the noproxy container and how the certificates are deployed and configured11:02
lyarwoodhttps://github.com/novnc/websockify/blob/master/README.md#encrypted-websocket-connections-wss - FWIW self.pem is the default cert websockify will try to load when it's asked to use SSL 11:05
lyarwoodas I said before https://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/cmd/baseproxy.py#L48-L87 is where Nova tries to provide the correct cert when launching the novncproxy service11:06
EugenMayerwell ok now i guess that will be the issue. is self.pem a cert+private-key format?11:07
*** lbragstad7 is now known as lbragstad11:07
EugenMayerah --cert --key11:08
lyarwoodright you should already have these in your env?11:10
lyarwoodjust under a different filename11:10
lyarwoodso just update the nova.conf used by the service to point to them11:10
lyarwoodcert=/path/to/cert11:10
lyarwoodkey=/path/to/key11:10
lyarwoodand again, DEFAULT namespace so outside of the [vnc] section etc.11:11
EugenMayerchecking the ansible tasks right now (kollas)11:11
lyarwoodyeah it doesn't look like it has support tbh11:16
EugenMayerhttps://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/templates/nova.conf.j211:16
lyarwoodlooking at the config templates at least11:16
EugenMayeryes, it's mising11:16
EugenMayerlyarwood did the nova implemenation of novnc change since victoria?11:17
lyarwoodI don't think anything has that would change this behaviour tbh11:18
EugenMayerin other words, looking back, that template never had cert/key as values set for TLS11:18
EugenMayerso either it has never been supported at all - or it is a regression11:19
lyarwoodyeah I would assume this has never been supported by Kolla tbh, should be pretty trivial to correct however11:20
EugenMayeryes it is just PITA to search for that, i you are clueless (like i'am). You never know what is supposed to work and what not, and how a working configuration does look like11:21
EugenMayerlyarwood any idea what the path of self.pem looks like? i mean i do not assume /self.pem is really absolute here11:22
lyarwoodhttps://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/conf/novnc.py#L41-L52 looks like it's relative so it depends how kolla is launching the service11:24
lyarwoodbut again updating the nova.conf used by the service to point to your actual key and cert is a better option here11:24
EugenMayeryes sure, it is a little more work then that11:25
EugenMayeri will need to volume-mount the certs first, i cannot just docker cp them, or they will be lost on upgrade. Then a config override for nova conf (conditional) and then mounting that certs11:26
EugenMayerbut still, HUGE help lyarwood, i should be able to handle the rest. Thank you big times!11:26
lyarwoodnp good luck :)11:26
EugenMayerthank you sir11:26
*** dpawlik1 is now known as dpawlik12:16
opendevreviewVlad Gusev proposed openstack/nova stable/train: Reproduce bug 1897528  https://review.opendev.org/c/openstack/nova/+/79211612:24
opendevreviewVlad Gusev proposed openstack/nova stable/train: Ignore PCI devices with 32bit domain  https://review.opendev.org/c/openstack/nova/+/79211712:24
opendevreviewVlad Gusev proposed openstack/nova stable/stein: Reproduce bug 1897528  https://review.opendev.org/c/openstack/nova/+/81665612:25
opendevreviewVlad Gusev proposed openstack/nova stable/stein: Reproduce bug 1897528  https://review.opendev.org/c/openstack/nova/+/81665612:26
opendevreviewVlad Gusev proposed openstack/nova stable/stein: Reproduce bug 1897528  https://review.opendev.org/c/openstack/nova/+/81665612:37
opendevreviewVlad Gusev proposed openstack/nova stable/stein: Ignore PCI devices with 32bit domain  https://review.opendev.org/c/openstack/nova/+/81668212:37
opendevreviewVlad Gusev proposed openstack/nova stable/stein: Ignore PCI devices with 32bit domain  https://review.opendev.org/c/openstack/nova/+/81668213:20
opendevreviewMerged openstack/nova master: compute: Update volume_id within connection_info during swap_volume  https://review.opendev.org/c/openstack/nova/+/80702513:24
opendevreviewMerged openstack/nova master: fup: Move _wait_for_volume_{attach,detach} to os-volume_attachments  https://review.opendev.org/c/openstack/nova/+/81077513:24
opendevreviewMerged openstack/nova master: fup: Refactor and simplify Cinder fixture GET volume mock  https://review.opendev.org/c/openstack/nova/+/81077613:25
opendevreviewMerged openstack/nova master: Clean up allocations left by evacuation when deleting service  https://review.opendev.org/c/openstack/nova/+/77869614:20
opendevreviewMerged openstack/nova stable/wallaby: Reproduce bug 1944759  https://review.opendev.org/c/openstack/nova/+/81091214:20
gibilyarwood: hi! it seems there is a variant of https://bugs.launchpad.net/nova/+bug/1931702 in https://zuul.opendev.org/t/openstack/build/582935ad35a348cf89dcb25bdc3be0ea/logs But the guest console log at volume detach is different now https://zuul.opendev.org/t/openstack/build/582935ad35a348cf89dcb25bdc3be0ea/log/controller/logs/tempest_log.txt#544414:53
gibielodilles: ^^14:53
gibi"[   15.981709] virtio_blk virtio4: req.0:id 4 is not a head!" 14:53
gibilyarwood: does it ring a bell for you?14:54
lyarwoodgibi: no I've not seen that before tbh14:56
gibilyarwood: ack, thanks14:56
artom_bauzas, hey, I think the Ironic folks would be really happy if we made https://review.opendev.org/c/openstack/nova/+/813263 a review priority...15:02
*** artom_ is now known as artom15:02
sean-k-mooneyi see15:03
sean-k-mooneyi think should be safe although it raise the question about oter life cyle events liek power on power off and had/soft reboot15:04
artomsean-k-mooney, the Ironic patch?15:05
sean-k-mooneyyes15:05
artomYeah, I suppose it does, but from what I've seen, use of plug_vifs() is highly limited, so it's safe to make it a noop15:05
sean-k-mooneyno its not15:05
sean-k-mooneywe need to call it for the inial spawn15:05
artomsean-k-mooney, I mean, look at my review notes inline, and tell me if I've missed something :)15:06
sean-k-mooneywe do not need to call it in init_host for ironci15:06
sean-k-mooneybut it cant jsut be a noop without change the spwan workflow 15:06
sean-k-mooneywe use it on inital boot to ensure that the networkign if fully configured by the backend before we power on the ironic host15:07
artomsean-k-mooney, maybe you're thinking of a slightly differently named method?15:07
sean-k-mooneyno im not15:07
artomIn the compute manager, it's only called from _init_instance(), which is only called from init_host()15:08
artomThat's it, nothing on spawn15:08
sean-k-mooneycorrect its not15:08
sean-k-mooneybut we also call plug_vifs during spwan15:08
sean-k-mooneyso you cant just make plug_vifs a noop15:08
artomFrom where?15:09
sean-k-mooneyit will mean during spawn we will not actully set up the networking proerly they have hacked around this here https://review.opendev.org/c/openstack/nova/+/813263/3/nova/virt/ironic/driver.py#160615:09
sean-k-mooneyby starting to use _plug_vifs to actully invoke the ironic api15:09
sean-k-mooneyfor interface attach15:09
artomThat's just inlining what plug_vifs() used to do into attach(), no?15:10
bauzasartom: I can mark it as a Review-Priority for me15:10
* bauzas jumped into the unified limits series15:11
artombauzas, PTL's discretion and all that :) I was just making a request15:11
bauzasany core can set this flag15:12
bauzas... for the moment15:12
artomBut you're the core-iest of cores15:12
bauzasI'm about to write a doc change for it, hopefully tomorow15:12
bauzasartom: nah, as sean-k-mooney said, I'm just a "cat herder" or if you prefer, some French guy yelling in the wind15:12
gibisean-k-mooney, artom: I read that ironic related nova patch, I see that it is correct and does not affect spawn, but now I'm affraid that sean-k-mooney has things I'm missing15:13
artomMeow.15:13
artomgibi, you and me both15:13
gibiwe need more cats15:13
bauzasI have a dog15:13
gibithen you are out15:13
gibi:P15:13
bauzascats are selfish15:13
artomIonesco says dogs are cats15:13
sean-k-mooneygibi: im mostly uncofrotable with changing the meaing of plug_vifs to be honest15:13
artomHe also says that Socrates was a cat15:13
sean-k-mooneyim currently reviewing the spawn path15:14
artomsean-k-mooney, I don't think that's our call to make, every driver can do what they want15:14
bauzasartom: the only merit to cats is that they help to prove some theorem15:14
bauzasabout quantic nature15:14
artomOnly if they're in boxes15:15
sean-k-mooneyartom: its used here https://github.com/openstack/nova/blob/fded762f4df26ff5706438a66da33ff966f833c6/nova/virt/ironic/driver.py#L191015:16
sean-k-mooneywhich is used by the compute manger here https://github.com/openstack/nova/blob/fded762f4df26ff5706438a66da33ff966f833c6/nova/compute/manager.py#L259715:17
sean-k-mooneyin _build_resources15:17
gibisean-k-mooney: our virt driver interface has the plug_vif method but we only use that from the computa manager in init_host15:17
sean-k-mooneywhich is part of  _build_and_run_instance15:17
gibisean-k-mooney: that call is transformed out in the proposed patch15:17
artomsean-k-mooney, yeah, and that's been inlined here: https://review.opendev.org/c/openstack/nova/+/813263/3/nova/virt/ironic/driver.py#191915:17
gibisean-k-mooney: and that call paths is totaly ironic specific, libvirt virt driver does not call back to plug_vifs during spawn15:18
artomAFAICT, TheJulia did her homework :)15:18
sean-k-mooneyoh that  prepare_networks_before_block_device_mapping15:18
* TheJulia appears having been summoned15:18
sean-k-mooneygibi: well we do use it internally in the virt dirver i think in livemigration and maybe hard reboot15:19
sean-k-mooneybut perhaps not directly in spwan15:19
gibisean-k-mooney: not the virt driver interface15:19
sean-k-mooneygibi not the virt dirver interface not but the funciton in the dirver15:19
artomTheJulia, we're trying to convince sean-k-mooney you're plug_vifs() patch is correct :)15:19
artom*your15:19
TheJuliaoh, yes, it is correct as far as I've been able to navigate15:19
artomOh god, I'm one of them now15:19
TheJuliasince ironic handles all attachment management15:19
artomThe people who put apostrophe's in plural's and no apostrophe's in possessive's15:20
sean-k-mooneyTheJulia: it was the swan path i was concerned about i had not expanded the context lins areound https://review.opendev.org/c/openstack/nova/+/813263/3/nova/virt/ironic/driver.py#191915:20
sean-k-mooneyTheJulia: the change you made in prepare_networks_before_block_device_mapping will ensure we actully plug the vifs still on spwan 15:20
TheJuliaand due to that, and the duality use of attach_interfaces being present, it is entirely redundant and harmful behavior for the operators to experience with nova-computes running the ironic driver15:21
gibisean-k-mooney: I see15:21
artomTheJulia, what does plugging the vifs mean in an Ironic context, anyways? Calling out to a physical switch and setting vlans and stuff?15:21
sean-k-mooneyTheJulia: what i was really concerned about is regressing spawn such that the compute manger would not wait for the vifs to be configured on the network swtich berofre powering on the server15:22
sean-k-mooneybut it looks like that cant happen so ill +1 it shortly15:22
TheJuliaartom: recording there should be an attachment, that is only sent to neutron until once the states change to active15:22
TheJuliasean-k-mooney: those are persistant and managed through the workflow and neutron ml2 plugins15:22
TheJuliasean-k-mooney: but totally valid concern not knowing the rest of the mechanics15:23
sean-k-mooneyTheJulia: well i mean this is not something that ironic should really mange entrily on its own so jsut making sure we still have the correct mechamins in place on the nova side15:24
sean-k-mooneyaltough looking at that code path  we dont seam to be correctly waiting for the neutron external event in _plug_vifs15:25
sean-k-mooneyhttps://github.com/openstack/nova/blob/fded762f4df26ff5706438a66da33ff966f833c6/nova/virt/ironic/driver.py#L1492-L152515:25
sean-k-mooneywe are just callign the node.vif_attach api 15:26
TheJuliasean-k-mooney: it must because of a security lifecycle must be enforced15:26
sean-k-mooneyso this looks like there is an existing race15:26
TheJuliaand it knows the state of the lifecycle15:26
EugenMayerAnybody in here got novnc working with kolla when using TLS? TLS is working on all sub-systems except when using TLS. lyarwood it seems like they use a haproxy (i got told) which does the SSL offloading, which might be the reason it is not configured. But this would not explain the error message15:27
opendevreviewBalazs Gibizer proposed openstack/nova master: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81341915:27
TheJuliasean-k-mooney: on start, but if the vif recrods are already on file, on start it doesn't matter, the nova-compute spins for quite a long time.15:29
TheJuliafor running state, that is a separate path and that has been the case for a while, I think.15:30
TheJuliaso I think I grok sean-k-mooney's concerns, and just to be on the safe side, I'll go change my "test nova-y tings patch in the ironic repo to pull that vif plug patch in and just make sure that it passes happily again. I believe it did so before, but there is the BFV use case which is a little different15:50
opendevreviewAlexey Stupnikov proposed openstack/nova master: WIP: Test aborting queued live migration  https://review.opendev.org/c/openstack/nova/+/77625015:54
TheJuliaartom: that hash ring handling wip seems to work, which is a good sign. Likely just need to go see if the devstack plugin forces a rebalance... and maybe make it force a rebalance :)15:55
artomTheJulia, yeah, I need to look at it again and properly wrap my head around it15:55
TheJuliaartom: yeah, a little different by just reconciling "what is running/active" versuse explicit record checks for each instance, but I'd hate to trigger a few thousand extra DB queries upon rebalance15:57
TheJuliachanged https://review.opendev.org/c/openstack/ironic/+/813264 to run the vif plug change15:59
TheJuliasean-k-mooney: ^^ if the ironic bfv job passes, I suspect we're safe and happy for the time being15:59
sean-k-mooneyack tahnks16:03
opendevreviewBalazs Gibizer proposed openstack/nova master: Remove SESSION_CONFIGURED global from DB fixture  https://review.opendev.org/c/openstack/nova/+/81568916:27
opendevreviewBalazs Gibizer proposed openstack/nova master: Refactor Database fixture  https://review.opendev.org/c/openstack/nova/+/81569016:27
opendevreviewBalazs Gibizer proposed openstack/nova master: Fix interference in db unit test  https://review.opendev.org/c/openstack/nova/+/81473516:29
melwittgibi: just read your comments, I might be wrong but if I am then I don't understand why it's needed. I'll look at it some more16:32
gibimelwitt: I followed your suggestion and things are still passing, so I think you are right16:33
melwittoh ok16:33
gibiso you were right that I don't need to patch the per connection case16:34
melwittack16:34
EugenMayerlyarwood FYI - kolla supports tls for novnc but uses a haproxy as SSL offloaded and LB in front of it. My issues was an internal vs external VIP IP. So kolla has support for it18:00
lyarwoodcool cool18:01
opendevreviewLee Yarwood proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages  https://review.opendev.org/c/openstack/nova/+/81673818:34
opendevreviewLee Yarwood proposed openstack/nova master: nova-next: Drop NOVA_USE_SERVICE_TOKEN from subnode  https://review.opendev.org/c/openstack/nova/+/81674018:41
opendevreviewGustavo Santos proposed openstack/nova master: Reattach mdevs to guest on resume  https://review.opendev.org/c/openstack/nova/+/81537320:31
opendevreviewsean mooney proposed openstack/nova master: [WIP] Add extra tests for pinning with partial siblings  https://review.opendev.org/c/openstack/nova/+/81675822:07
opendevreviewMerged openstack/nova stable/wallaby: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81091323:30

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