20:02:24 <ttx> #startmeeting tc
20:02:24 <markmcclain> o/
20:02:24 <openstack> Meeting started Tue Jul 30 20:02:24 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:27 <openstack> The meeting name has been set to 'tc'
20:02:44 <ttx> Agenda for today is at:
20:02:48 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:57 <ttx> do we have Rob Hisrschfeld around ?
20:03:01 <ttx> -s
20:03:24 <ttx> ok, let's start with devstack then
20:03:42 <mordred> o/
20:03:48 <ttx> (Rob told me he would be present only the first 30min so we might switch to him if he appears
20:03:50 <ttx> )
20:03:54 <ttx> #topic New program application: Devstack
20:04:01 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/011896.html
20:04:06 <ttx> (1) Scope, mission statement, how "essential" the effort is to OpenStack
20:04:14 <ttx> So this is mostly an oversight when we set up the original list of already-accepted programs
20:04:24 <ttx> Devstack was an official project in the old taxonomy, so there is no question of it being official/essential or not
20:04:34 <ttx> The question was more in the scope, should it land in QA, Infra, or in its own program
20:04:46 <ttx> Personally, since the core people caring about devstack are a separate set of the people caring for Infra or QA, it makes sense as a separate program
20:04:55 <mordred> I agree
20:05:00 <russellb> is it really a separate group?
20:05:07 <markmc> I see it as a developer tool, would like the mission statement to say something about that
20:05:15 <markmc> seems like a different group to me
20:05:17 <russellb> it seems sdague and dtroyer are the main reviewers, and they are both in qa-core
20:05:23 <mordred> also, again, the fact that we use devstack for infra or qa is an implementation detail. it's not devstack's primary purpose in life
20:05:26 <dtroyer> I am?
20:05:26 <markmc> e.g. would dtroyer identify himself as infra or QA?
20:05:29 <ttx> russellb: enough for QA and infra not wanting to sheperd it
20:05:34 <russellb> dtroyer: grenade?
20:05:40 <dtroyer> I didn't think I was in either team
20:05:47 <dtroyer> ah, right
20:06:00 <markmc> well
20:06:06 <dtroyer> does wearing one hat affect the other?
20:06:10 <ttx> russellb: in the end if neither program adopts it, that means it's a separate group
20:06:18 <markmc> I think that answers the "would dean identify himself as QA?" question :)
20:06:18 <ttx> even if it has people in common
20:06:18 <jgriffith> o/
20:06:19 <russellb> ttx: yep, guess so
20:06:37 <ttx> <markmc> I see it as a developer tool, would like the mission statement to say something about that
20:06:45 <mordred> I dont' think it's about dean's self-identification - I see it as that ^^
20:06:49 <mordred> that's not the mission of qa
20:06:52 <mordred> and it's not the mission of infra
20:06:54 <ttx> current mission statement is:
20:06:56 <markmc> oh, it does say that
20:06:58 <ttx> "To provide an installation of OpenStack from git repository master, or specific branches, suitable for development and operational testing.  It also attempts to document the process and provide examples of command line usage."
20:07:03 <markmc> yeah, sorry
20:07:08 <markmc> missed "suitable for development"
20:07:09 <ttx> markmc: does that work for you ?
20:07:12 <markmc> yep
20:07:46 <ttx> More comments/questions on the  Scope, mission statement part ?
20:08:19 * mordred thinks dtroyer is great
20:08:32 <ttx> (2) Team/effort/community maturity
20:08:42 <ttx> That effort is pretty mature by now. It's even almost in stable mode :)
20:09:01 <markmc> definitely
20:09:10 <ttx> dtroyer: is there more to do rather than maintain it ? Any short-term / mid-term objectives for the devstack "program" ?
20:09:26 <ttx> At this point it's a bit of a catch-all project with a lot of pass-by contributors
20:10:04 <dtroyer> The bulk of the work right now is making it all fit together but there is a lot of room for improvement
20:10:23 <dtroyer> mostly incremental though, no plans for radical changes
20:10:28 <ttx> dtroyer: and constant work to integrate more projects, i suppose
20:11:08 <ttx> Comments / Questions on the  Team/effort/community maturity aspect ?
20:11:12 <dtroyer> right.  a lot of that work comes out of the projects though as they know how their code should run
20:12:03 <ttx> OK, ready to vote ?
20:12:22 <jd__> yup
20:12:25 <mikal> Sure
20:12:25 <markmc> #vote yes
20:12:29 <ttx> tss
20:12:32 <ttx> wait for the signal
20:12:37 <markmc> #vote ok
20:12:43 <markwash> #vote lol
20:12:47 <ttx> #startvote Accept Devstack as an official OpenStack program? yes, no, abstain
20:12:48 <openstack> Begin voting on: Accept Devstack as an official OpenStack program? Valid vote options are yes, no, abstain.
20:12:49 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:12:49 <mikal> #vote yes
20:12:50 <markmc> #vote yes
20:12:52 <galstrom> #vote yes
20:12:54 <russellb> #vote yes
20:12:56 <ttx> #vote yes
20:12:56 <jgriffith> #vote yes
20:12:57 <shardy> #vote yes
20:12:58 <mordred> #vote yes
20:12:58 * markwash votes for two
20:12:58 <jd__> #vote yes
20:13:00 <markwash> #vote yes
20:13:01 <markmcclain> #vote yes
20:13:12 <ttx> markwash: you need to switch nicks before voting a second time.
20:13:35 <markwash> ttx: we can probably just let this one slide
20:13:39 <ttx> yeah
20:13:45 <gabrielhurley> #vote yes
20:13:45 <ttx> 30 more seconds
20:14:11 <ttx> #endvote
20:14:12 <openstack> Voted on "Accept Devstack as an official OpenStack program?" Results are
20:14:14 <openstack> yes (12): markmc, ttx, galstrom, shardy, jd__, russellb, jgriffith, mikal, mordred, gabrielhurley, markwash, markmcclain
20:14:16 <ttx> So that's a yes.
20:14:28 <dtroyer> Thanks all...I promise not to rewrite it all in Go.
20:14:30 <ttx> dtroyer: congrats. Not that it changes anything, but congrats still.
20:14:36 <jgriffith> dtroyer: haha!
20:14:42 <ttx> dtroyer: right, I missed that question.
20:14:45 <mordred> dtroyer: oh. wait. I thought you were going to do the opposite
20:14:49 <markmc> wait, did we just approve a non-python project?
20:14:52 <markmc> wut?!?
20:15:01 <jgriffith> indeed
20:15:03 <mordred> markmc: my friend - infra has several java repos...
20:15:11 <ttx> ssshhhh.
20:15:12 <markmc> mordred, burn!
20:15:14 <ttx> #topic Open discussion
20:15:23 <ttx> First thing I wanted to mention, I submitted a "Meet the Technical Committee" panel session for the next OpenStack Summit
20:15:30 <ttx> The idea being to explain what the TC does, our recent changes and decisions, and field questions from the audience
20:15:32 <gabrielhurley> mordred: you better hope the board don't make you use the common python API code for all that...
20:15:43 <ttx> We don't really know who will be in the TC by then, some people will probably not be available at the time it's scheduled (if it's accepted), and we don't really need EVERYONE to be present...
20:15:51 <ttx> but I wanted to give you an early heads-up in any case
20:15:58 <mordred> gabrielhurley: I'll implement it as a plugin
20:16:02 <gabrielhurley> lol
20:16:16 <ttx> & "plug-in"
20:16:17 <mordred> ttx: I'll be there - I have no idea if I'll still be TC - but I'll be there
20:16:31 <ttx> mordred: trying to crash ALL the panels ?
20:16:33 <gabrielhurley> ttx: +1, the "meet the core devs" sessions are always useful and well-attended at other open source conferences.
20:16:39 <markmc> ttx, sounds like a good idea (the TC panel thing)
20:16:48 <ttx> The other thing I wanted to mention is that some of us mentioned the idea of considering non-voting tempest integration as a prerequisite before graduation from incubation
20:16:57 <ttx> Historically we asked projects to set up QA/gating/tempest integration in the first months after graduation...
20:16:57 <mikal> gabrielhurley: should we have a meet the core devs session at the summit then?
20:17:03 <mordred> ttx: ++
20:17:08 <ttx> But in some cases that came back to bite us as other priorities tend to interfere
20:17:10 <mordred> I would very much like to have this be a real thing
20:17:19 <ttx> If we take that stance, it should be communicated. Trove might find it difficult to set up such thing in the time left before the end-of-cycle graduation review (end of August)
20:17:22 <gabrielhurley> mikal: that's called "the entire summit". just getting the TC together and answering questions is good enough.
20:17:30 <mordred> graduation from incubation should have as a requirement demonstrable non-voting gate jobs
20:17:33 <mordred> that work
20:17:41 <markmc> tempest requirement sounds reasonable ... but there's some minimal bar of test coverage too
20:17:51 <markmc> not just "a single tempest test to ping the API endpoint"
20:18:04 <mordred> nope. it should make us say "yes, when we turn that on as a gate, it will matter"
20:18:13 <mordred> and have been running long enough that it doesn't seem flaky
20:18:16 <ttx> markmc: sure, we always had that test coverage question... askign that they set up some CI gate is new though
20:18:32 <mikal> gabrielhurley: well, we discourage conference attendees from coming to design summit sessions now, so that's not entirely true
20:18:35 <markmc> the CI gate has to test something though
20:18:35 <mordred> thing is - one of the things they get out of incubation is that infra will talk to them
20:18:53 <gabrielhurley> mikal: damn. you've got me there... propose it if you like. ::shrug::
20:18:54 <mordred> so I'd see that they should make use of that during their incubation
20:18:55 <ttx> It /MIGHT/ make Trove fail graduation if they can't make it happen in the remaining time.
20:19:05 <ttx> hub_cap: fair warning ^
20:19:15 <markmc> mordred, what, at a minimum, should the gate for a new project test?
20:19:20 <hub_cap> oh im watching
20:19:20 <hub_cap> thx ttx
20:19:23 <hub_cap> but i do have a Q
20:19:32 <hub_cap> how come im alerted to this < 2mo in
20:19:39 <mordred> markmc: I don't know - I think quality of the gate might need to be  ajugdgement call from us for a bit
20:19:41 <ttx> hub_cap: given that you're the first project to be held to that standard, feel free to raise questions
20:19:43 <hub_cap> and required :) cant it be for /new/ projects?
20:19:58 <markmc> mordred, right - we need to give fair warning that it's not just a single API ping test
20:19:58 <hub_cap> i feel it'd be fair if i knew it from teh start, since heat integration was my requirement
20:20:25 <mordred> hub_cap: to be fair - you DO have a devstack-based integration gating test right now - so I betcha a single person could get that transitioned to the devstack gate if they were motivated
20:20:28 <mordred> but it's a fair question
20:20:37 <hub_cap> im _totally_ interested in tempest, and its #2 on the list of things for me to do
20:20:45 <hub_cap> but heat being #1 i dont want to skimp on it :)
20:21:37 <mordred> I'm fine with not adding the hard requirement this cycle - especially because I know that trove does have testing automation based on devstack-gate already
20:21:39 <hub_cap> sure mordred but motivated != pressured ;)
20:21:48 <mordred> but I do want it to be a thing that we consider important
20:21:58 <hub_cap> +1 mordred as soon as im done w/ heat integration im doing it
20:22:00 <ttx> hub_cap: it's a bit unfair to sump the requirement after so many months of incubation, yes
20:22:06 <hub_cap> heh ttx
20:22:06 <mordred> devananda: ^^ also, this may or may not apply to you too
20:22:23 <hub_cap> we are diligently trying to get out of incubation this cycle fwiw
20:22:49 <ttx> I'm fine with considering a good work in progress sufficient in the Trove case, if we have insurance it's really top priority for the team
20:22:51 <hub_cap> err, graduate incubation ;)
20:23:04 <hub_cap> ttx: guaranteed its my prio after heat integration
20:23:11 <ttx> mordred, others: thoughts ?
20:23:12 <hub_cap> im not a fan of having tests that are different from the community
20:23:36 <hub_cap> but we have tests :) and a ton of em
20:24:05 <ttx> Next on the open discussion we have Trove scope expansion to NRDB. It was raised a bit late to be formally considered by the TC, but we can still discuss it
20:24:12 <hub_cap> yea i figured ttx
20:24:21 <hub_cap> id be happy to start the discusion now and finish it next wk
20:24:42 <ttx> annegentle wanted to make sure her mission statement was ok, too, before she runs with it
20:24:51 <hub_cap> ok /me waits
20:25:00 <markmc> heh, a schedule for the open discussion :)
20:25:06 <hub_cap> lol
20:25:06 <markmc> agenda, rather
20:25:21 <ttx> "open discussion" just means "in parallel" for me :)
20:25:28 <hub_cap> ok then ill go!
20:26:16 <ttx> hub_cap: go for it
20:26:19 <hub_cap> so our redis POC makes no changes to the core api+core infrastructure. its just another _impl_. there are 2 extensions that are tied a bit to the guest impl but the redis guys are making those extensions in the guest as well. the guest already has a notion of 'im service X', so it can pretty easily get extensions from the codebase as well
20:26:39 <hub_cap> and the /clusters api will also have 'cluster flavors' as we call it
20:27:04 <hub_cap> so if you upgrade your redis instance, you will have a list of avail flavors so to speak, to upgrade to (not many for redis, mysql has many more)
20:27:12 <markmc> hub_cap, is the POC code posted anywhere?
20:27:27 <hub_cap> markmc: sooooo it is, pre rename
20:27:32 <hub_cap> let me push it into the codebase
20:27:38 <hub_cap> or at least put up a WIP review
20:27:45 <hub_cap> im sick as a dog today but ill rip it out tomorrow
20:27:48 <mordred> put up a WIP review I think would be great
20:27:54 <markmc> it'd be great to do that, fire a mail to openstack-dev and let folks take a look
20:27:55 <hub_cap> roger
20:28:06 * markmc doesn't have much of an opinion
20:28:07 <hub_cap> absolutely. ill reply to the email i sent
20:28:19 <hub_cap> i like your opinion markmc :)
20:28:19 <ttx> anything else hub_cap could do in preparation for next week's decision ?
20:28:28 <markmc> but maybe there's someone out there who has started working on something like this and has good insights
20:28:30 <mordred> so - my concern is
20:28:36 <hub_cap> :o
20:28:56 <mordred> what do we do if now trove has mysql + redis + cassandra + mongodb + bearddb
20:29:06 <mordred> and we end up with the virt-layer problem in nova
20:29:08 <hub_cap> +1 to bearddb
20:29:18 <mordred> of not-well-tested backends or backends that are abandoned
20:29:20 <hub_cap> well mordred i wont accept any impl w/o sufficient tests
20:29:28 <hub_cap> and i will deprecate / remove them if they are not used
20:29:35 <hub_cap> i dont like bitrot
20:29:57 <mordred> but are you going to expect the infra to test all the different backend combos?
20:30:00 <russellb> mordred: i'm moving to requiring public CI for all of them by the release of Icehouse (even if it's third party testing, as long as results are public)
20:30:12 <mordred> russellb: ++
20:30:12 <hub_cap> +1 russellb ill do the same
20:30:18 <russellb> i'd like to see a similar requirement everywhere
20:30:24 <mordred> yeah. I could totally live with that
20:30:24 <hub_cap> well mordred ill fire up clusters, mysql or _blah_
20:30:28 <russellb> i know jgriffith is wanting to do something along those lines as well, based on recent ML posts
20:30:30 <jgriffith> this sounds vaguely familiar :)
20:30:35 <russellb> jgriffith: :-)
20:30:42 <hub_cap> heh
20:30:43 <mordred> my main concern was explosive backends
20:30:46 <jgriffith> I think it's a natural progression
20:30:47 <mordred> hrm
20:30:49 <hub_cap> dirty
20:31:00 * mordred looks away in shame
20:31:04 <jgriffith> mordred: ha!!!
20:31:11 <russellb> >_<
20:31:17 <ttx> -_-
20:31:26 <hub_cap> :D i liked it
20:31:28 <markmc> *snort*
20:31:33 * hub_cap channels my inner markwash
20:31:37 <annegentle> lol
20:31:44 * markwash lold
20:31:48 <jgriffith> I think coffee just came out my nose
20:32:02 <hub_cap> so, mordred given that i wont allow code w/o sufficient tests
20:32:05 <jgriffith> which is still better than what happened to mordred
20:32:06 <hub_cap> tempest tests, since they are new
20:32:26 <hub_cap> and that ill work w/ you to make sure that your infinite cloud resources are not wasted :P
20:32:50 <hub_cap> fwiw, we will be doign the same testing w/ mysql, for clusters.. so, i think its a natural progression. and cluster testing will be in tempest as well
20:33:36 <hub_cap> and we could say the same w/ RDB systems, im sure we could impl a ton of those as well and end up w/ teh same issues
20:33:51 <hub_cap> clustered sqlite anyone?
20:34:03 * hub_cap assumes its not really possible ;)
20:34:25 <mordred> oh god
20:34:29 <ttx> ok, any more questions on trove nrdb ? More next week about this anyway
20:34:45 <hub_cap> yes ttx. ill have the POC shot to the ML tomorrow
20:34:50 <hub_cap> for your perusing
20:34:52 <ttx> annegentle: want to raise your program description, or the consequences of it ?
20:35:14 <hub_cap> me annegentle?
20:35:25 <annegentle> ttx: I'll just point out the summary
20:35:39 <annegentle> Since we cannot govern all documentation equally with the resources available, our focus is core first and users first…
20:35:53 <hub_cap> oh sry ttx... i thought annegentle said that to me, the fever is getting the best of me
20:36:10 <annegentle> oh dear :)
20:36:15 <ttx> annegentle: I think prioritization is fair.
20:36:58 <annegentle> I think I'll be shaping and honing further as we work on release documents, but I think that we'll continuously publish all the time.
20:37:42 <annegentle> it's just that continuous release doesn't mean "all the documented procedures all the time"
20:37:47 <ttx> annegentle: I still think if someone wants to work on some integrated project and document that, he should still be able to do so within the docs team
20:38:01 <annegentle> ttx: absolutely, we'll coach and assist as much as possible
20:38:02 <ttx> but mentioning priorities sounds good to me
20:38:40 <ttx> comments on that ? Can annegnetly run with her program description ?
20:38:45 <ttx> annegentle, even
20:38:48 <annegentle> can I run gently? :)
20:38:52 <ttx> gently.
20:39:05 <annegentle> I believe perfection is the enemy of good.
20:39:17 * markwash thinks you should /nick annerunsgently
20:39:33 <mikal> I'm ok with focussing on core and users
20:39:45 <annegentle> so we will continuously improve to collaborate wider, and we've gotten many more contributors even in the last three months
20:40:15 <markmc> I'd be a little wary of using "core" as the basis for prioritization, but absolutely some projects should be prioritized over others
20:40:15 <hub_cap> heh
20:40:35 <ttx> markmc: as long as it's not exclusive, i don't mind so much
20:40:36 <markwash> I guess I pretty much trust the docs people to know the correct prioritization
20:40:45 <markmc> *nod*
20:41:05 <markmc> e.g. "what users care most about"
20:41:26 <anneisgentle> markmc: yeah and I specifically took the user committee's definitions of users
20:41:27 <ttx> agree that documenting ceilometer is less important than documenting heat, for example
20:41:41 <anneisgentle> ttx: the great thing is, ceilometer has a great dev doc site
20:42:05 <ttx> heh
20:42:22 <ttx> Last thing I had on the agenda, although it's a bit emply if Rob is not around, is the Spider "what is core" thing
20:42:29 <ttx> "empty"
20:42:38 <markmc> so, on the "what is core" thing
20:42:49 <markmc> I feel like the conversation has progressed on into the far distance
20:43:01 <markmc> and I'm still stuck back trying to figure out what problem we're addressing
20:43:19 <markmc> e.g. I thought it was about using the trademark as a lever to ensure compatibility between public clouds
20:43:28 <markmc> and help form a market place of public clouds
20:43:38 <markmc> yet, rob's "why we care about core" blog:
20:43:39 <markmc> http://robhirschfeld.com/2013/07/22/making-openstack-meaningful/
20:43:47 <markmc> doesn't mention any of that
20:43:56 <ttx> markmc: so I'm not sure it makes any progress to solve the question of inclusive vs. limited number of projects
20:43:57 <markmc> it's all about ensuring we have a healthy project or something
20:44:03 <markmc> this is just occurring to me now, really
20:44:22 <ttx> some people apparently think that interop is easier if you limit the number of projects
20:44:27 <markmc> I'm just curious what other TC members make of the discussion
20:44:28 <ttx> I kinda think the opposite
20:44:41 <jgriffith> It's kind of all over the board IMO
20:44:58 <ttx> if we let every "openstack cloud" implement their own version of designate... we lose in interop
20:44:59 <jgriffith> markmc: My opinion was intially a better/tighter definition of OpenStack
20:45:04 <mikal> markmc: I think public cloud interop is important, but I'm not convinced that a big trademark hammer is the way to do it
20:45:05 <jgriffith> but I don't think that's the direction any longer
20:45:13 <mikal> markmc: but I don't have an alternate proposal either
20:45:20 <gabrielhurley> I'm with jgriffith: everyone want's a different problem addressed. We're no longer trying to achieve any one thing with it (if we ever were).
20:45:31 <markwash> markmc: +1 let's reaffirm the problem statement
20:45:38 <ttx> if we say "an openstack cloud must have DNSaaS and it must be Designate" then the end result is more interoperable
20:46:17 <ttx> I think the tradeoff is between "a lot of openstack clouds, somehow interoperable" and " a few very interoperable openstack clouds"
20:46:23 <mordred> yes
20:46:25 <markmc> but like
20:46:29 <markmc> what does e..g "Velocity – the rate of progress and quality of the code base.  "
20:46:36 <markmc> or "Culture – open source culture strongly encourages sharing and collaboration."
20:46:41 <markmc> have to do with any of this?
20:46:49 <mordred> markmc: the stuff that rob is collecting and putting together
20:46:58 <jgriffith> markmc: I can't speak for Rob but I had some conversations about that unrelated to the interop question
20:47:08 <AlanClark> is it kosher for me to jump into the conversation since I am not on the TC?
20:47:13 <mordred> are supposed to be basis for discussion and not the definitoin of it
20:47:15 <mordred> AlanClark: please do
20:47:27 <ttx> markmc: where is that ?
20:47:27 <AlanClark> thanks
20:47:27 <mordred> this is all open sores and stuff in here
20:47:28 <jgriffith> markmc: we talked a bit about how to keep components like Nova, Neutron etc focused and continuing to get better
20:47:35 <gabrielhurley> I'd also like to point out that ""an openstack cloud must have DNSaaS and it must be Designate" then the end result is more interoperable" is not actually true. How often do you try to make the existing OS services talk to themselves across clouds?
20:47:38 <jgriffith> with the explosion of *other* things being introduced
20:47:50 <ttx> markmc: I've been looking at http://robhirschfeld.com/2013/07/24/what-is-core-strawman/ and it doesn't mention velocity or culture
20:47:51 <gabrielhurley> I'd argue that competing implementations of the same standard improves interop
20:48:13 <jgriffith> gabrielhurley: interesting point, which makes me suggest we need to define better the *what*
20:48:13 <markmc> ttx, http://robhirschfeld.com/2013/07/22/making-openstack-meaningful/ is framed as "why core is important"
20:48:14 <mordred> gabrielhurley: well, that's one of the things that we keep coming back to - we are not a standards body
20:48:23 <markmc> ttx, from http://robhirschfeld.com/2013/07/22/kicking-off-core/
20:48:25 <gabrielhurley> we don't know what we are
20:48:25 <mordred> we are and always have been, a body where implementation is the definition
20:48:27 <shardy> gabrielhurley: we are trying to do exactly that with heat in standalone mode
20:48:27 <mordred> we do
20:48:32 <jgriffith> gabrielhurley: +10000
20:48:33 <mordred> know that we are not a standards body
20:48:37 <ttx> markmc: I skipped that one and jumped directly to the strawman
20:48:38 <gabrielhurley> says who?
20:48:48 <mordred> we've said that strongly since day one
20:48:51 <gabrielhurley> there's a lot of language in what Rob sent out that borders on being a standards body
20:48:56 <mordred> at no point have we ever said differnetly
20:49:01 <mordred> well, we'll fix that
20:49:11 <mordred> that's why the focus on running the code
20:49:13 <markmc> ttx, I'm note sure the strawman details the problem being addressed either
20:49:14 <mordred> and not just being api compat
20:49:20 <mordred> if all you need is api compat to be openstack
20:49:28 <mordred> then we're a standards body - just a poorly organized one
20:49:34 <gabrielhurley> mordred: that's why *you* focus on running the code... there are still a lot of folks in the community who are more concerned with API specs.
20:49:35 <mordred> but we're not - we ship software
20:49:50 <mordred> absolutely. api specs are important
20:49:58 <mordred> and I gotta well you - when clouds diverge we all lose
20:50:09 <gabrielhurley> agreed on that
20:50:18 <mordred> but I'm not interested in specs that are there to allow some jackass to go rewrite openstack in java because he just doesn't like python
20:50:18 <ttx> personally I have 3 gripes with the thing: (1) the use of "plug-in" term (solved), (2) it doesn't address the hard question of inclusive vs. limited approach, and (3) it relies a lot on tempest testing which will not just happen by magic
20:50:23 <jd__> that could be a song
20:50:26 <mordred> becuse that doesn't help anyone
20:50:42 <jgriffith> mordred: I agree with that, but I think there's a spot in the middle
20:50:49 <mordred> jgriffith: I agree with you :)
20:51:10 <mordred> I just think that we have to have code - if all we have is a spec, then we're not very interesting
20:51:33 <mordred> ttx: it's not intended to address 2
20:51:35 <gabrielhurley> mordred: you'd rather cling to python than accept some jackass' rewrite even if it's better, faster, and more reliable? (hypothetically speaking)
20:52:00 <mordred> gabrielhurley: if the TC decides that the jackass rewrite is better and that we should switch to it, then fine
20:52:12 <mordred> but until then, whatever that thing is, it's not openstack
20:52:15 <markwash> mordred: that's not really how consensus evolves :-)
20:52:22 <gabrielhurley> I'm not arguing for not having code, I just don't want to us to write bylaws that specify coding practices or languages
20:52:35 <hub_cap> is that not already implicit?
20:52:36 <mordred> I also do not want that - and don't want to imply that
20:52:37 <hub_cap> :P
20:52:52 <mordred> but I think that openstack is quite specifically the output of those of us who form openstack
20:52:59 <jgriffith> No offense but aren't we getting a bit sideways on this?
20:53:04 <gabrielhurley> yep
20:53:06 <mordred> heh
20:53:07 <gabrielhurley> and yep
20:53:12 <markmc> jgriffith, aresways is the precise term
20:53:19 <markmc> heh, typo
20:53:20 <jgriffith> markmc: haha
20:53:22 <markmc> sad, failed joke
20:53:31 <mordred> ttx: it's intended to provide framing for 2
20:53:32 <jgriffith> intent was received :)
20:53:54 <ttx> markwash: at the heart of the project is a community of developers. You won't turn them into Java devs overnight
20:53:55 <mordred> with the idea that, like judgements about technical things, there's always going to be judgement calls to be made, and you can't just constitution a defition up
20:54:01 <gabrielhurley> soooo... we should refine/restate the problem definition and then cut everything from the "what is core" document that's not addressing that problem?
20:54:19 <jgriffith> gabrielhurley: might be a good way to start
20:54:22 <ttx> markwash: so I'm with lordred on that one, whatever that thing is, it's not openstack
20:54:31 <mordred> I think that the point of the document is still being very poorly communicated
20:54:35 <gabrielhurley> lordred... he's been upgraded
20:54:40 <markwash> whos trying to make people into java devs?
20:54:59 <ttx> markwash: <gabrielhurley> mordred: you'd rather cling to python than accept some jackass' rewrite even if it's better, faster, and more reliable? (hypothetically speaking)
20:55:08 <galstrom> gabrielhurley: ++
20:55:10 <markwash> I just think reboots are healthy and it looks like a cohesive community would never do them
20:55:25 <jgriffith> ttx: mordred gabrielhurley so last spring we started having this disucssion among the TC IIRC (what is core) and punted it to the board
20:55:36 <jgriffith> IIRC we were trying to think about "what is OpenStack"
20:55:40 <gabrielhurley> that ^^^. it's not something you should be proscriptive against. just trust that if you do the right thing you won't ever need to.
20:55:40 <jgriffith> so we punted
20:55:42 <ttx> I was happy to punt
20:55:49 <mordred> this document is an attempt to collect all of the various fibers that are running around this topic
20:55:54 <mordred> it turns out that there are MANY
20:56:00 <gabrielhurley> too many
20:56:03 <jgriffith> ttx: yes, now I remember why we did so :)
20:56:03 <mordred> as the basis to frame a real discussion
20:56:04 <markmc> way too many
20:56:05 <markmc> is this discussion purely about using the trademark to ensuring interoperability clouds which call themselves OpenStack?
20:56:09 <ttx> jgriffith: I think we should keep it punted
20:56:11 <mordred> it's not intended to be a definition of core
20:56:13 <ttx> jgriffith:
20:56:25 <jgriffith> ttx: I'm mixed, only because I'd like some false sense of my destiny :)
20:56:27 <ttx> and just make sure they don't insert tech language in wahetever they come up with
20:56:29 <mordred> also, I think the word core needs to diaf
20:56:32 <mordred> it's become useless
20:56:42 <jgriffith> ttx: that may be the best approach
20:56:55 <markmc> mordred, we should call this discussion "how our trademark program for public clouds should work"
20:57:00 <anneisgentle> mordred: (or lordred, whatevs) what's diaf?
20:57:03 <jgriffith> ttx: I don't think we necessarily have the same perspective/interests
20:57:09 <mordred> anneisgentle: 'die in a fire'
20:57:10 <hub_cap> fire fire fire
20:57:11 <med_> die in a fire
20:57:11 <jgriffith> ttx: ^^ I mean TC versus board
20:57:15 <ttx> markmc: jgriffith has a point. Should we care, as the TC ?
20:57:23 <gabrielhurley> I say we should care, yes.
20:57:31 <mordred> markmc: I think it's "What does the word OpenStack mean?"
20:57:34 <markmc> what's in the strawman is an awful lot of stuff we care about
20:57:35 <jgriffith> markmc: ttx that's a great point, and I'm mixed
20:57:35 <gabrielhurley> expecially to make sure they're not inserting extra stuff into it like they clearly are
20:57:43 <ttx> gabrielhurley: care about trademark rules ?
20:57:50 <mordred> markmc: which I think is broader and more relevant than trademark law, but certainly informs that
20:57:51 <markwash> I mean, as much as this has to do with how api specs work, I think we care
20:58:08 <markwash> does it have nothing to do with api specs?
20:58:13 <mordred> I do not believe it's intended to have anything do to with api specs
20:58:15 <markmc> mordred, if that's the discussion, I think it's doomed
20:58:18 <gabrielhurley> ttx: if they were *only* and I mean really *only* talking about trademark rules I think we should be aware but it's totally their right to ignore us. But they're not at all.
20:58:18 <ttx> gabrielhurley: I agree we need to watch the process to make sure it doesn't go west
20:58:24 <mordred> markmc: that has to be answered. full stop.
20:58:41 <markmc> mordred, start with "what does the word Cloud mean?" then :)
20:58:44 <mordred> markmc: becuase without an answer to that, the question of how the trademark around it can be used is meaningless
20:58:54 <mordred> markmc: no, this is very specific and very important
20:58:59 <jgriffith> markmc: ha!!  I just solved that one the other day :)
20:59:02 <ttx> gabrielhurley: *that* is what we need to address I think.
20:59:12 <mordred> because if a person is going to interact with a thing named "OpenSTack" they need to know what they can and cannot expect from that thing
20:59:17 <mordred> which is why we name things with proper names
20:59:20 <ttx> gabrielhurley: not sure where they go beyond trademark rules though
20:59:25 <ttx> one minute left
20:59:27 <jgriffith> mordred: +1
20:59:29 <mordred> to give htem defining characterstics
20:59:36 <markmc> mordred, "a thing named OpenStack" == a public OpenStack cloud
20:59:38 <jgriffith> mordred: that's the part I'm interested in
20:59:40 <markmc> mordred,  or the project, or ... ?
20:59:46 <markmc> OpenStack is a lot of things
20:59:46 <mordred> markmc: the product
20:59:47 <jgriffith> markmc: no
20:59:47 <gabrielhurley> markmc: "public"?
20:59:59 <mordred> markmc: if I want to interact with an openstack cloud - what can I expect from it
21:00:00 <ttx> last minute thing: I'm not very hapopy we have that discussion on openstack-tc btw
21:00:00 <jgriffith> markmc: framwork for building/managing public and private clouds
21:00:06 <gabrielhurley> there are a lot of private openstack clouds that care about the trademark
21:00:06 <mordred> markmc: it's entirely possible...
21:00:11 <mordred> markmc: that we need to be more specific
21:00:14 <mordred> similar to java
21:00:16 <jgriffith> gabrielhurley: +10000
21:00:17 <mordred> Java VM
21:00:20 <mordred> Java Language
21:00:21 <mordred> etc.
21:00:24 <ttx> would like Rob to push it to a public list if it is to continue
21:00:34 <jgriffith> automate all things!
21:00:36 <ttx> OK, we are out of time
21:00:38 <gabrielhurley> ugh... 'cuz that'll narrow it down
21:00:44 <ttx> more next week maybe
21:00:44 <markmc> OpenStack the word is more than just what the expectations of the interface to an OpenStack install looks like
21:00:47 <ttx> or on the list
21:00:53 <mordred> markmc: I agree
21:00:54 <markmc> which is why I thought "the word" thing was too broad
21:00:59 <ttx> #endmeeting