14:01:10 <abhishekk> #startmeeting glance
14:01:11 <openstack> Meeting started Thu Sep 24 14:01:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:14 <openstack> The meeting name has been set to 'glance'
14:01:17 <abhishekk> #topic roll call
14:01:21 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:23 <abhishekk> o/
14:02:03 <abhishekk> waiting couple of minutes for others to join
14:02:46 <dansmith> o/
14:03:19 <abhishekk> dansmith, looks like again only two of us :D
14:03:33 <abhishekk> rosmaita, might be busy with cinder release
14:03:38 <dansmith> that's too bad,
14:03:51 <rosmaita> sorry, am not paying attention
14:03:52 <dansmith> because I wanted to discuss openstack client, like we should have before we merged that patch >:(
14:04:16 <rosmaita> if jokke were here, he would say openstack client is dead to us
14:04:25 <abhishekk> we can
14:04:43 <dansmith> rosmaita: I'm aware :/
14:04:43 <abhishekk> lets proceed
14:04:56 <rosmaita> well, somebody had to say it
14:05:01 <Steap> dang, I was in #openstack-unregistered :-(
14:05:07 <abhishekk> oops
14:05:12 <abhishekk> #topic Updates
14:05:23 <abhishekk> PTL nominations are open now
14:05:30 <abhishekk> I have filed nomination for W cycle
14:05:42 <abhishekk> Anyone interested can also file the nomination
14:06:12 <rosmaita> abhishekk: you have my vote!
14:06:25 <abhishekk> rosmaita, thank you
14:06:36 <rosmaita> thanks for stepping up
14:06:55 <abhishekk> thanks for your support
14:07:08 <abhishekk> moving ahead
14:07:16 <abhishekk> #topic release/periodic jobs update
14:07:23 <abhishekk> glance rc1 released today
14:07:43 <abhishekk> \o/ we managed to get targeted patches in time
14:07:59 <abhishekk> thank you to all new contributors and reviewers
14:08:15 <abhishekk> RC1 will be final release candidate for Victoria, unless we found any critical issue
14:08:49 <abhishekk> #topic Periodic jobs - Couple of timeouts for functional-py36 jobs, I will analyze the logs
14:08:59 <abhishekk> ahh
14:09:05 <abhishekk> Periodic jobs - Couple of timeouts for functional-py36 jobs
14:09:11 <abhishekk> others are green
14:09:47 <abhishekk> #topic Next week meeting
14:10:26 <abhishekk> I am taking a week off, so can we cancel next week's meeting or either of you are interested to chair the meeting
14:10:50 <dansmith> nope.
14:11:40 <abhishekk> ack, I think its better to cancel the next weeks meeting, I will sent mail on ML to notify the same
14:11:49 <abhishekk> Moving into open discussion
14:11:59 <abhishekk> #topic Open discussion
14:13:13 <abhishekk> this reminds me to ping fungi for symlinks in specs (for moving specs from approved to implemented directory)
14:14:12 <abhishekk> dansmith, regarding your concern about OSC
14:14:57 <abhishekk> It was decided by all the cores to not use osc in glance as it was not fully supported
14:15:06 <dansmith> shall I start talking or are you about to say something?
14:15:11 <jokke> hey
14:15:33 <abhishekk> you can put your concern
14:16:29 <dansmith> I understand that was done at some point, but I'd like to know when that was, and what the gaps were at the time, as well as what gaps need to be filled before glance is willing to be less than overtly hostile towards it
14:16:44 <dansmith> glance doesn't have to "support" OSC at all necessarily,
14:17:24 <abhishekk> I guess it was decided two cycles back
14:17:25 <dansmith> although I think that a purely-infra piece of code (those playbooks are basically an extension of devstack and d-g) is a perfect place to use it and even to get a little test coverage for some basic parts of it
14:17:39 <rosmaita> a key thing we need to do is to remove the deprecated tenant_is_owner option
14:17:53 <rosmaita> because OSC assumes that that is True
14:18:26 <abhishekk> yes
14:18:29 <dansmith> rosmaita: I don't know what that means, or what the impact is
14:18:46 <rosmaita> dansmith: give me a min to find you some info
14:18:52 <dansmith> rosmaita: but I can tell you that it doesn't prevent successful use of osc for listing and showing images, as that code was doing :)
14:19:29 <rosmaita> actually, it can affect a lot of stuff
14:19:48 <rosmaita> just look at any of the image sharing docs and see how complicated they are
14:20:23 <jokke> dansmith: so bit background for the OSC decision. We moved to endorse it back in the time when that was community goal (first time) even with all the gaps and issues the image part of it had. We raised those issues and told the community that we'll keep python-glanceclient around as long as needed for closing those gaps and getting the osc image parts to the state they should be
14:21:36 <jokke> We changed all our docs etc. and kept doing our new development on python-glanceclient. Couple of years, in every PTG and Summit we discussed about those very same issues and gaps in OSC and every time we were told they're been fixed. And 6 months later we had exactly the same discussion
14:22:49 <jokke> so couple of cycles ago, we pulled the plug and let the comunity know that we will recosider after OSC gets their client to good state and keeps feature parity to the API at least couple of cycles so we know it's actually maintained and not just one off effort to get us swap again
14:22:56 <dansmith> rosmaita: am I still waiting for a link or pointer?
14:23:53 <dansmith> jokke: so we move from "it kinda works but there are some gaps" to "we are going to ignore this until someone tells us it is 100% working"?
14:24:23 <dansmith> jokke: I don't understand why using it in infra-only code, which doesn't even get packaged in the distribution is anything other than free test coverage
14:25:02 <dansmith> I understand the desire not to encourage people to use it, to use glanceclient in glance docs, etc
14:25:03 <jokke> dansmith: we moved from "we're promoting broken client which has some things working to give it endorsement" to "We support the client we have control over and works"
14:25:14 <dansmith> I don't see how that relates to using it in infra-only code
14:25:39 <abhishekk> unfortunately that's true, since couple of years we don't have bandwidth to work other things than glance due to shortage of contributors
14:25:45 <dansmith> jokke: and that pertains to infra-only code, how? neither promotion, nor support are implied in that use
14:26:31 <rosmaita> dansmith: https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/spec-lite-deprecate-owner_is_tenant.html
14:26:57 <dansmith> abhishekk: but you've got a new contributor here, which wrote infra code for missing test functionality, using the community-standard client, and it was working fine,
14:27:11 <dansmith> abhishekk: and then you took time out for writing and reviewing a rewrite of that
14:27:24 <dansmith> rosmaita: thanks, will review
14:27:48 <fungi> abhishekk: sorry, stepped away but yes, please do get up with me to revisit your .htaccess redirects
14:28:06 <abhishekk> fungi, ack, thank you
14:28:12 <dansmith> abhishekk: that kind of approach doesn't really encourage new contributors to help, and probably relates to an approach that doesn't encourage other people in the community to help fix osc stuff in glance :/
14:28:27 <jokke> dansmith: so why should we use osc in there and expect people who might need to review those infra used bits to dig in how something works in osc? If infra wants to use osc only, they can host those files in their repos and maintain them. I just don't see reason nor benefit having OSC used in Images API facing stuff if we're not supporting it
14:28:59 <rosmaita> dansmith: the implications of that setting are explained here: https://docs.openstack.org/api-ref/image/v2/#sharing
14:29:24 <dansmith> jokke: no, these files are not hostable anywhere else
14:30:28 <dansmith> jokke: you're kinda implying that you will _never_ support it, because clearly support is never going to come in the form of 100% completion.. we already do image manipulation in devstack with osc, and if it were to break, ya'll would have to fix it all the same
14:30:41 <fungi> please also don't think that "infra" (tact sig and/or opendev collaboratory sysadmins) cares whether you use glanceclient or openstacksdk/openstackclient in your tests
14:30:50 <dansmith> covering a couple more cases here (really it's just image-show, so come on) gets you a little more baseline coverage at least
14:31:12 <dansmith> fungi: i'm lumping infra and qa together a bit here, which was fine until YOU showed up :P
14:31:19 <fungi> heh ;)
14:31:26 <fungi> fine, i can be the whipping post
14:31:52 <fungi> i personally care, but that's only my opinion
14:32:16 <jokke> dansmith: I think my biggest thing here is our little experiment with uwsgi ... that's actually very great example. We told strongly to everyone that it's not working, we don't have time nor expertese to figure it out, don't use it. And people went with "Oh it's used in infra for testing so it must be the right thing to do" I really don't want to send that message again
14:32:21 <fungi> as a user of glance in many public clouds, i use openstackclient and openstacksdk to upload, list and delete images in them
14:32:40 <dansmith> anyway, I know I'm not a *real* core here, but I'd just like to say that I don't think the "don't use OSC in docs" resolution should apply to something like this, and it would have been a lot cooler if we could have had a discussion about it before just steamrolling over it
14:32:46 <fungi> because i don't want to have to run a separate tool or library to interact with each api in openstack
14:33:01 <dansmith> especially since you guys are trying to attract and retain reviewers and contributors
14:33:33 <dansmith> jokke: right, but you might recall, it actually works fine for all those people who were using it :)
14:33:40 <dansmith> as does osc for glance, as fungi just mentioned
14:34:35 <fungi> i will readily admit i am not an advanced user of glance's features, but what i do with it probably represents what 90% of glance users need
14:34:44 <dansmith> exactly,
14:35:03 <dansmith> and for those 90%, there is a substantial benefit in having a unified client, with repeatable behaviors and patterns
14:35:05 <fungi> i don't use it for cloud administration, i don't run any production openstack clouds
14:35:20 <abhishekk> that was the story until import and multiple stores support is added
14:35:21 <dansmith> which is the thing most people hate the most about openstack, both in the community, and OUR customers
14:35:40 <dansmith> abhishekk: no, remember, lots of people are totally fine without using import and some outright disable is
14:35:43 <abhishekk> I guess import support is added recently and not sure it is supporting all import methods
14:35:53 <dansmith> abhishekk: so I still assert that the 90% (or greater) case applies
14:36:42 <dansmith> abhishekk: we could quickly test it in that same post playbook for things like web-download you know
14:36:51 <dansmith> but...it'd mean adding osc back into it :)
14:37:46 <fungi> with my clueless user hat on, i'm not sure what benefit "image import" represents to me. i just have this image i want to upload. it would of course be nice if all openstack providers supported most popular image types and converted them. some are doing that opaquely with tasks, and some have also asked not to rely on that because it brings their cloud to its knees when you do it a lot
14:37:50 <jokke> dansmith: fungi: the 90% also applies to the help requests we got over here from people. "Could someone help me I tried to do openstack image <X Y Z> and it's failing" and our first response was "Could you try with glance image-<X> <Y Z>" and reply we got back was "Hey thanks it works!"
14:38:11 <jokke> that was big contributor to that frustration
14:38:13 <dansmith> jokke: it's super easy to say "reproduce it with glanceclient and then I'll help you"
14:38:22 <fungi> is that 90% of your users, or 10% of your users? ;)
14:38:59 <jokke> fungi: I mean 90% of people that came to ask help on this channel
14:39:00 <dansmith> fungi: as a user, the only benefit (IMHO) is being able to provide a web url so glance fetches the image from there instead of you uploading
14:39:11 <dansmith> fungi: that could (of course) be implemented without import too, but that's how people can do it
14:39:18 <dansmith> fungi: otherwise import is just extra pain for users
14:40:00 <fungi> dansmith: got it. yeah i guess if i was super bandwidth constrained and wanted to use images someone else was publishing, that would be helpful
14:40:16 <jokke> dansmith: fungi: also automatic conversion, comression handling + anything the cloud op wants/needs to do upon image creation, like metadata injection.
14:40:32 <dansmith> jokke: he said *users*
14:41:26 <jokke> for glance user, it's still just one client call, but instead of figuring out what properties you need to set on that specific cloud and what format the image needs to be to work. you can just end the image on it's way and if it becomes active you should expect it to work
14:41:30 <fungi> well, as a user i want to be able to use the image i've uploaded, so glance's import process doing the things the provider wants for me to be able to do that in their environment is part of it (the client is merely triggering the call to perform the import if i understand)
14:41:42 <jokke> s/end/send/
14:42:24 <fungi> but i guess this is veering into the uwsgi problem discussion, not the osc/sdk discussion
14:42:57 <jokke> fungi: actually no, the osc got import support very recently
14:42:57 <dansmith> fungi: right, because osc supports this :)
14:43:19 <dansmith> and the reason osc supports this,
14:43:28 <jokke> this was one of those big feature gaps why we finally pulled the plug
14:43:56 <dansmith> is because in order to test this in devstack, we needed to do an import, and contributors jumped up to write the osc support so that we could do all those things, without having to add glanceclient usage back into devstack, which uses osc for basically everything
14:44:22 <dansmith> if we had just told those people to eff off, or even worse, gave up and just never tested it, then we wouldn't have that support
14:45:01 <abhishekk> fungi, dansmith to be frank, we faced lots of issues with osc, didn't have enough contributors or neither got any support from osc guys even after following up for couple of PTG
14:46:15 <dansmith> abhishekk: all of your tests are set up with osc now, which means you can either (a) deal with things as they arise or (b) just remove tests when those things break
14:46:21 <dansmith> (a) helps your users, (b) does not
14:46:45 <dansmith> (a) means less likely that people will show up with osc problems you have to solve (but can punt on) (b) hurts glanceclient users as well as osc users
14:47:04 <fungi> with my user hat on, the only real concern is that the docs don't indicate that the things i want to do are possible with osc/sdk and that i don't actually need to install a separate client. as someone who happens to know that it already does all the things i personally need, i'm mostly happy to just go on ignoring the glance user docs
14:48:38 <jokke> dansmith: don't get me wrong, I was very concerned when you jumped into looking that uwsgi stuff as I was expecting us to need spend loads of time on that based on the previous experience. I'm super happy that you did as it moved lots of thing in very good direction in general
14:48:44 <fungi> if glance made changes which caused it to stop working to that degree with osc, or osc made changes which caused it to stop working with glance, due to lack of testing, then that would also concern me as a user
14:50:16 <dansmith> fungi: that's kinda my point about not barring use of osc in upstream-only test playbooks.. we get a little early-mover advantage test coverage for basic things, without waiting for something dumb like "image show doesn't work anymore" to end up in a user's lap, which costs way more time to diagnose and fix
14:51:04 <dansmith> jokke: the same goes here.. we have good evidence that lots of people use osc with glance all the time, as they did glance and uwsgi. taking the absolutist approach that we will not allow any use of it doesn't change the reality of what people are doing, and is also far more extreme of a stance than we really need
14:51:21 <dansmith> refuse to help people with osc bugs all you want, but we needn't be client extremists, IMHO
14:52:32 <jokke> fungi: yeah, the osc path did not start well to begin with as we were told to not bother "OSC will do things it's way and the glance community input is not required nor desired" then lots of companies downscaled their contributions and all that was left just hanging but the two communities never collaborated about any of those aspects as we were struggling to keep afloat at that point and I think
14:52:38 <jokke> OSC folks just never got to it as basic create/delete/list worked "just fine"
14:53:20 <dansmith> jokke: do you know that osc now uses the python clients to do its actual work?
14:53:39 <dansmith> meaning, osc does (or will/should) use glanceclient to actually talk to glance, as it does with nova, et al
14:53:55 <fungi> but also the nodepool in opendev is using openstacksdk to upload something like 10 different images to a dozen different providers on various openstack releases with at least several different format requirements every day
14:54:06 <jokke> dansmith: honestly no, I have no idea about the details of osc current state
14:54:12 <abhishekk> I didn't know that
14:54:48 <fungi> the current high-level interface in openstacksdk is actually inherited from code which used to be a part of nodepool
14:55:15 <fungi> because we needed something which could present a consistent experience across a bunch of inconsistent clouds with their own quirks and requirements
14:55:23 <abhishekk> last 5 minutes,
14:55:31 <fungi> without the user needing to know each cloud's quirks
14:57:13 <fungi> but yes, the osc migration to openstacksdk isn't complete yet, so lots of service clients get called into where the sdk lacks coverage
14:57:50 <jokke> fungi: yeah, I think the drive behind the interop/trademark groups or what ever they were called that started this whole image-import journey were very noble and unfortunately that traction was something that got lost on all these downscales. Wouldn't it be great i you could have just send couple of API requests style: "Here is the metadata _we_ need and the payload, do what you must" and get
14:57:56 <jokke> working image in that specific cloud out of it :P
14:58:26 <jokke> Unstead of needing to do that in all the arious clients that might want to interface with said clouds
14:58:46 <jokke> *instead
14:59:10 <abhishekk> last minute
14:59:37 <fungi> it wasn't so much interop/trademark pushing that as it was our ci system's needs to be able to create nodes in lots of different clouds ;)
14:59:49 <fungi> the interop effort merely benefited from it
15:00:03 <abhishekk> As I stated, we will be happy to support OSC back once we ensure that it has support to all new features
15:00:09 <jokke> fungi: no I mean the interop push finished would have solved ot for you without needing special client for that ;)
15:00:25 <fungi> oh, yep
15:00:31 <abhishekk> I will find out the gap and will bring it during PTG or after next weeks discussion
15:00:51 <jokke> Thanks all! Good conversation. We ran out of time
15:01:03 * fungi goes back to using osc to upload some new debian images to his accounts
15:01:21 <abhishekk> we can continue in openstack-glance
15:01:26 <abhishekk> thank you all
15:01:30 <abhishekk> #endmeeting