14:00:15 <pdeore> #startmeeting glance
14:00:15 <opendevmeet> Meeting started Thu Mar 17 14:00:15 2022 UTC and is due to finish in 60 minutes.  The chair is pdeore. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:15 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <opendevmeet> The meeting name has been set to 'glance'
14:00:15 <pdeore> #topic roll call
14:00:15 <pdeore> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:25 <dansmith> o/
14:00:40 <pdeore> o/
14:00:50 <mrjoshi_> o/
14:00:54 <abhishekk> o/
14:01:33 <pdeore> lets wait few minutes for everyone to join
14:01:46 <rosmaita> o/
14:02:15 <abhishekk> jokke_, will not be joining today (holiday in Ireland)
14:02:27 <pdeore> yeah, so shall we start?
14:02:39 <abhishekk> now we can start
14:02:51 <pdeore> ok, let's start
14:02:58 <pdeore> We have short agenda today as well, with some review reminder again
14:03:07 <pdeore> #topic Updates
14:03:15 <pdeore> Zed PTG planning etherpad is up
14:03:15 <pdeore> #link https://etherpad.opendev.org/p/zed-ptg-glance-planning#L12
14:03:36 <pdeore> Kindly add your name in the list of attendees and the topics you would like to bring up, if you haven't added yet
14:03:54 <abhishekk> We have some interested topics in this PTG
14:04:46 <abhishekk> Please go through the planning etherpad and check whether if I missed anything
14:05:23 <pdeore> yeah, I would recommend to add yourself as a driver if you are interested in driving any particular session
14:05:33 <abhishekk> ++
14:05:39 <pdeore> moving to the next topic
14:05:43 <pdeore> #topic release/periodic jobs
14:05:58 <pdeore> glance-tempest-plugin is releasing this week, unfortunately we couldn't make few rbac metadef tests in this cycle
14:06:21 <pdeore> Can we still make it in Yoga? by updating the details on  https://review.opendev.org/c/openstack/releases/+/833574
14:06:42 <abhishekk> I think we can backport those, so no need to worry
14:07:01 <pdeore> ack
14:07:07 <abhishekk> Just get those reviewed first :D
14:07:23 <rosmaita> is glance_tempest_plugin branched?
14:07:45 <pdeore> yeah, dansmith we need your attention specially for those patches :)
14:07:53 <dansmith> pdeore: link?
14:07:54 <pdeore> rosmaita, no
14:08:04 <pdeore> https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802792
14:08:04 <pdeore> https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802794/14
14:08:04 <pdeore> https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802795/12
14:08:25 <pdeore> I've removed the lock and updated the namespaces names as per your suggestion
14:08:41 <dansmith> okay yeah, sorry for letting these get away from me
14:09:28 <pdeore> so, that's all, moving to Open discussion
14:09:30 <abhishekk> nah, in that case we can wait for the release I guess
14:09:51 <abhishekk> pdeore, you can comment on the release patch, saying we need some patches to get in
14:10:39 <pdeore> abhishekk, ok I will , do I need to -1 that patch with the comment?
14:10:46 <abhishekk> yes
14:10:51 <pdeore> ok
14:11:02 <abhishekk> and once all the patches merged,you can post a new revision as well
14:11:09 <abhishekk> I will let you know how to do that
14:11:17 <pdeore> ack
14:11:57 <pdeore> moving to Open Discussion
14:12:05 <pdeore> #topic Open discussion
14:12:47 <abhishekk> Nothing from me
14:13:11 <pdeore> I just had the review reminder for the glance-tempest-plugin patches, which we already discussed :)
14:13:16 <abhishekk> Just to update, Zed spec is now open, so your pending specs can be resubmitted against Zed repository
14:13:56 <pdeore> ack
14:13:58 <abhishekk> Tomorrow is Holiday in India, so we will not be around as well
14:14:27 <abhishekk> and glad to see dansmith back in the meetings :D
14:14:46 <dansmith> half our government voted to make it permanent in 2023 last week,
14:14:52 <dansmith> so hopefully this madness will stop eventually :)
14:15:12 <abhishekk> ::D, it should
14:16:15 <dansmith> so we're done?
14:16:20 <abhishekk> alistarle, we are about to wrap up
14:16:41 <alistarle> Oh sorry, I came a little late :/
14:16:48 <abhishekk> no worries
14:17:03 <abhishekk> do you have anything to update?
14:17:15 <pdeore> oops I forgot the periodic job update :?
14:17:21 <alistarle> Actually for our spec about glance-download, we are in a good shape, we develop averything you ask
14:17:35 <pdeore> everything is green, no failure other than retry limit for couple of jobs :)
14:17:58 <abhishekk> Cool, you can submit the spec for review and also add it in PTG etherpad for discussion
14:18:12 <alistarle> But we just encounter an issue, is it fine to store potentially a keystone token in the task input, so in the DB and in the task api ?
14:19:02 <dansmith> it's not a good idea, both for security reasons, but also if the token expires before you get to use it, things will break
14:19:19 <dansmith> nova has a long history of things that run too long and break at the end because our token runs out of time
14:19:24 <abhishekk> Also mention your favorable date/time  for the discussion
14:19:27 <alistarle> We actually hesitate to "hack" the import API to remove the token from the input to ensure it is not recoverable from the task-api, or let it like that
14:20:15 <abhishekk> alistarle, just give a brief idea to dansmith about your PoC
14:20:31 <abhishekk> so that he will be on same page as well
14:20:34 <alistarle> (for comparaison, mistral don't really care about that and keep the keystone token in the workflow execution, recoverable from the api…)
14:21:19 <abhishekk> ack, I guess masakari also does it (or was doing it initially)
14:21:40 <alistarle> dansmith sure, Idea is to add a new "glance-download" import method, like the web-download, but to ask a glance to download the image from another glance, really cool for federation or multi-region stuff
14:22:09 <dansmith> alistarle: ack, and you pass a token to the import via args?
14:22:49 <alistarle> in case of a federated keystone, no issue, we rely on the request context to get the token to contact the remote glance, but jokke_ ask us to allow the user to come with an other token from an other keystone, in case it is not federated, and that's where the issue come, how to store that securely
14:23:55 <dansmith> yeah, that's simple, but it'll be fragile in practice, IMHO.. if the download gets delayed (queued) and happens after the token timeout
14:24:06 <dansmith> not to mention the security concern, which is non-trivial, IMHO
14:25:15 <alistarle> token are by default 24h, so I think there shouldn't be more issue than nova snapshot or stuff like that
14:25:49 <pdeore> just received message from abhishek, he got disconnected due to power failure at his place
14:25:55 <dansmith> I dunno about that, I think we hit token timeout in CI jobs
14:26:44 <dansmith> anyway, the thing is,
14:27:07 <dansmith> that token gives the downloading glance *way* too much power
14:27:18 <dansmith> so protecting that token becomes extremely concerning
14:27:56 <dansmith> it's like logging into your computer for someone and then leaving the room and hoping they will only check their gmail and not *your* gmail, or change your password, or install some malware :)
14:28:23 <alistarle> true, but note that in all case this is not an admin token, just a regular user one, it can also be a read-only one if user want
14:28:59 <dansmith> this random first google hit I found says it's 1h by default: https://access.redhat.com/solutions/1527533
14:29:30 <dansmith> alistarle: I know it's not admin.. how can it be read-only? not sure where that would be honored
14:29:33 <alistarle> but I understand yeah, so you prefer to tweak a little bit the task creation code to forcefully remove the token from the task input ? Before it is saved into the db ?
14:30:12 <dansmith> well, I would definitely say writing it to the DB is a bad idea, but I also say it would be a lot better to try to do something where a raw token isn't required
14:31:05 <dansmith> like implement an app download sort of thing in glance where you can generate a short-term URL for an image with a randomly-generated app password-based url, and pass *that* to the remote glance
14:31:16 <dansmith> so that only that one image can be downloaded, no changes made, and no other images
14:31:32 <dansmith> because the token means I could download *all* your images not just the one you want me to
14:32:18 <dansmith> I assume the import process wants to pull the image metadata in addition to the image data, which is why you couldn't use ^ with web-download as it is
14:33:02 * abhishekk facing power fluctuations
14:33:11 <alistarle> Indeed, or we can decide this only work when using federated keystone, with glance in multi-region, and in that case no token is required, we only rely on the context on the import request
14:33:49 <dansmith> alistarle: so think of this example.. let's say your employer has a cloud, and you want to take some not-very-sensitive image out to vexxhost
14:34:22 <dansmith> in order to do this, you'd need to generate a token for your employer's very secure and sensitive cloud, give it to vexxhost for 1h (or 24h) and they'd be able to see everything in your account for that time.. images, instances, volumes, etc
14:35:36 <abhishekk> I will say mention all possible ways in the spec and lets decide the primary solution then
14:35:41 <dansmith> I definitely think it's a cool feature.. I dunno how often this is required, but if it's something we want to implement that's totally cool. But I think it should not violate (nor encourage users to violate) the security of the sending cloud :)
14:35:53 <abhishekk> also can't we have a policy similar to copy-image for this ?
14:36:41 <dansmith> meaning what? off/admin by default?
14:36:50 <abhishekk> yeo
14:36:52 <abhishekk> yep
14:37:07 <dansmith> the problem with that is, the policy is set on the receiving cloud, which is not the one you're violating the security of :)
14:37:19 <alistarle> For me it is acceptable to require a federated keystone, it is actually our use-case, and it doesn't violate any security policy, at least for a first version, what do you think about that ?
14:37:37 <dansmith> so vexxhost can enable that, and the fact that it's enabled and documented encourages users to generate basically passwords and given them to vexxhost to try to do the import :)
14:37:51 <abhishekk> hmm
14:37:58 <dansmith> also, you need more than just the token, you need the glance or keystone endpoint of the sending cloud right?
14:38:18 <dansmith> if you do the app-share url thing, you can just provide a single url to the remote side, which is enough for them to find the image info and data without much else
14:38:58 <alistarle> dansmith we can also decide to revoke the token after downloading the image in the local store right ?
14:39:42 <dansmith> alistarle: we being who, the target cloud? we already don't trust the target cloud in this scenario, but even if it's the user doing it... you're giving someone FULL access for a shorter period of time
14:39:48 <dansmith> it's the "full access" that is the problem
14:40:08 <dansmith> it's like saying "I'll leave my house door open while I make a *quick* trip to the store.. should be fine" :)
14:40:59 <abhishekk> hmm, so its user of the target cloud who is under suspicion here
14:41:19 <dansmith> not necessarily under suspicion, just not the same level of trust
14:41:28 <abhishekk> right
14:41:30 <dansmith> see my employer cloud -> vexxhost example above
14:41:37 <abhishekk> understood
14:41:44 <dansmith> you don't distrust vexxhost, you just can't give them your redhat creds :)
14:42:08 <alistarle> Indeed, so it is easy only when we are talking about multiple region in the same cloud
14:42:22 <dansmith> alistarle: right federated services have a relationship, so it's cool
14:42:23 <alistarle> Which is still a cool use-case to migrate images from regions to other regions
14:42:30 <dansmith> for sure
14:42:49 <abhishekk> alistarle, I would recommend to submit a spec to get better idea about design and then we can discuss the best possible solution
14:43:17 <abhishekk> dansmith, just curious, how can we verify this in tempest?
14:43:30 <dansmith> the federated case?
14:43:35 <abhishekk> yeah
14:44:01 <dansmith> that's similar to g-api-r but we just need a different glance db for that one right?
14:44:10 <dansmith> similar because it's a different endpoint in the catalog
14:44:27 <abhishekk> yep, that means we need devstack change as well
14:44:31 <dansmith> so we could add a g-api-remoterrr (name TBD)
14:44:41 <abhishekk> got it
14:45:07 <alistarle> Cool, we'll write the spec for that then
14:45:11 <abhishekk> thank you :D
14:45:17 <alistarle> is there already some schedule for the PTG ?
14:45:28 <abhishekk> https://etherpad.opendev.org/p/zed-ptg-glance-planning
14:45:34 <dansmith> alistarle: the devstack bit will be pretty simple because the g-api-r thing is almost what you need, I can help
14:45:43 <abhishekk> this is the planning etherpad at the moment
14:46:03 <abhishekk> you can add your topic, suitable date and time for the discussion
14:46:19 <abhishekk> we are gathering between 1400 UTC to 1700 UTC
14:46:26 <abhishekk> 4 to 8 April 2022
14:46:56 <abhishekk> Out of which 4 is reserved for TC discussions (so it will be 5 to 8 April)
14:47:42 <alistarle> Ok that's cool, we'll add the spec and the topic here also :)
14:48:25 <alistarle> I'm gonna leave to check if I well close my door, I left it open just for this *quick meeting* ;)
14:49:01 <abhishekk> :D
14:49:01 <dansmith> lol
14:49:33 <abhishekk> thank you alistarle
14:49:41 <abhishekk> I guess we are done now
14:49:51 <dansmith> good talk though :)
14:50:09 <alistarle> yes, thanks for your advice :)
14:50:44 <pdeore> Thank you :) do we have anything else to discuss, or we can wrap up?
14:50:51 <dansmith> ++
14:51:00 <abhishekk> nothing from me
14:52:01 <pdeore> ok, let's wrap up then :)
14:52:18 <pdeore> Thanks everyone :)
14:52:28 <pdeore> #endmeeting