| *** hemna7 is now known as hemna | 11:51 | |
| *** pdeore_ is now known as pdeore | 13:43 | |
| pdeore | #startmeeting glance | 14:00 |
|---|---|---|
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'glance' | 14:00 |
| pdeore | #topic roll call | 14:00 |
| pdeore | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 14:00 |
| dansmith | o/ | 14:00 |
| pdeore | o/ | 14:00 |
| mrjoshi_ | o/ | 14:00 |
| abhishekk | o/ | 14:00 |
| pdeore | lets wait few minutes for everyone to join | 14:01 |
| rosmaita | o/ | 14:01 |
| abhishekk | jokke_, will not be joining today (holiday in Ireland) | 14:02 |
| pdeore | yeah, so shall we start? | 14:02 |
| abhishekk | now we can start | 14:02 |
| pdeore | ok, let's start | 14:02 |
| pdeore | We have short agenda today as well, with some review reminder again | 14:02 |
| pdeore | #topic Updates | 14:03 |
| pdeore | Zed PTG planning etherpad is up | 14:03 |
| pdeore | #link https://etherpad.opendev.org/p/zed-ptg-glance-planning#L12 | 14:03 |
| 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 |
| abhishekk | We have some interested topics in this PTG | 14:03 |
| abhishekk | Please go through the planning etherpad and check whether if I missed anything | 14:04 |
| pdeore | yeah, I would recommend to add yourself as a driver if you are interested in driving any particular session | 14:05 |
| abhishekk | ++ | 14:05 |
| pdeore | moving to the next topic | 14:05 |
| pdeore | #topic release/periodic jobs | 14:05 |
| pdeore | glance-tempest-plugin is releasing this week, unfortunately we couldn't make few rbac metadef tests in this cycle | 14:05 |
| pdeore | Can we still make it in Yoga? by updating the details on https://review.opendev.org/c/openstack/releases/+/833574 | 14:06 |
| abhishekk | I think we can backport those, so no need to worry | 14:06 |
| pdeore | ack | 14:07 |
| abhishekk | Just get those reviewed first :D | 14:07 |
| rosmaita | is glance_tempest_plugin branched? | 14:07 |
| pdeore | yeah, dansmith we need your attention specially for those patches :) | 14:07 |
| dansmith | pdeore: link? | 14:07 |
| pdeore | rosmaita, no | 14:07 |
| pdeore | https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802792 | 14:08 |
| pdeore | https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802794/14 | 14:08 |
| pdeore | https://review.opendev.org/c/openstack/glance-tempest-plugin/+/802795/12 | 14:08 |
| pdeore | I've removed the lock and updated the namespaces names as per your suggestion | 14:08 |
| dansmith | okay yeah, sorry for letting these get away from me | 14:08 |
| pdeore | so, that's all, moving to Open discussion | 14:09 |
| abhishekk | nah, in that case we can wait for the release I guess | 14:09 |
| abhishekk | pdeore, you can comment on the release patch, saying we need some patches to get in | 14:09 |
| pdeore | abhishekk, ok I will , do I need to -1 that patch with the comment? | 14:10 |
| abhishekk | yes | 14:10 |
| pdeore | ok | 14:10 |
| abhishekk | and once all the patches merged,you can post a new revision as well | 14:11 |
| abhishekk | I will let you know how to do that | 14:11 |
| pdeore | ack | 14:11 |
| pdeore | moving to Open Discussion | 14:11 |
| pdeore | #topic Open discussion | 14:12 |
| abhishekk | Nothing from me | 14:12 |
| pdeore | I just had the review reminder for the glance-tempest-plugin patches, which we already discussed :) | 14:13 |
| abhishekk | Just to update, Zed spec is now open, so your pending specs can be resubmitted against Zed repository | 14:13 |
| pdeore | ack | 14:13 |
| abhishekk | Tomorrow is Holiday in India, so we will not be around as well | 14:13 |
| abhishekk | and glad to see dansmith back in the meetings :D | 14:14 |
| dansmith | half our government voted to make it permanent in 2023 last week, | 14:14 |
| dansmith | so hopefully this madness will stop eventually :) | 14:14 |
| abhishekk | ::D, it should | 14:15 |
| dansmith | so we're done? | 14:16 |
| abhishekk | alistarle, we are about to wrap up | 14:16 |
| alistarle | Oh sorry, I came a little late :/ | 14:16 |
| abhishekk | no worries | 14:16 |
| abhishekk | do you have anything to update? | 14:17 |
| pdeore | oops I forgot the periodic job update :? | 14:17 |
| alistarle | Actually for our spec about glance-download, we are in a good shape, we develop averything you ask | 14:17 |
| pdeore | everything is green, no failure other than retry limit for couple of jobs :) | 14:17 |
| abhishekk | Cool, you can submit the spec for review and also add it in PTG etherpad for discussion | 14:17 |
| 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:18 |
| 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 |
| 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 |
| abhishekk | Also mention your favorable date/time for the discussion | 14:19 |
| 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:19 |
| abhishekk | alistarle, just give a brief idea to dansmith about your PoC | 14:20 |
| abhishekk | so that he will be on same page as well | 14:20 |
| alistarle | (for comparaison, mistral don't really care about that and keep the keystone token in the workflow execution, recoverable from the api…) | 14:20 |
| abhishekk | ack, I guess masakari also does it (or was doing it initially) | 14:21 |
| 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:21 |
| dansmith | alistarle: ack, and you pass a token to the import via args? | 14:22 |
| 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:22 |
| 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:23 |
| dansmith | not to mention the security concern, which is non-trivial, IMHO | 14:24 |
| alistarle | token are by default 24h, so I think there shouldn't be more issue than nova snapshot or stuff like that | 14:25 |
| pdeore | just received message from abhishek, he got disconnected due to power failure at his place | 14:25 |
| dansmith | I dunno about that, I think we hit token timeout in CI jobs | 14:25 |
| dansmith | anyway, the thing is, | 14:26 |
| dansmith | that token gives the downloading glance *way* too much power | 14:27 |
| dansmith | so protecting that token becomes extremely concerning | 14:27 |
| *** tosky_ is now known as tosky | 14:27 | |
| 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:27 |
| 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 |
| dansmith | this random first google hit I found says it's 1h by default: https://access.redhat.com/solutions/1527533 | 14:28 |
| dansmith | alistarle: I know it's not admin.. how can it be read-only? not sure where that would be honored | 14:29 |
| 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:29 |
| 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:30 |
| 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 |
| dansmith | so that only that one image can be downloaded, no changes made, and no other images | 14:31 |
| dansmith | because the token means I could download *all* your images not just the one you want me to | 14:31 |
| 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:32 |
| * abhishekk facing power fluctuations | 14:33 | |
| 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 |
| 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:33 |
| 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:34 |
| abhishekk | I will say mention all possible ways in the spec and lets decide the primary solution then | 14:35 |
| 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 |
| abhishekk | also can't we have a policy similar to copy-image for this ? | 14:35 |
| dansmith | meaning what? off/admin by default? | 14:36 |
| abhishekk | yeo | 14:36 |
| abhishekk | yep | 14:36 |
| 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 |
| 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 |
| 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 |
| abhishekk | hmm | 14:37 |
| dansmith | also, you need more than just the token, you need the glance or keystone endpoint of the sending cloud right? | 14:37 |
| 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 |
| alistarle | dansmith we can also decide to revoke the token after downloading the image in the local store right ? | 14:38 |
| 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 |
| dansmith | it's the "full access" that is the problem | 14:39 |
| 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 |
| abhishekk | hmm, so its user of the target cloud who is under suspicion here | 14:40 |
| dansmith | not necessarily under suspicion, just not the same level of trust | 14:41 |
| abhishekk | right | 14:41 |
| dansmith | see my employer cloud -> vexxhost example above | 14:41 |
| abhishekk | understood | 14:41 |
| dansmith | you don't distrust vexxhost, you just can't give them your redhat creds :) | 14:41 |
| alistarle | Indeed, so it is easy only when we are talking about multiple region in the same cloud | 14:42 |
| dansmith | alistarle: right federated services have a relationship, so it's cool | 14:42 |
| alistarle | Which is still a cool use-case to migrate images from regions to other regions | 14:42 |
| dansmith | for sure | 14:42 |
| 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:42 |
| abhishekk | dansmith, just curious, how can we verify this in tempest? | 14:43 |
| dansmith | the federated case? | 14:43 |
| abhishekk | yeah | 14:43 |
| dansmith | that's similar to g-api-r but we just need a different glance db for that one right? | 14:44 |
| dansmith | similar because it's a different endpoint in the catalog | 14:44 |
| abhishekk | yep, that means we need devstack change as well | 14:44 |
| dansmith | so we could add a g-api-remoterrr (name TBD) | 14:44 |
| abhishekk | got it | 14:44 |
| alistarle | Cool, we'll write the spec for that then | 14:45 |
| abhishekk | thank you :D | 14:45 |
| alistarle | is there already some schedule for the PTG ? | 14:45 |
| abhishekk | https://etherpad.opendev.org/p/zed-ptg-glance-planning | 14:45 |
| 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 |
| abhishekk | this is the planning etherpad at the moment | 14:45 |
| abhishekk | you can add your topic, suitable date and time for the discussion | 14:46 |
| abhishekk | we are gathering between 1400 UTC to 1700 UTC | 14:46 |
| abhishekk | 4 to 8 April 2022 | 14:46 |
| abhishekk | Out of which 4 is reserved for TC discussions (so it will be 5 to 8 April) | 14:46 |
| alistarle | Ok that's cool, we'll add the spec and the topic here also :) | 14:47 |
| alistarle | I'm gonna leave to check if I well close my door, I left it open just for this *quick meeting* ;) | 14:48 |
| abhishekk | :D | 14:49 |
| dansmith | lol | 14:49 |
| abhishekk | thank you alistarle | 14:49 |
| abhishekk | I guess we are done now | 14:49 |
| dansmith | good talk though :) | 14:49 |
| alistarle | yes, thanks for your advice :) | 14:50 |
| pdeore | Thank you :) do we have anything else to discuss, or we can wrap up? | 14:50 |
| dansmith | ++ | 14:50 |
| abhishekk | nothing from me | 14:51 |
| pdeore | ok, let's wrap up then :) | 14:52 |
| pdeore | Thanks everyone :) | 14:52 |
| pdeore | #endmeeting | 14:52 |
| opendevmeet | Meeting ended Thu Mar 17 14:52:28 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:52 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/glance/2022/glance.2022-03-17-14.00.html | 14:52 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/glance/2022/glance.2022-03-17-14.00.txt | 14:52 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/glance/2022/glance.2022-03-17-14.00.log.html | 14:52 |
| *** dasm is now known as dasm| | 21:21 | |
| *** dasm| is now known as dasm|off | 21:21 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!