| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 16:20:58 | gmann | mriedem: fixed all formatting and scheduler_hints - https://review.openstack.org/#/c/603969/ | |
| 16:22:02 | cfriesen | kashyap: oooh, interesting. the fedora package has both | |
| 16:22:11 | kashyap | cfriesen: Yes | |
| 16:22:26 | kashyap | cfriesen: This whole OVMF binary file names across distributions is a cluster fuck sized Jupiter | |
| 16:22:31 | kashyap | cfriesen: But ... good news! | |
| 16:22:56 | kashyap | cfriesen: That's why upstream QEMU we introduced a formal *schema* (the @Firmware thing you read) | |
| 16:23:30 | kashyap | cfriesen: Because the firmware paths and names differ _across_ distros. E.g. see this on Ubuntu: https://packages.ubuntu.com/disco/all/ovmf/filelist | |
| 16:27:29 | kashyap | cfriesen: Anyway, all of this is resolved now (and much more simpler) thanks to a lot of work in EDK2/OVMF, QEMU & libvirt. | |
| 16:27:54 | kashyap | More details in a firefox tab (with the Secure Boot spec) near you :D | |
| 16:28:03 | cfriesen | yeah, it'll be better in another release cycle. | |
| 16:28:09 | cfriesen | later | |
| 16:28:31 | mriedem | gmann: comments inline :) but it's pretty good. | |
| 16:29:05 | mriedem | gmann: i'll probably just +1 once you fix those since we're close to the ptg and i want to make sure other cores (and ops/users) are aware of what's being proposed here before we move forward | |
| 16:29:19 | gmann | mriedem: sure, i will update | |
| 16:29:25 | mriedem | i think the majority of the team needs to approve or at least be aware and not care since this is a pretty big change | |
| 16:29:48 | gmann | make sense. | |
| 16:35:38 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Drop legacy-grenade-dsvm-neutron-multinode-live-migration from Pike https://review.openstack.org/653811 | |
| 16:35:45 | mriedem | dansmith: melwitt: ^ spring cleaning | |
| 16:38:14 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 16:38:30 | gmann | mriedem: ^^ done | |
| 16:41:48 | melwitt | mriedem: curious how the job is broken if it's passing? | |
| 16:42:13 | mriedem | it's not | |
| 16:42:15 | mriedem | non-voting | |
| 16:42:31 | mriedem | see https://review.openstack.org/#/c/640207/ | |
| 16:42:58 | mriedem | if you really want to go mad, you can read my ramblings in https://review.openstack.org/#/c/640197/ trying to fix the job in queens | |
| 16:43:13 | melwitt | oh, ok. I was confused by "removes the (broken) non-voting job" | |
| 16:44:02 | mriedem | tl;dr one of the nodes is using nova-cpu.conf and one is using nova.conf and as a result, only one of them has the rbd creds which means the ceph stuff all fails during live migration | |
| 16:44:22 | mriedem | i guess one way for me to deal with the busted job on queens is to just nix the rbd testing so we still have just block migration live migration | |
| 16:44:34 | melwitt | ah ok | |
| 16:57:30 | aspiers | sean-k-mooney: latest patch set of SEV spec is fully converted to the resource class approach https://review.openstack.org/#/c/641994/9 | |
| 16:57:49 | aspiers | cdent / jaypipes might be interested too | |
| 17:01:31 | cdent | thanks aspiers, putting it on the list | |
| 17:01:39 | aspiers | cheers | |
| 17:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640198 | |
| 17:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640197 | |
| 17:04:05 | sean-k-mooney | aspiers: loook like there is a pep8 issue jsut an fyi | |
| 17:04:10 | aspiers | darn | |
| 17:05:05 | aspiers | weird, can't see that locally | |
| 17:05:22 | aspiers | oh, wrong environment | |
| 17:05:37 | aspiers | I wonder why tox -e flake8 is allowed | |
| 17:07:18 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | |
| 17:07:22 | aspiers | sean-k-mooney: fixed | |
| 17:32:30 | cdent | aspiers: that's the just the unfortunate way tox works... | |
| 17:32:38 | openstackgerrit | Merged openstack/nova master: libvirt: set device address tag only if setting disk unit https://review.openstack.org/611974 | |
| 17:59:26 | efried | aspiers: Re-reviewed SEV spec | |
| 17:59:57 | aspiers | efried: thanks | |
| 17:59:58 | efried | cdent: I tried to explain there ^ why we don't ever remove things from os-traits, even if they're trash. | |
| 18:00:14 | efried | perhaps you can reinforce/augment | |
| 18:00:25 | cdent | efried: looking | |
| 18:05:12 | aspiers | efried, cdent: To "The pathological theoretical case is where somebody (not limited to nova) is on 0.11.0 or 0.12.0, sees the trait and uses it for $whatever", my question is: what could $whatever possibly be? Literally there is zero code which uses it. | |
| 18:06:05 | efried | I'm basically saying it doesn't matter | |
| 18:06:06 | aspiers | And even if they somehow concocted some way to use it, that couldn't possibly relate to SEV in any way, because again there is zero SEV code merged which uses it anywhere. | |
| 18:06:32 | cdent | aspiers, efried : the additional aspect is that whenever a placement service sees a new version of os-traits it syncs up its database with the strings that are in the package, creating a row in the traits table, with an id that becomes a foreign key in other tables | |
| 18:06:40 | cdent | s/becomes/can become/ | |
| 18:06:44 | aspiers | Ahah | |
| 18:06:52 | aspiers | Now that sounds like it could be a good reason | |
| 18:06:55 | cdent | nothing is present is in placement to do a reverse sync | |
| 18:07:02 | aspiers | Gotcha | |
| 18:07:25 | aspiers | In any case, it's trivial to ditch the removal from the spec, and I'm happy to do that | |
| 18:07:40 | cdent | that wasn't the reason why we can't remove, but once we decided we -weren't- going to remove, then it became safe for the sync mechanism to be that | |
| 18:07:40 | aspiers | I just wanted to understand the rationale out of curiosity ;-) | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 18:07:53 | aspiers | Yep that makes sense | |
| 18:07:53 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 18:08:18 | cdent | but the general ideas was simply: an extensible only enumeration is easier to manage than one than can be shrunk | |
| 18:08:32 | aspiers | Sure | |
| 18:08:39 | aspiers | OK, so it stays | |
| 18:08:49 | aspiers | In that case I'll just need to amend the docs to say not to use it for anything | |
| 18:08:58 | cdent | yeah, that's probably a good idea | |
| 18:09:02 | efried | Yeah, I kept trying to phrase that in terms of this specific trait, where it doesn't necessarily apply. That wasn't the most convincing approach. | |
| 18:09:15 | efried | thanks for the save cdent | |
| 18:09:18 | efried | :* | |
| 18:09:29 | cdent | :hugs: | |
| 18:09:53 | cdent | It does suggest that we probably need some kind of "are you really really sure" mechanism when we start adding traits | |
| 18:10:06 | cdent | when these went by I don't remember them seeming bad or suspect in any way | |
| 18:10:06 | sean-k-mooney | i am trying to think is there still a usecase for the trait but with the resouce class approch not really | |
| 18:10:20 | cdent | so it _might_ be that they are still okay in general, just not for this use | |
| 18:10:25 | sean-k-mooney | the only one i have is a forbiden trait | |
| 18:10:27 | aspiers | efried: Your idea of combining the resources: extra spec with an AMD trait is a nice idea. We're into bikeshedding territory now which is probably not ideal when formulating specs, but it is *conceivable* (if not likely) that in the future AMD might release another memory encryption technology - I dunno, maybe SEV2 or something | |
| 18:10:39 | sean-k-mooney | e.g. i have only a few host that support SEV so please avoaid them | |
| 18:10:48 | aspiers | In that case, not having an SEV-specific resource class would be problematic | |
| 18:11:28 | aspiers | sean-k-mooney: that's an interesting idea. Maybe could be done with anti-affinity scheduler somehow? | |
| 18:11:35 | efried | aspiers: Well now, this could be an argument for use of the trait :) | |
| 18:11:39 | efried | in the future | |
| 18:12:01 | aspiers | ... based on the premise that you can do anti-affinity for traits but not resources? | |
| 18:12:07 | sean-k-mooney | aspiers: well if we report both the inventory of the sev resouce class + add the sev trait to the RP | |
| 18:12:32 | sean-k-mooney | then operators can do it by just adding a forbidon trait to there non sev flavor | |
| 18:12:33 | cdent | Having provided a tiny bit of useful information, I think I'm going to bow out. Since those of you who will be in denver, in denver. | |
| 18:12:42 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640207 | |
| 18:12:45 | cdent | s/Since/See/ | |
| 18:12:46 | aspiers | sean-k-mooney: I'm fine with that (the trait provision code is already written) | |
| 18:12:49 | cdent | sigh | |
| 18:12:50 | aspiers | cdent: looking forward to it! | |
| 18:12:58 | sean-k-mooney | cdent: o/ | |
| 18:12:59 | efried | I care that my memory encryption is done specifically with SEV2: resources:MEM_ENCRYPT_CONTEXT=1,trait:HW_CPU_AMD_SEV2=required | |
| 18:13:23 | aspiers | efried: right, so we're back to traits then ;-) | |
| 18:13:44 | aspiers | Playing devil's advocate, are there any downsides to sort of duplicating info between a resource class and a trait? | |
| 18:13:45 | sean-k-mooney | please dont call it MEM_ENCRYPT_CONTEXT | |
| 18:13:51 | efried | For now, since there's only one way to do it, we don't need to use the trait | |