14:00:06 <nikhil> #startmeeting glance
14:00:06 <openstack> Meeting started Thu Jul 28 14:00:06 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <hemanthm> o/
14:00:10 <openstack> The meeting name has been set to 'glance'
14:00:16 <nikhil> #topic roll call
14:00:24 <rosmaita> o/
14:00:27 <hemanthm> o/
14:00:32 <itisha> o/
14:00:33 <kragniz> o/
14:00:41 <mfedosin> o/
14:00:42 <nikhil> welcome all
14:00:47 <nikhil> let's get started
14:00:50 <nikhil> #topic agenda
14:00:54 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:00 <nikhil> we've a full agenda today
14:01:19 <nikhil> so, I have set a recommended time limit to help us plan our conversations properly
14:01:32 <nikhil> please take a look at the agenda etherpad for more details
14:01:41 <nikhil> #topic Glare  ( mfedosin )
14:01:54 <bunting> o/
14:02:02 <mfedosin> hi :)
14:02:17 <mfedosin> I don't know where to start...
14:02:28 <nikhil> I know this one update
14:02:30 <nikhil> #link https://review.openstack.org/347999
14:02:32 <mfedosin> we fixed few bugs in glare code
14:02:51 <Jokke_> o/
14:03:03 <croelandt> \o
14:03:04 <mfedosin> yeah, it was a request from app-catalog community
14:03:14 <mfedosin> to store content-type for blobs
14:03:35 <flaper87> o/
14:03:48 <mfedosin> because as you may know glance supports only application/octet-stream
14:04:05 <nikhil> I think the use case needs to go in the spec
14:04:23 <mfedosin> so, for this reason we had to think off our own content-type when user wants to add a location to blob
14:04:45 <mfedosin> previously it was 'application/json'
14:04:58 <mfedosin> but now we have to differentiate them somehow
14:05:16 <mfedosin> nikhil: there is a use-case in the spec
14:05:40 <mfedosin> initially we wanted to call it application/glare-external-location
14:06:03 <mfedosin> but then I found out that this name is not restful :)
14:06:21 <mfedosin> and now it is application/vnd+openstack.glare-custom-location+json
14:06:37 <sskripnick> this is not looks like separate use-case. User uploaded blob with content-type "image/gif" and other user can see "Content-type: image/gif" when getting this blob
14:07:00 <mfedosin> we were guided by http://restcookbook.com/Resources/using-custom-content-types/
14:07:16 * sigmavirus is late, sorry
14:07:47 <mfedosin> sskripnick: makes sense, I'll add it to the spec
14:08:14 <mfedosin> anyway I'll have to update it, because commit message is wrong...
14:08:30 <rosmaita> i am confused about the 'location' part of the name when it's a content type, or am i confusing 2 different use casees
14:08:44 * nikhil will have to dig into glare spec again..
14:09:04 <sigmavirus> nikhil: me too
14:09:07 <sskripnick> we can avoid custom content-type by using other url for external blobs
14:09:10 <nikhil> :)
14:09:25 <sigmavirus> mfedosin: why not application/vnd+openstack.glare.custom-location+json?
14:09:48 <rosmaita> ok, we can discuss on the spec patch
14:10:02 <nikhil> I like what sskripnick suggests but yes on the spec would be nice
14:10:03 * sigmavirus nods
14:10:07 <sskripnick> like POST /api/artifacts/glance-image/some-uuid/icon/external (with application/json)
14:10:09 <nikhil> 1 min to go on this topic
14:10:24 <nikhil> ouch, that prolly won't work
14:10:26 <mfedosin> the use case is called * **Use Case 8.** Add a custom location for artifact.
14:10:32 <mfedosin> also I wanted to share sskripnick's work with you
14:10:38 <mfedosin> http://r-ci.tk:8100/
14:10:50 <mfedosin> it's app-catalog based on glare v1
14:11:00 <mfedosin> it's very early prototype
14:11:06 <rosmaita> cool!
14:11:12 <mfedosin> but I think it looks good
14:11:13 * nikhil wonders why is 'image' again being referred in glare
14:11:44 <nikhil> excellent, can't wait to see it
14:11:46 <mfedosin> nikhil: because app-catalog wants to distribute images
14:12:01 <mfedosin> it's what we have now http://apps.openstack.org/
14:12:05 <nikhil> so they need to use glance
14:12:16 <nikhil> I am asking why is images being used in glare API
14:12:17 <mfedosin> nikhil: no, they don't
14:12:20 <nikhil> ok
14:12:22 <mfedosin> ask docaedo
14:12:38 <nikhil> well, we WONT support images in glare API
14:12:41 <nikhil> and that was decided
14:12:50 <nikhil> we need to move on the next topic
14:12:55 <nikhil> sorry, this needs further discussion
14:13:06 <nikhil> #topic Nova v1, v2 ( nikhil )
14:13:10 <sskripnick> do we have to use glare to store all artifacts, and something other to store glance images (in app catalog?)
14:13:11 <mfedosin> you work in one company and I think you'll find some strategic vision with docaedo :)
14:14:05 <mfedosin> oh, there was a bug with glance's schemas in Nova
14:14:29 <nikhil> sorry guys, sskripnick , mfedosin  we need to talk offline on this. they can't use images API in glare and that's it. it's not about companies, it's about ecosystem. we
14:14:42 <nikhil> (we're on the next topic)
14:14:51 <nikhil> there's this bug that was causing some pain
14:14:57 <nikhil> #link https://bugs.launchpad.net/python-glanceclient/+bug/1596602
14:14:57 <openstack> Launchpad bug 1596602 in python-glanceclient "Instance Snapshot failure: "Unable to set 'kernel_id' to 'None'. Reason: None is not of type u'string'"" [High,Fix released] - Assigned to Mike Fedosin (mfedosin)
14:15:02 <nikhil> thanks to mfedosin for a quick fix
14:15:08 <mfedosin> I did not have time to finish the second patch today
14:15:11 <nikhil> we've resolved the issue with snapshots
14:15:35 <kairat> o/
14:15:41 <mfedosin> but I agree with Matt
14:15:43 <nikhil> but there could be more places in nova when the additional properties may not be matching schema and nova isn't validating schema
14:16:01 <mfedosin> I'll send the update right after this meeting
14:16:45 <nikhil> if you know people who are using virt drivers and have a test missing by chance, please ask them to negative test that snapshot, update image using nova, etc.
14:17:04 <nikhil> that way we will be able to exhaustively exclude corner cases and avoid last minute hustle
14:17:42 <nikhil> otherwise, we're looking good on nova using v2. and they've deprecated the proxy for images as per my last read on the ML email.
14:18:05 <nikhil> I will try to find time to propose the v1 deprecartion spec as it overlaps with some other work. more on this next week.
14:18:21 <nikhil> moving on
14:18:25 <nikhil> #topic Releases  ( nikhil )
14:18:47 <nikhil> I was able to get glance_store 0.15.0 released this week
14:19:03 <nikhil> the 0.14.0 caused issues in gate and has been blocked in g-r u-c
14:19:24 <nikhil> we need a couple more of store releases this cycle
14:19:35 <nikhil> especially one that includes the removal of s3
14:19:55 <nikhil> you can find more updates:
14:19:59 <nikhil> https://bugs.launchpad.net/glance-store/+bug/1605648
14:19:59 <openstack> Launchpad bug 1605648 in glance_store "help text string on config fails translations and breaks glance docs" [Critical,Confirmed]
14:20:00 <Jokke_> so that sohuld be a big one 1.0.0?
14:20:09 <nikhil> https://bugs.launchpad.net/glance-store/+bug/1606746
14:20:09 <openstack> Launchpad bug 1606746 in glance_store "cinder driver config string with %(tenant)s breaks glance gate and is preventing further store release" [Critical,Fix released] - Assigned to Nikhil Komawar (nikhil-komawar)
14:20:21 <nikhil> https://review.openstack.org/#/c/347595/
14:20:40 <nikhil> I plan to release one right after removal of s3 is merged
14:21:02 <nikhil> Jokke_: last time we removed one driver it was a minor bump
14:21:06 <kairat> I think we need to refactor store api a bit before releasing 1.0
14:21:18 <nikhil> our 1.0.0 is expected after the api refactor
14:21:19 <Jokke_> nikhil: oh we did
14:21:47 <mfedosin> I liked s3, even if it didn't work well :(
14:21:50 * Jokke_ tought that backwards incompatibilities were major
14:22:11 <mfedosin> agree with kairat, only after the refactoring
14:22:16 <Jokke_> or was it agreed minor due to the 0. series versioning still?
14:22:44 <nikhil> I will check the semver docs and see what comes up
14:23:04 <nikhil> will share the details before proposing a release and add Jokke_ to that review q.s.
14:23:07 <Jokke_> anyways, fortunately version numbers are cheap
14:23:13 <Jokke_> :D
14:23:17 <nikhil> :)
14:23:38 <nikhil> so the release of client libs is earlier than n-3
14:23:53 <nikhil> please prioritize your reviews on store first, then client and server
14:24:03 <nikhil> that's it from me on this topic
14:24:33 <nikhil> moving on
14:24:36 <nikhil> #topic Project Mascot  ( nikhil )
14:24:56 <nikhil> So, congrats all: our mascot has been selected
14:25:05 <nikhil> illustrator has been given details about the same
14:25:24 <nikhil> #info Email confirmed Chipmunk as selected mascot for glance
14:25:32 <nikhil> Note sent to ask the designer to ensure that the chipmunk is shown chewing nuts
14:25:40 <nikhil> Illustrations will include text and logo, another with just logo and one with just text.
14:25:42 <Jokke_> \\o \o/ o// o/7
14:25:50 <nikhil> tentatively available before summit for team to use in their presentations
14:26:03 <rosmaita> we need an ascii art version too, so we can put it in specs
14:26:09 <hemanthm> haha
14:26:10 <nikhil> ha
14:26:39 <Jokke_> rosmaita: ++
14:26:40 <nikhil> I think that would not be official unless our default one is in ascii
14:26:48 <Jokke_> rosmaita: and release commit messages
14:26:49 <nikhil> but that would mean everyone needs to choose that way
14:26:55 <nikhil> which is right hard to get
14:27:02 <nikhil> s/right/rather/
14:27:02 <rosmaita> we need to send a strongly worded message to the TC saying we must have ascii art
14:27:27 <nikhil> awesome :)
14:27:34 <Jokke_> flaper87: get it done
14:27:34 <nikhil> moving one in the interest of time
14:27:45 <nikhil> #topic Alembic for Glance migrations (hemanthm)
14:27:54 <hemanthm> Last week we spoke briefly about moving glance migrations to alembic.
14:28:03 <hemanthm> I'm working on a PoC to port the migrations over to alembic.
14:28:15 <hemanthm> While I have a couple of things to discuss related to it, let me first see if there are any comments/concerns/suggestions from last week.
14:28:39 <hemanthm> (since we didn't get enough time in last week's meeting to discuss this)
14:29:02 * nikhil finds link to last weeks mtg
14:29:05 <Jokke_> hemanthm: one quick one
14:29:09 <nikhil> http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-07-21-14.00.html
14:29:38 <nikhil> rather:
14:29:40 <nikhil> #link http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-07-21-14.00.log.html#l-253
14:29:42 <Jokke_> hemanthm: will we need to have both, sqlalchemy to do versions until now and then alembic taking care from that, or migrate all our current ones to alembic?
14:29:57 <hemanthm> Jokke_: the latter
14:30:11 <hemanthm> essentially replacing migrate with alembic
14:30:48 <Jokke_> that needs to be well tested between all supported version bumps then that we get same results
14:31:02 <hemanthm> Jokke_: absolutely
14:31:39 <hemanthm> and this sort of leads to the first thing I wanted to discuss today
14:31:44 <hemanthm> Since we are taking a fresh look at the migrations, how about starting directly with the kilo schema?
14:31:49 <hemanthm> Is there any reason we would like to preserve the previous migrations?
14:31:52 <nikhil> hemanthm are you planning ahead for ocata?
14:31:58 <hemanthm> nikhil: yes
14:32:03 <nikhil> k, ty
14:32:11 <hemanthm> not planning on getting this one into newton
14:32:35 <hemanthm> just trying to keep it ready when Ocata opens
14:32:45 <hemanthm> that way we can use that for Ocata migrations
14:32:46 <nikhil> hemanthm: we would like to preserve old style migrations for stable branches
14:33:08 <hemanthm> yes, so starting from kilo should be fine right?
14:33:40 <nikhil> atm, I think so but need to ask around if there're any concerns
14:34:10 <nikhil> basically, we/openstack support n, n+1 so that way it's acceptable
14:34:24 <nikhil> not sure what happens when someone jumps a migrations and what our message needs to be
14:34:44 <nikhil> s/jumps a migrations/jumps a cycle/
14:34:51 <rosmaita> i don't think we support skipping releases?
14:34:55 <hemanthm> (FYI) Neutron did the same thing, they started with kilo as a base and ported migrations from there on to alembic
14:34:59 <nikhil> we dont
14:35:03 <hemanthm> yeah, we don't
14:35:16 <rosmaita> though i noticed that someone proposed a talk about how to skip releases in openstack
14:35:23 <rosmaita> so everyone vote it down!
14:35:27 <rosmaita> (if you can find it)
14:35:28 <nikhil> but that's not stopping someone fromo doing that and if a big corporation does it
14:35:57 <nikhil> does it ... you reflected my exact thoughts above ( rosmaita )
14:36:04 <rosmaita> that's true, it's open source, people can do anything
14:36:15 <rosmaita> but they shouldn't!
14:36:48 <nikhil> hemanthm: any other important point? ( 3 more mins)
14:36:56 <hemanthm> yes, just one more
14:37:04 <hemanthm> How about dropping downgrades altogether?
14:37:20 <nikhil> just review the proposal already
14:37:28 <nikhil> spec is approved iirc
14:37:37 <hemanthm> I mean, not porting over the downgrades to alembic
14:37:48 <nikhil> #link https://review.openstack.org/229220
14:38:01 <rosmaita> just need to check when openstack stopped supporting downgrades
14:38:06 <rosmaita> hopefully it was in kilo
14:38:12 <nikhil> oh well, for now we can go with that. let's see what people think.
14:38:57 <hemanthm> sure, not porting downgrades for now then
14:39:09 <hemanthm> that's all from me on this topic
14:39:24 <nikhil> #link http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html
14:39:40 <nikhil> thanks hemanthm , we finished this one on time
14:39:44 <nikhil> #topic What to do about alernative location strategies? (rosmaita)
14:39:51 <rosmaita> OK, i will try to be brief about this.  We are talking about:
14:40:00 <rosmaita> #link https://review.openstack.org/#/c/336761/
14:40:08 <rosmaita> Here is what is at issue, it is associated with multiple image locations
14:40:15 <rosmaita> We have a config setting that allows you to specify a location_strategy to use
14:40:25 <rosmaita> Glance comes with 2 strategies
14:40:32 <rosmaita> Operators have requested some more and actually submitted patches for some, here is an example:
14:40:39 <rosmaita> #link https://review.openstack.org/#/c/268865/
14:40:53 <rosmaita> (i am typing as fast as i can)
14:40:58 <rosmaita> A change was made at some point as part of refactoring to use oslo_config better that restricted the value of the config option to the 2 pre-packaged ones
14:40:59 <nikhil> rosmaita: np, you
14:41:04 <nikhil> you have 9 mins
14:41:14 <rosmaita> But the location strategy code uses stevedore to load the modules and figures out what strategy names are available from that way
14:41:25 <rosmaita> So it looks like this functionality was designed to be easily extensible by operators
14:41:32 <rosmaita> But, the original blueprint (pre-spec days) does not explicitly say that
14:41:41 <rosmaita> Further, as Jokke_ points out on the patch, the image locations present security problems even when used properly
14:42:02 <rosmaita> But, if you look at the proposed new location strategy on review 268865 (link above), you can see that any customized policy is going to be very idiosyncratic to each deployment.
14:42:15 <rosmaita> The one on that patch is designed to be general, but you can see that in one of the comments, I tried to see how it would work, and it is very tricky.
14:42:23 <rosmaita> I think the deployment who proposed it will get it to work OK, but difficult for others
14:42:34 <rosmaita> Anyway, the point is: what is our attitude toward this kind of thing?  Do we want to make operators submit new location strategies as patches to Glance and only allow ones that make it through Glance code review?  Of just make them fork/patch Glance if they want a custom strategy?
14:42:56 * rosmaita takes deep breath
14:43:04 <nikhil> thanks
14:43:21 <nikhil> I did not digest the issue Jokke_ poised on the location stuff to be used with strategy
14:43:42 <kairat> same for me
14:43:53 <kairat> what is security issue with stevedore?
14:43:58 <nikhil> may be we need to discuss deprecating the multiple locations config option and use policies by default?
14:44:00 <nikhil> #link https://review.openstack.org/313936
14:44:09 <kairat> I know that Heat used it for custom resources
14:44:29 <nikhil> if the strategy be used by admins, we won't have serious issue (no more than what exists in nova, ironic, etc)
14:45:29 * nikhil puts this review on his priority list
14:45:29 <Jokke_> so if we decide to open the location strategies to the wild, IMO we encourage to utilize the multiple locations options (the strategies really doesn't make any sense without them)
14:45:45 <kairat> ah
14:45:47 <Jokke_> And that opens up the can of worms we have tried to patch over 2 cycles now
14:46:13 <nikhil> if that's the case:
14:46:18 <nikhil> I think we need to take a stand either:
14:46:28 <nikhil> 1) remove this feature in glance where you can set custom locations
14:46:51 <kairat> now it is more clear, thanks
14:47:09 <nikhil> 2) document clearly how this is for admins only and what repercussions are when they use it
14:47:40 <nikhil> since a lot of the teams are asking for this feature like fast snapshots in nova, I was inclining towards 2)
14:48:03 <nikhil> the use case proposed by Jake Yip with his complex strategy is for (Again) ceph based use case
14:48:17 * Jokke_ could imagine that limiting it admin only will probably kill most of the use cases for this functionality
14:48:22 <nikhil> (where resiliency of swift is having competition of performance of ceph)
14:48:30 <nikhil> s/of/with/
14:48:35 <mfedosin> nikhil: Can you to provide feedback http://lists.openstack.org/pipermail/openstack-dev/2016-July/100040.html
14:49:01 <Jokke_> anyways, I think this is seriously matter of spec, not a bug fix
14:49:12 <kairat> ++
14:49:14 <mfedosin> I got a lot of requests from Horizon and they don't know what to do with locations
14:49:31 <Jokke_> mfedosin: tell them to stop using them ;)
14:49:34 <nikhil> mfedosin: I will, just that I find it tiring to type the same things :) these teams have asked for feedback earlier and haven't paid attn.
14:49:40 <Jokke_> the best solution ever
14:49:54 <kairat> maybe redesign it
14:49:57 <kairat> ?
14:50:05 <rosmaita> ok, so what do we want a spec to be about?
14:50:26 <nikhil> kairat: and fei long: please work on a redesign or workaround for this together. we can review your work on a spec. works?
14:50:47 <nikhil> rosmaita: yeah, I think that's a good question:
14:50:52 <kairat> I can help with consultation for fei long
14:50:53 <mfedosin> Jokke_: not to use glance? :)
14:51:03 <kairat> since I was involved in glare implmentation
14:51:04 <nikhil> it should include:
14:51:05 <Jokke_> rosmaita: the use cases, what option we do have reaching them and their impact/dependency of the multiple locations access
14:51:21 <nikhil> 1) fei long's use case as a subset of use cases for image location
14:51:23 <Jokke_> mfedosin: good luck with that, but not use custom locations
14:51:40 <hemanthm> it feels like we just shouldn't encourage any changes to location strategy before figuring out the locations issue
14:51:49 <Jokke_> hemanthm: ++
14:51:49 <nikhil> 2) concerns poised by image locations (PLEASE DO NOT LINK PRIVATE BUGS UNLESS YOU CONSULT glance-core-sec)
14:52:01 <hemanthm> be it a spec or bug fix
14:52:02 <mfedosin> Jokke_: users will be disappointed
14:52:03 <nikhil> 3) workaround or a redesign
14:52:13 <kairat> Jokke_, what if we validate checksum and size when uploading location
14:52:20 <kairat> and make them trully external
14:52:26 <mfedosin> they won't have copy-from and custom-locations
14:52:27 <Jokke_> hemanthm: that's why I'd like to see the spec there so we have at least some of the multiple locations needs documented when we try to fix the issues
14:52:35 <mfedosin> but what to do with Heat?
14:52:46 <Jokke_> mfedosin: send them some comforting pictures of kittens
14:52:48 <nikhil> mfedosin: we are getting to this point when app-catalog is being given more importance than the standards def-core is trying to set
14:53:01 <rosmaita> ok, so part of this new spec will be to write the spec that does not exist for multiple image locations?
14:53:07 <nikhil> mfedosin: I really want to avoid getting to a situation where we need to involve TC for this conversation
14:53:07 <mfedosin> Heat can't work without setting custom locations
14:53:16 <rosmaita> which i would like, because i have never completely understood them
14:53:23 <nikhil> so either these teams need to work "with" glance or we go to TC
14:53:29 <kairat> Heat can de-precate properties AFAIK
14:53:55 <rosmaita> Jokke_: you mean comforting pictures of chipmunks
14:53:55 <kairat> So it is not a problem to ask them to deprecate location attrs
14:54:01 <hemanthm> rosmaita: I think just explain the need for removing the strategy restriction?
14:54:03 <Jokke_> rosmaita: I'd rather say that this spec might end up depending the multiple locations refactoring, but this spec would definitely provide context for that ... bit of a chicken and egg situation really
14:54:08 <kairat> the problem is what to do with locations=))
14:54:19 <nikhil> at this point we've multiple conversations streams in this meeting
14:54:20 <Jokke_> rosmaita: them as well ... and chipmunks beating kittens
14:54:21 <nikhil> so...
14:54:23 <nikhil> #topic open discussion
14:54:50 <kairat> rosmaita, what about https://review.openstack.org/#/c/273196/
14:55:02 <rosmaita> so does fei long (who is not here) get the action item for the locations spec?
14:55:08 <mfedosin> Jokke_: we have to prepare a collection of kitten pictures we will send to users :)
14:55:17 <kairat> WDYT, can we go with the patch and update the rests after that
14:55:48 <Jokke_> mfedosin: google can help
14:55:57 <rosmaita> kairat: good question
14:56:10 <kairat> I think our tests are quite stable
14:56:36 <kairat> so we can rely on them
14:56:50 <rosmaita> i haven't run the code coverage
14:56:56 <rosmaita> are all the changes covered?
14:57:32 <kairat> I hope so, additionally, we have reviewers
14:57:35 <nikhil> croelandt: you want more update on your topic proposed?
14:57:37 <rosmaita> my point isn't just about this particular patch, i think we (glance) should have a policy about making these type of changes
14:57:52 <kairat> why don't we rely on reviewers here?
14:58:05 <croelandt> nikhil: yep
14:58:09 <kairat> it is possible to make an error in any patch IMO=)
14:58:15 <nikhil> rosmaita: fwiw, I am with the proposal there
14:58:20 <croelandt> We're currently not making much progress on the image import refactorign
14:58:34 <nikhil> I would use the words carefully
14:58:34 <croelandt> flaper87, Jokke_ and I were wondering if we could release an MVP
14:58:36 <rosmaita> kairat: sure, but these are patches where there are a bunch of copy-and-paste changes, it is really easy to miss something
14:58:44 <croelandt> and if so, what exactly this MVP could be
14:59:06 <nikhil> I think it was decided at the summit
14:59:28 <croelandt> yeah, but things seem to have changed a bit since then
14:59:32 <nikhil> I can arrange a virtual hangout next thursday for us to discuss this
14:59:45 <nikhil> (btw, we're out of time)
14:59:54 <nikhil> let's carry over to #openstack-glance
14:59:57 <rosmaita> +1 for virtual hangout on image-import
14:59:59 <croelandt> nikhil: sure
15:00:01 <nikhil> #endmeeting