| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-25 | |||
| 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 | cfriesen | that is kind of icky. what if you stopped as soon as you got SEV supported for one machine type? | |
| 23:41:10 | aspiers | not that initHost() happens often, but still ... | |
| 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: Add online data migration for populating user_id https://review.openstack.org/633351 | |
| 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: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:55 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Add get_counts() to InstanceMappingList https://review.openstack.org/638072 | |
| 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: LM: add support for sending NUMAMigrateData to the source https://review.openstack.org/634828 | |
| 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:17 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.openstack.org/634605 | |
| 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: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 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 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: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 | |
| 02:58:58 | yonglihe | should we switch to just one UUID? | |
| 03:00:33 | mriedem | i'm also wondering why not return the server group name along with the uuid | |
| 03:00:38 | mriedem | while we're looking up the server group | |
| 03:00:50 | mriedem | i know you can get the name of the group via the GET /os-server-groups/{id} api | |
| 03:01:01 | mriedem | anyway, i'm mostly -1 because of the list | |
| 03:01:07 | mriedem | adding the name + uuid is just a thought | |
| 03:01:41 | yonglihe | people think that is redundant, uuid is enough. | |
| 03:02:52 | yonglihe | ok so we should patch the bp and rebase patch to return just UUID, along with address comments. | |
| 03:03:02 | mriedem | ugh, i see jaypipes' comment in the spec now https://review.openstack.org/#/c/612255/11/specs/stein/approved/show-server-group.rst@67 | |
| 03:03:07 | mriedem | exactly the opposite of mine :) | |
| 03:03:31 | yonglihe | should we align that? | |
| 03:04:32 | mriedem | yonglihe: can you ask about it in the mailing list? i see that my last comment in the spec was https://review.openstack.org/#/c/612255/5/specs/stein/approved/list-server-group.rst@38 | |
| 03:04:35 | mriedem | which wasn't the direction taken | |
| 03:05:44 | mriedem | i guess i was thinking something more like this based on what i just said in your patch https://review.openstack.org/#/c/612255/4/specs/stein/approved/list-server-group.rst@62 | |
| 03:06:37 | yonglihe | ok, i gonna re-open this on mail thead. | |
| 03:09:33 | mriedem | yonglihe: thanks, and sorry - but this is pretty straight-forward otherwise and i don't see a problem with getting it merged once we decide on the format | |