14:01:01 <abhishekk> #startmeeting glance
14:01:02 <openstack> Meeting started Thu Jul  2 14:01:01 2020 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'glance'
14:01:08 <abhishekk> #topic roll call
14:01:13 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:15 <abhishekk> o/
14:01:18 <mhen> greetings o/
14:01:22 <rosmaita> o/
14:01:22 * dansmith lurks
14:01:36 <Steap> (croelandt here, this is my only registered nick)
14:01:38 <Steap> o/
14:01:39 <jokke> o/
14:01:58 <abhishekk> cool, lets start
14:02:20 <abhishekk> #topic release/periodic jobs update
14:02:33 <abhishekk> V2 is 3 weeks away
14:03:04 <abhishekk> we need reviews on specs and get those merged within next couple of weeks
14:03:17 <abhishekk> so please spend some time in reviewing specs
14:03:46 <dansmith> so I need to get a spec up for the admin delegation thing soon
14:04:07 <abhishekk> apart from specs, dansmith and I found 3-4 bugs around copy plugins, patches for those fixes are up as well
14:04:13 <abhishekk> kindly review them as well
14:04:22 <abhishekk> dansmith, yes
14:04:52 <abhishekk> After meeting I will send mail regarding review priorities of the week
14:05:25 <dansmith> are there no approved glance specs for v yet?
14:05:30 <dansmith> directory looks empty
14:05:45 <abhishekk> dansmith, nothing at the moment
14:05:50 <dansmith> yikes okay
14:06:10 <abhishekk> I know :(
14:06:49 <abhishekk> regarding periodic job we have 1 timeout for all days in a week to functional-py36 jobs
14:07:14 <abhishekk> will spend some time around it to identify the cause of timeout
14:08:00 <abhishekk> jokke, rosmaita, smcginnis please focus on specs reviews as much as possible
14:08:02 <abhishekk> moving ahead
14:08:37 <rosmaita> abhishekk: ack
14:08:52 <abhishekk> I am going to skip 2nd and 3rd topic which is about reviews, backport reviews which I will include in a review priority mail
14:09:17 <abhishekk> Directly jumping to Open discussion
14:09:25 <abhishekk> #topic Open Discussion
14:09:39 <abhishekk> Retry feature for glanceclient, like the one in neutronclient?
14:09:46 <Steap> Yep
14:09:55 <Steap> so this is asked by one of my customers
14:10:10 <Steap> Obviously this is useless if the network is terribly bad
14:10:24 <Steap> but the idea kind of makes sense to me
14:10:41 <Steap> The neutron client can retry certain requests after they failed
14:10:53 <rosmaita> Steap: can you give an example scenario for glanceclient
14:10:55 <Steap> this is something that can be done when the client is used as a library
14:11:00 <abhishekk> So in what kind of failures it does consider for retrying?
14:11:12 <abhishekk> just what rosmaita asked
14:11:35 <Steap> The customer who requested that failed that it could be useful when Glance is used with Cinder
14:12:04 <Steap> so Cinder would actually ask glance to retry N times
14:12:18 <Steap> as I said, I'm a bit afraid that the customer's network is at fault here :)
14:12:31 <Steap> but it can happen that something goes wrong, and retrying fixes the issue
14:12:48 <Steap> the default behaviour would be the same as right now: do not retry anything, ever.
14:12:52 <rosmaita> on the cinder side, i think we already retry when trying to get stuff out of glance
14:14:35 <abhishekk> at the moment I am not able to point out any scenario where we can retry on failure
14:14:40 <Steap> so you "manually" call client.method() multiple times
14:15:01 <Steap> abhishekk: let's say you want to get a list of all images and are hit with a network error
14:17:03 <abhishekk> I can relate it but imo this retry thing should be added in the consumer of client
14:17:07 <rosmaita> https://opendev.org/openstack/cinder/src/branch/master/cinder/image/glance.py#L205-L214
14:17:46 <abhishekk> same thing ^^
14:17:50 <Steap> hehe
14:18:10 <jokke> yeah, for cli part I can see why it would be nce to have retry in image-list ... if you fail paging call 100 and the whole thing blows up at that point, it might be bit annoying ;)
14:18:21 <Steap> ok, it makes sense to not add the "retry" option in both the library and the consumer
14:19:00 <jokke> but for the python lib side, yes I do agree that the consumer should catch the errors they expect and handle retries if they so wish to do
14:19:22 <abhishekk> +1
14:19:47 <Steap> I was not aware Cinder already did this
14:19:57 <Steap> so let's forget about the generic retry in the library
14:20:06 <jokke> ++
14:20:07 <Steap> I'll deal with my customer :)
14:20:09 <Steap> thanks
14:20:13 <rosmaita> and the number of retries is configurable in cinder
14:20:14 <jokke> Thanks Cyril
14:20:17 <abhishekk> Step (cyril :D) thank you
14:20:46 <abhishekk> mhen, you are next
14:21:26 <mhen> so I was playing around with Global Request IDs in OpenStack and l believe I identified two issues in Glance
14:21:39 <mhen> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015672.html
14:22:45 <mhen> If any of you could spare a few minutes to have a look and tell me whether/where to report this, I would appreciate it
14:22:58 <abhishekk> will go through your mail and comment/reply accordingly
14:23:08 <mhen> abhishekk, thank you
14:23:19 <mhen> it's not urgent for me
14:23:37 <mhen> but didn't receive any reply so far, so just wanted to make you aware
14:23:43 <abhishekk> this request-id work has been to old to remember now, so need some to time to remember it
14:23:46 <rosmaita> mhen: off topic, but i left a comment on your spec, but it basically looks ok to me
14:24:17 <abhishekk> I have seen that mail but didn't got time, but will try to put some time in this week
14:24:27 <mhen> abhishekk, appreciated
14:24:51 <abhishekk> mhen, no problem, thanks for bringing this in discussion
14:25:14 <jokke> Couple of qick things from my side:
14:25:31 <abhishekk> next one is also yours
14:25:58 <mhen> jokke, related to the global request id thingy?
14:26:15 <jokke> nope generally on open discussion
14:26:37 <mhen> I have one other topic if you don't mind
14:26:47 <abhishekk> mhen, we need support in python-glanceclient as well
14:27:07 <jokke> mhen: absolutely go for it
14:27:16 <mhen> abhishekk, support as in support when using it as an actual CLI client?
14:27:28 <mhen> (instead of as a library)
14:28:21 <abhishekk> mhen, need to revisit my comment might be I misjudged it
14:28:39 <mhen> because, python-glanceclient as a library (when used by others, such as Nova) already has support for it (albeit broken at times, see mail)
14:29:14 <abhishekk> ack
14:29:33 <jokke> mhen: I think abhishekk is already on your encryption topic ;)
14:29:46 <mhen> oh
14:30:02 <abhishekk> sorry, I was talking about encryption one
14:30:07 <mhen> sorry, I was still on about the global request id
14:30:11 <jokke> ;)
14:30:20 <mhen> okay about the image encryption
14:30:36 <mhen> so the argument was that we should support glanceclient in favor of openstackclient
14:31:04 <mhen> my question is: does glanceclient support using other clients as libraries (such as barbicanclient), like openstackclient does?
14:31:26 <mhen> we'd need to make some calls to Barbican during the image encryption process for key retrieval for instance
14:31:41 <jokke> mhen: nope, and as such I'm not convinced we should do the encryption in glanceclient
14:31:48 <abhishekk> no, that's why I said I need to revisit my comment again
14:32:43 <mhen> do you see any other alternative than openstackclient then? (I don't tbh)
14:34:51 <abhishekk> in openstack client you are going to do some changes to barbican commands or glance commands?
14:35:00 <jokke> mhen: honestly I personally think people actually doing this won't be using either. They will have their image build pipeline doing all this without human interaction and thus I think we as Glance community need to make sure we can handle the metadata etc. in our end, I think openstack client is good place to put the "manual" functionality so people can test it and handle the manually created
14:35:06 <jokke> images.
14:35:45 <jokke> But I don't see huge urge to have actual client for encrypting images per se and definitely not the usecase for glanceclient doing it
14:36:04 <mhen> as an example, we added: "openstack image create --file myimage.raw --encryption-secret-id $BARBICAN_SECRET_ID my-encrypted-image" which locally encrypts an image and uploads it
14:37:03 <abhishekk> hmm
14:37:17 <mhen> tbh having to fiddle with encryption stuff manually is tedious and error-prone
14:37:46 <mhen> that's why we also added image signing automation into openstackclient (contributed upstream)
14:38:21 <jokke> mhen: yep .. and like said I think the osc for the "manual" usecase is great for testing and people to fiddle around, but I really don't expect majority of production users who would need this using that
14:38:22 <abhishekk> ack
14:40:08 <mhen> so, you think they'd be using the API directly and push their encrypted images this way (which they encrypted beforehand using some other pipeline)?
14:40:09 <abhishekk> Ok I will revisit my comment
14:40:43 <jokke> mhen: yeah, I'd expect these being integrated to what ever image building pipeline they are using.
14:40:50 <jokke> Being it Jenkins or something else
14:41:33 <mhen> I see your point but would it actually hurt to add this option to the client? Our architecture outsources the required methods to os-brick lib anyway - so essentially it's just method calls.
14:42:44 <jokke> mhen: glanceclient, I'd prefer not bloating it with all the dependencies to do it, like said osc is great place for it as it has pretty much all the dependency integrations already
14:43:35 <mhen> glanceclient does not provide the necessary requirement (using other client libs) anyway, it would need to be osc or none
14:44:26 <jokke> mhen: it doesn't mean you can't create encrypted images with glanceclient (and we need to make sure that is the case and that our schemas etc. works for that) as long as you have the key id and the excrypted payload
14:44:34 <abhishekk> So we need to document about this
14:44:39 <jokke> yup!
14:45:46 <abhishekk> last 15 minutes
14:45:55 <tosky> just a reminder for this backport of the zuulv3 migration backport to ussuri: https://review.opendev.org/#/c/738693/ (which I will backport to train) and this train-specific zuul change (already applied in other way on >=ussuri): https://review.opendev.org/#/c/739056/
14:46:01 <tosky> EOF
14:46:29 <abhishekk> tosky, I will include these in review priority mail
14:46:31 <mhen> jokke, I thought you were against it altogether but when you are fine with us putting it in osc then that's good
14:46:41 <jokke> mhen: my point was kind of if we expected the main use case being people doing this by hand, we probably should look into automating it with glanceclient or independent tooling. But for testing/development/odd manual usage purposes the osc is perfect place to do it
14:47:00 <mhen> jokke, agreed
14:48:35 <abhishekk> anything else mhen ?
14:49:16 <mhen> no, that's it, thanks for your attention :)
14:49:41 <jokke> mhen: if oyu could do it a way that one can also just encrypt the image locally without directly uploading it to glance from osc, that would be amazing
14:50:12 <mhen> jokke, will consider that, thanks for the suggestion
14:51:05 <abhishekk> jokke, you want to discuss something right?
14:51:06 <tosky> abhishekk: thanks! It's not supercritical but the sooner they (and the last one which will be created after merging the ussuri patch) are merged, the better (easier maintenance)
14:51:15 <jokke> abhishekk: yeah couple of things
14:51:24 <abhishekk> please go ahead
14:51:29 <abhishekk> tosky, ack
14:52:14 <jokke> 1) Relating to what dansmith has been working on (big hand Dan!) we kind of realized how bad idea it is to run the plugins as part of copy-image ... so there is patch up for it
14:52:43 <jokke> #link https://review.opendev.org/#/c/738675/
14:52:55 <jokke> The tests need bit more refining, but working on thta
14:53:04 <abhishekk> ack
14:53:06 <jokke> thanks abhishekk helping out with those tests
14:53:15 <abhishekk> :D
14:53:15 <jokke> the second one is a beast
14:53:34 <jokke> #link https://review.opendev.org/#/c/738672/
14:53:59 <jokke> deprecation removals including remains of registry and Images API v1
14:54:47 <jokke> 3 patches to go, the linked oe should be ready. The one after that I need to create dummy wsgi entry for v1 (sorry, QA/grenade) hit us again
14:55:33 <abhishekk> registry removal patch is merged
14:55:35 <jokke> should have it ready when the enable_v2_api removal merges and the last one is just config cleanup for all the stuff that was thrown away in the process
14:55:51 <abhishekk> the link you pasted here is removal of enable_v2_api
14:55:51 <jokke> yes the first one of the chain merged this morning, thank you
14:56:00 <jokke> abhishekk: correct
14:56:07 <jokke> it's the first one still in review
14:56:37 <abhishekk> hmm, I will include those on review priority mail as well
14:57:05 <abhishekk> we need to get these big patches in to avoid merge conflicts :D
14:57:08 <jokke> As these patches touches all over our codebase, please lets not keep them hanging as it will be absolute rebase nightmare
14:57:26 <abhishekk> ack
14:57:26 <jokke> that's all from me
14:57:46 <abhishekk> thank you jokke
14:57:54 <abhishekk> anything else guys?
14:58:36 <abhishekk> cool, keep eye on priority mail
14:58:54 <abhishekk> thank you all, have a nice time ahead
14:59:02 <jokke> thanks all!
14:59:12 <Steap> Thanks!
14:59:17 <mhen> thank you, see ya
14:59:24 <abhishekk> #endmeeting