| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-25 | |||
| 23:19:28 | aspiers | libvirt's virConnectGetDomainCapabilities() API requires specifying a particular arch and machine type | |
| 23:19:52 | mriedem | aspiers: hook up with kash | |
| 23:19:53 | mriedem | kashyap | |
| 23:19:57 | aspiers | mriedem: thanks | |
| 23:20:30 | aspiers | so the results presumably could vary per architecture and machine type, although in practice it seems that if the SEV feature is supported, it is supported across all (arch, machine type) pairs the host provides | |
| 23:21:31 | aspiers | but in order to detect the SEV capability (and provide a trait), this API call needs to be done during initHost() where arch/machtype is not known, rather than just before booting an instance when it is known | |
| 23:22:21 | aspiers | since currently this getDomainCapabilities API call is only used for SEV detection and nothing else, I could hardcode it to x86_64 and a single machine type | |
| 23:22:27 | aspiers | but that seems a bit ugly | |
| 23:23:15 | aspiers | or I could call it once for each (arch, machine type) the host provides, and then if SEV is supported for any one of those tuples, mark the SEV capability as supported for the host | |
| 23:24:37 | aspiers | but kashyap isn't currently here it seems ... | |
| 23:32:32 | melwitt | kashyap is EU time zone | |
| 23:33:38 | aspiers | melwitt: OK thanks | |
| 23:36:41 | cfriesen | aspiers: don't we specify arch in the nova config? | |
| 23:37:37 | aspiers | cfriesen: I don't think so | |
| 23:38:46 | aspiers | but actually it's only one of two possibilities in the libvirt driver | |
| 23:39:13 | aspiers | cfriesen: https://github.com/openstack/nova/blob/c7f0d160e4df95cc82706bcd8c4a9890a4dfeb51/nova/virt/libvirt/driver.py#L438 | |
| 23:39:34 | aspiers | so I can iterate over those two, but that still leaves the question of machine type | |
| 23:39:44 | aspiers | of which there are a zillion | |
| 23:39:52 | cfriesen | aspiers: ah...I was actually thinking of the "hw_machine_type" config option | |
| 23:40:02 | aspiers | ah yeah, that's different | |
| 23:40:14 | aspiers | and that's only a default | |
| 23:40:18 | cfriesen | right | |
| 23:40:40 | aspiers | but it seems wrong to call the virConnectGetDomainCapabilities API twice for each known machine-type | |
| 23:40:55 | aspiers | well not wrong, but inelegant at least | |
| 23:41:00 | aspiers | and expensive | |
| 23:41:10 | aspiers | not that initHost() happens often, but still ... | |
| 23:41:10 | cfriesen | that is kind of icky. what if you stopped as soon as you got SEV supported for one machine type? | |
| 23:41:48 | aspiers | well sure, could do that, but if I'm going to hardcode an assumption that this API call is only used for SEV capability detection then I could make it even simpler | |
| 23:42:54 | cfriesen | I think you could just make a "can host support SEV" call which just checks one known-to-be-valid config | |
| 23:43:03 | aspiers | exactly | |
| 23:43:19 | aspiers | but then what if something else in the future needs other data from this API? | |
| 23:43:29 | aspiers | or am I prematurely optimizing :) | |
| 23:43:55 | cfriesen | which API exactly are you talking about? | |
| 23:44:03 | aspiers | the one above | |
| 23:44:13 | aspiers | virConnectGetDomainCapabilities | |
| 23:44:37 | aspiers | actually I think I've just discovered a bug in libvirt | |
| 23:45:03 | aspiers | virsh domcapabilities --virttype kvm --emulatorbin /usr/bin/qemu-kvm --arch x86_64 --machine pc-i440fx-1.4 | xq /domainCapabilities/features/sev/@supported actually returns 'yes' | |
| 23:45:19 | aspiers | but SEV is not supported unless you use a q35 machine type | |
| 23:48:04 | cfriesen | I think you could just add a little helper function in virt/libvirt/guest.py that calls virConnectGetDomainCapabilities, then add another "is sev supported" helper function that calls the guest.py routine and is in turn called from LibvirtDriver.init_host() | |
| 23:48:54 | openstackgerrit | Chris Friesen proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| #openstack-nova - 2019-02-26 | |||
| 00:07:24 | alex_xu | mriedem: want to hear your opinion on https://review.openstack.org/#/c/634827/23/nova/objects/migrate_data.py@99 | |
| 00:08:47 | cfriesen | is it still the case that traits in image properties are specified as "trait:HW_SOME_TRAIT=required" with a colon after trait? | |
| 00:09:26 | cfriesen | alex_xu: I've uploaded a new version of the image/flavor validation commit | |
| 00:10:12 | alex_xu | cfriesen: got it, I will try second round today | |
| 00:11:26 | alex_xu | cfriesen: for your trait question http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/glance-image-traits.html | |
| 00:11:33 | alex_xu | so should be yes | |
| 00:34:21 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix resetting non-persistent fields when saving obj https://review.openstack.org/636271 | |
| 01:08:04 | mriedem | alex_xu: i'm not sure i understand the question on the review :) | |
| 01:08:39 | mriedem | are you saying, since we already have the migration context, why not just store the information there rather than pass it over rpc with the MigrateData object? | |
| 01:13:07 | alex_xu | mriedem: migration_context has the claimed_instance_numa, and we also need host numa obj, and some host configuration(like shared cpu set?). Then we pass all of those back to the src node, and src node can use existed code to generate libvirt xml. | |
| 01:14:08 | alex_xu | mriedem: the currently way in the patch is only fetching the needed back to the host node, I think that is why we hack the xml in the src node. | |
| 01:15:01 | mriedem | as far as i know this is working similar to how we handle updating the xml on the source host for things like volumes and vifs | |
| 01:15:07 | mriedem | based on data from the dest host | |
| 01:16:17 | alex_xu | yes, I agree, we already have code work as this. Just want to ensure whether we want to change that, if people really thing it is ok, then i will continue review as the current way | |
| 01:17:46 | mriedem | well, there might be better alternatives, but at this point in the release it's probably too late to try them without for sure deferring this change to train | |
| 01:17:53 | melwitt | sorrt | |
| 01:17:54 | openstackgerrit | melanie witt proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules https://review.openstack.org/638574 | |
| 01:17:54 | openstackgerrit | melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351 | |
| 01:17:55 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Add get_counts() to InstanceMappingList https://review.openstack.org/638072 | |
| 01:17:55 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 01:17:56 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 01:17:58 | melwitt | *sorry | |
| 01:18:17 | mriedem | alex_xu: i'm assuming artom has already been doing integration testing of this code too | |
| 01:18:18 | alex_xu | actually, just want you ensure whether worth to change that, which i'm not sure and hesitate :) | |
| 01:18:27 | mriedem | alex_xu: yeah i don't know either | |
| 01:18:45 | alex_xu | mriedem: yea, that is also part of my hesitate | |
| 01:19:27 | mriedem | takashin: i just have a couple of comments in https://review.openstack.org/#/c/638849/ otherwise it looks ok | |
| 01:20:10 | takashin | mriedem: Thank you. I will fix them. | |
| 01:38:00 | openstackgerrit | Merged openstack/nova master: Add unit tests for missing VirtualInterface in 2.70 os-interface https://review.openstack.org/639141 | |
| 01:39:39 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove wrong description for auto resize confirm https://review.openstack.org/638357 | |
| 01:48:45 | openstackgerrit | Merged openstack/python-novaclient master: Fix output of interface-attach command https://review.openstack.org/637677 | |
| 01:48:46 | openstackgerrit | Merged openstack/python-novaclient master: Add a note in "nova service-delete" help about deleting computes https://review.openstack.org/627637 | |
| 02:04:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669 | |
| 02:04:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source https://review.openstack.org/634827 | |
| 02:04:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.openstack.org/634828 | |
| 02:04:17 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.openstack.org/635229 | |
| 02:04:17 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.openstack.org/634605 | |
| 02:04:18 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP needs more tests] Full NUMA live migration support https://review.openstack.org/634606 | |
| 02:05:53 | artom | mriedem_afk, alex_xu, I run https://review.rdoproject.org/r/#/c/18832/ against the Nova patch series | |
| 02:06:20 | artom | It's a tempest plugin that massively subverts what tempest is for, but allows us to test stuff like this in an automated fashion | |
| 02:06:58 | artom | In there I have 3 tests for now: test that CPU pinning information is updated, test that emulator thread pinning information is updated, and test that hugepages information is updated. | |
| 02:07:28 | artom | The update I just pushed to the Nova patches passed all 3 tests | |
| 02:07:57 | artom | I'll write an ML or something, to have it in writing in a more permanent fashion | |
| 02:08:07 | artom | But for now, I'm gonna go get swole at the gym, then sleep | |
| 02:08:23 | artom | To be back harder tomorrow morning | |
| 02:52:09 | mriedem | yonglihe: alex_xu: comments in https://review.openstack.org/#/c/621474/ but i'm not sure why server_groups is a list - the server can only be in at most 1 server group | |
| 02:52:13 | mriedem | returning a list is misleading | |
| 02:52:33 | mriedem | so i would prefer to have just a key=value, e.g. server_group: <server_group_id or None> | |
| 02:52:52 | mriedem | i've also added tssurya to the review because I think we can also return the server group in the down-cell case | |
| 02:52:52 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 02:54:51 | yonglihe | mriedem, that suggested by jaypipes, history in the spec review comments. basically idea is that the group should have belong to multi groups . | |
| 02:55:42 | mriedem | "should have" is not "the way it is" | |
| 02:55:51 | mriedem | you currently cannot have a server in more than one group | |
| 02:56:04 | mriedem | i know people have tried to change the api to allow adding/removing servers to/from groups over time | |
| 02:56:07 | mriedem | but that is not implemented today | |
| 02:56:27 | mriedem | is this a list because windriver allows having a server in more than one group? | |
| 02:56:30 | mriedem | *starlingx | |
| 02:56:44 | yonglihe | no, it's not in starlingx, | |
| 02:58:22 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 02:58:39 | openstackgerrit | yenai proposed openstack/nova master: Disconnect volume when encryption is failed https://review.openstack.org/632598 | |