14:00:06 <nikhil> #startmeeting glance
14:00:07 <openstack> Meeting started Thu Aug  4 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <openstack> The meeting name has been set to 'glance'
14:00:22 <tsymanczyk> o/
14:00:25 <ativelkov> o/
14:00:30 <mfedosin> o/
14:00:31 <dshakhray> o/
14:00:33 <rosmaita> o/
14:00:35 <nikhil> #topic roll call
14:00:56 <nikhil> thanks for joining tsymanczyk ativelkov  mfedosin  dshakhray rosmaita
14:01:04 <kragniz> o/
14:01:15 <rosmaita> and kragniz !
14:01:20 <abashmak> o/
14:01:35 <rosmaita> and abashmak !
14:01:43 <nikhil> rosmaita: that was my passive way of adding names to roll call sheet ;)
14:01:52 <nikhil> anyway, let's get started
14:01:54 <hemanthm> o/
14:01:56 <nikhil> #topic agenda
14:02:02 <nikhil> https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:10 <nikhil> so, we've another day of full agenda today
14:02:32 <nikhil> please keep the updates precise and bring up only important points/links/issues
14:02:50 <nikhil> #topic Glare updates ( mfedosin )
14:03:05 <mfedosin> hi folks
14:03:36 <mfedosin> so, I want to begin with an announcement
14:03:50 <mfedosin> Glare leaves Glance project
14:04:03 <mfedosin> I think it will be better for all
14:04:14 <kragniz> :o
14:04:19 <mfedosin> Unfortunately there was a little confusion between Glance and App-Catalog
14:04:34 <mfedosin> The Catalog must distribute the images as artifacts
14:04:49 <mfedosin> and we need to have the appropriate artifact type for Glare
14:04:58 <nikhil> look at line #63 on the agenda
14:06:27 <rosmaita> mfedosin: is the plan that you will use external location to refer to images stored in Glance?
14:06:55 <nikhil> anyway, I'm not to be a blocker for any development. just want to make sure people take informed decisions and they are collaborative not something imposed on the community.
14:07:05 <mfedosin> DefCore never was against image artifact type in Glare
14:07:44 <mfedosin> rosmaita: sure, it's possible
14:07:44 <nikhil> That's not completely true. Some of the members in the committee still do not like the idea.
14:08:31 <rosmaita> mfedosin: just asking, cause i am wondering about the glare storage backend plans
14:09:00 <mfedosin> Glare will use glance_store
14:09:20 <mfedosin> about external locations
14:09:56 <mfedosin> kairat sent a message to ML and asked opinions about our external locations implementations
14:10:14 <mfedosin> Stuart provided a good feedback
14:10:54 <mfedosin> https://etherpad.openstack.org/p/glare-locations
14:11:01 <nikhil> I thought we decided to write a spec?
14:11:19 <mfedosin> nikhil: what spec?
14:12:28 <nikhil> http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-07-28-14.00.log.html#l-204
14:12:55 <mfedosin> ah, that's right
14:13:00 <rosmaita> nikhil: i think kairat's etherpad is part of the info gathering for the spec
14:13:11 <mfedosin> we haven't defined the final implementation yet
14:13:14 <nikhil> cool
14:13:28 <mfedosin> but yeah there will be a spec for that
14:13:56 <mfedosin> we have to explain people how to work with external locations
14:14:24 <nikhil> time check 3 more mins
14:14:43 <nikhil> what are the outcomes and action items for glare?
14:15:16 <mfedosin> I'll send a leaving message to ML right after this meeting
14:15:28 <nikhil> ok
14:15:30 <mfedosin> and we'll have the formal patches pushed to project-config earlier next week
14:16:11 <mfedosin> appropriate repositories, wiki and lauchpad space for Glare project will be created soon as well
14:16:46 <mfedosin> thanks :)
14:16:50 <nikhil> we need one more email:
14:17:11 <nikhil> one that explains glare's plans to implement images API (and extent to which it will)
14:17:29 <nikhil> and the reasons for it and who is that targetted to
14:17:51 <mfedosin> Glare won't implement Image API
14:18:03 <mfedosin> it will be unified Artifact API
14:18:23 <nikhil> well whatever it is, as long as Images can be created using glare ..
14:18:32 <nikhil> basically, this will go to [openstack-dev] [glance] [glare] [interop] [defcore] and others
14:18:34 <mfedosin> and we'll have image artifact type that will support image related properties
14:18:41 <nikhil> and I will forward it to monty
14:18:56 <dims> nikhil : it's too early for all that
14:19:11 <nikhil> this is because specifically some tc members and infra + osc team did not like the idea for different APIs to exist for Glare
14:19:15 <mfedosin> it's like saying you have special commands for copy-paste Mp3 files on your computer
14:19:24 <nikhil> dims: if this merged just before n-3 is cut, it's not too early
14:19:28 <nikhil> merges*
14:19:42 <nikhil> anyway, we're out of time
14:20:01 <nikhil> if no one sends, I will ask around for any outstanding concerns and send it
14:20:01 <dims> nikhil : Glare won't be part of big tent for a while, there's nothing defined yet, so don't see a problem
14:20:30 <nikhil> We've burnt 50M Calories talking about interop API and the blame shouldn't come on Glace team to not take informed decisions.
14:20:42 <nikhil> dims: that's okay. This is just precautionary.
14:20:47 <mfedosin> you copy-paste all files equally, but only files metadata is different, right? so Glare won't provide Image API
14:20:50 <dims> you can point to the Glare team :) once they get started
14:20:54 <nikhil> Glance shouldn't get any more bad press
14:21:17 <nikhil> Well I don't want others to start thinking we're in the dark.
14:21:37 <nikhil> we're out of time on this topic
14:21:38 <dims> mfedosin  will send email on Glare starting own repo, separate team
14:22:07 <mfedosin> dims: yeah, I've already said it
14:22:17 <dims> ++ mfedosin
14:22:22 <nikhil> dims: ok
14:22:36 <nikhil> #topic Nova v1, v2 updates ( mfedosin )
14:23:02 <nikhil> so, the bug that was preventing snapshots with None for kernerl id was fixed, thanks for mfedosin
14:23:29 <mfedosin> I haven't updated my patch
14:23:31 <mfedosin> sorry for that
14:23:34 <nikhil> but matt R. was investigating further points where Nova could be affected dur to image schema
14:23:44 <mfedosin> correct
14:23:56 <nikhil> mfedosin: I thought the initial patch merged, correct? (the continue one)
14:24:03 <mfedosin> give me 10 minutes and I'll upload new PS
14:24:36 <nikhil> ok, please add me as reviewer to that patch.
14:24:43 <mfedosin> ah, right
14:24:52 <nikhil> anything else, mfedosin ?
14:24:52 <mfedosin> anyway, I have to fix another issue
14:24:58 <mfedosin> no, nothing more
14:25:01 <nikhil> thanks!
14:25:16 <nikhil> #topic Releases ( nikhil )
14:25:34 <nikhil> #info store release 0.16.0
14:25:41 <nikhil> https://review.openstack.org/#/c/348980/
14:25:55 <nikhil> I think we'd be fine on that, but I will double check after the mtg
14:26:06 <dims> nikhil : am on duty today, looks like it needs a new SHA
14:26:13 <nikhil> (the dependencies merged)
14:26:21 <nikhil> dims: so you want the head on master?
14:26:51 <dims> nikhil : that's what you had implied and ttx comment reflected that
14:27:01 <nikhil> some related bumps https://review.openstack.org/350250 https://review.openstack.org/#/c/350192/
14:27:02 <dims> so we are waiting...
14:27:22 <nikhil> dims: I was waiting for those ^ 2 and they merged yday. SO, I was hoping we'd get 0.16.0 today :)
14:27:56 <dims> cool, you know where to find us when the review is updated :)
14:28:07 <nikhil> acl
14:28:09 <nikhil> ack
14:28:12 <nikhil> #info Likely one more store release this cycle to be set for stable/newton during R-7. This will give us one week to test the store in gate and downstream.
14:28:33 <nikhil> please plan your reviews accordingly to be prioritized
14:28:35 <nikhil> hemanthm: ^
14:28:55 <nikhil> #info glanceclient 2.3.0
14:28:56 <hemanthm> nikhil: ack
14:28:58 <nikhil> this is out
14:29:00 <nikhil> #link  https://review.openstack.org/350311
14:29:19 <nikhil> #info Will plan to release final client release to be set for stable/newton during R-7 along with store. It gives us two weeks to test the client.
14:29:30 <nikhil> any issues so far?
14:29:55 <nikhil> ok, moving on
14:29:59 <nikhil> #topic Tasks work_dir spec
14:30:04 <Jokke_> nikhil: sounds good
14:30:15 <nikhil> thanks
14:30:25 <nikhil> (this topic is assigned to me)
14:30:28 <nikhil> https://review.openstack.org/#/c/349174/
14:30:35 <nikhil> just want to get some thoughts on this
14:31:37 <nikhil> some WIP patch is at:
14:31:41 <nikhil> #link https://review.openstack.org/#/c/329394/
14:32:55 <nikhil> #action all: review task work_dir lite-spec and put - or + thoughts on it or on the linked review code
14:32:58 <nikhil> moving on
14:33:12 <nikhil> #topic Update from DefCore midcycle (nikhil)
14:33:30 <nikhil> I'm just gunna copy paste the whole thing line by line for others to read the logs
14:33:46 <nikhil> please keep questions ready for discussion right after (q.s.)
14:33:57 <nikhil> DefCore can't write-off on all 3 different impl. of glance-direct, swift-local, copy-from to be part of upload capability, at least it can't be said to be true yet
14:34:06 <nikhil> Discoverability based API is better than today, good for community and the right way forward at this point. 18 months in the future will tell more about adoption that will be an important factor in describing capability.
14:34:15 <nikhil> For Newton, our MVP should include Discovery API, schema and header changes and direct streaming protocol for bringing data bits into cloud. image conversion and other backend tasks can come later.
14:34:30 <nikhil> The current set of patches need to be resolved for tests, merge conflicts, need to be highly descriptive in their commit message and inline notes, etc. https://review.openstack.org/270980  https://review.openstack.org/267209 https://review.openstack.org/312972 https://review.openstack.org/312653 https://review.openstack.org/308386
14:34:38 <nikhil> A highly placed recommendation of discovery based API for implementing different types of image upload (import , locations, copy-from, etc). This will provide the end users some sane way to know the appropriate way to upload an image to the cloud.
14:34:47 <nikhil> No blockers from DefCore for Glare team to implement Images API but adoption of the API will be key factor in the future. So, Glance team recommends working together on the Images API support and keep wider openstack community in the loop about the design decisions and latest developments. See also, note about discovery.
14:34:55 <nikhil> Session notes from yesterday can be found at https://etherpad.openstack.org/p/DefCoreSummer2016Sprint-ImagesAPI
14:35:00 <nikhil> For more infomation on why the discovery call is important, please read line 61 onward in the above etherpad.
14:35:05 <nikhil> Since discovery is so important, "copy-from" should come from the import based implementation.
14:35:21 <nikhil> any concerns, questions?
14:35:31 <nikhil> Do all know what's coming next?
14:37:12 * nikhil waits for 2 more mins
14:37:47 <Jokke_> nikhil:
14:38:12 * nikhil extends the countdown counter
14:38:26 <Jokke_> I thought they were pretty clear they are not there to push for defenitions of features, but mere documenting them. This sounds pretty much opposite from that
14:38:54 <rosmaita> Jokke_: it is complicated, they want to have it both ways
14:39:12 <rosmaita> they want to influence things so that what's developed will be interoperable
14:39:26 <nikhil> Jokke_: they provide guidelins and give recommendations to the developers. if nothing works out, at some point a decision is made so that the capability is defined in their documentation.
14:40:00 <nikhil> so, working with them gives developers 'some' leeway to implement interoperable things
14:40:24 <Jokke_> tbh, I think this message has been contradicting from the beginning
14:41:04 <nikhil> Jokke_: yes, because openstack community is using defcore platform to influence API decisions on projects
14:41:45 <nikhil> eventually, it's just a platform. the influence is more than defcore -- end users/infra, osc, teams like nova, cinder, heat, horizon, etc.
14:42:00 <Jokke_> nikhil: I do understand that but if they are saying that they're not willing to write off the plans before 18 months, same time if we publish that API we never will be able to get rid of it, I'd say we focus on other things and come back to this in 18 months then
14:42:08 <Jokke_> maybe they can make their mind by that
14:42:20 <rosmaita> Jokke_: it has to be deployed for 18 months
14:42:22 <nikhil> Jokke_: ha, it'a  chicken and egg problem
14:42:27 <Jokke_> meanwhile we can implement for example copy-from to our current workflow ;P
14:42:27 <nikhil> == rosmaita
14:42:34 <tsymanczyk> lovely
14:42:49 <nikhil> defcore can't write off unless things are adopted and feedback is gatered
14:42:50 <Jokke_> rosmaita: I'm fully aware of their workflow :P
14:42:52 <nikhil> gathered
14:43:28 <nikhil> Jokke_: the outcome from yday's meeting was that we absolutely need the discovery platform so that it's the medium for community to accept the different image import workflow
14:43:42 <nikhil> if you read, mark's comments ...
14:44:06 <nikhil> there is a mention that even if the capability isn't written off, discovery will still help on many different levels
14:44:14 <rosmaita> well, i used to be really annoyed by the defcore stuff, but i have come to the realization that they represent pure API consumers of various operator scenarios, so they do have some good input about what will be interoperable
14:44:17 <Jokke_> I maybe just should wirte nice ranting post to the mailing list demanding them changing their project agenda ... that seems to have been common lately ;)
14:44:29 <rosmaita> and we do want interoperability, so that our code will be widely-used :)
14:44:30 <nikhil> so, this effort is no longer DefCore specific
14:44:49 <nikhil> Jokke_: they are in the process of changing their name , as you speak :)
14:44:59 <dshakhray> кооть) пошли есть)
14:45:02 <nikhil> Jokke_: not agenda  though
14:45:22 <dshakhray> i'm sorry)
14:45:40 <Jokke_> rosmaita: well ... it's not like there is lots of options what comes to the image service for OpenStack out there ;P
14:45:49 <nikhil> their undefined guidance was the biggest blocker for us
14:46:06 <rosmaita> Jokke_: looks like one more option was mentioned today :P
14:46:19 <Jokke_> nikhil: that's fair enough and what you are saying we still don't have that
14:46:25 <nikhil> but that can't be solved because that's not what they want us to do. so anyone requesting the interop API needs to settle with our currently planned spec work.
14:47:17 <nikhil> yeah, the very reason I was pushing heavily for Glare to adopt this discovery based Image API and not implement their own
14:47:18 <rosmaita> well, one thing that does bug me is that they seem to feel that image import is a disgusting hack, whereas i view it as elegant and well-designed
14:47:28 <nikhil> was that when tasks API was implemented, people were intially okay
14:47:50 <nikhil> but in the next few summits people planned and executed presentations that ill fated current Tasks API
14:48:20 <nikhil> rosmaita: yeah, we're on disagreement with them at a fundamental level
14:48:29 <nikhil> their process is too stringent
14:48:54 <nikhil> but fortunately, the voice of blaming the image API has become a lot lower now
14:48:58 <Jokke_> well only way to agree with them seems to be implementing one size that fits none and block usage of anything else
14:49:13 <Jokke_> exactly the approach leading us to this discussion in the first place
14:49:22 <nikhil> (vs a few months back, people were all throwing stones at it)
14:49:37 <rosmaita> i think the main problem is that people think of vm images as roughly jpeg sized, whereas the reality is a bit different
14:50:02 <nikhil> Jokke_: yep, you and I are on same page and those were my final words to them. we will be having a deja vu conversations with them after 18 months.
14:50:41 <nikhil> Jokke_: but many openstack influencers are okay with that so, I took it as no issue for Glance and people who want it this way will have to face the blame when that comes.
14:51:35 <nikhil> rosmaita: to me the fundamental problem is considering popularity of deployments as a model to write off capabilties and not the architecture of openstack itself.
14:52:05 <nikhil> and that's where the argument starts to fade off and people disagree so deeply
14:52:18 <rosmaita> nikhil: rem acu tetigisti
14:52:23 <nikhil> and we come to ask ourselves: what is openstack really?
14:52:27 <Jokke_> Can we just ignore them then until they come up with some concrete options and rather just work together with API wg to make sure that what ever we do does not look bat shait crazy to everyone else and move forward?
14:52:45 <rosmaita> api wg is cool with the designb
14:52:48 <rosmaita> *design
14:52:58 <rosmaita> at least they were 6 months or so ago
14:54:20 <nikhil> to be really honest, I think we should do this because we've spent so much energy on this. and in reality this is so much better than having 3 separate APIs. The real benefactors will be infra team , osc and horizon, heat who need copy-from.
14:54:58 <rosmaita> plus, it is elegant and well-designed :)
14:55:08 <nikhil> rosmaita: totally
14:55:13 <nikhil> #topic open discussion
14:55:36 <nikhil> who proposed "Need some eyes on Bhagyashri's proposal for fixing Glance to handle a "oneOf" schema" ?
14:55:42 <rosmaita> me
14:55:46 <Jokke_> nikhil & rosmaita: I do agree, what I'm saying is that we need to stop fooling anyone by claiming that this is done to meet/satisfy/what-so-ever defcore requirements
14:55:50 <nikhil> https://bugs.launchpad.net/glance/+bug/1585917/comments/11
14:55:50 <openstack> Launchpad bug 1585917 in Glance "member-create will raise 500 error if member-id is greater than 255 characters" [Undecided,Confirmed] - Assigned to Abhishek Kekane (abhishek-kekane)
14:55:59 <rosmaita> the bug title is misleading
14:56:15 <rosmaita> this has morphed into how to correct the schema related to image sharing
14:56:16 <nikhil> Jokke_: yes, you should see that sort of a sentiment when I send a ML email about this entire situation
14:56:21 <Jokke_> that's not why we do it, we do it because it will benefit our users and they are the ones who's acceptance we need to buy
14:56:57 * nikhil needs to be afk in the afternoon for some family matter but will be back and write email this evening
14:57:34 <rosmaita> anyway, bhagyashri proposes a fix, but is worried about regression probs
14:57:37 <nikhil> (image locations, copy-from etc. will have a better answer in that email)
14:57:56 <kairat> Jokke_, ++
14:58:22 <rosmaita> so, it would be good to know what other people think, or whether this needs a spec-lite, or what
14:58:40 <nikhil> this looks like a critical or at least high bug
14:58:49 <nikhil> rosmaita: so, prolly no lite-spec
14:59:00 <rosmaita> i think we're going to have to fix it for image import anyway
14:59:13 <rosmaita> current code can't handle "oneOf" schemas
14:59:35 <nikhil> I will have to read through (again as I did only partially last time)
14:59:41 <nikhil> we're out of time
15:00:12 <nikhil> #action all: provide comments on  https://bugs.launchpad.net/glance/+bug/1585917/
15:00:13 <openstack> Launchpad bug 1585917 in Glance "member-create will raise 500 error if member-id is greater than 255 characters" [Undecided,Confirmed] - Assigned to Abhishek Kekane (abhishek-kekane)
15:00:16 <nikhil> thanks all for joining!
15:00:23 <nikhil> have a good one.
15:00:29 <nikhil> #endmeeting