| *** gerrykopec has joined #openstack-nova | 00:03 | |
| *** tetsuro has joined #openstack-nova | 00:12 | |
| *** tetsuro_ has joined #openstack-nova | 00:14 | |
| *** Sundar has quit IRC | 00:14 | |
| *** tetsuro has quit IRC | 00:16 | |
| *** ttsiouts has joined #openstack-nova | 00:19 | |
| *** ttsiouts_ has joined #openstack-nova | 00:26 | |
| *** ttsiouts has quit IRC | 00:28 | |
| *** gyee has quit IRC | 00:29 | |
| *** mriedem has quit IRC | 00:30 | |
| *** ttsiouts has joined #openstack-nova | 00:34 | |
| *** dave-mccowan has joined #openstack-nova | 00:35 | |
| *** ttsiouts_ has quit IRC | 00:36 | |
| *** hemna has quit IRC | 00:37 | |
| *** hemna has joined #openstack-nova | 00:38 | |
| *** ttsiouts has quit IRC | 00:41 | |
| *** ttsiouts has joined #openstack-nova | 00:43 | |
| *** tetsuro_ has quit IRC | 00:50 | |
| *** ttsiouts has quit IRC | 00:51 | |
| *** markvoelker has joined #openstack-nova | 00:51 | |
| openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Fix a description for config_drive parameter https://review.opendev.org/653683 | 00:59 |
|---|---|---|
| *** whoami-rajat has joined #openstack-nova | 01:01 | |
| openstackgerrit | ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.opendev.org/651681 | 01:14 |
| *** ricolin has joined #openstack-nova | 01:15 | |
| openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Updates for OpenDev transition https://review.opendev.org/654429 | 01:20 |
| *** yedongcan has joined #openstack-nova | 01:31 | |
| *** takashin has joined #openstack-nova | 01:43 | |
| *** HuaChangWang has joined #openstack-nova | 01:45 | |
| mnaser | shopping an idea | 01:49 |
| mnaser | how do you feel about killing devstack. | 01:49 |
| mnaser | and replacing it by a deployment tool | 01:49 |
| *** brinzhang has joined #openstack-nova | 01:50 | |
| *** nicolasbock has quit IRC | 02:04 | |
| *** dakshina-ilangov has quit IRC | 02:05 | |
| *** _erlon_ has quit IRC | 02:05 | |
| openstackgerrit | zhongshengping proposed openstack/nova master: Replace git.openstack.org URLs with opendev.org URLs https://review.opendev.org/654398 | 02:08 |
| *** cfriesen has quit IRC | 02:11 | |
| *** HuaChangWang has quit IRC | 02:30 | |
| *** lbragstad has joined #openstack-nova | 02:39 | |
| lbragstad | efried get it figured out? | 02:40 |
| lbragstad | efried as far as i know, the duplicated sessions were completely removed from the schedule | 02:41 |
| lbragstad | https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/increasing-api-accessibility-with-granular-policy-and-default-roles is the one i have on my schedule | 02:43 |
| *** dklyle has quit IRC | 02:45 | |
| *** dklyle has joined #openstack-nova | 02:46 | |
| *** ttsiouts has joined #openstack-nova | 02:48 | |
| *** dave-mccowan has quit IRC | 02:48 | |
| *** takashin has left #openstack-nova | 03:03 | |
| *** hongbin has joined #openstack-nova | 03:10 | |
| *** cfriesen has joined #openstack-nova | 03:17 | |
| *** ttsiouts has quit IRC | 03:21 | |
| *** cfriesen has quit IRC | 03:32 | |
| *** lpetrut has joined #openstack-nova | 03:50 | |
| *** lpetrut has quit IRC | 04:13 | |
| openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: Pass on region when we don't have a valid ironic endpoint https://review.opendev.org/654692 | 04:15 |
| openstackgerrit | Merged openstack/nova stable/rocky: libvirt: set device address tag only if setting disk unit https://review.opendev.org/653511 | 04:16 |
| eandersson | efried, ^ we could honestly just pass on the region, since region_name is only actually consumed if endpoint or session is missing. | 04:16 |
| eandersson | But I am fine just passing it on when we don't have an endpoint. | 04:17 |
| *** udesale has joined #openstack-nova | 04:22 | |
| *** hongbin has quit IRC | 04:33 | |
| *** lbragstad has quit IRC | 04:47 | |
| *** ratailor has joined #openstack-nova | 04:56 | |
| *** markvoelker has quit IRC | 04:57 | |
| *** sridharg has joined #openstack-nova | 05:11 | |
| *** jaosorior has joined #openstack-nova | 05:17 | |
| *** ttsiouts has joined #openstack-nova | 05:18 | |
| *** Luzi has joined #openstack-nova | 05:36 | |
| *** ivve has joined #openstack-nova | 05:38 | |
| *** ttsiouts_ has joined #openstack-nova | 05:43 | |
| *** ttsiouts has quit IRC | 05:45 | |
| *** ccamacho has quit IRC | 05:46 | |
| *** ttsiouts has joined #openstack-nova | 05:47 | |
| *** ttsiouts_ has quit IRC | 05:49 | |
| *** ttsiouts has quit IRC | 05:52 | |
| *** lpetrut has joined #openstack-nova | 06:00 | |
| *** pcaruana has joined #openstack-nova | 06:06 | |
| *** dpawlik has joined #openstack-nova | 06:18 | |
| *** slaweq has joined #openstack-nova | 06:21 | |
| *** udesale has quit IRC | 06:35 | |
| *** udesale has joined #openstack-nova | 06:37 | |
| *** udesale has quit IRC | 06:44 | |
| *** udesale has joined #openstack-nova | 06:44 | |
| *** markvoelker has joined #openstack-nova | 06:52 | |
| *** ircuser-1 has quit IRC | 06:53 | |
| *** ircuser-1 has joined #openstack-nova | 06:56 | |
| *** ccamacho has joined #openstack-nova | 07:13 | |
| *** lee1 has joined #openstack-nova | 07:17 | |
| *** tosky has joined #openstack-nova | 07:17 | |
| *** udesale has quit IRC | 07:18 | |
| *** lee1 is now known as lyarwood | 07:18 | |
| *** udesale has joined #openstack-nova | 07:19 | |
| *** ttsiouts has joined #openstack-nova | 07:22 | |
| *** ccamacho has quit IRC | 07:27 | |
| *** ccamacho has joined #openstack-nova | 07:27 | |
| openstackgerrit | Boxiang Zhu proposed openstack/python-novaclient master: Add host and hypervisor_hostname to create servers https://review.opendev.org/647671 | 07:37 |
| *** kashyap has joined #openstack-nova | 07:46 | |
| kashyap | efried: Was on PTO yesterday. Just saw the scroll. I will address yours and mriedem's questions on that "CPU selection..." spec. | 07:52 |
| kashyap | efried: I tried to be conscious to "not assume anything", _still_ my phrasing seems to be not sufficiently clear enough. Will rework. | 07:54 |
| *** dtantsur|afk is now known as dtantsur | 07:55 | |
| sean-k-mooney | kashyap: i think the issue is you assumed people understand and follow libvirt and did not present the usecase in terms of nova but instead present it as libvirt has this new api we shoudl use it with the assumtion people knew what libvirt api we currently use and what features it is used for | 07:55 |
| kashyap | sean-k-mooney: I partly disagree. I didn't "assume" it that way. | 07:56 |
| kashyap | How much more clearer can you phrase this: | 07:56 |
| kashyap | [quote] | 07:56 |
| kashyap | [/quote] | 07:57 |
| kashyap | sean-k-mooney: My comment on PS-4, on: Apr 9 6:38 PM | 07:57 |
| sean-k-mooney | that did not rendeer from me | 07:57 |
| sean-k-mooney | i just see open and close quotes | 07:58 |
| kashyap | I can add additional details and answer questions -- sure. But what is already there is sufficiently clear enough, no? | 07:58 |
| kashyap | sean-k-mooney: Yeah, that was intentional; sorry :-) I didn't paste anything | 07:58 |
| kashyap | (Because I didn't wanted to paste the large comment from the change) | 07:58 |
| kashyap | sean-k-mooney: See my comment on PS-4: https://review.opendev.org/#/c/645814/4 | 07:58 |
| *** luksky has joined #openstack-nova | 07:59 | |
| sean-k-mooney | ya but the poblem with that comment is you dont say how nova will handel it | 08:00 |
| kashyap | sean-k-mooney: I told Nova's guest CPU selection is lacking. And even provided a rough example like: | 08:00 |
| kashyap | "Is this combination of IvyBridge + 'pcid' & 'pdpe1gb' supported by KVM, QEMU and libvirt on the host?" | 08:00 |
| kashyap | sean-k-mooney: Yes, that part, I will addres. | 08:00 |
| sean-k-mooney | e.g. will the agent refuse to start | 08:00 |
| kashyap | Right, will address them, once I finish addressing comments on the Secure Boot spec. | 08:00 |
| sean-k-mooney | by the way nova has no cpu selection logic outside of host-model so its not really lacking as non existent | 08:01 |
| sean-k-mooney | i just found out that weechat has mouse support and gesture ... | 08:02 |
| sean-k-mooney | i dont think i like them | 08:03 |
| kashyap | sean-k-mooney: I'm of course aware that we default to 'host-model'. That's not the point. When I say "CPU selection", it also means CPU model + features (obviously). | 08:04 |
| sean-k-mooney | kashyap: for what its worth i only barely followed what you were proposing in that spec. | 08:04 |
| kashyap | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3948,#L3957 | 08:04 |
| sean-k-mooney | kashyap: yes but that is hardcoded effectivly via the config | 08:04 |
| sean-k-mooney | its not nova making the selection in this case its the operator | 08:04 |
| kashyap | (I will rephrase the spec with a couple more examples.) | 08:04 |
| kashyap | (Not entirely, some bits. While adding additional details.) | 08:05 |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.opendev.org/645520 | 08:05 |
| sean-k-mooney | one thing i was wondering is do you want to merge this spec with https://review.opendev.org/#/c/642030/ | 08:06 |
| kashyap | No, I want to keep it separate. | 08:06 |
| sean-k-mooney | the current one has no end user visable impact | 08:06 |
| sean-k-mooney | ok | 08:06 |
| kashyap | As I'm not even sure if we should do: https://review.opendev.org/#/c/642030/ | 08:06 |
| sean-k-mooney | ya i guessed that is why | 08:06 |
| sean-k-mooney | if we do implment the second spec https://review.opendev.org/#/c/642030/ it will depend on this new api | 08:07 |
| sean-k-mooney | or it should use the new api | 08:07 |
| kashyap | Also, not every spec needs to be "user visible". (That said, in this case, it _is_ "operator visible" in a way. Will save the write-up for the spec) | 08:07 |
| *** helenafm has joined #openstack-nova | 08:07 | |
| sean-k-mooney | well its not other then the agent will stop if its not compatible | 08:08 |
| *** rpittau|afk is now known as rpittau | 08:08 | |
| sean-k-mooney | there is not rest api changes | 08:08 |
| sean-k-mooney | or traits changes | 08:08 |
| kashyap | sean-k-mooney: It is not just about 'compat check'. The resulting CPU + flags will be more _useful_ and _useable_ | 08:09 |
| sean-k-mooney | how | 08:09 |
| kashyap | I explained it in the spec. I wonder if you even read that. | 08:10 |
| sean-k-mooney | the set of flag we get back for what the host support wont change | 08:10 |
| sean-k-mooney | yes i did | 08:10 |
| sean-k-mooney | you did not explain it well | 08:10 |
| sean-k-mooney | in terms of how its more useful to nova | 08:10 |
| sean-k-mooney | beyond we can as if the value in the config are valid | 08:10 |
| kashyap | sean-k-mooney: Did you read this at all? | 08:12 |
| kashyap | [quote] | 08:12 |
| kashyap | - While determining guest CPU models, Nova can take into account several other aspects, e.g. the type of virtualization (pure emulation vs. hardware-accelerated), QEMU binary's capabilities, guest machine type, and CPU architcture to construct a better-informed guest CPU. | 08:12 |
| kashyap | [/quote] | 08:12 |
| kashyap | What is unclear about that? | 08:12 |
| kashyap | Your "how" is answered by the above. | 08:12 |
| sean-k-mooney | what is uncleare is what does "better-informned guest cpu" mean | 08:12 |
| *** tssurya has joined #openstack-nova | 08:12 | |
| sean-k-mooney | will the cpu flag in the guest (via lscpu) change | 08:13 |
| kashyap | Please wait. | 08:13 |
| kashyap | One thing at a time. | 08:13 |
| kashyap | You get a "better-informed guest CPU" because: the newer API, when calculating baseline, baselineHypervisorCPU() will *filter out* CPU features that are not supported by QEMU on the host. | 08:14 |
| * kashyap --> goes heads-down; be back later | 08:15 | |
| sean-k-mooney | o/ | 08:16 |
| *** jangutter has joined #openstack-nova | 08:18 | |
| *** ttsiouts_ has joined #openstack-nova | 08:21 | |
| *** ttsiouts has quit IRC | 08:23 | |
| *** dikonoor has joined #openstack-nova | 08:27 | |
| *** derekh has joined #openstack-nova | 08:28 | |
| *** yedongcan has quit IRC | 08:32 | |
| *** yedongcan has joined #openstack-nova | 08:32 | |
| *** tkajinam has quit IRC | 08:42 | |
| *** gibi_off is now known as gibi | 08:47 | |
| openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.opendev.org/636132 | 08:52 |
| *** ttsiouts has joined #openstack-nova | 08:53 | |
| *** jiaopengju has joined #openstack-nova | 08:53 | |
| *** Dinesh_Bhor has quit IRC | 08:55 | |
| *** yankcrime has joined #openstack-nova | 08:55 | |
| *** ttsiouts_ has quit IRC | 08:56 | |
| *** dikonoor has quit IRC | 08:56 | |
| *** dikonoor has joined #openstack-nova | 09:09 | |
| *** phasespace has joined #openstack-nova | 09:24 | |
| *** ratailor_ has joined #openstack-nova | 09:25 | |
| *** ratailor has quit IRC | 09:27 | |
| *** lpetrut has quit IRC | 09:30 | |
| *** jaosorior has quit IRC | 09:31 | |
| *** jaosorior has joined #openstack-nova | 10:14 | |
| *** threestrands has quit IRC | 10:15 | |
| *** NewBruce0 has quit IRC | 10:39 | |
| *** NewBruce has joined #openstack-nova | 10:39 | |
| *** tbachman has quit IRC | 10:40 | |
| *** tetsuro has joined #openstack-nova | 10:56 | |
| *** nicolasbock has joined #openstack-nova | 11:00 | |
| *** jaosorior has quit IRC | 11:00 | |
| *** jaosorior has joined #openstack-nova | 11:02 | |
| *** dikonoor has quit IRC | 11:03 | |
| *** tetsuro has quit IRC | 11:03 | |
| *** dikonoor has joined #openstack-nova | 11:06 | |
| alex_xu | emm...US evus enrollment not compatible with google chrome :( | 11:21 |
| *** yedongcan has left #openstack-nova | 11:27 | |
| *** belmoreira has joined #openstack-nova | 11:45 | |
| jangutter | alex_xu: Could be worse, according to https://help.cbp.gov/app/answers/detail/a_id/1090/~/technical-difficulties-submitting-my-esta-application the ESTA system supports IE 5 SP 2, or Netscape 6.2 | 11:46 |
| sean-k-mooney | jangutter: firefox worked for me but ya government sites then to be updated infrequently | 11:53 |
| *** tbachman has joined #openstack-nova | 11:55 | |
| *** panda is now known as panda|lunch | 11:57 | |
| *** markvoelker has quit IRC | 12:01 | |
| *** jiaopengju has quit IRC | 12:01 | |
| jangutter | (the versions of Netscape and IE probably correspond to the date that the original software was delivered by the contractors.) | 12:01 |
| *** jiaopengju has joined #openstack-nova | 12:02 | |
| sean-k-mooney | ya the current maintainer (if there is one) proably has never seen that page | 12:02 |
| *** jiaopengju has quit IRC | 12:02 | |
| *** jiaopengju has joined #openstack-nova | 12:03 | |
| *** jiaopengju has quit IRC | 12:04 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove unused param from _fill_provider_mapping https://review.opendev.org/655107 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move _fill_provider_mapping to the scheduler_utils https://review.opendev.org/655108 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: handle port allocation during migration https://review.opendev.org/655112 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113 | 12:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114 | 12:04 |
| *** jiaopengju has joined #openstack-nova | 12:04 | |
| *** mchlumsky has joined #openstack-nova | 12:06 | |
| *** mriedem has joined #openstack-nova | 12:11 | |
| mriedem | i need a stable core to hit this queens backport https://review.opendev.org/#/c/640198/ | 12:13 |
| *** jiaopengju_1 has joined #openstack-nova | 12:16 | |
| *** brinzhang has quit IRC | 12:18 | |
| *** jiaopengju has quit IRC | 12:19 | |
| openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.opendev.org/652197 | 12:22 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | 12:26 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't run tempest/devstack jobs on nova/test.py only changes https://review.opendev.org/655121 | 12:26 |
| aspiers | vcpu:1 | 12:32 |
| aspiers | oops | 12:32 |
| *** mchlumsky has quit IRC | 12:38 | |
| *** mchlumsky has joined #openstack-nova | 12:38 | |
| *** tobias-urdin has joined #openstack-nova | 12:39 | |
| kashyap | aspiers: When you're about -- remind me again, are you planning to cache the result of getDomainCapabilities(), as part of SEV work? | 12:40 |
| aspiers | kashyap: not just planning, but https://review.opendev.org/#/c/633855/12/nova/virt/libvirt/host.py already does that | 12:41 |
| *** arshad777 has joined #openstack-nova | 12:41 | |
| kashyap | aspiers: Ah: | 12:41 |
| kashyap | domain_caps[arch][machine_type] = \ | 12:41 |
| kashyap | self._get_domain_capabilities(emulator_bin, arch, | 12:41 |
| kashyap | machine_type, virt_type) | 12:41 |
| aspiers | right | 12:42 |
| kashyap | aspiers: So something to consider: | 12:42 |
| kashyap | aspiers: This morning, while talking to a libvirt developer (Michal Privoznik), he was saying: caching domain capabilities probably doesn't make sense -- because it will be outdated everytime libvirt and QEMU are updated. | 12:43 |
| arshad777 | Hi everyone: I am trying to create an instance on multi-node setup. But getting error "no valid host found". For detail refer url http://paste.openstack.org/show/749631/ | 12:43 |
| arshad777 | compute services are running. Please refer url http://paste.openstack.org/show/749630/ for more detail | 12:43 |
| aspiers | kashyap: it would only be cached in the running service, not persisted to disk | 12:43 |
| kashyap | aspiers: As we know, there are 4 input values (path to qemu binary, guest architecture, machine type and virt type) -- so any change if one of them and we get a different set of capabilities | 12:43 |
| kashyap | aspiers: Noted | 12:44 |
| aspiers | kashyap: if a compute node's libvirt/QEMU gets updated, it seems reasonable to expect that nova-compute will get restarted too | 12:44 |
| aspiers | or at least for major updates | 12:44 |
| kashyap | aspiers: Yes, not "reasonable", it should, to avoid any surprises :-) | 12:44 |
| mriedem | jaypipes: can you take a look at the stein regression bug fix series starting with the functional recreate test here? https://review.opendev.org/#/c/653268/ | 12:45 |
| aspiers | kashyap: qemu binary path will have a single value and is programmatically obtained | 12:45 |
| aspiers | and virt type will presumably be fixed within the context of the libvirt driver anyway | 12:46 |
| aspiers | so in reality it's just two values which can change | 12:46 |
| mriedem | gibi: can you take a look at the stein regression bug fix series starting here? https://review.opendev.org/#/c/653098/ | 12:46 |
| kashyap | aspiers: True, good point. (So you're aware of it; just thought I'd notify.) | 12:46 |
| gibi | mriedem: looking | 12:46 |
| aspiers | unless it's possible to have the libvirt driver allowing both Xen and KVM on one host | 12:46 |
| aspiers | which I assumed not | 12:46 |
| aspiers | or at least that noone would be crazy enough to try that ;-) | 12:46 |
| kashyap | aspiers: No, that's too FrankenStack to mix it like that :D | 12:47 |
| aspiers | right | 12:47 |
| kashyap | Okay, /me moves "office", home --> library; bbiab | 12:47 |
| aspiers | kashyap: getting the emulator was the whole point of https://review.opendev.org/#/c/640483/ | 12:48 |
| sean-k-mooney | aspiers: what were you going to use the emulator for? | 12:51 |
| aspiers | for calling the API as per above | 12:52 |
| aspiers | gotta run, biab | 12:52 |
| sean-k-mooney | aspiers: you can only have kvm and zen on the same host if you run two agents. and are happy to support it entirly yourself because noone else will touch it :) | 12:54 |
| *** lbragstad has joined #openstack-nova | 12:55 | |
| sean-k-mooney | kashyap: if you did not restat the agent i think we would pick you the capablity changes via the periodic task but ya it would be an ill defined state untill that happened | 12:56 |
| kashyap | Right | 12:57 |
| mriedem | melwitt: about 5am i was thinking about quota and rebuild from cell0 - thoughts are in the spec https://review.opendev.org/#/c/648686/2/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@96 if you can check my thinking | 13:03 |
| mriedem | tssurya: is your locked_reason stuff ready for review? if so, can you queue it up for runways? | 13:03 |
| *** eharney has quit IRC | 13:04 | |
| gibi | mriedem: what will happen if we run the migration, run archive, run migration, run archive again. Does that second archive fail to move the marker instance due to a unique constraint on the uuid field in the shadow table? | 13:04 |
| openstackgerrit | Nikolay Fedotov proposed openstack/nova master: Fix disappearing ironic hypervisors after rebuilding hashring https://review.opendev.org/654584 | 13:05 |
| *** belmoreira has quit IRC | 13:07 | |
| gibi | mriedem: never mind, we dont add the unique constraint to the shadow tables | 13:07 |
| gibi | mriedem: series starting at https://review.opendev.org/#/c/653098/ looks good to me | 13:07 |
| mriedem | right | 13:07 |
| *** jaosorior has quit IRC | 13:08 | |
| mriedem | thinking about your migration + archive thing, i don't think we archive the deleted marker instance because of the fkey relationship to the vif | 13:08 |
| *** tbachman has quit IRC | 13:09 | |
| mriedem | i also don't think we ever delete the marker vif even if we don't need to migrate any more records, | 13:09 |
| mriedem | so eventually when we remove that online data migration, we'll likely also need to delete the marker vif so archiving can remove it and we can remove the hack in the api | 13:10 |
| *** belmoreira has joined #openstack-nova | 13:11 | |
| gibi | mriedem: hm, then I don't get how your functional test passes at https://review.opendev.org/#/c/653098/2/nova/tests/functional/regressions/test_bug_1825034.py@77 | 13:13 |
| gibi | mriedem: or we delete the marker instance but no the marker vif? | 13:13 |
| mriedem | correct | 13:13 |
| mriedem | the instance record is soft deleted but the marker vif is not | 13:14 |
| mriedem | efried: i reckon anything going into a runway slot today will get an extra week because of the summit yeah? | 13:14 |
| gibi | mriedem: I see | 13:14 |
| mriedem | melwitt: i removed the counting quotas from placement series out of the runway slot since the time expired but feel free to queue it back up | 13:15 |
| *** francoisp has joined #openstack-nova | 13:15 | |
| bauzas | mriedem: sorry was on bank holiday yesterday, how can I help with some review ? | 13:17 |
| openstackgerrit | Lucian Petrut proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | 13:17 |
| mriedem | bauzas: stein regression series starting here would be good https://review.opendev.org/#/c/653268/ | 13:18 |
| mriedem | bauzas: and i need review on this queens backport https://review.opendev.org/#/c/640198/ | 13:18 |
| mriedem | we're very close to closing out pike | 13:18 |
| mriedem | extra credit for https://review.opendev.org/#/c/639382/ which is #2 in my series of 45+ changes in the cross-cell series | 13:19 |
| mriedem | gibi: could i also ask, when you get a min, to review this functional recreate test for a latent bug https://review.opendev.org/#/c/641521/ | 13:20 |
| gibi | mriedem: sure, looking | 13:20 |
| *** lpetrut has joined #openstack-nova | 13:21 | |
| mriedem | thanks | 13:22 |
| *** panda|lunch is now known as panda | 13:23 | |
| *** ratailor_ has quit IRC | 13:25 | |
| gibi | mriedem: done, looks good | 13:28 |
| mriedem | thanks again, and i see you took the extra credit :) | 13:29 |
| mdbooth | lyarwood: Just sent a thing on swap-volume to the ML which you might be interested in. | 13:30 |
| gibi | mriedem: :) | 13:30 |
| lyarwood | mdbooth: swap volume and interested should never appear in the same sentence | 13:31 |
| * lyarwood looks | 13:32 | |
| *** phasespace has quit IRC | 13:33 | |
| mdbooth | lyarwood: I proposed a green field implemention :) You never know, it might even make you happy. | 13:33 |
| mdbooth | lyarwood: Anyway, I wanted *something* written down before the PTG session just to ensure it has some structure. If we throw it away that's fine. | 13:34 |
| tssurya | mriedem: not yet I am still writing test cases and notification changes. Will add it to the queue once that is done | 13:34 |
| lyarwood | mdbooth: ack thanks | 13:36 |
| efried | mriedem: Extra runway time: sure | 13:38 |
| mriedem | mdbooth: without reading, if i wrote swap volume today i'd probably use the os-server-external-events API as the callback from cinder like we use for neutron and cinder's extend volume api | 13:38 |
| efried | kashyap: ack, thx | 13:38 |
| efried | lbragstad: Yup, got it figured, thanks. | 13:38 |
| efried | eandersson: ack, will look. Either way would be fine. I was going to say this is temporary until we rip out ironicclient; but the region_name and min/max fixes should be backported, so the stable branches will carry that code for a while. | 13:40 |
| efried | mriedem: ack, saw the test.py thing, +2, good call. | 13:40 |
| *** mlavalle has joined #openstack-nova | 13:43 | |
| mdbooth | mriedem: My proposal wasn't explicit about what rpc method was used, but it is explicit about synchronous guarantees. | 13:43 |
| *** liuyulong has joined #openstack-nova | 13:44 | |
| mdbooth | mriedem: If we can use something more appropriate to the task than the rest api whilst having explicit calls and waiting between cinder and nova that would be awesome. | 13:44 |
| mdbooth | I don't think it's possible to do with 1-way asynchronous calls, though, and 2-way asynchronous calls would be more complex. | 13:45 |
| *** tbachman has joined #openstack-nova | 13:46 | |
| *** psachin has joined #openstack-nova | 13:58 | |
| *** bryan_stephenson has joined #openstack-nova | 13:58 | |
| *** boxiang has quit IRC | 13:59 | |
| *** boxiang has joined #openstack-nova | 14:00 | |
| *** jaosorior has joined #openstack-nova | 14:00 | |
| mdbooth | mriedem: Thanks, btw. I'd completely forgotten to discuss rpc mechanisms in that mail. I just tacked it on. | 14:01 |
| mriedem | mdbooth: i wasn't talking about rpc, i was talking about rest api | 14:03 |
| mdbooth | mriedem: I was talking about 'rpc', where the rest api is a type of rpc | 14:04 |
| mriedem | mdbooth: do you want a new dedicated swapVolume server action that is synchronous to cinder? | 14:04 |
| mdbooth | mriedem: It's described in the ML post, but basically there would be 2 separate calls and cinder would do the bulk of the copy itself. | 14:05 |
| *** yan0s has joined #openstack-nova | 14:06 | |
| *** Luzi has quit IRC | 14:06 | |
| mdbooth | Note that the currently implementation is essentially synchronous as it has a callback, btw. Except when it doesn't :/ | 14:09 |
| openstackgerrit | Christian Berendt proposed openstack/nova stable/rocky: Fix regression in glance client call https://review.opendev.org/655167 | 14:09 |
| *** sridharg has quit IRC | 14:17 | |
| kashyap | efried: sean-k-mooney: A "traits" question: If I were to add a 'COMPUTE_UEFI_SECURE_BOOT' trait, to indicate the host QEMU+libvirt+OVMF is capable of Secure Boot support, what existing similar example would you suggest to look at, in the Nova code? | 14:19 |
| mriedem | kashyap: look at the capabilities stuff the drivers report as traits | 14:20 |
| mriedem | and what dansmith is doing with supported image types | 14:20 |
| efried | mriedem has... yeah | 14:20 |
| *** eharney has joined #openstack-nova | 14:20 | |
| mriedem | https://review.opendev.org/#/c/652710/ | 14:20 |
| kashyap | mriedem: Ah, yes. I took a cursory look at Dan's image_types. /me looks | 14:20 |
| kashyap | Thanks, both | 14:21 |
| efried | kashyap: also https://review.opendev.org/#/c/645316/ | 14:22 |
| kashyap | efried: Yep, bookmarked & reading. Thanks for the (non-null) pointers | 14:22 |
| kashyap | efried: mriedem: Oh, speaking of traits, it reminds of something I noticed the other day: e.g. I see the CPU_TRAITS_MAPPING work that alex_xu and co. did in the past | 14:25 |
| kashyap | ...I see that we're missing some useful and important CPU traits like PCID feature, etc. | 14:26 |
| sean-k-mooney | kashyap: i propsoed that in the past. https://review.opendev.org/#/c/514713/4/os_traits/fw/uefi.py | 14:26 |
| kashyap | Is there a "recommended" way to systematically add new / missing traits? | 14:26 |
| sean-k-mooney | although it was a slightly different usecase | 14:26 |
| kashyap | sean-k-mooney: Right, I just saw the remark on your (abandoned) change | 14:27 |
| mriedem | kashyap: propose them to the os-traits library | 14:27 |
| kashyap | efried: Or is it just a matter of: "go, simply add the missing trait"? | 14:27 |
| mriedem | lpetrut: was asking the same yesterday | 14:27 |
| sean-k-mooney | if COMPUTE_UEFI_SECURE_BOOT means this host is capable of virtualising a vm with secure boot i think its fine | 14:27 |
| kashyap | Yeah, so far I was "ignoring" traits thingie. Now I can no longer :D | 14:27 |
| efried | kashyap: Yeah, I don't think we want a strategy of "add all these traits that might ever be relevant". | 14:28 |
| kashyap | mriedem: Thanks! This one: https://github.com/openstack/os-traits | 14:28 |
| sean-k-mooney | what i was orginally trying to model was this host host secure boot ebabled | 14:28 |
| sean-k-mooney | that is what the pushback was reated too | 14:28 |
| efried | Rather, we want to add as needed. | 14:28 |
| aspiers | efried: thanks for the SEV spec review, just replying now | 14:28 |
| efried | aspiers: ack | 14:28 |
| *** obre has quit IRC | 14:28 | |
| kashyap | efried: Not "might". E.g. a practical example: if you applied all the Meltdown/Spectre fixes, then your guests are suddenly awfully w.r.t performance (while you may get security) | 14:29 |
| *** obre has joined #openstack-nova | 14:29 | |
| mriedem | lyarwood: per your email about extracted placement + tripleo, does that mean train tripleo ci is using extracted placement in base deploys? | 14:29 |
| sean-k-mooney | kashyap: os-traits uses story board so you will want to creat a story for the new triat | 14:29 |
| kashyap | efried: ... unless you specify PCID. (https://kashyapc.fedorapeople.org/Reducing-OpenStack-Guest-Perf-Impact-from-Meltdown.txt) | 14:29 |
| efried | kashyap: If you have a use case that encompasses some traits, that counts. | 14:29 |
| kashyap | sean-k-mooney: Sigh, it seems more red tape, why a "storyboard" ticket for such a simple thing? A commit message should be able to handle it | 14:30 |
| *** yan0s has quit IRC | 14:30 | |
| efried | kashyap, sean-k-mooney: I agree. | 14:30 |
| efried | sorry | 14:30 |
| efried | I agree that we shouldn't need a story for new traits. | 14:30 |
| kashyap | efried: I'm only looking at CPU traits that are practically important / relevant. | 14:30 |
| efried | unless there's some massive architectural thing going on. | 14:30 |
| kashyap | sean-k-mooney: Let's not sleep-walk into mind-numbing process. It shoos away more contributors. | 14:30 |
| efried | You can expect some bikeshedding on namespaces and whatnot, but all of that can happen in review. | 14:31 |
| sean-k-mooney | kashyap: im not | 14:31 |
| sean-k-mooney | once added a trait can never be remvoed | 14:31 |
| kashyap | efried: Yeah, that's fine. | 14:31 |
| sean-k-mooney | so i just wanted it to not slip between the cracks | 14:31 |
| efried | but kashyap, note that storyboard in this sense would be more akin to bugs.launchpad, not blueprints.launchpad. | 14:31 |
| kashyap | sean-k-mooney: The merits / demerits of a trait can be discussed in the review. If there is consensus that it should not be added, any reasonable person will concur. | 14:32 |
| kashyap | efried: Yep, I've filed a few 'stories' myself :-) | 14:32 |
| kashyap | (For the infra project, though) | 14:32 |
| efried | I'm one for less process anywhere possible | 14:32 |
| efried | kashyap: btw, in case your reference to the github repo was meaningful, os-traits is developed in gerrit | 14:33 |
| efried | so like don't go submitting a pull request. | 14:33 |
| kashyap | Yep, figured as much. | 14:33 |
| efried | cool | 14:33 |
| kashyap | Hehe, I by default assume all these are Gerrit-based. | 14:34 |
| jaypipes | mriedem: yessir | 14:34 |
| openstackgerrit | sean mooney proposed openstack/nova master: [DNM] AUTOPEP8 ignore https://review.opendev.org/655171 | 14:37 |
| *** artom has joined #openstack-nova | 14:39 | |
| jaypipes | efried: can you link me the review I said I'd re-look at that I responded "yessir" to you last evening? my scrollback doesn't have it (and no, I don't log irc) | 14:39 |
| jaypipes | efried: tia | 14:40 |
| lyarwood | mriedem: sorry missed your ping, yes AFAIK it's the default in CI now | 14:40 |
| efried | jaypipes: It was aspiers' SEV reproposal: https://review.opendev.org/641994 | 14:40 |
| jaypipes | danke | 14:40 |
| efried | jaypipes: he said he's responding to my last couple of comments now. | 14:40 |
| jaypipes | k | 14:40 |
| *** lpetrut has quit IRC | 14:40 | |
| kashyap | jaypipes: Will answer your question shortly on the review. (And interesting pointer on "Shielded VMs", I guess that's the nail on the "use case coffin" :D) | 14:41 |
| kashyap | jaypipes: Also on "stupid questions"...recall what the inimitable Carl Sagan said: | 14:42 |
| kashyap | "There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question."—Carl Sagan | 14:42 |
| *** udesale has quit IRC | 14:45 | |
| *** udesale has joined #openstack-nova | 14:46 | |
| *** ccamacho has quit IRC | 14:46 | |
| jaypipes | kashyap: the complete quote ends with "unless you're speaking with Jay Pipes. If that's the case, yes, there is definitely such a thing as a stupid question." | 14:48 |
| kashyap | Hehe, go easy on yourself | 14:48 |
| jaypipes | efried: k. to be clear, have all of danpb's concerns been addressed? | 14:49 |
| efried | jaypipes: I definitely want to get a re-ack from danpb before we merge the spec. My review was only in terms of the placement- and nova-isms. | 14:49 |
| efried | aspiers: Any progress on contacting danpb to sign off? | 14:50 |
| efried | jaypipes: Of course you should dig into the SEV-specific gorp as you are able/willing, but I mainly wanted to make sure you were on board with the switchover to quantitative inventorying of SEV context. | 14:52 |
| jaypipes | is there a danpb bat-signal? | 14:52 |
| efried | "we're going to rewrite nova" | 14:52 |
| efried | ^ that should do it | 14:52 |
| jaypipes | efried: ack, lemme focus on those changes. | 14:52 |
| jaypipes | efried: lol | 14:52 |
| jaypipes | efried: danpb long ago gave up the nova ghost. | 14:53 |
| *** luksky has quit IRC | 14:54 | |
| efried | eandersson: I want to backport your region_name fix, so just need a bug associated with it and I think we're good to go. | 14:54 |
| kashyap | jaypipes: Hehe, from what I see Dan is largely back to working on libvirt/QEMU | 14:55 |
| kashyap | (But he's still on #virt, and #qemu OFTC. That's where I ask some gnarly questions.) | 14:55 |
| *** lpetrut has joined #openstack-nova | 14:56 | |
| * efried bbiab | 14:59 | |
| *** tetsuro has joined #openstack-nova | 14:59 | |
| *** tetsuro has quit IRC | 15:01 | |
| kashyap | efried: jaypipes: On the SEV thing, DanPB just said: if you stopped using 'hard limit' (for memory) then the important bit is addressed. | 15:04 |
| jaypipes | ack | 15:07 |
| kashyap | artom: BTW, I spent 2-ish hours this morning responding to your (and cfriesen's) comments on the Secure Boot spec. Thanks for your time. When you can, let me know (on the review) if I answered your questions | 15:09 |
| *** gyee has joined #openstack-nova | 15:09 | |
| artom | kashyap, yeah, saw your responses in an email, will need to circle back... | 15:10 |
| * artom needs to "methodicize" his upstream work | 15:10 | |
| kashyap | We should fast-track artom into management, he's using the right jargon: "circle back" :D | 15:10 |
| artom | For instance, "Tuesday and Thursday afternoons (or whatever) are for upstream" | 15:10 |
| artom | kashyap, I'm a freaking buzzword bingo generator | 15:11 |
| mnaser | you haven't gone full management till you start "redlining" specs instead of reviewing them | 15:11 |
| mnaser | :P | 15:11 |
| artom | I take synergies and value-add process efficiencies. | 15:11 |
| kashyap | artom: On the off chance, wonder if you've seen Urban Dictionary's definition of "circle back". | 15:11 |
| artom | kashyap, oh, I'm sure it's unspeakable in this channel | 15:12 |
| kashyap | artom: Not quite. But it makes the point well | 15:12 |
| aspiers | https://www.urbandictionary.com/define.php?term=Circle%20Back | 15:12 |
| aspiers | pretty funny, and surprisingly SFW | 15:12 |
| artom | Yeah, I was fully expecting "back" to be, err, backdoor stuff | 15:13 |
| kashyap | artom, Back to work, on your main N->N-1 migration and SMM XML bit: good news! It is a non-problem for us. See my answer on the change | 15:13 |
| kashyap | aspiers: Heh, yeah | 15:13 |
| mriedem | lyarwood: fyi apparently https://review.opendev.org/#/q/I3ed3303309fe2a25c0043fd206f36bada4b3b8f9 broke ceph-backed snapshots | 15:14 |
| artom | kashyap, because we're guaranteed to have a libvirt/qemu that support it, correct? | 15:14 |
| mriedem | https://review.opendev.org/#/c/655167/ | 15:14 |
| lyarwood | mriedem: looking | 15:14 |
| kashyap | artom: Yes | 15:14 |
| mriedem | since the ceph job is non-voting i didn't notice the failure in your backports | 15:14 |
| kashyap | artom: The min libvirt/QEMU versions in Nova are way beyond what's required. | 15:14 |
| mriedem | but indeed the ceph job failed with snapshot tests | 15:14 |
| artom | kashyap, OK, might be worth writing down in the spec. Unless I | 15:14 |
| artom | Unless I'm really the only confused lost soul | 15:14 |
| kashyap | artom: To put things in perspective, first commit to QEMU on SMM support was in 2006 sometime (I was still in college) :D | 15:15 |
| kashyap | artom: Yeah, I've added the versions required already in the spec. | 15:15 |
| artom | kashyap, ack. | 15:15 |
| lyarwood | mriedem: crap, ack. | 15:15 |
| mriedem | just fyi since you might hear about it internally :) | 15:16 |
| mriedem | maybe we should put some effort behind making the ceph job non-voting | 15:16 |
| mriedem | i'm not really sure why it's non-voting now anyway, besides maybe a history of intermittent failures a few releases ago | 15:16 |
| kashyap | artom: Lastly: min QEMU version that has the relevant SB-related features libvirt looks for is 2.4. (Current Nova min versoina take satisfy those too.) | 15:17 |
| kashyap | s/take// | 15:17 |
| *** ccamacho has joined #openstack-nova | 15:17 | |
| lyarwood | mriedem: yeah, happy to help keep it GREEN during Train and on stable if it means we avoid issues like this tbh. | 15:18 |
| kashyap | mriedem: When you get a sec, so if I add a CPU flag 'trait' to `os-traits` library, then I should also add it to CPU_TRAITS_MAPPING dict (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/utils.py#L49,#L81) | 15:19 |
| * kashyap looks about | 15:20 | |
| mriedem | the cpu flag name is literally 'trait'? | 15:21 |
| *** lpetrut has quit IRC | 15:22 | |
| mriedem | if you want the cpu feature flag to show up as a trait on the compute node resource provider automatically then yeah i guess it goes in that mapping | 15:23 |
| mriedem | alex_xu is probably the authority on that code | 15:23 |
| alex_xu | o/ | 15:23 |
| sean-k-mooney | kashyap: is this realted to secure boot | 15:23 |
| kashyap | sean-k-mooney: No-no, completely unrelated | 15:23 |
| sean-k-mooney | ok i was going to say that is not a cpu flag | 15:24 |
| sean-k-mooney | never mind | 15:24 |
| kashyap | sean-k-mooney: I'm adding PCID, SSBD, etc. | 15:24 |
| sean-k-mooney | ah ok | 15:24 |
| kashyap | Of course, it's not. Huh :-) | 15:24 |
| alex_xu | kashyap: if hope the nova to discover the PCID and report PCID trait to the placement, then you should add it to CPU_TRAITS_MAPPING | 15:25 |
| kashyap | alex_xu: Yes, exactly. Thought so | 15:25 |
| alex_xu | I guess you also need to raise the required version of os-traits | 15:25 |
| kashyap | alex_xu: So, along with adding to /os-traits/os_traits/hw/cpu/x86.py, I will add it to the CPU_TRAITS_MAPPING dict | 15:25 |
| kashyap | (Yes?) | 15:26 |
| alex_xu | yes | 15:26 |
| kashyap | alex_xu: Where do I raise the 'os-traits' version? | 15:26 |
| *** ttsiouts has quit IRC | 15:27 | |
| alex_xu | requirement | 15:27 |
| *** ttsiouts has joined #openstack-nova | 15:27 | |
| alex_xu | kashyap: requirement.txt | 15:28 |
| openstackgerrit | Christian Berendt proposed openstack/nova stable/queens: Fix regression in glance client call https://review.opendev.org/655186 | 15:28 |
| kashyap | alex_xu: Thanks! | 15:30 |
| aspiers | efried: after much deliberating I've finally figured out how to articulate my thoughts https://review.opendev.org/#/c/641994/11 | 15:30 |
| kashyap | alex_xu: I see currently 0.9.0 traits is released. And in Nova, we have: os-traits>=0.8.0 | 15:31 |
| kashyap | alex_xu: I am going to make that to: | 15:31 |
| kashyap | - os-traits>=0.8.0 | 15:31 |
| kashyap | + os-traits>=0.10.0 | 15:31 |
| alex_xu | yea, to the version has PCID trait | 15:31 |
| aspiers | kashyap: thanks for relaying the message from danpb - indeed hard_limit is no longer proposed in the latest version of the SEV spec http://logs.openstack.org/94/641994/11/check/openstack-tox-docs/a439f50/html/specs/train/approved/amd-sev-libvirt-support.html#memory-locking-and-accounting | 15:31 |
| *** ttsiouts has quit IRC | 15:32 | |
| kashyap | aspiers: Noted. Thanks for the pointer | 15:33 |
| kashyap | aspiers: BTW, I must say, this is one of the most well-written specs I've evern seen. Nice work. | 15:33 |
| aspiers | kashyap: thanks! :) | 15:33 |
| aspiers | I received a lot of great advice on it over 2 cycles, which has helped hugely | 15:35 |
| *** mvkr has quit IRC | 15:35 | |
| kashyap | Yeah, it shows the careful, unhurried effort to think-through the problem and incorporating the feedback. | 15:35 |
| aspiers | Well I'm too stubborn to give up, and not quite stupid enough to believe that I could shove a spec down your throats before it was ready and expect to succeed ;-) | 15:37 |
| *** dustinc_away is now known as dustinc | 15:37 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955 | 15:37 |
| *** helenafm has quit IRC | 15:37 | |
| *** jamesdenton has joined #openstack-nova | 15:38 | |
| kashyap | alex_xu: By the way, the CPU_TRAITS_MAPPING takes both AMD _and_ Intel flags, yes? | 15:40 |
| alex_xu | yes | 15:41 |
| kashyap | aspiers: Hehe, noted. (Sustained concentration is a "feature" in this distracted world with 280-char attention spans.) | 15:42 |
| kashyap | alex_xu: Thx. | 15:42 |
| aspiers | Indeed | 15:42 |
| * artom hopes he'll receive kashyap's feature patch soon. | 15:43 | |
| artom | Although realistically, that'll probably mean drugs, so maybe not? | 15:43 |
| kashyap | What a charitable interpretation. | 15:43 |
| aspiers | LOL | 15:43 |
| artom | Is it? Charitable, I mean? | 15:44 |
| aspiers | It's not a coincidence that I'm currently doing a meditation course on productivity ;-) | 15:44 |
| kashyap | alex_xu: As I add these missing traits to the CPU_TRAITS_MAPPING, I have an uneasy feeling that we're duplicating work | 15:44 |
| kashyap | alex_xu: I think we're OK with its growth over the years... | 15:44 |
| kashyap | aspiers: Nice. | 15:45 |
| alex_xu | kashyap: yes, welcome any better idea | 15:45 |
| kashyap | alex_xu: Nothing currently :-) Will keep thinking about this problem, will let you know if I come up with anything better | 15:46 |
| alex_xu | kashyap: cool, thanks | 15:46 |
| *** ccamacho has quit IRC | 15:46 | |
| *** ccamacho has joined #openstack-nova | 15:47 | |
| mriedem | adrianc: some comments in https://review.opendev.org/#/c/649345/ | 15:50 |
| mriedem | adrianc: if you agree, i'm willing to make that change and then still +2 | 15:51 |
| mriedem | it's just docs and variable naming | 15:52 |
| *** dave-mccowan has joined #openstack-nova | 15:57 | |
| efried | dansmith, mriedem, gibi: Did we ever settle on the accepted way to add resource/trait/aggregate things via a request_filter so they end up in the GET /a_c request? | 15:58 |
| *** bryan_stephenson has quit IRC | 15:59 | |
| mriedem | not that i know of, i know gibi posted a patch, | 16:00 |
| mriedem | and my eyes glazed over at the discussion within my multiattach capability trait patch | 16:00 |
| mriedem | for now i'm just shoving a trait in the flavor extra spec on the request spec before it hits the scheduler and making sure the change isn't persisted | 16:00 |
| mriedem | i.e. hitching a ride to scheduler town | 16:00 |
| mriedem | cash, grass, or ... | 16:01 |
| mriedem | no traits ride for free | 16:01 |
| efried | making sure the change isn't persisted? | 16:02 |
| mriedem | RequestSpec.flavor gets persisted | 16:03 |
| efried | so you're adding it to the flavor extra spec until the GET /a_c and then removing it? | 16:03 |
| mriedem | i want to make sure that twiddling RequestSpec.flavor.extra_specs for a one-time scheduler run doesn't get persisted | 16:03 |
| mriedem | nothing is explicitly removing it, | 16:03 |
| efried | ...you just aren't saving it | 16:03 |
| mriedem | you reset changes on the object so that when it's saved those changes aren't persisted | 16:03 |
| efried | okay | 16:03 |
| *** belmoreira has quit IRC | 16:03 | |
| *** dikonoor has quit IRC | 16:05 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755 | 16:05 |
| *** dave-mccowan has quit IRC | 16:07 | |
| jaypipes | mdbooth: what is the primary use case for the volume-update operation? (as opposed to just doing a detach-volume, start-new-instance-elsewhere, attach-volume flow? | 16:08 |
| mriedem | volume live migration and retypes | 16:10 |
| mriedem | for a retype it's a new volume, else it's the same volume on a different backend with the same type (i think) | 16:11 |
| mriedem | https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_swap_volume | 16:11 |
| jaypipes | mriedem: what's the use case though? | 16:13 |
| aspiers | jaypipes wins the Review Of The Week award for a perfect use of a Big Lebowski quote | 16:13 |
| jaypipes | aspiers: yw | 16:13 |
| mriedem | jaypipes: this feels like a trap | 16:14 |
| mriedem | what's the use case for live migration? | 16:14 |
| jaypipes | mriedem: no, I'm honestly curious. | 16:14 |
| jaypipes | mriedem: is volume live migration different from live migration? | 16:14 |
| mriedem | yes | 16:14 |
| mriedem | it's initiated through cinder | 16:14 |
| mriedem | smcginnis: maybe you want to elaborate here ^ | 16:14 |
| jaypipes | mriedem: so this is not an operation a user would ever issue, right? | 16:15 |
| mriedem | https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-migration.html | 16:15 |
| jaypipes | (like instance live migration is not an operation any normal user even knows about) | 16:15 |
| mriedem | for volume migration i think that is correct, it's admin-only by default, | 16:15 |
| mriedem | but retype is admin or owner of the volume aka the user | 16:15 |
| mriedem | https://developer.openstack.org/api-ref/block-storage/v3/?expanded=migrate-a-volume-detail,retype-a-volume-detail#retype-a-volume | 16:15 |
| mriedem | "Change the volume type of existing volume, Cinder may migrate the volume to proper volume host according to the new volume type." | 16:16 |
| mriedem | i think of volume retype like server resize | 16:16 |
| mriedem | by default retyping should not migrate the volume, but the user can override that | 16:16 |
| mriedem | "If the volume is attached to a server instance and will be migrated, then by default policy only users with the administrative role should attempt the retype operation." | 16:17 |
| mriedem | ^ is because the nova swap volume api is admin-only by default | 16:17 |
| mriedem | it's f'ing great | 16:17 |
| jaypipes | hrmph | 16:17 |
| mriedem | so i as a non-admin user could try to retype my attached volume and migrate it which could then blow up b/c nova rejects my non-admin user token passed by proxy from cinder | 16:18 |
| aspiers | efried: when you have a moment, if you can give me some newb pointers about how encrypted_memory=true would be implemented, I can submit a new patch set proposing that | 16:18 |
| mriedem | not sure if cinder has added anything to escalate that token to admin/service user in the last 3 years | 16:18 |
| mriedem | the more sane thing to do would probably be stop the instance, detach the volume, retype it, re-attach and then restart the server | 16:19 |
| jaypipes | or design your application to write to multiple volumes in a replica set instead of one giant panda volume. | 16:20 |
| jaypipes | but I digress. | 16:20 |
| mriedem | my enterprise panda volume is very important and can never go down | 16:20 |
| mriedem | it runs my website visit counter | 16:20 |
| jaypipes | :) | 16:20 |
| jaypipes | new band name: Enterprise Panda Volume. | 16:20 |
| jaypipes | or EPV for the cool kids. | 16:21 |
| mriedem | EPV if you're talking to execs | 16:21 |
| mriedem | yeah :) | 16:21 |
| panda | uh ? | 16:21 |
| jaypipes | :) | 16:21 |
| mnaser | LOL | 16:21 |
| jaypipes | hahahaha | 16:21 |
| aspiers | there is actually a panda on this channel who is gonna be wondering why they suddenly got a bunch of notifications :-D | 16:21 |
| jaypipes | panda: :) | 16:21 |
| aspiers | oh, I was too late | 16:21 |
| panda | can I get back to sleep ? | 16:21 |
| panda | :) | 16:21 |
| aspiers | :) | 16:21 |
| jaypipes | panda: sorry, a "Panda" is a pet virtual machine that can not be killed otherwise it's an international incident :) | 16:21 |
| jaypipes | sorry for waking you! | 16:22 |
| panda | oh my. | 16:22 |
| mriedem | oh it also looks like swap volume will work on root volumes, whereas detach / attach does not (yet) | 16:23 |
| jaypipes | mriedem: yuck. | 16:23 |
| *** mrhillsman is now known as openlab | 16:23 | |
| jaypipes | :P | 16:23 |
| panda | nice to know more nice uses of my nick :) | 16:23 |
| *** openlab is now known as mrhillsman | 16:23 | |
| aspiers | jaypipes: I guess I need to update my slides https://youtu.be/uMCMDF9VkYk?t=483 | 16:23 |
| jaypipes | aspiers: yes. yes you do. | 16:24 |
| *** mrhillsman is now known as openlab | 16:24 | |
| *** wwriverrat has joined #openstack-nova | 16:24 | |
| jaypipes | aspiers: and add a Big Lebowski reference while you're at it. | 16:24 |
| aspiers | good plan | 16:24 |
| *** openlab is now known as mrhillsman | 16:25 | |
| *** dtantsur is now known as dtantsur|afk | 16:28 | |
| *** itlinux has joined #openstack-nova | 16:30 | |
| *** whoami-rajat has quit IRC | 16:30 | |
| *** rcernin has quit IRC | 16:36 | |
| *** whoami-rajat has joined #openstack-nova | 16:39 | |
| openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add HW_CPU_X86_* traits for Meltdown/Spectre mitigation https://review.opendev.org/655191 | 16:40 |
| openstackgerrit | Merged openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755 | 16:42 |
| openstackgerrit | Kashyap Chamarthy proposed openstack/os-traits master: Add CPU traits for Meltdown/Spectre mitigation https://review.opendev.org/655193 | 16:45 |
| *** tosky has quit IRC | 16:46 | |
| kashyap | Any "Traits People", please let me know if I got the above even partly right... | 16:46 |
| * kashyap bbiab | 16:46 | |
| *** udesale has quit IRC | 16:47 | |
| efried | aspiers: I was just doing that in the review when I received an interrupt, getting back to it now. | 16:47 |
| aspiers | efried: if it's easier you can just educate me here | 16:47 |
| sean-k-mooney | kashyap: do we need seperate VIRT-SSDB and AMD-SSDB traits | 16:48 |
| aspiers | efried: since I'll probably have questions which the extra round trip latency from Gerrit won't help | 16:48 |
| efried | aspiers: okay, sure. One minute... | 16:48 |
| kashyap | sean-k-mooney: Yes, we do. | 16:48 |
| sean-k-mooney | why? | 16:48 |
| *** eharney has quit IRC | 16:48 | |
| kashyap | sean-k-mooney: Let me quote the upstream QEMU documentation: | 16:49 |
| kashyap | [quote] | 16:49 |
| kashyap | virt-ssbd | 16:49 |
| kashyap | Required to enable the CVE-2018-3639 fix. Not included by default in any AMD CPU model. Must be explicitly turned on for all AMD CPU models. This should be provided to guests, even if amd-ssbd is also provided, for maximum guest compatibility. Note for some QEMU / libvirt versions, this must be force enabled when when using “Host model”, because this is a virtual feature that doesn’t exist | 16:49 |
| kashyap | in the physical host CPUs. | 16:49 |
| kashyap | [/quote] | 16:49 |
| kashyap | Note the: *even if amd-ssbd- is also provided* part. | 16:49 |
| kashyap | sean-k-mooney: They are separate CPU flags, so of course we need separate traits. | 16:49 |
| sean-k-mooney | well we dont that is basically my point | 16:49 |
| kashyap | Oh? | 16:50 |
| kashyap | sean-k-mooney: What do you mean? | 16:50 |
| sean-k-mooney | there does not need to be a 1:1 mapping between tratis adn cpus flags | 16:50 |
| *** altlogbot_2 has quit IRC | 16:50 | |
| sean-k-mooney | the traits dont impact the xml generation | 16:50 |
| sean-k-mooney | so for the tratis we need to think about whgat we schdule on | 16:50 |
| kashyap | Please comment in the review; I need to leave the library. It's closing | 16:50 |
| sean-k-mooney | sure will do | 16:51 |
| kashyap | Much appreciated | 16:51 |
| artom | What's the ? at the beginning of https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/devstack/tempest-dsvm-lvm-rc#L33 ? | 16:51 |
| artom | 'r="^(?!.*"' | 16:51 |
| artom | I thought I groked regex, but this confuses me. | 16:51 |
| artom | ? would mean 0 or 1, right? So... "maybe a (" ? | 16:52 |
| * efried puts on regex cape | 16:52 | |
| artom | But... why? | 16:52 |
| aspiers | that's a negative look-ahead assertion | 16:52 |
| aspiers | (?!foo.*bar) means "foo.*bar can't come next" | 16:53 |
| efried | ..."but don't capture it" | 16:53 |
| aspiers | right | 16:53 |
| aspiers | it's one of the more obscure features of pcre, been around since Perl 5 days though | 16:53 |
| artom | Ah, I was reading it as a quantifier | 16:53 |
| artom | Thanks aspiers | 16:53 |
| aspiers | https://xkcd.com/208/ is the obvious reference here | 16:53 |
| artom | *snerk* | 16:54 |
| * aspiers shows his age | 16:54 | |
| artom | More like https://xkcd.com/1171/ | 16:54 |
| aspiers | hahahaha | 16:54 |
| aspiers | that's good | 16:54 |
| efried | Ye gods, my goats are freaking out. aspiers, back atcha in 5... | 16:55 |
| * aspiers . o O ( goats?! ) | 16:55 | |
| efried | meanwhile, digest this: | 16:55 |
| efried | Okay, so what I had been thinking thus far was that you would be implementing a request filter method here: | 16:55 |
| efried | https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py | 16:55 |
| efried | Those methods get the RequestSpec, which has the image and flavor in it, so you can grab encrypt_mem=true from either/both. | 16:55 |
| *** altlogbot_1 has joined #openstack-nova | 16:55 | |
| artom | Or the well known "Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. " | 16:56 |
| aspiers | efried: ahah! yep, makes sense | 16:56 |
| artom | efried, you confuse me. A Francophone American BJJ practitioner (right? I seem to remember that from somewhere) with goats. | 16:56 |
| *** derekh has quit IRC | 16:57 | |
| aspiers | artom: my Perl regexp knowledge comes from the same era as my personal website https://twitter.com/adamspiers/status/1115929350736613376 | 16:59 |
| aspiers | I should try not to think too much about how long ago that is | 16:59 |
| artom | Your Twitter picture doesn't fit your website's copyright notice :) | 17:02 |
| artom | Unless you were, like, 10 when you made it | 17:02 |
| artom | (The website, not the picture) | 17:02 |
| * artom wonders | 17:03 | |
| artom | Oh god it's still out there: http://web.archive.org/web/20040611101606/http://coth.no-ip.org/ | 17:03 |
| artom | Whatever pride I have left just went out the window | 17:03 |
| stephenfin | efried: Spent the day working on summit stuff but I'll create the nova-console removal (specless) BP tomorrow, plus more for nova-consoleauth removal (I've that series drafted already). Hit me if I don't | 17:03 |
| artom | I wasn't even that your when I made that | 17:03 |
| artom | *that young | 17:04 |
| stephenfin | (though not really. I imagine that would hurt) | 17:04 |
| artom | Like, 19 | 17:04 |
| aspiers | haha | 17:06 |
| aspiers | artom: the internet is a cache of dirty secrets | 17:06 |
| aspiers | artom: I was 20 in 1995 | 17:07 |
| artom | So we're literally the same age, what are you feeling old for? | 17:07 |
| artom | Wait, no, I fail at math | 17:07 |
| artom | I was 10 | 17:07 |
| aspiers | LOL | 17:07 |
| artom | Oh god, more of my "work": http://web.archive.org/web/20021010075531/http://geocities.com/the_lambda_place/ | 17:08 |
| * stephenfin was three | 17:08 | |
| * stephenfin shuffles out | 17:08 | |
| artom | You're grounded, go to your room | 17:08 |
| aspiers | hahahaha | 17:09 |
| aspiers | artom: looks disturbingly similar to https://www.adamspiers.org/computing/quake/ | 17:09 |
| aspiers | I think that deserves to be labelled as "Web 0.2" | 17:09 |
| artom | aspiers, well now adze has to be your Friday nick | 17:10 |
| efried | catching up (in reverse order) | 17:10 |
| *** ivve has quit IRC | 17:10 | |
| aspiers | nooooo | 17:10 |
| *** nicolasbock has quit IRC | 17:10 | |
| aspiers | efried: best if you skip the last 10 minutes ;-) | 17:10 |
| efried | I'm the same age as artom, give or take a year. | 17:10 |
| efried | stephenfin: ack, thanks | 17:10 |
| efried | I used to be a perl wiz, actually taught a class at one time | 17:10 |
| efried | and artom yes, all of those things. And http://www.thunderpony.com and I was also a child actor :P | 17:11 |
| efried | and regular expressions are awesome. | 17:11 |
| efried | now, back to request filters... | 17:11 |
| artom | efried, damn, you sing as well | 17:12 |
| artom | Oh, right, the thing I'm actually paid to do | 17:12 |
| * artom goes back to test regexes | 17:12 | |
| efried | aspiers: So the RequestSpec is how you find out if your magic key=val is in the flavor and/or image. | 17:13 |
| efried | Tthe jury is still out as to what happens next. | 17:13 |
| aspiers | artom: here's some fun with regexes for you https://adamspiers.org/computing/perl_signatures.html | 17:13 |
| efried | mriedem and I were discussing that about 1h15m ago ^^ | 17:14 |
| aspiers | efried: and that would automatically work for both extra specs and image properties? | 17:14 |
| aspiers | efried: thanks, scrolling up 75m | 17:14 |
| efried | aspiers: well, it would work for both if you implemented both. | 17:14 |
| efried | you have access to both because they're in the RequestSpec. | 17:14 |
| artom | aspiers, yeah, no :P | 17:14 |
| efried | aspiers: I knew a guy who copy/pasted one of those obfuscated perl regex commands into his interpreter. It was one of those //ee things, and translated to something like rm -rf / | 17:15 |
| aspiers | efried: OK. I guess this will start making a lot more sense as I start reading that code and hacking on it | 17:15 |
| aspiers | efried: Ouch, that's a more sinister case of the "curl ... | sudo bash" syndrome | 17:16 |
| *** luksky has joined #openstack-nova | 17:16 | |
| aspiers | although I promise that all of those .sigs are totally innocent and safe to run | 17:16 |
| aspiers | Well the top one still works, at least | 17:17 |
| efried | aspiers: Detecting the property from the request spec is going to be the easy part. The thing mriedem and I were talking about stemmed from his patch here https://review.opendev.org/#/c/645316/ which does a very similar thing to what you're wanting to do in terms of adding stuff that'll make its way into the placement request. | 17:17 |
| * aspiers looks | 17:17 | |
| efried | tl;dr: one way to do it would be to stuff the placement-ese translation of your request - so like a resource request for 1 MEM_ENC_CONTEXT - into the actual RequestSpec.flavor.extra_specs, and make sure that that change to the flavor does *not* get persisted. | 17:18 |
| efried | However, longer term, we're going to want to do such things by stuffing them into RequestSpec.requested_resources: https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L93-L100 | 17:20 |
| *** rpittau is now known as rpittau|afk | 17:20 | |
| efried | but as hinted by that TODO, we're only using that for bandwidth resources at the moment. | 17:20 |
| aspiers | ok | 17:21 |
| aspiers | I guess this can all be done as one of the later work items in the spec, right? Since it's more about improving the UX than actually enabling SEV | 17:22 |
| efried | aspiers: Well, you don't need to talk about anywhere near this level of detail in the spec | 17:22 |
| efried | I'm just showing you that it's definitely doable to support the same generic property (encrypt_my_memory=true) in the flavor and image props | 17:23 |
| efried | and get it translated to placement-ese by "nova". | 17:23 |
| efried | So the UX is encrypt_my_memory=true, done. | 17:23 |
| aspiers | efried: but without that detail how will I pip generic-resource-pools.rst to the post for the largest spec ever? ;) | 17:23 |
| efried | Add a seqdiag | 17:24 |
| aspiers | but seriously, yup - it was always a goal of the spec to allow booting SEV via image properties | 17:24 |
| aspiers | ohhhhh nice idea | 17:24 |
| efried | http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html | 17:24 |
| efried | that seqdiag is only ~38L source :( | 17:25 |
| aspiers | :D | 17:26 |
| efried | oh, I've got a better idea | 17:26 |
| efried | ascii diagrams of nested provider trees | 17:26 |
| efried | those take up some good vertical space. | 17:26 |
| jaypipes | I'm sure those make cdent shiver. | 17:27 |
| aspiers | I was thinking more in terms of the file size | 17:27 |
| aspiers | I'm about 400 bytes behind the leader ;-) | 17:28 |
| efried | oh, you're going byte size? | 17:28 |
| efried | I thought you were going #lines | 17:28 |
| *** psachin has quit IRC | 17:28 | |
| aspiers | well the ranking is the same regardless | 17:29 |
| efried | one of my earlier specs, don't remember which one, dansmith literally -1'd it because it was too long. I distinctly remember trimming it by 10% to earn his +2. | 17:29 |
| aspiers | haha | 17:29 |
| mriedem | gmann: if i'm defining a new ci job which extends tempest-multinode-full-py3 and modify the devstack_localrc vars from that job, does it merge the vars or do i need to do a full replace with what i want? | 17:29 |
| dansmith | pretty sure that's exactly how that went down, no embellishment at all | 17:29 |
| aspiers | I never intended SEV to be so long, just kept getting feedback on new angles | 17:30 |
| efried | aspiers: I think it was this one: https://review.opendev.org/#/c/510244/ | 17:31 |
| efried | hah, yup http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-17.log.html#t2017-10-17T15:21:53 <== dansmith | 17:33 |
| aspiers | efried: just looked at https://review.opendev.org/#/c/645316/2/nova/compute/api.py - IIUC I could just add an invocation of a new _modify_request_spec_for_encrypted_memory() to _provision_instances() which would apply the translation to the flavor extra specs or image properties? | 17:41 |
| mriedem | heh n-obj is still enabled by default in devstack | 17:41 |
| mriedem | derp | 17:41 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498 | 17:43 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396 | 17:43 |
| openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for external events in compute manager https://review.opendev.org/644881 | 17:43 |
| efried | aspiers: more or less. I think this would be better positioned as a method in request_filter.py personally, but that's details. The thing that you'll be needing that isn't applicable in --^ is how you determine whether to add the thing. | 17:43 |
| aspiers | efried: so the new method would frob either reqspec.flavor.extra_specs or reqspec.image? | 17:43 |
| efried | yes | 17:43 |
| aspiers | ahah OK, request_filter.py looks pretty trivial to extend | 17:44 |
| efried | aspiers: But that code path has access to the reqspec too, so whatevs. | 17:44 |
| aspiers | right | 17:44 |
| efried | yes, in fact I should -1 mriedem's patch for that. | 17:44 |
| aspiers | I was going to ask, why didn't https://review.opendev.org/#/c/645316/2/nova/compute/api.py extend request_filter.py :) | 17:44 |
| efried | well, I was going to say it's because the logic of how he's determining whether to add the filter comes from someplace that's not easy to get at from request_filter.py | 17:45 |
| mriedem | efried: that is the rason | 17:45 |
| mriedem | *reason | 17:45 |
| aspiers | ahah, right | 17:45 |
| mriedem | the multiattach info is on the bdm, and even then only after it's connected | 17:45 |
| aspiers | but in my case all I need is the request_spec | 17:46 |
| efried | yup | 17:46 |
| mriedem | so during server create, the request filter would have to loop the bdms looking for the volume_id, then query cinder to get the volume multiattach flag | 17:46 |
| mriedem | which is pretty shitty for performance during scheduling | 17:46 |
| efried | and since this is all about performance during scheduling... | 17:46 |
| aspiers | Ok awesome, this is starting to make a lot of sense | 17:46 |
| mriedem | right | 17:46 |
| aspiers | efried: tweaking the spec now | 17:46 |
| mriedem | well, it's about performance and not picking a compute that doesn't support multiattach | 17:46 |
| efried | aspiers: Hold on a tick, I'm answering your other concern too. | 17:47 |
| aspiers | efried: ok | 17:47 |
| mriedem | if we stored a multiattach attribute on the bdm object and stored something about those in the request spec it'd be a different story | 17:47 |
| mriedem | but that's a lot of ifs | 17:47 |
| tssurya | gibi: if I bump the version on the instance_payload do I need to manually also bump the versions on all payloads inheriting from the instance_payload ? | 17:51 |
| efried | aspiers: responded. And hanging out if you have questions. | 17:53 |
| aspiers | efried: thanks! | 17:54 |
| *** ccamacho has quit IRC | 17:54 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add nova-multi-cell job https://review.opendev.org/655222 | 17:54 |
| mriedem | dansmith: let's cross our fingers and toes ^ | 17:54 |
| dansmith | hoo boy | 17:54 |
| efried | aspiers: Also note that jaypipes responded. | 17:55 |
| aspiers | yep, already saw that | 17:55 |
| efried | jaypipes: Are you okay with "unlimited" being expressed as MAXINT inventory? | 17:55 |
| efried | or, heh, an allocation_ratio of 1E9999 :P | 17:58 |
| jaypipes | efried: there is no such thing as an unlimited inventory. it there was, it would be a trait, because it isn't quantitative/consumable. | 17:59 |
| aspiers | efried: "It'll be up to the driver to determine what that inventory should look like and what it's based on, knowing that the request will always be for 1 unit." - my point was that maybe we *don't* know that | 17:59 |
| aspiers | efried: e.g. picking a stupid example, what if MKTME counted it per vcpu rather than per host? | 18:00 |
| efried | jaypipes: rightright, this is a case where there's always a limit, but sometimes we don't know exactly what it is, so we need to let it be imposed by the host (not by placement). But we still need an inventory, so the driver can in that case specify an inventory that's "arbitrarily large". | 18:00 |
| jaypipes | efried: obviously, there's nothing *stopping* anyone from putting MAX_INT in there :) | 18:00 |
| jaypipes | efried: just saying it doesn't really make sense to me :) | 18:01 |
| aspiers | efried: but in the future I'm guessing AMD machines *may* remove that limit | 18:01 |
| *** lbragstad has quit IRC | 18:01 | |
| aspiers | at least it's not something we can immediately rule out | 18:02 |
| efried | aspiers: Then the driver would use an inventory of actual_limit/num_vcpus or something clever | 18:02 |
| efried | aspiers: But I also meant to mention this: | 18:02 |
| efried | if something like that does come up, we can always add a new, specialized resource class for that. | 18:02 |
| aspiers | well sure, but that's why I was suggesting starting with an implementation-specific resource class | 18:03 |
| efried | aspiers: But do you understand my counter-usecase for that? | 18:03 |
| efried | It means you'll *never* be able to schedule generically. | 18:03 |
| *** lbragstad has joined #openstack-nova | 18:03 | |
| efried | whereas if you start generic, you can always get more specific. | 18:04 |
| aspiers | I don't see why, since our plan is for the user to always use encrypt_memory=true | 18:04 |
| aspiers | the request filter can then decide into which resource classes to translate that request | 18:04 |
| efried | yes, exactly. | 18:04 |
| efried | In an env where there's AMD_SEV and INTEL_MKTME, which would it choose? | 18:05 |
| aspiers | so a RequestSpec can't do "give me either foo or bar"? | 18:05 |
| efried | nope | 18:05 |
| aspiers | ahah | 18:05 |
| sean-k-mooney | you can do that with traits | 18:05 |
| efried | more to the point, placement can't | 18:05 |
| sean-k-mooney | but not resouce classes | 18:06 |
| sean-k-mooney | actully that has not merged yet | 18:06 |
| aspiers | OK | 18:06 |
| sean-k-mooney | or been coded | 18:06 |
| aspiers | efried: so it sounds like basically this isn't even a debate, the only way to make it work is to have a vendor-agnostic resource class :) | 18:07 |
| sean-k-mooney | im think of https://review.opendev.org/#/c/649992/ | 18:07 |
| efried | sean-k-mooney: We have ?traits=in:X,Y,Z, don't we?? | 18:07 |
| *** tssurya has quit IRC | 18:07 | |
| aspiers | I'm fine with that - it's certainly going to make it easier to justify in the spec | 18:07 |
| sean-k-mooney | efried: there is a spec for that | 18:07 |
| sean-k-mooney | which is the one i linked https://review.opendev.org/#/c/649992/ | 18:07 |
| * aspiers takes a short break, back in ~15 | 18:08 | |
| *** ivve has joined #openstack-nova | 18:10 | |
| *** tssurya has joined #openstack-nova | 18:10 | |
| efried | aspiers: One can envisage starting off with a specific resource class, and then moving to a generic one when the next one is introduced. Resulting in an interesting upgrade problem where you may have to "reshape" existing inventories/allocations from the old resource class to the new one. And we still support mismatched conductor/compute environments, IIRC, though I can never remember which one has to go first, so that could also | 18:10 |
| efried | aspiers: So it's still a debate, yes; it could be made to work either way, yes; but IMO for reasons stated, generic is a bit more future-proof without actually losing you anything. | 18:11 |
| efried | sean-k-mooney: Hmph, I coulda sworn we already had required=in:..., but I don't see it in the api-ref. | 18:12 |
| efried | yup, that spec. | 18:13 |
| sean-k-mooney | ya so they were previously approved for stein but no implemented | 18:14 |
| sean-k-mooney | anyway with a generic resocue class and specific trats we could support that usecase if we hav requrie=in | 18:15 |
| sean-k-mooney | or we could reshape | 18:15 |
| sean-k-mooney | we do however already have the trait | 18:16 |
| *** ricolin has quit IRC | 18:17 | |
| efried | mriedem: Would you be able to run the nova meeting this Thursday? I got suckered^wroped into school runs. I should be back around :15-:20. | 18:22 |
| openstackgerrit | Eric Fried proposed openstack/nova master: Hacking N363: Don't use spec[_set]='string' https://review.opendev.org/650370 | 18:31 |
| *** nicolasbock has joined #openstack-nova | 18:31 | |
| openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: Pass on region when we don't have a valid ironic endpoint https://review.opendev.org/654692 | 18:36 |
| *** eharney has joined #openstack-nova | 18:39 | |
| mriedem | efried: yeah i think i can do that | 18:41 |
| efried | thanks mriedem | 18:41 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Support adding the reason behind a server lock https://review.opendev.org/648662 | 18:42 |
| efried | eandersson: Hmph, I see why you did that; perhaps I need a separate bug for min/max | 18:42 |
| efried | as currently stacked, min/max would have to be partial and yours would have to be closes | 18:42 |
| eandersson | Nah I think your bug is the real fix | 18:42 |
| eandersson | Mine is just a fallback bug fix | 18:42 |
| *** amodi has joined #openstack-nova | 18:43 | |
| eandersson | but I am fine with separate bug reports as well | 18:43 |
| efried | eandersson: Mine should really have a bug that says, "ksa endpoint lookup never worked because of min_version" | 18:43 |
| efried | Your bug is about region_name not being respected, which is true regardless of my fix. | 18:44 |
| efried | eandersson: You want to open the other or should I? | 18:44 |
| efried | I mean, credit's to you for finding the problem (and pretty much for tracking down the cause too) so... | 18:45 |
| * efried attempts to use flattery to get eandersson to do the paperwork | 18:45 | |
| eandersson | Haha | 18:47 |
| eandersson | Actually yours fixes my bug 99.9% | 18:47 |
| eandersson | of the time | 18:47 |
| eandersson | The only time your fix does not fix my bug is if ServiceNotFound is raised | 18:47 |
| efried | which probably would mean that ironicclient would raise the same | 18:48 |
| eandersson | Very likely | 18:48 |
| efried | I can live with that. I can change mine to Partial-Bug and yours can be Closes-Bug. Or we can swap the order of the fixes. But I don't think we're allowed to have Partial-Bug *after* Closes-Bug. mriedem, a ruling? | 18:49 |
| eandersson | The only difference is that the ironicclient is less opiniated (in it's current implementation) | 18:49 |
| eandersson | Sure | 18:49 |
| efried | ...I guess we can break them apart too. There's actually no reason for them to be in a series, I don't think. | 18:49 |
| mriedem | efried: don't think that matters too much, but partial-bug will change the assignee, whereas related-bug wouldn't | 18:50 |
| mriedem | so i'd use related-bug or separate bugs | 18:50 |
| efried | they're truly both fixing part of the bug. | 18:51 |
| eandersson | I assumed that partial-bug wouldn't change the assignee | 18:51 |
| efried | but okay, if the assignee is the only bit of process that matters | 18:51 |
| eandersson | The more you know | 18:51 |
| efried | and we can always change the assignee | 18:52 |
| efried | so effit, let's go as is. | 18:52 |
| eandersson | Sounds good | 18:52 |
| efried | mriedem: series at https://review.opendev.org/#/c/654457/ when you get a chance -- ironic ksa stuff never worked (/me sheepish); but ironicclient covered for us; but wasn't respecting region_name when it did, we were just getting lucky most of the time. | 18:53 |
| efried | what other core can tackle ksa stuff? | 18:53 |
| tssurya | mriedem: silly question - does the addition of an existing key (locked) to filters/sorting have anything to do with microversions ? as in we just allow them without any checks from the moment we implement them right ? | 18:53 |
| eandersson | It was also partially broken on the ironic client side https://github.com/openstack/python-ironicclient/commit/c038f1db67e7809513d5535648d15c3590b191d5 | 18:54 |
| mriedem | tssurya: there is a whitelist on filters and sorting params, | 18:54 |
| tssurya | right, | 18:54 |
| mriedem | specifying filters that aren't in the whitelist are just ignored for now (gmann has a spec to make that an error), | 18:54 |
| mriedem | specifying sort params that aren't in the whitelist is a 400 | 18:55 |
| mriedem | so you can't add locked as a filter/sort param without a microversion bump | 18:55 |
| mriedem | efried: ack | 18:55 |
| *** amodi has quit IRC | 18:55 | |
| mriedem | tssurya: that's how i verified you couldn't just filter/sort on the instance.hidden field in my change | 18:55 |
| tssurya | mriedem: ah because of change in behaviour for sort params? | 18:56 |
| mriedem | yes | 18:56 |
| mriedem | i thought we said in your spec we weren't going to start filtering/sorting on locked? | 18:56 |
| tssurya | oh we did ? :D | 18:56 |
| mriedem | oh nvm | 18:56 |
| mriedem | "Filtering/Sorting: The locked key will be added to the existing list of valid sorting/filtering keys so that instances can be filtered/sorted based on this field." | 18:56 |
| tssurya | the last iteration was that we would | 18:56 |
| mriedem | i might have been thinking of locked_by | 18:56 |
| tssurya | yea | 18:56 |
| tssurya | okay since I have the bump anyways might as well add this too | 18:57 |
| mriedem | yeah so you'll need a microversion | 18:57 |
| tssurya | thanks mriedem | 18:57 |
| mriedem | np | 18:57 |
| mriedem | gmann: you might want to comment on this https://review.opendev.org/#/c/648919/4/specs/train/approved/int-replace-default-value-of-the-flavor-swap.rst@77 | 19:08 |
| mriedem | it's a small inconsistency cleanup in the api spec so people have said it should be merged into your general cleanup spec, but that's just adding more stuff to your already somewhat large api change | 19:09 |
| -openstackstatus- NOTICE: the zuul scheduler is being restarted now in order to address a memory utilization problem; changes under test will be reenqueued automatically | 19:09 | |
| mriedem | efried: questions in https://review.opendev.org/#/c/654457/ | 19:23 |
| efried | ... | 19:23 |
| efried | eandersson: ^ | 19:24 |
| mriedem | why not squash those 2 changes together? | 19:25 |
| *** mvkr has joined #openstack-nova | 19:25 | |
| efried | They're pretty unrelated. | 19:27 |
| *** nicolasbock has quit IRC | 19:27 | |
| efried | one fixes how we do ksa stuff, the other fixes how we construct the ironicclient | 19:27 |
| *** nicolasbock has joined #openstack-nova | 19:27 | |
| mriedem | it seems the answer to my question here https://review.opendev.org/#/c/654457/2/nova/virt/ironic/client_wrapper.py@131 though is 'ironicclient will try to sort it out' but needs the region_name passed along as well (if you've got multiple regions and are configuring nova-compute to talk to different ones) | 19:29 |
| *** igordc has joined #openstack-nova | 19:29 | |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Support adding the reason behind a server lock https://review.opendev.org/648662 | 19:31 |
| efried | mriedem: Yes. | 19:31 |
| efried | Though I think that was actually not the case until recently. | 19:32 |
| efried | I think the logic to "figure it out" was broken until https://github.com/openstack/python-ironicclient/commit/c038f1db67e7809513d5535648d15c3590b191d5 ? | 19:32 |
| efried | mriedem: so, do you want these squashed? Am I being silly asserting that they're doing different things? | 19:33 |
| *** boxiang has quit IRC | 19:36 | |
| mriedem | well, it looks like it might be better to keep them separate because of how ironicclient handles the kwargs in older releases, it looks like region_name was only since Ifc7b45d047c8882a41021e1604b74d17eac2e6e8 in rocky and before that it was os_region_name | 19:37 |
| mriedem | so backports to queens for eandersson's change could be a bit trickier | 19:37 |
| mriedem | especially since we don't have integration testing for this stuff | 19:37 |
| *** boxiang has joined #openstack-nova | 19:37 | |
| *** tssurya has quit IRC | 19:39 | |
| mriedem | ok +2 on the bottom and +W on the top | 19:41 |
| efried | thanks mriedem. Any idea who else should look at the bottom one? | 19:41 |
| mriedem | https://review.opendev.org/#/q/topic:bug/1825583+(status:open+OR+status:merged) | 19:41 |
| mriedem | cleans that up | 19:41 |
| mriedem | you guys and your silly tp's | 19:41 |
| mriedem | *tb's | 19:42 |
| mriedem | efried: ummm, melwitt? | 19:42 |
| * mriedem spins the nova core wheel of fortune | 19:42 | |
| artom | Wheel of cortune | 19:42 |
| efried | nice | 19:42 |
| artom | That's basically the extent of my contribution here. Puns. | 19:43 |
| eandersson | Not backporting mine beyond Rocky is fine, as the main patch will fix most cases. | 19:49 |
| eandersson | And endpoint_override is a valid work around. | 19:50 |
| *** idlemind has quit IRC | 19:52 | |
| mriedem | and you're on rocky so you don't have to care about queens :) | 20:00 |
| *** igordc has quit IRC | 20:10 | |
| mriedem | it's sad that something as simple as "pass az to unshelve" https://review.opendev.org/#/c/624689/ is this complicated | 20:13 |
| *** igordc has joined #openstack-nova | 20:14 | |
| *** igordc has quit IRC | 20:15 | |
| mriedem | sorrison: i think this old bug https://bugs.launchpad.net/nova/+bug/1453629 has been fixed since pike due to https://review.opendev.org/#/c/446053/ - are you on pike or later and can confirm? | 20:16 |
| openstack | Launchpad bug 1453629 in OpenStack Compute (nova) "Creating neutron ports uses incorrect instance availability zone" [Low,Confirmed] | 20:16 |
| *** colby_ has joined #openstack-nova | 20:18 | |
| colby_ | Hey All. Is there any way to have shelved_offloaded instances not count toward cpu hours/ram hour usage? | 20:18 |
| aspiers | efried: if resources:foo=1 doesn't currently work with image properties, I'm unsure how it would work when translating another image property gimme_foo=true into it within request_filter.py | 20:19 |
| aspiers | efried: wouldn't we have to add support to ResourceRequest.from_image_props() at least? | 20:21 |
| sean-k-mooney | aspiers: you are not allowed to request resoruce from an image | 20:22 |
| sean-k-mooney | and i dont think that should be part of teh SEV spec if we intoduce it | 20:23 |
| aspiers | sean-k-mooney: is the term "resource" overloaded here? | 20:24 |
| sean-k-mooney | i assume resouce:foo was a placment resouce class request | 20:24 |
| aspiers | sean-k-mooney: by the way it's named, ResourceRequest.from_image_props() considers an image property requesting a trait as a resource request | 20:24 |
| sean-k-mooney | that is not allowed in an image | 20:25 |
| aspiers | so in that naming, a "resource" can also refer to something wider which can include traits, not just something from a resource class | 20:25 |
| sean-k-mooney | is that in the nova code? | 20:25 |
| aspiers | yes | 20:25 |
| aspiers | nova/scheduler/utils.py | 20:26 |
| aspiers | ResourceRequest.from_image_props() | 20:26 |
| aspiers | currently it only supports required traits | 20:26 |
| sean-k-mooney | that jus tgets the traits | 20:26 |
| aspiers | and you seem to be saying that it shouldn't support required resource classes | 20:26 |
| sean-k-mooney | it does not extrage resouces | 20:26 |
| sean-k-mooney | *extract | 20:26 |
| sean-k-mooney | correct it should not | 20:27 |
| aspiers | why is that not allowed? | 20:27 |
| sean-k-mooney | because i can very eassilay do a denical of serivce attack | 20:27 |
| aspiers | I got the impression from other conversations with efried that we could do this | 20:27 |
| sean-k-mooney | or get access to hardware im not billed for | 20:27 |
| aspiers | how? | 20:27 |
| sean-k-mooney | user can upload images | 20:28 |
| aspiers | oh I see | 20:28 |
| sean-k-mooney | if they can request any resouce then can ask for a vgpu for example but select the smalest flavor | 20:28 |
| aspiers | how is that different with traits? | 20:28 |
| sean-k-mooney | traits do not change teh abount of resocue you are requesting | 20:28 |
| sean-k-mooney | then just filter the posible resouce providers that the resouce can come form | 20:29 |
| artom | I think aspiers's point is that a public cloud might want to bill for a qualitative thing | 20:29 |
| aspiers | right | 20:29 |
| artom | Like SEV ;) | 20:29 |
| sean-k-mooney | artom: they might | 20:29 |
| sean-k-mooney | but its not a security risk | 20:29 |
| efried | aspiers: Until we polish up that RequestSpec.requested_resources thing: | 20:30 |
| efried | You're translating encrypt_my_memory=true, which you glean from either the image or the flavor extra specs, gleaned from the RequestSpec | 20:30 |
| efried | ==> to a resources:MEM_ENC_CTX=1 in the same RequestSpec's flavor extra specs | 20:30 |
| efried | but that's okay because that request spec's flavor is *not* persisted to the db. | 20:30 |
| efried | So the placement-ese resource request exists as a flavor extra spec when it's used to create the placement GET /a_c request, but only then. | 20:30 |
| artom | Well, no, but it's still a financial risk if users can give themselves qualitative things through image props | 20:30 |
| sean-k-mooney | artom: if you care you can use glances upload filetre to prevent it or not allow user to set metadta on an image | 20:31 |
| artom | True | 20:31 |
| aspiers | efried: ohhh I see | 20:31 |
| efried | technically you're requesting resource from an image property. But not explicitly with placement-y resources keys. | 20:31 |
| sean-k-mooney | but the point is we deliberly choose not to allow resocue request wehn we enabeld tratis | 20:31 |
| *** pcaruana has quit IRC | 20:32 | |
| mriedem | colby_: there is no support for that but it's come up several times | 20:34 |
| mriedem | colby_: tbc, do you mean not count in the os-simple-tenant-usage API? | 20:34 |
| mriedem | or not count toward quota? | 20:35 |
| aspiers | efried, sean-k-mooney: can we quickly bikeshed the name for the resource class? e.g. MEM_ENC_CTX vs. MEMORY_ENCRYPTED_CONTEXT etc. Do we even need the _CONTEXT suffix? I can't see any precedent for it | 20:35 |
| sean-k-mooney | i think we need the sufics otherwise its not a noun | 20:35 |
| aspiers | it could be ENCRYPTED_MEMORY | 20:36 |
| efried | aspiers: The suffix is traditionally units. A sev context thingy is kinda unitless, so not sure that applies. | 20:36 |
| sean-k-mooney | thats still technically an ajitive | 20:36 |
| efried | ENCRYPTED_MEMORY makes it sound like a trait. | 20:36 |
| sean-k-mooney | yep | 20:36 |
| aspiers | encrypted is an adjective, memory is a noun | 20:37 |
| sean-k-mooney | not really | 20:37 |
| aspiers | really ;-) | 20:37 |
| aspiers | well, for sure memory is a noun | 20:38 |
| aspiers | I think encrypted is a gerund or maybe a gerundive | 20:38 |
| aspiers | and they function as an adjective at least | 20:38 |
| sean-k-mooney | my other issue with encryped_memory is the units it impiles | 20:38 |
| aspiers | agreed | 20:38 |
| sean-k-mooney | we have memory_mb | 20:39 |
| sean-k-mooney | i woudl expect encrpted_memory to also be in mb | 20:39 |
| aspiers | yup, so that doesn't work | 20:39 |
| sean-k-mooney | encrypted_memory_context | 20:39 |
| sean-k-mooney | i woudl expect ot have idfferent units | 20:39 |
| aspiers | memory_encrypted_guests? | 20:40 |
| aspiers | the unit is one guest | 20:40 |
| sean-k-mooney | no the units are stil wrong | 20:40 |
| aspiers | wrong how? | 20:41 |
| sean-k-mooney | if i have a multi numa node guest how many sev contextes do i need 1 or more then 1 | 20:41 |
| aspiers | 1 | 20:41 |
| aspiers | AFAIK | 20:41 |
| sean-k-mooney | the bit that buggs me with memory_encrypted_guests is if we port the num_instance_filter to placement in the future | 20:42 |
| sean-k-mooney | we could have an inventory of guests/isntance | 20:42 |
| sean-k-mooney | ont he hypervior | 20:42 |
| aspiers | why is that an issue/ | 20:42 |
| sean-k-mooney | so it coudl be a bit strange to consome 1 allocation of memory_encrypted_guest and 1 allocation of insntace | 20:43 |
| aspiers | doesn't seem particularly strange to me :) | 20:43 |
| aspiers | they are different counts | 20:44 |
| sean-k-mooney | why not just SEV_CONTEXT | 20:44 |
| aspiers | because efried doesn't want a vendor-specific name | 20:44 |
| sean-k-mooney | i had tought efried last stamet was to go with a speficig vendero one first | 20:44 |
| aspiers | as discussed earlier | 20:44 |
| aspiers | no, the opposite | 20:44 |
| sean-k-mooney | efried: ? | 20:44 |
| aspiers | I proposed SEV_CONTEXT and he argued for the opposite | 20:45 |
| aspiers | you can see in the latest spec comments | 20:45 |
| aspiers | https://review.opendev.org/#/c/641994/11/specs/train/approved/amd-sev-libvirt-support.rst@541 | 20:45 |
| sean-k-mooney | we went back and fort on that a few times so i was nto sure what the latest was | 20:45 |
| aspiers | there are pros and cons both ways | 20:46 |
| aspiers | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-04-23.log.html#t2019-04-23T18:03:32 | 20:46 |
| *** artom has quit IRC | 20:48 | |
| sean-k-mooney | well unless its partiaclarly egregious im not going to -1 over the resocue class name | 20:48 |
| aspiers | OK thanks but would still be nice to pick a good name ;-) | 20:48 |
| aspiers | I was just wondering where the _CONTEXT idea came from | 20:49 |
| sean-k-mooney | i take it you dislike the presence of context | 20:49 |
| sean-k-mooney | proably me | 20:49 |
| aspiers | only slightly, just feels a bit vague | 20:49 |
| sean-k-mooney | well for me i thing of security context in many forms | 20:49 |
| aspiers | but I haven't really come up with anything more precise except _GUEST | 20:49 |
| aspiers | it would be good to find something which conveys the "1 per guest" notion | 20:50 |
| sean-k-mooney | like an ipsec context | 20:50 |
| aspiers | like _SLOTS | 20:50 |
| aspiers | not sure if slots has other meanings in nova already? | 20:51 |
| sean-k-mooney | slot have a more generic meaning to me | 20:51 |
| sean-k-mooney | but kindof | 20:51 |
| aspiers | well at least slots are clearly discrete integer values | 20:51 |
| aspiers | context doesn't imply discrete or continuous or int or float etc. | 20:51 |
| sean-k-mooney | you havent worked with enough hardware people | 20:51 |
| aspiers | hahah | 20:51 |
| aspiers | thankfully | 20:51 |
| sean-k-mooney | you can make a nice logical assumtionlike slot can be subdevided an they will alwyas find a reason / way to make it happen | 20:52 |
| aspiers | true | 20:53 |
| sean-k-mooney | you can proable kick the precise name out of the sepc and leave it to the implemetnaiton | 20:53 |
| aspiers | OK maybe let's wait for $0.02 from efried | 20:53 |
| aspiers | yes good point | 20:53 |
| aspiers | I'll stick with MEM_ENCRYPTED_CONTEXT for now | 20:53 |
| aspiers | and I'm gonna check with AMD that it really is 1 per guest | 20:54 |
| aspiers | https://www.redhat.com/archives/libvir-list/2019-January/msg00652.html is all I have to go on currently | 20:54 |
| sean-k-mooney | aspiers: looking at the livirt schema | 21:01 |
| sean-k-mooney | https://github.com/libvirt/libvirt/blob/545b0574fd27b56f243e21711935f99160cec214/docs/schemas/domaincommon.rng#L458-L490 | 21:01 |
| sean-k-mooney | it only allows 1 launchSecurity element | 21:01 |
| sean-k-mooney | so regarless of what amd requires libvirt can only enabel 1 | 21:02 |
| aspiers | well, launchSecurity has a bunch of parameters | 21:03 |
| sean-k-mooney | yes | 21:03 |
| aspiers | and whatever hardware resource is being consumed by each guest could feasibly depend on other things | 21:03 |
| aspiers | like it could be one per vcpu for example | 21:03 |
| sean-k-mooney | but it can only exist once and non fo the sub element can be repeteded | 21:03 |
| aspiers | then it wouldn't be dependent on this XML | 21:03 |
| aspiers | or 1 per numa node | 21:03 |
| aspiers | but I'm just sending an email to the AMD guys now to double-check | 21:04 |
| sean-k-mooney | let me double check | 21:04 |
| aspiers | so we should know for sure soon | 21:04 |
| sean-k-mooney | cool | 21:04 |
| aspiers | sent | 21:05 |
| colby_ | mriedem: yea currently we use nova usage for billing purposes. I have gnocchi running and have not looked into if it excludes shelved instances or not from usage data | 21:05 |
| sean-k-mooney | aspiers: i can only exist once in the domain https://github.com/libvirt/libvirt/blob/545b0574fd27b56f243e21711935f99160cec214/docs/schemas/domaincommon.rng#L81-L83 | 21:06 |
| aspiers | sean-k-mooney: yeah, we already have code parsing that https://review.opendev.org/#/c/636318/3/nova/virt/libvirt/config.py | 21:07 |
| aspiers | (which is unfinished BTW) | 21:08 |
| efried | aspiers: I like MEM_ENCRYPTED_CONTEXT | 21:10 |
| aspiers | efried: that's lucky, since I just did a search and replace to change everything to that ;-) | 21:10 |
| efried | I agree with the gripe about _GUEST or _INSTANCE or similar. _SLOT seems too loaded with meaning, like I/O slot. | 21:11 |
| aspiers | yeah fair | 21:11 |
| efried | MEM_ENCRYPTION_CONTEXT would be better actually. | 21:11 |
| efried | ION vs ED | 21:11 |
| aspiers | oh yeah | 21:12 |
| efried | otherwise it's the context that's mem-encrypted. | 21:12 |
| efried | when really you want a mem encryption context | 21:12 |
| efried | for your instance :) | 21:12 |
| aspiers | right | 21:12 |
| aspiers | efried: and the user-friendly extra spec / property name is gonna be what exactly? since we're bike-shedding :) | 21:14 |
| aspiers | I'm adding that to the spec now | 21:14 |
| sean-k-mooney | aspiers: hw:mem_encrypt=True | 21:15 |
| sean-k-mooney | hw:mem_encrypt=sev | 21:15 |
| aspiers | LOL | 21:15 |
| efried | sean-k-mooney: Why the hw: prefix, out of curiosity? | 21:15 |
| aspiers | well the whole point of this one is to be vendor-agnostic | 21:15 |
| efried | otherwise, mem_encrypt=True is fine by me. (Is it True or true?) | 21:15 |
| sean-k-mooney | because all standard flavor extraspecs are namespaced | 21:15 |
| aspiers | especially since it will get mapped to resources:MEM_ENCRYPTION_CONTEXT=1 | 21:16 |
| sean-k-mooney | efried:whatever the user provides we should lower case | 21:16 |
| sean-k-mooney | and document "tRue" to mess with stephenfin | 21:17 |
| efried | heh | 21:17 |
| sean-k-mooney | im jsut catich up with the last few comment on the spec by they way | 21:18 |
| efried | okay, if there's some good reason to have a prefix, and there's some good reason for that prefix to be hw:, then some variant of hw:mem_encrypt=$bool is fine with me. hw:mem_encryption would have a nice symmetry with the resource class name. | 21:18 |
| *** igordc has joined #openstack-nova | 21:19 | |
| sean-k-mooney | ya that would be good with me too | 21:19 |
| aspiers | I like the consistency of the hw: prefix | 21:20 |
| efried | btw, aspiers, can I strike this topic from the PTG agenda? | 21:20 |
| efried | since it seems pretty much resolved? | 21:20 |
| aspiers | efried: the spec topic? only if we get it merged before the PTG ;-) | 21:20 |
| sean-k-mooney | :) | 21:20 |
| aspiers | I hope I can still find an excuse to spend time in the nova room though | 21:20 |
| aspiers | invent some more SEV problems for us to solve together ;-) | 21:21 |
| aspiers | well I guess there's still the implementation haha | 21:21 |
| aspiers | I'll just hack away in a corner and occasionally ask stupid questions | 21:21 |
| sean-k-mooney | add numa to the spec somewhere. it will delay it by a decade | 21:21 |
| efried | aspiers: You can own this one: | 21:21 |
| efried | Compute capabilities traits placement request filter (mriedem) | 21:21 |
| aspiers | sean-k-mooney: LOL | 21:21 |
| aspiers | efried: uhoh :) | 21:21 |
| efried | it'll actually be very closely related to what you're doing here. | 21:22 |
| aspiers | well sure that sounds interesting | 21:23 |
| efried | hmph, except for the wrinkle in the existing patch about not being able to get at the multiattach bool from within request_filter.py, the generic solution would be pretty easy there. | 21:23 |
| sean-k-mooney | its also related in a way to the image metadata prefilteing im hoping to work on although not quite the same | 21:24 |
| openstackgerrit | Merged openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640198 | 21:24 |
| sean-k-mooney | anyway looking at the sev spec which i just finsished again. | 21:24 |
| sean-k-mooney | we proably could merge it as is and fixup the last few nits in a follow up patch | 21:24 |
| sean-k-mooney | but that up to ye | 21:25 |
| sean-k-mooney | i didnt see any really blocker anymore | 21:25 |
| aspiers | sean-k-mooney: thanks, just got a few minor tweaks based on last few hours of discussion | 21:25 |
| aspiers | I'll submit one more patch set and hopefully that will be enough | 21:25 |
| sean-k-mooney | on the + side your feature already has excelent documentation | 21:26 |
| aspiers | cool | 21:26 |
| aspiers | oh I already got a response from Brijesh at AMD | 21:27 |
| aspiers | he confirms it's 1 unit per guest | 21:27 |
| sean-k-mooney | excelent | 21:27 |
| aspiers | and there will always be a limit, which can be queried through the CPUID | 21:27 |
| sean-k-mooney | ya that is not surprising | 21:27 |
| efried | always always? | 21:27 |
| efried | like, don't need the conf var always? | 21:28 |
| aspiers | always always a limit | 21:28 |
| *** tosky has joined #openstack-nova | 21:28 | |
| aspiers | https://marc.info/?l=qemu-devel&m=155502702424182&w=2 | 21:28 |
| sean-k-mooney | well i think they ment there will alway be a limit in hardware | 21:28 |
| aspiers | yes | 21:28 |
| sean-k-mooney | but not sure that mean we can discover it via cpuid yet | 21:28 |
| aspiers | that patch exposes it in QEMU | 21:28 |
| aspiers | next step would be to expose in libvirt getDomainCapabilities() | 21:29 |
| aspiers | at which point we can get it in nova | 21:29 |
| efried | but that would require a bump in the min qemu version and stuff... | 21:29 |
| efried | which I thought was kind of already what was discussed with danpb | 21:29 |
| sean-k-mooney | ok so we need to cary the config option for at least 2 years | 21:29 |
| aspiers | efried: not just with danpb but already covered in the spec | 21:31 |
| aspiers | sean-k-mooney: yeah most likely | 21:31 |
| sean-k-mooney | jaypipes: thanks for reviewing the sriov mighration pathces :) | 21:33 |
| sean-k-mooney | now if only stephenfin or maybe efried could leave the final +2+w it could merge before the ptg | 21:33 |
| sean-k-mooney | or more importantly before one of the 41 conflicting patches does | 21:34 |
| efried | sean-k-mooney: link please | 21:34 |
| sean-k-mooney | https://review.opendev.org/#/c/629589/27 | 21:34 |
| sean-k-mooney | that and https://review.opendev.org/#/c/620115/35 | 21:34 |
| efried | When you say things like sriov and live migration I immediately think, "I hope someone else has got this." | 21:34 |
| aspiers | sean-k-mooney, efried: BTW funnily enough Brijesh's reply when I asked why there is a limit "We have limited number of slots in memory controller, each slot gets a different encryption key." | 21:35 |
| efried | hah! | 21:35 |
| sean-k-mooney | ya | 21:35 |
| efried | MEM_ENCRYPTION_KEY_SLOTS | 21:35 |
| efried | again, pretty impl specific. Let's stick with CONTEXT | 21:36 |
| aspiers | OK X-D | 21:36 |
| sean-k-mooney | it had to be somthign like that e.g. they what a fix number of keys they coudl handel | 21:36 |
| aspiers | yeah | 21:36 |
| sean-k-mooney | with this kid of thing you donw want those stored in ram which means sticking them in a register file somewhere | 21:37 |
| sean-k-mooney | and you only have so much spcae on a die to add that memory so there will always be a limit like this | 21:37 |
| sean-k-mooney | at least 15/16 is resonable | 21:38 |
| aspiers | right | 21:38 |
| sean-k-mooney | i remember being asked to enable QOS policies with intel QAT devices at one point where the limit was 4 | 21:38 |
| aspiers | haha | 21:39 |
| sean-k-mooney | you could have 32 VF | 21:39 |
| sean-k-mooney | but only 4 QOS policies | 21:39 |
| sean-k-mooney | and it was a 1:1 maping between QOS policey and a singel VF | 21:39 |
| sean-k-mooney | if you used any of the other ones they ignroed the qos policy | 21:39 |
| sean-k-mooney | we never enabeld in in openstack. | 21:40 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: AZ list performance optimization: avoid double service list DB fetch https://review.opendev.org/636947 | 21:40 |
| mriedem | efried: i found and cleaned this up with test wrinkles and addressed some of my own comments ^ let me know if you think it needs more | 21:40 |
| mriedem | but yeah that's a really nice perf improvement from avolkov | 21:40 |
| *** whoami-rajat has quit IRC | 21:40 | |
| efried | mriedem: ack, looking. | 21:41 |
| *** tjgresha_nope has quit IRC | 21:41 | |
| efried | are you recusing yourself from approving at this point? | 21:41 |
| sean-k-mooney | mriedem: ya it look like its about half the time | 21:41 |
| mriedem | efried: not necessarily | 21:41 |
| mriedem | i just added test stuff and some code comments | 21:41 |
| *** ttsiouts has joined #openstack-nova | 21:42 | |
| *** tjgresha has joined #openstack-nova | 21:43 | |
| openstackgerrit | Merged openstack/python-novaclient master: Updates for OpenDev transition https://review.opendev.org/654429 | 21:43 |
| sean-k-mooney | ya the delta for what you added is mainly non functional changes | 21:43 |
| sean-k-mooney | so is the main sped up form getting the avilablity zones for jsut the enabled serivces | 21:45 |
| efried | mriedem: lgtm. Why did you switch from monkeypatch to mock.patch? | 21:46 |
| mriedem | so i can count the calls | 21:46 |
| mriedem | silly pants | 21:46 |
| mriedem | sean-k-mooney: it's that we don't get enabled services across 10K hosts twice | 21:47 |
| aspiers | did you folks spot the pysnooper tip? | 21:47 |
| sean-k-mooney | ah | 21:48 |
| sean-k-mooney | ya | 21:48 |
| sean-k-mooney | im not sure if ill end up using it or not but we will see | 21:48 |
| aspiers | it looks pretty nice | 21:48 |
| sean-k-mooney | ya but im not sure it will actully be helpful fo more complicate things. but next time i ned to debug some thing complex and im not usgin a grapical debugger ill give it a try | 21:52 |
| efried | mriedem: oh, stub_out doesn't return the fixture. And apparently MonkeyPatch doesn't have a .mock attribute, like MockPatch does. Remind me why we have stub_out? | 21:53 |
| efried | (rhetorical) | 21:53 |
| gmann | mriedem: RE: on job, yes it will merge the var from parent and derived jobs. | 21:55 |
| gmann | mriedem: few zuul var are not append-able for example files, irrelevant-files etc which are regex not array. but devstack var are all merged from all hierarchy of job | 21:57 |
| mriedem | jaypipes: fat ol -2 on this https://review.opendev.org/#/c/625755/ if you remember it | 21:59 |
| mriedem | efried: to get off mox? | 21:59 |
| mriedem | gmann: yup thanks. i'm now just waiting a few days for ci results. :) | 22:00 |
| *** imacdonn has quit IRC | 22:01 | |
| *** imacdonn has joined #openstack-nova | 22:01 | |
| sean-k-mooney | mriedem: by the way did you want to review the sriov migrtion stuff or are you happy to leave it to jay and stephen | 22:07 |
| mriedem | want to? | 22:09 |
| mriedem | why don't you have it in a runway if you're looking for reviews? | 22:09 |
| sean-k-mooney | oh good point | 22:09 |
| sean-k-mooney | its going to take w while form e to get opendev.org into fingre memory. im really glad the got the redirects in place | 22:12 |
| sean-k-mooney | anyway night all o/ | 22:12 |
| *** slaweq has quit IRC | 22:12 | |
| *** slaweq has joined #openstack-nova | 22:14 | |
| mriedem | speaking of it looks like we have busted jobs on stable branches b/c the openstack-infra/devstack-gate change wasn't made there in our .zuul.yaml | 22:15 |
| mriedem | eandersson: are you going to work on backports for these? https://review.opendev.org/#/q/topic:bug/1825583+status:open+project:openstack/nova | 22:19 |
| eandersson | If I get the time this week. Got a busy schedule, and well next week is Denver. | 22:20 |
| eandersson | So can't promise that I will be able to do it before Denver. | 22:20 |
| mriedem | minions... | 22:20 |
| eandersson | =] | 22:20 |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207 | 22:30 |
| *** jangutter has quit IRC | 22:35 | |
| *** tonyb has joined #openstack-nova | 22:41 | |
| efried | o/ | 22:42 |
| *** luksky has quit IRC | 22:43 | |
| openstackgerrit | Merged openstack/nova master: Only set oslo_messaging_notifications.driver if using RPCFixture https://review.opendev.org/653954 | 22:50 |
| *** tkajinam has joined #openstack-nova | 22:55 | |
| openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.opendev.org/641994 | 22:56 |
| aspiers | efried, sean-k-mooney, jaypipes: patch set 12 now up, hopefully the final one https://review.opendev.org/#/c/641994/11..12//COMMIT_MSG | 23:02 |
| openstackgerrit | Ivens Zambrano proposed openstack/nova-specs master: RMD Plugin: Energy Efficiency using CPU Core P-State control The power state of a core can be setup between a minimum and the maximum frequency on the cores as defined in the factory. Each core on a CPU can be defined individually to perform at specific f https://review.opendev.org/651024 | 23:02 |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Add infrastructure for invoking libvirt's getDomainCapabilities API https://review.opendev.org/655268 | 23:09 |
| openstackgerrit | Tony Breeds proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207 | 23:12 |
| *** tosky has quit IRC | 23:13 | |
| *** ttsiouts has quit IRC | 23:14 | |
| *** ttsiouts has joined #openstack-nova | 23:15 | |
| *** gmann is now known as gmann_afk | 23:17 | |
| *** ttsiouts has quit IRC | 23:19 | |
| *** rcernin has joined #openstack-nova | 23:20 | |
| *** mlavalle has quit IRC | 23:24 | |
| openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.opendev.org/633855 | 23:27 |
| aspiers | kashyap: ^^^ I finally gave you what you wanted ;-) | 23:32 |
| aspiers | you'll note that the SEV patch is extremely readable now | 23:32 |
| *** igordc has quit IRC | 23:32 | |
| * aspiers goes to bed | 23:32 | |
| *** gyee has quit IRC | 23:39 | |
| *** jangutter has joined #openstack-nova | 23:40 | |
| *** artom has joined #openstack-nova | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!