14:01:58 <flaper87> #startmeeting Glance Drivers
14:01:58 <openstack> Meeting started Tue Oct  6 14:01:58 2015 UTC and is due to finish in 60 minutes.  The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:01 <openstack> The meeting name has been set to 'glance_drivers'
14:02:02 <flaper87> Courtesy Glance Drivers' meeting reminder: nikhil_k, flaper87, sigmavirus24, rosmaita, mclaren, dhellmann, jokke_
14:02:02 <nikhil> o/
14:02:10 <flaper87> o/
14:02:12 <nikhil> thanks for the reminder flaper87
14:02:30 <rosmaita> o/
14:02:31 <flaper87> nikhil: w000h00! I really love the courtesy pings
14:02:38 <nikhil> :)
14:02:47 <flaper87> The only reason I have a calendar is so I can ignore it
14:02:54 <rosmaita> flaper87: +1
14:02:56 <nikhil> haha, true :P
14:03:12 <flaper87> ok, I guess it'll be the 3 of us for now
14:03:19 <flaper87> #topic Agenda
14:03:22 <flaper87> #link https://etherpad.openstack.org/p/glance-drivers-meeting-agenda
14:03:22 <rosmaita> i need an app that will give me an electric shock at meeting time
14:03:29 <flaper87> rosmaita: ++
14:03:32 <flaper87> that'd be awesome
14:03:39 <rosmaita> ESaaS
14:03:44 <flaper87> and it feel just into the agenda topic, we should discuss that instead
14:03:46 <flaper87> :P
14:03:58 <flaper87> #topic spec-lite (or no spec) (flaper87)
14:04:25 <flaper87> I think it's time to start discussing spec-lite
14:04:38 <nikhil> ++
14:04:46 <flaper87> I was reviewing our processes and other project's
14:05:09 <flaper87> I talked to johnthetubaguy and got feedback from him. He mentioned that Nova doesn't use specs at all for small specs but just blueprints
14:05:25 <flaper87> and it seems like a good idea to me but I obviously want to know your thoughts
14:05:45 <flaper87> The blueprint is *always* required and that's what we use for rel-mgmt anyway
14:05:56 <flaper87> The description seems to be enough for a lite spec
14:06:21 <flaper87> Thoughts?
14:06:24 <rosmaita> i'm ok with that, if the description isn't enough, then we know a full spec is needed
14:06:25 <nikhil> yes and yes though I have one feedback that seems important to me
14:06:35 <flaper87> rosmaita: ++
14:06:37 <flaper87> nikhil: shoot
14:06:47 <nikhil> BLueprints are not discoverable and not a good source of reference
14:07:11 <flaper87> that is great feedback
14:07:16 <nikhil> for example -- say we have 3 specs that deal with image status changes (state transition -- just an example)
14:07:17 * sigmavirus24_awa is here, sorry for being late
14:07:33 <nikhil> having to refer all 3 and say that they are compatible and
14:07:44 <nikhil> that they allow changes that fit into the cycle goals
14:07:58 <nikhil> and that they won't create a blackhole to further change
14:08:06 <nikhil> changes* -- becomes rather difficult
14:08:23 <nikhil> and to concise thoughts and provide a directional feedback becomes quite tough
14:08:36 <flaper87> I wonder how important is discoverabilty and reference for these kind of specs
14:08:42 <nikhil> one thing that we could do is appoint someone duty to import the change logs from BPs into specs
14:08:48 <flaper87> I mean, they are spec lite and the blueprint is kind of a formality
14:08:55 <flaper87> please, correct me if I'm wrong
14:09:01 <nikhil> sure, one more example
14:09:07 <nikhil> quite recent
14:09:13 <nikhil> the image member notification change
14:09:22 <flaper87> but, I'd expect the commit messages for these spec-lite to be lenghty and almost have the whole spec in it
14:09:24 <flaper87> :D
14:09:29 <nikhil> that allowed changes to the domain proxies in a way that someone could mis interpret
14:09:51 <nikhil> I wonder if that sort of thing would re trigger another change that reverses it
14:10:14 <nikhil> and we do find that in many a cases people propose a change after something that is opposite has been merged
14:10:32 <nikhil> historical references become a tribal knowledge
14:10:46 * jokke_ is lurking
14:11:15 <nikhil> but I am okay if we want to redact the process and try a no-spec thing to see how things work
14:11:31 <flaper87> I think that feedback is awesome
14:11:34 <nikhil> my feedback was observational and not necessarily future proofing
14:11:46 <nikhil> Thanks!
14:12:07 <flaper87> Would it be fair to say: "lets give this a try BUT for spec lite, we ought to be nitpicky on commit messages" ?
14:12:12 <rosmaita> i wonder whether we can require a post-spec, maybe taking the commit message from the spec-lite?
14:12:23 <rosmaita> that way we'd get the info into the specs repository
14:12:28 <nikhil> rosmaita: I was proposing something along those lines
14:12:48 <nikhil> or even to glance doc/source/*
14:12:57 <jokke_> can we just state then that if the bp is proposed without spec it needs to be clear and short enough to have that description in the commit message?
14:13:00 <nikhil> pick the important changes and put them in the prj repos
14:13:18 <flaper87> jokke_: yeah, that's kinda what we are headed towards here
14:13:33 <rosmaita> yeah, key thing is to have everything in one place for new devs to look at when they want to get up to speed on the glance project
14:13:37 <jokke_> like not assume and not leaving the room for guessing, just plain and simple ;)
14:14:01 <flaper87> The good thing about this is that, if a driver thinks a tiny spec might be useful, the commit message can be copied over by the driver himself/herself
14:14:10 <nikhil> flaper87: also, for worthy spec lite changes, I presume we will have some sort of major impact to one of the dimensions of the prj -- say developer, deployer, security, notification, api etc ?'
14:14:42 <jokke_> one question 'though ... how that will affect the review workflow
14:14:53 <flaper87> mmh, I'd say that major impacts should require a full spec
14:15:00 <nikhil> jokke_: +1 to using wisdom where appropriate. I think we are sorta agreeing this for a generic case
14:15:11 <jokke_> with the specs (regardless how long and detailed it is) it's quite clear when it's ok to start merging code
14:15:39 <flaper87> jokke_: mmh, not sure I follow
14:15:51 <jokke_> I'm one of us that didn't get that much exposed to the workflow when bps were purely used
14:15:54 <flaper87> I mean, if the blueprint is approved, the patches can be merged
14:15:57 <nikhil> flaper87: so let's take the example of the notification change. That affects notifications in a drastic way -- there were no member notification and  now they exist. Should that be a full spec?
14:16:35 <jokke_> so how I verify that there is agreement to get that feature in, when it has not gone through the spec process and reviews
14:16:47 <nikhil> jokke_: I think we will have to be prompt on setting the status of "direction approved" on the BP when it's okay to start merging code
14:16:54 <flaper87> nikhil: mmh, I'd say no. I mean, it's an addition but it's not changing existing ones.
14:17:04 <jokke_> the reason why everyone moved to specs was because the workflow was difficult to follow
14:17:20 <flaper87> I guess we could restrict the impact group list
14:17:41 <flaper87> as in: if it affects dev, deployer, security, api then write a spec
14:17:48 <nikhil> flaper87: so, for such cases I think we should enforce adding a section to the BP that describes the impact to notification so that the driver copy pasting the code doesn't have to second guess what's going on... just saying..
14:17:49 <jokke_> another pointer I'd like to raise is that relying on bps would work for while but I'd like to remind that there is continuous work ongoing to move OpenStack away from Launchpad
14:18:02 <flaper87> but the same reasoning should happen even if we have an actual spec considered light
14:18:16 <flaper87> nikhil: oh yes, the section should be there
14:18:20 <jokke_> the specs repos are easy to maintain and keep regadless what release and bug tracking system is being used
14:18:35 <flaper87> ok, lets give this one more week. We gotta discuss other topics
14:18:41 <flaper87> sorry for timeboxing the topic
14:18:42 <jokke_> nikhil: ok, thnx
14:18:47 <nikhil> flaper87: one more thing happens with BPs is that they are spammed a lot. So we have to continuously triage. As LP API is exposed.
14:18:52 <sigmavirus24> alternate idea: what if we use a different directory in the specs repo with a different template?
14:18:55 <flaper87> Lets put some thoughts on it and discuss it again next week
14:19:05 <sigmavirus24> mitaka/lite/
14:19:10 <sigmavirus24> (for example)
14:19:10 <rosmaita> sigmavirus24: ++
14:19:18 <rosmaita> i think that's what jokke_  was getting at
14:19:21 <flaper87> sigmavirus24: I'd like to avoid proposing more patches to that repo and increasing the review queue
14:19:30 <nikhil> sigmavirus24: +1 ( I was saying either that or put it in glance prj repo)
14:19:41 <nikhil> the adv to putting in glance repo is
14:19:43 <flaper87> I mean, not *I* but that's the idea behind not having a spec at all
14:19:44 <jokke_> I think that's what I proposed few weeks ago when this discussion was agreed to be postponed until Mitaka ;)
14:19:51 <nikhil> the code and the spec can go in together in one review
14:19:55 <sigmavirus24> flaper87: but we're still calling them specs which will cause lots of confusion
14:20:04 <sigmavirus24> if we don't want to use that repo we need to really be discussing this on the ML
14:20:16 <jokke_> sigmavirus24: ++
14:20:17 <sigmavirus24> nikhil: that may work too, I'm not sure I like that
14:20:29 <flaper87> sigmavirus24: wait, it's just for spec lites, not for all the specs
14:20:36 <sigmavirus24> flaper87: I get that
14:20:42 <flaper87> sigmavirus24: and yes, that's the second part of the discussion
14:20:49 <sigmavirus24> I just don't think any of us are on the same page and the wider community may have better ideas
14:20:49 * nikhil shuts up and waits for next week discussion on this
14:20:54 <flaper87> One reason I brought this up is because it seems to be working for nova
14:20:54 * sigmavirus24 will shut up too
14:21:07 <sigmavirus24> flaper87: ah, I think I missed the description of how nova does this
14:21:14 <flaper87> now, we really need to change topic! Lets discuss this again next week
14:21:15 <rosmaita> maybe we should all take action items to look at how nova does this
14:21:21 * sigmavirus24 also doesn't work on nova so he may just have been expected to know it from experience and doesn't
14:21:23 <flaper87> #topic     https://review.openstack.org/#/c/229891/ (flaper87) (Nova v1 -> v2)
14:21:24 * sigmavirus24 nodes
14:21:33 <nikhil> woohoo!
14:21:40 <flaper87> ok, that's the spec to make nova use v2, it was merged
14:21:55 <flaper87> It's a mix between the old spec and the one for Liberty
14:22:02 <flaper87> There are some patches up already
14:22:03 <nikhil> \\o \o/ o//
14:22:04 <flaper87> w000h00
14:22:25 <flaper87> moving on unless there are questions
14:22:27 <flaper87> :D
14:22:39 <nikhil> flaper87: were there amendments going on that?
14:22:46 <nikhil> I may have read the commentary wrong
14:22:49 <jokke_> flaper87: was that done via backmail, bribery, combination of those or via some other back magic? :P
14:23:03 <flaper87> jokke_: ssssssssssssssssshhhhhhhhhhhh
14:23:13 <flaper87> nikhil: nope, just nits here and there because I can't english
14:23:24 <nikhil> LOL
14:23:25 <nikhil> ok
14:23:32 <flaper87> if there are scary things in there, please, do tell so they can be fixed before the code is out
14:23:37 <flaper87> ok, moving on
14:23:40 <flaper87> #topic     https://review.openstack.org/#/c/230970/ (Use approved specs dir) (flaper87)
14:23:47 <nikhil> ++
14:23:57 <nikhil> (to scary things)
14:24:21 <flaper87> It's pretty straightforward. I think we should put approved patches under approved and then move them under `implemented`
14:24:30 <flaper87> That way we know what was actually implemented
14:24:34 <nikhil> works for me
14:24:51 <jokke_> flaper87: so new specs should be proposed against approved, right?
14:24:53 <flaper87> in the process of checking Liberty patches, I found some that weren't implemented and they were still in the Liberty folder. This should help for future releases
14:24:58 <flaper87> jokke_: correct
14:25:10 <flaper87> s/releases/cycles/
14:25:17 <sigmavirus24> +1 flaper87
14:25:20 <rosmaita> +1
14:25:26 <flaper87> sweet
14:25:42 <flaper87> #topic https://review.openstack.org/#/c/206431/ <- (rosmaita) this is a Nova spec, not a Glance spec, but I'd like to talk about it briefly if there's time
14:25:45 <flaper87> rosmaita: floor is yours
14:25:47 <nikhil> nova does this too
14:26:06 <flaper87> nikhil: yeah, I've been researching a bit lately by looking into other projects
14:26:09 <rosmaita> just want to point out a nova spec
14:26:21 <rosmaita> https://review.openstack.org/#/c/206431/
14:26:24 <nikhil> gotcha
14:26:39 <jokke_> rosmaita: that's the inherited properties spec?
14:26:40 <rosmaita> it concerns property protectrions
14:26:46 <rosmaita> jokke_: yes
14:26:58 * jokke_ likes that spec
14:27:07 <rosmaita> so the proposal is that a config option be added to nova so it uses admin creds for adnim-protected properties
14:27:08 <nikhil> rosmaita: so, is a service token the key objection at this point?
14:27:15 <rosmaita> nikhil: not really
14:27:21 <rosmaita> but, it's a problem for cinder, too
14:27:22 <flaper87> I like it too but I won't deny that using admin to write the properties worries me
14:27:41 <nikhil> eh
14:27:45 <rosmaita> and someone brought up that it's a pain to keep the config potion and the prop protections config coordinated
14:28:01 <flaper87> The fact that you need to make that in 2 steps w/ 2 different users probably means that there's something missing somewhere
14:28:12 <rosmaita> so i just want to mention that maybe we oculd think of a better / more general solution
14:28:23 <flaper87> rosmaita: ++
14:28:26 <rosmaita> but, we also already have a lot for mitaka
14:28:33 <flaper87> rosmaita: that's true
14:28:34 <rosmaita> so the current spec could be short term
14:28:40 <rosmaita> would work for nova
14:28:42 <flaper87> I think we could let this go as a short term solution
14:28:49 <rosmaita> but worth brainstorming "the future"
14:28:57 <flaper87> and then I'll shut the #@$#@$ up because I'm basically saying the same thing you're saying
14:28:59 <rosmaita> or maybe discuss with cinder and others at the summit
14:29:09 <rosmaita> (sorry, mytyping is slow)
14:29:24 <jokke_> flaper87: yeah ... there is the fact that we still have no idea if it was random guy wiht our client or another service doing the call ;)
14:29:44 <nikhil> hmm, I think a service token would help in  so many ways
14:29:48 <rosmaita> i may propose something for design summit if we are light on topics
14:29:56 <nikhil> w/ re-uploads too
14:30:04 <flaper87> rosmaita: as of now, we are light on topics
14:30:04 <rosmaita> but, yeah some kind of service token, or combo token, or something
14:30:19 <nikhil> flaper87: should we discuss mid-cycle sometime soon?
14:30:24 <rosmaita> ok, i will slap in a paragraph and people can + or - it
14:30:32 <jokke_> rosmaita: ++
14:30:36 <nikhil> I think planning it early would help, last time was a BIG PAIN
14:30:39 <flaper87> nikhil: yup, I was planning to do that as soon as we get the summit schedule done
14:30:44 <nikhil> gotcha
14:30:45 <flaper87> nikhil: agreed
14:31:03 <flaper87> hopefully this next week/the one before the summit
14:31:06 <nikhil> the reason to bring this up was if not design summit the above topic can go to mid-cycle as fall back
14:31:26 <nikhil> cool, thanks!
14:31:36 <rosmaita> i'm behind on finishing the new-import spec, will have it up before Thurs meeting
14:31:42 <flaper87> ok, we're out of time!
14:31:47 <nikhil> rosmaita: +1
14:31:48 <flaper87> rosmaita: please, I'll give you candies
14:31:51 <flaper87> and whisky
14:31:57 <rosmaita> i like whisky
14:31:57 <flaper87> well, not if I drink it first
14:32:00 <flaper87> ok
14:32:02 <flaper87> ok
14:32:02 <rosmaita> save me a sip
14:32:06 <flaper87> I'll give you whisky
14:32:10 <flaper87> #endmeeting