14:00:01 <nikhil> #startmeeting glance
14:00:02 <openstack> Meeting started Thu Jul 14 14:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'glance'
14:00:05 <nikhil> #topic roll call
14:00:12 <tsymanczyk> O/
14:00:17 <jokke_> nikhil: fair enough ;)
14:00:20 <jokke_> o/
14:00:28 <mfedosin> o/
14:00:29 <kragniz> o/
14:00:45 <rosmaita> o/
14:00:59 <hemanthm> o/
14:01:23 <nikhil> #topic agenda
14:01:33 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:42 <nikhil> We've a full agenda today.
14:02:04 <nikhil> Please be concise in your updates and raise any serious concerns on -glance after this meeting.
14:02:05 <itisha> o/
14:02:09 <nikhil> Let's get started.
14:02:17 <nikhil> #topic Glare updates ( mfedosin )
14:02:22 * jokke_ tries to remember last time when we didn't
14:02:26 <abhishekk> o/
14:02:48 <mfedosin> hi
14:03:04 <mfedosin> so, as you may know Glare API spec is merged
14:03:13 <mfedosin> thanks Nikhil for that
14:03:14 <kragniz> woop!
14:03:36 <jokke_> \\o \o/ o// o/7
14:03:58 <jokke_> time to _review_ the code!
14:04:01 <mfedosin> currently we have an agreement that only Heat artifact type will be included in Glare
14:04:37 <rosmaita> i have to say, after reading through the nikhil/mfedosin exchange, i am very concerned about this.  i think glare should have its own database.
14:04:38 <mfedosin> jokke_: we're fixing bugs and I'll update code later today
14:04:45 <rosmaita> we can always merge databases later
14:04:52 <rosmaita> but separating them is much more difficult
14:05:18 <rosmaita> i think that the conceptual arcs of glance and glare are diverging
14:05:22 <rosmaita> that's all from me, though
14:05:25 <mfedosin> Glare has own tables and all artifact will be stored there
14:05:57 <rosmaita> quick question: is there a use case for deploying glare wihtout glance?
14:06:02 <mfedosin> also we had a meeting with Heat team today, we defined their type structure
14:06:31 <mfedosin> It will be published tomorrow
14:06:49 <mfedosin> and when v1 code is merged Heat folks will start to implement POC
14:07:07 <kairat> rosmaita, not sure but maybe app catalog folks would like to have catalog only
14:07:36 <kairat> but they also need to provide list of images in catalog, so it is not defined yet
14:07:38 <mfedosin> kairat: yeah, they will have only glare
14:07:57 <rosmaita> so i wonder whether a separate DB is a good idea?
14:08:03 <rosmaita> why keep the db unified?
14:08:24 <nikhil> rosmaita: I can see where you are going with this
14:08:36 <nikhil> and I think from a operational perspective this makes complete sense
14:08:37 <mfedosin> also, we had discussions with local infra team - they want to integrate glare with Jenkins and store artifacts there
14:08:59 <rosmaita> i think the glare and glance db use cases are quite different
14:09:08 <rosmaita> because you have some artifacts stored in the db, right?
14:09:11 * nikhil thinks that the jenkins mfedosin is talking about is not upstream jenkins
14:09:24 <mfedosin> nikhil sure :)
14:09:27 <rosmaita> i mean the blobs, not the record
14:09:30 <jokke_> let me ask this other way around ... is there any benefits hanving glance and glare sharing single database?
14:09:50 <rosmaita> jokke_: the main benefit was that we were working on the same thing, more or less
14:09:54 <jokke_> nikhil: there is no more upstream jenkins
14:09:58 <rosmaita> but i'm not so convinced of that any more
14:10:12 <nikhil> jokke_: ? gerrit runs on jenkins, no?
14:10:17 <kragniz> not anymore
14:10:25 <kragniz> zuul all the way now
14:10:27 <jokke_> nikhil: nope
14:10:34 <rosmaita> i'm not saying divergence of glance/glare is a bad thing, this is just an observation
14:10:36 <jokke_> zuul take care of everything
14:10:46 <nikhil> ah, my email confused me
14:10:50 <nikhil> thanks for the update
14:11:22 <mfedosin> rosmaita: one thing I want to say about this
14:11:22 <jokke_> rosmaita: I'm not saying that either. I'm asking if glare has already totally separated tables, are there any benefits running these two on the same db?
14:11:32 <mfedosin> we need reliable import in glance
14:11:47 * nikhil stays confused because of name -- Jenkins (Code Review) <review@openstack.org>
14:11:50 <rosmaita> (i know ... i need to shut up and work on import!)
14:11:53 <jokke_> like creating new db is what, 2 lines
14:12:01 <mfedosin> from Glare or from somewhere else :)
14:12:16 <nikhil> rosmaita: but you are working on it via the testing spec for defcore!
14:12:45 <rosmaita> jokke_: my concern is that if we think separate dbs is a good idea, we should do it before v1 of glare
14:12:51 * nikhil sometimes pretends to hide but watches every move of the crowd
14:12:56 <mfedosin> we can postpone this work in Glare and wait for several month
14:12:59 <rosmaita> will be less confusing for operators
14:13:27 <mfedosin> but if it won't be done in Ocata we'll have to start working on import images in Glare
14:13:43 <mfedosin> because customers really want it
14:14:15 * jokke_ is confused now ... what is the link between glance and glare sharing database and glance image import?
14:14:28 * nikhil has been reading mfedosin
14:14:37 * nikhil has been reading mfedosin's mind
14:14:50 <nikhil> jokke_: mike wants to implement images API in glare
14:14:54 <kairat> IMHO, it is good option to have separate dv
14:14:55 <kairat> db
14:14:56 <jokke_> I'd say we're 15min in the meeting ... how about mfedosin you continue your updates and we get back to this on open discussion/ after meeting?
14:15:13 <kairat> ++ to jokke_
14:15:20 <mfedosin> okay :)
14:15:23 <nikhil> jokke_: and that's why I have published those comments on the spec so that community is clear on what's in the plate
14:16:03 <kairat> Current Glare code designed in the way where we can change db interface without big updates
14:16:12 <kairat> so let's proceed with updates
14:16:14 <nikhil> I'd kept about 20 mins for glare today but we can continue.
14:16:37 <nikhil> kairat: it's not about the code, it's about operations that's a big pain.
14:16:38 <kairat> nikhil, sorry, didn't have time to respond them in time
14:16:44 <jokke_> nikhil: I doubt 4 min is enough to clear this ;)
14:16:48 <nikhil> I think we need to have this discussion on a etherpad
14:16:49 <mfedosin> since there are no Nova updates we can skip it
14:17:10 <nikhil> #topic Nova v1, v2 updates
14:17:20 <mfedosin> no nova updates
14:17:26 <nikhil> thanks Mike
14:17:27 <mfedosin> everything works
14:17:43 <nikhil> mfedosin: can we get a status check on nova this week?
14:17:58 <nikhil> let's make sure we've something for the team in the next week
14:18:20 <nikhil> either 'all is working fine, no op for glance' or 'we really need to fix this bug'
14:18:49 <nikhil> Also, we'd keep an eye on their deprecation of Images API
14:18:54 * jokke_ likes this
14:19:05 <nikhil> #topic releases
14:19:25 <nikhil> I've proposed a review for n-2 release (glance)
14:19:45 <nikhil> (a late last night)
14:20:06 <nikhil> once that's approved, the n2 release will be out
14:20:31 <nikhil> but you won't get an email as doug had mentioned that such releases are not announced
14:20:32 <jokke_> nikhil: do you have statistics already for us. How does it look like?
14:20:56 <nikhil> jokke_: I will publish highlights on the n2 and share with the team
14:21:03 <jokke_> nikhil: thnx
14:21:07 <nikhil> also, I will update my newton-2  release notes
14:21:22 <nikhil> as that's not a dependency on the release, it can be done after the release too.
14:21:23 <jokke_> one nice thing that tracking releases in lauhpad did was it gave those stats really easily
14:21:43 <nikhil> yeah
14:22:05 <nikhil> #topic Announcements
14:23:05 <nikhil> We should have the videos of midcycle (two days) and ops sync (one day) and defcore sync (one day), published in the next few days. I've reached out to the resp folks to see them uploaded that can be accessed publicly.
14:23:37 <nikhil> I will plan to release store and client next week.
14:23:58 <nikhil> #action all: ping nikhil on irc if you need a commit included in those releases
14:24:01 <jokke_> yes sorry I forgot the midcycle recordings from the day 2
14:24:41 * jokke_ will sharpen up
14:24:44 <nikhil> np, I too need to free space on my pc to be able to process the ops recording
14:24:53 <nikhil> it's about 1GB
14:25:07 <nikhil> anyway, that's all for announcements
14:25:14 <nikhil> #topic Project mascot
14:25:23 <nikhil> #link     https://etherpad.openstack.org/p/glance-project-mascot
14:25:29 <nikhil> #link https://etherpad.openstack.org/p/glance-project-mascot
14:25:38 <nikhil> Please don't forget to self-vote your proposals
14:25:47 <jokke_> Time to bikeshed folks! Do we want red, green or purple?
14:25:57 <nikhil> #info Please don't forget to self-vote your proposals on the project mascot etherpad
14:25:58 <rosmaita> black!
14:26:07 <kragniz> loris color, deffo
14:26:13 <tsymanczyk> Mauve
14:26:25 <nikhil> Only, the vote count in the proposals will be counted.
14:26:34 <kragniz> tsymanczyk: controversial
14:26:50 * nikhil surprised no one mentioned pink
14:26:55 <jokke_> done
14:27:21 <nikhil> It needs to be a cartoon so the proposals will be a tad diff than what's in the picture.
14:27:53 <nikhil> #info the deadline to vote is Monday jul 18th and I will send top 3 nominations for Heidi to review.
14:28:14 <nikhil> that's all on this from me
14:28:19 <nikhil> questions/comments?
14:28:29 * kragniz starts the media campaign for the slow loris
14:28:31 <jokke_> nikhil: the sooner the better, they are given out first come first served basis ;)
14:28:34 <rosmaita> kragniz: is there such a thing as a fast loris
14:28:41 <kragniz> I hope not
14:28:45 <kragniz> those things have teeth
14:28:51 <nikhil> jokke_: sure :)
14:29:06 <nikhil> jokke_: I see your +2A, but remember there's +3 for strong vote
14:29:26 <nikhil> this voting scheme is taken from voting on oslo proposal for summit and it has worked well for them
14:29:34 <rosmaita> i may have to -3 the slow loris ... we get enough grief from other projects about glance's speed without having "slow" in the name of our mascot
14:30:07 <nikhil> make that two
14:30:10 <hemanthm> how about a sloth then? dones't have the word slow in its name
14:30:24 <kragniz> aw
14:30:30 <rosmaita> hemanthm: you are not helping
14:30:31 * nikhil is thinking on increasing his vote for chipmunks
14:30:50 <hemanthm> rosmaita: sloths are awesome though
14:31:01 <rosmaita> kragniz: if you can get it renamed to "clever loris" i would be ok with that
14:31:02 <hemanthm> and pandas too. But pandas are way too popular
14:31:10 <jokke_> rosmaita: I kind of like the slow loris option after the chipmunk ... community gets what they asked for :P
14:31:50 <kragniz> there's just a regular loris
14:32:11 <kragniz> "Red slender loris
14:32:12 <nikhil> hemanthm: please propose that one, I like that option.
14:32:12 <rosmaita> glance mascot: the regular (not the slow!) loris
14:32:13 <kragniz> "
14:32:19 <hemanthm> how about a bike shed?
14:32:33 <hemanthm> but that's better for Openstack in general I guess
14:32:35 <jokke_> hemanthm: do we have natural bikesheds?
14:32:41 <kairat> hemanthm, lol
14:32:47 <rosmaita> it seems to be a natural condition in openstack!
14:32:51 <kragniz> maybe the openstack logo is a stylized bike shed?
14:32:54 <hemanthm> jokke_: what if we have a wooden bikeshed? :P
14:33:03 <jokke_> hemanthm: I think the OpenStack logo should be changed to bikeshed
14:33:08 <hemanthm> ++
14:33:16 <jokke_> I don't think any project deserves it more than all of them
14:33:20 <rosmaita> yeah, except what color would it be?
14:33:20 <nikhil> I want to propose 'sun' -- you can only glare or glance at it depending on the season /time of day
14:33:34 <kairat> or crutch
14:33:38 <bunting> nikhil: Don't look too long or it could burn your eyes?
14:33:39 <hemanthm> nikhil: that's deep
14:33:43 <kragniz> http://www.ourendangeredworld.com/wp-content/uploads/2013/04/Red-Slender-Loris-large-eyes.png
14:33:54 <rosmaita> your eyes hurt so bad you don't notice that it's slow
14:34:31 <rosmaita> kragniz: we would have to include instructions to the artist that this is NOT the slow loris
14:34:48 * nikhil exclaims great!, is glad the team is bonding on something
14:34:57 <jokke_> first you burn your eyes with the logo and then you get them on tears with the onion layers ... sounds like a plan
14:35:18 <hemanthm> ah, an onion!
14:35:24 <kragniz> tor has that
14:35:32 <hemanthm> :(
14:35:48 <jokke_> kragniz: not onion logo sun logo, we have the onion layers in our design already
14:36:22 <hemanthm> jokke_: that's why it's onion is more appropriate for Glance
14:36:27 <hemanthm> it's innate to Glnace
14:36:50 <hemanthm> Everyone has a soul, Glance has an onion
14:37:06 <kragniz> >You can select a mascot from the natural world
14:37:07 * hemanthm stops his poor jokes
14:37:08 <kragniz> does that imply that things from outside the world are not allowed?
14:37:10 <nikhil> yeah and the onion press publishes quite deep discussions/posts
14:37:59 <nikhil> kairat: nothing artificially produced
14:37:59 <mfedosin> have I already suggested? http://vignette2.wikia.nocookie.net/disney/images/3/3e/Flash_Zootopia.png/revision/latest?cb=20151224194629
14:38:18 <jokke_> kragniz: also in all their creationism they think that humans are not part of the natural world
14:38:25 <nikhil> alright, we need to move on for now
14:38:51 <nikhil> Thanks all for a fun discussion.
14:38:57 <nikhil> #topic Feedback on splitting migrations into expand and contract to get started with rolling upgrades (hemanthm)
14:39:12 <hemanthm> As a precursor to rolling upgrades, how about we start splitting our migrations into expand and contract?
14:39:20 <hemanthm> Essentially, separate additive migrations and everything else so that one would be able to expand the database while the previous version is still running. When I say everything else, I mean it's our non-additive migrations as well as the data migrations.
14:39:37 <hemanthm> We can maybe make glance-manage db_sync do both expands and contracts in succession. That way the current deployments won't change much for the operators but the migrations will in fact be performed in expand and contract manner.
14:39:48 <hemanthm> So, obviously this alone won't get us rolling upgrades. But, this would be the first tiny step.
14:40:00 <rosmaita> (and this is one reason i wonder about splitting the glance/glare dbs)
14:40:31 <hemanthm> Just want to see how folks feel about this
14:40:41 <rosmaita> it is a slender-loris sized step
14:42:39 <nikhil> I like this idea
14:42:40 <kairat> I am personally in favor of this
14:42:57 <kairat> Then we can deprecate registry
14:43:05 <jokke_> with the very little understanding of databases I have I'm in favor
14:43:18 <jokke_> but how that would work on the db versioning?
14:43:20 <kairat> hemanthm, I remember you showed some pdf with explanation of your approach
14:43:47 <kairat> I had some questions because I did not understand how we can do N+1 rolling upgrades with additive migrations only
14:43:57 <jokke_> so one could not keep doing just the expands, but would need to do the "other" part in between
14:43:58 <kairat> hemanthm, could you please re-send it
14:43:59 <hemanthm> kairat: yeah, I'm writing a spec. I should have something up for review in a day or two
14:44:05 <kairat> hemanthm, cool
14:44:38 <jokke_> kairat: darn ... you were tiny bit faster ;)
14:44:42 <hemanthm> jokke_: that's a good point. I have to figure it out.
14:45:10 <dharinic> I read Hemanth's idea on this. And with little prior knowledge, I think its a great approach too.
14:45:14 <hemanthm> jokke_: I know how neutron does it but they use alembic
14:45:51 <hemanthm> jokke_: maybe we could consider each expand and contract migration to be a version
14:46:11 <jokke_> hemanthm: I think that's what we would need to do
14:46:22 <rosmaita> i agree
14:46:22 <jokke_> hemanthm: and do the contract always with the higher version number
14:46:30 <jokke_> and do those only once in a cycle
14:46:48 <hemanthm> ++ jokke_
14:46:59 <nikhil> ++
14:47:50 <hemanthm> one intention to do this now is to give time for all of us get used to thinking in terms of expand and contract
14:47:52 <jokke_> which kind of will make it difficult with the milestones
14:48:52 <hemanthm> jokke_: true
14:48:53 <nikhil> we don't support milestone releases, they are merely development checkpoints and not a produce for full fleged testing
14:49:03 <jokke_> we effectively can do expand until X-3 and then merge the contract between -3 and RC1
14:49:20 <jokke_> but there is no way we can merge and test contracts through cycle then
14:49:27 <nikhil> we need to support release-to-release migrations, that's all
14:50:19 <jokke_> nikhil: we have to support X-2 to X release and if the database says it's version YY and we release X database version YY that must be the same database
14:50:28 <hemanthm> what do you guys think about keeping two db versions? expand version and contract version  vs the one version that we keep now?
14:50:46 <jokke_> we can say that we release Xwith database version YY and YY-1 is expand only which is supported
14:51:10 <tsymanczyk> In what sense? Both read only?
14:52:16 * nikhil finds the grammar hard to comprehend
14:52:27 <hemanthm> nikhil: if you need time to cover other items on the agenda maybe we can take this to -glance
14:52:31 <nikhil> *DB version grammar
14:52:44 <hemanthm> nikhil: whatever I said?
14:53:08 <nikhil> hemanthm: from the looks of it, I may need to refer the spec first to make sense of the support criterion described above.
14:53:09 <tsymanczyk> Desk chair is the big issue with two databases.
14:53:23 <tsymanczyk> desync
14:53:39 <tsymanczyk> thanks autocorrect
14:53:44 <nikhil> :)
14:53:47 <rosmaita> i like "desk chair" better
14:53:48 <hemanthm> tsymanczyk: possibly, I haven't thought this through yet.
14:54:01 <nikhil> #topic open discussion
14:54:06 <hemanthm> maybe I will get a spec going, we can all chime in there
14:54:19 <nikhil> hemanthm: +1
14:54:27 <tsymanczyk> if either are write I'd be really against i
14:54:41 <nikhil> abhishekk: you can go ahead with your topic
14:54:44 <jokke_> I really dislike the multiple versions approach as currently the version tells exactly what the database looks like ... if we start carrying two versions that does not apply anymore
14:55:05 <abhishekk> hi, just need to be sure is lite-specs is ok for this?
14:55:18 <tsymanczyk> if they disagree whichever se correct?
14:55:30 <rosmaita> jokke_: that is a good concern
14:55:48 <nikhil> abhishekk: sure, let's start a lite spec
14:55:53 <tsymanczyk> Jokk_ ++
14:55:54 <hemanthm> jokke_: yep, that's a valid concern.
14:56:11 <abhishekk> nikhil: its already registered in LP https://bugs.launchpad.net/glance/+bug/1525259
14:56:11 <openstack> Launchpad bug 1525259 in Glance "Add request_ids attribute to v2 schemas" [Wishlist,Triaged] - Assigned to Abhishek Kekane (abhishek-kekane)
14:56:11 <nikhil> abhishekk: I see, that's a old version of a lite-spec
14:56:23 <jokke_> abhishekk: helps taking something like that in the consideration if that light spec would be in the commit message as it should
14:56:51 <abhishekk> jokke_: I will add that as well
14:57:04 <nikhil> jokke_: you want a full spec for this?
14:57:12 <abhishekk> nikhil: should I write new lite-specs as per current format?
14:57:30 <nikhil> fyi, we're past our proposal time for full specs for newton
14:57:45 <jokke_> nikhil: not really sure ... IMHO litespec is fine, but I'm not sure if that is enough by your latest specification
14:57:59 <abhishekk> nikhil: hmm I know :(
14:58:06 <nikhil> abhishekk: not sure, but that discussion is quite interesting
14:58:24 <jokke_> I'm more ocncerned about how we tack this issue as we clearly can't just take the x-project approach
14:58:48 <jokke_> and that x-proj approach is the one I -2'd I'm not against the functionality in pronciple
14:58:53 <jokke_> principle even
14:58:59 <abhishekk> jokke_: I will update the existing lite-specs with current approach
14:59:36 <nikhil> for such a verbose, lite-spec you'd have had better attn on a full spec :)
14:59:56 <nikhil> we're out of time
15:00:00 <nikhil> Thanks all for joining.
15:00:06 <jokke_> thanks
15:00:07 <kairat> abhishekk, Does openstackclient provide request-id correctly
15:00:09 <mfedosin> thanks :)
15:00:11 <nikhil> abhishekk: pls update the existing stuff and we can chat after.
15:00:12 <abhishekk> thank you nikhil, jokke_
15:00:14 <kragniz> thanks
15:00:16 <nikhil> #endmeeting