14:00:33 <rosmaita> #startmeeting glance
14:00:34 <openstack> Meeting started Thu Oct 13 14:00:33 2016 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:38 <openstack> The meeting name has been set to 'glance'
14:00:39 <nikhil> o/
14:00:44 <tsymanczyk> \o
14:00:47 <rosmaita> #topic roll call
14:00:47 <liwei> o/
14:00:48 <kairat> o/
14:00:52 <nikhil> o/
14:00:52 <hemanth> o/
14:00:54 <abashmak> o/
14:00:55 <tsymanczyk> \o
14:00:55 <dharinic> \o
14:01:08 <tsymanczyk> now the wave \o/
14:01:14 <rosmaita> good turnout!
14:01:16 <rosmaita> #topic agenda
14:01:17 <rosmaita> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:48 <rosmaita> nikhil: kairat: please respond to myu email about coresec at your earliest convenience
14:01:58 <rosmaita> #topic updates
14:02:21 <rosmaita> #topic update: import refactor
14:02:23 <kairat> rosmaita, ok
14:02:28 <rosmaita> kairat: ty
14:02:53 <rosmaita> nothing much to report, we had a productive sync on tuesday
14:03:17 <rosmaita> meeting was logged, so please look at the log if you're interested
14:03:26 <rosmaita> and this is where i should post a link
14:03:55 <rosmaita> #link http://eavesdrop.openstack.org/meetings/image_import_sync/
14:04:15 <rosmaita> that's all from me about that
14:04:25 <rosmaita> #topic update: community images
14:04:33 <rosmaita> tsymanczyk: you have the mic
14:04:50 <tsymanczyk> there's a lot to say but if everyone stays calm we'll get through it it's not that bad
14:05:08 <rosmaita> and please hold your applause for the end
14:05:11 <tsymanczyk> the first patchset is essentially finished, a lot of great feedback, all integrated
14:05:16 <tsymanczyk> i don't mind interrupting applause
14:05:31 <tsymanczyk> the second patchset is down to 8 failing tests which should be easy to solve this week if not today
14:06:07 <tsymanczyk> now the "downside". last week's sync rosmaita mentioned an idea that i'd been putting off thinking of - that 'shared' possibly should be the default value going forward
14:06:27 <Jokke_> o/
14:06:48 <tsymanczyk> and working on the second patchset and finally  having to think about it - i agree. it make a lot of things better, and just in the "it really makes the code cleaner" way i believe it's the correct paradigm
14:06:53 <tsymanczyk> so that left me with two choices
14:07:14 <tsymanczyk> either the first patchset alters the table with private as teh default, and then the second patchset alters the table again changing just the default
14:07:27 <tsymanczyk> or i just go and do the table alteration in the first patchset, leaving shared as teh default
14:07:45 <tsymanczyk> note that this doesnt actual "harm" the first patchset's functionality as the backend always just treated that column as either public or not public
14:07:51 <tsymanczyk> as per the original paradigm
14:08:06 <tsymanczyk> this has resulted in one of the jobs failing because nova doesn't understand "shared"
14:08:18 <tsymanczyk> so currently jenkins is -1ing the first patchset even though it's fine
14:08:43 <tsymanczyk> but that's a problem we were going to have to deal with anyways, when that "would be" implemented with the second patchset
14:08:48 <Jokke_> So how it is ok of Nova fails on it?
14:08:53 <tsymanczyk> so there's pretty much two ways forward that i can see
14:09:06 <Jokke_> s/of/if/
14:09:17 <tsymanczyk> nova is failing on it because it's seeing images come back as "Shared" which is what we intended and would've been the end goal with the 2nd patchset
14:09:32 <rosmaita> is the problem that nova is using a versioned-object for the Image?
14:09:34 <tsymanczyk> "in the end" this is a failure that is going to happen regardless.
14:09:55 <rosmaita> we probably need to update the Image object in nova to accept the new visibility values
14:09:59 <Jokke_> tsymanczyk: ah, gotcha
14:09:59 <tsymanczyk> the nova api log complains about 'shared' not being one of 'public' or 'private'
14:10:12 <tsymanczyk> anyways, there are two way forward
14:10:24 <nikhil> looks like a v1->v2 feature gap
14:10:47 <rosmaita> nova should be using v2 in master, though
14:10:47 <tsymanczyk> i can either back out my 1st patchset change, it can remain public/private, and we can have the literal noop firstpatchset pass 100% and be integrated and the second patchset does the dirty with a rather pointless default-value schema change
14:10:57 <tsymanczyk> or i can collapse the two changesets into one
14:11:07 <Jokke_> yeah, I though we've had shared already. So our shared image status was actually never tested?
14:11:07 <nikhil> rosmaita: yes it does
14:11:15 <tsymanczyk> because if you look at the difference between teh two, the second really doesn't change much functionality.
14:11:25 <rosmaita> Jokke_: no, never had 'shared' as actual 'visibility' value
14:11:37 <tsymanczyk> i can't think of a reason to keep them seperate anymore beyond "We want to be able to say the 1st  one passes 100%" for some reason.
14:11:48 <tsymanczyk> yeah, shared images are exposed as 'private'.
14:11:56 <Jokke_> oh ffs
14:12:32 <Jokke_> pardon my french
14:12:35 <tsymanczyk> going forward my preference is to collapse them into one unless someone else (rolling upgrades?) would benefit from keeping them separate and the rather weak 2nd schema change.
14:12:43 <tsymanczyk> that is all i have to say
14:12:52 <tsymanczyk> please remember and join the sync friday 9am  pst if you want to yell at me
14:12:58 <tsymanczyk> also i'll be on irc most of the day
14:13:02 <rosmaita> yes, a design decision that has come back to bite us in the derriere, pardon my french also
14:13:16 <tsymanczyk> but the takeaway is this is almost done
14:13:24 <tsymanczyk> 8 unit tests to fix, then "the new" unit tests to add
14:13:27 <tsymanczyk> there's light, people.
14:13:27 * rosmaita applauds
14:13:38 <Jokke_> tsymanczyk: I don't see you being responsible for another past feck up
14:13:58 * sigmavirus apologizes for being late
14:14:32 <rosmaita> tsymanczyk: can you paste the nova api error you're seeing somewhere?
14:14:34 <Jokke_> tsymanczyk: I'd say well done ... looking ofrward to have these fixed. Now how we address this backwards incompatibility towards nova
14:14:34 <tsymanczyk> beyond fixing the code i have no idea how to move forward. this nova coordination thing is goign to be a drag i asume.
14:14:43 <tsymanczyk> yeah sure one sec
14:14:47 <rosmaita> i suspect it's a versioned object problem
14:15:34 <rosmaita> #action rosmaita to look into what's necessary nova-side for image viz change
14:15:39 <tsymanczyk> https://www.irccloud.com/pastebin/ma0Gnh8j/
14:15:45 <rosmaita> thanks!
14:15:49 <sigmavirus> rosmaita: solved by a versioned object approach or casued by v.o.s?
14:15:58 <rosmaita> sigmavirus: both, i guess
14:16:39 <rosmaita> i'm pretty sure nova already uses a versioned object to represent an Image
14:16:39 <tsymanczyk> but i want to reiterate, if anyone sees benefit from my unbreaking the first patchset and doing a secodn migration that's fine i'm happy to do it.
14:16:56 <tsymanczyk> just left on my own i'd collapse them to one and walk away.
14:17:16 <rosmaita> let's talk about that at tomorrow's sync
14:17:53 <rosmaita> community images sync: 16:00 UTC in #openstack-glance on friday
14:18:05 <rosmaita> any questions, comments for tsymanczyk ?
14:19:11 <rosmaita> ok, moving on ... i just took the liberty of moving agenda items around
14:19:18 <rosmaita> #topic design summit
14:19:32 <rosmaita> #link https://etherpad.openstack.org/p/ocata-glance-summit-planning
14:19:44 <rosmaita> i've scheduled the Glance design sessions
14:19:55 <rosmaita> but not yet permanently
14:20:09 <rosmaita> anyway, session leaders, please check for conflicts
14:20:25 <rosmaita> i checked, but only for obvious conflicts
14:20:39 <rosmaita> flaper87: flwang: Jokke_: ^^
14:21:18 <rosmaita> i will send out an email a bit later to the ML and cc session leaders for final approval before updating the actual summit schedule
14:21:37 <rosmaita> i want to add some "expected outcomes" to each session first
14:21:46 <rosmaita> one thing i want to emphasize
14:21:55 <rosmaita> we won't have a session on rolling upgrades
14:22:13 <rosmaita> mainly because the key people working on them won't be present at the summit
14:22:36 <rosmaita> as mentioned last week, we will have a video session about rolling upgrades shortly after the summit
14:22:40 <Jokke_> is there CP session for that?
14:22:46 <rosmaita> there is
14:22:59 <rosmaita> and there's also one or two main summit sessions
14:23:01 <Jokke_> need to make a note to be there
14:23:07 <rosmaita> (main == not design summit track)
14:23:27 <rosmaita> Jokke_: that's a good point
14:23:36 <rosmaita> the cross-project sessions have been scheduled
14:23:42 <rosmaita> i think they're pretty much all tuesday
14:24:02 <rosmaita> i think this is the link
14:24:06 <rosmaita> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Cross%20Project%20workshops%3A
14:24:21 <Jokke_> rosmaita: yeah I think it was supposed to be in a way that CPs collide as little as possible with project sessions so they are all on same day
14:24:55 <rosmaita> we could try to coordinate like last summit so that glance is represented in various rooms
14:25:09 <rosmaita> but there are so few of us, it might not be worth it
14:25:58 <rosmaita> anyway, summit attendees: please look at the glance design summit etherpad and point out any conflicts
14:26:07 <rosmaita> any questions, comments?
14:27:20 <rosmaita> ok, moving along, then
14:27:23 <Jokke_> lgtm
14:27:29 <Jokke_> so far ;)
14:27:32 <rosmaita> #topic "v2 route doesn't exist"
14:27:34 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1632742
14:27:36 <openstack> Launchpad bug 1632742 in Glance "/v2 route doesn't exist" [Undecided,Triaged] - Assigned to Brian Rosmaita (brian-rosmaita)
14:28:00 <rosmaita> matt riedemann filed this, details are on the bug, but i have a quick question for the community
14:28:28 <rosmaita> the situation is that in the "versions" response
14:28:45 <rosmaita> i mean the response to GET / or GET /versions
14:28:56 <rosmaita> #link http://developer.openstack.org/api-ref/image/versions/index.html?expanded=id1-detail#id1
14:29:12 <rosmaita> key thing to notice is that the href in the links looks like this:
14:29:12 <rosmaita> http://g.os.org:9292/v1/
14:29:12 <rosmaita> http://g.os.org:9292/v2/
14:29:36 <rosmaita> when you do GET http://g.os.org:9292/v1/ , you get an image-list response
14:29:49 <rosmaita> which is a bit weird, but it's legacy behavior
14:30:04 <rosmaita> when you do GET http://g.os.org:9292/v2/ , you get a 404
14:30:20 <rosmaita> which isn't new behavior, but it is a bit odd also
14:30:55 <rosmaita> my question is: we could return a list of v2 versions for GET http://g.os.org:9292/v2/
14:31:09 <rosmaita> but that would change the response code from 404 to 200
14:31:27 <rosmaita> i'm just wondering whether that's a breaking change
14:32:19 <hemanth> it doesn't sound like a breaking change to me
14:32:30 <rosmaita> also wondering whether the endpoint advertised in the "versions" response really has to give you some kind of content with a 200
14:32:46 <rosmaita> or whether it's just supposed to be a starting point for constructing API calls
14:32:51 <nikhil> even if it is (which I think is) this change looks a good one
14:32:59 <Jokke_> well like Sean pointed out the API ref does not claim /v2/ being valid url
14:33:37 <nikhil> is the uri /v2/ or just /v2 ?
14:34:07 <hemanth> any one know what other projects do?
14:34:09 <Jokke_> nikhil: so /v2/ returns 404 and /v2 returns 302 + no content
14:34:23 <nikhil> ah, thx
14:34:58 <stevelle> imo don't return an image list for /v2/ just because v1 does that.
14:35:12 <Jokke_> stevelle: ++
14:35:16 <hemanth> +1
14:35:17 <rosmaita> i agree with that entirely!
14:35:22 <stevelle> what I would expect from /v2/ would be a discovery endpoint that tells me what I can do with v2.
14:35:36 <stevelle> but that isn't on the table right now
14:36:00 <rosmaita> stevelle: you mean like some kind of json home thing?
14:36:08 <stevelle> yes
14:36:23 <Jokke_> redirect to api reference docs
14:36:37 <nikhil> lol
14:36:39 <rosmaita> i missed sean's comment in the bug, otherwise i would have just agreed and not mentioned any of this!
14:37:13 <rosmaita> i think we close as "won't fix" and wait for the api-wg to come to agreement on stevelle 's suggestion
14:37:28 <rosmaita> otherwise, we'll be stuck wiht whatever we return now
14:37:43 <rosmaita> so i think, return 404
14:38:08 <stevelle> +1
14:38:14 <Jokke_> so only change I'd be ok doing atm. to that is to agree that we return the same thing from /v2 and /v2/ being that 404 or 302 without content
14:38:41 <rosmaita> ok, i'll put my position on the bug, if anyone has second thoughts, please go to the bug and register them
14:39:05 <rosmaita> Jokke_: i'm not sure i even want to do that
14:39:08 <Jokke_> what ever it is we have documented the behavior being for either (I'm pretty sure we haven't documented 'em both)
14:39:25 <rosmaita> yes, i think this is undocumented
14:39:43 <Jokke_> if we are undocumented on both, lets not touch it
14:40:34 <rosmaita> i think the current behavior makes sense; it's not documented, but that gives us flexibility in case it makes sense to change the 404 to some kind of content later
14:40:39 <Jokke_> for people like Monty and Matt who like to talk to these APIs via curl, there is the API reference documentation telling them what they can/can't/should do
14:41:54 <rosmaita> ok, works for me ... any other comments?
14:42:30 <rosmaita> ok, one more topic for today
14:42:46 <rosmaita> #topic glance_store (Shared & public images not working with multi-tenant swift backend)
14:42:59 <rosmaita> dharinic brought this up a few meetings ago
14:43:17 <rosmaita> i think she and hemanth have figured out the cause
14:43:25 <rosmaita> and it is a bit unpleasant
14:43:36 <Jokke_> I'm not surprised
14:43:53 <nikhil> publicized images though, some public imgs like admin provided work
14:44:04 <rosmaita> as far as i can tell, image sharing and public image access is broken in the current glance_store if you use swift configured for multi-tenant storage
14:44:17 <Jokke_> and I think the solution for that is document that these 2 wont work together?
14:44:41 <rosmaita> no, they can work together
14:44:53 <nikhil> well the workaround is okay with me
14:45:09 <Jokke_> uuh ... positive surprise for a change ;)
14:45:10 <rosmaita> what can't work together is the swift+config setting plus swift-multi-tenant
14:45:22 <rosmaita> actually, i dont' think we have a workaround
14:45:24 <hemanth> we can even add some validation for glance to not come up if both are configured
14:45:36 <rosmaita> i think there are two separate bugs
14:45:44 <nikhil> k
14:45:51 <dharinic> Yes. cos wift+condif and multi-tenant causes the storage_url to be picked up from the swift config's auth address
14:46:04 <dharinic> swift+config
14:46:14 <nikhil> would be good to get info on the other part of the bug as a second bug
14:47:17 <rosmaita> ok, so bug #1: (or is it a feature request?): Glance should not allow swift+config to be used with multi-tenant-store
14:47:17 <openstack> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 - Assigned to MFauzilkamil Zainuddin (apogee)
14:47:17 <nikhil> dharinic: and why is it difficult to have a workaround that auth url?
14:47:41 <stevelle> lol
14:47:54 <nikhil> heh
14:47:58 * rosmaita can't wait to see what bug #2 is
14:48:10 <nikhil> bug #2
14:48:14 <hemanth> nikhil: should be possible in theory I think but it's just way it is right now
14:48:39 <rosmaita> bug #2 is: there was a change in glance_store to get the swift endpoint from the caller's service catalog
14:48:58 <rosmaita> when the caller is requesting a shared image, or a public image, this isn't going to work
14:49:05 <dharinic> nikhil, I am not sure I understood the question.
14:49:40 <hemanth> bug #2 is caused by a fix to bug #1
14:49:40 <openstack> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 - Assigned to MFauzilkamil Zainuddin (apogee)
14:49:54 <nikhil> I see
14:49:55 <rosmaita> well, a "fix", anyway
14:50:10 <hemanth> "fix" in some sense of the word
14:50:15 <stevelle> we're not setting the right read permissions on the swift container when it writes using multi-tenant-store?
14:50:29 <hemanth> stevelle: no, we are just reading from the wrong account
14:50:47 <Jokke_> rosmaita: first one is defo RFE documenting it is bug "fix"
14:51:00 <rosmaita> stevelle: we try to pull the image from the caller's account, not the actual image owner's account
14:51:03 <hemanth> stevelle: if you created the public/shared image, I'm be looking for that image under my account
14:51:13 <hemanth> *I'd
14:51:17 <dharinic> And just as the bug reporter said, the storage_url obtained from the users context causes it to be bound to the image downloader's project and so the GET fails.
14:51:52 <Jokke_> does swift support symbolic links between accounts? :P
14:51:55 <stevelle> ok, so if trying to read a shared image we don't own we just need to use a different url construction
14:52:08 <stevelle> that makes sense
14:52:29 <rosmaita> so i believe we will need to revert that "fix" to bug 1 in order to fix bug 2
14:52:29 <openstack> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 - Assigned to MFauzilkamil Zainuddin (apogee)
14:52:45 <rosmaita> (thought not using a # would fool it)
14:52:52 <Jokke_> /kb openstack nuf is nuf
14:52:59 <Jokke_> :P
14:53:01 <abashmak> bug1
14:53:06 <rosmaita> and then we will have to release a new glance_store
14:53:22 <stevelle> that seems necessary, regardless
14:54:12 <rosmaita> i want to bring it up here because i'm not sure how we can test this
14:54:42 <rosmaita> our current tests didn't catch it
14:55:07 <rosmaita> #action everyone put on thinking caps
14:55:25 <hemanth> maybe assert the swift url we are reading from?
14:55:25 <Jokke_> Do we have tempest bringing that environment up?
14:55:41 <Jokke_> I think that's the place this could/should be tested
14:55:57 <rosmaita> Jokke_: i think you are correct about that
14:56:16 <rosmaita> but i'm also wondering how many people use multi-tenant-swift-store ?
14:56:32 <rosmaita> anyone here know of anyone who uses it?
14:56:42 <rosmaita> i believe the bug was detected in devstack
14:56:43 <Jokke_> based on how messed up it is and how little we hear about it, I'd say none :P
14:57:13 <rosmaita> i wonder whether i should float a proposal to remove support and see what the reaction is
14:57:43 <Jokke_> ++
14:57:44 <rosmaita> because setting up tempest tests for this would be an interesting exercise, but i don't want it to be pointless as well
14:57:46 <nikhil> let's not do it without a plan
14:58:06 <rosmaita> nikhil: how do you mean?
14:58:10 <stevelle> tempest is the right place for this test
14:58:19 <nikhil> w/o a multi tenant swift store support the evolution for swift backend seems impossible
14:58:35 <Jokke_> nikhil: evolution to what?
14:58:38 <nikhil> storing all images in one account is def a bad practice
14:59:03 <rosmaita> but so is storing it in n accounts where n == number of end users
14:59:08 <nikhil> using the config file you can sanely scale that one account to may be 10
14:59:11 <hemanth> nikhil: with swift+config I think we can store images in multiple accounts
14:59:31 <rosmaita> yes, i think they are different use cases?
14:59:33 <rosmaita> and we are out of time
14:59:41 <nikhil> I don't care
14:59:50 <rosmaita> we'll have to continue this discussion later
14:59:55 <nikhil> but doing it just for the sake of getting reaction doesn't seem fittin
15:00:16 <rosmaita> #endmeeting