Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-31
16:24:53 bauzas like the unified limits
16:24:58 gmann indeed
16:25:16 bauzas remember tho, operators play old versions, so they couldn't be that helpful
16:25:23 bauzas but this is not a reason to ask
16:25:33 bauzas to not* ask
16:25:39 gmann yeah, just if we can get initial feedback what they think on these new things
16:25:45 bauzas gotcha
16:25:50 bauzas and brilliant idea
16:26:01 bauzas gmann: you're doing my homework !
16:26:12 gmann :)
16:26:35 bauzas ok, next topic, I guess ?
16:27:09 bauzas looks so
16:27:20 bauzas #topic Review priorities
16:27:25 bauzas #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1
16:27:42 bauzas #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there.
16:28:14 bauzas #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have
16:28:48 bauzas looks we found a consensus on my proposal for https://review.opendev.org/c/openstack/project-config/+/837595
16:29:04 bauzas sean-k-mooney: could you then please provide a new rev for it ? ^
16:30:38 sean-k-mooney ah i tought you were going to update it but sure
16:31:33 bauzas sean-k-mooney: oh, I can do it
16:32:17 bauzas #action bauzas to update https://review.opendev.org/c/openstack/project-config/+/837595
16:33:10 bauzas sean-k-mooney: no worries, I'll take it
16:33:36 bauzas next topic then
16:33:38 bauzas #topic Stable Branches
16:33:55 bauzas elodilles: feel free to take the mic
16:34:00 elodilles #info ussuri is unblocked, thanks to gmann's tempest pinning patches
16:34:17 bauzas \o/
16:34:21 gmann yeah, and stable/victoria is also pinned with old tempest
16:34:27 elodilles #info stable branches are now unblocked, but intermittent failures need further investigations. melwitt's tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:34:32 elodilles gmann: thanks! \o/
16:34:33 gmann took almsot 1 week to get all these merged
16:34:42 elodilles :S
16:34:57 elodilles #info placement's stable/branches are unblocked back till victoria (see melwitt's etherpad ^^^)
16:35:12 bauzas \o/ agai,
16:35:17 gmann cyborg-tempest plugin job which is non voting in nova gate also will be fixed by #link https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/843329
16:36:27 elodilles gmann: ack, thanks for that, too!
16:36:41 elodilles (that's all from my side)
16:36:42 bauzas :)
16:36:51 bauzas greatly appreciated, thanks gmann
16:37:03 gmann np!
16:37:18 bauzas and thanks melwitt for the tracking
16:37:24 bauzas moving on
16:37:29 bauzas we have one last item
16:37:48 bauzas #topic Open discussion
16:38:00 bauzas (levy14) Discuss ability to call Barbican from inside VM without supplying credentials
16:38:03 bauzas levy14: around ?
16:38:06 levy14 yep
16:38:25 levy14 was not around last week to put it on the agenda
16:38:34 bauzas levy14: I'll be honest, I'm not sure we have quorum for discussing your point today, but we can try
16:39:36 levy14 but my org would greatly benefit if any code in a vm could call barbican to fetch secrets. now there are secrets in code, in config files, injected but not properly handled. I'd like to get rid of that.
16:39:59 levy14 without having to put the credentials in the code, I mean
16:40:31 levy14 I see this as a big security improvement for users of nova
16:40:50 sean-k-mooney i actuly see it as the opisite form a nova point of view
16:40:57 sean-k-mooney is potentally a large security whole
16:41:22 sean-k-mooney nova today almost excilulive does not handel any tenatn secrets
16:41:45 bauzas yup, that's what we said
16:41:48 sean-k-mooney nova or admins by default cannot retirve secrets form barbican
16:42:00 sean-k-mooney only the user can
16:42:05 levy14 I understand. but that forces users of nova to improvise. and it's not good what users do. the outcome is nasty.
16:42:32 sean-k-mooney yep thats also true
16:42:46 levy14 if there would be a feature to allow this specific use case, that would make life of nova users much better
16:42:48 sean-k-mooney realisticaly the simpelte way to achive this today id via an external vender data service
16:43:06 sean-k-mooney which could inject a bootstrap token via the metadta api
16:43:25 sean-k-mooney simialr to how nova-join works https://opendev.org/x/novajoin#design
16:43:35 levy14 the problem with that is that I cannot realitically get it implemented across the federation of sites we represent
16:43:38 sean-k-mooney https://docs.openstack.org/nova/latest/admin/vendordata.html
16:44:31 sean-k-mooney levy14: what you are trying to achive is somethign simialr to k8s ablity to inject secrets into the pods right
16:45:16 sean-k-mooney kubernets allows secreates to be injected via config maps or other mechanium such that the pod applciation can the interact with the k8s apis
16:45:40 sean-k-mooney levy14: what you want is a way for nova instance to be able to bootstrap talkign to keystone/barbican
16:45:53 sean-k-mooney so that they can programitacly get teh secretes that are stored there
16:45:57 levy14 not necessarily. I would like a transparent mechanism. that watches for outgoing https reguests to barbican and adds a header with the auth to access the secrets. based on some form of vm identity
16:46:14 sean-k-mooney levy14: nova does not controll the guest networking
16:46:25 sean-k-mooney so such a serice woudl be outside our scope
16:46:48 levy14 sean-k-mooney: they can do that today, if they inject a secret. but that needs them to properly tend and handle the secret with care. users don't care, they are sloppy.
16:47:13 sean-k-mooney one posiablity but its a hack
16:47:28 sean-k-mooney woudl be to take teh token we are invoked with and include it in the metadata
16:47:35 sean-k-mooney that token would expire
16:48:01 sean-k-mooney but it woudl be suffient for the app to bootsrap potenally by issueing an application credetial
16:48:25 levy14 sean-k-mooney: it was just a suggestion. or a way to describe what I expect to happen, don't know which project implements it. I thought I bring it up in nova, as it seems some sort of vm identity is needed for it to work
16:48:46 sean-k-mooney if you want the http request to be intercepted transparently you would need service function chaning or similar to implement that
16:49:08 sean-k-mooney levy14: that the thing vms dont have an identiy
16:49:14 sean-k-mooney they are owned by porjects
16:49:24 sean-k-mooney secrets are owned by users
16:49:28 levy14 sean-k-mooney: maybe they should start having one
16:49:46 sean-k-mooney perhaps
16:49:56 levy14 or secrets in barbican can be set up so that an entire project has access to them?
16:50:14 sean-k-mooney im not sure but that would still not allow nova to access them
16:50:33 sean-k-mooney services and cloud admins cannot acces barbican secrets
16:50:44 levy14 so the possibilities are:
16:50:48 sean-k-mooney that is doen intentiolly for improved security
16:51:01 levy14 1. metadata service
16:51:19 levy14 2. interception of network calls outgoing from a vm
16:52:30 sean-k-mooney those are two possiblities yes
16:52:42 levy14 any other?
16:52:49 sean-k-mooney for 1 you would have to define what the metadata service will provide the vm
16:53:03 levy14 and anyone sees this as a valuable feature for nova?
16:53:05 sean-k-mooney 2 is not in scope of nova
16:53:36 sean-k-mooney levy14: if it was done securly maybe.
16:53:52 sean-k-mooney but i also see it as a non trivial feature
16:54:11 jrosser_ i did some more looking at this after it was discussed ~ 1 week ago

Earlier   Later