| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 15:23:09 | mriedem | alex_xu is probably the authority on that code | |
| 15:23:26 | alex_xu | o/ | |
| 15:23:40 | sean-k-mooney | kashyap: is this realted to secure boot | |
| 15:23:49 | kashyap | sean-k-mooney: No-no, completely unrelated | |
| 15:24:01 | sean-k-mooney | ok i was going to say that is not a cpu flag | |
| 15:24:05 | sean-k-mooney | never mind | |
| 15:24:09 | kashyap | sean-k-mooney: I'm adding PCID, SSBD, etc. | |
| 15:24:16 | kashyap | Of course, it's not. Huh :-) | |
| 15:24:16 | sean-k-mooney | ah ok | |
| 15:25:06 | 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:19 | kashyap | alex_xu: Yes, exactly. Thought so | |
| 15:25:30 | alex_xu | I guess you also need to raise the required version of os-traits | |
| 15:25:52 | 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:26:02 | kashyap | (Yes?) | |
| 15:26:06 | alex_xu | yes | |
| 15:26:52 | kashyap | alex_xu: Where do I raise the 'os-traits' version? | |
| 15:27:25 | alex_xu | requirement | |
| 15:28:22 | alex_xu | kashyap: requirement.txt | |
| 15:28:38 | openstackgerrit | Christian Berendt proposed openstack/nova stable/queens: Fix regression in glance client call https://review.opendev.org/655186 | |
| 15:30:03 | kashyap | alex_xu: Thanks! | |
| 15:30:16 | aspiers | efried: after much deliberating I've finally figured out how to articulate my thoughts https://review.opendev.org/#/c/641994/11 | |
| 15:31:00 | kashyap | alex_xu: I see currently 0.9.0 traits is released. And in Nova, we have: os-traits>=0.8.0 | |
| 15:31:04 | kashyap | alex_xu: I am going to make that to: | |
| 15:31:11 | kashyap | - os-traits>=0.8.0 | |
| 15:31:15 | kashyap | + os-traits>=0.10.0 | |
| 15:31:44 | alex_xu | yea, to the version has PCID trait | |
| 15:31:48 | 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:33:10 | kashyap | aspiers: Noted. Thanks for the pointer | |
| 15:33:42 | kashyap | aspiers: BTW, I must say, this is one of the most well-written specs I've evern seen. Nice work. | |
| 15:33:50 | aspiers | kashyap: thanks! :) | |
| 15:35:00 | aspiers | I received a lot of great advice on it over 2 cycles, which has helped hugely | |
| 15:35:55 | kashyap | Yeah, it shows the careful, unhurried effort to think-through the problem and incorporating the feedback. | |
| 15:37:06 | 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:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955 | |
| 15:40:35 | kashyap | alex_xu: By the way, the CPU_TRAITS_MAPPING takes both AMD _and_ Intel flags, yes? | |
| 15:41:28 | alex_xu | yes | |
| 15:42:04 | kashyap | aspiers: Hehe, noted. (Sustained concentration is a "feature" in this distracted world with 280-char attention spans.) | |
| 15:42:11 | kashyap | alex_xu: Thx. | |
| 15:42:14 | aspiers | Indeed | |
| 15:43:32 | artom | Although realistically, that'll probably mean drugs, so maybe not? | |
| 15:43:51 | kashyap | What a charitable interpretation. | |
| 15:43:52 | aspiers | LOL | |
| 15:44:22 | artom | Is it? Charitable, I mean? | |
| 15:44:24 | aspiers | It's not a coincidence that I'm currently doing a meditation course on productivity ;-) | |
| 15:44:37 | 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:58 | kashyap | alex_xu: I think we're OK with its growth over the years... | |
| 15:45:10 | kashyap | aspiers: Nice. | |
| 15:45:43 | alex_xu | kashyap: yes, welcome any better idea | |
| 15:46:18 | kashyap | alex_xu: Nothing currently :-) Will keep thinking about this problem, will let you know if I come up with anything better | |
| 15:46:31 | alex_xu | kashyap: cool, thanks | |
| 15:50:56 | mriedem | adrianc: some comments in https://review.opendev.org/#/c/649345/ | |
| 15:51:58 | mriedem | adrianc: if you agree, i'm willing to make that change and then still +2 | |
| 15:52:03 | mriedem | it's just docs and variable naming | |
| 15:58:52 | 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? | |
| 16:00:21 | mriedem | not that i know of, i know gibi posted a patch, | |
| 16:00:30 | mriedem | and my eyes glazed over at the discussion within my multiattach capability trait patch | |
| 16:00:51 | 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:58 | mriedem | i.e. hitching a ride to scheduler town | |
| 16:01:09 | mriedem | cash, grass, or ... | |
| 16:01:17 | mriedem | no traits ride for free | |
| 16:02:44 | efried | making sure the change isn't persisted? | |
| 16:03:00 | mriedem | RequestSpec.flavor gets persisted | |
| 16:03:17 | efried | so you're adding it to the flavor extra spec until the GET /a_c and then removing it? | |
| 16:03:18 | mriedem | i want to make sure that twiddling RequestSpec.flavor.extra_specs for a one-time scheduler run doesn't get persisted | |
| 16:03:35 | mriedem | nothing is explicitly removing it, | |
| 16:03:45 | mriedem | you reset changes on the object so that when it's saved those changes aren't persisted | |
| 16:03:45 | efried | ...you just aren't saving it | |
| 16:03:49 | efried | okay | |
| 16:05:14 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755 | |
| 16:08:49 | 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:10:44 | mriedem | volume live migration and retypes | |
| 16:11:22 | 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:41 | mriedem | https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_swap_volume | |
| 16:13:17 | jaypipes | mriedem: what's the use case though? | |
| 16:13:41 | aspiers | jaypipes wins the Review Of The Week award for a perfect use of a Big Lebowski quote | |
| 16:13:48 | jaypipes | aspiers: yw | |
| 16:14:02 | mriedem | jaypipes: this feels like a trap | |
| 16:14:09 | mriedem | what's the use case for live migration? | |
| 16:14:17 | jaypipes | mriedem: no, I'm honestly curious. | |
| 16:14:30 | jaypipes | mriedem: is volume live migration different from live migration? | |
| 16:14:40 | mriedem | yes | |
| 16:14:45 | mriedem | it's initiated through cinder | |
| 16:14:50 | mriedem | smcginnis: maybe you want to elaborate here ^ | |
| 16:15:15 | jaypipes | mriedem: so this is not an operation a user would ever issue, right? | |
| 16:15:19 | mriedem | https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-migration.html | |
| 16:15:30 | jaypipes | (like instance live migration is not an operation any normal user even knows about) | |
| 16:15:42 | mriedem | for volume migration i think that is correct, it's admin-only by default, | |
| 16:15:48 | mriedem | but retype is admin or owner of the volume aka the user | |
| 16:15:59 | mriedem | https://developer.openstack.org/api-ref/block-storage/v3/?expanded=migrate-a-volume-detail,retype-a-volume-detail#retype-a-volume | |
| 16: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:27 | mriedem | i think of volume retype like server resize | |
| 16:16:52 | mriedem | by default retyping should not migrate the volume, but the user can override that | |
| 16:17:08 | 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:22 | mriedem | ^ is because the nova swap volume api is admin-only by default | |
| 16:17:25 | mriedem | it's f'ing great | |
| 16:17:31 | jaypipes | hrmph | |
| 16:18:03 | 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:14 | 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:24 | mriedem | not sure if cinder has added anything to escalate that token to admin/service user in the last 3 years | |
| 16:19:19 | 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 | |