| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-03 | |||
| 17:51:21 | dansmith | mriedem: while we're waiting for confirm, we still have the original instance root disk still on the source, right? | |
| 17:52:13 | mriedem | per v2 of the spec i said we destroy the guest | |
| 17:52:23 | mriedem | on revert we re-spawn it | |
| 17:52:53 | dansmith | destroy, but does that mean delete too? | |
| 17:52:56 | mriedem | i went the driver.destroy route because that unplugs vifs and disconnects volumes on the source host | |
| 17:53:02 | dansmith | right, saw that | |
| 17:53:18 | dansmith | was not sure that would delete the image though as I thought there's a flag for that and was thinking maybe you were planning to not | |
| 17:54:16 | mriedem | that driver.destroy method has a destroy_disks flag which defaults to True, | |
| 17:54:59 | mriedem | which deletes the instance path, | |
| 17:55:04 | mriedem | which is where the root disk image is right? | |
| 17:55:04 | dansmith | okay let me finish my comment on v2 and you can see what I'm asking | |
| 17:55:22 | dansmith | yes | |
| 17:55:46 | dansmith | mriedem: look at my last two comments just now | |
| 17:56:17 | mriedem | i think the main difference between destroy and migrate_disk_and_power_off is that migrate_disk_and_power_off powers off the instance rather than destroy it (and copies the disks obviously), it also disconnects volumes like destroy, but doesn't unplug vifs for some weird reason | |
| 18:04:06 | dansmith | mriedem: added a few more comments, but I think if you fix the image question I'll be ready to +2 | |
| 18:04:30 | mriedem | replying to the first set | |
| 18:06:48 | openstackgerrit | Ifat Afek proposed openstack/nova master: The field instance_name was added to InstanceCreatePayload https://review.openstack.org/627967 | |
| 18:09:08 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120 | |
| 18:09:08 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 18:09:09 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 18:09:09 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 18:17:48 | ade_lee | mriedem, hey is the log with the privsep logging on (I think) -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz | |
| 18:18:11 | ade_lee | mriedem, I do see this -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_25_532237 | |
| 18:18:45 | ade_lee | mriedem, and also this -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_27_635858 | |
| 18:21:07 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: AMD SEV: address final feedback received prior to merge https://review.openstack.org/628252 | |
| 18:22:59 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: AMD SEV: address final feedback received prior to merge https://review.openstack.org/628252 | |
| 18:37:53 | mriedem | ade_lee: yeah this http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_25_525734 | |
| 18:38:16 | mriedem | looks like we have a classic circular import | |
| 18:40:20 | mriedem | ade_lee: yeah it's this change https://github.com/openstack/nova/commit/26521718bdba3bccbf6270e26b76754c26304658#diff-31323cc5d9a493e21871761c5051db7c | |
| 18:40:25 | mriedem | merged on dec 8 which is when the failures started | |
| 18:42:32 | mriedem | i need to wrap up replying to comments on a spec and then i can push a change to see if i can fix that | |
| 18:42:55 | dansmith | why is tripleo the only thing hitting that I wonder? | |
| 18:44:10 | mriedem | that lvm thing? it's not | |
| 18:44:14 | mriedem | the nova-lvm job is busted by it | |
| 18:50:40 | dansmith | oh okay | |
| 18:51:23 | dansmith | first saw it come up in #tripleo so I just assumed | |
| 19:03:46 | mriedem | dansmith: replies inline https://review.openstack.org/#/c/616037/ thanks - seems like non-drastic changes | |
| 19:04:26 | mriedem | maybe i'll change that 'open questions' section to 'known issues' to denote things we know about but don't really care about right now and could be dealt with later if necesary | |
| 19:08:18 | mriedem | jaypipes: so in yonglihe's show server topology spec, your alternative is the GET /servers/{server_id}/topology which would just be NUMA info (not pci devices) and admin-only by default? | |
| 19:08:57 | jaypipes | mriedem: right | |
| 19:09:18 | jaypipes | mriedem: with work on a /devices endpoint done in a separate spec (with efried's help) | |
| 19:10:02 | mriedem | i believe i said in the ML thread that i was ok with /diagnostics or a sub-resource, as long as it wasn't something shoe-horned into the normal response body (GET /servers/{server_id}) or list (GET /servers or GET /servers/detail) | |
| 19:10:13 | mriedem | so whatever | |
| 19:12:09 | mriedem | replied to the ML | |
| 19:12:17 | dansmith | mriedem: yep, just need to fix the fact that you're deleting all the original copies of the instance in case of rollback and then I'm good | |
| 19:12:42 | mriedem | i eagerly await the spec proposal in 12 months to include GET /servers/{server_id}/topology info in GET /servers/{server_id} and GET /servers/detail output | |
| 19:12:48 | mriedem | because 2 api calls is hard | |
| 19:13:57 | jaypipes | mriedem: well, by that point, we'll have changed everything to GraphQL so we're all good. | |
| 19:15:08 | ade_lee | mriedem, thanks! | |
| 19:21:41 | cdent | something something pabst blue ribbon | |
| 19:35:47 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116 | |
| 19:40:21 | openstackgerrit | Chris Dent proposed openstack/nova master: Switch to using os-resource-classes https://review.openstack.org/628278 | |
| 20:38:21 | cfriesen | when advertising new traits (specifically the COMPUTE_SECURITY_TPM_2_0 trait), does the trait need to be added to some standard list first? | |
| 20:40:59 | cdent | cfriesen: you mean placement related traits or other kinds of traits? | |
| 20:41:13 | cfriesen | placement | |
| 20:41:40 | cfriesen | does it need to get added to os_traits first or something? | |
| 20:41:43 | cdent | to create a new standard trait it gets added to the os-traits lib: http://git.openstack.org/cgit/openstack/os-traits | |
| 20:41:58 | cdent | and then the code which uses the added trait depends on the release of the lib that includes it | |
| 20:42:55 | cfriesen | okay, makes sense. for the one I mentioned above, would that go in os_traits/compute/security.py then? with TRAITS=['TPM_2_0"] as the content? | |
| 20:43:08 | cdent | lemme confirm, one sec | |
| 20:43:13 | sean-k-mooney1 | cfriesen: any trait not defiend in os-traitns must start with CUSTOM_ | |
| 20:43:19 | melwitt | o/ | |
| 20:43:38 | cfriesen | sean-k-mooney1: yeah...the intent is for this to be a standard trait, so I think we need to add it to os_traits | |
| 20:43:59 | cdent | cfriesen: simple answer to you where and content question is "yes" | |
| 20:44:06 | sean-k-mooney1 | yes you do i had a patch for that i abandons over a year ago | |
| 20:44:09 | cfriesen | cdent: sweet, thanks | |
| 20:44:36 | cdent | you're welcome | |
| 20:45:19 | sean-k-mooney1 | cfriesen: https://review.openstack.org/#/c/514712/3/os_traits/hw/platform/security.py | |
| 20:46:15 | sean-k-mooney1 | melwitt: o/ happy new year | |
| 20:46:48 | melwitt | sean-k-mooney1: happy new year | |
| 20:47:03 | cdent | sean-k-mooney1, cfriesen is it COMPUTE or HW? | |
| 20:47:22 | cfriesen | so in the spec we have it as COMPUTE_SECURITY_TPM_2_0 | |
| 20:47:45 | cfriesen | at the time of sean's change I don't think the "compute" subdirectory existed yet | |
| 20:48:30 | sean-k-mooney1 | cdent: my patch was from 2017 so the example is in the wong folder but as cfriesen said the spec says COMPUTE_SECURITY_TPM_2_0 | |
| 20:50:42 | mriedem | melwitt: i'm out next week so if you want me to review the counting quotas from placement spec after updates, you probably need to make those soonish https://review.openstack.org/#/c/509042/ | |
| 20:51:08 | mriedem | i made a lot of comments but i'm not sure there is anything earth shattering in there | |
| 20:51:44 | sean-k-mooney1 | cdent: i tink where we left the disucstion was compute traits did not require hardware an hypervior that can emulate a tpm can advertise COMPUTE_SECURITY_TPM_2_0 but HW_SECURITY_TPM_2_0 would be resrved for futur use to signify that the host has a tpm that supports v2 | |
| 20:51:55 | melwitt | mriedem: thank you for the reminder. I'll go through and reply/update today | |
| 20:56:31 | melwitt | nova meeting in 4 minutes | |
| 21:02:49 | mriedem | dansmith: forgot to ask earlier but was hoping you could reply to http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001112.html and if there is compromise we can update the spec and move forward before the freeze | |
| 21:07:34 | dansmith | mriedem: ugh | |
| 21:08:34 | dansmith | mriedem: can we discuss tomorrow? I'm guessing I'm not really going to be happy with any of the options, but I need to page all that in before I will know I guess | |
| 21:09:17 | mriedem | sure | |
| 21:21:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix circular import in nova.privsep.utils https://review.openstack.org/628302 | |
| 21:43:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Run nova-lvm job on nova/privsep/* changes https://review.openstack.org/628306 | |
| 21:46:04 | mriedem | ade_lee: ^ | |
| 21:47:27 | cfriesen | I'm looking for input on https://review.openstack.org/#/c/618542...for the "quota:" stuff that is defined in https://docs.openstack.org/nova/latest/user/flavors.html but might only apply to one or two hypervisors, does it make sense to enforce the rules even if the instance might end up on a hypervisor that ignores those extra-specs? | |
| 21:47:47 | sean-k-mooney1 | i was going to mention https://review.openstack.org/#/c/591607/ for open discussion. melwitt: looks like the ordering was corrected | |
| 21:48:59 | sean-k-mooney1 | ah the parent patch has a -1 while they work on functional tests | |
| 21:49:08 | sean-k-mooney1 | nevermind | |
| 21:50:01 | melwitt | sean-k-mooney1: ah, ok | |
| 21:51:18 | melwitt | I saw some discussion in gerrit | |
| 21:52:27 | ade_lee | mriedem, thanks! | |
| 21:57:57 | dansmith | mriedem: there, I replied | |
| 21:58:34 | mriedem | <3 | |
| 22:20:28 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 22:20:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106 | |
| 22:20:52 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110 | |
| 22:21:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix circular import in nova.privsep.utils https://review.openstack.org/628302 | |
| 22:21:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Run nova-lvm job on nova/privsep/* changes https://review.openstack.org/628306 | |