20:01:18 <ttx> #startmeeting tc
20:01:19 <openstack> Meeting started Tue Mar 18 20:01:18 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:23 <openstack> The meeting name has been set to 'tc'
20:01:35 <ttx> Thanks to markmc for chairing last week
20:01:39 <ttx> Our agenda for today:
20:01:44 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:01:48 <markmc> ttx, np; nothing compares 2 u
20:01:54 <ttx> We'll probably not complete all of this agenda and overflow to next week
20:02:00 <ttx> markmc: now I have music on my mind
20:02:16 <ttx> nothiiing compares    to you
20:02:34 * markmc tries to force some tears for the close-up shot
20:02:34 <ttx> devananda: around ?
20:02:41 <devananda> o/
20:02:45 <ttx> #topic Ironic graduation review
20:02:54 <ttx> This one should hopefully be quick, as we unofficially covered it in past discussions
20:03:06 <ttx> We added a lot of new graduation requirements during this cycle, as well as stronger QA requirements, which is a very good thing
20:03:17 <ttx> but it also means potentially longer incubation for projects that were incubated before we spelled those new requirements out
20:03:36 <ttx> For Ironic I think time ran short to complete new graduation requirements wrt. Nova integration in the Icehouse release
20:04:10 <ttx> Which IMHO means Ironic can't be integrated in Juno and will have to wait for K for common release
20:04:34 <annegentle> ttx: sounds sound
20:04:36 <ttx> anyone thinks different ? (besides Apple)
20:04:36 <jgriffith> o/
20:04:47 <russellb> apple?
20:04:49 <jeblair> is there an etherpad worksheet for ironic, like we've had for the reviews of nova, etc?
20:04:50 <devananda> FWIW, we had planned on doing the QA work after graduation // in Juno, based on discussions at the last summit, so as those req's were written down during the cycle, we were not prepared.
20:04:55 <ttx> russell_h: Think different.
20:05:05 <russellb> ah.
20:05:06 <ttx> russellb: "Think different"
20:05:17 <dhellmann> #link https://etherpad.openstack.org/p/IronicGraduationDiscussion
20:05:31 <russellb> i don't think the driver was ready for code review until towards the very end anyway
20:05:33 <markmc> dhellmann, thanks
20:05:40 <devananda> dhellmann: I havn't updated that ehterpad recently
20:05:41 <russellb> even without the CI requirement, i think it was cutting it close
20:05:55 <ttx> devananda: yeah. Frankly, this should not be seen as blame. We raised the bar while you started to jump.
20:05:56 <mikal> The CI require was also advertised for a long time
20:05:57 <dhellmann> devananda: noted
20:06:13 <devananda> without the CI req and the deprecate-nova-bm req, I think we would be very close
20:06:35 <ttx> and I think raising the bar was a good thing
20:06:40 <devananda> would probably miss the deployer-documentation requirement too, though we have folks working on that now (and had intended to work on it during FF)
20:06:55 <annegentle> devananda: good on ya
20:07:11 <devananda> also fwiw, I agree with the CI req, though I'd like to talk about it at the summit
20:07:29 <devananda> asymmetric gating for a whole cycle is going to present a lot of pain for Ironic's development team
20:07:35 <ttx> devananda: arguably Ironic was made fully functional only recently, and could use a bit more time anyway
20:07:42 <markmc> ttx, devananda, we also talked last week about being more explicit that new projects should deprecate the old before graduating
20:07:44 <devananda> ttx: *nod*
20:07:51 <markmc> (where the new project is being split out from an existing project)
20:08:17 <ttx> OK, if everyone agrees, little point in spending more time on this, long agenda
20:08:22 <devananda> markmc: that means an integrated project must depend on an incubated one, though
20:08:34 <devananda> markmc: topic for another time :)
20:08:43 <ttx> #agreed ironic should continue in incubation during the Juno cycle
20:08:53 <markmc> #link http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-11-20.03.log.html#l-354
20:09:11 <ttx> kgriffs: around ?
20:09:24 <kgriffs> o/
20:09:31 <ttx> #topic Marconi graduation review
20:09:39 <ttx> kgriffs: Do you have an etherpad with your incubation/graduation requirements answers ?
20:09:48 <kgriffs> I have a wiki page: https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
20:09:50 <ttx> or a wiki
20:09:51 <markmc> devananda, no, ironic would be integrated in K, iff nova is willing to deprecate nova-bm in K
20:09:58 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
20:09:58 <lifeless> oh this is good timing for me managing to get a timeslice
20:10:02 <ttx> #link https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
20:10:02 <russellb> dhellmann: have you had a chance to review the pecan ML post?
20:10:08 <lifeless> at the tripleo sprint we were looking at marconi
20:10:12 <dhellmann> russellb: only briefly
20:10:14 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030326.html
20:10:27 <russellb> our requirements state you should use oslo libs where appropriate
20:10:37 <russellb> so we should clarify what we expect here ...
20:10:40 <lifeless> and were very confused - rather than an API around existing production queues, it seems to implement its own message queue backed by mysql...
20:11:07 <kgriffs> lifeless: that was clarified in the incubation meeting. I didn't realize there was still some confusion on that point.
20:11:12 <lifeless> which raises a large set of scaling and performance questions when comparing it to e.g. kestrel
20:11:59 <dhellmann> russellb: based on an initial skim, and my observations over the course of this cycle, I'm completely unsurprised by the conclusions
20:12:34 <zehicle> o/ (sorry I was late)
20:12:36 <ttx> russell_h: link to pecan analysis ?
20:12:41 <ttx> zehicle: o/
20:12:45 <russellb> ttx: #linked above
20:12:46 <ttx> damn
20:12:50 <russellb> ttx: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030326.html
20:12:57 <ttx> taht other russellTAB is going to kill me
20:13:03 <dhellmann> #link https://wiki.openstack.org/wiki/Marconi/pecan-evaluation
20:13:14 <russellb> dhellmann: thoughts on whether we should allow divergence like this?
20:13:30 <markmcclain> the write up seemed very slanted and the graphs are meaningless with code
20:13:31 <russellb> 708274
20:13:37 <markmcclain> s/with/without/
20:13:50 <dhellmann> russellb: no other team has objected so strenuously to using the same toolkit as the rest of us, so I do have concerns about why marconi is setting themselves up as different
20:13:57 <adrian_otto> a divergence should be considered if there is a good technical reason for it. Expectation for control plane APIs shoudl be different for those of data plane APIs.
20:13:59 <russellb> agree
20:13:59 <kgriffs> markmcclain: FWIW, I have tried very hard to stay out of the evaluation since I know I am biased. We can provide code very easily
20:14:15 <lifeless> kgriffs: I wasn't on the TC when that meeting happened
20:14:24 <lifeless> kgriffs: so sure, a previous committee was happy
20:14:25 <ryanpetrello> I believe the code in question is https://github.com/balajiiyer/marconi/commits/Pecan ?
20:14:38 <kgriffs> lifeless: ah, sure. I am happy to discuss your concerns.
20:14:41 <lifeless> kgriffs: however I'm  very worried
20:15:07 <ttx> dhellmann: I guess the question is more, is there anything Falcon does that can't be obtained by improving Pecan ? Like awesome performance
20:15:22 <russellb> and we discussed this during incubation right?  that it should at least be evaluated
20:15:28 <lifeless> kgriffs: in particular the concerns about divergent stack being raised right now
20:15:29 <russellb> though an evaluation was posted on graduation review day, heh
20:15:34 <russellb> hard to have time to really digest and respond to it
20:15:48 <lifeless> are a side effect of marconio being a queueing implementation rather than an API for queueing implementations
20:15:51 <dhellmann> ttx: some of the performance differences are explained by the fact that pecan relies on webob, which handles cases that falcon's request parser just doesn't handle
20:15:56 <sdague> yeh, the fact that it was posted today is kind of a red flag. That really should have been at least a month before.
20:16:03 <russellb> sdague: yes
20:16:04 <kgriffs> russellb: apologies, balaji has been working on it for a while, actually, but he has been swamped.
20:16:19 <russellb> so i'm basically -1 because we don't have time to have a proper discussion about this
20:16:29 <dhellmann> russellb: yeah, although I was more interested in community effects than arbitrary performance numbers
20:16:34 <ttx> Is the Pecan vs. Falcon question the only gap, or are there other areas that are borderline ?
20:16:50 <mordred> ttx: see lifeless question above
20:16:52 <sdague> regardless of the falcom / pecan issues, my concern is this is the extend of gate testing - http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/queuing/test_queues.py
20:16:57 <sdague> which isn't yet voting
20:17:02 <kgriffs> dhellmann: was the original Pecan eval you did documented somewhere?
20:17:12 <russellb> sdague: no voting functional testing?
20:17:12 <lifeless> because - as it stands, I would have voted -1 on marconi's incubation
20:17:22 <kgriffs> sdague: that's a good point. We definitely need more tests there.
20:17:27 <ttx> mordred: sheall we defer this to next week so that (1) lifless has time to raise his remarks on the ML and (2) we get time to discuss the Pecan vs. Falcon report ?
20:17:32 <mordred> sdague: that is more vexing to me than anything else
20:17:40 <sdague> russellb: not last time I checked
20:17:44 <dhellmann> kgriffs:  https://etherpad.openstack.org/p/havana-common-wsgi
20:17:44 <mordred> ttx: what sdague just raised is WAY more worrying
20:17:49 <sdague> it was in progress the last couple of weeks
20:18:02 <ttx> mordred: indeed
20:18:04 <kgriffs> dhellmann: thanks!
20:18:22 <jeblair> i think the consistency around pecan is very important; as we've grown, we're hearing demands for consistency and standardization in our dependencies and architectures more
20:18:34 <dhellmann> ttx: the evaluation of the technical question has raised some questions for me about an "us vs. them" attitude I observed early in the release cycle, which makes me concerned that we will have constant fights with this team over using common tools
20:18:37 <malini> sdague: the tests are an ongoing thing. I raised the coverage question in #openstack-qa & my understanding from the responses was this is adequeate. We have detailed coverage in the functional test suite & will add the same level of coverage in tempest as well
20:18:43 <sdague> we're having lots of projects without solid testing in the gate causing all kinds of issues in making an openstack whole
20:18:57 <sdague> malini: having it in a different test suite doesn't count
20:19:09 <dhellmann> jeblair: +1
20:19:09 <kgriffs> dhellmann: "common tools" is a blanket statement. Are there other tools specifically that you have seen friction with?
20:19:17 <sdague> malini: I'm sorry that you got the wrong impression there
20:19:23 <lifeless> malini: do you have stress tests (e.g. thousands of tenants, millions of queues?)
20:19:27 <ttx> sdague, dhellmann: so adding a week won't change your opinion on it ?
20:19:33 <jeblair> i think the pecan/falcon report is a good place to start a discussion about whether openstack should move to falcon, but i think it would have to be _really_ compelling to be an argument that marconi should diverge
20:19:35 <dhellmann> kgriffs: we do have some teams that have rejected python 3 patches, packaging changes, etc.
20:19:42 <dhellmann> ttx: no
20:19:43 <malini> lifeless: We have done stress tests using tsung
20:19:43 <markmc> jeblair, dhellmann, on the web framework consistency, we have to admit the project as a whole has been slow to standardize here
20:19:44 <ttx> jeblair: +1
20:19:45 <sdague> ttx: no
20:19:53 <markmc> jeblair, dhellmann, not completely excusing it, but ...
20:20:18 <dhellmann> markmc: the implementation was always meant to be slow, there is no point rebuilding without having a reason to bump the api version
20:20:43 <dhellmann> otoh, the investigation and learning has been picking up -- every integrated project has talked to us, iirc
20:20:57 <markmc> dhellmann, yep, definitely picked up since you started pushing it
20:21:12 <lifeless> kgriffs: what's your strategy for folk that want @scale marconi? Do they need to reimplement the API (which would be coutner to everything we're trying to achieve...) ? Is there an API vs implementation split in the code?
20:21:19 <markmc> dhellmann, picked up from near zero, is my point
20:21:22 <dhellmann> and so far, every single other team has just said "ok, we'll do that" without argument
20:21:34 <markmc> dhellmann, yeah, fair
20:21:42 <kgriffs> lifeless: we can chat about scale, but Marconi actually scales and performs quite well already.
20:21:44 <ttx> So how about... kgriffs posts a governance patch to switch Marconi to integrated. Lifeless starts a thread on the base concepts. We discuss Falcon vs. Pecan on the ML, and it all ties back into our votes on that proposed patch
20:22:14 <ttx> because it will require a vote, I think
20:22:16 <jeblair> ttx: seems fair
20:22:21 <mordred> ++
20:22:22 * dhellmann nods
20:22:31 <kgriffs> lifeless: like I said, I would be happy to discuss in detail
20:22:42 <ttx> and to vote we need the governance patch
20:22:46 <markmc> #link https://wiki.openstack.org/wiki/Marconi/Incubation
20:22:50 <ttx> then next week we can make the final call on it
20:22:51 <markmc> (for reference)
20:22:52 <lifeless> kgriffs: per ttx I will raise my concerns and hesitations on the mailing lit and we can deep dive there.
20:23:01 <kgriffs> kk
20:23:10 <lifeless> kgriffs: but for instance, how does it compare to kestrel
20:23:17 <ttx> kgriffs: ping me if you need help drafting the governance patch
20:23:23 <kgriffs> ttx: will do
20:23:35 <ttx> that's where final voting will happen
20:24:03 <ttx> and while it runs, we can have the complementary discussions about Falcon or the whole concept of doing queue on top of mysql
20:24:25 <ttx> #action kgriffs to post a governance patch to switch Marconi to integrated
20:24:40 <ttx> #action lifeless to start a thread on the base concepts
20:24:56 <ttx> #action TC to analyze and comment on Falcon vs. Pecan report
20:25:23 <ttx> #agreed final decision at meeting next week
20:25:35 <ttx> #topic Integrated projects and new requirements: Neutron
20:25:43 <ttx> #link https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron
20:25:48 <russellb> so, i was supposed to start a thread off of this, and i didn't.  sorry.
20:25:54 <ttx> I read the log from last week, and I think we need to clarify something
20:26:03 <ttx> The review of currently-integrated projects vs. new requirements is *not* about discussing de-integrating some projects
20:26:12 <ttx> It's about having a clear gap analysis and an agreed plan and deadlines to cover that gap
20:26:21 <russellb> agree
20:26:22 <ttx> Now, *if* that plan and deadlines are not met (or we can't agree on a plan), we'll discuss de-integration, but that's not an immediate topic
20:26:32 <markmc> #link http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-11-20.03.log.html#l-313
20:26:34 <ttx> So the question we are asking ourselves today is not "would we accept Neutron today"
20:26:34 <annegentle> ttx: good to set
20:26:45 <ttx> It's "what is the gap between the current state and our current expectations, and what is the plan to address it ASAP"
20:26:58 <ttx> So we the TC should produce a clear gap analysis, markmcclain as PTL should answer with a plan to address it, and we the TC should bless that plan and the deadlines in it
20:27:11 <markmcclain> so here's the gap analysis that I've been tracking
20:27:14 <markmcclain> #link https://etherpad.openstack.org/p/neutron-nova-parity
20:27:31 <ttx> I noted down 3 areas
20:27:37 <ttx> 1. nova-net feature parity (including easier setup of basic networking)
20:27:40 <ttx> 2. Migration plan from nova-net
20:27:46 <ttx> 3. Functional tests coverage
20:27:55 * ttx checks markmcclain etherpad
20:28:00 <sdague> markmcclain: good list
20:28:09 <russellb> performance/reliability parity is another ... largely just part of #1 and #3
20:28:21 <russellb> but is a specific concern area that must be addressed before folks are comfortable with the deprecation
20:28:29 <sdague> I think it should be explicit that #3 definitely depends on #1 and #2 completing
20:28:29 <russellb> but yeah, it's a good list
20:28:36 <ttx> russellb: yeah, nova-net feature/perf parity
20:28:42 <markmc> markmcclain, awesome list of tempest additions
20:29:01 <russellb> i agree that the list covers it from my perspective
20:29:10 <markmcclain> markmc: mlavelle really help spearhead that work
20:29:15 <ttx> markmcclain: is performance somewhere in your etherpad ?
20:29:31 <markmcclain> I'll clarify it #8
20:29:34 <mordred> I'm number 5!
20:30:24 <jeblair> mordred: you're a network!
20:31:07 <mordred> markmcclain: if you call that api verb mordred, I'll vote for nova-network deprecation right now (also, great list)
20:31:17 <markmcclain> mordred: haha
20:31:23 <lifeless> is 5 really a thing nova network has ?
20:31:25 <ttx> markmcclain: so that's the gap analysis. Do you have a plan to tackle it yet ? Something that would show per-dev-milestone progress ?
20:31:41 <lifeless> I'd like to see a poionter to the nova network docs that match it, so we can see waht needs to be done to meet it
20:31:47 <dhellmann> lifeless: good question
20:31:54 <ttx> I think what we missed in the past is a plan more precise than "we'll fix it by next release"
20:32:15 <lifeless> because really, its two API calls to geet neutron up and active with a new network - one for the network, one for the subnet, done.
20:32:17 <russellb> and is Juno release a reasonable deadline?
20:32:54 <dhellmann> markmcclain: is this list in order by priority or dependencies or something else?
20:32:56 <lifeless> and I've seen deployrs fight for weeks getting nova-network configured properly... :)
20:32:57 <markmcclain> lifeless also the router and rtr interface plugging
20:33:00 <ttx> lifeless: My original understanding of that requirement is to match the "simplicity" of Nova-net, but I agree it got a lot more specific now
20:33:09 <mordred> lifeless: for deployer or for tenant?
20:33:29 <markmcclain> ttx: yes so the last 4 items I want to have concrete blueprints for in Juno
20:33:36 <mordred> lifeless: because having gotten a tenant with no working network, I can tell you it was not 2 api calls to get a working network
20:33:39 <lifeless> mordred: deployers. nvoa-network doesn't have per-tenant self defined networks.
20:33:47 <markmcclain> #3 we can define good bugs to track
20:34:08 <mordred> lifeless: right - nova-network just had a network that worked because the option of a non-working one wasn't present
20:34:18 <ttx> markmcclain: Ideally you would discuss the whole plan with your core team. it needs to be a group commitment, not just you
20:34:24 <mordred> so I think there is an end-user experience parity thing here
20:34:27 <markmcclain> dhellmann: that is the general order of priority
20:34:31 <lifeless> mordred: and neutron can do that too. You may have a deployer that made poor choices, which is a docs issue.
20:34:38 <markmcclain> mordred: exactly
20:34:42 <ttx> markmcclain: So we can let you refine the deadlines and milestone targets and conclude this next week
20:34:45 <lifeless> mordred: e.g. 'clouds should provide a default all-tenants network'
20:35:05 <annegentle> lifeless: interesting, who is accountable for the docs issue on a core project? (she asks hypothetically)
20:35:13 <ttx> markmcclain: unless you already have theit commitment behind the plan you have in mind
20:35:16 <markmcclain> ttx: that works
20:35:23 <lifeless> annegentle: I dunno :)
20:35:30 <mordred> annegentle: you!!! ;)
20:35:40 <annegentle> or the core team
20:35:45 <ttx> #info neutron integration gap analysis posted at https://etherpad.openstack.org/p/neutron-nova-parity
20:35:49 <lifeless> annegentle: btw I don't mean that the docs team failed here, I mean that the issue may not be one of design or code
20:36:12 <annegentle> lifeless: yep, agreed, just pointing out it's difficult to fix issues without known owners
20:36:26 <ttx> #action markmcclain to come up with precise and per-milestone plan to address gap analysis, get core support behind it and present at next meeting
20:36:28 <lifeless> annegentle: agreed. I want the issue to be more precise first too
20:37:00 <lifeless> annegentle: right now I can't tell what problem mordred had, that he wants fixed, nor whether it is parity with nova-network, or polish on a new feature nova-network doesn't have
20:37:09 <mordred> lifeless: I'd naively argue that we might e talking about defaults and not docs
20:37:21 <ttx> markmcclain: you could even propose it as a resolution, so that we vote on it and have some official record of that commitment
20:37:37 <markmcclain> ttx: sure I'll post one
20:37:39 <lifeless> mordred: my suspicion is that a public cloud deployed a cloud with no default network, which IMO is really bad news.
20:37:45 <lifeless> mordred: and that you got bitten bu this.
20:37:47 <mordred> lifeless: this is correct
20:37:49 <lifeless> s/bu/by/
20:37:57 <mordred> lifeless: my experience as an opensatck user was poor
20:38:12 <ttx> OK, let's move on to next topic
20:38:16 <lifeless> mordred: I don't believe this is a nova-network parity issue, its a deployer that *didn't follow the guidelines*
20:38:23 <mordred> lifeless: so I expressed that I'd like a way to say "hey man, give me a default working network"
20:38:34 <ttx> lifeless: you can discuss mordred-network off-meeting :)
20:38:42 <lifeless> ttx: well, its part of the parity list
20:38:45 <lifeless> ttx: so its on topic
20:38:51 <ttx> lifeless: fair enough
20:38:56 <mordred> lifeless: guidelines are guidelines - they're not a thing that can be counted on
20:39:04 <lifeless> ttx: can you add an action item that that point needs to be precise, and cover the actual gap, not issues with new features
20:39:20 <mordred> and if we're wanting to say that we want experiences across openstack clouds to be consistent
20:39:23 <lifeless> ttx: its entirely possible - and easy - for deployres to deploy noeutron so that it behaves just like nova-network for users.
20:39:31 <markmc> lifeless, you could add a comment to that effect in the etherpad
20:39:34 <mordred> then there needes to be at least a consistent way for me to get into a working state
20:39:36 <mordred> imho
20:40:05 <lifeless> mordred: I accept your point, but don't see it as a gap. new feature, new proboems. Don't use the new feature (per tenant networks)...
20:40:09 <lifeless> markmc: ading.
20:40:10 <mordred> which is either a default beahvior a depoloyer would ned to actively go out of their way to break - or an api call I can exercise
20:40:12 <ttx> #action mordred to precise what is behind the mordred-network line in the gap analysis
20:40:29 <mordred> lifeless: as a user, I cannot choose to not use per-tenant networks
20:40:30 <ttx> yes, that can devolve into a ML thread to make progress before next week
20:40:36 <mordred> kk
20:40:46 <ttx> #topic Draft bylaws change from Defcore
20:40:55 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-March/000566.html
20:41:02 <ttx> There were two things I wanted to discuss from that thread...
20:41:07 <ttx> (1) The proposed bylaws change
20:41:14 <markmc> I'm not sure the draft change itself is worth discussing that much
20:41:19 <ttx> My understanding (confirmed with Mark's second email) is that their intent is to clarify how the TC can add new projects allowed to call themselves "OpenStack" something
20:41:34 <ttx> Yes, my reading is that this bylaws change just creates a process for us to clarify things, and doesn't reduce or impede on our authority
20:41:48 <markmc> the intent is to change the wording of "the TC proposes new projects to Core and the board approves"
20:41:49 <ttx> Arguably it even increases it, since in the current authority split the BoD fully owns the trademark side
20:41:49 <zehicle> I may be able to help clarify (but I was not in the meeting, so they may have altered course)
20:41:55 <markmc> to something which doesn't mention "Core"
20:42:09 <markmc> but not in any way affecting how we decide what goes in the integrated release
20:42:11 <russellb> ok, that makes sense
20:42:13 <ttx> zehicle: I think if anyone has concerns they can voice it on that -tc thread
20:42:21 <ttx> I think that point is pretty ok
20:42:27 <ttx> (2) The snark and the angst at our response
20:42:35 <markmc> yes
20:42:37 <ttx> Leaving the snarkiness aside, I think I understand their frustration. From their point of view:
20:42:43 * jgriffith ties his hands behind his back
20:42:47 <ttx> The BoD needs a technical information ("designated sections") to go forward with designing trademark rules
20:42:57 <ttx> The PTLs are definitely their main points of contact for that information
20:43:03 <ttx> The TC is looped in as a convenient mechanism to gather that technical information
20:43:15 <ttx> Then the TC answers that the whole idea doesn't seem to be the best way to achieve our common goals, and we should focus our efforts on something else
20:43:25 <ttx> So obviously they don't like our answer.
20:43:36 <ttx> Now, IMHO we can't prevent them from going forward with the process they defined, since that's fully under the BoD responsibility
20:43:36 <markmc> agree, but it also appears we went off the deep-end interpreting what was required for "designated sections"
20:43:47 <markmc> due to lack of clarification, but also us being geeks I guess
20:43:53 <ttx> I think our official answer (that we don't think it's the best way to achieve our goals) is good enough to make the point that we don't really like it
20:43:54 <markmc> #link https://etherpad.openstack.org/p/openstack-designated-sections
20:43:59 <mordred> markmc: ++
20:44:06 <ttx> At this point I'm fine with them going to each PTL to get the technical answer they need to go forward
20:44:08 <jgriffith> I'm still very unclear on what the goal is and nobody has answered that IMO
20:44:09 <dhellmann> my main concern, which wasn't reflected fully in the response, was what form that "designation" has to take -- because IANAL, and I don't know what is "sufficient" for this purpose
20:44:10 <markmc> that makes it very clear it's very, very high level info needed
20:44:11 <mikal> Frankly, I can't see what Josh hopes to achieve by grandstanding the way he did
20:44:16 <ttx> But maybe that's just me -- not caring enough about trademarks and happy to leave that completely to the BoD
20:44:36 <mordred> mikal: let's ignore the snark for a second - fun as it is
20:44:49 <zehicle> I'm working on a draft that may help - will vet it w/ mikal
20:44:52 <annegentle> mordred: that's not even fun snark or clever, it's mean
20:44:53 <markmc> dhellmann, this is the form they have in mind: https://etherpad.openstack.org/p/openstack-designated-sections
20:44:56 <ttx> mikal: we won't change josh
20:45:03 <mikal> mordred: you didn't sit through 2.5 hours of it
20:45:10 <markwash> jgriffith: I agree about being unclear, but I felt like once the "frustration" was being left aside there were actually some decent explanations given in the discussion in the defcore meeting
20:45:21 <dhellmann> markmc: the lack of detail leaves a lot of room for interpretation
20:45:33 <jgriffith> markwash: yes and no.. but I can seek clarity later
20:45:39 <ttx> zehicle: did I describe the frustration accurately ?
20:45:40 <mordred> I agree with markwash - I think the follow up explanations ahve made it clear what was being asked for
20:45:44 <sdague> dhellmann: I think that's intentional. Because this is going to be somewhat honor bound
20:45:46 <markwash> I think what defcore needs to understand is that you guys aren't trying to do their job for them, we just need to better understand their job in order to translate it into actual designations
20:46:02 <russellb> it's hard to give a technical answer to a question when you're not sure if you fundamentally agree with what's being asked ...
20:46:06 <markwash> because us being geeks, the specific intent seems to matter a lot
20:46:06 <dhellmann> if they don't care about line numbers in files, then it seems perfectly reasonable to say "you may provide an entry point with this API" or "you may respond to RPC calls with this API" and be detailed about it
20:46:10 <mordred> clearer
20:46:13 <jgriffith> russellb: +1
20:46:44 <markmc> dhellmann, the current requirement is open to even more interpretation
20:46:57 <mikal> I think part of the problem is that defcore hasn't really made an effort to explain to the TC what they want / need
20:47:00 <russellb> it's hard to even take this etherpad seriously with snark in it
20:47:00 <markmc> dhellmann, we're not really being asked (as a body) for our input on the trademark policy
20:47:00 <dhellmann> markmc: sure, but I thought we were trying to fix that
20:47:03 <mikal> So we guessed, and they didn't like our guess
20:47:17 <dhellmann> markmc: so we shouldn't have an opinion?
20:47:20 <zehicle> mikal, we did offer to have an interactive meeting to discuss this
20:47:25 <ttx> anyone thinks the TC (and not the PTLs) should be the point of contact to get that information ?
20:47:32 <markmc> dhellmann, for something like this, I think we as individuals should have opinions
20:47:47 <jeblair> ttx: i think consistency is warranted here...
20:47:55 <russellb> jeblair: +1
20:47:58 <markwash> As a PTL, i consider the TC to both represent and guide me
20:48:14 <mikal> jeblair: certainly long term consistency, a PTL election shouldn't change radically what a vendor can do
20:48:14 <ttx> jeblair: listening to Josh, he doesn't seem to be after consistency
20:48:16 <markmc> dhellmann, e.g. Josh individually has opinions on how we run the project, but we wouldn't be so keen on the BoD having such opinions
20:48:17 <jeblair> ttx: so while i agree that the ptls are an excellent resource for this info, i worry that if we abdicate, we'll get completely different responses
20:48:35 <dhellmann> markmc: as an engineer, I find it difficult to help guide "requirements gathering" when it seems like it is off course
20:48:42 <zehicle> just like you Josh is just one person in the DefCore meeting - we have discussions.  discussoin != result
20:48:42 <markmc> dhellmann, yeah
20:48:43 <annegentle> I think we're all a little cagey about the definitions -- originally I see this as a documentation/communication task, a list of each project and what each "cares" about (which may have to be PTL drafted?)
20:48:49 <annegentle> see/saw
20:48:50 <annegentle> heh
20:48:50 <dhellmann> to *not* guide
20:48:54 <mikal> jeblair: I don't think its abdication? I think Josh intends to just route around us.
20:49:14 <ttx> mikal: he may be disappointed. The PTLs and the TC are pretty close :)
20:49:27 <mikal> zehicle: it was an extremely negative first interaction where no one else in the room reigned it in though.
20:49:36 <mikal> But I should stop talking about the snark
20:49:47 <mordred> honestly, I think that discussions of what someone who is not here may or may not be thinking are inappropriate
20:49:54 <annegentle> mikal: it can certainly feel that way with Josh and as your first interaction you were rightfully shocked
20:50:02 <mikal> The reason I keep mentioning the snark is that I think what the TC needs to do is better understand what defcore wants / needs, and they chose to use the time to bitch instead
20:50:07 <jgriffith> let's move along shall we?
20:50:08 <jeblair> my primary concern is that we're develping open source software; that software has a name: openstack, and i think the trademark should reflect that.  i'm not sure why there should be any sections designated as replacable
20:50:08 <markwash> opinions aside, I just really think the lack of clarity about what defcores specific goals are blocks selecting designated sections
20:50:15 <ttx> ack, let's move along
20:50:16 <zehicle> mikal, thanks.
20:50:18 <dhellmann> jeblair: +1
20:50:20 <russellb> jeblair: +100
20:50:36 <dhellmann> jeblair: otoh, drivers
20:50:45 <jgriffith> jeblair: I'd kinda agree with that, I added my thoughts to the etherpad
20:51:09 <jgriffith> The only thing in Cinder that should be swappable are the drivers
20:51:15 <ttx> jeblair: I think the fact that we define what the "openstack project" is made of (see proposed bylaws change) ensures that what we develop is still called openstack
20:51:19 <sdague> to play devil's advocate: do all the clouds we think of as openstack implement the nova scheduler as is?
20:51:22 <jgriffith> The rest is not designed to be "interchangeable" so to speak
20:51:25 <russellb> but even with drivers, once something is out of tree, consistency is (potentially) completely shot
20:51:25 <dhellmann> markwash: right, I think that has been clarified sufficiently that we could give an answer now
20:51:41 <markwash> dhellmann: sorry, I must have missed the docs of that
20:51:50 <russellb> replaceable?  sure.  what we (openstack) built?  no.
20:51:50 <jgriffith> russellb: that's true but then it's a functionality issue IMO
20:51:52 <sdague> zehicle: you had some early test results right?
20:51:52 <dhellmann> markwash: oh, based on the etherpad linked above
20:51:57 <dhellmann> markwash: with examples
20:52:10 <russellb> jgriffith: which is of course why our response was to prioritize functionality to start with
20:52:13 <russellb> instead of rat holing on this
20:52:14 <ttx> jeblair: but I'm fine with PTLs answering that "all of it" is designated sections. I just don't want the TC to mandate that they do
20:52:15 <dhellmann> markwash: I would still prefer more detail, but this is a reasonable starting place
20:52:19 <sdague> that might be useful to understand the realities of how different different providers are
20:52:23 <zehicle> sdague, we have some initial scoring of capabliities.
20:52:33 <sdague> zehicle: is that sharable data?
20:52:48 <mikal> I think I have a problem with PTLs at the end of their elected cycle deciding this
20:52:58 <jgriffith> mikal: ha!
20:53:00 <mikal> I think the newly elected PTLs at the least should be consulted
20:53:03 <zehicle> #link https://docs.google.com/spreadsheet/ccc?key=0Av62KoL8f9kAdFo4V1ZLUFM0OHlrRnFpQUkxSHJ5QWc&usp=drive_web#gid=6
20:53:16 <russellb> mikal: i don't think any ptl ever should decide it alone
20:53:21 <jgriffith> mikal: you think those of us on the way out are suddenly going to sabotage something?
20:53:24 <russellb> and should always consult broader group on controversial issues
20:53:25 <dhellmann> mikal: I think that was why the TC was being asked
20:53:29 <dhellmann> what russellb said
20:53:30 <russellb> so i don't htink the cycle should really be a concern
20:53:38 <markwash> sabotage +1 :-D
20:53:39 <ttx> zehicle: what's the timing behind this ? Can it wait for newly-elected PTLs ? (April 10)
20:53:41 <zehicle> my recommendation is that you agree on some general principles that can be used to drive selecton
20:53:41 <mikal> What I worry about is long term trajectory
20:53:41 <jeblair> ttx: so maybe we should ask the ptls, and make our response from that
20:53:47 <annegentle> We already got away from an all-PTL TC
20:53:57 <sdague> zhhuabj: ok, but that's not showing it against some clouds? that's just test suite analysis
20:53:57 <jeblair> ttx: we can get the best information that way, and make sure it makes sense as a whole
20:53:59 <mikal> I don't want a PTL to decide on a plan "everything shall be designated!" and then a new PTL to change it
20:54:00 <jgriffith> jeblair: that seems reasonable
20:54:17 <jgriffith> I think we may be making this harder than it need be again
20:54:24 <zehicle> ttx, yes
20:54:28 <markwash> dhellmann: ah, I was familiar with that etherpad, it is illustrative but too broad of a stroke in some cases to be useful
20:54:28 <jgriffith> I'd say clarify the goal
20:54:30 <ttx> jeblair: we should definitely be engaging with PTLs rather than discuss it just here
20:54:40 <jgriffith> PTL's bring recommendations/thoughts to TC and we move forward
20:54:56 <zehicle> ttx, I was hoping that you'd discuss the pricples for selection ( I added a strawman to that wiki page)
20:55:05 <ttx> OK, to move forward i'll metion it in the PTLs / release / prject meetin gnext
20:55:19 <jlibosva> markmcclain: hi, sorry about the delay, can we discuss https://review.openstack.org/#/c/75924/ now?
20:55:28 <russellb> i think we're going to waste so much time debating this, sigh
20:55:30 <ttx> zehicle: damn, missed the addition
20:55:49 <zehicle> question: do you want a response from DefCore?
20:55:52 <lifeless> o my concern on PTLs
20:56:08 <lifeless> is that PTLs are arbitrators, not dictators
20:56:09 <zehicle> or should have have an interactive meeting first?  It looks like the TC is making progress
20:56:13 <ttx> russellb: yes, I'd rather just ignore the whole thing
20:56:23 <markmc> zehicle, a clarification, in prose, with examples and rationale of what DefCore is looking for would be great
20:56:27 <dhellmann> lifeless: as a PTL, I would ask my team, and be the point of contact for this question
20:56:29 <lifeless> which ties into mikals concern
20:56:38 <jgriffith> markmc: yes please!
20:56:43 <ttx> zehicle: we'll loop PTLs in that discussion
20:56:45 <jeblair> markmc: ++
20:56:45 <russellb> ttx: well i feel like our response and offer to collaborate on a particular area first was very reasonable, a response to that would be great
20:56:46 <zehicle> markmc, I'd like to do that in collaboration with some TC representatives.
20:56:46 <russellb> zehicle: ^
20:56:50 <ttx> and continue this next week...
20:56:54 <zehicle> That was the idea of an interactive meeting
20:57:04 <markmc> zehicle, is this not "interactive" ?
20:57:29 <zehicle> sorry, yes
20:57:36 <ttx> zehicle: so yes, an answer to our answer would be cool. At this point I heard "no thanks, please designate sections"
20:57:37 <zehicle> voice enabled with eitherpad
20:57:54 <ttx> zehicle: but maybe it could be more subtle
20:58:01 <dhellmann> I read better than I listen, so either way I would VERY MUCH appreciate having more detailed examples of what a description of designated sections might look like, if this etherpad is not entirely sufficient as a response.
20:58:16 <ttx> need to move on
20:58:19 <ttx> 2 min left
20:58:20 <russellb> how about an etherpad without ridiculous snark, too
20:58:24 <zehicle> the DefCore committee came up with 3 alternatives - I was out last week so did not get a chance to review w/ the DefCore/TC appointees
20:58:28 <russellb> completely not productive
20:58:48 <zehicle> russellb, I'm trying...
20:59:09 <dhellmann> zehicle: could you post a link to those alternatives? I must have missed them #emailoverload
20:59:26 <mikal> zehicle: I would be happy to take a look at a draft defcore response and provide feedback, although asking a few other TC people for feedback would be a good idea as well
20:59:28 <zehicle> I have not circulated yet - wanted to get byin from my cochair before blasting them
20:59:37 <dhellmann> zehicle: ok
20:59:42 <zehicle> mikal, adding you and annegentle to the doc
20:59:42 <ttx> zehicle: ok, post it when ready
20:59:46 <annegentle> zehicle: sounds good
20:59:54 * ttx moves on for last minute mentions
20:59:56 <ttx> #topic Other governance changes
21:00:02 <ttx> * Graduate Sahara (ex. Savanna) project (https://review.openstack.org/#/c/79766/)
21:00:07 <ttx> * Add Networking Program mission (https://review.openstack.org/#/c/79744/)
21:00:22 <ttx> Shara will be formally approved when it reaches the threashold
21:00:25 <ttx> damn
21:00:28 <ttx> typing too fast
21:00:32 <jeblair> renamed again!
21:00:39 <annegentle> jeblair: hee
21:00:40 <ttx> Networking program mission will be approved unless someone complains
21:01:03 <ttx> that's all for this week
21:01:04 <ttx> #endmeeting