| *** brinzhang has joined #openstack-nova | 00:24 | |
| *** brinzhang has quit IRC | 00:32 | |
| *** brinzhang has joined #openstack-nova | 01:00 | |
| *** brinzhang has quit IRC | 01:05 | |
| *** igordc has quit IRC | 01:24 | |
| *** huaqiang has joined #openstack-nova | 01:55 | |
| *** tetsuro has joined #openstack-nova | 02:01 | |
| *** brinzhang has joined #openstack-nova | 02:08 | |
| *** brinzhang_ has joined #openstack-nova | 02:09 | |
| *** brinzhang_ has quit IRC | 02:10 | |
| *** brinzhang_ has joined #openstack-nova | 02:10 | |
| *** brinzhang_ has joined #openstack-nova | 02:12 | |
| *** brinzhang has quit IRC | 02:13 | |
| *** eharney has quit IRC | 02:23 | |
| *** markvoelker has joined #openstack-nova | 02:29 | |
| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Retrun 400 if invalid query parameters are specified https://review.opendev.org/670440 | 02:36 |
|---|---|---|
| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add a live migration regression test https://review.opendev.org/641200 | 02:37 |
| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add database schema upgrade check https://review.opendev.org/667047 | 02:38 |
| *** rcernin has quit IRC | 02:45 | |
| *** rcernin has joined #openstack-nova | 02:47 | |
| *** bhagyashris has joined #openstack-nova | 02:49 | |
| *** ricolin_ has joined #openstack-nova | 03:06 | |
| *** psachin has joined #openstack-nova | 03:31 | |
| *** psachin has quit IRC | 03:34 | |
| *** tetsuro has quit IRC | 03:37 | |
| *** psachin has joined #openstack-nova | 03:37 | |
| *** psachin has quit IRC | 03:55 | |
| *** udesale has joined #openstack-nova | 03:59 | |
| *** brinzhang has joined #openstack-nova | 04:04 | |
| *** tetsuro has joined #openstack-nova | 04:06 | |
| *** brinzhang_ has quit IRC | 04:07 | |
| alex_xu | sean-k-mooney: kashyap a question for https://review.opendev.org/#/c/670189/, whether we will break the guest if change the machine type after upgrade. | 04:21 |
| *** Luzi has joined #openstack-nova | 05:06 | |
| *** brtknr has quit IRC | 05:17 | |
| *** brtknr has joined #openstack-nova | 05:19 | |
| *** whoami-rajat has joined #openstack-nova | 05:22 | |
| *** jaosorior has joined #openstack-nova | 05:26 | |
| *** tetsuro has quit IRC | 05:30 | |
| *** sridharg has joined #openstack-nova | 05:42 | |
| *** ratailor has joined #openstack-nova | 05:47 | |
| *** ratailor_ has joined #openstack-nova | 05:50 | |
| *** ratailor has quit IRC | 05:52 | |
| *** huaqiang has quit IRC | 06:00 | |
| *** mdbooth_ has joined #openstack-nova | 06:00 | |
| *** mdbooth has quit IRC | 06:03 | |
| *** takashin has quit IRC | 06:04 | |
| *** brinzhang_ has joined #openstack-nova | 06:16 | |
| *** brinzhang has quit IRC | 06:19 | |
| openstackgerrit | pengyuesheng proposed openstack/os-vif master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/672857 | 06:19 |
| *** dpawlik has joined #openstack-nova | 06:27 | |
| *** brinzhang_ has quit IRC | 06:28 | |
| *** mkrai has joined #openstack-nova | 06:36 | |
| *** tetsuro has joined #openstack-nova | 06:38 | |
| *** maciejjozefczyk has joined #openstack-nova | 06:42 | |
| *** ttsiouts has joined #openstack-nova | 06:56 | |
| *** slaweq has joined #openstack-nova | 06:58 | |
| *** janki has joined #openstack-nova | 07:02 | |
| *** brinzhang has joined #openstack-nova | 07:05 | |
| *** tesseract has joined #openstack-nova | 07:08 | |
| *** rcernin has quit IRC | 07:11 | |
| *** rpittau|afk is now known as rpittau | 07:11 | |
| *** tssurya has joined #openstack-nova | 07:14 | |
| *** tetsuro has quit IRC | 07:17 | |
| *** bhagyashris has quit IRC | 07:19 | |
| *** ttsiouts has quit IRC | 07:25 | |
| *** pcaruana has joined #openstack-nova | 07:31 | |
| kashyap | alex_xu: Morning, will check | 07:32 |
| *** jchhatbar has joined #openstack-nova | 07:34 | |
| *** janki has quit IRC | 07:38 | |
| *** brault has joined #openstack-nova | 07:38 | |
| *** jangutter has joined #openstack-nova | 07:38 | |
| *** arxcruz|off is now known as arxcruz | 07:38 | |
| *** mdbooth has joined #openstack-nova | 07:39 | |
| *** mdbooth_ has quit IRC | 07:41 | |
| kashyap | alex_xu: On that machine type question for Windows -- | 07:43 |
| kashyap | alex_xu: ... I don't quite parse your question. The answer is "it depends" | 07:43 |
| kashyap | Because, if the operator knowingly updated the machine type, then there won't be any problems. But if their Windows+App was running 'pc' and was "suddenly" changed to 'q35', then there _might_ be issues depending on what the application expects | 07:44 |
| *** tetsuro has joined #openstack-nova | 07:45 | |
| alex_xu | kashyap: sorry, I didn't describe clearly | 07:46 |
| alex_xu | kashyap: with that patch, we changed the machine_type from q35 to pc for the compute node didn't set any machine type explicitly | 07:46 |
| *** jchhatbar has quit IRC | 07:46 | |
| kashyap | alex_xu: You changed it in nova.conf, and then stop + started the windows guest? | 07:48 |
| alex_xu | kashyap: emm...I thougth the windows guest os will complain for the license. Do you mean the APP in the guest windows os depending on the machine type? | 07:48 |
| alex_xu | kashyap: yes | 07:48 |
| kashyap | alex_xu: Hmm, let me check with another QEMU guy | 07:49 |
| *** tetsuro has quit IRC | 07:50 | |
| *** jchhatbar has joined #openstack-nova | 07:50 | |
| *** lpetrut has joined #openstack-nova | 07:51 | |
| alex_xu | kashyap: sorry, I mean no value for CONF.libvirt.machine_type. In S release, it is pc. But we changed the default machine type in the code for T release, after upgrade, a stop/start will change the instance to q35 machine type. | 07:53 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Verify NOVA_USE_SERVICE_TOKEN=True in the Nova gate https://review.opendev.org/673227 | 07:54 |
| kashyap | alex_xu: Isn't your question same as: if you boot a hard disk with Windows from PC1 to PC2, will it boot? :-) | 07:55 |
| kashyap | alex_xu: And did the instance boot or not, in your test? | 07:55 |
| alex_xu | kashyap: yes, i think so | 07:55 |
| kashyap | alex_xu: Then, isn't it a question for Microsoft? :-) | 07:56 |
| alex_xu | hah | 07:56 |
| *** bhagyashris has joined #openstack-nova | 07:56 | |
| *** ttsiouts has joined #openstack-nova | 07:57 | |
| *** ircuser-1 has joined #openstack-nova | 07:57 | |
| kashyap | alex_xu: https://support.microsoft.com/en-us/help/20530/windows-10-reactivating-after-hardware-change | 07:57 |
| kashyap | So: | 07:58 |
| kashyap | [quote] | 07:58 |
| kashyap | When installing Windows 10, the digital license associates itself with your device's hardware. If you make significant hardware changes on your device, such as replacing your motherboard, Windows will no longer find a license that matches your device, and you’ll need to reactivate Windows to get it up and running. | 07:58 |
| kashyap | [/quote] | 07:58 |
| kashyap | peterx: So the answer is, yes, it will affect -- because changing machine type is similar to changing your motherboard | 07:59 |
| alex_xu | kashyap: so I'm thinking whether we should have a release upgrade note for the operator running windows at least | 07:59 |
| *** jaosorior has quit IRC | 07:59 | |
| alex_xu | warning them the machine type is changed, if you don't want get the trouble with that, update CONF.libvirt.machine_type to q35? | 08:00 |
| kashyap | "not trouble", but we should be explicit - that you might have to reactivate licensing keys | 08:00 |
| kashyap | alex_xu: You say "we" changed default machine type in the code for T release -- do you mean Intel's own OpenStack variant? | 08:02 |
| kashyap | Or by "we" are you referring to upstream? | 08:02 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: Get rid of args to RBDDriver.__init__() https://review.opendev.org/668564 | 08:02 |
| alex_xu | kashyap: referring to upstream | 08:02 |
| alex_xu | intel don't have oepnstack variant | 08:02 |
| kashyap | alex_xu: No, we didn't change upstream machine type - what makes you say so? | 08:02 |
| kashyap | alex_xu: In that patch, for x86|i386 it is still 'pc' -- https://review.opendev.org/#/c/670189/14/nova/virt/libvirt/utils.py | 08:03 |
| alex_xu | kashyap: sorry, no the upstream, the patch https://review.opendev.org/670189 changed | 08:03 |
| kashyap | alex_xu: Which exactly line are you referring to? | 08:03 |
| kashyap | alex_xu: Ah, hang on. | 08:04 |
| kashyap | That patch was fixing a bad assumption | 08:04 |
| alex_xu | kashyap: https://review.opendev.org/#/c/670189/14/nova/virt/libvirt/host.py@745 | 08:05 |
| kashyap | alex_xu: The second point in the commit message only says, there is an "initiative to update to q35", but that has _not_ landed yet (not even the spec) | 08:05 |
| alex_xu | emm... | 08:05 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove native LUKS compat code https://review.opendev.org/669121 | 08:05 |
| kashyap | alex_xu: That line (745) was only removing an assumption. It is not changing anything. | 08:06 |
| alex_xu | ah.... | 08:06 |
| kashyap | aspiers: When you're about, some discussion in the scrollback on that harden getDomainCapabilities() patch. | 08:06 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: libvirt: flatten rbd images when unshelving an instance https://review.opendev.org/668123 | 08:07 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: DNM - Test rbd unshelve fix on stable queens https://review.opendev.org/668142 | 08:07 |
| *** ralonsoh has joined #openstack-nova | 08:08 | |
| tssurya | brinzhang: I have a question regarding the -1 you have https://review.opendev.org/#/c/666792/ and https://review.opendev.org/#/c/645611/, please reply whenever you have time | 08:08 |
| alex_xu | kashyap: ah, I know where I missunderstand now | 08:09 |
| *** aojea has joined #openstack-nova | 08:10 | |
| kashyap | :-) | 08:10 |
| kashyap | alex_xu: And for the record, ignore my (and yours?) "we should be explicit" on the warning about license keys -- no warning is required in this case :-) | 08:11 |
| alex_xu | yes, nothing required | 08:12 |
| kashyap | alex_xu: I added a summary of our discussion here, let me know if that looks good: https://review.opendev.org/#/c/670189/14 | 08:14 |
| alex_xu | thanks | 08:14 |
| *** ivve has joined #openstack-nova | 08:15 | |
| *** aojea has quit IRC | 08:17 | |
| brinzhang | tssurya: about https://review.opendev.org/#/c/666792/, beacuse of the power-update not support for the nova CLI, I donot understand why need to add this change. | 08:18 |
| brinzhang | tssurya: Even if you don't add 2.75 microversion, will it affect the functionality of novaclient? | 08:18 |
| tssurya | brinzhang: if I don't update the client version, I cannot use the server side changes | 08:19 |
| tssurya | that | 08:19 |
| tssurya | is why we update | 08:19 |
| brinzhang | If it's true, I think my understanding is biased, I will remove that -1. thanks | 08:19 |
| tssurya | also as you can see here: https://review.opendev.org/#/c/666792/3/novaclient/tests/unit/v2/test_shell.py@4278 , this is why we add "2.75" to the list of versions that do not need change on the client side | 08:20 |
| tssurya | that is also why we have no tests | 08:20 |
| tssurya | brinzhang: thanks , next time you have a question feel free to just ask without having to give a vote :) | 08:20 |
| brinzhang | Yeah, because of on weekends, so... I will care :P | 08:21 |
| brinzhang | tssurya: If we not add this change, it will be raise 404? or anonther? | 08:24 |
| tssurya | brinzhang: https://docs.openstack.org/python-novaclient/latest/contributor/microversions.html | 08:27 |
| tssurya | in my particular case (https://review.opendev.org/#/c/645611/9/nova/api/openstack/compute/server_external_events.py@72) its a schema invalidation so yes a 404 | 08:29 |
| tssurya | but the main point is to bump the versions serially, like we shouldn't be doing 2.76 and just leave 2.75 on the client because it doesn't have any "code changes" | 08:30 |
| *** tkajinam has quit IRC | 08:30 | |
| tssurya | ^ its mentioned in the docs | 08:30 |
| *** avolkov has joined #openstack-nova | 08:31 | |
| brinzhang | Yeah, I know this, I think it will be raise 406. | 08:31 |
| brinzhang | { | 08:32 |
| brinzhang | "computeFault":{ | 08:32 |
| brinzhang | "message": "Version 2.78 is not supported by the API. Minimum is 2.1 and maximum is 2.76.", | 08:32 |
| brinzhang | "code": 406 | 08:32 |
| brinzhang | } | 08:32 |
| brinzhang | } | 08:32 |
| kashyap | alex_xu: Thank you for ACKing, much appreciated. | 08:32 |
| tssurya | brinzhang: no the server supports 2.75, we are trying to make the client support it as well | 08:33 |
| *** kdean has quit IRC | 08:33 | |
| *** brtknr has quit IRC | 08:33 | |
| kashyap | stephenfin: Hi, when you're about, can you please have a gander at this: https://review.opendev.org/#/c/670189/ (libvirt: harden Host.get_domain_capabilities()) | 08:33 |
| kashyap | stephenfin: Already has +2 from Alex. And it's useful for two features, one for SEV, the other for the Secure Boot thing | 08:34 |
| *** brtknr has joined #openstack-nova | 08:35 | |
| *** tetsuro has joined #openstack-nova | 08:43 | |
| alex_xu | kashyap: np | 08:44 |
| *** janki has joined #openstack-nova | 08:45 | |
| *** jchhatbar has quit IRC | 08:45 | |
| *** mkrai has quit IRC | 08:46 | |
| *** jaosorior has joined #openstack-nova | 08:46 | |
| *** panda has quit IRC | 08:47 | |
| *** tetsuro has quit IRC | 08:47 | |
| *** panda has joined #openstack-nova | 08:48 | |
| brinzhang | tssurya: about https://review.opendev.org/#/c/645611/, replyed with comment. | 08:50 |
| *** derekh has joined #openstack-nova | 08:53 | |
| *** lpetrut has quit IRC | 08:58 | |
| *** tesseract has quit IRC | 08:58 | |
| *** zhouyao has joined #openstack-nova | 09:06 | |
| *** mkrai has joined #openstack-nova | 09:07 | |
| *** jchhatbar has joined #openstack-nova | 09:10 | |
| *** janki has quit IRC | 09:10 | |
| *** ccamacho has joined #openstack-nova | 09:13 | |
| *** trident has quit IRC | 09:16 | |
| *** trident has joined #openstack-nova | 09:17 | |
| *** tesseract has joined #openstack-nova | 09:20 | |
| *** altlogbot_1 has quit IRC | 09:24 | |
| *** ksdean has joined #openstack-nova | 09:24 | |
| *** altlogbot_1 has joined #openstack-nova | 09:25 | |
| *** ricolin_ has quit IRC | 09:29 | |
| *** takashin has joined #openstack-nova | 09:34 | |
| *** takashin has left #openstack-nova | 09:36 | |
| *** cdent has joined #openstack-nova | 09:37 | |
| aspiers | kashyap: here | 09:44 |
| kashyap | aspiers: Hi, go straight to my update in the Gerrit change. | 09:44 |
| kashyap | aspiers: (Saves you time from reading IRC scrollback) | 09:45 |
| aspiers | OK | 09:45 |
| aspiers | kashyap: not sure if there's a question for me? looks like it's all clarified? | 09:46 |
| kashyap | aspiers: Yeah, no more question. Was more of an FYI | 09:48 |
| aspiers | kashyap: OK thanks. BTW I need your review on https://review.opendev.org/#/c/673151/ more than anyone else's :) | 09:48 |
| aspiers | That ties to the scrollback I wrote on Sat | 09:48 |
| kashyap | aspiers: Will do. First trying to write some code to parse getDomainCapabilities() for 'efi' bits :D | 09:48 |
| * kashyap just finished shaving this yak: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 | 09:49 | |
| openstack | bugzilla.redhat.com bug 1733940 in libvirt "getDomainCapabilities() does not report all available OVMF firmware binaries" [Unspecified,New] - Assigned to libvirt-maint | 09:49 |
| kashyap | aspiers: What scrollback from Sat? I missed | 09:49 |
| aspiers | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-27.log.html#t2019-07-27T18:15:17 | 09:49 |
| kashyap | aspiers: BTW, funnily enough, I have a "vested interest" to review that patch. Why? | 09:50 |
| kashyap | aspiers: ... I too have a need for domain capabilities for 'q35' for Secure Boot | 09:51 |
| kashyap | (Secure Boot for KVM/QEMU _mandates_ 'q35') | 09:51 |
| kashyap | aspiers: I will get to this interesting patch today. | 09:51 |
| aspiers | kashyap: Yeah, this is not a huge coincidence, since SEV mandates UEFI via OVMF | 09:52 |
| aspiers | lack of UEFI is probably why my SEV guests are currently unresponsive | 09:52 |
| kashyap | Ah, I see | 09:53 |
| kashyap | aspiers: Aside, if you don't mind holding your nose: https://kashyapc.fedorapeople.org/Create-a-SecureBoot-enabled-VM.bash | 09:53 |
| aspiers | although it does not require secure boot AFAIK | 09:54 |
| kashyap | Right | 09:54 |
| aspiers | are there docs for UEFI boot in nova? | 09:54 |
| kashyap | Afraid, not much I guess | 09:54 |
| openstackgerrit | Dongcan Ye proposed openstack/nova master: Fix wrong huge pages in doc https://review.opendev.org/673252 | 09:54 |
| * aspiers looks at https://blueprints.launchpad.net/nova/+spec/boot-from-uefi | 09:55 | |
| kashyap | aspiers: Do you have a few more minutes to chat on a related topic? | 09:55 |
| aspiers | yes | 09:55 |
| * kashyap types | 09:56 | |
| kashyap | aspiers: So I need to parse that 'efi' bit on line-3: http://paste.openstack.org/show/755057/ | 09:58 |
| kashyap | aspiers: I'm searching through the SEV series, to 'Depend On' a patch that parses surrounding bits from getDomainCapabilities() | 09:59 |
| kashyap | aspiers: Probably somewhere surrounding here? https://review.opendev.org/#/c/640483/3/nova/virt/libvirt/config.py | 10:01 |
| * aspiers is looking | 10:02 | |
| kashyap | (After I add the config class LibvirtConfigDomainCapsFirmwareEFI() or something like that) | 10:02 |
| *** bhagyashris has quit IRC | 10:02 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: Use os-brick locking for volume attach and detach https://review.opendev.org/614190 | 10:03 |
| aspiers | kashyap: I don't think there is any unmerged patch you need to depend on | 10:03 |
| aspiers | kashyap: that patch you linked was merged ages ago | 10:04 |
| kashyap | aspiers: Yep, just realized | 10:04 |
| aspiers | kashyap: well, maybe https://review.opendev.org/#/c/673151/3 | 10:05 |
| aspiers | which is the one I'm asking you to look at anyway :) | 10:06 |
| kashyap | aspiers: Yeah, I have it open, and have half read the commit message, while I got 3 pings :D | 10:06 |
| aspiers | hacking on nova feels a bit like wandering around a vast desert, and the experience of randomly bumping into someone else in the same vicinity is equally surprising | 10:07 |
| kashyap | aspiers: Will spend time on it tooday, definitely | 10:07 |
| aspiers | kashyap: just realised that maybe the subject of that commit is misleading | 10:07 |
| aspiers | it's enhancing the parsing of *capabilities* not domain caps | 10:08 |
| aspiers | the change regarding domain caps is that getDomCaps API gets called more often as a result (for the canonical machine types in addition to the default machine type for the arch) | 10:08 |
| kashyap | aspiers: Hehe, mind you, we're in a mini desert in the "Cosmos of Nova" -- we're in HDD (Hypervisor Driver Desert) | 10:09 |
| aspiers | If I change (only) a commit message and rebase the stuff on top, will Gerrit/Zuul re-run all the CI on an identical git tree? | 10:09 |
| aspiers | true X-D | 10:09 |
| kashyap | lyarwood: --^ | 10:10 |
| kashyap | aspiers: I _think_ rebase will re-run the entire world's CI :-( But I have a faint voice in the head saying: "that has changed" | 10:10 |
| aspiers | I fear you might be right | 10:11 |
| aspiers | kashyap: so are there *any* docs on how to do UEFI boot in nova? | 10:11 |
| aspiers | kashyap: surely there must be another way to find out than reading merged gerrit patches | 10:11 |
| aspiers | even the release note is useless | 10:11 |
| kashyap | aspiers: Not that I know of. I don't think not even in the config help text I guess. | 10:12 |
| kashyap | aspiers: Does this count? -- https://opendev.org/openstack/nova-specs/src/branch/master/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst | 10:12 |
| kashyap | :D | 10:12 |
| kashyap | The part in the "Problem description" can account for _some_ documentation. /me ducks | 10:12 |
| aspiers | hah | 10:14 |
| aspiers | for SEV, I felt that if I didn't include insanely comprehensive docs with the patches, I would have no chance of getting it accepted | 10:14 |
| aspiers | maybe that was a misperception | 10:14 |
| aspiers | but I don't regret writing them, of course | 10:14 |
| aspiers | kashyap: BTW http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html is a nicer rendering of the same | 10:15 |
| kashyap | Ah, thank you | 10:16 |
| kashyap | aspiers: On docs, don't worry -- if you've improved the 'void' (i.e. non-existent docs), then it definitely is worth accepting. | 10:17 |
| kashyap | I don't guess anyone would have the gall to "not accept" those. | 10:18 |
| kashyap | (Without a damn good reason) | 10:18 |
| openstackgerrit | Brin Zhang proposed openstack/nova master: Add delete_on_termination to volume-attach API https://review.opendev.org/673133 | 10:18 |
| aspiers | kashyap: hah, I know you weren't doing this, but given the effort I spent on them, if anyone described the docs I've submitted as "they improved the void", that would feel like a slap in the face X-D | 10:19 |
| aspiers | kashyap: check out https://review.opendev.org/#/c/666616/22/doc/source/admin/configuration/hypervisor-kvm.rst | 10:19 |
| aspiers | and then press ']' twice for the other docs | 10:19 |
| kashyap | aspiers: Yeah, sorry, as you guessed - I didn't target that at you at all. Was saying more in general | 10:19 |
| kashyap | If anyone provides any docs that _improves_ the status quo, accept it, no ifs and buts. | 10:20 |
| kashyap | aspiers: Oh, the ']' trick, I didn't know; thanks! | 10:20 |
| aspiers | Well yeah, but if a new feature is submitted with sub-par docs, I'd argue that's *worsening* the docs | 10:20 |
| aspiers | kashyap: press '?' for all shortcuts | 10:20 |
| aspiers | they're almost all worth memorising | 10:21 |
| kashyap | aspiers: Yeah, fugreed. BTW, excellent docs there, as usual: https://review.opendev.org/#/c/666616/22/doc/source/admin/configuration/hypervisor-kvm.rst | 10:21 |
| kashyap | aspiers: I say not many developers have the discipline to write solid docs. | 10:21 |
| aspiers | It's a shame. It's not the most fun thing to do, but damn is it satisfying once they're done | 10:22 |
| aspiers | especially when all the subsequent questions you get can be answered with RTFM ;-) | 10:22 |
| kashyap | Yes. Many many developers forget to realize that their "beautiful code" is not worth a damn if they don't spend a decent chunk of time describing the feature | 10:22 |
| kashyap | Not a curt, crappy document. But a good one, that makes you feel "pain" when you write. And after some rounds of editing. | 10:23 |
| *** jaosorior has quit IRC | 10:23 | |
| kashyap | aspiers: BTW, I'll of course be writing a document for Sec Boot, collecting artefacts here: https://kashyapc.fedorapeople.org/Secure-Boot-for-KVM-QEMU-guests/ | 10:24 |
| aspiers | great | 10:24 |
| openstackgerrit | Huachang Wang proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | 10:25 |
| aspiers | so, in the absence of TFM, please can you tell me how to configure UEFI boot? | 10:25 |
| aspiers | even your SB spec problem description doesn't really cover it AFAICS | 10:25 |
| aspiers | https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/boot-from-uefi.html sort of does | 10:26 |
| aspiers | is hw_firmware_type=uefi enough? | 10:26 |
| aspiers | oh I found it! https://docs.openstack.org/glance/pike/admin/troubleshooting.html#launch-instances-with-uefi | 10:26 |
| *** brinzhang_ has joined #openstack-nova | 10:27 | |
| aspiers | kashyap: unfortunately I am now being bitten by your decision not to +1 https://review.opendev.org/#/c/348394/, since I need this working on SLES 12 ... | 10:27 |
| aspiers | I think it could have been a reasonable stop-gap solution | 10:29 |
| *** huaqiang has joined #openstack-nova | 10:29 | |
| kashyap | aspiers: Oh, speaking of which! | 10:30 |
| aspiers | TBH I think it would still make sense to merge that, even at this late stage | 10:30 |
| kashyap | Can you check with Dirk & co. on any progress on getting the JSON file descriptor files as part of SLES's EDK2/OVMF package? | 10:30 |
| kashyap | I've written the patch for Fedora: | 10:30 |
| *** brtknr has quit IRC | 10:30 | |
| aspiers | kashyap: I thought we connected you with Jim Fehlig on that front? | 10:30 |
| *** brinzhang has quit IRC | 10:30 | |
| aspiers | he's our OVMF expert | 10:31 |
| kashyap | Yes, we did. I'll revive the thread with the example | 10:31 |
| aspiers | and in fact he's the one who yesterday suggested that my SEV guest is broken because it wasn't booted with UEFI | 10:31 |
| kashyap | See this example: https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8 | 10:31 |
| kashyap | Please point it to Jim. Or I'll revive that thread post Denver with some more info | 10:32 |
| *** brtknr has joined #openstack-nova | 10:32 | |
| kashyap | aspiers: I've filed similar RFE bugs for Debian and Ubuntu, too | 10:32 |
| aspiers | I've found the old mail thread | 10:32 |
| aspiers | May 8-10 | 10:32 |
| *** zhouyao has quit IRC | 10:33 | |
| kashyap | Right | 10:33 |
| *** brtknr has quit IRC | 10:34 | |
| *** ksdean has quit IRC | 10:34 | |
| *** kaisers has quit IRC | 10:35 | |
| sean-k-mooney | kashyap: by the way changing the motherboard does not always cause windows to be reactivated or require reactivation. it depend on if its a retail copy or oem. oem copies are tied to the machine they are booted on retail are not. | 10:35 |
| sean-k-mooney | *installed on | 10:35 |
| *** brtknr has joined #openstack-nova | 10:35 | |
| *** brtknr has quit IRC | 10:36 | |
| kashyap | What is the difference between "retail copy" and "OEM"? | 10:36 |
| sean-k-mooney | if the frimware/system uuid does not change i think it would not triger reactivation of windows licenes | 10:36 |
| sean-k-mooney | kashyap: its a diffenet EULA and teh activation key is from a diffferent pool onther then that they are identical | 10:37 |
| sean-k-mooney | oem key are cheaper | 10:37 |
| sean-k-mooney | having said that for openstack | 10:37 |
| sean-k-mooney | you would be useing datacenter volume licences | 10:37 |
| kashyap | That sounds incredibly messy | 10:37 |
| kashyap | Regardless, I think it robust to _assume_ it changes | 10:37 |
| *** jawad_axd has joined #openstack-nova | 10:38 | |
| * kashyap --> bbiab | 10:39 | |
| sean-k-mooney | well it makes sense. they assume if you buy windows your self. e.g. a retail copy that you might be building your own pc and might upgrade it | 10:39 |
| sean-k-mooney | but if you go windows with your pc e.g. form dell its an oem license | 10:39 |
| aspiers | kashyap: what I see from my SEV machine is lacking some of the bits you see: http://paste.openstack.org/show/755058/ | 10:40 |
| aspiers | kashyap: is my libvirt or qemu old or something? | 10:40 |
| *** yaawang has quit IRC | 10:40 | |
| sean-k-mooney | and they assume since you baugt prebuilt your not going to swap out the motherboard, you can buy oem license and they are cheaper but its one of the limitations that come with the cost reduction | 10:40 |
| *** cdent has quit IRC | 10:41 | |
| sean-k-mooney | but in either case its against the windows desktop license agreement to use either for systems that are purly virtualised | 10:41 |
| sean-k-mooney | to run windows permently in a vm you need a different licnese (volume licenseing or datacenter) which have different activation critia | 10:43 |
| *** brtknr has joined #openstack-nova | 10:45 | |
| *** mkrai has quit IRC | 10:57 | |
| *** mkrai has joined #openstack-nova | 10:57 | |
| *** brtknr has quit IRC | 11:04 | |
| *** brtknr has joined #openstack-nova | 11:05 | |
| *** brtknr has quit IRC | 11:06 | |
| *** brtknr has joined #openstack-nova | 11:06 | |
| *** brtknr has quit IRC | 11:07 | |
| *** lpetrut has joined #openstack-nova | 11:07 | |
| *** brtknr has joined #openstack-nova | 11:08 | |
| *** smrcascao has quit IRC | 11:17 | |
| *** brtknr has quit IRC | 11:20 | |
| *** brtknr has joined #openstack-nova | 11:21 | |
| *** brtknr has quit IRC | 11:22 | |
| *** brtknr has joined #openstack-nova | 11:23 | |
| *** brtknr has quit IRC | 11:23 | |
| *** brtknr has joined #openstack-nova | 11:24 | |
| *** brtknr has quit IRC | 11:24 | |
| *** brtknr has joined #openstack-nova | 11:25 | |
| *** udesale has quit IRC | 11:26 | |
| *** jaypipes has joined #openstack-nova | 11:26 | |
| sean-k-mooney | the nova-next job is ment to test thing that we intend to make the default in a subsequent release right | 11:28 |
| sean-k-mooney | or is it for something else? | 11:29 |
| sean-k-mooney | it looks like it was orignially for placmenet and cells testing when they were optional and for stien was the first full python 3 job? so it evelovs to test the futrue state we expect nova to run in | 11:31 |
| sean-k-mooney | the reason im asking it related to a donwstream converstation about service tokens | 11:33 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L18-L42 | 11:33 |
| sean-k-mooney | it look like we have not considerd service tokens to be experimental since 2017 | 11:33 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion 2.75: Add 'power-update' external event https://review.opendev.org/645611 | 11:33 |
| sean-k-mooney | and nova-next has been running with them for over 2 years | 11:33 |
| sean-k-mooney | lyarwood has a patch https://review.opendev.org/#/c/673226/1 to enable them by defualt in devstack but im wondering should we just enable it by default in nova | 11:34 |
| *** jaosorior has joined #openstack-nova | 11:34 | |
| sean-k-mooney | efried: johnthetubaguy bauzas ^ any input on that? | 11:34 |
| *** derekh has quit IRC | 11:43 | |
| *** cdent has joined #openstack-nova | 11:46 | |
| openstackgerrit | Huachang Wang proposed openstack/nova master: doc: correct the information of 'cpu_map' https://review.opendev.org/673272 | 11:46 |
| *** bbowen has joined #openstack-nova | 11:49 | |
| *** eharney has joined #openstack-nova | 12:00 | |
| aspiers | kashyap: let me know when you're back | 12:09 |
| aspiers | kashyap: I'm changing the patch title to "Track libvirt host/domain capabilities for multiple machine types" | 12:09 |
| *** mkrai has quit IRC | 12:13 | |
| *** artom has joined #openstack-nova | 12:20 | |
| *** mvkr has quit IRC | 12:22 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Multiple API cleanup changes https://review.opendev.org/666889 | 12:27 |
| aspiers | kashyap, efried: I noticed that Element.getchildren() is deprecated since lxml 2.7 and our requirements has >= 3.4.1 - would it make sense to submit a patch getting rid of those? | 12:30 |
| *** ricolin_ has joined #openstack-nova | 12:30 | |
| *** Conqueror has joined #openstack-nova | 12:31 | |
| *** ivve has quit IRC | 12:34 | |
| sean-k-mooney | aspiers: you are ment to just do list(element) now right to get the childeren | 12:34 |
| aspiers | sean-k-mooney: yes I know | 12:35 |
| aspiers | sean-k-mooney: my new code is already doing that | 12:35 |
| sean-k-mooney | i guess iter(element) should work as well | 12:35 |
| aspiers | just "for child in parent:" works fine | 12:35 |
| sean-k-mooney | ah yes | 12:35 |
| sean-k-mooney | personally i prefer using xpath expressions | 12:35 |
| aspiers | that's a different use case | 12:35 |
| sean-k-mooney | proably but it really depends on what your doing int he body of that for | 12:37 |
| kashyap | aspiers: Sorry, wasn't paying close attention | 12:37 |
| kashyap | aspiers: On that patch from Dirk, it's not only SLES, even CentOS is affected -- https://bugs.launchpad.net/nova/+bug/1825386 | 12:38 |
| openstack | Launchpad bug 1825386 in OpenStack Compute (nova) "Nova is looking for OVMF file no longer provided by CentOS 7.6" [Undecided,New] | 12:38 |
| *** ratailor_ has quit IRC | 12:38 | |
| kashyap | aspiers: (And yes, the new patch title is far more accurate; thank you) | 12:38 |
| aspiers | let's see how Gerrit handles the rewording | 12:39 |
| kashyap | aspiers: Now looking at your pastebin | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Track libvirt host/domain capabilities for multiple machine types https://review.opendev.org/673151 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Add <launchSecurity> and <driver iommu='on' /> to config.py https://review.opendev.org/636318 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565 | 12:39 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616 | 12:39 |
| sean-k-mooney | aspiers: i like to use xpath for thinks like parseing the support device model enum. "/enum[@name='modelType']/value/text()" is much cleaner then looping over the child of my child that is a enm with a name atribute and then extraging alls its childerns text values | 12:42 |
| aspiers | sean-k-mooney: yes but it depends on the context. config.py already has a top-down tree-based approach to iterating so in that context xpath makes no sense | 12:42 |
| sean-k-mooney | well im planning to use it there | 12:43 |
| sean-k-mooney | and if we used xpath in config.py more liberally it would be much shorter then it currently is | 12:43 |
| aspiers | maybe | 12:43 |
| aspiers | sean-k-mooney: feel free to add me to the review | 12:43 |
| sean-k-mooney | https://review.opendev.org/#/c/666915/6/nova/virt/libvirt/config.py@182 | 12:43 |
| kashyap | aspiers: On your pastebin (http://paste.openstack.org/show/755058/): you lack the 'efi' bit because, (a) old version; (b) your EDK2/OVMF package doesn't yet have these files: | 12:44 |
| kashyap | /usr/share/qemu/firmware | 12:44 |
| kashyap | /usr/share/qemu/firmware/40-edk2-ovmf-x64-sb-enrolled.json | 12:44 |
| kashyap | /usr/share/qemu/firmware/50-edk2-ovmf-x64-sb.json | 12:44 |
| kashyap | /usr/share/qemu/firmware/60-edk2-ovmf-x64.json | 12:44 |
| kashyap | --- | 12:44 |
| aspiers | kashyap: /usr/share/qemu/firmware doesn't exist at all | 12:45 |
| sean-k-mooney | i dont see that on ubunut | 12:45 |
| kashyap | aspiers: Right - it doesn't exist on those yet. Hence these RFEs I filed for Debian and Ubuntu: | 12:46 |
| kashyap | aspiers: It is part of QEMU 4.1 (coming next month) - merged in Git. | 12:46 |
| kashyap | The files. | 12:46 |
| aspiers | ouch, 2.11.2 here | 12:46 |
| kashyap | (But each distro should ship a variant of those files that matches with their EDK2/OVMF.) | 12:46 |
| sean-k-mooney | i have it in a different location on debian | 12:47 |
| kashyap | sean-k-mooney: The JSON files don't exist yet on Debian | 12:47 |
| sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fs | 12:47 |
| sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fd | 12:47 |
| *** mriedem has joined #openstack-nova | 12:47 | |
| aspiers | sean-k-mooney: that's not the json files | 12:47 |
| aspiers | that's the blobs | 12:47 |
| kashyap | sean-k-mooney: We're talking about .json files | 12:47 |
| sean-k-mooney | oh the json file is seperate form the firmware image | 12:47 |
| *** cdent has quit IRC | 12:47 | |
| kashyap | Here are the RFEs I filed for Debian/Ubuntu: | 12:48 |
| kashyap | (1) Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 | 12:48 |
| openstack | Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Open] | 12:48 |
| sean-k-mooney | no its fine | 12:48 |
| kashyap | (2) Ubuntu: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1836859 | 12:48 |
| openstack | Launchpad bug 1836859 in edk2 (Ubuntu) "RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package" [Undecided,New] | 12:48 |
| kashyap | coreycb: Hi, any update on the above from 'dannf'? --^ | 12:49 |
| kashyap | coreycb: Sorr for pestering; I'll be off from 06-Aug to 23-Aug, trying to get it into Ubuntu by then | 12:49 |
| kashyap | coreycb: It's a simple change, just requires one to go through the motions and get a package build out. | 12:49 |
| sean-k-mooney | they may still decide to package tehm in a different location but you know more about it then i | 12:49 |
| kashyap | sean-k-mooney: They can package it in whatever location - it doesn't matter, so long as they're shipping the JSON file with their custom path. | 12:50 |
| sean-k-mooney | i think its somewhat confusing that they are in the qemu directory and not in OVMF | 12:50 |
| kashyap | sean-k-mooney: That is what the QEMU firmware specifcation looks for. | 12:51 |
| kashyap | https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json#l312 | 12:51 |
| kashyap | 312 # - /usr/share/qemu/firmware -- populated by distro-provided firmware | 12:51 |
| kashyap | 313 # packages (XDG_DATA_DIRS covers | 12:51 |
| kashyap | 314 # /usr/share by default), | 12:51 |
| sean-k-mooney | i guess it depends on if its in the qemu package or ovmf package | 12:51 |
| sean-k-mooney | its edk2 | 12:51 |
| kashyap | For distributions shipping EDK2/OVMF, they should ship these files as part of that package. | 12:52 |
| sean-k-mooney | right so it seam weird that that package would add somthing to the qemu firmware folder unless that package has a hard depency on qemu e.g. it cant be instlled without it | 12:53 |
| aspiers | kashyap: weirdly, changing the commit message only invalidated the V+1 of that commit, not all the others rebased above it | 12:54 |
| sean-k-mooney | yep | 12:54 |
| sean-k-mooney | if gerrit can tell that the rest of the content did not change it wont drop the +/- 1 | 12:54 |
| sean-k-mooney | so if you are just fixing a commit message then it will generally keep everything else as long as you did not rebase | 12:55 |
| kashyap | sean-k-mooney: The /usr/share/qemu is not weird -- why? Because QEMU (4.1 onwards) _itself_ ships bundled EDK2 + JSON firmware files | 12:55 |
| kashyap | But those distributions building QEMU (and EDK2/OVMF) decouple that and ship separately | 12:56 |
| kashyap | aspiers: I'm writing a "summer time update" to the SUSE folks; look out for an e-mail | 12:56 |
| aspiers | kashyap: great | 12:57 |
| sean-k-mooney | the relationship is inverted if edk2 does not depend on qemu it shouldnt modify qemu directories but anyway i dont really want to dicuss this now | 12:57 |
| sean-k-mooney | if the json files were part of the qemu package the current state makes sense to me | 12:58 |
| coreycb | kashyap: i think he's on pto | 12:58 |
| efried | sean-k-mooney: what's the question? Whether service tokens are still experimental? | 12:58 |
| sean-k-mooney | efried: the question is can we enable them by default | 12:58 |
| coreycb | kashyap: this is for qemu 4.1 right? | 12:58 |
| efried | aspiers: Re Element.getchildren() -- sure; I'm assuming there's a fairly straightforward replacement. | 12:59 |
| sean-k-mooney | efried: or rather should we | 12:59 |
| aspiers | efried: literally just dropping ".getchildren()" | 12:59 |
| aspiers | efried: for child in parent: | 12:59 |
| aspiers | or children = list(parent) | 12:59 |
| sean-k-mooney | efried: they implemented the iterator protocol on the Element class so you can now just use list() itter() or pass it to a for loop and it will loop over the childeren | 13:00 |
| kashyap | coreycb: Yes, it is for QEMU 4.1 (coming out in the 2nd week of August). But no need to wait for the release | 13:00 |
| kashyap | aspiers: A quick one: what is the package called on SUSE? 'edk2' or 'edk2-ovmf' or 'ovmf'? | 13:01 |
| efried | aspiers: neat. Then yeah, for sure, let's get a patch up. | 13:01 |
| coreycb | kashyap: right so from what i understand 19.10 won't have qemu 4.1 so we have time. it's slated for 20.04. | 13:01 |
| * sean-k-mooney just realised someone put a comma in the filename of several of the binary blob "QEMU,tcx.bin" i am sure that has broken no one ever... | 13:02 | |
| efried | sean-k-mooney: When you say enable by default, the operator would still have to put admin creds into the service_user section of the conf to make it work; you're just suggesting getting rid of the need for the extra [service_user]send_service_user_token granny switch? | 13:03 |
| aspiers | kashyap: not sure but you can probably find out from these ... https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP4:Update/ovmf/ovmf.spec?expand=1 | 13:04 |
| aspiers | https://build.opensuse.org/package/view_file/SUSE:SLE-15:Update/ovmf/ovmf.spec?expand=1 | 13:04 |
| kashyap | coreycb: When is 20.04 out? | 13:04 |
| kashyap | coreycb: Note: this _doesn't_ require QEMU 4.1 per-se | 13:04 |
| aspiers | https://build.opensuse.org/package/show/hardware:boot/edk2 | 13:04 |
| coreycb | kashyap: april of 2020. right but i imagine that's how it will be prioritized. | 13:05 |
| sean-k-mooney | efried: i may not fully understand this feature but i was fering to removing of chaning the defualt of https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L28-L43 | 13:05 |
| kashyap | aspiers: Actually, I found it documented in my own spec :-) -- the pacakge in SLES is called: qemu-ovmf-x86_64 | 13:05 |
| aspiers | efried, kashyap: so SEV needs UEFI and currently the only way to activate this is hw_firmware_type=uefi on the image. What if an image without this is booted with hw:mem_encryption='True' ? | 13:05 |
| aspiers | Should nova throw an error, or impose uefi on the image? | 13:06 |
| sean-k-mooney | i guess you also need to set up the service user | 13:06 |
| aspiers | sean-k-mooney: interested in your opinion too | 13:06 |
| kashyap | coreycb: Well, why can't the package be even available in the "latest" Git distro? (In Fedora's terms, "Rawhide") | 13:06 |
| kashyap | coreycb: Fedora already ships these for a couple of weeks. There's no reason to delay this | 13:06 |
| sean-k-mooney | aspiers: does sev only work with uefi guests | 13:06 |
| aspiers | yes | 13:07 |
| coreycb | kashyap: i'm not the maintainer i'm just assuming how it will work | 13:07 |
| aspiers | it's mentioned in the spec | 13:07 |
| kashyap | aspiers: Hmm, I'd say "impose UEFI on the image" -- if it's a prereq for SEV -- but ... I don't off-hand if any caveats need to be thought out | 13:07 |
| sean-k-mooney | then you should have a check in the api and reject the spawn before we create a request spec or instance object | 13:07 |
| aspiers | albeit briefly | 13:07 |
| *** jroll has quit IRC | 13:07 | |
| aspiers | kashyap: I'm more inclined to agree with sean-k-mooney's suggestion here | 13:08 |
| aspiers | let's see what efried thinks | 13:08 |
| kashyap | coreycb: Noted. I'd also assume any other Debian packager submitting the change / patch shold be accepted. I hope the process is not blocked on a single maintainer. | 13:08 |
| *** jawad_axd has quit IRC | 13:08 | |
| *** jroll has joined #openstack-nova | 13:08 | |
| sean-k-mooney | you can do it like this https://review.opendev.org/#/c/671338/4/nova/compute/api.py | 13:08 |
| efried | aspiers: I don't know what any of that means, but it sounds like you've got a couple of choices: | 13:08 |
| efried | 1) make hw_firmware_type=uefi automatic when hw:mem_encryption=True (or... vice versa?) | 13:08 |
| efried | 2) make the operation fail if hw:mem_encryption=True but hw_firmware_type!=uefi | 13:08 |
| kashyap | aspiers: Yeah, nod. I was thinking in terms of how libvirt auto-adds 'smm' bit when requesting Secure Boot. But that's not an analogy at all | 13:08 |
| efried | oh | 13:08 |
| efried | that's exactly what you just said. | 13:08 |
| sean-k-mooney | just add a check to _validate_flavor_image_nostatus | 13:09 |
| efried | I don't understand this uefi thing well enough to render an opinion (like, what could go wrong if you set it implicitly, what is the impact of doing this thing the user didn't ask for, etc.) | 13:10 |
| aspiers | efried: I'm assuming that images need some UEFI support magic baked in | 13:10 |
| sean-k-mooney | efried: the host would have to be configured with uefi firmware to be able to enable it. | 13:10 |
| aspiers | but I don't actually know | 13:10 |
| *** ivve has joined #openstack-nova | 13:11 | |
| aspiers | does the scheduler know whether hosts support UEFI? | 13:11 |
| kashyap | aspiers: At this point, no. | 13:11 |
| sean-k-mooney | aspiers:for a uefi boot there would have to be a gpt partion on the image and it would need a efi boot partion to unpack the efi into | 13:11 |
| efried | If the host needs uefi-ness, then that needs to be part of determining whether the host exposes the SEV capability and the MEM_ENC_CTX inventory. | 13:11 |
| sean-k-mooney | i think | 13:11 |
| aspiers | efried: every SEV host will support UEFI | 13:12 |
| aspiers | efried: in fact I'm guessing also every host made in the last $NOT_SMALL years | 13:12 |
| sean-k-mooney | basicaly uefi booth need (typically) a 1M partition for use by the uefi firmware. if that is not in the disk image then the firmeware suppoied by the host wont work | 13:12 |
| aspiers | so it's not an issue for SEV, but it might be for hw_firmware_type in general | 13:13 |
| aspiers | sean-k-mooney: thanks, that's extremely helpful | 13:13 |
| *** jmlowe has joined #openstack-nova | 13:13 | |
| aspiers | and also scary because it highlights that I might have no easy way of getting a UEFI-capable SLES image :-( | 13:13 |
| sean-k-mooney | the only time i have used uefi with vms sofar i have installed from iso so it did the right thing | 13:13 |
| *** cdent has joined #openstack-nova | 13:14 | |
| sean-k-mooney | no idea if the cloud image are set up to work out of the box but i know disk image builder used to have issue with non msdos partion tables and i dont know if it can work wtih gpt partion tables yet so im guessing people milage will vary on this one | 13:14 |
| efried | okay, so you can't just toggle that property on an image and expect it to work. | 13:14 |
| efried | that answers the question, right? | 13:15 |
| sean-k-mooney | you cant assuem it will work correct | 13:15 |
| aspiers | right | 13:15 |
| efried | then do the validation thingy | 13:15 |
| * efried dusts hands | 13:15 | |
| aspiers | so yeah I'll follow sean-k-mooney's suggestion | 13:15 |
| aspiers | thanks all | 13:15 |
| *** jchhatbar has quit IRC | 13:15 | |
| efried | sean-k-mooney: re service auth... | 13:15 |
| sean-k-mooney | efried: ya so looking at the config code i was not aware we had to expclitly set addtional credentials that were not alreday required | 13:16 |
| *** ivve has quit IRC | 13:16 | |
| efried | the way it works is this: | 13:17 |
| efried | Some services do long-running operations, followed by other operations. Your user token may expire during the long-running operation, and then you would bounce on the subsequent operations. | 13:17 |
| efried | So you set up [service_user] with ksa creds and that toggle you pointed out. | 13:17 |
| efried | And we wrap your user token in what is effectively an admin token, which we then use if the user token expires. | 13:17 |
| efried | Yeah, the stealth inclusion of ksa creds is easy to miss | 13:17 |
| efried | so basically it looks like that conf only has one option, but it really has like a dozen -- all the ksa auth/session/adapter stuff. | 13:17 |
| sean-k-mooney | ya i kind of glossed over the bottm of the file as i assume it was the normal boiler plate but looking at it now i see its not | 13:18 |
| efried | So today you have to have that toggle switched on for us to even try loading up the ksa stuff. | 13:18 |
| efried | if we turned off that toggle, we would try loading up the ksa stuff and if it fails just carry on with the user token as is | 13:18 |
| efried | which is basically what we do today if you have the switch on anyway. | 13:18 |
| *** BjoernT has joined #openstack-nova | 13:18 | |
| efried | what's not clear is, if that toggle is gone, how should we behave if we can't load up the ksa bits? Just warn as we do today and carry on using the user token presumably | 13:19 |
| sean-k-mooney | ya the context for this was there was a discussion downstream of if/when we will start supproting this in our product | 13:19 |
| efried | but if the op doesn't *want* to use service auth, they're getting a warning for doing what they wanted. | 13:19 |
| *** mvkr has joined #openstack-nova | 13:20 | |
| sean-k-mooney | efried: well i think the present of the service user in the config would be enough to singnel this no? | 13:20 |
| sean-k-mooney | e.g. if you put it in the config we asssume you want to use it | 13:20 |
| sean-k-mooney | if you didnt we assume you dont | 13:20 |
| sean-k-mooney | is ther service_user section used for anythin else currently? | 13:20 |
| sean-k-mooney | if so the toggle makes sense if not then its a needless extra step | 13:21 |
| sean-k-mooney | but in anycase its not as simple as jsut enabling it by defualt. the operator need to add serveice_user creds | 13:21 |
| efried | right, but it's a bit different than the other auth sections | 13:22 |
| sean-k-mooney | i had asumeed we would reuse the admin creds that nova already has rather then accept a different set | 13:22 |
| efried | The other ones, if you spell something wrong or mess up your creds, you can't do things. | 13:22 |
| efried | With this one, we can still mostly operate. | 13:22 |
| efried | so how should we behave if you put stuff in but f it up? | 13:23 |
| *** jdillaman has joined #openstack-nova | 13:23 | |
| sean-k-mooney | ya i get the concern about the silent failure | 13:23 |
| *** cdent has quit IRC | 13:23 | |
| efried | Really this is a question we should be addressing with what we have today anyway. | 13:23 |
| sean-k-mooney | if you populated the filed and the password or whatever was wong i woudl expect an error | 13:23 |
| efried | because IMO if you said "I want to do this thing" but we can't work with what you've entered, it should arguably be a failure. | 13:23 |
| efried | right | 13:24 |
| sean-k-mooney | but if you typo the section name that is tricker | 13:24 |
| efried | but that's a separate discussion I think. | 13:24 |
| sean-k-mooney | ok | 13:24 |
| sean-k-mooney | you ansered my question anyway | 13:24 |
| sean-k-mooney | its not as simple as just truning it on and it working | 13:24 |
| sean-k-mooney | so the installer would have to configure it | 13:24 |
| efried | sean-k-mooney: other quirks and details to be aware of: | 13:24 |
| efried | it only applies to some services | 13:25 |
| efried | like, ironic is always admin, so service auth is n/a | 13:25 |
| efried | glance is always user, and it applies there | 13:25 |
| sean-k-mooney | yes appreent glance can recive teh service token but not send it | 13:25 |
| efried | neutron is *sometimes* admin | 13:25 |
| efried | why would glance need to send a service token? | 13:25 |
| sean-k-mooney | i was not sure about that either but appreently it has something to do with the glance_store. im guessint its related to there replication/validation capablities | 13:27 |
| sean-k-mooney | efried: oh it for when glance it using cinder/swift as a backend | 13:27 |
| sean-k-mooney | https://review.opendev.org/#/c/526611/ | 13:27 |
| efried | okay, well, that sounds like an issue for glance to deal with then. | 13:28 |
| sean-k-mooney | anyway our glance folks downstream mentioned that there are still somthing related to the glance_store drivers | 13:29 |
| sean-k-mooney | ya is not a nova problem | 13:29 |
| sean-k-mooney | well it could be for shelve | 13:29 |
| *** BjoernT_ has joined #openstack-nova | 13:29 | |
| sean-k-mooney | e.g. we send glance the user and service token but it might just use teh user token and fail | 13:29 |
| sean-k-mooney | anyway tl;dr there is still work to do in some services | 13:30 |
| *** BjoernT has quit IRC | 13:30 | |
| *** BjoernT has joined #openstack-nova | 13:32 | |
| *** BjoernT_ has quit IRC | 13:34 | |
| *** mvkr has quit IRC | 13:34 | |
| *** sridharg has quit IRC | 13:41 | |
| *** whoami-rajat has quit IRC | 13:42 | |
| *** dpawlik has quit IRC | 13:45 | |
| *** mvkr has joined #openstack-nova | 13:47 | |
| *** cdent has joined #openstack-nova | 13:48 | |
| *** dpawlik has joined #openstack-nova | 13:52 | |
| *** artom has quit IRC | 13:54 | |
| *** tbachman has joined #openstack-nova | 13:55 | |
| *** dklyle has quit IRC | 14:00 | |
| *** dklyle has joined #openstack-nova | 14:00 | |
| aspiers | kashyap: libvirtError: operation failed: unable to find any master var store for loader: /usr/share/OVMF/OVMF_CODE.fd | 14:02 |
| aspiers | I made that file a symlink to /usr/share/qemu/ovmf-x86_64-code.bin | 14:02 |
| aspiers | where is the master var store supposed to live? | 14:02 |
| aspiers | biab | 14:02 |
| sean-k-mooney | <os> | 14:05 |
| sean-k-mooney | <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> | 14:05 |
| sean-k-mooney | <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> | 14:05 |
| sean-k-mooney | <nvram>/var/lib/libvirt/qemu/nvram/ovn1_VARS.fd</nvram> | 14:05 |
| sean-k-mooney | <boot dev='hd'/> | 14:05 |
| sean-k-mooney | </os> | 14:05 |
| sean-k-mooney | aspiers: ^ | 14:05 |
| sean-k-mooney | i think you are missing the per vm VARs file | 14:06 |
| sean-k-mooney | i belive its generated form a template | 14:06 |
| sean-k-mooney | but i know know where that lives | 14:06 |
| sean-k-mooney | aspiers: but kashyap will be able to point you in the right direction when he is back | 14:06 |
| * kashyap is here, just finishing up a comment in a bug | 14:06 | |
| *** jmlowe has quit IRC | 14:08 | |
| *** panda is now known as panda|brb | 14:19 | |
| *** tetsuro has joined #openstack-nova | 14:20 | |
| *** smrcascao has joined #openstack-nova | 14:24 | |
| *** tetsuro has quit IRC | 14:24 | |
| *** panda|brb is now known as panda | 14:25 | |
| *** smrcascao has quit IRC | 14:30 | |
| *** dpawlik has quit IRC | 14:31 | |
| *** mkrai has joined #openstack-nova | 14:31 | |
| mriedem | forbidden aggregates must have jumped the runways queue https://etherpad.openstack.org/p/nova-runways-train | 14:35 |
| *** ttsiouts has quit IRC | 14:35 | |
| *** ttsiouts has joined #openstack-nova | 14:36 | |
| mriedem | looks like brin zhang updated the runways but didn't log the changes | 14:37 |
| mriedem | brinzhang_: ^ | 14:38 |
| kashyap | aspiers: Yeah, you should have a corresponding VARS file | 14:39 |
| *** lpetrut has quit IRC | 14:39 | |
| kashyap | aspiers: On SLES, it is this combination: | 14:40 |
| kashyap | - Firmware binary: /usr/share/qemu/ovmf-x86_64-opensuse-code.bin | 14:40 |
| kashyap | - Matching variable store template: /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin | 14:40 |
| *** ttsiouts has quit IRC | 14:40 | |
| *** ttsiouts has joined #openstack-nova | 14:41 | |
| kashyap | aspiers: Make the last file on SLES as a symlink to '/usr/share/OVMF/OVMF_VARS.fd'. Then your instance should launch. | 14:42 |
| mriedem | well i think i unborked the runways queue etherpad | 14:42 |
| *** jaypipes has quit IRC | 14:46 | |
| *** tbachman has quit IRC | 14:46 | |
| sean-k-mooney | it was broken? | 14:51 |
| sean-k-mooney | i had it open in a tab and it more or less looks the same | 14:51 |
| *** belmoreira has joined #openstack-nova | 14:51 | |
| aspiers | kashyap: thanks! | 14:53 |
| *** ivve has joined #openstack-nova | 14:55 | |
| *** mlavalle has joined #openstack-nova | 14:57 | |
| kashyap | aspiers: When you get around to it, let me know if that works for you :-) | 14:59 |
| aspiers | kashyap: trying right now | 14:59 |
| kashyap | Okay; /me --> call | 14:59 |
| aspiers | but I don't know if my image is really UEFI | 14:59 |
| aspiers | any easy way to check? | 14:59 |
| kashyap | aspiers: Yes: | 15:01 |
| aspiers | kashyap: I assume I want /usr/share/qemu/ovmf-x86_64-suse-vars.bin since this is SLES not openSUSE | 15:01 |
| kashyap | aspiers: Yes, run `tree efi` on /boot on your VM image | 15:02 |
| aspiers | you mean after mounting it with qemu-nbd or libguestfs? | 15:02 |
| kashyap | If your VM image is EFI-capable, then you'll see files with .efi extension (e.g. BOOTX64.EFI) under /boot/efi | 15:03 |
| aspiers | thanks | 15:04 |
| kashyap | Let me show you on Fedora - comparing an image that is not UEFI-capable with one that is | 15:04 |
| kashyap | aspiers: (And yes, after mounting) | 15:06 |
| kashyap | I use `guestmount`. | 15:06 |
| aspiers | still getting Instance failed to spawn: libvirtError: operation failed: unable to find any master var store for loader: /usr/share/OVMF/OVMF_CODE.fd | 15:06 |
| *** Luzi has quit IRC | 15:06 | |
| aspiers | lrwxrwxrwx 1 root root 41 Jul 29 04:22 OVMF_CODE.fd -> /usr/share/qemu/ovmf-x86_64-suse-code.bin | 15:06 |
| aspiers | lrwxrwxrwx 1 root root 41 Jul 29 04:22 OVMF_VARS.fd -> /usr/share/qemu/ovmf-x86_64-suse-vars.bin | 15:06 |
| kashyap | aspiers: Here is the comparison: http://paste.openstack.org/show/755075/ | 15:07 |
| mriedem | https://review.opendev.org/#/c/621476/50 needs a lot of work... | 15:07 |
| kashyap | aspiers: Let's try one more thing: | 15:08 |
| mriedem | gmann: new compute api policy naming discussion in https://review.opendev.org/#/c/621476/50/nova/policies/server_topology.py@20 | 15:09 |
| mriedem | i did my best to recommend names | 15:10 |
| kashyap | aspiers: Let's try one more thing: can you post your /etc/libvirt/qemu.conf? | 15:10 |
| kashyap | In short, if you _don't_ have this entry, add it in there: | 15:10 |
| kashyap | nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" | 15:10 |
| aspiers | sure | 15:10 |
| kashyap | ]] | 15:10 |
| aspiers | it's commented out | 15:10 |
| kashyap | aspiers: Can you uncomment both the VARS, and CODE file out, restart libvirtd & try? | 15:11 |
| aspiers | sure | 15:11 |
| aspiers | except the commented bit is wrong | 15:12 |
| kashyap | [This is test-only; note that long longer libvirt upstream intends to get rid of this config.] | 15:12 |
| efried | mriedem: IMO runways shouldn't be limited to "ready for core review". What does that even mean? Code complete and passing tests should be sufficient. Are you saying they should be required to have so many rounds of non-core reviews before being eligible? That doesn't sound workable to me. | 15:13 |
| efried | mriedem: (this is without having looked at the patch that triggered your comment btw, maybe it was marked WIP or not passing zuul, which would be valid reasons to keep it out of runways) | 15:13 |
| efried | "obviously a mess" (my words, not yours) is super subjective. obviously you'll set a much higher bar than an inexperienced contributor. | 15:14 |
| kashyap | aspiers: Note that in the 'nvram' libvirt config, you can give SUSE's precise file paths. (Symlinks should work too, of course) | 15:14 |
| aspiers | kashyap: ack | 15:15 |
| *** artom has joined #openstack-nova | 15:20 | |
| *** udesale has joined #openstack-nova | 15:22 | |
| *** ttsiouts has quit IRC | 15:23 | |
| *** ttsiouts has joined #openstack-nova | 15:24 | |
| aspiers | kashyap: progress!! | 15:25 |
| aspiers | kashyap: now I can see the vnc console and a kernel panic X-D | 15:25 |
| aspiers | that's huge progress | 15:25 |
| mriedem | efried: where did i say "obviously a mess"? | 15:25 |
| mriedem | oh nvm, | 15:26 |
| mriedem | i didn't | 15:26 |
| efried | mriedem: yeah, I was kind of putting words in your mouth, sorry about that. | 15:26 |
| *** tssurya has quit IRC | 15:26 | |
| *** mkrai has quit IRC | 15:27 | |
| mriedem | as for not really ready for core review, i removed that. it'd be nice if contributors from large companies that have other developers working on this project would do some peer review before putting stuff into runways, but i guess that's a pipe dream. | 15:27 |
| aspiers | kashyap: that kinda gives me hope this whole thing might actually work :) | 15:27 |
| mriedem | but i mean, there were just typos all over the thing | 15:27 |
| mriedem | so i consider that not really ready for core review | 15:27 |
| aspiers | mriedem: I really hope to do more "selfless" upstream work (including reviews) but right now I'm battling this SEV deadline | 15:27 |
| mriedem | aspiers: ok? | 15:27 |
| cdent | mriedem: pretty soon having reviewers at all will be a pipe dream | 15:28 |
| sean-k-mooney | dont we already have a requirement that code must not be in WIP state to enter the runways | 15:28 |
| mriedem | cool | 15:28 |
| mriedem | it wasn't wip | 15:28 |
| aspiers | mriedem: nevertheless some of the SEV work is enabling stuff that kashyap and sean-k-mooney are working on, so at least it's not *entirely* selfish ... | 15:29 |
| sean-k-mooney | im not sure which revew set ye were refering to by the way | 15:29 |
| mriedem | anyway, i shouldn't have said anything, i'm just cranky. woken up too early, had to fix the runways etherpad, etc etc | 15:29 |
| *** tbachman has joined #openstack-nova | 15:29 | |
| mriedem | aspiers: i'm not complaining about SEV stuff at all | 15:29 |
| *** ttsiouts has quit IRC | 15:29 | |
| sean-k-mooney | aspiers: well the only depency i have on the sev work is the harding patch | 15:29 |
| aspiers | mriedem: I know, but I was trying to boost your morale a bit ;-) | 15:29 |
| mriedem | SEV does not boost my morale but ok | 15:29 |
| sean-k-mooney | which is not really part of the series more a depency for my blueprint and yours | 15:29 |
| aspiers | sean-k-mooney: sshhh, I'm trying to cheer up mriedem ;-) | 15:30 |
| sean-k-mooney | hehe ok | 15:30 |
| artom | Time for the Riderman song? | 15:30 |
| aspiers | sean-k-mooney: also you got the getDomainCapabilities code from me for free | 15:30 |
| cdent | oh, I misunderstood. I was trying to mriedem more sad. | 15:30 |
| aspiers | haha | 15:30 |
| sean-k-mooney | aspiers: yes but i technically never needed it | 15:30 |
| aspiers | bah :) | 15:30 |
| aspiers | sean-k-mooney: what about https://review.opendev.org/#/c/673151/, maybe that is useful for you too | 15:30 |
| sean-k-mooney | aspiers: im just using it since its there | 15:31 |
| kashyap | aspiers: Selectively reading the scroll | 15:31 |
| sean-k-mooney | i havenet seen that patch before. so i dont know | 15:31 |
| kashyap | aspiers: Hehe, so long as you're in the console, good. My assistance is over ;-) | 15:31 |
| aspiers | mriedem: I mean, I was trying to cheer you up by saying that I'm hoping to contribute more than just SEV and its peripheries | 15:31 |
| aspiers | sean-k-mooney: I wrote it on Sat | 15:31 |
| aspiers | sean-k-mooney: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-27.log.html#t2019-07-27T18:15:17 | 15:32 |
| sean-k-mooney | aspiers: but i would prefer to merge teh code i have and then see if we can refactor later | 15:32 |
| aspiers | sean-k-mooney: it's not a refactor and I don't think it overlaps with your changes | 15:32 |
| aspiers | well there is a bit of refactoring in there | 15:32 |
| aspiers | but that's not the main point | 15:33 |
| aspiers | anyway gotta go again | 15:33 |
| aspiers | biab | 15:33 |
| kashyap | mriedem: Yes, to be fair -- parts from SEV work in Nova _do_ help the Secure Boot stuff and some of what Sean's doing. | 15:37 |
| aspiers | I wasn't trying to portray SEV as the saviour of nova ;-) or even anything significantly helpful. Just stating my wish to contribute more to nova *beyond* SEV in the future | 15:37 |
| aspiers | I've already done bits and pieces here and there | 15:38 |
| aspiers | but would like to do more | 15:38 |
| kashyap | aspiers: Heh, you don't need to defend yourself _that_ much by feeling like you're walking on some eggshells. | 15:38 |
| kashyap | It's good work, and enables a useful and imporant usecase. | 15:39 |
| aspiers | sure, I don't feel under attack either ;) | 15:39 |
| *** gyee has joined #openstack-nova | 15:39 | |
| kashyap | Okido; then let's keep maintaining our inner tranquility.. | 15:40 |
| kashyap | s/.././ | 15:41 |
| *** udesale has quit IRC | 15:41 | |
| *** udesale has joined #openstack-nova | 15:41 | |
| *** mkrai has joined #openstack-nova | 15:41 | |
| eandersson | sean-k-mooney, I tried to backport the prelude patch needed for | 15:42 |
| eandersson | https://review.opendev.org/#/c/672855/ | 15:42 |
| eandersson | but I think I'll have to leave that for someone else | 15:42 |
| eandersson | So many changes between Stein and Rocky on that front | 15:42 |
| *** mkrai has quit IRC | 15:43 | |
| *** derekh has joined #openstack-nova | 15:54 | |
| sean-k-mooney | eandersson: sure once its merged on master then people on teh stable/core teams will be able to backport it if needed or i can try to take a look | 15:56 |
| *** mvkr has quit IRC | 16:01 | |
| *** vishwanathj has quit IRC | 16:02 | |
| *** rpittau is now known as rpittau|afk | 16:04 | |
| *** belmoreira has quit IRC | 16:05 | |
| aspiers | kashyap: does this look capable? http://paste.openstack.org/show/755079/ | 16:10 |
| aspiers | I don't see any shims | 16:10 |
| *** vishwanathj has joined #openstack-nova | 16:19 | |
| *** ivve has quit IRC | 16:21 | |
| aspiers | kashyap: so grub actually shows secure boot enabled! | 16:21 |
| efried | phew, glad alex_xu and stephenfin were able to approve that get_domain_capabilities() patch. I was having nightmares. | 16:21 |
| aspiers | hehe | 16:21 |
| eandersson | Sounds good sean-k-mooney | 16:21 |
| sean-k-mooney | i commented on the review by the way | 16:22 |
| aspiers | efried: if that gave you nightmares, I dread to think what https://review.opendev.org/#/c/673151/ will do | 16:22 |
| sean-k-mooney | just pointing out that it may change the message if we dont actully through the exception | 16:22 |
| efried | ahcrap, is that *also* blocking the SEV work? | 16:22 |
| sean-k-mooney | but i have not confimed that | 16:22 |
| aspiers | efried: it's the first in the series | 16:22 |
| aspiers | so, yeah :) | 16:22 |
| eandersson | Yea - I wasn't sure if that was the case. | 16:23 |
| efried | okay, so look, I'm probably not going to be able to +2 the super-libvirty things in that series, but as long as you've got folks like alex_xu and stephenfin to look, I guess you should be okay. | 16:24 |
| sean-k-mooney | eandersson: worst case it just wont have a stack trace pointing to where it was thrown | 16:24 |
| sean-k-mooney | because it was not raised | 16:24 |
| *** ganso has quit IRC | 16:24 | |
| sean-k-mooney | best case it will have a stack trace that point to where it was constucted | 16:24 |
| sean-k-mooney | which is basically where we would have raised it before | 16:24 |
| openstackgerrit | Vladyslav Drok proposed openstack/nova master: [libvirt] Check if domain is persistent on cleanup https://review.opendev.org/673332 | 16:25 |
| aspiers | efried: I've added them. Next one is https://review.opendev.org/#/c/638680/ which you were previously +2 on. I think pretty much only changes since then have been to fix your nits and rebase | 16:25 |
| aspiers | PS27 was +2 W+1 | 16:26 |
| efried | ack. I've been procrastinating due to the prereqs. Was hoping to dive in again this week. | 16:27 |
| aspiers | efried: oh, and also fixing tests which never got run before: https://review.opendev.org/#/c/638680/30..31/nova/tests/functional/libvirt/test_report_cpu_traits.py | 16:27 |
| *** tesseract has quit IRC | 16:28 | |
| aspiers | so if you're happy with that ^^ and trust my rebasing skills then I guess it should be easy to recycle your previous +2 W+1 | 16:28 |
| *** brault has quit IRC | 16:29 | |
| sean-k-mooney | eandersson: efried based on a simple test in the repel it will have no traceback | 16:29 |
| sean-k-mooney | >>> val_error = ValueError() | 16:29 |
| sean-k-mooney | >>> val_error.__traceback__ | 16:29 |
| sean-k-mooney | >>> | 16:29 |
| sean-k-mooney | >>> raise val_error | 16:30 |
| sean-k-mooney | Traceback (most recent call last): | 16:30 |
| sean-k-mooney | File "<stdin>", line 1, in <module> | 16:30 |
| sean-k-mooney | ValueError | 16:30 |
| sean-k-mooney | >>> val_error.__traceback__ | 16:30 |
| sean-k-mooney | <traceback object at 0x7fc44ac5db48> | 16:30 |
| efried | aspiers: yup. But urgency again reduced by the fact that there's a big not-reviewable-by-me thingy in front of it again/still. | 16:30 |
| sean-k-mooney | so it looks like the tracback is only compute when its raised | 16:30 |
| efried | sean-k-mooney: ack, but that only matters if the traceback is being used somewhere up the chain | 16:30 |
| efried | which afaict it isn't. | 16:31 |
| efried | all we're doing is printing the exception | 16:31 |
| efried | which is the same whether it's raised or not. | 16:31 |
| sean-k-mooney | its not its just being logged | 16:31 |
| efried | right | 16:31 |
| *** jangutter has quit IRC | 16:31 | |
| sean-k-mooney | so i dont know if we care | 16:31 |
| efried | I didn't -1 before | 16:31 |
| efried | right, I don't know either. | 16:31 |
| sean-k-mooney | i think we dont | 16:31 |
| efried | I would have accepted either explanation, really. | 16:31 |
| sean-k-mooney | just you were asking if they were the same and they technically arnt | 16:31 |
| efried | Even if we want to say "this is future proofing in case someone wants to print this stack trace somewhere" | 16:32 |
| sean-k-mooney | but not in a way that matters for our usecase | 16:32 |
| efried | ++ thanks for the clarification. | 16:32 |
| sean-k-mooney | ill copy that example into a comment and change my +0 to a +1 | 16:32 |
| *** epoojad1 has joined #openstack-nova | 16:35 | |
| *** N3l1x has joined #openstack-nova | 16:43 | |
| *** ivve has joined #openstack-nova | 16:52 | |
| mriedem | eandersson: re https://review.opendev.org/#/c/672855/ i might write a functional regression test for the issue (separate patch) and stack your change on top | 16:53 |
| mriedem | that code is too shitty for just unit tests | 16:53 |
| eandersson | Yea that would be great | 16:54 |
| eandersson | It's a pretty big problem for services like Senlin if this happens | 16:54 |
| eandersson | It exposed a bug in Senlin as well of course | 16:54 |
| mriedem | i worry about a refactor of that code in the future to remove the non-reschedule logic to drop the error handling | 16:55 |
| *** ganso has joined #openstack-nova | 16:56 | |
| sean-k-mooney | it is certenly not the most intuitive code i have seen | 16:56 |
| mriedem | years and years of piling more stuff into it | 16:56 |
| *** udesale has quit IRC | 16:57 | |
| *** cdent has quit IRC | 16:57 | |
| sean-k-mooney | eandersson: well its a problem in general. senlin is proably more sensitive but haveing a server always in build and nerver erroring out becasue we miseed that exception being raised is going to break alot of workflows | 16:58 |
| *** ivve has quit IRC | 16:59 | |
| sean-k-mooney | eandersson: if you use something like heat that had a timeout onf the whole heat stack create process it would clean it up but only after doing a lot of work that got thrown away and after waiting for the timeout to fire | 16:59 |
| mriedem | ok i'm going to get lunch and then i'll write a functional regression test and rebase the fix on top | 16:59 |
| *** igordc has joined #openstack-nova | 16:59 | |
| *** derekh has quit IRC | 17:00 | |
| openstackgerrit | sean mooney proposed openstack/nova master: Libvirt: add support for vPMU configuration. https://review.opendev.org/671338 | 17:07 |
| *** xek has quit IRC | 17:07 | |
| *** xek has joined #openstack-nova | 17:08 | |
| sean-k-mooney | stephenfin: by the way when your back from PTO tommorow can you take a look at this os-vif change i wrote https://review.opendev.org/#/c/672834/ | 17:08 |
| openstackgerrit | Dustin Cowles proposed openstack/nova master: WIP: Provider config file https://review.opendev.org/673341 | 17:12 |
| *** artom has quit IRC | 17:14 | |
| efried | sean-k-mooney: https://review.opendev.org/#/c/666604/ I think I may have said the same thing as you, in different words... | 17:17 |
| * sean-k-mooney reads | 17:17 | |
| sean-k-mooney | more or less yes | 17:18 |
| efried | okay, cool | 17:19 |
| sean-k-mooney | im not sure if we store teh compute capablities in the nova db or if they only live in memory in the compute agent | 17:20 |
| sean-k-mooney | that said i think they must be in the db for the compute capbalites fiter to work | 17:20 |
| *** vishwanathj has quit IRC | 17:21 | |
| openstackgerrit | Merged openstack/nova master: libvirt: harden Host.get_domain_capabilities() https://review.opendev.org/670189 | 17:21 |
| sean-k-mooney | so its not really clear to me if 1 the info is avialble outside the compute node and 2 if retriving the info from placmenet would be cheaper then an rpc or db call. (ignoring if the traits is a thing we want for the sake of argument) | 17:22 |
| *** dpawlik has joined #openstack-nova | 17:22 | |
| sean-k-mooney | you could proably retrive it form placement in 1 call by looking the RP up by name which should match the instance.host | 17:23 |
| sean-k-mooney | and if you pull back the full RP i assume that would contian the traits too | 17:24 |
| *** ricolin_ has quit IRC | 17:24 | |
| *** ralonsoh has quit IRC | 17:25 | |
| sean-k-mooney | actully your right it would need 2 quires | 17:26 |
| sean-k-mooney | since we just have the link to the traits endpoint and not the tratis in the responce from /resource_providers?name={instance.host} | 17:27 |
| openstackgerrit | Eric Fried proposed openstack/nova master: Move adding vlans to interfaces to privsep. https://review.opendev.org/635436 | 17:34 |
| *** vishwanathj has joined #openstack-nova | 17:39 | |
| *** whoami-rajat has joined #openstack-nova | 17:40 | |
| *** artom has joined #openstack-nova | 17:44 | |
| *** trident has quit IRC | 17:47 | |
| *** trident has joined #openstack-nova | 17:51 | |
| mriedem | sean-k-mooney: it's not available outside the compute node | 17:54 |
| mriedem | and not stored *in* the compute node object | 17:54 |
| mriedem | as i said in my reply to chris, a pre-filter might not make sense | 17:55 |
| mriedem | it would likely be logic in the api itself | 17:55 |
| mriedem | to either ignore or not the current instance.host | 17:55 |
| mriedem | this is also a super latent issue and at the bottom of my priority list | 17:56 |
| sean-k-mooney | ok i was guessing it was someing like that. e.g. not available out side of the compute | 18:09 |
| sean-k-mooney | a trait on the RP would be less expensive to check then intoducing a new rpc call | 18:10 |
| mriedem | and consistent with all of the compute capabilities as traits stuff we've been doing since rocky | 18:14 |
| sean-k-mooney | ya im aware of the other traits but i was not sure if we did it that way only because they are only available on the compute node or because they are usefult to schdule on | 18:23 |
| sean-k-mooney | e.g. the multi attach trait is useful to shcduler on if you are booting with a multi attach volume | 18:24 |
| sean-k-mooney | but im not sure i see a usecase for passing this new trait as a requried trait on boot but i understand how it coudl be used on migrate/resize | 18:25 |
| sean-k-mooney | maybe there is a usecase where you would want to require it on spawn but it just felt a little different then the other capablity traits we have | 18:25 |
| aspiers | big achievement just unlocked: booting a fully functional SEV guest via nova | 18:27 |
| aspiers | that only took what - 9 months? | 18:27 |
| sean-k-mooney | :) | 18:28 |
| sean-k-mooney | you mean you didnt hardcode it quickly to test it works 9 months ago | 18:28 |
| sean-k-mooney | hehe when im doing stuff that requires new xml i have often hard coded enabling the featuer just in the compute ndoe to make sure it actully can boot followint the upstream(libvirt/qemu) docs then work backwards to figure out how to report it to the RT/schduler and how to request it form the api | 18:30 |
| sean-k-mooney | just to sanity check that teh libvirt/qemu part works as expected. | 18:31 |
| sean-k-mooney | so i dont spend 9 months trying to enable somthing that broken. | 18:31 |
| * sean-k-mooney past expeirnce with preproduction hadware has told me to not trust docs until you see it working with your own eyes | 18:33 | |
| aspiers | sean-k-mooney: we already had other guys boot it successfully without nova | 18:40 |
| aspiers | sean-k-mooney: the reference XML is even linked from the SEV nova spec | 18:40 |
| aspiers | persuading nova to achieve a working config was the hard bit | 18:40 |
| sean-k-mooney | sure it just make me feel better when i do it myself pluse the xml generation is usually the simplest part | 18:40 |
| aspiers | since the reference XMLs were not generated from nova, therefore it was a question of gradually shrinking the differences until nova generated a working config | 18:41 |
| aspiers | like boring from opposite ends of a tunnel and meeting in the middle | 18:41 |
| aspiers | now I have like 2 days to backport the whole thing to rocky | 18:42 |
| * aspiers laughs hysterically ... or maybe it's crying | 18:42 | |
| sean-k-mooney | your goign to backport it before it merges | 18:43 |
| aspiers | yes just for this demo | 18:44 |
| aspiers | downstream only | 18:44 |
| aspiers | the backport would never get accepted upstream anyway | 18:44 |
| sean-k-mooney | well yes but if its a demo i would personally use master | 18:46 |
| sean-k-mooney | it would make your life a lot simpler | 18:46 |
| aspiers | it won't because SUSE OpenStack Cloud doesn't run on master | 18:53 |
| aspiers | having said that, plan B will just be to use devstack I guess | 18:54 |
| sean-k-mooney | aspiers: i was assuming you would demo with devstack yes | 18:55 |
| sean-k-mooney | i fixed the typos you spotted in the vpmu patch by the way. | 18:55 |
| sean-k-mooney | im going to go have dinner so talk to you tomorow/later | 18:56 |
| openstackgerrit | Gage Hugo proposed openstack/nova master: Update config doc policy file type https://review.opendev.org/673349 | 19:00 |
| *** maciejjozefczyk has quit IRC | 19:14 | |
| aspiers | sean-k-mooney: thanks | 19:14 |
| aspiers | something in my devstack changed and now I get this when I try to delete instances: | 19:15 |
| aspiers | ERROR oslo_messaging.rpc.server RemoteError: Remote error: IncompatibleObjectVersion Version 1.1 of ConsoleAuthToken is not supported, supported version is 1.0 | 19:15 |
| aspiers | I know that's an OVO thing, but I have no idea how to fix it except for redeploying devstack which would take ages and hose a bunch of setup I want to keep - any ideas? | 19:15 |
| aspiers | ah, I see the patch which added 1.1 recently - that explains why it happened, but not how I can migrate my objects | 19:16 |
| * aspiers reads https://docs.openstack.org/oslo.versionedobjects/latest/ | 19:20 | |
| aspiers | doh, I just had to restart *all* nova services | 19:24 |
| aspiers | must have been a mismatch with n-cpu | 19:24 |
| * aspiers goes for dinner too | 19:26 | |
| openstackgerrit | Eric Fried proposed openstack/nova-specs master: tox -e fast-specs https://review.opendev.org/673356 | 19:35 |
| efried | sean-k-mooney, mriedem: as we discussed the other day ^ | 19:35 |
| efried | stephenfin: that probably wants your sphinx expertise ^ | 19:36 |
| openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855 | 19:37 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional regression test for bug 1837955 https://review.opendev.org/673357 | 19:39 |
| openstack | bug 1837955 in OpenStack Compute (nova) "MaxRetriesExceeded sometime fails with messaging exception" [Medium,In progress] https://launchpad.net/bugs/1837955 - Assigned to Erik Olof Gunnar Andersson (eandersson) | 19:39 |
| mriedem | eandersson: efried: sean-k-mooney: ^ here is the functional test, i'll rebase the fix on top of it - was kind of a pain to make sure it would work on queens | 19:39 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855 | 19:42 |
| mriedem | rebased | 19:42 |
| *** brault has joined #openstack-nova | 19:56 | |
| *** jmlowe has joined #openstack-nova | 19:57 | |
| *** vishwanathj has quit IRC | 19:58 | |
| *** brault has quit IRC | 20:00 | |
| *** vishwanathj has joined #openstack-nova | 20:06 | |
| openstackgerrit | Eric Fried proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855 | 20:08 |
| *** belmoreira has joined #openstack-nova | 20:09 | |
| eandersson | Thanks efried | 20:09 |
| efried | thanks for the fix | 20:09 |
| efried | now we just need someone to send mriedem's test | 20:09 |
| *** jmlowe has quit IRC | 20:14 | |
| sean-k-mooney | dumb question but we have a bunch of tempest test that end in TestJSON what makes them different form normal tempest tests. are then calling the api with json payloads or somthing? | 20:28 |
| *** slaweq has quit IRC | 20:35 | |
| *** whoami-rajat has quit IRC | 20:39 | |
| sean-k-mooney | ... i is confused | 20:43 |
| sean-k-mooney | the tempest-fully-py3 job supports depends-on against neutron patches right | 20:43 |
| *** xek has quit IRC | 20:43 | |
| sean-k-mooney | because my patch failed with an error message i deleted form the neutron code base so it really looks like it didnt work | 20:44 |
| sean-k-mooney | yat http://logs.openstack.org/32/602432/12/check/tempest-full-py3/39b553b/job-output.txt.gz#_2019-07-23_17_51_24_263888 it looks like it didnt check out my patch | 20:45 |
| sean-k-mooney | yep it ran with master ... http://logs.openstack.org/32/602432/12/check/tempest-full-py3/39b553b/job-output.txt.gz#_2019-07-23_17_54_02_352110 | 20:46 |
| *** trident has quit IRC | 20:49 | |
| *** trident has joined #openstack-nova | 20:52 | |
| openstackgerrit | sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.opendev.org/602432 | 21:01 |
| *** rafaeldtinoco has left #openstack-nova | 21:13 | |
| eandersson | btw is it just RamFilter that is being removed? Or is AggregateRamFilter being removed as well? | 21:16 |
| eandersson | Because I see AggregateRamFilter is still a thing in Stein | 21:16 |
| *** belmoreira has quit IRC | 21:17 | |
| sean-k-mooney | both | 21:17 |
| sean-k-mooney | and the core and disk filter both aggreagte and non aggrate forms | 21:18 |
| sean-k-mooney | eandersson: all 6 filter have been depreacted since ocata | 21:18 |
| sean-k-mooney | we removed the caching scudler i think in stien which was the last valid usecase for them | 21:19 |
| eandersson | I see | 21:19 |
| sean-k-mooney | we still actully have the filter on master but i dont think they work properly anymore | 21:20 |
| eandersson | I did like how you could orchestrate aggregates | 21:20 |
| sean-k-mooney | you can still do that in a sligtly different way via placmenet | 21:21 |
| *** dpawlik has quit IRC | 21:21 | |
| sean-k-mooney | but its perfromce before did nto scale well and there were a bunch of edgcases | 21:21 |
| sean-k-mooney | it looks like https://github.com/openstack/nova/commit/78645e61c63bf042453d1f822ae8b3f1ee6a311b missed the aggrate versions | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP-until-series-is-ready] Introduce live_migration_claim() https://review.opendev.org/635669 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for augmenting migrate_data with info from claims https://review.opendev.org/634828 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | 21:22 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Functional test for NUMA live migration https://review.opendev.org/672595 | 21:22 |
| artom | Probably broke a whole bunch of unit tests with that, will let CI tell me what's up. | 21:23 |
| artom | But the problems that were left at the end of Stein have been fixed | 21:25 |
| sean-k-mooney | the main one was saving the updated xml right | 21:32 |
| sean-k-mooney | when i tested it at the end of stien it more or less worked bar the quirk | 21:33 |
| artom | The two problems were: 1. not saving the new instance_numa_topology 2. If the resource audit ran during the LM, it wouldn't pick up the migrating instance, and would remove its resources from usage | 21:34 |
| sean-k-mooney | oh ok and they are fixed in the patches you just pushed | 21:35 |
| sean-k-mooney | im going to redeploy my 2 node ovn setup to something more more useful | 21:36 |
| artom | Yeah. But like I said, I probably broke other things, just by changing some method names and removing that PinMapping object | 21:36 |
| sean-k-mooney | should i pull down your latest patches and give them a try? | 21:36 |
| artom | Not yet :) | 21:36 |
| artom | I'll email the ML when it's ready (should be this week) | 21:36 |
| artom | I know Windriver (and Cisco too, apparently?) would like to test it out | 21:37 |
| sean-k-mooney | ok i might try and test numa + sriov next week | 21:37 |
| sean-k-mooney | i havent powered up my physical server since the sriov stuff merged but it would be nice to test both together | 21:37 |
| sean-k-mooney | ideally if we can get your numa stuff merged soon ish i can then test stephens cpu pinning change too | 21:39 |
| artom | His thing was surprisingly quick | 21:41 |
| artom | Given the upgrade impact, I was expecting it to take longer | 21:41 |
| sean-k-mooney | the PCUs in placement changes | 21:41 |
| artom | Yeah | 21:42 |
| *** betherly has joined #openstack-nova | 21:42 | |
| sean-k-mooney | well the fact we dont have numa this cycle signifcatly redues the upgrade impact | 21:42 |
| sean-k-mooney | but i als dont know if the reshap is fully working yet | 21:42 |
| sean-k-mooney | i think it is but there was still one edgecase that stephen was looking into | 21:43 |
| sean-k-mooney | not with the reshap but with the schduler handeling old instance or host topologies | 21:43 |
| *** tetsuro has joined #openstack-nova | 21:45 | |
| *** betherly has quit IRC | 21:47 | |
| *** betherly has joined #openstack-nova | 21:48 | |
| * artom heads home | 21:50 | |
| mriedem | sean-k-mooney: eandersson: the Aggregate filters are not deprecated | 21:51 |
| mriedem | otherwise the docs would say so https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-filters | 21:51 |
| sean-k-mooney | mriedem: the aggreate filters dont work anymore because the limmits set in the aggreate metadata are ignored by placmenet | 21:52 |
| sean-k-mooney | so you have to set the limits on all the compute nodes or viat the placement api instead | 21:52 |
| mriedem | i realize, i wrote these docs https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#allocation-ratios | 21:52 |
| eandersson | They kinda work | 21:52 |
| eandersson | I mean they work for us because computes are misconfigured | 21:53 |
| *** betherly has quit IRC | 21:53 | |
| mriedem | i don't know why we didn't deprecate the aggregate filters when the others were deprecated, probably different timelines | 21:53 |
| *** artom has quit IRC | 21:54 | |
| sean-k-mooney | when we found that bug and melwitt sent http://lists.openstack.org/pipermail/openstack-dev/2018-January/126283.html i thought that was use signeling the depreacation | 21:54 |
| mriedem | sean-k-mooney: tempest TestJson is a remnant from when we had xml api testing | 21:54 |
| sean-k-mooney | we also have that gian warning https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#scheduling-considerations | 21:55 |
| sean-k-mooney | mriedem: ah ok | 21:55 |
| mriedem | sean-k-mooney: well i guess no one bothered to follow up and actually deprecate those filters | 21:55 |
| sean-k-mooney | i rembere there was an xml api and i never used it | 21:55 |
| mriedem | i deprecated the core/ram/disk filters since those were clearly no longer useful outside of the caching scheduler | 21:55 |
| sean-k-mooney | mriedem: ok am can we do it in train and kill them in U then? | 21:55 |
| mriedem | i would ask in the ML b/c that is a bunch of context i don't have loaded into my head right now | 21:56 |
| sean-k-mooney | right and as you noted ironic stoped reporting the cpus ram and disk so they activly were broken with ironic as of stien | 21:56 |
| mriedem | noted in my commit message you mean | 21:56 |
| sean-k-mooney | yes | 21:56 |
| mriedem | eandersson: also fyi https://review.opendev.org/#/c/640898/ - an osc command to update allocation ratios on provider aggregates | 21:57 |
| mriedem | it's been hung up in how to actually write the command using osc conventions | 21:57 |
| *** BjoernT has quit IRC | 21:59 | |
| sean-k-mooney | speaking of osc my patch for adding evacuate to osc https://review.opendev.org/#/c/643578/ | 22:01 |
| sean-k-mooney | i havent looked at it in a while but ill try to get back to it soon ish | 22:02 |
| mriedem | there are unanswered comments in there | 22:02 |
| mriedem | mainly that dansmith wanted to continue calling it evacuate to avoid different names all over the place | 22:02 |
| sean-k-mooney | i think ill mail the list and ask for feedback on the way forward vs nameing | 22:02 |
| sean-k-mooney | ya | 22:02 |
| sean-k-mooney | i am ok to do that i did care more earlier but i would prefer to land a command rather then none | 22:03 |
| sean-k-mooney | if people want too keep using evacuate then i guest that is fine. | 22:03 |
| sean-k-mooney | but ill email the list tomorrow. | 22:04 |
| sean-k-mooney | if i rememebr ill email the list about deprecating those filter too | 22:04 |
| sean-k-mooney | hum we are still sometimes getting "Could not open '/opt/stack/data/nova/instances/69509dd0-a86f-4efe-997c-986a076e4a5d/disk': No such file or directory\n"" issue in gate jobs | 22:06 |
| *** mvkr has joined #openstack-nova | 22:06 | |
| *** mriedem has quit IRC | 22:11 | |
| *** mlavalle has quit IRC | 22:16 | |
| sean-k-mooney | mdbooth: is http://logs.openstack.org/58/640258/10/check/neutron-tempest-dvr/922e7e9/controller/logs/screen-n-cpu.txt.gz#_Jul_29_21_20_26_895955 the same as the downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1445391 i noticed that we fail to resize the image way earlier | 22:20 |
| openstack | sean-k-mooney: Error: Error getting bugzilla.redhat.com bug #1445391: NotPermitted | 22:20 |
| sean-k-mooney | http://logs.openstack.org/58/640258/10/check/neutron-tempest-dvr/922e7e9/controller/logs/screen-n-cpu.txt.gz#_Jul_29_21_20_05_626653 which makes me think it might be related. | 22:20 |
| sean-k-mooney | that bug is private but the upstream version is https://bugs.launchpad.net/nova/+bug/1686703 | 22:21 |
| openstack | Launchpad bug 1686703 in OpenStack Compute (nova) "Error in finish_migration results in image deletion on source with no copy" [Undecided,Won't fix] | 22:21 |
| sean-k-mooney | i think that ^ can happen for just normal spawns too rather then requrieing resizes/migrations as it implies | 22:25 |
| sean-k-mooney | at least if the upstream gate failure is the same thing it was not a move operations that triggered it so i think it can happen anytime a resize of the image fails | 22:26 |
| sean-k-mooney | anyway night all o/ | 22:26 |
| efried | Having gone on a spec abandoning rampage, /me calls it quits. o/ | 22:27 |
| sean-k-mooney | ya i saw hehe o/ | 22:27 |
| *** tetsuro has quit IRC | 22:49 | |
| *** eharney has quit IRC | 22:51 | |
| *** tkajinam has joined #openstack-nova | 22:54 | |
| *** rcernin has joined #openstack-nova | 23:02 | |
| *** tjgresha has joined #openstack-nova | 23:08 | |
| *** bbowen has quit IRC | 23:17 | |
| *** avolkov has quit IRC | 23:40 | |
| *** huaqiang has quit IRC | 23:43 | |
| *** mdbooth_ has joined #openstack-nova | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!