15:00:28 <nikhil_k> #startmeeting Glance
15:00:29 <openstack> Meeting started Thu Feb 19 15:00:28 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:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:32 <ativelkov> o/
15:00:33 <openstack> The meeting name has been set to 'glance'
15:00:37 <mfedosin> yup
15:00:38 <jokke_> o/
15:00:39 <kragniz> o/
15:00:39 <stevelle> o/
15:00:39 <mfedosin> o/
15:00:39 <nikhil_k> https://etherpad.openstack.org/p/glance-team-meeting-agenda
15:00:49 <rosmaita> o/
15:01:22 <nikhil_k> Let's get started
15:01:31 <nikhil_k> #topic Glance review guidelines
15:01:39 <nikhil_k> hemanthm: mfedosin ?
15:01:42 <mfedosin> okay
15:01:53 <mfedosin> before I begin I have some good news
15:01:55 <hemanthm> nikhil_k, o/
15:02:09 <mfedosin> Now we have a dedicated technical writer for Glance
15:02:21 <kragniz> woo!
15:02:22 <mfedosin> er name is Lena and she has big experience in writing documentation - over 7 years.
15:02:29 <TravT_> \o/
15:02:30 <jokke_> \\o \o/ o// o/7
15:02:45 <mfedosin> Unfortunately she's on vacation this week, but I hope next time she can join us and introduce herself.
15:02:57 <kragniz> that sounds great
15:03:06 <nikhil_k> Nice, good news indeed
15:03:12 <mfedosin> yeah, she's good
15:03:17 <rosmaita> mfedosin: that is really good news, we need someone to get the docs straightened out
15:03:30 <pkoniszewski> o/
15:03:43 <mfedosin> so, about review guide...
15:03:49 <pennerc> o/
15:04:04 <mfedosin> I want to show you draft of the review guidelines. It still needs some work, but you can read it and leave your comments.
15:04:12 <mfedosin> https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5RJabsI/edit?usp=sharing
15:05:01 <mfedosin> I think Hemanth as a author can say a couple of words about it
15:05:39 <mfedosin> I have several questions:
15:05:46 <mfedosin> Do we need examples there? And what kind of...
15:05:49 <sigmavirus24> o/
15:05:55 <mfedosin> 1. example of good and bad code
15:06:05 <mfedosin> 2. successful corrections
15:06:10 <mfedosin> 3. bad reviews
15:06:23 <mfedosin> And do we need another paragraphs there?
15:06:34 <hemanthm> If we want it to be educational, I'd say lets leave examples there
15:06:55 <nikhil_k> Since this is the first draft. 1 -> good to have but not necessary
15:07:10 <sigmavirus24> Yeah I think examples will help more than hurt
15:07:17 <hemanthm> at least for some glance specific practices  like wrapping and reraising exceptions
15:07:20 <nikhil_k> can you please elaborate on 2 ?
15:07:24 <kragniz> more examples are good
15:07:52 <sigmavirus24> Yeah 2 is a bit vague
15:08:12 <mfedosin> nikhil_k, links for good reviews
15:08:27 <mfedosin> and 3 links for bad reviews
15:08:30 <nikhil_k> ah
15:08:37 <nikhil_k> I don't think we want 3
15:08:39 <ativelkov> status:merged should be such a link
15:08:42 <hemanthm> hehe
15:08:46 <lakshmiS> i think some troubleshooting tips/scenarios will be good if it helps in the context
15:08:54 <mfedosin> ativelkov, ;)
15:09:13 <nikhil_k> we can have something that says what are nitpicks , corner cases, some bikeshedding examples, etc
15:09:14 <hemanthm> lakshmiS, good idea but that can do in the dev guide maybe? mfedosin is going to talk about it next
15:09:20 <hemanthm> *can go
15:09:55 <jokke_> mfedosin, hemanthm: Is there a reason to have the non-glance-specific stuff there to keep in sync rather than improving the OS wiki regarding those?
15:09:59 <lakshmiS> hemanthm, as long as it's there in some doc, that will be helpful
15:10:06 <nikhil_k> but we *DONOT* want to point out someone publicaly and condemn them
15:10:13 <mfedosin> hemanthm, yes, so I think we need 1, and reject 2 and 3
15:11:59 <hemanthm> jokke_, yeah we could always point to appropriate wikis, but the idea was to share a few commonly found patterns and then link to the wikis for more info
15:12:24 <nikhil_k> New reviewers are not going to like that and our objective is, to be inclusive as far as possible
15:12:36 <mfedosin> jokke_, Hemanth is right. There is a small description of this guide and what is is for...
15:13:11 <kragniz> is this planned to be placed on the wiki at some point?
15:13:24 <hemanthm> kragniz, yes, that's the idea
15:13:40 <kragniz> cool
15:14:34 <mfedosin> and as I mentioned all your thoughts  and suggestions are appreciated :)
15:14:35 <sigmavirus24> The other thing we might want to do is discuss certain special cases
15:14:45 <jokke_> I would prefer the approach that Hacking doc has as in just header pointing to the OS general guidelines, and telling to read them first, then reading them again and then coming back to the glance specific stuff (keeping the later part as small as possible)
15:15:06 <sigmavirus24> So I was reviewing one of sabari's changes in glance_store and learned that for driver-specific changes, nova asks the driver name be first (which contradicts with the general style guide)
15:15:33 <sigmavirus24> do we want to do the same, etc
15:15:49 <sigmavirus24> (that's the value add I see in doing this separately first)
15:16:25 <hemanthm> sigmavirus24, +1, could you please add any special cases you are aware of
15:16:46 <jokke_> sigmavirus24: could you explain this "nova asks the driver name be first"? Be first where, how?
15:16:50 <sigmavirus24> hemanthm: well I think they're things we should decide as a community which is why I brought that up
15:17:03 <sigmavirus24> jokke_: so in the subject it would be "VMware: Do x y z and update foo bar bogus"
15:17:11 <nikhil_k> == sigmavirus24
15:17:38 <sigmavirus24> That breaks the general style rule of "Imperative subjects" i.e. "Change VMWare driver to do x y z and update foo bar bugs"
15:17:43 <nikhil_k> Our commits are often not par with such standards but we've improving for sure
15:18:07 <sigmavirus24> On the one hand: The former gives the reader an immediate understanding that this is VMWare specific, on the other it breaks with the generic style guide
15:18:12 <nikhil_k> iiuc, that is a general git rule
15:18:48 <nikhil_k> sigmavirus24: I think openstack breadth asks for breaking that rule
15:18:49 <jokke_> sigmavirus24: well I think that's the problem ... it gives impression something being VMWare specific, which it might not be
15:19:31 <nikhil_k> jokke_: that would be a corner case when you change the interface code
15:19:46 <nikhil_k> I think we need to move on
15:19:51 <sigmavirus24> yeah
15:20:01 <nikhil_k> Let's discuss this on the docs/comments/email etc
15:20:01 * sigmavirus24 didn't mean for this to be a full discussion at this point in time
15:20:05 <sigmavirus24> email is best
15:20:06 <sigmavirus24> :)
15:20:10 <nikhil_k> #topic Glance developer documentation
15:20:14 <jokke_> nikhil_k: looking how much we have refactoring around oslo etc. I think it has been more rule than exception for example on our vmware driver lately :P
15:20:33 <nikhil_k> jokke_: ah ok
15:20:43 <mfedosin> yep
15:20:49 <nikhil_k> mfedosin: any specific inputs on this topic?
15:20:51 <mfedosin> https://docs.google.com/a/mirantis.com/document/d/10OVbGkVTYOIF9_SnXHWlupiQBaVGIBtbroP0jewgPsU/edit?usp=sharing
15:20:59 <mfedosin> There is not so much currently, but you already can get a picture what it'll be.
15:21:05 <sigmavirus24> mfedosin: need access
15:21:11 <kragniz> mfedosin: it wants access
15:21:19 <nikhil_k> mfedosin: can you please move that to google domain?
15:21:25 <nikhil_k> it's on mirantis one, atm
15:21:43 <mfedosin> done
15:21:51 <mfedosin> sorry :)
15:21:57 <nikhil_k> np
15:22:18 <mfedosin> We started it with Lena last week and there will be 4 or 5 parts.
15:22:21 <ativelkov> #link https://docs.google.com/document/d/10OVbGkVTYOIF9_SnXHWlupiQBaVGIBtbroP0jewgPsU/edit
15:22:54 <mfedosin> First one about Architecture like http://docs.openstack.org/developer/nova/devref/architecture.html but much better :)
15:23:16 <kragniz> mfedosin: looks pretty nice!
15:23:22 * jokke_ likes the first impression ... thanks1
15:23:27 <mfedosin> Second is optional and I have some concerns about its including in the documentation. It's  about inner structure of glance utils like scrubber, pruner and replicator. I suppose not so many people need this kind of documentation and if they need, they can easily find out for themselves.
15:23:50 <mfedosin> Third is about structure of domain and its layer. Plus there will be Repo API and description of Factory, Gateway and Image class
15:24:11 <mfedosin> *layers
15:24:19 <sigmavirus24> mfedosin: this sounds awesome
15:24:19 <mfedosin> Forth for what domain model is. Proxy classes and Helpers
15:24:34 <kragniz> I really like the high level view
15:24:48 <mfedosin> And the last one describes DB API and organization of the tables.
15:25:22 <nikhil_k> mfedosin: Looks really good.
15:25:32 <TravT_> This is really great!
15:25:32 <mfedosin> thanks, it will be better
15:25:42 <nikhil_k> We may want to avoid showing DB schema like this (created manually)
15:26:07 <kragniz> this is going to be part of the glance documentation?
15:26:30 <nikhil_k> If we can get some doc strings on the schema specification in the code, that would be better
15:26:50 <hemanthm> While this is really useful, documentation like this tends to go out of sync very quickly if we don't maintain it. That's definitely a cost involved with it
15:26:52 <mfedosin> yes, I see
15:27:25 <mfedosin> hemanthm, and that's why we have Lena as a technical writer
15:27:33 <nikhil_k> yeah, also the pipeline makes it difficult to determine the correlation of the doc with the deployment
15:27:46 <jokke_> while there is cost involved I really like that ... this is like first human readable version of what's going on there I've seen ;)
15:28:16 <mfedosin> You can look and comment as well as the review guide. Everyone is welcome.
15:28:26 <sigmavirus24> mfedosin++ Lena++
15:28:52 <TravT_> schema could be generated by raw output from describing it.
15:29:31 <mfedosin> yes, but I want it to be pretty looked picture
15:29:59 <nikhil_k> jokke_: true but human readable does not guarantee the authenticity and that can be bad sometimes
15:30:03 <mfedosin> but I agree - maintain all the migrations is annoying
15:30:20 <nikhil_k> for example the image status transitions are not complete here http://docs.openstack.org/developer/glance/statuses.html
15:30:30 <sigmavirus24> :(
15:31:00 <mfedosin> And also I want to know about the timing. Until what date should it be completed?
15:31:11 <nikhil_k> mfedosin: yes, good point
15:31:26 <kragniz> mfedosin: having it for the kilo release would probably be great
15:31:28 <sigmavirus24> Do we want it in time for the summit so we can show it off?
15:31:41 <nikhil_k> mfedosin: I don't think we have a _completion_ date however, good to have a small first version (minimal style)
15:31:43 <sigmavirus24> or what kragniz said ;)
15:31:46 <mfedosin> 13, March?
15:31:55 <nikhil_k> sure
15:32:14 <sigmavirus24> should we set a k-1 milestone for it before that to solicit feedback on a near-final draft?
15:32:17 <kragniz> sigmavirus24: shipping it with kilo would be kindest to ops :P
15:32:36 <nikhil_k> k3 you mean?
15:32:37 <sigmavirus24> kragniz: wait, you mean ops aren't just imaginary things? They're real humans? *mindblown* =P
15:32:37 <kragniz> sigmavirus24: k3 you mean?
15:32:54 <sigmavirus24> kragniz: well k-1 would be the milestone for the document, doesn't need to coincide with k-3
15:32:55 <sigmavirus24> it can
15:33:10 <nikhil_k> I don't think we can timeslide back
15:33:14 <kragniz> sigmavirus24: k1 has been and gone :P
15:33:24 <sigmavirus24> well we're releasing the document for kilo
15:33:32 <nikhil_k> yes, so k3
15:33:34 <sigmavirus24> the document's development didn't start with the rest of kilo
15:33:41 <mfedosin> btw, what will be after Z?
15:33:42 <sigmavirus24> so document-relative k-1
15:33:45 <nikhil_k> those are informal milestones so do not matter officially
15:33:46 <mfedosin> A again?
15:33:54 <sigmavirus24> mfedosin: AA ;)
15:33:59 <sigmavirus24> then AB, then AC =P
15:34:00 <mfedosin> then we have to wait 13 years
15:34:05 * sigmavirus24 doesn't actually know
15:34:15 <nikhil_k> greek characters
15:34:20 <nikhil_k> we need to move on
15:34:25 <sigmavirus24> nikhil_k: by then certainly everyone will support unicode ;)
15:34:29 <mfedosin> nikhil_k, :D
15:34:33 <nikhil_k> #topic stable/juno requirements sync with global requirements
15:34:47 <nikhil_k> ativelkov: ?
15:34:51 <ativelkov> yup
15:34:57 <jokke_> #link https://review.openstack.org/#/c/154728/
15:35:25 <ativelkov> ah, great
15:35:26 <jokke_> that's capping the requirements (finally)
15:35:40 <ativelkov> just wanted to ask what is the correct practice here
15:36:05 <jokke_> ativelkov: bot proposes, we verify that it does not break the hell loose and merge ;)
15:36:25 <ativelkov> is that the same for stable branches?
15:36:28 <nikhil_k> also, we are midful about the release date and freeze time
15:36:35 <nikhil_k> mindful*
15:37:12 <sigmavirus24> ativelkov: yes mostly because unexpected releases have been breaking things (see: half of oslo and eventlet for examples)
15:37:50 <jokke_> ativelkov: bot proposes to the stable/* just stable team +2+2+A
15:37:55 <nikhil_k> ativelkov: there was some discussion about not having to maintain 3 branches simultaneously. You might want to be on the lookout there. Try asking in cross project meetings on the upto data info.
15:38:11 <ativelkov> got it, thanks
15:38:28 <sigmavirus24> there's also a discussion on the ML about how we maintain stable/* requirements lists in openstack/requirements
15:38:38 <jokke_> nikhil_k: I think the unfortunate reality what has been promised to explore is 4 releases when Kilo comes out :(
15:38:40 <sigmavirus24> (you might notice some of these deps are equivalent to pins)
15:39:07 <nikhil_k> jokke_: wow, that's not fun!
15:39:10 <kragniz> jokke_: the more releases, the more fun!
15:39:24 <nikhil_k> can we move one?
15:39:28 <jokke_> nikhil_k: it's transition, but still
15:39:34 <jokke_> I think so
15:39:38 <ativelkov> yup
15:39:38 <nikhil_k> thanks
15:39:39 <nikhil_k> #topic Abandoning stale PS from review
15:39:45 <nikhil_k> jokke_: was that you?
15:39:49 <jokke_> yeah
15:40:01 <nikhil_k> http://comments.gmane.org/gmane.comp.cloud.openstack.devel/46352
15:40:06 <nikhil_k> https://etherpad.openstack.org/p/glance-cleanout-of-inactive-PS
15:40:43 <jokke_> so Nova is doing this automated (IIUC) after 4 weeks, Swift is sending chase e-mail out after 4 weeks and abandoning manually if no activity in 2 weeks from that
15:41:35 <jokke_> The take from the mailing list and X-project meeting at Tue was that it's reasonable and at least for now there won't be OS wide governing for this
15:41:51 <kragniz> jokke_: I thought nova stopped doing the automated abandon?
15:42:22 <jokke_> kragniz: at least what I understood from sdague's comment at tue it's scripted
15:42:42 <jokke_> kragniz: OS stopped the automatic 2week abandon which was on all
15:42:54 <kragniz> okay
15:42:56 * sigmavirus24 wonders if there's a way to automate a message to the ML asking for sponsors for older patch sets before abandoning
15:43:14 <nikhil_k> please no, that would create so much spam
15:43:19 <kragniz> sigmavirus24: the question is more can you do that without annoying everyone
15:43:28 <jokke_> sigmavirus24: I'd certainly not spam mailing list with any automation like that
15:43:37 <sigmavirus24> kragniz: it should be obvious that I care not about annoying people ;)
15:43:49 <nikhil_k> heh
15:44:03 <kragniz> I personally think the older reviews are not causing any trouble
15:44:04 <nikhil_k> jokke_: worth creating a poll on the ML discussion?
15:44:36 * sigmavirus24 realizes that it's probably best just to set up a collection of dashboards for people to use
15:44:51 <jokke_> also the main concern on the mailing list feedback in short was that someone might hurt their feelings if we drop their change after they have not responded to us for weeks ... which was at least on X-proj meeting pretty much discarded
15:45:10 <kragniz> sigmavirus24: (plug for http://goo.gl/eS05pD)
15:45:14 <nikhil_k> heh, I think gerrit can support such a filter (but not sure if one already exists/can be enabled)
15:45:47 <jokke_> again using automated filters removes all flexibility and smartness ... makes the situation just worse
15:46:08 <ativelkov> If I remember correctly, the concern was also about loosing real user-stories if we abandon something
15:46:20 <jokke_> if someone wakes up at the point when the change gets abandoned there is simple way to restore it without hassle
15:46:45 <nikhil_k> yes, that's the case. However, if we can omit WIP patch sets from being abandoned then it would solve it, right?
15:47:00 <nikhil_k> and that can be mentioned in the good practice guideline
15:47:13 <ativelkov> We may suggest the reviewers to create a launchpad bug or BP (if relevant) before abandoning the changes, so noce-to-have features remain in backlog
15:47:18 <kragniz> jokke_: yes, but it's a harder for someone else to find it later if it's abandoned
15:47:40 <nikhil_k> ok, we need to move on
15:47:57 <nikhil_k> Let's continue on the ML for now and get back on this next week if necessary
15:48:15 <nikhil_k> #topic Catalog Index service reviews
15:48:25 <nikhil_k> https://etherpad.openstack.org/p/catalog-index-service
15:48:28 <TravT_> On the follow page is a little diagram showing the patches related to index service: https://etherpad.openstack.org/p/catalog-index-service
15:48:42 <TravT_> You might need to zoom out a bit for the diagram to render correctly
15:48:57 <TravT_> One is really just an update on metadefs functionality (adding notifications), but is pretty much ready: https://review.openstack.org/#/c/148546/
15:49:06 <TravT_> Others are functionally very close to completion and serious test writing is starting up.
15:49:13 <nikhil_k> https://review.openstack.org/#/c/148546/
15:49:18 <TravT_> Would be much better to get reviews now so comments can be addressed before the mad end of cycle zuul rush where it takes multipe days to just check a patch.
15:49:36 <nikhil_k> cool, so we need reviews
15:49:56 * sigmavirus24 was working on that yesterday I think
15:50:02 <nikhil_k> #help review catalog index service patches
15:50:31 <TravT_> Thanks!
15:50:31 <nikhil_k> TravT_: do we have more updates or should we move on?
15:50:40 <nikhil_k> #topic glanceclient sorting
15:50:55 <nikhil_k> Please help mfedosin review https://review.openstack.org/#/c/120777/
15:51:09 <nikhil_k> That was my addition and that's pretty much it for now.
15:51:36 <mfedosin> currently we don't have support for sorting in glance client
15:51:55 <jokke_> mfedosin: when did that break?
15:51:55 <mfedosin> this patch implement it
15:52:16 <jokke_> mfedosin: or is our sorting done on the API server end?
15:52:24 <mfedosin> in v2 there is no sorting
15:52:41 <mfedosin> in client
15:53:09 <nikhil_k> anyways, we can discuss this on the review itself
15:53:16 <nikhil_k> #topic Reviews for zero downtime config reload
15:53:36 <mfedosin> thanks :) I will be appreciate
15:53:37 <nikhil_k> I think we need to get some feedback to these folks
15:54:05 <nikhil_k> https://review.openstack.org/#/c/127238/
15:54:13 <nikhil_k> https://review.openstack.org/122181
15:54:23 <nikhil_k> #topic Open discussion
15:55:01 <kragniz> we need reviews on the last couple of glanceclient patches for the next release
15:55:27 <nikhil_k> kragniz: do you have links handy so that people can see in the meeting logs?
15:55:29 <kragniz> #link https://launchpad.net/python-glanceclient/+milestone/v0.16.0
15:55:33 <nikhil_k> cool
15:55:34 <jokke_> nikhil_k: quick update request, what's the status on our client and store releases?
15:55:36 <nikhil_k> good enough
15:55:46 <mfedosin> folks, there is my spec about new sorting syntax https://review.openstack.org/#/c/155841/ can you check it out?
15:55:58 <nikhil_k> for store we were waiting on stuart's patch for ativelkov 's copy-from fix
15:56:00 <kragniz> also
15:56:05 <kragniz> #link https://review.openstack.org/#/c/157372/
15:56:17 <nikhil_k> but we can release today if that's not ready
15:56:19 <kragniz> nikhil_k: stuart's not going to have that ready in time
15:56:24 <hemanthm> nikhil_k, reminder:  maintainer for glance_store
15:56:26 <nikhil_k> okay
15:56:34 <nikhil_k> oh yes
15:56:38 <wayne_> any thoughts on this one would be appreciated: https://review.openstack.org/#/c/154229/
15:56:47 <nikhil_k> is anyone willing to volunteer as a maintainer for glance_store repo
15:56:57 <ativelkov> A question to sigmavirus24 and rosmaita: are we done with the semver discussion? :)
15:57:02 <nikhil_k> that way we can have multiple point of contacts for the release process
15:57:19 <kragniz> sigmavirus24: would that be mostly release management?
15:57:22 <hemanthm> nikhil_k, I'd be interested
15:57:25 <nikhil_k> hemanthm, you were interested, right?
15:57:30 <nikhil_k> okay, thanks
15:57:33 <nikhil_k> anyone else?
15:57:39 <sigmavirus24> ativelkov: if the plan is to support something in a broader scheme after adding semver (to at least get artifacts rolling) that's fine
15:57:41 <jokke_> nikhil_k: I think I have my hands full with current promises ;)
15:57:51 <kragniz> nikhil_k: I can do release stuff
15:57:56 <ativelkov> sigmavirus24: exactly
15:58:06 <sigmavirus24> Otherwise I still object to the fact that we're limiting artifacts versioning to such an extremely narrow group of potential users (since semver has no users at the moment, all users are potential)
15:58:09 <nikhil_k> ativelkov: it's upto sigmavirus24 now. rosmaita and I are on agreement
15:58:22 <sigmavirus24> s/semver/artifacts/
15:58:27 <nikhil_k> jokke_: ok, thanks!
15:58:30 <nikhil_k> kragniz: noted
15:58:48 <nikhil_k> #action add kragniz and hemanthm for glance_store release management
15:58:54 <sigmavirus24> nikhil_k: I can help if necessary but it sounds like hemanthm and kragniz are good
15:59:19 <ativelkov> nikhil_k: could you please comment on https://review.openstack.org/#/c/151466/ ? It has got 2 +2 but no +A, and it is blocking us
15:59:48 <sigmavirus24> ativelkov: probably people are waiting for the spec to be approved first
15:59:53 <kragniz> we're out of time, so move to #openstack-glance?
15:59:55 <jokke_> ok, time!
15:59:59 <jokke_> Thanks all
16:00:02 <nikhil_k> ativelkov: yes, I was waiting on the discussion. Thanks for the reminder!
16:00:14 <nikhil_k> Thanks all..
16:00:16 <nikhil_k> #endmeeting