20:02:18 #startmeeting tc 20:02:19 Meeting started Tue Jul 1 20:02: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:02:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:22 The meeting name has been set to 'tc' 20:02:32 So today is the Defcore-specific TC meeting that was requested last week 20:02:43 I had several discussions with TC members to try to clearly identify key concerns and questions 20:02:54 They fell into 3 main categories, which will form our agenda for today 20:03:02 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:17 #topic Scope of Defcore 20:03:22 ttx, do we want to give josh a minute? 20:03:27 he did say he was going to be here 20:03:46 * markmcclain is stuck in traffic 20:03:48 zehicle_at_dell: is someone else from defcore supposed to attend? 20:03:53 shall we wait? 20:04:14 http://lists.openstack.org/pipermail/defcore-committee/2014-June/000221.html 20:04:35 I did not get specific RSVPs 20:04:43 but thought we had some people say they would join 20:04:49 I am here if needed 20:05:05 I just don't want to lose too much of our precious single-topic meeting time 20:05:21 ttx, cool 20:05:26 we're ~10% into the meeting, maybe we should go ahead and circle back if josh joins late? 20:05:27 I guess we can wait a bit more 20:05:30 we're 5 minutes in *shrug* 20:05:38 let's go 20:05:40 :) 20:05:44 yup 20:05:51 so this topic is about... 20:05:56 what exactly are the trademark use cases being targeted ? 20:06:07 It might be clear from Defcore standpoint, but we found conflicting documentation on that topic 20:06:17 And the answer affects a lot how strongly the TC feels about some issues 20:06:30 Our guess was that the capabilities/designated sections approach would be used for the "OpenStack-powered" trademark license program 20:06:39 zehicle_at_dell: Is that a correct guess ? 20:06:53 yes 20:07:03 that was the expectation 20:07:06 So to be clear... 20:07:11 ttx, and similar licenses like $VENDOR OpenStack as explained by sparkyc 20:07:15 trademark would require using designated sections and passing required tests 20:07:17 We're talking about "FooTron powered by OpenStack" 20:07:24 Not "FooTron OpenStack" 20:07:25 Yes? 20:07:35 mikal, both 20:07:43 both 20:07:52 commerical trademark license agreements administered by the foundation 20:07:55 there is a community use for the trademark that is not commercial 20:08:00 zehicle_at_dell: "powered by openstack" trademark program would require using designated sections and passing required tests ? 20:08:02 yep 20:08:06 there are really three uses: commercial, community & code 20:08:11 So, I thought the "powered by" mark was a runner up prize 20:08:13 Am I confused? 20:08:13 ttx, yes 20:08:17 so this is for all 3 uses, not just the powered-by use? 20:08:25 mikal, no. that's the primary mark 20:08:34 i.e. powered by was for people who didn't comply with the full defcore requirements? 20:08:35 mikal, yeah, there's *potential* for an "OpenStack API Compatible" type trademark program in future; not agreed on yet 20:08:42 dhellmann, NO. it;s only for commerical 20:08:43 it seems backwards to be designating the sections that are OpenStack. Shouldn't everything be designated by default and then we identify the legitimate plugin points? 20:08:45 mikal, that would be the "runner up" 20:08:53 markmc: ahhh, ok 20:09:04 To my knowledge, Compatible is for drivers / plug-ins 20:09:05 zehicle_at_dell: is Defcore about defining more than the Powered by openStack trademark license program ? 20:09:09 zaneb: we're not to that part yet :) 20:09:17 zehicle_at_dell: ok 20:09:21 what do you mean "runner up" 20:09:24 that's not clear 20:09:34 zehicle_at_dell: someone who doesn't ship all the required bits 20:09:37 mikal: openstack powered = things built with openstack software; openstack compatible = things build on top of openstack or plugging into, emulating, etc 20:09:56 So, for example... 20:09:56 you could not call it openstack if you did not have the required bits AND pass the tests 20:10:02 If I rewrote nova in quickbasic 20:10:04 openstack powered includes things like appliances, converged hardware/software products, distrubitions 20:10:06 there is no "runner up" - it's a binary thing 20:10:12 is the intent for the outcome of DefCore to apply equally to all commercial trademark applications, or to create a test between different trademarks ("OpenStack" vs "Powered by OpenStack" vs "OpenStack Compatible", for example) 20:10:15 I could not get "FooTron OpenStack", or "FooTron powered by OpenStack" 20:10:22 of course, it's Apache2 so, you could use the code without using the trademark 20:10:22 mikal: nove in quickbasic would not be powered by openstack and you would not get either 20:10:26 But I might one day be able to get "FooTron OpenStack Compatible" 20:10:35 mikal: correct 20:10:44 jbryce: cool. Just wanting to be super clear on this point 20:10:44 DefCore is only dealing with one trademark currently 20:10:46 mikal, no 20:10:51 zehicle_at_dell, there is potential for "OpenStack API Compatible" mark for products that just meet the API requirements, but not the designated sections requirements 20:10:55 that's not the way Compatible is currently defined 20:11:08 zehicle_at_dell: when you say "you could not call it openstack" you mean you cannot use the "Powered by OpenStack" trademark license program, right ? 20:11:10 markmc, yes. that's a potential but not under discussion at this time 20:11:11 zehicle_at_dell, as I said, not agreed on - but important TC understands the potential is there; helps clarify "OpenStack Powered" 20:11:15 sorry to insist but that's a key question 20:11:33 ttx, yes. control of the trademark is the only real power that we have 20:11:41 focus is on the OpenStack powered in this phase afaik 20:12:13 zehicle_at_dell, we really need precision here - you mean "control of the requirements for the commercial trademark licenses" 20:12:15 for commercial contexts 20:12:34 openstack powered is for any product (cloud, appliance, distribution) that includes the community-developed software 20:12:40 zehicle_at_dell, that confusion is all this item on the agenda is hoping to clear up 20:12:41 and not defining "openstack" itself 20:12:49 markmc, it's about controlling who can use the trademark. that's the power the Foundation has 20:13:06 zehicle_at_dell, *for commercial uses* 20:13:06 zehicle_at_dell: the specific scope of the trademark is what we're trying to clarify 20:13:07 capabilities and designated sections are meant to set the bounds on what is required for those products to be able to sign an openstack powerd license agreement 20:13:07 really, the foundation manages ALL THREE of the uses cases 20:13:15 has to or we'd lose control of the mark 20:13:18 because it changes how we're thinking about what it says to respond to it 20:13:25 BUT DefCore is only concerned about the commerical use 20:13:28 so it's about the "OpenStack" trademark, not just the Powered by OpenStack" trademark license program 20:13:44 for DefCore, it's only about the commercial ones 20:13:49 Ah. 20:13:57 zehicle_at_dell: and that's 20:13:59 oops 20:14:01 exactly 20:14:10 and that's "powered by" not "compatible", right? 20:14:23 can someone please restate this very clearly - I am still not clear on scope 20:14:27 dhellmann, I believe it's both. those are both commericial 20:14:35 but we're mainly focused on Powered By right now 20:14:38 compatible to be considered in future phase 20:14:47 there was some activity around the Compatiblie mark too 20:14:55 mordred: I think what zehicle_at_dell means by "commercial uses of the trademark" is what we mean by "commercial trademark license programs" 20:14:57 but that is not moving as fast 20:14:58 if we get powered right we have a great starting point 20:15:00 the current scope doesn’t include it 20:15:00 ok, well, if my answer today is going to be used for both then I would like to understand the intent of both clearly 20:15:03 and by we I mean the bylaws 20:15:15 dhellmann: powered by = built with community-developed openstack software (therefore capabilities and designated sections are relevant); compatible = built around the software, more api based. may tie into capabilities for instance, but still has to be fleshed out 20:15:23 vishy, yes. we intentioanlly keep DefCore narrow 20:15:37 dhellman_: the designated sectrions and capabilities only apply to the powered by mark 20:16:02 yes 20:16:02 vishy, yes. 20:16:03 jbryce: so would compatible be part of what we're asking to designate, with substitutions, or would it be a layer above (apps) or below (drivers)? 20:16:08 vishy: ok, thanks 20:16:13 Let me try to summarize: 20:16:17 I gather the "Compatible" mark is not being discussed now, but I'm still not clear if we're talking about the commercial use of the "OpenStack" trademark or the "Powered by OpenStack" trademark or both. 20:16:17 "DefCore is only about the commercial uses of the trademark -- currently, only the "Powered by OpenStack" trademark license program" 20:16:20 summary - "the capabilities and designated sections defined through the DefCore process is only immediately intended to be used in the context of the 'OpenStack Powered' commercial trademark license agreement' 20:16:38 zehicle_at_dell: does that work for you ? 20:16:41 dhellmann: compatible would most likely have no designated code requirements. it could include management software for instance, that only integrates with the api but never implements any openstack 20:16:41 +1 20:16:55 #agreed the capabilities and designated sections defined through the DefCore process is only immediately intended to be used in the context of the 'OpenStack Powered' commercial trademark license agreement 20:17:03 #agreed DefCore is only about the commercial uses of the trademark -- currently, only the "Powered by OpenStack" trademark license program 20:17:05 ttx: thanks 20:17:15 OK, let's move on 20:17:18 Lots to cover 20:17:20 yup 20:17:21 #topic Defcore Capabilities 20:17:24 jbryce: ok, I'm trying to understand if compatible would allow for something that looks like an openstack service but isn't our code 20:17:34 Our answer on scoring the "Aligns with Technical Direction" columns is almost finalized 20:17:40 We have two governance reviews up (initial scoring, clarification of 0.5 scores) to address that: 20:17:45 #link https://review.openstack.org/100721 20:17:47 #link https://review.openstack.org/100722 20:17:58 There is a bit of confusion about capabilities though, mostly because they seem to be only defined in a json file that maps to test names 20:18:13 If those are to form the basis of a trademark license program, our suggestion would be to document 1-2 sentences about the intent of each capability, with the tests used as a backup definition 20:18:13 dhellmann, my understanding on that - potentially yes, but not agreed on by the board yet 20:18:25 ttx, we'd love for that to happen 20:18:36 I think it would be a very power thing for the community 20:18:37 markmc: ok, that feels very different from how it is being presented here in this meeting, though, almost like another type of license 20:18:40 zehicle_at_dell: cool 20:18:41 dhellmann: that is not currently allowed by the existing license, but it has definitely been talked about as a potential additional use for that license 20:18:53 troytoman make a great start with the capabilities list BUT it still has a long way to go 20:18:57 The second question on capabilities would be to clarify the relationship between capabilities and designated sections 20:18:58 we did not expect DefCore to own that 20:19:09 zehicle_at_dell: My understanding was that the "OpenStack-powered" trademark license program would apply to those which run designated sections *and* appeared to implement capabilities 20:19:15 ttx: that was the intention but the work needs to be done. i have been planning to work on that but was waiting for some of the processes to settle to make editing the json feasible 20:19:47 troytoman: I don't think that prevents us from answering, just makes it a bit more time-consuming 20:19:57 ttx, yes. Appeared = passed tests for those cabilities 20:20:06 zehicle_at_dell: But there is wording in some defcore etherpads that seem to suggest that designated sections could be nullified by excluding capabilities 20:20:06 ttx: understood. 20:20:22 troytoman and ttx, and that's what's in the JSON file 20:20:41 we have to have a single source of truth for capabilities (which tests and the description) 20:20:56 ttx, exteending?? 20:20:57 dhellmann: the openstack compatible license does not allow for the same naming rights as the openstack powered license. for instance, you can never called something “FooTron OpenStack” under the compatible license. you can only say things like “FooTron Widget compatible with OpenStack” 20:21:10 jbryce: ok 20:21:22 that's a surprise. I do not remember any disucssion where we talked about capabilities beyond those covered by the reference implementation 20:21:26 IMHO that would be a failure 20:21:36 zehicle_at_dell: https://etherpad.openstack.org/p/DefCoreLighthouse.F2F (lines 96-102) 20:21:47 (and I can point to past cases where a licensed implementation did that and it was bad) 20:21:50 maybe we misread that 20:22:19 Swift creates interesting discussion 20:22:29 but it's a bit of a single item compared the the broader questions 20:22:39 zehicle_at_dell: ok, you confirm that it should be an AND 20:22:39 happy to spend time on it, but it's not necessarily the common case 20:22:46 capabilities AND designated sections 20:22:50 ttx, YES 20:22:58 jbryce: the "Powered by OpenStack" program also supports calling something "FooTron OpenStack"? 20:23:05 so they do not intersect 20:23:25 ttx, that was the specific work hammered out in the spider cycle where we did the 10 principles 20:23:35 #agreed Powered by OpenStack should pass capabilities tests AND implement designated sections 20:23:55 OK, I think that clarifies well 20:23:57 there is required (designated) code and required tests. vendors may have alternate implementation of non-designated areas 20:24:01 can i take one second to clarify something 20:24:08 jbryce: sure 20:24:48 I think it's worth spelling out the swift example 20:24:58 but that contradicts the AND thing we've just agreed here 20:25:10 code can be required to be shipped even if the APIs it implements aren't required? 20:25:23 if there is no designated code then part of the AND is a noop 20:25:50 marmc_, good question 20:25:51 if there is designated code and no corresponding capabilities, is the question 20:25:56 the license agreement in question is called OpenStack Powered and is intended for use with products and services that are built using OpenStack software. for instance a public cloud “FooTron Compute Powered By OpenStack”, an appliance “FooTron Appliance Powered by OpenStack, a distribution “FooTron OpenStack” 20:26:14 the etherpad says something like "if the TC designates swift, we'll remove the swift capabilities" 20:26:19 if the required code is part of sections without required capabilities then we _assumed_ that that project would not be required 20:26:23 20:26:27 jbryce: thank you, that is very clear :) 20:26:29 so, we should clarify that 20:26:32 jbryce: thank you 20:26:34 jbryce: thanks 20:26:38 all of those difference products would be held to the same standard. in other words, they would all be required to expose the same capabilities (testable over the APIs) and include the same actual community-developed software bits (designated sections) 20:26:38 jbryce: that clarifies the scope of this 20:27:01 jbryce: thanks. that answers my question from earlier 20:27:03 #info the license agreement in question is called OpenStack Powered and is intended for use with products and services that are built using OpenStack software. for instance a public cloud �FooTron Compute Powered By OpenStack�, an appliance �FooTron Appliance Powered by OpenStack, a distribution �FooTron OpenStack� 20:27:03 we've been thinking of FooTron Openstack and FooTron powered by OpenStack as different things 20:27:04 jbryce: thanks, that is helpful 20:27:06 jbryce, very nice summary 20:27:11 #info all of those difference products would be held to the same standard. in other words, they would all be required to expose the same capabilities (testable over the APIs) and include the same actual community-developed software bits (designated sections) 20:27:19 (sorry, capturing for the meetgin minutes) 20:27:26 * mordred hands ttx a beer 20:27:43 jbryce: thanks for clarifying 20:27:49 if the required code is part of sections without required capabilities then we _assumed_ that that project would not be required 20:27:54 think that's where we were at 20:28:16 the only other product-type license agreement that currently exists, is OpenStack Compatible which is intended for products and services which are built on top of or plug into the community-developed software. For instance, a back-end storage system, or a cloud automation management layer that consumes the OpenStack APIs 20:28:25 markmc_: I think that makes sense but I don't know that we've been explicit 20:28:27 #info if the required code is part of sections without required capabilities then Defcore _assumed_ that that project would not be required 20:28:37 for example, if Saraha has designated code but no capabilities then it would still not be required for the mark 20:28:55 OK, I think that answers our question 20:28:59 yes 20:29:05 yeah, contradicting the AND thing earlier 20:29:19 but if you include something that implements the Swift APIs, the swift code is not required, right? (if no swift capabilities included) 20:29:25 markmc_, I don't see why. you need both 20:29:33 * ttx looks into boolean theory to find the right operator 20:29:41 xor? 20:29:46 AND AND IFF 20:29:47 zehicle_at_dell, you don't need swift designated code if there are no swift capabilities - that's the AND we meant 20:29:50 or something bizarre 20:30:23 markmc_, yes. no required caps means the code is not required 20:30:29 anyway, cool - clarified now ... 20:30:33 so, perhaps there's an ordering item that's important 20:30:35 #info no required caps means the code is not required 20:30:42 first, you need to have required capabilities 20:30:50 passes test == (!capabilities_included OR (capabilities_pass && designated_sections_included)) 20:30:59 zehicle_at_dell: so if the capability is not required, but you deploy it anyway, but you don't use the designated section... ? 20:31:08 then you must include the designated code under those capabilities 20:31:19 zaneb, we call that earning karma 20:31:31 and if there is no capability then it doesn't matter if the code is there or not? 20:31:45 dhellman_, +1 20:31:51 OK, I propose we move on 20:32:00 we did a graphic of this at the ATL summit 20:32:04 It clarified what we needed clarified 20:32:11 fair enough 20:32:18 #topic Defcore Designated sections 20:32:18 yeah, I think I get it now -- this is what I thought the position as in the beginning 20:32:19 Will is pointing out to me that we're looking for a MINIMUM (least common deminotor) 20:32:30 So, our view on this (as the TC) is the following: 20:32:40 The TC defines the contents of the integrated release, and that's the set of things we vouch for 20:32:44 I'll go ahead and be the first person to say "INTEROP" 20:32:55 Defining a subset of the integrated release would make the TC, the representation of the contributors to the project, appear to endorse or encourage replacing part of their work with proprietary alternatives 20:33:05 (although we value that the Apache license gives you that freedom) 20:33:14 (and we respect that it's the board prerogatives to determine trademark license programs) 20:33:26 Basically, the TC doesn't want to be the deciders of where proprietary replacements are allowed in "OpenStack Powered" products 20:33:30 ttx, my understandoing is that the project is _designed_ to have replacable parts 20:33:51 zehicle_at_dell: i wouldn't say it's designed to use proprietary replacements, no 20:33:57 ttx, that does not make sense to me. it's part of the design of the project 20:33:59 it's designed to be modular 20:34:04 Anyway 20:34:10 we'd like to recognize that it's the board's right to define a subset of the integrated release to use for the purpose of commercial trademark license agreements 20:34:15 modular, but only for open alternatives? 20:34:20 (such as the "OpenStack Powered" trademark program) 20:34:21 zehicle: OpenStack is not an open core project imo 20:34:29 and therefore the board should have final say on "designated sections" 20:34:36 zehicle: modular because that's the implementation that makes sense. the projects have multiple choices within the project itself 20:34:40 It is very consistent with what the bylaws currently say, fwiw. TC builds the set, and Board picks a subset to apply trademark rules on. 20:34:43 zehicle_at_dell, the technical architecture allows for replacements, we make no guarantees about the API for those replacements 20:34:58 markmc_, agreed. that's why we want tests 20:34:59 zehicle_at_dell, we value that our copyright license allows proprietary replacements 20:35:09 basically the upshot is the tc shouldn’t be making this decision because it isn’t a technical decision 20:35:16 zehicle_at_dell, but think it's the board's call on what the trademark license allows 20:35:34 if you ask the board to make a technical decision about which code to include, they will likely have to say none (since we are not in a position to make that decision) 20:35:42 we are asking for help from the TC about this 20:35:46 it puts us in a weird position to have already decided what's in an out, the integrated release, and then come back and be asked for a different set of software that's in 20:35:58 for us, we've already made a very clear call on what's in 20:36:10 whether "OpenStack Powered" products are required to ship swift or not is certainly *not* a technical question 20:36:12 right, we have a process for stuff making it into the integrated release over time 20:36:17 not one iota of that is technical 20:36:24 markmc_: +1 20:36:29 from our point of view, swift is part of opensatck 20:36:42 we respect that it's the board right to say otherwise 20:36:52 mordred, based on evidence from a commerical perspective, it's not 20:36:53 for use oin trademark programs 20:37:05 totally, the board controls the requirements of the commercial trademark licenses 20:37:12 zehicle_at_dell: that's why it is the board's perrogative to contradict us 20:37:14 there are people using openstack without including swift 20:37:19 and other integrated parts too 20:37:21 zehicle_at_dell: that is their right to do 20:37:27 but we, as the people who make openstack 20:37:30 have included swift in it 20:37:35 zehicle_at_dell: there are people using *parts of* openstack that way 20:37:39 which means swift is a part of openstack 20:37:40 zehicle_at_dell: correct but it isn’t a technical decision to say whether that is allowed 20:37:45 so, should they be allowed to use the name OpenStack if they don't include swift? 20:37:53 zehicle_at_dell: if the board says so 20:37:57 even if they use every other line of the prodyct 20:37:59 zehicle_at_dell: that's the board's call 20:38:03 that's teh board's call. but from our side, swift is a part of openstack 20:38:17 zehicle_at_dell, it's completely the board's decision whether some products should be allowed to be called "OpenStack Powered" 20:38:24 We have two ways to get there, I think 20:38:24 and if the board makes a different decision from us based on things, then that's within its legal rights 20:38:26 if you want to push the technical decision about designatated sections to the board, I'm happy to run that up the flag pole 20:38:38 zehicle_at_dell: We have two ways to get there, I think 20:38:39 we do not want to push the technical decision to the board 20:38:40 but I don't advise it 20:38:46 we already made the technical decision 20:38:48 zehicle_at_dell: as markmc_ said, swift isn't a technical decision 20:38:50 (1) would be to designate all the havana integrated release as a havana designated section, *and* recognize that it's the Board's right to designate a final subset of that set for trademark license program usage 20:38:50 Does the TC have a preference? (i.e. it should be the same as the integrated release?) 20:38:54 zehicle_at_dell: the assertion is there is no technical part to this 20:39:05 right, it's not a technical decision and it's patently clear that it's the board decision anyway 20:39:08 (2) would be to adopt markmc's suggested process on the Defcore list: let the Board come up with a strawman designated sections list, RFC that with TC and PTLs and the wider community, then let the board build the final synthesis 20:39:18 zehicle_at_dell: we've already declared to the world the software we think is in openstack 20:39:29 I think both approaches would address the concern that the TC should not decide where proprietary replacements are allowed in "OpenStack Powered" products 20:39:35 if the board wants to grant someone the ability to use the trademark when they use a different set of software 20:39:36 troytoman1, we would prefer the board to come up with a strawman based on their full understand of the commercial considerations 20:39:37 tehy can 20:39:39 based on community feedback in the process, we felt that it was important to have upstream code included 20:39:44 as a requirement 20:39:44 troytoman1, we're happy to provide input on that 20:39:49 zehicle_at_dell: it seems like the default here (that sections have to be designated explicitly to be required) is backwards 20:39:52 zehicle_at_dell: I think upstream code is exsential 20:40:03 IMHO, the design of the code allows for us to have designated sections 20:40:04 zaneb: +1 20:40:05 troytoman1, but the board - with its understanding of the commercial ecosystem - is best placed to come up with that strawman 20:40:09 it’s not just about proprietary replacements 20:40:10 zaneb: +! 20:40:21 zehicle_at_dell: I don't think there would be as much objection to designating optional sections 20:40:24 zehicle_at_dell: you are not differentiating between whole projects and plugin APIs 20:40:25 jbryce, +1. there are lots of ways to replace the code 20:40:25 zehicle_at_dell: this is an important point 20:40:26 in my experience in the real world, there are open alternatives being switched into places 20:40:31 markmc_: that's fine. i'm just trying to understand if the TC has any guidance or preference - I'll take it that it doesn't 20:40:35 probably most frequently 20:40:39 troytoman1: I do not agree 20:40:46 zehicle_at_dell: we are saying that the plug in interfaces inside our code were intended for alternate implementations also present in our code 20:40:49 e.g. I would designate the heat-cfn-api and all the AWS compatibility resources as optional quite happily 20:40:50 troytoman1: I think we're saying quite the opposite of that 20:40:57 dhellman_, I am asking for the TC help help make that distinction. I'm intentionally trying to stay away from that 20:41:06 mordred: quite the opposite of what? 20:41:08 troytoman1: I believe _I_ a t least am saying that I have already made the call on which bits are in and out 20:41:15 troytoman1: that we don't want to give guidance 20:41:23 mikal, like KVM? it's that inside our code? 20:41:23 zehicle_at_dell: you certainly can tell the difference between swift and a hypervisor driver in nova, though, so we should not conflate those 2 cases 20:41:23 mordred: +1 20:41:24 troytoman1: I want to give guidance - I voted on the integrated release 20:41:32 I believe that's opensatck 20:41:41 zehicle_at_dell: like the kvm and xen drivers, yes 20:41:41 if someone else, who is not me, wants to call someone else openstack 20:41:41 mordred: agreed 20:41:43 mordred: I read that as "I think it should be the integrated release but you can decided differently" 20:41:46 they're going to have to do that without my agreement 20:41:49 zehicle_at_dell: the nova driver to talk to kvm is in our code 20:41:49 troytoman1: you can 20:41:56 mikal, those are not inside OpenStack or part of the integrated release 20:42:01 troytoman1: you are legally allowed to disagree with the TC 20:42:07 zehicle_at_dell: the trick is, that distinction is more about policy than it is about a technical question 20:42:07 zehicle_at_dell: the drivers are 20:42:08 mordred: I am trying to figure out if that is a TC view or a mordred view 20:42:20 TC view 20:42:21 everyone in the TC who agrees with me ++ 20:42:24 ++ 20:42:25 ++ 20:42:27 mordred: ++ 20:42:30 ++ 20:42:31 ++ 20:42:32 ++ 20:42:32 troytoman: it's pretty heavily believed by the TC 20:42:36 ++ 20:42:38 mordred: I'm fine with either but I would like to know what the thoughts are as we deliberate or come up with a strawman 20:42:41 zehicle_at_dell: what we're saying is, that code is modular is a result of good coding practices, not the result of an intent to enable proprietary plugins or alternate implementations. 20:42:55 -- 20:42:56 thanks for that input everyone - it is very helpful to me, at least 20:43:00 that is not my view 20:43:16 but that is the tc consensus 20:43:20 vishy: that's because you're unique 20:43:24 and the correct position for the tc imo 20:43:24 * mordred loves vishy 20:43:43 -- (I can see good reason for the board to allow OpenStack Powered products not ship all of OpenStack) 20:43:45 zehicle_at_dell: which of the two approaches I ourtlined earlier would have your preference ? 20:43:56 but I think the TC is not the ones best placed to make that call 20:44:04 I think it's a terrible idea to ask the TC to make that call 20:44:06 markmc_: ++ 20:44:09 i think we can work on a straw man - but it is helpful to know what the current opinion is 20:44:10 We can provide technical feedback on a strawman, for sure 20:44:15 as anybody in our community can 20:44:19 markmc_: I can see good reasons for the board to do that, too 20:44:32 troytoman1: so... approach (2) ? 20:44:39 highly suggest that the strawman differentiates between replacing components and projects 20:44:42 "adopt markmc's suggested process on the Defcore list: let the Board come up with a strawman designated sections list, RFC that with TC and PTLs and the wider community, then let the board build the final synthesis" ? 20:44:54 ttx, we already did that 20:44:59 and addresses the swift case head-on 20:45:08 so…can i ask a crazy question? 20:45:16 vishy: that’s where my question was going = ) 20:45:16 jbryce: please :) 20:45:19 our strawman has swift = 0% 20:45:25 troytoman1: defcore needs to differentiate between vertical division between projects like swift and nova and horizontal divisions of those projects into layers with drivers that can be added outside the tree 20:45:26 zehicle_at_dell: so be it 20:45:27 markmc_: but the point is that that is not a technical decision 20:45:27 vishy: ++ 20:45:38 zehicle_at_dell: some people will cmplain at that in RFC phase 20:45:46 #link https://etherpad.openstack.org/p/openstack-designated-sections 20:45:48 dhellman_: Defintely 20:45:50 dhellman_: ++ 20:46:00