14:01:10 #startmeeting glance 14:01:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:14 The meeting name has been set to 'glance' 14:01:17 #topic roll call 14:01:21 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:23 o/ 14:02:03 waiting couple of minutes for others to join 14:02:46 o/ 14:03:19 dansmith, looks like again only two of us :D 14:03:33 rosmaita, might be busy with cinder release 14:03:38 that's too bad, 14:03:51 sorry, am not paying attention 14:03:52 because I wanted to discuss openstack client, like we should have before we merged that patch >:( 14:04:16 if jokke were here, he would say openstack client is dead to us 14:04:25 we can 14:04:43 rosmaita: I'm aware :/ 14:04:43 lets proceed 14:04:56 well, somebody had to say it 14:05:01 dang, I was in #openstack-unregistered :-( 14:05:07 oops 14:05:12 #topic Updates 14:05:23 PTL nominations are open now 14:05:30 I have filed nomination for W cycle 14:05:42 Anyone interested can also file the nomination 14:06:12 abhishekk: you have my vote! 14:06:25 rosmaita, thank you 14:06:36 thanks for stepping up 14:06:55 thanks for your support 14:07:08 moving ahead 14:07:16 #topic release/periodic jobs update 14:07:23 glance rc1 released today 14:07:43 \o/ we managed to get targeted patches in time 14:07:59 thank you to all new contributors and reviewers 14:08:15 RC1 will be final release candidate for Victoria, unless we found any critical issue 14:08:49 #topic Periodic jobs - Couple of timeouts for functional-py36 jobs, I will analyze the logs 14:08:59 ahh 14:09:05 Periodic jobs - Couple of timeouts for functional-py36 jobs 14:09:11 others are green 14:09:47 #topic Next week meeting 14:10:26 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 nope. 14:11:40 ack, I think its better to cancel the next weeks meeting, I will sent mail on ML to notify the same 14:11:49 Moving into open discussion 14:11:59 #topic Open discussion 14:13:13 this reminds me to ping fungi for symlinks in specs (for moving specs from approved to implemented directory) 14:14:12 dansmith, regarding your concern about OSC 14:14:57 It was decided by all the cores to not use osc in glance as it was not fully supported 14:15:06 shall I start talking or are you about to say something? 14:15:11 hey 14:15:33 you can put your concern 14:16:29 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 glance doesn't have to "support" OSC at all necessarily, 14:17:24 I guess it was decided two cycles back 14:17:25 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 a key thing we need to do is to remove the deprecated tenant_is_owner option 14:17:53 because OSC assumes that that is True 14:18:26 yes 14:18:29 rosmaita: I don't know what that means, or what the impact is 14:18:46 dansmith: give me a min to find you some info 14:18:52 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 actually, it can affect a lot of stuff 14:19:48 just look at any of the image sharing docs and see how complicated they are 14:20:23 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 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 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 rosmaita: am I still waiting for a link or pointer? 14:23:53 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 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 I understand the desire not to encourage people to use it, to use glanceclient in glance docs, etc 14:25:03 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 I don't see how that relates to using it in infra-only code 14:25:39 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 jokke: and that pertains to infra-only code, how? neither promotion, nor support are implied in that use 14:26:31 dansmith: https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/spec-lite-deprecate-owner_is_tenant.html 14:26:57 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 abhishekk: and then you took time out for writing and reviewing a rewrite of that 14:27:24 rosmaita: thanks, will review 14:27:48 abhishekk: sorry, stepped away but yes, please do get up with me to revisit your .htaccess redirects 14:28:06 fungi, ack, thank you 14:28:12 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 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 dansmith: the implications of that setting are explained here: https://docs.openstack.org/api-ref/image/v2/#sharing 14:29:24 jokke: no, these files are not hostable anywhere else 14:30:28 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 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 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 fungi: i'm lumping infra and qa together a bit here, which was fine until YOU showed up :P 14:31:19 heh ;) 14:31:26 fine, i can be the whipping post 14:31:52 i personally care, but that's only my opinion 14:32:16 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 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 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 because i don't want to have to run a separate tool or library to interact with each api in openstack 14:33:01 especially since you guys are trying to attract and retain reviewers and contributors 14:33:33 jokke: right, but you might recall, it actually works fine for all those people who were using it :) 14:33:40 as does osc for glance, as fungi just mentioned 14:34:35 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 exactly, 14:35:03 and for those 90%, there is a substantial benefit in having a unified client, with repeatable behaviors and patterns 14:35:05 i don't use it for cloud administration, i don't run any production openstack clouds 14:35:20 that was the story until import and multiple stores support is added 14:35:21 which is the thing most people hate the most about openstack, both in the community, and OUR customers 14:35:40 abhishekk: no, remember, lots of people are totally fine without using import and some outright disable is 14:35:43 I guess import support is added recently and not sure it is supporting all import methods 14:35:53 abhishekk: so I still assert that the 90% (or greater) case applies 14:36:42 abhishekk: we could quickly test it in that same post playbook for things like web-download you know 14:36:51 but...it'd mean adding osc back into it :) 14:37:46 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 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 and it's failing" and our first response was "Could you try with glance image- " and reply we got back was "Hey thanks it works!" 14:38:11 that was big contributor to that frustration 14:38:13 jokke: it's super easy to say "reproduce it with glanceclient and then I'll help you" 14:38:22 is that 90% of your users, or 10% of your users? ;) 14:38:59 fungi: I mean 90% of people that came to ask help on this channel 14:39:00 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 fungi: that could (of course) be implemented without import too, but that's how people can do it 14:39:18 fungi: otherwise import is just extra pain for users 14:40:00 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 dansmith: fungi: also automatic conversion, comression handling + anything the cloud op wants/needs to do upon image creation, like metadata injection. 14:40:32 jokke: he said *users* 14:41:26 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 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 s/end/send/ 14:42:24 but i guess this is veering into the uwsgi problem discussion, not the osc/sdk discussion 14:42:57 fungi: actually no, the osc got import support very recently 14:42:57 fungi: right, because osc supports this :) 14:43:19 and the reason osc supports this, 14:43:28 this was one of those big feature gaps why we finally pulled the plug 14:43:56 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 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 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 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 (a) helps your users, (b) does not 14:46:45 (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 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 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 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 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 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 refuse to help people with osc bugs all you want, but we needn't be client extremists, IMHO 14:52:32 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 OSC folks just never got to it as basic create/delete/list worked "just fine" 14:53:20 jokke: do you know that osc now uses the python clients to do its actual work? 14:53:39 meaning, osc does (or will/should) use glanceclient to actually talk to glance, as it does with nova, et al 14:53:55 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 dansmith: honestly no, I have no idea about the details of osc current state 14:54:12 I didn't know that 14:54:48 the current high-level interface in openstacksdk is actually inherited from code which used to be a part of nodepool 14:55:15 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 last 5 minutes, 14:55:31 without the user needing to know each cloud's quirks 14:57:13 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 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 working image in that specific cloud out of it :P 14:58:26 Unstead of needing to do that in all the arious clients that might want to interface with said clouds 14:58:46 *instead 14:59:10 last minute 14:59:37 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 the interop effort merely benefited from it 15:00:03 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 fungi: no I mean the interop push finished would have solved ot for you without needing special client for that ;) 15:00:25 oh, yep 15:00:31 I will find out the gap and will bring it during PTG or after next weeks discussion 15:00:51 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 we can continue in openstack-glance 15:01:26 thank you all 15:01:30 #endmeeting