15:01:24 <nikhil_k> #startmeeting Glance
15:01:24 <openstack> Meeting started Thu Mar  5 15:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:27 <openstack> The meeting name has been set to 'glance'
15:01:29 <kragniz> o/
15:01:32 <sigmavirus24> o/
15:01:33 <stevelle> o/
15:01:37 <ativelkov> o/
15:01:41 <mfedosin> o/
15:01:49 <nikhil_k> https://etherpad.openstack.org/p/glance-team-meeting-agenda
15:02:02 <TravT_> o/
15:02:02 <nikhil_k> Courtesy meeting reminder: ativelkov, cpallares, esheffield, flaper87, flwang1, hemanthm, ivasilevskaya, jokke_, kragniz, mclaren, mfedosin, nikhil_k, rosmaita, sigmavirus24, sabari, TravT, zhiyan
15:02:03 <ivasilevskaya> o/
15:02:11 <nikhil_k> (for all those not already here)
15:02:22 <rosmaita> nikhil_k: should probably paste that in #openstack-glance
15:02:30 <rosmaita> o/
15:02:33 <kragniz> rosmaita: too late!
15:02:34 <nikhil_k> did too! thanks for the pointer :)
15:03:21 <Olena> o/
15:03:24 <nikhil_k> seems like we've a small agenda but a few other items to be covered nonetheless in today's meeting
15:03:49 <nikhil_k> #topic k3 status
15:04:10 <nikhil_k> (jitter beinb observed, apologize the delay in messages)
15:04:15 <nikhil_k> https://etherpad.openstack.org/p/kilo-glance-k3
15:04:39 <nikhil_k> Please keep a special note on
15:04:41 <nikhil_k> Glance images output sorting in v2
15:04:51 <nikhil_k> that one needs a API minor version bump
15:05:05 <nikhil_k> (for server side changes)
15:05:33 <nikhil_k> TravT_: did we get any more input on https://review.openstack.org/#/c/107676/ ?
15:05:41 <nikhil_k> ativelkov: is blocked on it
15:05:53 <TravT_> Steve spent all afternoon on it.
15:06:02 <nikhil_k> huh :/
15:06:14 <TravT_> he's looking at different ways to handle it
15:06:28 <TravT_> but I guess there isn't a reason to block it
15:06:46 <TravT_> we'll just have to figure out how to make it work.
15:06:47 <nikhil_k> TravT_: ok, thanks. is he on IRC?
15:07:00 <TravT_> no, i'm trying to track him down this morning.
15:07:04 <nikhil_k> TravT_: may be ativelkov and mfedosin can chat with him..
15:07:18 <ativelkov> The idea behind that spec is that it is not exclusive, it's just one way of doing things. If at some point we even decide to do not do them in semver way, then no harm will be done
15:07:30 <nikhil_k> sure, you all please co-ordinate and do let me know so that we can try to get that one in today
15:07:41 <TravT_> the only troublesome part of that is the release tag handling.
15:08:12 <TravT_> but that is a semver issue
15:08:17 <nikhil_k> ativelkov: the thing is pep440 might not be very neat for elastic search style (java code) but may fit in just fine..
15:08:53 <TravT_> steve figured out a way that he thinks will work with queries, but it is kind of ugly.
15:08:57 <ativelkov> nikhil_k: the proposal has some bits reserved - so we may easily (without compatibility breaking) add that pep-440-style pre-release tags easily
15:08:59 <sigmavirus24> nikhil_k: pep440 is ruled out either way
15:09:12 <sigmavirus24> it was an early suggestion that no one has brought up since it was excluded
15:09:41 <nikhil_k> cool
15:09:46 <TravT_> steve just came online...
15:09:48 <ativelkov> i.e. we can do "Linux-compatible semver" (the one Monty has made for pbr) easily using the same data structure
15:10:12 <ativelkov> which is actually a good old semver + pep440-style pre-release tags
15:10:20 <mfedosin> ativelkov, will it be compatible with the standard btw?
15:10:36 <ativelkov> mfedosin: define standard :)
15:10:44 <nikhil_k> ativelkov: makes sense, we'd get to spec then soon
15:10:51 <sigmavirus24> mfedosin: all versioning standards are incompatible with each other. that's the point
15:11:25 <nikhil_k> yep
15:11:48 <nikhil_k> (for approval - if sigmavirus24, rosmaita have time. flavio is not here)
15:11:59 <sigmavirus24> approval of the spec?
15:12:10 <mfedosin> I like how they do things in pbr, if we have the same it'll be good
15:12:15 * sigmavirus24 is working on $WORK things for the most part
15:12:20 <sigmavirus24> mfedosin: that was also ruled out
15:13:07 <jokke_> why pbr was actually ruled out?
15:13:09 <ativelkov> The idea was to add semver (2.0) for now and start adding support for others afterwards
15:13:13 <jokke_> I think I missed that
15:13:15 <sigmavirus24> mfedosin: the conclusion of the spec was to limit the versioning capability to a defined "standard" that subsets of multiple developer communities follow as opposed to a standard that entire communities follow
15:13:33 <sigmavirus24> *entire developer communities
15:13:59 <sigmavirus24> Because none of the discussed versioning systems support every versioning system available (although pbr's semver-pep440 hybrid can sort of work with debian/ubuntu/fedora/etc.)
15:14:35 <ativelkov> jokke_: it was not completely ruled out, but the concern was that it is very openstackish standard, while artifacts are not only openstack things
15:14:42 <sigmavirus24> The need for SemVer is to be able to sort in the database and because it provides constraints on the number of components in the version string
15:15:05 <sigmavirus24> ativelkov: although the early consumers of artifacts will only be openstack from what I'm hearing from Jay Pipes and others
15:15:07 <jokke_> ativelkov: oh? So to whom we're doing this if not OS?
15:15:14 <ativelkov> so we may add pbr support as the second available format
15:15:32 <ativelkov> not only OS
15:16:26 <ativelkov> e.g. Murano is generic Application Catalog, so Murano Applications are written by other developers, not  from OS-community. Probably they are not written in Python
15:16:29 <jokke_> ativelkov: ok, cool. That was actually the reason why I was personally pro pbr as it seems to be "the" OS way ;)
15:17:12 <ativelkov> The services which consume artifacts are OS-services. But the artifacts themselves are not
15:17:29 <ativelkov> even VM Images are not OS-specific stuff :)
15:17:39 <nikhil_k> (about to say)
15:18:37 <ativelkov> There is just a single concern: "version" is a generic artifact property, but we will end up with letting artifact plugin developers to specify their preferred versioning standard. That's fine unless plugin developers decide to change the standard between different plugin versions
15:18:47 <jokke_> ativelkov: but isn't it more important then that the service consumers can deal with our versioning sematics than the actual content of the artifact? (just a thought)
15:19:27 <nikhil_k> jokke_: please remember this is experimental and extensible
15:19:40 <nikhil_k> (though, good to bring it up early)
15:19:47 <ativelkov> jokke_: the semantics (i.e. the actual meaning behind the version) is up to the plugin/service. We only care about sorting and filtering
15:20:11 <ativelkov> unfurtunately different standards have different view even on sorting and filtering
15:21:17 <ativelkov> Anyway, I'll add a spec on the generic extensibility of version field (i.e. some programmatic ways of adding new versioning standards later) - and an implementation of pbr-style versioning based on it
15:21:34 <ativelkov> but that goes to L already
15:22:05 <nikhil_k> ativelkov: thanks! We'd open L after (I think)
15:22:19 <ativelkov> for now we do really need semantic_version to land to global_requirements
15:22:43 <nikhil_k> ativelkov: the issue is we need to wait and see how it's actually being used rather then extending it in that direction now
15:22:58 <sigmavirus24> ativelkov: you'll need to bother requirements-core then
15:22:58 <ativelkov> otherwise all our patches have -1 from jenkins, which is a bit not good
15:23:04 <nikhil_k> yep
15:23:14 <ativelkov> sigmavirus24: I did. They say "we need the spec approved"
15:23:19 <nikhil_k> sigmavirus24: are we doing your BP in K https://blueprints.launchpad.net/glance/+spec/pass-targets-to-policy-enforcer ?
15:23:42 <sigmavirus24> nikhil_k: I'll try to work on it tonight but I have $WORK things to do during the day
15:23:49 <nikhil_k> sigmavirus24: yeah, I posted a comment on that review but later found our dependency with CIS
15:23:53 <sigmavirus24> nikhil_k: we can get a partial implementation in but I'm not sure we'll get everything n
15:24:03 <nikhil_k> sigmavirus24: ok, thanks.
15:24:14 <sigmavirus24> Also there are changes in the queue that make that BP a moving target
15:24:29 <ativelkov> rosmaita: I think the semver spec had a +2 from you, it got removed when I fixed couple of nits. Could you please put it back please? :)
15:24:32 <sigmavirus24> I think it's the CIS changes and the activate/deactivate changes that are currently following the wrong practice
15:24:48 <rosmaita> ativelkov: will do it right now
15:24:58 <nikhil_k> #info From the looks, we _may_ get FFE for CIS, Artifacts
15:25:59 <mfedosin> what about sorting?
15:26:02 <nikhil_k> But we got a thumbs up from API-WG on deactive spec!?
15:26:16 <nikhil_k> (deactivate)
15:26:45 <sigmavirus24> nikhil_k: you got acquiescence that it was Glance's choice to make
15:26:56 <sigmavirus24> elmiko found old examples that worked in your favor
15:27:06 <sigmavirus24> The opinion has changed since then on the ML after Flavio pointed out a few things
15:27:30 <sigmavirus24> So it wasn't approval, it was "We've talked about this for three meetings and every possible solution presented was met with 'No' so we give up"
15:27:50 <rosmaita> sigmavirus24: the vote should have been more carefully worded, then
15:28:05 <rosmaita> this is a big problem if we are going to re-litigate every change
15:28:24 <sigmavirus24> rosmaita: if you're going to decide on something at a summit and simply want a rubber stamp, don't bring it to the API-WG
15:28:43 <sigmavirus24> Also my complaints about activate/deactivate are simply in it using policy enforcer wrong (which I think is leading to this discussion)
15:28:54 <sigmavirus24> (Because currently, everything is using the policy enforcer wrong)
15:28:56 <rosmaita> sigmavirus24: it was very carefully discussed, and the counter agruments were not very convincing.  we can take this offline
15:29:17 <nikhil_k> thanks!
15:29:22 <nikhil_k> kragniz: how about your BP https://blueprints.launchpad.net/glance/+spec/swift-retry-wait ?
15:29:29 <nikhil_k> https://review.openstack.org/#/c/146437/
15:30:17 <mclaren> I think I'm getting some traction on the swiftclient changes
15:30:29 <kragniz> nikhil_k: mclaren is currenly looking at moving that logic into swiftclient
15:30:31 <nikhil_k> mclaren: can we get those -1s removed?
15:30:37 <nikhil_k> kragniz: ah ok
15:30:42 <kragniz> nikhil_k: so that's on hold for a while
15:30:47 <nikhil_k> mclaren: sorry, misunderstood
15:30:55 <nikhil_k> thanks!
15:31:12 <kragniz> I'll -W to make it clearer
15:31:26 <nikhil_k> seems like sabari fixed the tests https://review.openstack.org/#/c/148426/ https://blueprints.launchpad.net/glance/+spec/vmware-store-multiple-datastores
15:31:29 <mclaren> if the swiftclient changes go in we'll still nee[C[C[C[Cd a small bit of work on the glance side
15:31:42 <nikhil_k> mclaren: that's happening in K?
15:32:15 <mclaren> Dunno. The changes need to merge and a new swiftclient release too
15:32:36 <mclaren> (I'd like it to though)
15:32:46 <sigmavirus24> It's too early for notmyname to be up probably but we should see if swift can tell us the feasibility of that
15:33:45 <jokke_> mclaren: that's to get the config options passed to the swiftclient, right? (the glance change needed)
15:33:55 <mclaren> If the changes go in we can also potentially simplify the CooperativeReader fix
15:34:12 <kragniz> jokke_: yes, that would happen in glance_store
15:34:19 <mclaren> jokke_: removal of the retry_iter
15:34:21 <nikhil_k> hmm
15:34:32 <kragniz> then a glance patch to add to the default config
15:34:46 <jokke_> I don't think that would be a problem even shortly after FF if they go past it
15:35:13 <nikhil_k> jokke_: we cannot extend doc freeze date (I think) or it's difficult bargain
15:35:44 <jokke_> nikhil_k: ah darn ... forgot them :(
15:35:51 <nikhil_k> #info Please merge doc related changes on or before Mar12th
15:36:09 <jokke_> nikhil_k: does Doc freeze same time as oslo?
15:36:32 <nikhil_k> mclaren:  thanks.  We should decide on landing it in Kilo may be on Mar10th?
15:37:04 <mclaren> nikhil_k: sure
15:37:05 <nikhil_k> jokke_: worth checking, but it seems 19th from this
15:37:05 <nikhil_k> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
15:37:32 <jokke_> nikhil_k: yeah 19th is the general freeze, oslo freezez week earlier as in 12th
15:37:51 <nikhil_k> jokke_: err, forgot the mention that the string freeze is mentioned as 19th there
15:38:35 <ativelkov> BTW, do we observe feature proposal freeze?
15:38:39 <jokke_> *puuh* so we have two weeks instead of week with those :)
15:39:23 <nikhil_k> ativelkov: same as code freeze, 12th
15:39:31 <nikhil_k> (per project basis)
15:39:44 <nikhil_k> jokke_: :)
15:40:06 <jokke_> nikhil_k: so do we freeze @ 12th or @ 19th?
15:40:21 <nikhil_k> #info I've suggested ativelkov et.al. and TravT_ et.al. to make smaller changes found in their features as a part of bugs after k3 (during RCs). Excludes. security issues found, 500s founds, doc, API etc ImpactFlags missing.
15:41:00 <nikhil_k> jokke_: 12th is project freeze and week for FFEs and bugs before rc1
15:41:17 <nikhil_k> that's to ensure that we're not missing the entities mentioned in the info I pasted above
15:41:23 <ativelkov> Agreed. We've also stopped pushing new patchsets to prevent rebases
15:41:41 <mfedosin> nikhil_k, ++
15:42:06 <sigmavirus24> ativelkov: thank you. Thanks makes review efforts far simpler
15:42:35 <nikhil_k> please be on the look out, this spec needs a doc change in glance (https://review.openstack.org/#/c/148426/) so does zhiyan's BP https://blueprints.launchpad.net/glance/+spec/store-capabilities
15:43:35 <nikhil_k> moving on, unless there's something more..
15:44:07 <nikhil_k> #topic Reviews/Bugs/Releases
15:44:41 <nikhil_k> We'd client and store releases recently
15:45:00 <jokke_> yeii
15:45:29 <nikhil_k> If any features have client related changes that should go in Kilo please ping sigmavirus24, kragniz , zhiyan , hemanthm , flavio or me for adding in the https://trello.com/b/GFXMXxsP/openstack-glance
15:45:49 <nikhil_k> That will ensure visibility
15:46:05 <jokke_> or me ;)
15:46:14 <nikhil_k> (That's it from me on this one)
15:46:24 <nikhil_k> jokke_: yes, sorry...
15:46:37 <jokke_> np
15:46:49 <nikhil_k> especially jokke_ (please send him a lot of pings) ;)
15:47:18 <nikhil_k> He's our stability hero, afterall!
15:47:24 <jokke_> yeah, more I add them in there, the less I get spam stuff being changed :P
15:47:31 <sigmavirus24> jokke_: heh
15:48:17 <nikhil_k> #topic Open Discussion
15:48:32 <jokke_> I have couple of things I forgot to put on the agenda
15:49:17 <jokke_> 1) Log Working Group had first meeting yesterday, looking for liaisons in projects ... I marked myself down already ... if someone else insists feel free to change :D
15:49:56 <jokke_> 2) With the logging please, please, please read this: http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
15:50:39 <jokke_> 3) As it does not seem to have effect on the participants could we please stop this 1hr alternating on the meetings? It's just annoying and confusing
15:51:19 <rosmaita> jokke_: +1 to all
15:51:25 <hemanthm> I don't mind as long as nikhil_k is send courtesy reminders :)
15:51:28 <nikhil_k> #startvote can we please stop this 1hr alternating on the meetings?
15:51:29 <openstack> Begin voting on: can we please stop this 1hr alternating on the meetings? Valid vote options are Yes, No.
15:51:30 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:51:34 <nikhil_k> #vote Yes
15:51:47 <rosmaita> #vote Yes
15:51:53 <hemanthm> #vote yes
15:51:58 <ativelkov> #vote yes
15:52:00 <jokke_> #vote Yes
15:52:07 <mfedosin> #vote Yes
15:52:14 <kragniz> #vote yes
15:52:36 <ativelkov> If we stop, what is the fixed time then?
15:52:44 <ativelkov> Both are ok for me, just curious
15:52:46 <nikhil_k> ativelkov: 14.30 UTC?
15:52:54 <jokke_> Either one of the existing ones is better than current\
15:53:00 <mclaren> I think one was better for Zhi Yan?
15:53:00 <lakshmiS> #vote yes
15:53:09 <mclaren> but can't remember
15:53:20 <ivasilevskaya> #vote Yes
15:53:25 <Olena> #vote Yes
15:53:28 <jokke_> I think Zhi Yan prefers as early as possible due to TZ
15:53:38 <kragniz> mclaren: I'm guessing the earlier one
15:53:45 <mclaren> ok
15:54:23 <nikhil_k> I think TravT_ is affected but is being overwhelmed by majority
15:54:37 <TravT_> In a week time changes
15:54:42 <TravT_> so it won't be so bad
15:54:45 <nikhil_k> sigmavirus24: lakshmiS TravT_ ^
15:54:47 <nikhil_k> ah ok
15:54:57 <jokke_> TravT_: even better then ;)
15:55:08 <nikhil_k> #endvote
15:55:09 <sigmavirus24> #vote yes
15:55:09 <openstack> Voted on "can we please stop this 1hr alternating on the meetings?" Results are
15:55:12 <nikhil_k> oops
15:55:14 <sigmavirus24> ;)
15:55:29 * sigmavirus24 is distracted this morning
15:55:33 <ativelkov> Seems like the bot prefers alterations
15:55:39 <nikhil_k> #action nikhil_k to send email to ML for readjusting the meeting time to 14:00UTC
15:55:52 <kragniz> ativelkov: the bot just can't make up its mind
15:55:55 <jokke_> that was all from me this time
15:56:38 <mfedosin> folks, Zhi Yan asked me to know, is there a possibility to direct access glance_store from Nova as it mentioned in the spec https://blueprints.launchpad.net/glance/+spec/create-store-package
15:56:41 <jokke_> I'd like to also assume that the review cleanup is ok as no more e-mails for over 2 weeks now on the mailchain ;)
15:57:04 <mfedosin> because I don't know how to show it in the developer documentation
15:57:11 <jokke_> mfedosin: the lib is out there, Nova can use it if they want to
15:57:17 <nikhil_k> email from jokke_ about Log Working Group, http://osdir.com/ml/openstack-dev/2015-03/msg00328.html
15:57:25 <sigmavirus24> jokke_: have you not seen the one John Griffith started about auto-abandon?
15:57:31 <mfedosin> jokke_, nice, thank you
15:57:45 <kragniz> jokke_: have you read the other threads on it?
15:57:48 <sigmavirus24> jokke_: the community seems mostly against it
15:57:58 <sigmavirus24> s/mostly/majority/
15:58:09 <kragniz> jokke_: (last email about half an hour ago)
15:58:34 <jokke_> sigmavirus24: I'd disagree ... the few loud one is community seems to be drumming the same message against it ;)
15:58:53 <jokke_> "ones are" even
15:59:52 <kragniz> anyway, we're out of time
16:00:04 <TravT_> thanks everyone
16:00:09 <jokke_> thnx!
16:00:16 <mclaren> ciao
16:00:17 <pennerc> thnx
16:00:21 <kragniz> thanks
16:00:22 <nikhil_k> Thanks all!
16:00:28 <nikhil_k> #endmeeting