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