16:00:35 <bauzas> #startmeeting nova
16:00:35 <opendevmeet> Meeting started Tue May 31 16:00:35 2022 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <opendevmeet> The meeting name has been set to 'nova'
16:00:40 <bauzas> EHLO
16:00:53 <elodilles> o/
16:00:56 <Uggla> qo/
16:01:03 <gmann> o/
16:01:45 <bauzas> not sure if gibi is around, but let's start to discuss (he told me he couldn't be in our meeting)
16:02:59 <bauzas> #topic Bugs (stuck/critical)
16:03:04 <bauzas> #info No Critical bug
16:03:09 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 14 new untriaged bugs (-1 since the last meeting)
16:03:12 <bauzas> thanks elodilles :)
16:03:18 <bauzas> #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (0 since the last meeting) in Storyboard for Placement
16:03:18 <elodilles> o:)
16:03:26 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:36 <bauzas> elodilles: do you want to discuss about some bug ?
16:03:50 <elodilles> bauzas: nothing to discuss i think,
16:03:54 <bauzas> cool
16:04:11 <bauzas> thanks for the bug triage etherpad btw.
16:04:19 <elodilles> i only triaged two bugs and they were more or less clear (or incomplete)
16:04:30 <bauzas> nice
16:04:44 <bauzas> so, after you, we're done with the roster
16:04:58 <bauzas> if someone wants to triage, let me know now
16:05:04 <bauzas> for next week
16:05:57 <bauzas> ok, looks not
16:06:17 <bauzas> then, let's rerun the roster :)
16:06:23 <elodilles> ++
16:06:31 <bauzas> I'll be the next bug baton folk
16:06:50 <bauzas> I can run it for two weeks if needed as I'll ask to not have a meeting next week
16:07:13 <elodilles> i guess gibi is not here to object :)
16:08:14 <bauzas> heh, I'll see him f2f next week
16:08:20 <bauzas> so I could pass him the baton :p
16:08:32 <elodilles> :)
16:08:39 <bauzas> anyway
16:08:46 <bauzas> #info Next bug baton is passed to bauzas
16:08:59 * bauzas has to run then
16:09:13 <bauzas> meh, joking
16:09:20 <bauzas> next topic, then
16:09:24 <bauzas> #topic Gate status
16:09:28 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:09:35 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status
16:09:38 <bauzas> #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs
16:09:43 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:09:47 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:10:02 <bauzas> all the jobs look good to me
16:10:51 <bauzas> something to tell about the gate ?
16:11:57 <bauzas> ok, looks not, continuing
16:12:06 <bauzas> #topic Release Planning
16:12:11 <bauzas> #link https://releases.openstack.org/zed/schedule.html
16:12:16 <bauzas> #info Zed-2 is in 6 weeks
16:12:20 <bauzas> the tick is clicking
16:12:36 <bauzas> I'll ask for a spec review day maybe in two weeks's meeting
16:13:31 <bauzas> nothing to tell here, I'm slowing reviewing a few specs
16:14:05 <bauzas> and oh, this reminds me to modify Launchpad for those accepted blueprints
16:14:18 * bauzas forgot to do it last week
16:14:45 <bauzas> anything to talk about specs, per say ?
16:15:57 <bauzas> -
16:16:04 <bauzas> #topic OpenInfra Summit
16:16:13 <bauzas> #info bauzas, gibi and stephenfin will attend the summit (at least for those I know)
16:16:36 <bauzas> so, then I have a question for those around
16:16:47 <bauzas> shall we cancel next week's meeting ?
16:16:50 <bauzas> I have a vote !
16:16:57 <bauzas> #startvote Cancel Nova meeting next week ? (yes/no)
16:16:57 <opendevmeet> Begin voting on: Cancel Nova meeting next week ? Valid vote options are , yes, no, .
16:16:57 <opendevmeet> Vote using '#vote OPTION'. Only your last vote counts.
16:17:09 <bauzas> #vote yes
16:17:12 <elodilles> #vote yes
16:17:12 <gmann> though I will travel but ok for me to cancel,
16:17:16 <gmann> #vote yes
16:17:20 <Uggla> #vote yes
16:17:23 <gmann> *I will not travel
16:17:32 <bauzas> gmann: you'll be missed
16:17:54 <bauzas> I'll close the vote
16:17:58 <bauzas> but, before this
16:18:09 <bauzas> if someone wants run the meeting, he can
16:18:25 <bauzas> this is just I'm not sure we'll have a quorum then
16:18:47 <bauzas> let's end the vote
16:18:48 <bauzas> #endvote
16:18:48 <opendevmeet> Voted on "Cancel Nova meeting next week ?" Results are
16:18:48 <opendevmeet> yes (4): Uggla, gmann, elodilles, bauzas
16:19:14 <bauzas> so,
16:19:25 <bauzas> I haven't seen interest by someone to run it,
16:19:47 <bauzas> #agreed June 7th nova meeting is CANCELLED.
16:19:59 <bauzas> I'll send an email accordingly
16:20:23 <bauzas> one last point, if some people read our minutes,
16:20:26 <bauzas> #info We'll provide a Nova meet-and-greet Operators feedback  session on Wednesday,  June 8, 2:50pm - 3:20pm. Operators are welcome.
16:20:45 <bauzas> I can proxy any opinions or thoughts at the forum, btw.
16:20:54 <bauzas> stick around on IRC, you could be pinged
16:21:53 <gmann> bauzas: good idea. is there any etherpad i can add topic?
16:22:05 <bauzas> gmann: I surely can create one
16:22:06 <gmann> I would like to get soem feedback on SRBAC especially on scope thing
16:22:29 <gmann> thanks, that will be great I will not be there but I think you can discuss it and I will add details in etherpad
16:22:32 <bauzas> gmann: so you imagine some feedback etherpad, or rather some etherpad for adding notes before and remarks after ?
16:22:40 <bauzas> ah, I see
16:22:47 <gmann> bauzas: latter one
16:22:59 <bauzas> gmann: this is an excellent idea, let's setup this
16:23:05 <gmann> +1
16:23:28 <bauzas> gmann: I wish the Forum sessions would have their own etherpads tho
16:23:29 <gmann> we are trying to get this topic for ope meetup also but getting per project feedback also will be great
16:23:53 <gmann> bauzas: yeah, that also work, anywhere I can add this topic so that you remember it
16:24:05 <bauzas> gmann: oh, you meant about operators feedback at our meet-and-greet ? gotcha.
16:24:11 <gmann> yeah
16:24:26 <bauzas> gmann: then, I'll start an etherpad and I'll discuss this with gibi as he co-hosts
16:24:34 <gmann> thanks
16:24:47 <bauzas> this is a good point, we have a few things we'd like operators to play witgh
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
16:54:22 <levy14> sean-k-mooney: I am sure is non-trivial
16:54:53 <jrosser_> and came to the same conclusion that there was no user associated with a VM so it was not possible to generate a usable token, even though it was possible to assert the identity of the vm
16:55:00 <levy14> sean-k-mooney: but I see it very valuable to have
16:55:27 <bauzas> timebox : we only have 5 mins left
16:55:55 <sean-k-mooney> levy14: do you feel comfortable wrting a spec propsoal even an incomplete one with your usecases
16:56:09 <sean-k-mooney> levy14: and or would you be able to implement this with our guidance
16:56:11 <bauzas> yes, we should rather discuss this by a spec
16:56:31 <levy14> sean-k-mooney: I can try writing an (incomplete) spec, I am not up to implement it myself
16:56:41 <sean-k-mooney> jrosser_: i could see us adding a --application-credetial or something to the api
16:57:00 <sean-k-mooney> jrosser_: i.e. you precreate one and tell nova to pass it to the guest via the metadtaa service
16:57:03 <jrosser_> i think that spcifying a service user for a VM might be enough
16:57:40 <jrosser_> anyway this is a rabbit hole and i don't want to disrupt your meeting
16:57:58 <bauzas> jrosser_: no worries, we don't have other discussions
16:58:47 <bauzas> at least, looks to me we have a consensus : levy14 will provide an incomplet spec or a backlog one
16:58:54 <bauzas> levy14: do you know about https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html ?
16:59:09 <jrosser_> tldr was that other $clouds let you associate a service user (thats already in your project) with that VM, and that combined with a JWT from the metadata  to auth against keystone would give you a token for that service user
16:59:36 <bauzas> anyway, we're at the last minute for our meeting
16:59:48 <levy14> I saw the page, seemed convoluted. next week I'm at openinfra, but for the week after that I'll try to create a spec.
16:59:50 <sean-k-mooney> jrosser_: i think the closest thing to a service user we have in openstack in an application credential
17:00:46 <bauzas> levy14: ok, then, we're done today
17:00:54 <bauzas> thanks folks
17:00:56 <bauzas> #endmeeting