20:03:04 <ttx> #startmeeting tc
20:03:05 <openstack> Meeting started Tue May 27 20:03:04 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:07 <zehicle_at_dell> o/
20:03:08 <openstack> The meeting name has been set to 'tc'
20:03:09 <mikal> Morning
20:03:18 <ttx> Here is our agenda for today:
20:03:22 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:32 <ttx> david-lyle: around?
20:03:35 <david-lyle> o/
20:03:38 <ttx> #topic Integrated projects and new requirements: Gap coverage plan for Horizon
20:03:44 <ttx> Last week we did a gap analysis for Horizon
20:03:49 <ttx> #link https://etherpad.openstack.org/p/horizon-gap-analysis
20:03:54 <ttx> A number of gaps were identified:
20:03:59 <ttx> * Scope needs to be documented
20:04:03 <ttx> * Refresh of horizon-coresec needed
20:04:08 <ttx> * Integration test framework tied to gate
20:04:13 <ttx> * Non-standard test/packaging/translation tooling due to combined projects in one repo
20:04:20 <ttx> Two non-blocking remarks were made:
20:04:27 <ttx> * A major architectural change is planned (split of repo into toolkit and django app)
20:04:32 <ttx> * Would be nice to have a listing of API calls not available in GUI per service
20:04:38 <ttx> david-lyle: Do you have a plan to address the gaps in the near future ?
20:04:41 <david-lyle> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage
20:04:56 <david-lyle> missed the non-standard tooling item
20:05:03 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage
20:05:11 <david-lyle> will have to amend
20:05:26 <jeblair> well, in the last meeting rdopiera came to talk about splitting the horizon repo
20:05:45 <mordred> o/
20:06:22 <ttx> david-lyle: plan looks good to me
20:06:22 <jeblair> so i'm optimistic that will get better soon, though it doesn't necessarily follow that everything will become more standard
20:06:28 <markmc> nicely done david-lyle
20:06:46 <ttx> Any objection on the proposed plan ?
20:07:06 <annegentle> david-lyle: where will you document the gaps?
20:07:13 <david-lyle> jeblair: there is a larger issue in the community regarding nodejs
20:07:23 <sdague> ttx: lgtm
20:07:46 <david-lyle> annegentle: good question, likely on w.o.o
20:08:31 <david-lyle> I think it's too transient to put anywhere in the code base
20:08:52 <dhellmann> what is "Exhaustive list of API calls not supported"? Is that calls into other projects that horizon doesn't use anywhere?
20:09:04 <ttx> #info Gap coverage plan looks sane, will review for progress after milestones
20:09:16 <annegentle> david-lyle: sounds good to me, was going to suggest wiki
20:09:49 <david-lyle> dhellmann, the goal is find areas where Horizon doesn't match features exposed by the CLI
20:10:04 <david-lyle> that is a common complaint against Horizon
20:10:29 <ttx> Anything else on that topic ?
20:10:33 <dhellmann> ok, maybe consider rephrasing that gap in the way you just said it because it wasn't obvious what was meant by the current wording
20:11:00 <david-lyle> we're hoping to fill those gaps, so users aren't forced to switch to CLI to accomplish certain tasks
20:11:05 <david-lyle> dhellmann: sure
20:11:28 <markmcclain> david-lyle: I'd also suggest maybe breaking out into subsets for each project
20:11:30 <dhellmann> otherwise it all looks good
20:11:43 <ttx> OK then, let's move on to next topic
20:11:51 <ttx> david-lyle: many thanks!
20:11:52 <david-lyle> markmcclain: yes
20:11:58 <ttx> zehicle_at_dell: around?
20:12:20 <zehicle_at_dell> o/
20:12:23 <ttx> #topic "TC direction" 0.5 scores refinement on Defcore scoring page
20:12:34 <ttx> #link https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf
20:13:02 <ttx> So we wanted to double-check the scoring on that page, especially the "TC direction" column and those 0.5 scores
20:13:07 <zehicle_at_dell> DefCore meeting last week also wanted to get TC input on how to handle scoring going into the future
20:13:11 <ttx> zehicle_at_dell: FWIW I formally contacted the PTLs to help on those unscored lines
20:13:14 <zehicle_at_dell> that's likely a dedicated meeting topic
20:13:20 <zehicle_at_dell> ttx, thanks
20:13:22 <ttx> zehicle_at_dell: yes
20:13:30 <zehicle_at_dell> let me know how we can help.  I'll make myself available
20:13:50 <ttx> I looked at the current scores in htat column and they make sense to me
20:13:56 <zehicle_at_dell> We're making a point of finding a good time for mikal at the next meeting
20:13:57 <ttx> Anyone would like to suggest different scores for any of those ?
20:14:18 <mikal> zehicle_at_dell: I haven't gotten around to that yet, but I think I'll want to sit down with you to work through the nova ones some time in the next week
20:14:30 <mikal> zehicle_at_dell: I will also reply to the meeting time email today
20:14:43 <zehicle_at_dell> ttx, was wondering how the TC wanted to collect feedback about scores that need discussion.  was thinking gerrit like process
20:14:54 <zehicle_at_dell> but happy to do it more interactive if that's the preference
20:15:20 <ttx> zehicle_at_dell: trying to determine how much we need to tweak them
20:15:38 <annegentle> zehicle_at_dell: I should know this, but how can I get a deeper description of a capability, such as compute-auth?
20:15:45 <annegentle> zehicle_at_dell: in tempest itself?
20:15:47 <zehicle_at_dell> ttx, we starting thinking ahead into the Icehouse & Juno reviews.  Assuming that we start from Havana and then need to discuss line by line
20:15:59 <markmc> definitely would be good to have a way of tracking the discussion that went into any particular score
20:16:05 <markmc> but it is looking fairly reasonable to me
20:16:17 <zehicle_at_dell> #link https://github.com/stackforge/refstack/tree/master/defcore/havana
20:16:31 <ttx> I think we can do hte havana one interactively but yes, some more gerrit-driven approach would sclae better for future occurences
20:16:33 <zehicle_at_dell> annegentle, we want to add more detail to the capability json file
20:17:00 <zehicle_at_dell> ttx, +1 on that.  would like to get a discussion about that on a future TC agenda then
20:17:15 <zehicle_at_dell> hopefully, next releases are just deltas
20:17:19 <sdague> annegentle: the answer *should* be in tempest itself, however our docs aren't what they should be either.
20:17:32 <sdague> annegentle: so it would mostly involve reading code at this point
20:17:49 <zehicle_at_dell> sdague, that's why we need to roll up into capabilities
20:17:59 <ttx> #action ttx to schedlue discussion on future scoring process at a future TC meeting
20:18:05 <zehicle_at_dell> even getting short descriptions into that capabilities.json would be a great step for users
20:18:15 <sdague> zehicle_at_dell: yep. We also talked a lot about new doc standards in tempest that would go a long way here
20:18:34 <ttx> zehicle_at_dell: looks like the current scoring is good enough. That only leaves the unscored lines
20:18:36 <sdague> honestly, random folks using tempest need this info too, so I'd love to get it baked back i nthere
20:18:44 <mordred> ++
20:18:49 <zehicle_at_dell> sdague, +1
20:19:04 <ttx> zehicle_at_dell: for the unscored lines you should try to extract data frmo PTLs first
20:19:15 <ttx> zehicle_at_dell: we  can get involved if that process gets stuck, I guess
20:19:34 <zehicle_at_dell> ttx, yes.  was going that route.  was hoping to collaborate on it w/ TCs
20:19:35 <sdague> totally happy to do it in a way that would make it easily / machine extractable for defcore
20:19:39 <ttx> zehicle_at_dell: did any of the PTLs conact you yet ?
20:19:45 <markmc> zehicle_at_dell, mapping to tempest tests here: https://github.com/stackforge/refstack/blob/master/defcore/havana/capabilities.json
20:19:46 <zehicle_at_dell> Swift
20:19:51 <markmc> sorry, that was for annegentle
20:19:59 <zehicle_at_dell> notmyname, has been pretty engaged
20:20:18 <ttx> zehicle_at_dell: I suspect mikal will engage at the next meeting if he can make it
20:20:26 <zehicle_at_dell> (which brings up the other topics we need help with - designated sections)  mikal is working with us on that
20:20:26 <ttx> zehicle_at_dell: that leaves jgriffith
20:20:40 <mikal> Yes, mikal feels guilt about this and means to get to it ASAP
20:20:50 <zehicle_at_dell> yes, jgriffith (thinking @notmyname twitter)
20:21:20 <zehicle_at_dell> mikal, I'm working on a blog about designated sections.  Would be happy to co-author with you.  I'll send you a link
20:21:51 <mikal> zehicle_at_dell: cool, let's talk about it in email
20:21:57 <ttx> zehicle_at_dell: looks like those 0.5 scores actually reflect reality after all
20:22:01 <annegentle> thanks markmc zehicle_at_dell
20:22:08 <ttx> zehicle_at_dell: anything more you need at this point ?
20:22:34 <zehicle_at_dell> timeframe?
20:22:43 <zehicle_at_dell> I'd like everyone on board w/ timing
20:23:02 <zehicle_at_dell> since we'd like to have the advisory Havana list compelete for community review by 7/4
20:23:11 <zehicle_at_dell> so that we can have the board approve it at the OSCON meeting
20:23:34 <zehicle_at_dell> that means all the .5s, the missing sections and (ideally) designated code for the impacted projects
20:24:13 <jgriffith> ttx: zehicle_at_dell I can help with the Cinder sections, but had some q's for zehicle_at_dell
20:24:16 <ttx> zehicle_at_dell: you mean we shouldn't leave any 0.5 ? I think they were acceptable scores ?
20:24:20 <jgriffith> maybe after the meeting?
20:24:29 <ttx> jgriffith: yes
20:24:41 <zehicle_at_dell> ttx, we were trying to make it binary for now
20:25:00 <markmc> ttx, AIUI 0.5 == FIXME :)
20:25:01 <ttx> zehicle_at_dell: ah! sorry, totally missed that.
20:25:05 <zehicle_at_dell> we were using .5 as a place holder for revuew needed.  yes
20:25:24 <ttx> Hmm, then I think we'll have to come up with a formal proposal
20:25:29 <ttx> and Gerrit it
20:25:47 <ttx> any TC member up for drafting a binary proposal for the TC direction column ?
20:25:49 <zehicle_at_dell> ttx, we have the tests in gerrit now
20:25:59 <zehicle_at_dell> I could add the scores to that json file and then let them go under review
20:26:14 <zehicle_at_dell> that's not a process, just the doc
20:26:18 <ttx> I would do it if I weren't traveling all week
20:26:32 <zehicle_at_dell> but it would let you address individual scores per test/capability
20:26:59 <ttx> zehicle_at_dell: let's try to make a proper TC resolution on that
20:27:16 <mordred> ttx: I can do it
20:27:25 <ttx> mordred: cool, thx
20:27:35 <zehicle_at_dell> +1
20:27:44 <ttx> #action mordred to draft binary proposal for the "TC direction" column scores
20:28:06 <zehicle_at_dell> happy to have a smaller or 1x1 meeting about it.  we spent some time in DefCore talking about exactly that
20:28:08 <mordred> ttx: for completeness, I think it should be the whole column, yeah?
20:28:13 <ttx> zehicle_at_dell: then for the missing lines, if you don't get what you need frmo PTLs we can escalate to TC mid-June so that you're still on time for OSCON
20:28:19 <ttx> mordred: indeed
20:28:26 <zehicle_at_dell> thanks.  yes
20:28:43 <ttx> Anything more on that topic ?
20:29:04 <dhellman_> are we assuming that once they are defined in https://github.com/stackforge/refstack/blob/master/defcore/havana/capabilities.json a given capability's definition won't change?
20:29:04 <zehicle_at_dell> mordred, yes.  since any change to the row can impact the whole score.  it's a single unit for review
20:29:31 <zehicle_at_dell> dhellman_, release by release they will likely change
20:29:54 <zehicle_at_dell> small source of confusion > we're using capabilities as proxies for the tests right now.  in next releases, we really should consider the tests
20:30:10 <zehicle_at_dell> because a capability _may_ have some that are not required yet
20:30:22 <zehicle_at_dell> it was just too much work to do it from the bottom up
20:30:29 <zehicle_at_dell> so capabilities were a good compromise
20:30:32 <dhellman_> sure
20:31:07 <dhellman_> I'm just trying to reconcile the idea the the TC is going to vote on a definition of "compute-volume" and that definition will be changing later in a repo where we don't get a re-vote
20:31:21 <sdague> zehicle_at_dell: so in an ideal world, is there a capability level grouping in tempest that we are missing? I sort of thought the capabilities here mapped to tempest directories, but now I'm not quite so sure
20:31:37 <zehicle_at_dell> sdague, yes.  Ideally, it would be managed there
20:32:17 <sdague> zehicle_at_dell: ok, so if there is feedback on restructures to make that clearer in the tempest, that would be appreciated. I think that team would be receptive to it.
20:32:20 <zehicle_at_dell> mainly we did not expect DefCore to take long term ownership of that.  it was needed to move forward this cycle
20:32:24 <ttx> dhellman_: we get to revote at each release actually
20:32:45 <sdague> zehicle_at_dell: yep, all good. Just want to use the feedback to make things better for everyone.
20:32:54 <zehicle_at_dell> I think users would appreciate a consistent capabilities set even if we change some of the tests inside them
20:33:05 <dhellman_> ttx: ok
20:33:27 <zehicle_at_dell> +1000
20:33:29 <ttx> ok, I think we can move on
20:33:36 <sdague> zehicle_at_dell: agreed. And I think it's a good way of "consuming" the information out of tempest, which has become pretty vast
20:33:36 <zehicle_at_dell> +1
20:33:55 <zehicle_at_dell> sdague, I'm working on specs for refstack to help w/ visualization
20:34:04 <sdague> zehicle_at_dell: great
20:34:08 <ttx> #topic K release naming
20:34:16 <ttx> We need to come up with a short list of 3-5 names to submit to a public poll (after trademark checks)
20:34:22 <ttx> Last time we used a Condorcet TC members poll to select that short list out of a larger pool of candidates
20:34:30 <ttx> The candidate names (following the naming rules) are up at:
20:34:35 <ttx> #link https://wiki.openstack.org/wiki/ReleaseNaming
20:34:52 <ttx> Which ones from this list would you like to see on the Condorcet for the short list?
20:34:53 <mikal> Can we have another mutiny over names?
20:34:58 <anteaya> kepler
20:34:58 <ttx> mikal: NO
20:35:01 <sdague> so after talking with mikal, I'd like to apply for a grizzly class exception :)
20:35:03 <mikal> I'd like to see Kilo / Kilogramme added to that list
20:35:09 <markmcclain> why do I get the suspicion that kyoto will win?
20:35:12 <ttx> Personally I'd pick Kepler, Kleber, Kossuth, Kourou, Kyoto
20:35:12 <mikal> Its in Paris, and its a cool name
20:35:20 <zaneb> mikal: ++ :)
20:35:28 <dhellman_> yeah, we should definitely not put names commonly associated with other places on the list
20:35:30 <devananda> kerity, klang, or kepler -- if we stick to that list
20:35:44 <jeblair> devananda: the "havana" boat already sailed ;)
20:35:52 <ttx> mikal: Kilo doesn't mean anything and Kilogramme is WAYY too long. Furthermore, we don't need an exception :)
20:36:11 <mikal> But its out big chance to make fun of those non-metric people
20:36:13 <ttx> And Kepler is an awesome dude, too
20:36:21 <anteaya> ++
20:36:28 <jeblair> ++kepler
20:36:52 * dhellman_ will be voting for Klébér because he wants unicode characters in all the package names
20:36:59 <ttx> Furthermore the refeence kilogram is NOT EVEN in Paris
20:37:17 <anteaya> kindwiller isn't bad
20:37:18 <jeblair> ttx: !!?
20:37:31 <ttx> It's in Sevres. Not Paris. Close. But not Paris.
20:38:08 <mordred> ++kepler
20:38:15 <devananda> ttx: and Juno is not in Atlanta
20:38:18 <anteaya> we need a few choices
20:38:23 <mikal> The IPK and its six sister copies are stored at the International Bureau of Weights and Measures (known by its French-language initials BIPM) in an environmentally monitored safe in the lower vault located in the basement of the BIPM’s Pavillon de Breteuil in Sèvres on the outskirts of Paris.
20:38:37 <mikal> Its in a vault in Paris
20:38:40 <mikal> Whch is awesome
20:38:52 <ttx> key word is "outskirts" :)
20:38:56 <mordred> rule is state - not city
20:38:56 <mgagne> mordred: I'm sad, I can't find a place named Kraken in France
20:38:57 <mikal> Sigh. Dude.
20:39:01 <anteaya> keryado
20:39:05 <mikal> None of us know the edge of Paris
20:39:12 <mikal> Its just a big blob of Frenchyness to us
20:39:12 <markmc> ttx is right, though - 'kilo' is not 'kilogram'
20:39:16 <markmc> kepler it is
20:39:17 <ttx> mikal: I object to that
20:39:24 <ttx> #info names to include i poll
20:39:42 <ttx> #info Kepler, Kleber, Kossuth, Kourou, Kyoto
20:39:44 <mikal> kepler is a good name though
20:39:51 <ttx> #info kerity, klang
20:39:59 <anteaya> keryado?
20:40:00 <markmc> keller ?
20:40:11 <anteaya> I don't think that is hard to figure out how to pronounce
20:40:17 <markmcclain> why not KILLEM? :)
20:40:25 <ttx> killem is pretty neat
20:40:25 <anteaya> no no no
20:40:36 <mikal> Is it too late to argue to Koala?
20:40:41 * mikal is mostly trolling
20:40:42 <jeblair> i would like to see kilo on the list, though i would probably vote for kepler over it
20:40:44 <ttx> mikal: stick to the rules!
20:41:06 <ttx> anteaya: is keryado a french city?
20:41:12 <anteaya> it is on the list
20:41:20 <ttx> #info keryado
20:41:42 <ttx> markmcclain: want killem on the short list condorcet poll ?
20:41:53 <ttx> #info keller
20:42:02 <markmc> http://en.wikipedia.org/wiki/Helen_Keller
20:42:28 <jaypipes> kepler ftw
20:42:37 <zaneb> interesting that almost all the city names beginning with a K are German...
20:42:46 <markmcclain> ttx:  sure
20:42:52 <wendar> that struck me as odd too, history of conquest, I suppose
20:42:53 <ttx> zaneb: yes, Alsacian region
20:42:58 <ttx> the other half are Brittany
20:43:07 <ttx> Ker* stuff
20:43:15 <ttx> Ker meaning village there
20:43:21 <zaneb> ah, interesting
20:43:37 <anteaya> if killem makes the list I want kindwiller
20:43:40 <ttx> anyway, I'll set up the condorcet poll so that TC members can pick a short list of 5
20:43:42 <zaneb> I assume K is not a popular letter at the beginning of a word in French
20:43:48 <ttx> #info kindwiller
20:44:01 <ttx> you assume correctly
20:44:15 <ttx> then we'll submit the list for cursory trademark checks
20:44:32 <ttx> and the resulting list of 3-4 will be pushed on a public poll
20:45:21 <ttx> #action ttx to set up the condorcet poll for TC members to pick the short list
20:45:52 <zaneb> I like the sound of Kirchberg. reminds me of Bavaria :)
20:46:22 <ttx> #topic Requirements changes
20:46:35 <ttx> * Add Ceilometer requirements (https://review.openstack.org/85978)
20:47:21 <ttx> I'm tempted to abandon this one
20:47:41 <ttx> this it doesn't get enough attention from proposer and clogs the meeting every week
20:47:52 <sdague> on the ceilometer bit, I'd kind of like to pull out that + heat + horizon statements and do a more general "integrated projects should integrate with other projects"
20:47:57 <sdague> in a more general way
20:48:20 <ttx> sdague: sounds like a good proposal that would make that one obsolete
20:48:28 <sdague> which I'm happy to propose if there is some agreement on that direction
20:48:38 <sdague> ok, will take as a todo
20:48:48 <ttx> sdague: that said, I think that's where we started from
20:48:52 <ttx> and then people got more specific
20:49:13 <sdague> yeh, let me take a whack at language changes and see if people like it
20:49:14 <devananda> i also remember there being concern at leaving it too generic
20:49:15 <zaneb> sdague: +1 but example don't hurt either
20:49:16 <dhellman_> we did, because we wanted to list the expected ways that integration should happen, at a high level
20:49:32 <ttx> right, so I remember correctly
20:49:40 <sdague> I think general with examples works well. Before it was just general, with no examples
20:49:51 <devananda> give some direction so that future TCs don't miss necessary items in their pre-graduation gap analysis
20:49:54 <sdague> that's how I was redoing the upgrade language
20:50:10 <dhellman_> the problem with general is it doesn't provide a checklist for reviewing integration proposals; we need the checklist *somewhere*
20:50:19 <markmcclain> +1 to checklist
20:50:20 <devananda> dhellman_: ++
20:50:33 <devananda> perhaps we should actually just checklist against /all/ projects
20:50:37 <sdague> dhellman_: honestly, checklists for graduation requirements are overrated I think
20:50:46 <sdague> because there is *so* much context behind these
20:50:59 <sdague> and we've seen substantial confusion on the lists so far
20:51:01 <devananda> which is, itself, a general statement
20:51:14 <ttx> #action ttx to talk to jd__ about his proposal and threaten to abandon it if it doesn't get more love
20:51:19 <ttx> * add upgrade expectations (https://review.openstack.org/87234)
20:51:25 <annegentle> I'm all for talking to future TCs
20:52:10 <ttx> I think the latest version of that one should be good to go, just missing fresh votes
20:52:30 <sdague> much appreciation to devananda and eglynn-afk for catching all my typos
20:52:30 <dhellman_> ttx, I'm rebasing it now
20:52:31 <ttx> will approve when it gets 7 YES
20:52:55 <ttx> #topic Minor governance changes
20:53:00 <jeblair> sdague: er
20:53:02 <dhellman_> https://review.openstack.org/#/c/85978/3
20:53:03 <ttx> * Add project mission statement for Ceilometer (https://review.openstack.org/87526)
20:53:10 <jeblair> sdague: This requirement becomes relevant after the first stable release that	199 a project ships in
20:53:26 <jeblair> sdague: so it's not really a graduation requirement, it's a post-graduation requirement?
20:53:33 <sdague> jeblair: correct
20:53:47 <ttx> One more approval and this one is good to go
20:53:59 <sdague> jeblair: it's in the First Integrated Cycle Expections section
20:54:06 <jeblair> sdague: is there any aspect of that we would want to consider before the graduation vote?
20:54:08 <ttx> The other 3 are housecleaning, and will be approved unless someone screams really soon:
20:54:13 <ttx> * removed openstack/database-api from programs (https://review.openstack.org/95416)
20:54:17 <ttx> * Add infra-specs to infra program (https://review.openstack.org/94896)
20:54:22 <ttx> * add oslo-specs to oslo program (https://review.openstack.org/95226)
20:54:40 <ttx> #topic Open discussion
20:54:49 <sdague> jeblair: I'd love to nudge projects there, which is the reason for this language
20:54:52 <sdague> "		198
20:54:52 <sdague> This requirement becomes relevant after the first stable release that	199
20:54:52 <sdague> a project ships in, however projects are encouraged to incorporate a	200
20:54:52 <sdague> culture of upgradability early in their project lifecycle."
20:55:06 <ttx> sdague: so maybe we can expand on that question of specific vs. general guidelines
20:55:06 <jeblair> sdague: yeah, i think that's really clear.  ++
20:56:22 <sdague> ttx: on open discussion, yay for designate incubation proposal!
20:56:28 <sdague> happy to be discussing that next week
20:56:29 <jeblair> yaaaay!
20:56:46 <markmcclain> finally glad it's back
20:56:49 <ttx> sdague: are they up to snuff on the QA side ? Haven't looked at it yet
20:56:51 <mikal> I have some concerns with designate, but I've mentioned them to the team
20:57:05 <sdague> ttx: haven't yet, will do this week
20:57:17 <mikal> For example, they have an API rewrite planned
20:58:06 <devananda> i continue to have some concerns about ceilometer's scope, but that seems to be overridden by the majority, and i think we've got good progress on the mission statement.
20:58:19 <devananda> awaiting feedback from eglynn on my last suggestion
20:59:12 <eglynn> devananda: just looking at that, I'd be happy to resubmit with those suggested changes
20:59:15 * ttx looks up devananda's concerns
20:59:40 <jeblair> fwiw i also think the 'avoid examples in mission statement' is a good point
21:00:05 <dhellman_> eglynn: if you're going to make more changes, that "reliably" bit seems redundant (we want all of the openstack projects to be reliable, don't we?)
21:00:30 <eglynn> dhellman_: reliably was inserted early in response to feedback
21:00:37 <eglynn> (from jogo IIRC)
21:00:38 <devananda> ttx: gathering billing data vs gathering performance data vs gathering performance data of the tenant's application (eg, for Heat scaling)
21:00:42 <ttx> ok, time is up. Looks like that ceilo mission statement could use one more patchset
21:00:49 <devananda> ttx: three separate things IMO
21:01:03 <ttx> devananda: feel free to -1 it to block it :)
21:01:11 <dhellman_> devananda: gathering similar data for multiple purposes
21:01:12 <eglynn> ok, one more roundtrip to the well :)
21:01:20 <ttx> #endmeeting