21:03:23 #startmeeting crossproject 21:03:23 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:27 The meeting name has been set to 'crossproject' 21:03:36 o/ 21:03:37 o/ 21:03:39 I might need you to do John hot spare again 21:03:42 mikal: ^ 21:03:49 Our agenda for today: 21:03:52 #link http://wiki.openstack.org/Meetings/CrossProjectMeeting 21:03:59 ttx: sure 21:04:03 #topic Convergence on specs process 21:04:09 (Although I have to duck out a littler early) 21:04:25 So this was put on the agenda by johnthetubaguy but he is not around 21:04:31 o/ 21:04:32 ttx: again.... 21:04:35 I'll try my best to drive the discussion anyway 21:04:40 I can help too 21:04:43 so that we don't postpone it twice 21:05:07 So the idea is to continue the cross-project session on specs we had in Paris 21:05:24 is there an etherpad? I didn't make it 21:05:25 and see which practices may be interesting to apply to everyone 21:05:29 is there a link to a suggestion to what we are converging to 21:05:31 (if any) 21:05:36 ttx: can you tl;dr the outcome of the session in Paris 21:05:37 o/ 21:05:40 IIRC, first step was get Blueprints wiki page up to date for all projects 21:05:53 #link https://etherpad.openstack.org/p/kilo-crossproject-specs 21:05:54 and then see if there were actually differences to deal with and discuss 21:06:02 also which differences are useful and which is just superfluous 21:06:06 yeah 21:06:20 * ttx tries to find the etherpad from that session 21:06:35 ttx: ^^ 21:06:41 I'd be interested in if other projects have soemthing better than procedural -2's as well 21:06:46 dhellmann: thx! 21:07:05 here 21:07:28 Maybe first step is to look at https://wiki.openstack.org/wiki/Blueprints 21:07:36 "Spec + Blueprints lifecycle" chapter 21:07:47 and see who actually follows that, if anyone 21:08:06 'Upload a design specification in the "specs/" folder in $PROJECT-specs' 21:08:08 ttx: there are minor diffs for nova in that 21:08:12 -> nova uses approved/ implemented/ 21:08:15 ttx: things like paths being wrong in those instructions 21:08:22 ttx: we also have a per-release template 21:08:38 ttx: we also don't remove non-completed specs 21:08:39 ttx: we have been mostly following it, though mistakes are getting made (even by me) 21:08:44 That looks like the lifecycle that is used by Cinder 21:08:46 ttx: we instead move implemetned specs to that different directory 21:08:47 mikal: why do you track the implementation status in 2 places? 21:08:57 mikal: I can see a few drawbacks in switching spec location at implementation time 21:09:03 dhellmann: as in the directory move? 21:09:06 mikal: yes 21:09:13 ttx: we've been following it for Trove as well. 21:09:16 mikal: why not just use the blueprint for that? 21:09:26 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 ok 21:09:36 dhellmann: we actively push operators to the specs repo 21:09:37 at the summit swift proposed a change in flow for specs https://github.com/openstack/swift-specs/blob/master/README.rst 21:09:43 dhellmann: but then don't explain that it might be a pack of lies 21:09:56 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 That wiki page also doens't mention backlog specs, which we stole from Keystone 21:10:03 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 mikal: yeah, ok, that does make some sense. I'd almost drop blueprints at that point. 21:10:17 in the spec. 21:10:21 dhellmann: we need bps for mechanical release reasons though 21:10:30 dhellmann: I agree this isn't perfect 21:10:32 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 ttx: cinder just removes the specs that weren't completed in the release. 21:10:38 mikal: yeah, true 21:10:43 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 OK, let's focus on that particular bit, the use of a specific "implemented" directory 21:11:01 dhellmann, we have had a couple half-done and we just proposed a / highlighting what was done and what wasn't 21:11:04 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 who else uses that ? just nova ? 21:11:10 if it wasn't touched at all, i'd delete it/move it back to backlog 21:11:11 morganfainberg: that makes sense 21:11:11 morganfainberg: agree on not moving, surely that breaks the specification URL field in LP? 21:11:16 devananda: ++ 21:11:29 devananda, that is the goal for keystone as well. 21:11:33 as a result, we haven't had to look at a separate /implemented/ dir 21:11:33 ttx: we have "done" and "in_progress" in swift 21:11:36 devananda, unless it's proposed to backlog 21:11:44 morganfainberg: right - backlog is not release specific 21:11:52 (nothing proposed there yet for us, but planned this cycle) 21:11:55 specs/[backlog, juno, kilo] 21:11:58 i think it's dumb using the spec repo to store state when lp is doing that 21:12:04 ttx: implemented is something specifically didn't want because we didn't want to confuse specs with docs 21:12:12 asalkeld: +1 21:12:14 asalkeld: +1 21:12:21 maybe just remove the kilo/juno folder too 21:12:28 specs is just that.. a spec. Not a feature list 21:12:28 asalkeld: I think that's an overly emotive way of putting it 21:12:40 maybe 21:12:44 I find it helpful to break specs down by cycle 21:12:44 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 But I can see how people may confuse the two 21:12:49 So, we have ops people deep linking to specs 21:12:56 We're just going to delete stuff and let them get a 404? 21:13:06 asalkeld, i wouldn't remove the history, we make previous releases appear differently via sphinx magic 21:13:12 sorry, just seems like trying to mirror stuff unnecessary 21:13:26 mikal: how does that deeplink survive the move to "implemented/" ? 21:13:38 ttx: we have a sphinx plugin which creates redirects 21:13:47 ttx: this does raise a question for me. I see some blueprints "specification URL" pointing to gerrit reviews 21:13:47 ttx: its not very good, but it works 21:13:56 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 ttx: but I dont know where that practice came from 21:14:12 devananda: spec2bp.py should overwrite that :) 21:14:13 implemented/previous releases 21:14:20 ttx: i actually find it very helpful 21:14:28 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 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 mikal: not askign anyone to drop anything yet. Just trying to see if there can be more common practices. 21:14:38 ttx: for not-yet-approved blueprints to have a URL pointing to the spec review 21:14:44 asalkeld: we have different core groups for specs 21:14:45 ops don't look at nova's specs in a vacuum 21:14:46 devananda: +1 21:14:49 asalkeld: separate core group 21:14:57 so they try to make sense of specs.o.o ovberall and can't 21:15:01 ironic has spec-cores who are not ironic-cores 21:15:17 so just permissions issue? 21:15:19 asalkeld: also some spec repos cover more than one project 21:15:23 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 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 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 devananda, that wasn't meant to be directed to you ^ just to the channel in general 21:16:19 ttx: for --blocked specs, could spec2bp set the URL to the review? 21:16:23 I'd be interested in how (if at all) other PTLs are encouraging operators to come on in-review specs 21:16:30 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 s/come/comment/ 21:16:38 devananda: oh, you mean the spec review ? 21:16:45 ttx: yes 21:16:51 devananda: that.. kind of makes sense 21:16:52 thingee: yeah, I was thinking of mikal's point about people having links pointing to them 21:17:05 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 devananda: maybe add it as comment to https://review.openstack.org/#/c/108041/ 21:17:29 mikal: I talked it up with some folks at the summit, especially about the work on oslo.log. Not takers, yet. 21:17:42 morganfainberg: we have a few faithful operators, but not a lot of smaller deploys are commenting 21:18:11 People do tell me they like the blog posts, but then don't actually comment on reviews 21:18:17 And they're a fair bit of work to write 21:18:46 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 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 mikal, that is just wild supposition on my part though 21:19:06 OK, what about specs.o.o TOC differences between projects ? Those seem more gratuitous (cc maishsk) 21:19:11 ttx: posted 21:19:12 morganfainberg: yeah, it might also be that they're completely happy 21:19:15 Its hard to tell from the outside 21:19:31 ttx: define TOC differences? 21:19:37 ttx: the formatting is different - which is confusing 21:19:39 ttx: as in the number of headins displayed? 21:19:42 http://specs.openstack.org/openstack/heat-specs/ 21:19:45 mikal, ask cburgess next time as well, he's a good voice for the smaller (until recently) deployer groups. 21:19:46 http://specs.openstack.org/openstack/nova-specs/ 21:19:48 dhellmann: working on logging-->you'll see start this week 21:19:59 Rockyg: cool 21:20:04 mikal: confusing differences in navigation 21:20:06 mikal even though he contributes code as well 21:20:07 reported by maishsk 21:20:08 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 thingee: +1 21:20:15 Did someone say my name? 21:20:21 cburgess: no 21:20:22 :P 21:20:32 Fine :P 21:20:40 ttx: yeah, I think someone should just submit formatting changes to fix those. Maybe maishsk can do that? 21:20:48 maishsk: so, you're confused because the indx pages look different? 21:20:57 maishsk: isn't that a largely cosmetic problem? 21:21:02 mikal: not only me 21:21:17 ~/msg Rockyg hey there! Erno here, do you have a moment after the meeting to sync up? 21:21:18 i like the flat layout 21:21:18 maishsk, what specifically is confusing? mor than "there are differences" 21:21:30 mikal: essentially yes cosmetic 21:21:32 darn 21:21:51 first world problems :-O 21:21:58 morganfainberg: the format of the page, why are some of the projects different - layout is different. 21:22:01 So, bigger projects are always going to want to split per release I would think 21:22:13 We had nearly 100 specs in Juno for Nova 21:22:18 I think per-cycle split is something we can standardize on 21:22:20 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 even if you have 5 it still makes sense 21:22:37 ttx, ++ 21:22:40 to at least question if you should copy them over 21:22:42 ttx: +1 21:22:44 ttx: ++ 21:22:49 mikal / ttx +1 to per cycle split. 21:22:51 ttx: can we not be prescriptive yet? specs is still something very new, and it's a learning process 21:22:58 -- to per cycle split 21:23:15 notmyname, +1 21:23:26 To be honest I am not sure if I see a lot of value in being proscriptive 21:23:28 notmyname: I would only prescribe consensual things at this point. Can you explain your -- ? 21:23:31 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 The templates are differnt as well 21:23:44 Are we goign to force all projects to use the same template 21:23:45 ? 21:23:51 mikal: Why not? 21:24:00 ++ to per-cycle split in the TOC. I dont care so much if it's in the file layout 21:24:05 standardization..... 21:24:05 maishsk: I can help you with the oslo-specs change, if one is needed. 21:24:06 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 maishsk: because different projects have different things to be concerned about 21:24:12 mikal: I think they may end up sharing best practices by copying themselves a bit more 21:24:20 but also, I don't think it matters enough yet to proscribe it to other projects 21:24:23 but i would let them evolve separately 21:24:38 yeah, oslo has very different concerns for graduating a library than nova does when adding a feature 21:24:43 mikal: definitely not the same template across projects 21:24:47 Exactly 21:25:01 mikal: are the format of blueprints submitted across projects different - or do they all have the same base structure? 21:25:02 there are certain things some projects care about uniquely, because they are unique 21:25:11 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 notmyname: on the other hand, we don't want people to learn 15 different ways of posting a spec 21:25:25 maishsk: blueprints are often a single sentence. They have no format. 21:25:30 15 different templates is ~ok 21:25:38 15 different processes... not so much I think 21:25:49 The entire community is traditionally cargo-cultish (see *client). Having at least a default starting point is of value here 21:25:50 ttx: ++ 21:25:51 ttx there is a template in each project 21:25:55 mikal: I am not saying the same information has to be the same - just presented 'cosmetically' the same way 21:26:03 maishsk: is there a reason we wanted to step out of the scope of blueprint ;) 21:26:06 dtroyer: we do have a cookiecutter template for new specs repositories 21:26:07 asalkeld: that's fine. Instructions can be "copy and edit template 21:26:08 you grab the template and fill it in 21:26:08 " 21:26:14 think infra specs... they span countless infra projects none of which participate in the integrated release cadence 21:26:23 but if they can't tell where to get the template... less fun 21:26:29 same formatting guidelines, same proposal and review process for specs, but variation in templated sections and guidelines therein 21:26:45 is what seems to make sense to me 21:26:45 dtroyer: http://git.openstack.org/cgit/openstack-dev/specs-cookiecutter/ 21:26:57 devananda: exactly - format should be the same across the board 21:27:04 have there been complaints from people submitting specs to 15 projects? 21:27:08 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 those are probably the folks who it would be interesting to hear from 21:27:20 bknudson: the complaints are coming from people trying to read them 21:27:28 bknudson: only one that I know of (osprofiler) 21:27:31 notmyname: ++ 21:27:36 notmyname: I'd agree with that. 21:27:45 I think annegentle had a spec in every repo as well? 21:27:50 notmyname: ++ … I understood this to be a search for commonality in what we have so far 21:27:53 what are the complaints exactly? can people not find what they are looking for? 21:28:13 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 notmyname: ++ 21:28:25 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 dhellmann: oh, neat. that'll solve an issue I've bumped into this week :) 21:28:45 so, basic outline and minimum contents across all projects, then notmyname can experiment on top of it 21:28:49 We are not done with experimenting yet 21:29:05 dhellmann: thank you 21:29:24 devananda, thingee : I'll try to get that merged soon and cut a release so you can try it out 21:29:25 dhellmann: That's pretty neat. Will take a closer look, thanks! 21:30:28 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 dhellmann: +1 Cool 21:30:56 notmyname: +1 21:31:00 notmyname: I think both audiences are important to be honest. 21:31:00 notmyname: I think the concern is about ops getting involved in specs 21:31:08 specs make it easier for the non coding community to participate 21:31:10 they are typically going cross-project 21:31:23 ttx: notmyname why is that a concern? 21:31:24 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 ttx: ++ 21:31:33 and differences are hurtign their experience. Not fatal, I agree, just creating some friction 21:31:36 mikal: +++++ 21:31:51 ttx: I disagree there 21:32:00 tho' i don't think i have seen any ops folks reviewing heat specs 21:32:03 ttx: ops don't care about proposal processes, as they're not proposing 21:32:12 ttx: they just care about publication and open review 21:32:24 if you're an op looking at spec reviews you're not worrying about how the toc output looks. 21:32:28 mikal: they still need to figure out the various sites under specs.o.o 21:32:38 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 ttx: I actually disagree there too 21:32:45 (sorry) 21:32:54 mikal: that's fine :) 21:32:54 ttx: ops reading specs.o.o is too late 21:32:59 ttx: the spec is approved at that point 21:33:10 mikal: unless something rages a huge red flag 21:33:10 maishsk: are you aware of anyone using the new rss feeds? 21:33:12 ttx: hence the blog post -- to drive them to gerrit to comment on the review _before_ approval 21:33:21 mikal: you can tell I haven't prepared this topic since I expecetd someone else to drive it :) 21:33:32 dhellmann: someone blog about them the other day on planet.o.o 21:33:36 hmmm, ok 21:33:46 what we need is an rss of specs in review 21:33:48 mikal: yeah, I saw that and encouraged them to add their opml file to the specs page 21:33:49 according the number people that have hit the page - I would assume so 21:33:51 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 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 asalkeld: that would be nice. I hand produce that at the moment. 21:34:06 asalkeld: it would be a flood of data though 21:34:07 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 asalkeld: we have 150 proposals for Kilo Nova 21:34:18 dhellmann: I am trying to get the patches up 21:34:18 yeah 21:34:35 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 I wanted to touch briefly on procedural -2s 21:34:50 jeblair: is there any plan to support that ? ^ 21:34:52 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 maishsk: oh, that was you!?sorry! 21:34:56 ttx: what is a procedural -2? 21:35:11 notmyname: I -2 code proposals wehere the spec hasn't been approved yet 21:35:14 notmyname: to stop accidental merge 21:35:25 notmyname: it is horrible 21:35:26 mikal: ah ok. so on the code side, not specs side 21:35:29 * dhellmann needs to start doing that 21:35:31 mikal, we do the same in keystone - especially around FF. 21:35:34 or when we are under some kind of freeze. Not a judgment on the proposal itself, just the wrong moment 21:35:42 mikal: ya, I've done that (rarely) 21:35:46 ttx, mikal: i have not forgotten about that 21:35:48 notmyname: yeah, its a process thing. Hence "procedural" 21:35:51 but in specs i don't think we have (though with a hard submit deadline we might this time) 21:35:53 prevents other people from reviewing 21:35:53 ttx: ok, so that's orthogonal to specs, right? 21:36:10 ttx, mikal: i plan on looking into that soon, but it has been holidays + firefighting since summit :( 21:36:18 it's sometimes part of the spec approval process. And one of the discussions there was in that session in Paris 21:36:19 notmyname: closely related, but we'd do it even without specs at freeze etc 21:36:21 maybe there's a unicode symbol that could be used in place of -2 21:36:23 or, one procedural reason might be related to a spec. but that's not the only reason 21:36:30 mikal: right. with you. 21:36:36 notmyname: but yes, overlapping 21:36:37 The biggest issue is that they can't be removed by the PTL if the core isn't around 21:36:40 so what's the question about it? finding a different way to do that? 21:36:40 mikal, why do you care that a spec is approved 21:36:54 asalkeld: because we're not landing the code until the spec is approved 21:36:58 asalkeld: that's the point of the spec 21:37:02 jeblair: ok, so too early to put it back on the table 21:37:04 ttx, mikal: i believe i fully understand the use case and agree that it's important to try to address 21:37:05 mikal: PTL needs super-core privileges ;-) 21:37:16 mikal, this might be a case where another column that is sticky and PTL/project release group only - that blocks merging? 21:37:21 jeblair, cc ^ 21:37:29 for me approving a spec is "we approve of the design" 21:37:30 morganfainberg: I don't want to define implementation 21:37:34 probably best not to bikeshed on gerrit implementation details at this stage 21:37:37 mikal, sure 21:37:40 Alright, last words on that topic before we switch ? 21:37:40 I want to remind jeblair that we want _something_ 21:37:45 And then let infra do their thing 21:37:51 and use lp for milestones etc.. 21:37:54 yep, that's what i signed up for 21:37:59 jeblair, ++ 21:38:02 jeblair: thanks! 21:38:06 hmm...like a -2 workflow 21:38:34 or something. cool. looking forward to see what happens 21:38:41 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 let's move on 21:38:47 (for anyone wondering why i haven't just done it -- it may involve prolog) :) 21:38:53 jeblair: ewww 21:38:55 jeblair, hehe 21:38:59 hopefulyl that ends the bikeshedding for now 21:39:01 * SlickNik pretends he didn't hear that 21:39:10 #topic osprofiler options naming (kragniz) 21:39:13 jeblair, can you paint the prolog red? 21:39:16 kragniz: you around ? 21:39:16 okay, this should be fairly quick 21:39:27 so let's talk about the option for enabling/disabling osprofiler 21:39:31 * mikal departs 21:39:38 in glance, we have an option named '[profiler]/enabled' and all other projects use'[profiler]/profiler_enabled' 21:39:53 cinder guys requested 'profiler_enabled' rather than 'enabled' 21:40:08 [profiler]/profiler_enabled seems superfluous 21:40:10 I thought this is why we have oslo-incubator and config options in oslo libs? 21:40:15 and so other projects used that name afterwards 21:40:20 can we decide on a common name and standardize it across projects? 21:40:34 bknudson: yes, that's right 21:40:34 no need for both the prefix and section, surely? 21:40:48 eglynn: +1 21:40:59 eglynn: ++ 21:41:04 eglynn: +1 21:41:05 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 eglynn, ++ 21:41:10 thingee: do you know the reasons cinder wanted the other name? 21:41:14 bknudson, we haven't merged osprofiler 21:41:24 ttx: that's what I want 21:41:25 ttx: Hell yeah! 21:41:36 I don't actually mind one way or the other 21:41:51 for anyone still interested in spec reviews, sdague built a nice dashboard for all the spec repositories: http://bit.ly/1wdmq0m 21:42:02 but having the same option have the same name across projects makes sense to me 21:42:11 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 ttx: but it does suck really badly 21:42:44 ttx: yes, so I'm proposing we deprecate 'enabled' in glance and replace it with 'profiler_enabled' 21:42:44 this is what's put into the config file right? 21:42:45 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 notmyname: yup 21:42:57 notmyname: correct 21:43:05 ya, what Rockyg just said. "enabled" isn't unique 21:43:11 Yeah, wondering why cinder is pointed out as the requester when Glance is the outlyer. 21:43:15 What am I missing? 21:43:50 jungleboyj: Glance were first implementer and cinder was the second one and they wanted it differently :P 21:44:01 jokke_: Ooops 21:44:08 jungleboyj: osprofiler support was added to glance first, and used the original config name boris-42 wanted 21:44:09 and then everyone else followed Cinder ? Who is everyone else ? 21:44:21 jokke_: Then everyon else followed us? 21:44:27 jungleboyj: yup 21:44:34 jungleboyj: that's it 21:44:41 I think I read "everyone else" doesn't include keystone 21:44:42 * jungleboyj looks sheepish 21:44:47 ttx: yet 21:44:56 kragniz: no idea, but I know who would be behind it. 21:45:20 Ruh roh 21:45:58 jungleboyj: I'm not sure if it was everyone else followed or boris implemented with that to everywhere else 21:46:31 I wonder how many examples of this kind of thing there are... e.g., different SSL config options 21:46:35 so how many projects are using [profiler]/profiler_enabled at this point ? 21:46:52 ttx: uuh 21:46:53 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 ttx: I had a list somewhere 21:47:05 I know heat does 21:47:08 bknudson: too many. but we can fix over time. Gives ops a headache 21:47:11 bknudson: cargoculting means not so many. The problem with osprofiler is atht it was added after the copy 21:47:23 i'd be inclined to say [profiler]/profiler_enabled really isn't that burdonsome or odd or bad 21:47:36 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