Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-10
15:48:33 lyarwood yup
15:49:03 rosmaita i can look into blocking this at the API layer, hopefully that's not too complicated
15:49:20 lyarwood rosmaita: let me know if you need help and I can also take a look at that
15:49:29 rosmaita lyarwood: thanks, will do
15:49:59 lyarwood rosmaita: btw, do you think cinder could ever move to a shared encryption_key image property with glance and nova?
15:50:14 lyarwood rosmaita: it would make all of this so much easier to handle
15:50:36 rosmaita lyarwood: well ... there's another encryption key effort going on
15:50:44 rosmaita it envisions shared keys
15:50:54 lyarwood rosmaita: oh jeez
15:50:57 rosmaita meaning one key, multiple resources
15:51:13 lyarwood rosmaita: link?
15:51:16 rosmaita this cinder workflow is meant to keep 1-1 key-resource relation to make deletion possible
15:51:40 lyarwood rosmaita: 1:1 between the volume and image?
15:51:56 efried rosmaita: "config change"? what config change?
15:52:21 rosmaita efried: blacklisting the cinder_* properties in the non_inheritable_image_properties list
15:52:50 efried rosmaita: Is there not a way to simply do that blacklisting without involving the conf opt?
15:52:51 rosmaita lyarwood: each volume and each image have their own corresponding barbican secret
15:53:26 rosmaita efried: don't know, that's what the conf opt has been used for in the past
15:53:26 efried rosmaita: I think that's what I was suggesting earlier. IOW wherever this conf opt is processed in the nova code, just *always* add those keys no matter what. And don't change the conf opt default.
15:53:52 rosmaita it prevents the img_* properties from being inherited (those are the ones used for signature validation_)
15:54:58 spatel sean-k-mooney: morning, This is cool, soon going to run erlang load-test and will let you know - http://paste.openstack.org/show/789378/
15:55:06 rosmaita lyarwood: https://etherpad.openstack.org/p/image-encryption-weekly-meeting -- it's not up to date, but i think it has links to all the specs about the other encryption effort
15:55:37 lyarwood rosmaita: oh that, I think that's died now anyway
15:55:53 rosmaita lyarwood: no, it is very much alive, the etherpad is just dead
15:56:04 lyarwood rosmaita: well the nova-spec died at least
15:56:40 rosmaita lyarwood: interesting
15:56:53 lyarwood rosmaita: I wanted to propose a LUKS based alternative in V FWIW
15:57:21 rosmaita lyarwood: eharney is very much of the same mind, i think
15:59:02 lyarwood rosmaita: wonderful, it would need some qemu-img convert magic to rotate keys while keeping things encrypted etc but shouldn't be too hard to sort out in nova and cinder.
15:59:40 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Never convey cinder_encryption_key_* in snapshots https://review.opendev.org/706888
15:59:41 efried lyarwood: rosmaita: So what I'm talking about is, don't muck with the conf opt defaults (or do, actually, it wouldn't matter), instead do like this: ^
15:59:59 efried ...as well as the API blocker.
16:01:34 rosmaita efried: i don't object to that, though you may want to keep a list instead
16:01:50 efried "keep a list" of what?
16:01:57 rosmaita because the img_ properties should probably also be popped
16:02:17 rosmaita efried: keep a list of really_seriously_non_inheritable_image_properties
16:02:21 rosmaita (not configurable)
16:02:22 efried oh, yeah, sure, whatevs, the idea being that there are certain keys we *never* inherit, regardless of the conf opt
16:02:35 efried I leave the details to the experts :P
16:03:15 lyarwood ack yeah LGTM if we also block attempts to create instances from images with these props in the same change.
16:03:26 efried cool.
16:05:19 rosmaita efried: lyarwood: ok, i will include the really_seriously_non_inheritable_image_properties in the same patch as the API change
16:06:30 efried rosmaita: cool, left summary text on the patch with pointers to this conversation. I'll abandon my DNM.
16:06:42 rosmaita efried: ty
16:09:10 efried bauzas: I went ahead and abandoned the MKTME spec https://review.opendev.org/#/c/666769/
16:09:11 efried AFAIU that effort is dead anyway. If Intel decides to do anything with mem-encrypted images, it would probably be around SGX anyway.
16:09:39 bauzas cool with me
16:10:02 bauzas FWIW, I'm giving a round of spec reviews today before tomorrow's spec review day
16:10:14 bauzas efried: or others, ping me any spec you'd like me to review
16:29:30 openstackgerrit Lee Yarwood proposed openstack/nova master: images: Use JSON as the output format of qemu-img https://review.opendev.org/706898
16:29:30 openstackgerrit Lee Yarwood proposed openstack/nova master: images: Move qemu-img info calls into privsep https://review.opendev.org/706897
16:29:31 openstackgerrit Lee Yarwood proposed openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899
16:29:32 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Fix attached encrypted volume extension https://review.opendev.org/706900
17:02:11 gibi bauzas: left some feedback on the NUMA spec https://review.opendev.org/#/c/552924/
17:03:25 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812
17:03:25 openstackgerrit Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811
17:03:26 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.82 allowing boot from volume rescue https://review.opendev.org/701430
17:03:26 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429
17:03:27 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Support boot from volume instance rescue https://review.opendev.org/701431
17:03:27 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212
17:04:36 bauzas gibi: ok, it's 6pm here and you provide good thoughts
17:04:50 bauzas gibi: let's discuss on it if you agree by tomorrow 10am (-ish)
17:04:52 gibi bauzas: yeah, it is something to sleep on :)
17:05:45 gibi I will be available around 10ish tomorrow
17:06:22 bauzas cool
17:06:29 bauzas I have to leave btw.
17:06:30 bauzas \o
17:06:42 gibi o/
17:38:21 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643
19:10:50 umbSublime sean-k-mooney, efried I got some bad news :/ I was told (not without a fight) to stop all efforts related to inv TSC blueprint... (At least during business hours)
19:26:15 efried umbSublime: Okay. What do you want to do paperwork-wise?
19:26:22 efried Abandon or defer?
19:37:36 umbSublime I don't know :/ (this situation kind of got me a bit riled up), I guess abandon. If this is re-prioritized again on our end I'll recreate the bp/spec
19:39:10 efried umbSublime: okay. Abandon is totally undo-able, nothing is lost.
19:42:09 sean-k-mooney umbSublime: i see ok. given the time constraitns im not sure upstream people will be able to spend much time on this this cycle but next cycle we can help adress this usecasue if it is still important to you or others
19:43:17 umbSublime During all my reaserch on this topic I didn't notice any related feature request of openstack users hitting the issue I weas trying to resolve therefore. It's probably best to adandon, this might of been a very specific use case
19:43:17 sean-k-mooney i.e. i wont have spare time to drive this myself before thursday but i can help you with it next cycle if that is soemthing you want
19:44:05 sean-k-mooney well no harm done either way
19:49:18 umbSublime I'm not to sure where I stand on this right now, but i think abandon is the way to go for now
#openstack-nova - 2020-02-11
01:15:45 openstackgerrit Merged openstack/nova stable/rocky: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706716
02:06:10 openstackgerrit Huachang Wang proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656
02:21:16 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-create-backup https://review.opendev.org/707038
02:25:00 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-create-backup policies https://review.opendev.org/707039
02:36:23 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-console-output https://review.opendev.org/707040
02:41:23 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-console-output policies https://review.opendev.org/707041
03:22:19 ileixe Hi Nova,
03:22:28 ileixe Does anyone know the current status of https://blueprints.launchpad.net/nova/+spec/ip-aware-scheduling-placement?
03:23:17 ileixe I thought if nova does not aware of neutron segment, routed network does not work and the spec say it's not implemented yet.
03:23:39 ileixe Does it mean routed network not yet implemented?
05:50:25 alex_xu ileixe: I think it is implemented
05:51:27 ileixe alex_xu: Thanks for response. Do you mean nova lookup segment then?
05:51:46 alex_xu ileixe: no, the neutron side will do that, and report the resource to the placement
05:52:20 alex_xu ileixe: https://blueprints.launchpad.net/neutron/+spec/routed-networks
05:52:41 alex_xu ileixe: I never try that feature, but hope ^ that can help you
05:53:52 alex_xu ileixe: also this one https://docs.openstack.org/neutron/pike/admin/config-routed-networks.html
05:56:53 ileixe alex_xu: Hm.. maybe I understand what neutron does for routed network
05:57:11 ileixe What I do not understand is.. how nova use resource provider which neutron gave
05:57:55 alex_xu ileixe: maybe i'm wrong, i saw the note from the matt, looks like neutorn side impelemnt, but yes, nova side do nohting now
05:58:44 ileixe iirc, matt you said is the owner of the commit (https://review.opendev.org/#/c/656885/) right?
05:59:13 alex_xu ileixe: yes, he isn't working on that anymore

Earlier   Later