14:00:01 <nikhil_k> #startmeeting Glance
14:00:01 <openstack> Meeting started Thu Mar 12 14:00:01 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. 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:10 <nikhil_k> https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:12 <kragniz> yo yo
14:00:15 <kragniz> o/
14:00:19 <pkoniszewski> o/
14:00:24 <rosmaita> o/
14:00:28 <sigmavirus24> o/
14:00:43 <ativelkov> o/
14:01:05 <Nikolay_St> щ.
14:01:07 <Nikolay_St> o/
14:01:12 <cpallares> o/
14:01:18 <TravT> o/
14:01:20 <flaper87> o/
14:01:23 <Olena> o/
14:01:29 <jokke_> o/
14:01:37 <ivasilevskaya> o/
14:01:59 <jokke_> wow ... we have good participation today :D
14:02:00 <mfedosin> o/
14:02:01 <nikhil_k> cool, looks like a full house
14:02:06 <hemanthm> o/
14:02:16 <lakshmiS> o/
14:02:18 <nikhil_k> #topic K3
14:02:36 <nikhil_k> https://launchpad.net/glance/+milestone/kilo-3
14:03:04 <nikhil_k> Seems like a lot of them merged
14:03:11 <nikhil_k> (very recently)
14:03:26 <nikhil_k> A few that we need today merged are
14:03:40 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/basic-import-conversion <- point of contact flaper87
14:03:46 <jokke_> ativelkov: thanks for the docstrings ... made it so much easier to follow
14:03:53 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/glance-sorting-enhancements <- POC mfedosin
14:04:20 <flaper87> 0/
14:04:33 <ativelkov> jokke_: no problem, thanks for pointing that out,I didn't realise that docstrings are under the freeze
14:04:44 <nikhil_k> A couple that seem to be in trouble may be and should get updated soon:
14:04:52 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/deactivate-image <- POC hemanthm , rosmaita
14:05:04 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/pass-targets-to-policy-enforcer < poc sigmavirus24
14:05:23 <sigmavirus24> the spec still needs approval
14:05:42 <nikhil_k> pkoniszewski: how positive are we to land https://blueprints.launchpad.net/glance/+spec/metadefs-upgrade-by-json-file ? seems a bit trixy at this point I'd say
14:06:32 <jokke_> I don't want to talk anyone down, but I'd like to remind that we have a week to land what we're landing
14:06:40 <nikhil_k> hmm, may be we'd come back to that
14:07:05 <pkoniszewski> nikhil_k: implementation is ready and covers everything that was mentioned in spec
14:08:02 <nikhil_k> pkoniszewski: sg, I'd leave it upto you and resp core reviewers to judge that
14:08:04 * flaper87 is fixing the gate failure, it looks like it fails just with testr (yay?)
14:08:16 <nikhil_k> Like announced earlier I'd ask for FFE on Artifacts and Catalog Index Service
14:08:50 <nikhil_k> and possibly on something that does not get merged today but the chances of it being in the FFE are very narrow
14:09:01 <flaper87> to be clear, the gate failure in *my* patch
14:09:17 <nikhil_k> so, please update your code and ping reviewers for the same
14:09:28 <cpallares> flaper87: lol
14:10:01 <nikhil_k> We'd start fixing bugs and other things that should follow the freeze creterion before different kinds of freeze next week
14:10:18 <flaper87> cpallares: :P
14:10:27 <sigmavirus24> nikhil_k: which parts of Artifacts because that's a huge set of patches for us to review in <= 1 week
14:10:27 <nikhil_k> so, docs , config deprecation, critical bugs that affect the API etc
14:10:52 <jokke_> yeah ... please people if there is anything that has DocImpact, the next 7 days are critical so that we stay in good terms with docs folks :P
14:10:53 <nikhil_k> sigmavirus24: It'd be good to discuss that on the code
14:11:15 <nikhil_k> #info jokke_ : please people if there is anything that has DocImpact, the next 7 days are critical so that we stay in good terms with docs folks
14:11:36 <nikhil_k> (seemed important :P)
14:12:26 <jokke_> well we do want to give them the time to works what they deserve, right
14:12:35 <jokke_> =s
14:14:12 <nikhil_k> There may be some bugs that can't be tacked in after 19th so please bring important ones to the notices of cores around you
14:14:12 <nikhil_k> tackled*
14:14:13 <nikhil_k> (ugh, too many typos)
14:14:13 <TravT> nikhil_k: @here: pkonizewski's spec may really help us to handle migration / bug fixes on metadata definitions.
14:14:13 <ativelkov> sigmavirus24: I'd prefer to land all of them, since the feature becomes functional only when the last one is merged
14:14:19 <TravT> there are a few updates (sorry I don't have bug for it) to existing definitions that we might need to do.
14:14:36 <TravT> And his spec makes that easier to do from a migration perspective.
14:14:53 <sigmavirus24> ativelkov: you do realize that's something around >=5000 lines to review when there are far more attainable features that could be merged in the amount of time it will take to effectively review and update artifacts, right?
14:14:58 <nikhil_k> gotcha
14:15:46 <sigmavirus24> ativelkov: the specs have been approved. It isn't as if artifacts won't ever be accepted at this point
14:17:04 <ativelkov> sigmavirus24: I care mostly about Kilo, not about "ever" :)
14:17:20 <jokke_> Ref ativelkov's note of having the functionality in ... I think that is the most important part. If we do not have the functionality in by the review, we need to have revert plan to pull out the code that gets merged but is not in use for the release. Last thing we want is to have some half baked modules going out with release that does not work
14:17:30 <sigmavirus24> ativelkov: and I care about kilo's stability, usability, and giving the best experience to the user
14:17:57 <nikhil_k> jokke_: I don't think that would be bad on the migrations stuff
14:18:09 <nikhil_k> I believe that it'd be bad*
14:18:12 <jokke_> thus I have been wondering where these are as I thought we agreed to start pulling the artifacts in soon after k-2 but I haven't heard anything about it before now
14:18:38 <jokke_> nikhil_k: what do you mean?
14:18:59 <nikhil_k> I think we should not revert DB migrations
14:19:04 <jokke_> sigmavirus24: ++
14:19:13 * flaper87 back
14:19:30 <sigmavirus24> jokke_: the spec was only recently approved. No one was willing to review the code when it was rebased many times a week for the duration of kilo. Review comments were almost always rebased into the past and never addressed
14:20:43 <jokke_> sigmavirus24: well that is fully a Glance issue I've been trying to raise for whole cycle ... it seems that we do not merge specs before the code is ready
14:20:50 <nikhil_k> So, this is prolly a learning lesson, I think it would nice to mention here
14:21:19 <jokke_> sigmavirus24: so spec not approved is really not an excuse to not have the code ready (or at least that has been the message over whole cycle)
14:21:51 <sigmavirus24> jokke_: I agree
14:21:59 <nikhil_k> #info If your feature code needs reviews, you're responsible for pinging core reviewers and get it reviewed. It'd hardly be possible for everyone to understand when something is ready and when isn't given the amount of code that is proposed and number of cores we've.
14:22:17 <nikhil_k> jokke_: +1 on that!
14:22:41 <flaper87> jokke_: on the flip side, some specs definitely need to be discussed before you can start coding
14:22:58 <ativelkov> The was ready by the time of mini-summit. But that's 7 dependent commits, a minor issue found in one of them was causing the whole chain to be rebased
14:23:03 <flaper87> that said, I agree with you
14:23:03 <nikhil_k> flaper87: I think you're right however what jokke_ is saying that you don't need them approved
14:23:26 <nikhil_k> you can discuss and iterate over the design based on the findings
14:23:45 <nikhil_k> I can mention a few cases on CIS (Catalog Index Service)
14:23:57 <jokke_> flaper87: my personal take is that poc is absolute max what should be done before the spec is approved and the spec should be approved as soon as the main design points have been agreed, but that does not seem to be the case
14:27:42 <lakshmiS> jokke_: +1
14:28:45 <nikhil_k> jokke_: do you have examples where these concerns were brought up and not covered by complete design discussion?
14:29:08 <sigmavirus24> I had tried reviewing artifacts several times before and after the mini-summit ativelkov I still don't think any of my review comments were ever replied to, but it's easy to lose the email notifications (and patch set numbers) when things have been rebased so frequently
14:29:25 <jokke_> nikhil_k: I can grep the irc logs at some point ... At least in couple of meetings earlier on the cycle
14:29:59 <nikhil_k> sure that would be good to bring it up to (Active) drivers as feedback for future specs
14:30:50 <nikhil_k> The policy has been to keep specs open until after the code has been almost agreed upon barring exceptions that involve FF, 3 year long discussions and approved BPs
14:31:18 <nikhil_k> may be we need to know where that's been not handled well
14:31:22 <ivasilevskaya> sigmavirus24, you are not being honest here. I personally saw to addressing all of your comments, especially the declarative framework part)
14:32:17 <jokke_> nikhil_k: I was in understanding that the specs were supposed to be the answer for that exact issue ;)
14:33:00 <rosmaita> i am really concerned about blocking artifacts at this point, especially since it is an optional service with an api marked as EXPERIMENTAL
14:33:04 <jokke_> nikhil_k: for me the basic understanding was bit like a planning permission for your house ... it's bad idea to build it before you get the stamp on the paper that it's ok to do
14:33:21 <nikhil_k> jokke_: ok, I don't get you there but would like to correct this situation right away so may be we'd discuss this outside of the meeting unless someone else has feedback
14:33:42 <sigmavirus24> Haven't we been warned several times by outside developers that EXPERIMENTAL APIs are always well intentioned but are always a disaster?
14:33:46 <jokke_> nikhil_k: sure
14:34:12 <sigmavirus24> ivasilevskaya: I still haven't found those replies
14:34:48 <nikhil_k> sigmavirus24: ativelkov jokke_ ivasilevskaya : I think we need to come to common understanding on this point and back and forth arguments might not help
14:35:04 <jokke_> rosmaita: I do agree and I'm more than happy to get artifacts in as long as we get them in right ... I would hate to see same circus with ninja approved changes etc. what happened when we rushed glance_store in at last minute
14:35:07 <sigmavirus24> ivasilevskaya: also, I didn't say they were never replied to, just that I still haven't found them and I'm tired of trying to help artifacts when all prior efforts were ignored
14:35:55 <nikhil_k> so, I'd like to propose something tangible but would like to get some feedback for how we can move 'forward'?
14:36:36 <jokke_> rosmaita: if it's experimental enough we probably can do non-voting testing for it and just make sure that images stays stables and usable while we landslide the code in
14:37:22 <rosmaita> jokke_: i don't think it contains anything that would affect images (although it does use the same DB, different tables, though)
14:37:48 <nikhil_k> jokke_: is it going to have testing that carries vote weight?
14:37:54 <ativelkov> There are no actual intersections between images and artifacts. They use the same DB (and thus the same migration chain), but that's the only shared location
14:37:57 <nikhil_k> (just trying to understand)
14:38:35 <nikhil_k> ativelkov: and we don't have tests from tempest, neutron, etc projects in glance gate and we can ensure that until this code is stable?
14:39:03 <jokke_> nikhil_k: well the point is that if we bring it in and it breaks the gate it breaks the gate for everything ... if we bring it in and it breaks non-voting tests on gate it's just our problem to get those stabilized
14:39:43 <ativelkov> nikhil_k: didn't get this part. We do not have tempest tests for artifacts, as we do not have their support in the client yet
14:39:58 <nikhil_k> jokke_: I'm worried that infra might not like that complication. Because everything would be in py27 run
14:40:20 <nikhil_k> ativelkov: yes, thanks for stating that explicitly
14:40:42 <ativelkov> We do only test artifacts as part of DB tests, functional API tests + some unit tests on particular modules such as declarative framework
14:40:42 <jokke_> nikhil_k: which makes this situation difficult ... that was just proposal to point out one way around this issue
14:41:15 <nikhil_k> I think that's what jokke_ is worried about no? Otherwise, I'm unsure how to break glance test suite into two parts in the gate
14:41:37 <nikhil_k> Also, not to diverge sigmavirus24's original point about code completeness
14:42:00 <jokke_> nikhil_k: correct ... any of those test being flaky affects our gating from the point they get merged
14:42:04 <ativelkov> Currently all the checks are green, as far as I can see
14:42:30 <nikhil_k> Where can we discuss some of these concerns? Can we open an etherpad ativelkov sigmavirus24 jokke_ ?
14:42:36 <jokke_> so we need to have either backout plan if we don't get it all right early enough or find a way not to break the gate bringing that experimental code in
14:42:41 <sigmavirus24> nikhil_k: mailing list perhaps?
14:42:49 <sigmavirus24> We can use an etherpad too
14:43:04 <sigmavirus24> I think there is a greater wealth of knowledge and experience on the ML though
14:43:09 <nikhil_k> Collaboration works so much better on etherpad and real time feedback too
14:43:11 <jokke_> ++
14:43:22 <ativelkov> I do have etherpad for Artifact reviews at https://etherpad.openstack.org/p/Artifacts_Reviews
14:43:24 <nikhil_k> hm, true
14:43:53 <nikhil_k> hmm, may be we've sub points for each of those reviews
14:44:02 <nikhil_k> I think not all of this applied to all reviews
14:44:06 <nikhil_k> applies*
14:44:14 <jokke_> please if we use etherpad, mark your name/nick on the color so we know who has written and what
14:44:36 <nikhil_k> ok, let's move on for now
14:44:44 <sigmavirus24> jokke_: what if I use someone else's name and color? =P
14:44:51 <nikhil_k> #action sigmavirus24 and ativelkov to discuss etherpad and ML option for further discussion
14:45:03 <nikhil_k> #topic Reviews/Bugs/Releases
14:45:06 <jokke_> sigmavirus24: I'll find you and feed you to the sharks ;)
14:45:20 <sigmavirus24> jokke_: works for me
14:45:30 <nikhil_k> #info One release planned for glance_store and one for client on either Mon/Tues depending on the state of the patches
14:45:49 <jokke_> uuh my second favorite topic :D
14:45:59 <jokke_> can we rant an hour about this as well :D
14:46:00 <nikhil_k> #info we will look into the option of a stable branch for these that would be cut at Kilo RC3
14:46:08 <kragniz> these will be the last for kilo?
14:46:24 <nikhil_k> kragniz: may be, depending on review speed
14:46:29 <kragniz> okay
14:46:54 <nikhil_k> Please add bugs and features for these in the trello board
14:47:23 <nikhil_k> I'm inclined to move on unless someone wants to say anything
14:47:54 <nikhil_k> #topic Other
14:48:09 <nikhil_k> http://lists.openstack.org/pipermail/openstack-operators/2015-March/006450.html
14:48:27 <nikhil_k> Do we have a bug for it?
14:49:02 <kragniz> I don't think so
14:49:10 <jokke_> I don't think so either ...
14:49:11 <nikhil_k> I think we can further discuss on the bug once that opens up why 500 is seen
14:49:30 <jokke_> I'm also not on the ops list so I hear forst time about this issue now
14:49:42 <jokke_> first
14:49:51 <nikhil_k> yeah
14:50:14 <jokke_> sounds like our grenade testing has failed
14:50:17 <sigmavirus24> Oh yeah, I think I added that
14:50:19 <nikhil_k> ok, moving on. I think we can leave a note for them to open the bug if they are not here
14:50:27 <nikhil_k> sigmavirus24: :P
14:50:35 <nikhil_k> do we have more info/logs?
14:51:04 <sigmavirus24> Oh I meant I added that to the agenda
14:51:11 <sigmavirus24> Not that I posted the message to -operators
14:51:14 <nikhil_k> looks cryptic and we don't know the data they are pulling from DB so could be anything
14:51:40 <sigmavirus24> nikhil_k: agreed. I was still curious about other people's thoughts on the matter. If there's something we can figure out how to do better
14:51:41 <nikhil_k> sigmavirus24: yeah, I figured that you may know them. wrong assumption sorry..
14:51:55 <sigmavirus24> I can get to know Nathan
14:52:01 <nikhil_k> thanks!
14:52:01 * sigmavirus24 goes into undercover spy mode
14:52:17 <nikhil_k> Glance upgradeability
14:52:18 <TravT> zhiyan: jokke_: any other core please look at: https://review.openstack.org/#/c/159532/ (Provide a way to upgrade metadata definitions).  This is the result of a conversation with Zhiyan on a previous review in K-2.
14:52:21 <jokke_> sigmavirus24: I would appreciate if you could forward me some meaningful bundle of responses if any coming from that end
14:52:22 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/versioned-objects
14:52:28 <nikhil_k> https://review.openstack.org/#/c/151194/
14:52:37 <nikhil_k> I believe that is a review call for the cores
14:52:38 <sigmavirus24> jokke_: so CC you from the start? got it. =P
14:52:42 <pkoniszewski> it's me again!
14:52:57 <jokke_> sigmavirus24: if that works, good
14:53:07 <pkoniszewski> I'm aware that it is a bit late for kilo release to implement objects
14:53:14 <jokke_> sigmavirus24: I've just seen the lists dropping ccs out
14:53:26 <sigmavirus24> jokke_: Yeah
14:53:28 <pkoniszewski> however, if we manage to get this in L-release, update will be available from L to M release, it won't work from K to L, so it is imo beneficial to get this in L release
14:53:30 <nikhil_k> and drivers*
14:53:51 <nikhil_k> pkoniszewski: agreed. we can move this to L once we open it up
14:53:56 <jokke_> pkoniszewski: quick recap ... what are you looking for with that?
14:54:00 <nikhil_k> thanks to jokke_ the review is in place already
14:54:34 <nikhil_k> pkoniszewski: may be we can rebase it on https://review.openstack.org/#/c/163382/
14:54:37 <pkoniszewski> jokke_: smooth upgrades between versions
14:55:01 <pkoniszewski> nikhil_k: sure!
14:55:10 <nikhil_k> cool
14:55:15 <nikhil_k> #topic Open Discussion
14:55:18 <TravT> was it ever decided exactly what the rules are for an experimental API ?
14:55:59 <nikhil_k> They aren't and I think we should discuss that on [TC] flag if needed
14:56:03 <TravT> I mean, if you mark an API as experimental, does that mean it doesn't have to provide a 2 release deprecation cycle?
14:56:16 <jokke_> TravT: I'd say log a lot, document even more and make sure that everybody understands it's not really production stable
14:56:50 <jokke_> TravT: I think that was pretty much the idea that experimental api might change more rapidly
14:57:10 <nikhil_k> So, rosmaita brought up an excellent point in the mid-cycle meetup. We need to blog about it and post in on ML, Social networks and inform peers, users, opers
14:57:47 <nikhil_k> TravT: however, your original point - what are the rules? They don't seem to be defined
14:58:02 <nikhil_k> and would be excellent to have
14:58:06 <TravT> Probably it is up to a project to define then?
14:58:19 <nikhil_k> I think we missed pointing out the context
14:58:52 <jokke_> does API wg has any take on that?
14:58:54 <nikhil_k> There has been some discussion going on CIS, please see https://review.openstack.org/#/c/161621/
14:59:05 <TravT> there is some discussion ... Nikhil beat me to it.
14:59:08 <nikhil_k> API has guidelines and not rules jokke_
14:59:23 <nikhil_k> API-WG* sorry ^
14:59:46 <jokke_> nikhil_k: good ... do they have anything there we can directly steal and adhere to?
14:59:53 <kragniz> this had +2A before it required a rebase, so some quick reviews would be nice: https://review.openstack.org/#/c/149344/
15:00:11 <TravT> it seems to me that usually when we take requests to TC that they may give back guidance, but there aren't a lot of "thou shalt" rules.
15:00:12 <nikhil_k> Time to call all the discussions outside of the meeting..
15:00:16 <rosmaita> if people still have time let's continue this in openstack-glance channel, it is important to discuss
15:00:29 <nikhil_k> == rosmaita
15:00:31 <jokke_> thanks everybody!
15:00:33 <kragniz> thanks all
15:00:34 <nikhil_k> Thanks all!
15:00:37 <ativelkov> thanks
15:00:41 <rosmaita> see you in openstack-glance!
15:00:43 <nikhil_k> #endmeeting