Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-29
04:21:06 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.
06:19:51 openstackgerrit pengyuesheng proposed openstack/os-vif master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/672857
07:32:46 kashyap alex_xu: Morning, will check
07:43:13 kashyap alex_xu: On that machine type question for Windows --
07:43:43 kashyap alex_xu: ... I don't quite parse your question. The answer is "it depends"
07:44:59 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:46:04 alex_xu kashyap: sorry, I didn't describe clearly
07:46:41 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:48:36 kashyap alex_xu: You changed it in nova.conf, and then stop + started the windows guest?
07:48:49 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:52 alex_xu kashyap: yes
07:49:32 kashyap alex_xu: Hmm, let me check with another QEMU guy
07:53:40 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:54:16 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM - Verify NOVA_USE_SERVICE_TOKEN=True in the Nova gate https://review.opendev.org/673227
07:55:01 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:30 kashyap alex_xu: And did the instance boot or not, in your test?
07:55:50 alex_xu kashyap: yes, i think so
07:56:25 kashyap alex_xu: Then, isn't it a question for Microsoft? :-)
07:56:39 alex_xu hah
07:57:54 kashyap alex_xu: https://support.microsoft.com/en-us/help/20530/windows-10-reactivating-after-hardware-change
07:58:14 kashyap So:
07:58:16 kashyap [quote]
07:58:17 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:22 kashyap [/quote]
07:59:06 kashyap peterx: So the answer is, yes, it will affect -- because changing machine type is similar to changing your motherboard
07:59:34 alex_xu kashyap: so I'm thinking whether we should have a release upgrade note for the operator running windows at least
08:00:03 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:48 kashyap "not trouble", but we should be explicit - that you might have to reactivate licensing keys
08:02:04 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:13 kashyap Or by "we" are you referring to upstream?
08:02:20 openstackgerrit Lee Yarwood proposed openstack/nova master: Get rid of args to RBDDriver.__init__() https://review.opendev.org/668564
08:02:33 alex_xu kashyap: referring to upstream
08:02:47 alex_xu intel don't have oepnstack variant
08:02:49 kashyap alex_xu: No, we didn't change upstream machine type - what makes you say so?
08:03:28 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:31 alex_xu kashyap: sorry, no the upstream, the patch https://review.opendev.org/670189 changed
08:03:48 kashyap alex_xu: Which exactly line are you referring to?
08:04:15 kashyap alex_xu: Ah, hang on.
08:04:24 kashyap That patch was fixing a bad assumption
08:05:05 alex_xu kashyap: https://review.opendev.org/#/c/670189/14/nova/virt/libvirt/host.py@745
08:05:08 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:39 alex_xu emm...
08:05:51 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove native LUKS compat code https://review.opendev.org/669121
08:06:02 kashyap alex_xu: That line (745) was only removing an assumption. It is not changing anything.
08:06:47 alex_xu ah....
08:06:58 kashyap aspiers: When you're about, some discussion in the scrollback on that harden getDomainCapabilities() patch.
08:07:02 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: flatten rbd images when unshelving an instance https://review.opendev.org/668123
08:07:03 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: DNM - Test rbd unshelve fix on stable queens https://review.opendev.org/668142
08:08:51 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:09:08 alex_xu kashyap: ah, I know where I missunderstand now
08:10:55 kashyap :-)
08:11:54 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:12:25 alex_xu yes, nothing required
08:14:06 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:29 alex_xu thanks
08:18:39 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:54 brinzhang tssurya: Even if you don't add 2.75 microversion, will it affect the functionality of novaclient?
08:19:19 tssurya brinzhang: if I don't update the client version, I cannot use the server side changes
08:19:21 tssurya that
08:19:25 tssurya is why we update
08:19:47 brinzhang If it's true, I think my understanding is biased, I will remove that -1. thanks
08:20:11 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:19 tssurya that is also why we have no tests
08:20:48 tssurya brinzhang: thanks , next time you have a question feel free to just ask without having to give a vote :)
08:21:45 brinzhang Yeah, because of on weekends, so... I will care :P
08:24:29 brinzhang tssurya: If we not add this change, it will be raise 404? or anonther?
08:27:21 tssurya brinzhang: https://docs.openstack.org/python-novaclient/latest/contributor/microversions.html
08:29:36 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:30:31 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:46 tssurya ^ its mentioned in the docs
08:31:56 brinzhang Yeah, I know this, I think it will be raise 406.
08:32:11 brinzhang {
08:32:11 brinzhang "computeFault":{
08:32:11 brinzhang "message": "Version 2.78 is not supported by the API. Minimum is 2.1 and maximum is 2.76.",
08:32:11 brinzhang "code": 406
08:32:11 brinzhang }
08:32:12 brinzhang }
08:32:44 kashyap alex_xu: Thank you for ACKing, much appreciated.
08:33:40 tssurya brinzhang: no the server supports 2.75, we are trying to make the client support it as well
08:33:59 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:34:22 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:44:45 alex_xu kashyap: np
08:50:31 brinzhang tssurya: about https://review.opendev.org/#/c/645611/, replyed with comment.
09:44:35 aspiers kashyap: here
09:44:59 kashyap aspiers: Hi, go straight to my update in the Gerrit change.
09:45:07 kashyap aspiers: (Saves you time from reading IRC scrollback)
09:45:12 aspiers OK
09:46:46 aspiers kashyap: not sure if there's a question for me? looks like it's all clarified?
09:48:14 kashyap aspiers: Yeah, no more question. Was more of an FYI
09:48:28 aspiers kashyap: OK thanks. BTW I need your review on https://review.opendev.org/#/c/673151/ more than anyone else's :)
09:48:47 aspiers That ties to the scrollback I wrote on Sat
09:48:55 kashyap aspiers: Will do. First trying to write some code to parse getDomainCapabilities() for 'efi' bits :D
09:49:03 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:27 kashyap aspiers: What scrollback from Sat? I missed
09:49:48 aspiers http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-27.log.html#t2019-07-27T18:15:17
09:50:40 kashyap aspiers: BTW, funnily enough, I have a "vested interest" to review that patch. Why?
09:51:10 kashyap aspiers: ... I too have a need for domain capabilities for 'q35' for Secure Boot
09:51:24 kashyap (Secure Boot for KVM/QEMU _mandates_ 'q35')
09:51:40 kashyap aspiers: I will get to this interesting patch today.
09:52:12 aspiers kashyap: Yeah, this is not a huge coincidence, since SEV mandates UEFI via OVMF

Earlier   Later