21:03:23 <ttx> #startmeeting crossproject
21:03:23 <openstack> Meeting started Tue Dec  9 21:03:23 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:27 <openstack> The meeting name has been set to 'crossproject'
21:03:36 <morganfainberg> o/
21:03:37 <kragniz> o/
21:03:39 <ttx> I might need you to do John hot spare again
21:03:42 <ttx> mikal: ^
21:03:49 <ttx> Our agenda for today:
21:03:52 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:03:59 <mikal> ttx: sure
21:04:03 <ttx> #topic Convergence on specs process
21:04:09 <mikal> (Although I have to duck out a littler early)
21:04:25 <ttx> So this was put on the agenda by johnthetubaguy but he is not around
21:04:31 <jungleboyj> o/
21:04:32 <maishsk> ttx: again....
21:04:35 <ttx> I'll try my best to drive the discussion anyway
21:04:40 <mikal> I can help too
21:04:43 <ttx> so that we don't postpone it twice
21:05:07 <ttx> So the idea is to continue the cross-project session on specs we had in Paris
21:05:24 <bknudson> is there an etherpad? I didn't make it
21:05:25 <ttx> and see which practices may be interesting to apply to everyone
21:05:29 <asalkeld> is there a link to a suggestion to what we are converging to
21:05:31 <ttx> (if any)
21:05:36 <eglynn> ttx: can you tl;dr the outcome of the session in Paris
21:05:37 <SlickNik> o/
21:05:40 <russellb> IIRC, first step was get Blueprints wiki page up to date for all projects
21:05:53 <dhellmann> #link https://etherpad.openstack.org/p/kilo-crossproject-specs
21:05:54 <russellb> and then see if there were actually differences to deal with and discuss
21:06:02 <ttx> also which differences are useful and which is just superfluous
21:06:06 <russellb> yeah
21:06:20 * ttx tries to find the etherpad from that session
21:06:35 <dhellmann> ttx: ^^
21:06:41 <mikal> I'd be interested in if other projects have soemthing better than procedural -2's as well
21:06:46 <ttx> dhellmann: thx!
21:07:05 <notmyname> here
21:07:28 <ttx> Maybe first step is to look at https://wiki.openstack.org/wiki/Blueprints
21:07:36 <ttx> "Spec + Blueprints lifecycle" chapter
21:07:47 <ttx> and see who actually follows that, if anyone
21:08:06 <ttx> 'Upload a design specification in the "specs/<release>" folder in $PROJECT-specs'
21:08:08 <mikal> ttx: there are minor diffs for nova in that
21:08:12 <ttx> -> nova uses approved/ implemented/
21:08:15 <mikal> ttx: things like paths being wrong in those instructions
21:08:22 <mikal> ttx: we also have a per-release template
21:08:38 <mikal> ttx: we also don't remove non-completed specs
21:08:39 <devananda> ttx: we have been mostly following it, though mistakes are getting made (even by me)
21:08:44 <jungleboyj> That looks like the lifecycle that is used by Cinder
21:08:46 <mikal> ttx: we instead move implemetned specs to that different directory
21:08:47 <dhellmann> mikal: why do you track the implementation status in 2 places?
21:08:57 <ttx> mikal: I can see a few drawbacks in switching spec location at implementation time
21:09:03 <mikal> dhellmann: as in the directory move?
21:09:06 <dhellmann> mikal: yes
21:09:13 <SlickNik> ttx: we've been following it for Trove as well.
21:09:16 <dhellmann> mikal: why not just use the blueprint for that?
21:09:26 <mikal> dhellmann: because it was felt that it would be confusing to operators and other non-dev consumers if leave the specs repo in an inconsistent state
21:09:35 <dhellmann> ok
21:09:36 <mikal> dhellmann: we actively push operators to the specs repo
21:09:37 <notmyname> at the summit swift proposed a change in flow for specs https://github.com/openstack/swift-specs/blob/master/README.rst
21:09:43 <mikal> dhellmann: but then don't explain that it might be a pack of lies
21:09:56 <devananda> ttx: ironic also has a /backlog/ directory now, for things we know we won't do this cycle, but want to record
21:10:01 <mikal> That wiki page also doens't mention backlog specs, which we stole from Keystone
21:10:03 <morganfainberg> i personally do not like the "move" the spec when implemented.  - i would, if anything, update incomplete specs with a "incomplete" status?
21:10:04 <dhellmann> mikal: yeah, ok, that does make some sense. I'd almost drop blueprints at that point.
21:10:17 <morganfainberg> in the spec.
21:10:21 <mikal> dhellmann: we need bps for mechanical release reasons though
21:10:30 <mikal> dhellmann: I agree this isn't perfect
21:10:32 <dhellmann> morganfainberg: in oslo we just delete them if they aren't done, but we haven't had any "half done" ones yet
21:10:33 <thingee> ttx: cinder just removes the specs that weren't completed in the release.
21:10:38 <dhellmann> mikal: yeah, true
21:10:43 <jokke_> quick comment based on the discussion on the etherpad. One thing I really like about the specs is that as it's just another git repo you can propose changes. I think it would benefit all to have the spec approved on principal quite early and redefined based on the implementation on the way
21:11:01 <ttx> OK, let's focus on that particular bit, the use of a specific "implemented" directory
21:11:01 <morganfainberg> dhellmann, we have had a couple half-done and we just proposed a <next release>/<same spec> highlighting what was done and what wasn't
21:11:04 <devananda> I don't know if it would work for larger projects, but in Ironic we're not approving specs until they are very likely to be landable in the cycle
21:11:08 <ttx> who else uses that ? just nova ?
21:11:10 <morganfainberg> if it wasn't touched at all, i'd delete it/move it back to backlog
21:11:11 <dhellmann> morganfainberg: that makes sense
21:11:11 <eglynn> morganfainberg: agree on not moving, surely that breaks the specification URL field in LP?
21:11:16 <dhellmann> devananda: ++
21:11:29 <morganfainberg> devananda, that is the goal for keystone as well.
21:11:33 <devananda> as a result, we haven't had to look at a separate /implemented/ dir
21:11:33 <notmyname> ttx: we have "done" and "in_progress" in swift
21:11:36 <morganfainberg> devananda, unless it's proposed to backlog
21:11:44 <devananda> morganfainberg: right - backlog is not release specific
21:11:52 <morganfainberg> (nothing proposed there yet for us, but planned this cycle)
21:11:55 <devananda> specs/[backlog, juno, kilo]
21:11:58 <asalkeld> i think it's dumb using the spec repo to store state when lp is doing that
21:12:04 <notmyname> ttx: implemented is something specifically didn't want because we didn't want to confuse specs with docs
21:12:12 <jokke_> asalkeld: +1
21:12:14 <eglynn> asalkeld: +1
21:12:21 <asalkeld> maybe just remove the kilo/juno folder too
21:12:28 <ttx> specs is just that.. a spec. Not a feature list
21:12:28 <mikal> asalkeld: I think that's an overly emotive way of putting it
21:12:40 <asalkeld> maybe
21:12:44 <devananda> I find it helpful to break specs down by cycle
21:12:44 <notmyname> ttx: and "done" in swift-specs is basically "we're not looking at this any more so it's an effective trash can but kept for history"
21:12:45 <ttx> But I can see how people may confuse the two
21:12:49 <mikal> So, we have ops people deep linking to specs
21:12:56 <mikal> We're just going to delete stuff and let them get a 404?
21:13:06 <morganfainberg> asalkeld, i wouldn't remove the history, we make previous releases appear differently via sphinx magic
21:13:12 <asalkeld> sorry, just seems like trying to mirror stuff unnecessary
21:13:26 <ttx> mikal: how does that deeplink survive the move to "implemented/" ?
21:13:38 <mikal> ttx: we have a sphinx plugin which creates redirects
21:13:47 <devananda> ttx: this does raise a question for me. I see some blueprints "specification URL" pointing to gerrit reviews
21:13:47 <mikal> ttx: its not very good, but it works
21:13:56 <morganfainberg> asalkeld, previous releases and implemented specs (keystoneclient does move spec to "implemented" because they are not the same as the named releases) we do: http://specs.openstack.org/openstack/keystone-specs/implemented.html
21:14:12 <devananda> ttx: but I dont know where that practice came from
21:14:12 <ttx> devananda: spec2bp.py should overwrite that :)
21:14:13 <morganfainberg> implemented/previous releases
21:14:20 <devananda> ttx: i actually find it very helpful
21:14:28 <asalkeld> also any reason the specs have to be in a seperate repo? it would make it easier to keep uptodate if they were in-tree
21:14:36 <dhellmann> mikal: that's actually a very good point. maybe this cycle I'll move all of the incomplete ones over to an "incomplete" folder
21:14:37 <ttx> mikal: not askign anyone to drop anything yet. Just trying to see if there can be more common practices.
21:14:38 <devananda> ttx: for not-yet-approved blueprints to have a URL pointing to the spec review
21:14:44 <mikal> asalkeld: we have different core groups for specs
21:14:45 <ttx> ops don't look at nova's specs in a vacuum
21:14:46 <SlickNik> devananda: +1
21:14:49 <devananda> asalkeld: separate core group
21:14:57 <ttx> so they try to make sense of specs.o.o ovberall and can't
21:15:01 <devananda> ironic has spec-cores who are not ironic-cores
21:15:17 <asalkeld> so just permissions issue?
21:15:19 <mtreinish> asalkeld: also some spec repos cover more than one project
21:15:23 <devananda> because there are operational stake-holders who grok the architecture but don't neceessarily write or review code on a daily basis
21:15:40 <morganfainberg> devananda, i expect keystone to also have that. and we also have our API spec in the -specs repo. That does not belong in-tree for the code
21:16:01 <ttx> devananda: the whiteboard should get autopopulated by Gerrit with review links as long as you reference the BP in the commit message
21:16:13 <morganfainberg> devananda, that wasn't meant to be directed to you ^ just to the channel in general
21:16:19 <devananda> ttx: for --blocked specs, could spec2bp set the URL to the review?
21:16:23 <mikal> I'd be interested in how (if at all) other PTLs are encouraging operators to come on in-review specs
21:16:30 <thingee> dhellmann: if a spec isn't going to happened because it's abandoned, does it make sense just to delete it? It's in git history, you can retrieve it back. I guess you don't have the convenience of searching through a directory for keywords if something was discussed before.
21:16:35 <mikal> s/come/comment/
21:16:38 <ttx> devananda: oh, you mean the spec review ?
21:16:45 <devananda> ttx: yes
21:16:51 <ttx> devananda: that.. kind of makes sense
21:16:52 <dhellmann> thingee: yeah, I was thinking of mikal's point about people having links pointing to them
21:17:05 <morganfainberg> mikal, we haven't had a large issues convincing operators to do so for keystone. but we started with operators helping us with the spec process (UofKent, etc)
21:17:21 <ttx> devananda: maybe add it as comment to https://review.openstack.org/#/c/108041/
21:17:29 <dhellmann> mikal: I talked it up with some folks at the summit, especially about the work on oslo.log. Not takers, yet.
21:17:42 <mikal> morganfainberg: we have a few faithful operators, but not a lot of smaller deploys are commenting
21:18:11 <mikal> People do tell me they like the blog posts, but then don't actually comment on reviews
21:18:17 <mikal> And they're a fair bit of work to write
21:18:46 <thingee> I have not had any help on cinder specs from operators. mostly just other vendors making sense of an interface that works for everyone. I would love operators feedback though.
21:18:51 <morganfainberg> mikal, it might also be the blog posts are sufficient - the specs are less important in direciton because they are smaller they can be nimble about working around / incorporating the spec.
21:19:06 <morganfainberg> mikal, that is just wild supposition on my part though
21:19:06 <ttx> OK, what about specs.o.o TOC differences between projects ? Those seem more gratuitous (cc maishsk)
21:19:11 <devananda> ttx: posted
21:19:12 <mikal> morganfainberg: yeah, it might also be that they're completely happy
21:19:15 <mikal> Its hard to tell from the outside
21:19:31 <mikal> ttx: define TOC differences?
21:19:37 <maishsk> ttx: the formatting is different - which is confusing
21:19:39 <mikal> ttx: as in the number of headins displayed?
21:19:42 <ttx> http://specs.openstack.org/openstack/heat-specs/
21:19:45 <morganfainberg> mikal, ask cburgess next time as well, he's a good voice for the smaller (until recently) deployer groups.
21:19:46 <ttx> http://specs.openstack.org/openstack/nova-specs/
21:19:48 <Rockyg> dhellmann:  working on logging-->you'll see start this week
21:19:59 <dhellmann> Rockyg: cool
21:20:04 <ttx> mikal: confusing differences in navigation
21:20:06 <morganfainberg> mikal even though he contributes code as well
21:20:07 <ttx> reported by maishsk
21:20:08 <devananda> mikal: to your question, I'm not sure what to suggest. I have a small set of involved operators, so I poke them directly when I see things that affect them. Also, they have an engaged dev team ...
21:20:09 <jungleboyj> thingee: +1
21:20:15 <cburgess> Did someone say my name?
21:20:21 <mikal> cburgess: no
21:20:22 <mikal> :P
21:20:32 <cburgess> Fine :P
21:20:40 <dhellmann> ttx: yeah, I think someone should just submit formatting changes to fix those. Maybe maishsk can do that?
21:20:48 <mikal> maishsk: so, you're confused because the indx pages look different?
21:20:57 <mikal> maishsk: isn't that a largely cosmetic problem?
21:21:02 <maishsk> mikal: not only me
21:21:17 <jokke_> ~/msg Rockyg hey there! Erno here, do you have a moment after the meeting to sync up?
21:21:18 <asalkeld> i like the flat layout
21:21:18 <morganfainberg> maishsk, what specifically is confusing? mor than "there are differences"
21:21:30 <maishsk> mikal: essentially yes cosmetic
21:21:32 <jokke_> darn
21:21:51 <asalkeld> first world problems :-O
21:21:58 <maishsk> morganfainberg: the format of the page, why are some of the projects different - layout is different.
21:22:01 <mikal> So, bigger projects are always going to want to split per release I would think
21:22:13 <mikal> We had nearly 100 specs in Juno for Nova
21:22:18 <ttx> I think per-cycle split is something we can standardize on
21:22:20 <maishsk> If the purpose was to make it easier for people to read, I would have to say we are missing the point
21:22:29 <ttx> even if you have 5 it still makes sense
21:22:37 <morganfainberg> ttx, ++
21:22:40 <ttx> to at least question if you should copy them over
21:22:42 <thingee> ttx: +1
21:22:44 <maishsk> ttx: ++
21:22:49 <SlickNik> mikal / ttx +1 to per cycle split.
21:22:51 <notmyname> ttx: can we not be prescriptive yet? specs is still something very new, and it's a learning process
21:22:58 <notmyname> -- to per cycle split
21:23:15 <asalkeld> notmyname, +1
21:23:26 <mikal> To be honest I am not sure if I see a lot of value in being proscriptive
21:23:28 <ttx> notmyname: I would only prescribe consensual things at this point. Can you explain your -- ?
21:23:31 <maishsk> dhellmann: If you are willing to hold my hand (at least in the beginning) - and not have you all bash me on reviews - I would be happy to give it a shot
21:23:31 <mikal> The templates are differnt as well
21:23:44 <mikal> Are we goign to force all projects to use the same template
21:23:45 <mikal> ?
21:23:51 <maishsk> mikal: Why not?
21:24:00 <devananda> ++ to per-cycle split in the TOC. I dont care so much if it's in the file layout
21:24:05 <maishsk> standardization.....
21:24:05 <dhellmann> maishsk: I can help you with the oslo-specs change, if one is needed.
21:24:06 <notmyname> making every project use the same structure means that there are less ways that are being experimented. and certainly all projects aren't going to fit the same mold as to what works best (different review loads, different level of activity, etc)
21:24:09 <mikal> maishsk: because different projects have different things to be concerned about
21:24:12 <ttx> mikal: I think they may end up sharing best practices by copying themselves a bit more
21:24:20 <devananda> but also, I don't think it matters enough yet to proscribe it to other projects
21:24:23 <ttx> but i would let them evolve separately
21:24:38 <dhellmann> yeah, oslo has very different concerns for graduating a library than nova does when adding a feature
21:24:43 <devananda> mikal: definitely not the same template across projects
21:24:47 <mikal> Exactly
21:25:01 <maishsk> mikal: are the format of blueprints submitted across projects different - or do they all have the same base structure?
21:25:02 <devananda> there are certain things some projects care about uniquely, because they are unique
21:25:11 <mikal> Frankly, I'm very disinterested in being told I can't have a "project priority" heading because its not in the global template (for example)
21:25:12 <ttx> notmyname: on the other hand, we don't want people to learn 15 different ways of posting a spec
21:25:25 <mikal> maishsk: blueprints are often a single sentence. They have no format.
21:25:30 <ttx> 15 different templates is ~ok
21:25:38 <ttx> 15 different processes... not so much I think
21:25:49 <dtroyer> The entire community is traditionally cargo-cultish (see *client).  Having at least a default starting point is of value here
21:25:50 <devananda> ttx: ++
21:25:51 <asalkeld> ttx there is a template in each project
21:25:55 <maishsk> mikal: I am not saying the same information has to be the same - just presented 'cosmetically' the same way
21:26:03 <jokke_> maishsk: is there a reason we wanted to step out of the scope of blueprint ;)
21:26:06 <dhellmann> dtroyer: we do have a cookiecutter template for new specs repositories
21:26:07 <ttx> asalkeld: that's fine. Instructions can be "copy and edit template
21:26:08 <asalkeld> you grab the template and fill it in
21:26:08 <ttx> "
21:26:14 <fungi> think infra specs... they span countless infra projects none of which participate in the integrated release cadence
21:26:23 <ttx> but if they can't tell where to get the template... less fun
21:26:29 <devananda> same formatting guidelines, same proposal and review process for specs, but variation in templated sections and guidelines therein
21:26:45 <devananda> is what seems to make sense to me
21:26:45 <mtreinish> dtroyer: http://git.openstack.org/cgit/openstack-dev/specs-cookiecutter/
21:26:57 <maishsk> devananda: exactly - format should be the same across the board
21:27:04 <bknudson> have there been complaints from people submitting specs to 15 projects?
21:27:08 <notmyname> ttx: specs are a way to do communication. not a box to check off. we're _really_ early as a community figuring out if specs are good and how to do them better. I'm asking that we let the specs experiment continue to run before formallizing a process
21:27:16 <bknudson> those are probably the folks who it would be interesting to hear from
21:27:20 <dhellmann> bknudson: the complaints are coming from people trying to read them
21:27:28 <devananda> bknudson: only one that I know of (osprofiler)
21:27:31 <dhellmann> notmyname: ++
21:27:36 <ttx> notmyname: I'd agree with that.
21:27:45 <mikal> I think annegentle had a spec in every repo as well?
21:27:50 <dtroyer> notmyname: ++  … I understood this to be a search for commonality in what we have so far
21:27:53 <dstanek> what are the complaints exactly? can people not find what they are looking for?
21:28:13 <dhellmann> as another experiment, I put together a sphinx extension to ensure that the spec name matches a blueprint name in launchpad. I'm adding it to oslosphinx to make it easy for projects to adopt - https://review.openstack.org/#/c/140362/6
21:28:17 <devananda> notmyname: ++
21:28:25 <ttx> notmyname: Iat this point I just want to reduce accidental / gratuitous changes that are not there for a good reason and hurt navigability by people outside of projects, like what maishsk reported with index pages all looking different
21:28:27 <devananda> dhellmann: oh, neat. that'll solve an issue I've bumped into this week :)
21:28:45 <Rockyg> so, basic outline and minimum contents across all projects, then notmyname can experiment on top of it
21:28:49 <ttx> We are not done with experimenting yet
21:29:05 <thingee> dhellmann: thank you
21:29:24 <dhellmann> devananda, thingee : I'll try to get that merged soon and cut a release so you can try it out
21:29:25 <SlickNik> dhellmann: That's pretty neat. Will take a closer look, thanks!
21:30:28 <notmyname> ttx: actually, isn't it an important question as to who specs are for? arent' they for the contributing community? isnt' that what we're optimizing for (instead of "external" communication)? maybe that's still part of the expirament
21:30:30 <jungleboyj> dhellmann: +1  Cool
21:30:56 <jokke_> notmyname: +1
21:31:00 <mikal> notmyname: I think both audiences are important to be honest.
21:31:00 <ttx> notmyname: I think the concern is about ops getting involved in specs
21:31:08 <Rockyg> specs make it easier for the non coding community to participate
21:31:10 <ttx> they are typically going cross-project
21:31:23 <maishsk> ttx: notmyname why is that a concern?
21:31:24 <mikal> notmyname: I very much want ops to tell us we're on the wrong track before we get too far into implementation of a feature
21:31:31 <Rockyg> ttx: ++
21:31:33 <ttx> and differences are hurtign their experience. Not fatal, I agree, just creating some friction
21:31:36 <maishsk> mikal: +++++
21:31:51 <mikal> ttx: I disagree there
21:32:00 <asalkeld> tho' i don't think i have seen any ops folks reviewing heat specs
21:32:03 <mikal> ttx: ops don't care about proposal processes, as they're not proposing
21:32:12 <mikal> ttx: they just care about publication and open review
21:32:24 <bknudson> if you're an op looking at spec reviews you're not worrying about how the toc output looks.
21:32:28 <ttx> mikal: they still need to figure out the various sites under specs.o.o
21:32:38 <notmyname> mikal: ya. I was considering ops (deployers) to be part of the contributors. external as in the people looking at openstack externally from a project management perspective
21:32:43 <mikal> ttx: I actually disagree there too
21:32:45 <mikal> (sorry)
21:32:54 <ttx> mikal: that's fine :)
21:32:54 <mikal> ttx: ops reading specs.o.o is too late
21:32:59 <mikal> ttx: the spec is approved at that point
21:33:10 <maishsk> mikal: unless something rages a huge red flag
21:33:10 <dhellmann> maishsk: are you aware of anyone using the new rss feeds?
21:33:12 <mikal> ttx: hence the blog post -- to drive them to gerrit to comment on the review _before_ approval
21:33:21 <ttx> mikal: you can tell I haven't prepared this topic since I expecetd someone else to drive it :)
21:33:32 <mikal> dhellmann: someone blog about them the other day on planet.o.o
21:33:36 <ttx> hmmm, ok
21:33:46 <asalkeld> what we need is an rss of specs in review
21:33:48 <dhellmann> mikal: yeah,  I saw that and encouraged them to add their opml file to the specs page
21:33:49 <maishsk> according the number people that have hit the page - I would assume so
21:33:51 <fungi> specs _are_ just files in a git repo, under code review, and can be revised through the same review process if needed
21:33:51 <notmyname> mikal: actually, that's why we decided to merge specs early and often. as soon as we agree on something, merge it. therefore you have a living document until the implementation is finished
21:34:00 <mikal> asalkeld: that would be nice. I hand produce that at the moment.
21:34:06 <mikal> asalkeld: it would be a flood of data though
21:34:07 <ttx> I guess I'll circle back to john, but it looks like there isn't that much convergence to drive right now
21:34:11 <mikal> asalkeld: we have 150 proposals for Kilo Nova
21:34:18 <maishsk> dhellmann: I am trying to get the patches up
21:34:18 <asalkeld> yeah
21:34:35 <fungi> asalkeld: mikal: we have a script that publishes arbitrary review info for projects as an rss feed in a swift container. it could be adapted pretty easily
21:34:40 <ttx> I wanted to touch briefly on procedural -2s
21:34:50 <ttx> jeblair: is there any plan to support that ? ^
21:34:52 <mikal> ttx: yes, that's much more interesting to me
21:34:53 * maishsk is not strong enough yet in the ways of OpenStack code submissions. (padawan)
21:34:56 <dhellmann> maishsk: oh, that was you!?sorry!
21:34:56 <notmyname> ttx: what is a procedural -2?
21:35:11 <mikal> notmyname: I -2 code proposals wehere the spec hasn't been approved yet
21:35:14 <mikal> notmyname: to stop accidental merge
21:35:25 <mikal> notmyname: it is horrible
21:35:26 <notmyname> mikal: ah ok. so on the code side, not specs side
21:35:29 * dhellmann needs to start doing that
21:35:31 <morganfainberg> mikal, we do the same in keystone - especially around FF.
21:35:34 <ttx> or when we are under some kind of freeze. Not a judgment on the proposal itself, just the wrong moment
21:35:42 <notmyname> mikal: ya, I've done that (rarely)
21:35:46 <jeblair> ttx, mikal: i have not forgotten about that
21:35:48 <mikal> notmyname: yeah, its a process thing. Hence "procedural"
21:35:51 <morganfainberg> but in specs i don't think we have (though with a hard submit deadline we might this time)
21:35:53 <ttx> prevents other people from reviewing
21:35:53 <notmyname> ttx: ok, so that's orthogonal to specs, right?
21:36:10 <jeblair> ttx, mikal: i plan on looking into that soon, but it has been holidays + firefighting since summit :(
21:36:18 <ttx> it's sometimes part of the spec approval process. And one of the discussions there was in that session in Paris
21:36:19 <mikal> notmyname: closely related, but we'd do it even without specs at freeze etc
21:36:21 <bknudson> maybe there's a unicode symbol that could be used in place of -2
21:36:23 <notmyname> or, one procedural reason might be related to a spec. but that's not the only reason
21:36:30 <notmyname> mikal: right. with you.
21:36:36 <ttx> notmyname: but yes, overlapping
21:36:37 <mikal> The biggest issue is that they can't be removed by the PTL if the core isn't around
21:36:40 <notmyname> so what's the question about it? finding a different way to do that?
21:36:40 <asalkeld> mikal, why do you care that a spec is approved
21:36:54 <mikal> asalkeld: because we're not landing the code until the spec is approved
21:36:58 <mikal> asalkeld: that's the point of the spec
21:37:02 <ttx> jeblair: ok, so too early to put it back on the table
21:37:04 <jeblair> ttx, mikal: i believe i fully understand the use case and agree that it's important to try to address
21:37:05 <notmyname> mikal: PTL needs super-core privileges ;-)
21:37:16 <morganfainberg> mikal, this might be a case where another column that is sticky and PTL/project release group only - that blocks merging?
21:37:21 <morganfainberg> jeblair, cc ^
21:37:29 <asalkeld> for me approving a spec is "we approve of the design"
21:37:30 <mikal> morganfainberg: I don't want to define implementation
21:37:34 <fungi> probably best not to bikeshed on gerrit implementation details at this stage
21:37:37 <morganfainberg> mikal, sure
21:37:40 <ttx> Alright, last words on that topic before we switch ?
21:37:40 <mikal> I want to remind jeblair that we want _something_
21:37:45 <mikal> And then let infra do their thing
21:37:51 <asalkeld> and use lp for milestones etc..
21:37:54 <jeblair> yep, that's what i signed up for
21:37:59 <morganfainberg> jeblair, ++
21:38:02 <SlickNik> jeblair: thanks!
21:38:06 <notmyname> hmm...like a -2 workflow
21:38:34 <notmyname> or something. cool. looking forward to see what happens
21:38:41 <ttx> I'll circle back to johnthetubaguy because I'm not sure we coverted all he had in mind, but it looks like there isn't that much convergence to drive right now
21:38:46 <ttx> let's move on
21:38:47 <jeblair> (for anyone wondering why i haven't just done it -- it may involve prolog) :)
21:38:53 <mikal> jeblair: ewww
21:38:55 <morganfainberg> jeblair, hehe
21:38:59 <jeblair> hopefulyl that ends the bikeshedding for now
21:39:01 * SlickNik pretends he didn't hear that
21:39:10 <ttx> #topic osprofiler options naming (kragniz)
21:39:13 <morganfainberg> jeblair, can you paint the prolog red?
21:39:16 <ttx> kragniz: you around ?
21:39:16 <kragniz> okay, this should be fairly quick
21:39:27 <kragniz> so let's talk about the option for enabling/disabling osprofiler
21:39:31 * mikal departs
21:39:38 <kragniz> in glance, we have an option named '[profiler]/enabled' and all other projects use'[profiler]/profiler_enabled'
21:39:53 <kragniz> cinder guys requested 'profiler_enabled' rather than 'enabled'
21:40:08 <eglynn> [profiler]/profiler_enabled seems superfluous
21:40:10 <bknudson> I thought this is why we have oslo-incubator and config options in oslo libs?
21:40:15 <kragniz> and so other projects used that name afterwards
21:40:20 <kragniz> can we decide on a common name and standardize it across projects?
21:40:34 <dhellmann> bknudson: yes, that's right
21:40:34 <eglynn> no need for both the prefix and section, surely?
21:40:48 <jokke_> eglynn: +1
21:40:59 <dhellmann> eglynn: ++
21:41:04 <Rockyg> eglynn:  +1
21:41:05 <bknudson> for some reason we don't have it in keystone.
21:41:06 * ttx has no opinion, but I suspect our ops would appreciate some consistency there
21:41:09 <morganfainberg> eglynn, ++
21:41:10 <kragniz> thingee: do you know the reasons cinder wanted the other name?
21:41:14 <morganfainberg> bknudson, we haven't merged osprofiler
21:41:24 <kragniz> ttx: that's what I want
21:41:25 <maishsk> ttx: Hell yeah!
21:41:36 <kragniz> I don't actually mind one way or the other
21:41:51 <dhellmann> for anyone still interested in spec reviews, sdague built a nice dashboard for all the spec repositories: http://bit.ly/1wdmq0m
21:42:02 <kragniz> but having the same option have the same name across projects makes sense to me
21:42:11 <ttx> kragniz: if only Glance has a different name, minimal disruption rule would lead us to the other name that everyone else uses. Unelss it sucks really badly
21:42:42 <jokke_> ttx: but it does suck really badly
21:42:44 <kragniz> ttx: yes, so I'm proposing we deprecate 'enabled' in glance and replace it with 'profiler_enabled'
21:42:44 <notmyname> this is what's put into the config file right?
21:42:45 <Rockyg> reasoning behind Profileer_enable as that enable is in other parts of code.  Reasoning not needed is it's always prefixed with [Profiler}
21:42:52 <kragniz> notmyname: yup
21:42:57 <jokke_> notmyname: correct
21:43:05 <notmyname> ya, what Rockyg just said. "enabled" isn't unique
21:43:11 <jungleboyj> Yeah, wondering why cinder is pointed out as the requester when Glance is the outlyer.
21:43:15 <jungleboyj> What am I missing?
21:43:50 <jokke_> jungleboyj: Glance were first implementer and cinder was the second one and they wanted it differently :P
21:44:01 <jungleboyj> jokke_: Ooops
21:44:08 <kragniz> jungleboyj: osprofiler support was added to glance first, and used the original config name boris-42 wanted
21:44:09 <ttx> and then everyone else followed Cinder ? Who is everyone else ?
21:44:21 <jungleboyj> jokke_: Then everyon else followed us?
21:44:27 <kragniz> jungleboyj: yup
21:44:34 <jokke_> jungleboyj: that's it
21:44:41 <ttx> I think I read "everyone else" doesn't include keystone
21:44:42 * jungleboyj looks sheepish
21:44:47 <jokke_> ttx: yet
21:44:56 <thingee> kragniz: no idea, but I know who would be behind it.
21:45:20 <jungleboyj> Ruh roh
21:45:58 <jokke_> jungleboyj: I'm not sure if it was everyone else followed or boris implemented with that to everywhere else
21:46:31 <bknudson> I wonder how many examples of this kind of thing there are... e.g., different SSL config options
21:46:35 <ttx> so how many projects are using [profiler]/profiler_enabled at this point ?
21:46:52 <kragniz> ttx: uuh
21:46:53 <jungleboyj> jokke_: Understood.  So, it seems like it is down to do we change just Glance or get those who used profiler_enabled to change.
21:46:59 <kragniz> ttx: I had a list somewhere
21:47:05 <kragniz> I know heat does
21:47:08 <Rockyg> bknudson:  too many.  but we can fix over time.  Gives ops a headache
21:47:11 <ttx> bknudson: cargoculting  means not so many. The problem with osprofiler is atht it was added after the copy
21:47:23 <morganfainberg> i'd be inclined to say [profiler]/profiler_enabled really isn't that burdonsome or odd or bad
21:47:36 <morganfainberg> it's just not that awful. this whole discussion feels alot like bikeshed
21:47:59 * maishsk wonders what is a bikeshed
21:47:59 <kragniz> morganfainberg: I just wanted my review to be accepted!
21:48:03 <ttx> My personal preference (not that it matters) would be to limit disruption and option rename
21:48:18 <morganfainberg> maishsk, bikeshed.org
21:48:23 <morganfainberg> ttx, i agree.
21:48:25 <jungleboyj> morganfainberg: +1
21:48:37 <bknudson> it's not that disruptive since the old name can work too
21:48:41 <Rockyg> ttx, ++
21:48:42 <ttx> kragniz: but then if glance-core doesn't want to renazme, i can't force them
21:48:46 <devananda> maishsk: http://bikeshed.com/
21:49:16 <kragniz> ttx: ptl doesn't mind one way or the other
21:49:28 <dhellmann> ttx: according to the code I have checked out, only cinder, glance, and heat are using osprofiler right now and cinder and heat are the only projects other than the docs that mention profiler_enabled
21:49:49 <ttx> hmm, so there is room for converging the other direction
21:50:01 <asalkeld> i don't mind a backwards compatible name change (if needed)
21:50:05 <ttx> if cinder and heat agree their option naming sucks
21:50:18 <dhellmann> yeah, this feels like a big kerfuffle over what should be a small change in 1-2 projects
21:50:21 <devananda> so i'm curious, other than keystone, are there other projects which haven't implemented osprofiler yet?
21:50:37 <dhellmann> devananda: only 3 projects *have* adopted it so far
21:50:37 <kragniz> dhellmann: +1
21:50:38 <ttx> thingee: do you mind the rename ?
21:50:46 <devananda> dhellmann: oh. i totally misread that, then. thankjs
21:50:52 <dhellmann> http://paste.openstack.org/show/148174/
21:51:16 <dhellmann> http://paste.openstack.org/show/148180/
21:51:18 <jungleboyj> ttx: I am thinking we don'tcare.
21:51:19 <asalkeld> manuals
21:51:42 <dhellmann> asalkeld: yes, but the manuals will have to be updated either way
21:51:49 <ttx> kragniz: so... maybe submit changes in the other two. and see which one wins
21:51:52 * jungleboyj != thingee though
21:52:06 <kragniz> ttx: hmm, okay
21:52:07 <jungleboyj> ttx: Ooooh.
21:52:08 <thingee> ttx: no
21:52:17 <ttx> agree that it's less of an issue than I thought if only t3 projects impacted
21:52:20 <ttx> 3*
21:52:42 <ttx> ok, let's move on
21:52:55 <morganfainberg> more importantly, this sounds like an option that should be owned by osprofiler not each-and-every-project-to-implement0differently, but that is differnt color to paint the bikeshed...
21:52:58 <morganfainberg> i agree move on
21:53:03 <ttx> #topic Open discussion & announcements
21:53:12 <ttx> We had release 1:1 syncs today, full speed ahead with kilo-1 next week. Logs at:
21:53:17 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-12-09-08.49.html
21:53:21 * jokke_ hand morganfainberg bucket of pink paint :P
21:53:21 <ttx> Anything else, anyone ?
21:54:40 <dhellmann> morganfainberg: ++
21:54:51 <ttx> Neutron is in the middle of its advanced serviuce split process
21:55:37 <ttx> If nobody else has anything, I suggest we close early
21:56:15 <jokke_> sounds good
21:56:25 <ttx> Alright then. Thanks for coming!
21:56:28 <kragniz> thanks all, sorry for the bikeshed
21:56:32 <ttx> #endmeeting