Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-27
21:30:06 openstackgerrit Adam Spiers proposed openstack/nova master: Enhance parsing of domain capabilities and track canonical machine types https://review.opendev.org/673151
21:30:07 openstackgerrit Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
21:30:07 openstackgerrit Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
21:30:08 openstackgerrit Adam Spiers proposed openstack/nova master: Add and to config.py https://review.opendev.org/636318
21:30:08 openstackgerrit Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334
21:30:09 openstackgerrit Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616
21:30:09 openstackgerrit Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565
22:23:43 openstackgerrit Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565
22:23:43 openstackgerrit Adam Spiers proposed openstack/nova master: Add and to config.py https://review.opendev.org/636318
22:23:44 openstackgerrit Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616
#openstack-nova - 2019-07-28
09:48:05 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336
09:50:02 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336
10:34:44 openstackgerrit Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
10:34:44 openstackgerrit Adam Spiers proposed openstack/nova master: Enhance parsing of domain capabilities and track canonical machine types https://review.opendev.org/673151
10:34:45 openstackgerrit Adam Spiers proposed openstack/nova master: Add and to config.py https://review.opendev.org/636318
10:34:45 openstackgerrit Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334
10:34:45 openstackgerrit Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
10:34:46 openstackgerrit Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565
10:34:47 openstackgerrit Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616
#openstack-nova - 2019-07-29
02:36:37 openstackgerrit Takashi NATSUME proposed openstack/nova master: Retrun 400 if invalid query parameters are specified https://review.opendev.org/670440
02:37:43 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add a live migration regression test https://review.opendev.org/641200
02:38:31 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add database schema upgrade check https://review.opendev.org/667047
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 "code": 406
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 "computeFault":{
08:32:11 brinzhang {
08:32:12 brinzhang }
08:32:44 kashyap alex_xu: Thank you for ACKing, much appreciated.

Earlier   Later