| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 16:04:25 | mriedem | efried: https://etherpad.openstack.org/p/nova-stable-pike-em is up to date | |
| 16:05:11 | efried | thanks mriedem | |
| 16:05:50 | mriedem | tl;dr novaclient is ready for final release, no open changes, | |
| 16:05:57 | mriedem | os-vif has no open changes nor any changes since the last release, so it's ready for em | |
| 16:06:06 | mriedem | nova has 6 pending | |
| 16:09:36 | efried | tonyb[m]: ^ FYI | |
| 16:09:46 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653514 | |
| 16:10:25 | lyarwood | efried / mdbooth ; sorry was stuck on a call, I'd say 30mins to be conservative | |
| 16:10:57 | efried | lyarwood: Cool, we've set it up for 1115-1150 | |
| 16:11:28 | efried | if really needed we can come back after team picture and go til lunch | |
| 16:13:51 | lyarwood | efried: ack thanks | |
| 16:16:44 | cfriesen | kashyap: what happens if you have running instances using /usr/share/OVMF/OVMF_CODE.fd, then you shut down the node, upgrade the OVMF RPM, and boot the node. Are the instances all toast? | |
| 16:17:54 | kashyap | cfriesen: Have not tested it; but I'd expect some error. I don't think instance will be "toast". Because it's "only" the firmware. | |
| 16:18:15 | cfriesen | but we wouldn't be able to boot it, as the xml would be specifying the "wrong" file | |
| 16:18:18 | kashyap | cfriesen: Can you try on one instance, by doing the fugly workaround of: | |
| 16:18:22 | kashyap | ln -sf /usr/share/OVMF/OVMF_CODE.secboot.fd /usr/share/OVMF/OVMF_CODE.fd | |
| 16:18:37 | kashyap | Does it boot, if you do the above? | |
| 16:18:55 | cfriesen | I don't have a suitable setup at the moment. | |
| 16:20:06 | kashyap | cfriesen: But yes -- obviously, instance won't boot if the file is missing | |
| 16:20:34 | cfriesen | I'm wondering why RHEL/Centos didn't include both OVMF_CODE.fd and OVMF_CODE.secboot.fd in the RPM | |
| 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 | |