14:00:04 <jokke_> #startmeeting glance
14:00:05 <openstack> Meeting started Thu Mar 22 14:00:04 2018 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'glance'
14:00:09 <jokke_> #topic roll-call
14:00:11 <smcginnis> o/
14:00:12 <Roamer`> o/
14:00:14 <jokke_> o/
14:00:16 <abhishekk> o/
14:00:17 <rosmaita> o/
14:01:10 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:23 <jokke_> #topic updates
14:02:04 <jokke_> I was hoping that i could tell you that we had the glanceclient release out, but it's not there just yet. Today still I'd expect
14:02:59 <abhishekk> just one question about that
14:03:02 <jokke_> We've definitely had good start for the cycle. Lots of reviews coming in and even getting merged! \\o \o/ o// o/7
14:03:10 <jokke_> abhishekk: shoot
14:03:21 <abhishekk> create_image_via_import is documented as EXPERIMENTAL, should we remove that?
14:03:23 <abhishekk> https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/shell.py#L112
14:03:36 <jokke_> abhishekk: YES! thank you!
14:03:42 <rosmaita> not yet, i don't think
14:03:44 <jokke_> hmm-m
14:03:46 <jokke_> actually
14:03:49 <jokke_> not convinced
14:03:53 <rosmaita> we will be stuck with that name
14:03:59 <rosmaita> leave it experimental in queens
14:04:01 <jokke_> if it's the via import
14:04:07 <rosmaita> we can deal with it in master
14:04:08 <jokke_> and likely rocky
14:04:50 <jokke_> we want to move that functionality to the normal image create and deprecate that name
14:04:57 <abhishekk> ok, sounds good
14:04:57 <rosmaita> also, as far as release timing goes, i think it needs another day of testing
14:05:01 <jokke_> so lets plan that bit more carefully
14:05:15 <rosmaita> so let's aim to release early next week so we get all bugfixes merged
14:05:31 <smcginnis> If it's not today, that gives a few days for testing since we don't normally do releases on Fridays.
14:05:37 <smcginnis> rosmaita: ++
14:05:40 <rosmaita> smcginnis ++
14:05:43 <smcginnis> :)
14:05:45 <abhishekk> ++
14:06:16 <rosmaita> when i say another day of testing, i mean that i am actually doing that today
14:06:26 <rosmaita> (it's not speculative)
14:06:36 <smcginnis> Excellent
14:06:55 <jokke_> rosmaita: mind to elaborate? I see one bug against it that has fix merged to the master already
14:07:10 <rosmaita> yeah, i ran out of time while fixing that bug
14:07:20 <rosmaita> i never ran through the complete scenario start to finish
14:07:38 <rosmaita> (i had trouble getting the unit tests for that bug to work)
14:08:02 <rosmaita> so i don't know of any actual problems
14:08:10 <rosmaita> but i have not thoroughly tested yet
14:08:34 <abhishekk> i guess its good to have another round for functional testing
14:09:14 <jokke_> well, in that case lets freeze everything else and get onto it ;)
14:09:37 <rosmaita> ok
14:10:55 <jokke_> #action everyone Get testing the 'web-download' on glanceclient and do not merge anything else before that is done so we get the client releases out of the door.
14:12:24 <jokke_> ok, that's all on updates side from me, rosmaita you have anything?
14:12:27 <rosmaita> i will send out an update to the ML at my end of day today saying whether i found anything else or not
14:12:49 <rosmaita> if i don;'t find anything, i will put up release patch for monday
14:13:13 <rosmaita> jokke_ i have items 5 & 6 for later
14:13:19 <jokke_> yeah
14:13:24 <jokke_> I mean updates
14:13:38 <jokke_> ok, next one
14:13:57 <Roamer`> right, that would be me, I guess
14:13:58 <jokke_> #topic New store driver (StorPool)
14:14:06 <jokke_> Roamer`: stage is yours
14:14:29 <Roamer`> short and sweet: how would you guys feel about me proposing a new driver?  There are already some vendor-specific drivers, we'd like to add ours too
14:15:05 <Roamer`> we tried once before, but we never really did the work, and even before that, the spec was received with, well, doubt
14:15:13 <Roamer`> #link https://review.openstack.org/#/c/137360/
14:15:39 <Roamer`> I do understand people's concerns about untested drivers, or about a possible vendor driver explosion, but as things stand, we will write the driver anyway for a customer
14:16:13 <jokke_> based on the discussion around this on the ML, I'd like to know if there is anything specifically you want to do this native on glance instead of using the cinder driver?
14:17:21 <Roamer`> well, to be completely honest, I haven't really looked at the Glance Cinder backend (glance_store/_drivers/cinder), if that's what you mean
14:18:23 <Roamer`> what I have in mind is a driver that makes sure that no data is being transferred needlessly - if an image has to be created from a StorPool-backed Cinder volume or vice versa, it's just a matter of creating a snapshot using the StorPool API
14:18:28 <jokke_> Yes, so the Cinder driver has been actually usable for past couple of releases now and utilizing that instead of writing native driver just might get all of us off the hook much easier
14:20:10 <jokke_> Roamer`: Fundamentally I'm not against it as long as we have commitment of the maintenance of that driver and 3rd party CI for it, just thinking that you guys utilizing the framework already built in with Cinder might be easier path to achieve the same
14:20:53 <smcginnis> Roamer`: I agree with jokke_. It's probably worth your time to investigate the cinder/glance use first. Then if that doesn't meet some use case, we should be able to accept a new driver I would hope.
14:20:58 <jokke_> and more of a documentation how to set it up than writing a new driver doing much of the same that your cinder driver does
14:21:55 <Roamer`> my only worry is that from an (admittedly very, very quick) look at the Glance Cinder driver and at the common Cinder driver I don't see any special handling for the case that I mentioned
14:22:27 <Roamer`> if somebody tries to create a volume from an image, where is the code that will notice that this is already a Cinder-backed image and will try to optimize the thing and not transfer the whole data again?
14:22:48 <jokke_> Roamer`: that's in Cinder
14:22:52 <Roamer`> (also taking up space for the whole data again on the Cinder storage backend instead of taking up zero space)
14:23:20 <Roamer`> yeah, sorry, when I said "the common Cinder driver" I meant the Cinder side
14:23:26 <imacdonn> i think it is an interesting use-case actually ... but (off the top of my head) it seems like it'd require some short-circuiting on the cinder side too ?
14:23:37 <jokke_> so when Cinder requests that image, it looks the direct url (as long as it's available for it) and does the magic on it's own end rather that streaming the data back and forth
14:24:38 <jokke_> at least that what cinder guys convinced me to be the case about year ago when we had good heated discussion about this as they wanted to achieve the same
14:25:08 <jokke_> there was lots of backend vendors who wanted to exactly what you are describing
14:25:15 <Roamer`> I'm just now looking at Cinder's cinder/volume/driver.py, and the _copy_image_data_to_volume() function does not seem to do that
14:27:23 <Roamer`> smcginnis, I know that you're not supposed to know all the Cinder code by heart :) but would you have any idea where this is supposed to be implemented?
14:27:36 <Roamer`> (I could also ask in -cinder right now to see if anybody knows)
14:27:37 <jokke_> ok, can you write a spec for us having the cinder approach as alternative solution and lets get some cinder folks chipping in. as that was definitely on the discussions
14:28:35 <smcginnis> Roamer`: Sorry, I haven't had to dig into that area.
14:28:39 <jokke_> I'd just hate us going through all the effort only to get cinder guys telling us year later "You could have just flipped this switch in cinder config and be grand"
14:28:52 <smcginnis> Roamer`: There's probably someone in the -cinder channel that might be able to give us some tips.
14:29:14 <Roamer`> jokke_, I'm not really certain what you mean by "having the cinder approach" - you mean extend the Glance Cinder driver to do that, or extend the Cinder code to do that for Glance images, or something else?
14:29:45 <Roamer`> OK, so it seems that this needs a bit more research at least on my side - many apologies for taking up the meeting time without really doing the basic homework of at least trying the Glance Cinder driver :(
14:30:05 <jokke_> Roamer`: so utilizing the cinder driver and have cinder taking care of the no-transfer-copy on the backend
14:30:06 <Roamer`> I'll look at how things stand and discuss it more in the -glance and -cinder channel and maybe on the mailing list
14:30:34 <Roamer`> apologies again, I believe the meeting may move on to the next topic
14:30:35 <smcginnis> Roamer`: I know others are doing this (pretty sure) so there's probably just some changes needed to your cinder driver.
14:30:57 <Roamer`> smcginnis, thanks, this seems reasonable
14:31:34 <jokke_> Roamer`: no problem ... that's one of the reasons why we get together here every week, to toss around these ideas before we do lots of work to make something happen that just might be already possible
14:31:45 <jokke_> ok next
14:31:56 <jokke_> #topic image lifecycle - hide retired images
14:32:11 <jokke_> belmoreira: you here?
14:32:54 <jokke_> #link https://review.openstack.org/#/c/545397/
14:33:12 <jokke_> #link https://review.openstack.org/#/c/508133/
14:33:29 <jokke_> those are two specs with same subject about this
14:33:55 <jokke_> I'd like to get understanding where we are at this
14:34:06 <smcginnis> Why two?
14:34:11 <jokke_> rosmaita: I saw your comment in there, do you have any insight?
14:34:44 <rosmaita> smcginnis one is a continuation
14:34:54 <smcginnis> OK, I see rosmaita's comment on the one. I agree.
14:34:56 <rosmaita> i think there were some merge problems
14:35:04 <smcginnis> That should just be updated to keep history.
14:35:12 <rosmaita> i think the open issue is discoverability at this point
14:35:27 <rosmaita> jokke_ did you buy belmoreira 's argument that it is necessary?
14:36:36 <rosmaita> i think let's contact  belmoreira offline and get him to attend next week to discuss so we can keep this moving
14:36:42 <jokke_> not really
14:36:49 <jokke_> yeah
14:37:27 <rosmaita> btw, i think we skipped abhishekk 's item #3, or did i fall asleep?
14:37:35 <jokke_> so my problem is, if you have usecase and need to create new instances out of the older version of the image (not just migrations, snapshot etc.) you should not be retiring it
14:38:01 <abhishekk> i thought it will be discussed in open discussion
14:38:13 <jokke_> rosmaita: yes, sorting bug
14:38:14 <rosmaita> sure, but then you have the problem of how to distinguish the preferred image from the usable one
14:38:48 <rosmaita> we can talk more next week, or maybe i should start a discussion on the ML
14:39:08 <jokke_> lets move this back offline as we clearly don't have the full scope nor people needed to have something fruitful out of the few mins we have
14:39:15 <rosmaita> agreed
14:39:19 <jokke_> #topic image stays gueued
14:39:23 <jokke_> abhishekk: go for it
14:39:30 <abhishekk> yup
14:39:41 <abhishekk> I still think the bug is valid, if node_staging_uri is not set explicitly then its default value is file:///tmp/staging/ which ends with / and leads to error unbound local varaible as mentioned in the bug
14:39:52 <abhishekk> #link https://github.com/openstack/glance/blob/acafa76a78578f93629de1dfc47e6de0616f496a/glance/common/config.py#L680
14:40:13 <abhishekk> https://bugs.launchpad.net/glance/+bug/1753964
14:40:14 <openstack> Launchpad bug 1753964 in Glance "Image remains in queued state for web-download when node_staging_uri uses default value" [Undecided,Invalid] - Assigned to Abhishek Kekane (abhishek-kekane)
14:40:55 <imacdonn> Hmm I wonder if my bug is related or not - https://bugs.launchpad.net/glance/+bug/1750892
14:40:56 <openstack> Launchpad bug 1750892 in Glance "Image remains in queued status after location set via PATCH" [Undecided,New]
14:41:57 <abhishekk> imacdonn, I guess your bug is different one
14:42:29 <imacdonn> abhishekk: it seems like stating_uri shouldn't come into play for my case, but the subjects are so similar ;)
14:42:42 <imacdonn> staging*
14:42:47 <abhishekk> imacdonn, right
14:43:21 <abhishekk> so requesting to reconsider it and we can move ahead as short on time
14:43:49 <jokke_> abhishekk: lets discuss this after the meeting ... I might have misunderstood something
14:44:03 <abhishekk> yes
14:44:19 <jokke_> #topic bug squad report
14:44:25 <jokke_> rosmaita: go go go
14:44:29 <rosmaita> ok, we had our first meeting on monday
14:44:52 <rosmaita> it will be bi=weekly, here is the info: http://eavesdrop.openstack.org/#Glance_Bug_Squad_Meeting
14:45:12 <rosmaita> the agenda is listed on that page
14:45:25 <rosmaita> next meeting is monday 2 april at 10:00 UTC
14:45:49 <rosmaita> that's all
14:45:53 <jokke_> k
14:46:09 <jokke_> #topic release update
14:46:29 <rosmaita> we are about one month away from R-1
14:46:39 <rosmaita> just want to remind everyone
14:46:46 <jokke_> yes, which is not a lot
14:47:01 <rosmaita> no, it's actually 3 weeks + 3 days if we release on wednesday
14:47:03 <rosmaita> as we like to do
14:47:20 <rosmaita> so quick reminder of priorities: https://etherpad.openstack.org/p/glance-rocky-priorities
14:47:36 <rosmaita> ok, and we already talked about the glanceclient
14:47:47 <rosmaita> will aim to release 2.10.0 early next week
14:47:53 <rosmaita> out of stable/queens
14:48:15 <rosmaita> that's all
14:48:19 <jokke_> ok
14:48:30 <jokke_> #topic Open Discussion
14:48:45 <jokke_> there was couple of stranglers in the agenda for this slot
14:48:47 <rosmaita> let me switch the order of the 2 items
14:49:05 <rosmaita> i revised my devstack patch: https://review.openstack.org/#/c/545483/
14:49:21 <rosmaita> basically the same as earlier, but the default is to run under uwsgi
14:49:31 <rosmaita> even though we don't actually like that
14:49:40 <rosmaita> but this will give us a config option to run glance correctly
14:49:53 <rosmaita> that we can use in the dsvm functional tests
14:50:06 <rosmaita> and, they can backport it to stable/pike for COA
14:50:30 <rosmaita> spotz can just tell people to put the correct config in local.conf before starting devstack
14:50:47 <rosmaita> i looked into trying to do a reverse proxy thing
14:51:01 <spotz> rosmaita: What I do?:)
14:51:03 <rosmaita> but the problem has to do with grenade using hte uwsgi config ile
14:51:17 <abhishekk> rosmaita, how this will help if we add functional tests in glance?
14:51:19 <rosmaita> spotz : take a look at https://review.openstack.org/#/c/545483/ when you have time
14:51:58 <rosmaita> abhishekk when we define the dsvm job, we use the GLANCE_USE_UWSGI: False as part of the definition
14:52:40 <abhishekk> ok, I will catch you after to understand in detail
14:52:46 <rosmaita> cool
14:52:58 <jokke_> and then we need to define any of the tests that depends on that not to be ran in the uwsgi mode so the grenade doesn't break again
14:53:16 <rosmaita> abhishekk it's for dsvm based tests, our current glance functional tests do not use devstack
14:53:26 <spotz> Nice, thanks rosmaita
14:53:28 <abhishekk> cool
14:53:54 <rosmaita> the other thing i wanted to mention, i think smcginnis actually knows more about
14:54:02 <jokke_> rosmaita: is there possibility to make noop uwsgi config file and fool grenade thinking it's doing what it think it's doing? :P
14:54:52 <rosmaita> jokke_ i thought about that, am not sure, but i figure last cycle i held off too long trying to figure out a good solution that we are not kind of screwed, so just want to get something in now
14:54:52 <abhishekk> :D
14:55:06 <jokke_> rosmaita: totally agree
14:55:10 <rosmaita> then we can get an experimental dsvm functional job going and protect ourselves
14:55:18 <jokke_> lets hope we get this moving forward at least somehow
14:55:24 <bhagyashris> hi, just want to discuss regarding the policy refactor changes: as per the discussion in PTG the changes will first go on new upstream branch right? so just to inform I will contribute for this once the new branch will be created.
14:55:43 <jokke_> bhagyashris: thanks for the reminder
14:55:49 <smcginnis> New branch?
14:55:57 <rosmaita> ??
14:56:01 <jokke_> #action jokke_ Get that policy feature branch created finally
14:56:05 <rosmaita> oh, right
14:56:09 <rosmaita> i forgot all about that
14:56:23 <bhagyashris> jokke_: Thank you :)
14:56:26 <rosmaita> just when i was thinking things could not get more complicated :P
14:56:31 <smcginnis> Are we sure we want to do a feature branch? I've heard those can be more work than they are worth.
14:57:28 <jokke_> smcginnis: we've had success with them before (glare) and I think for this purpose when we're poking heavily on security side of glance it will be worth of the effort
14:57:56 <smcginnis> jokke_: OK. Just a data point, but other projects have moved over to policy in code step by step on master.
14:58:24 <jokke_> smcginnis: this is not policy in code, this is refactoring the whole policy layer of glance to get rid of it
14:58:41 <smcginnis> jokke_: Ah! OK, please ignore me then. :)
14:58:45 <jokke_> and implement the policies closer to the api than the db
14:58:48 <smcginnis> That sounds a little scarier.
14:58:54 <rosmaita> real quick, the last item ... just want people to be careful about some of these mass changes, some people are not testing changes locally before putting up patches those patches
14:58:55 <jokke_> yes
14:59:08 <imacdonn> I have something that I'd at least like to throw out before the end, even if there isn't time to discuss....
14:59:25 <rosmaita> go for it
14:59:25 <jokke_> imacdonn: be quick
14:59:29 <imacdonn> https://review.openstack.org/#/c/554362/
14:59:50 <imacdonn> basically if v1 API gets removed, I'm hosed, because I rely on being able to register images by location on an external http server
14:59:57 <jokke_> ok have a look on ^^ and we can continue discussing it in -glance
15:00:00 <imacdonn> so I need some sort of equivalent with the v2 API
15:00:01 <jokke_> TY all!
15:00:03 <imacdonn> please review
15:00:09 <jokke_> #endmeeting