Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Jonathan Bryce]

On Feb 6, 2014, at 8:08 AM, Dolph Mathews  wrote:

> I'm curious about the level of granularity that's envisioned in each 
> definition. "Designated sections" could be as broad as keystone.* or as 
> narrow as keystone.token.controllers.Auth.validate_token_head(). It could be 
> defined in terms of executables, package paths, or line numbers.
> 
> The definition is likely to change over time (i.e. per stable release). For 
> example, where support for password-based authentication might have been 
> mandated for an essex deployment, a havana deployment has the ability to 
> remove the password auth plugin and replace it with something else.
> 
> The definition may also be conditional, and require "either A or B." In 
> havana for example, where keystone shipped two "stable" APIs side by side, I 
> wouldn't expect all deployments to enable both (or even bother to update 
> their paste pipeline from a previous release).


Here’s an example of the real world application in the current implementation 
of the commercial usage agreements (Russell alluded to this earlier):

http://www.openstack.org/brand/powered-by-openstack/
--
PRODUCT REQUIREMENTS. You must meet the following requirements in order to 
qualify for an "OpenStack Powered" trademark license:

1) A primary purpose of your product must be to run a functioning operational 
instance of the OpenStack software.

2) To ensure compatibility, your product must:

i. include the entirety of the OpenStack Compute (Nova) code from either of the 
latest two releases and associated milestones, but no older, and

ii. expose the associated OpenStack APIs published on http://www.openstack.org 
without modification.

3) As of January 1st, 2012, your product must pass any Faithful Implementation 
Test Suite (FITS) defined by the Technical Committee that will be made 
available on http://www.openstack.org/FITS , to verify that you are 
implementing a sufficiently current and complete version of the software (and 
exposing associated APIs) to ensure compatibility and interoperability. Your 
product will be required to pass the current FITS test on an annual basis, 
which will generally require you to be running either of the latest two 
software releases.
--

The request from the DefCore committee around designated sections would replace 
Section 2(i) in the above example. The external API testing that is being 
developed would fulfill Section 3. You’ll notice that Section 2(i) is not 
granular at all, but does include a version requirement. I think Thierry’s 
proposal around breaking it into two separate steps makes a lot of sense. 
Ultimately, it all has to find its way into a form that can be included into 
the legal agreements these organizations sign.

Jonathan






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Doug Hellmann]

On Thu, Feb 6, 2014 at 9:21 AM, Thierry Carrez wrote:

> Dolph Mathews wrote:
> > I'm curious about the level of granularity that's envisioned in each
> > definition. "Designated sections" could be as broad as keystone.* or as
> > narrow as keystone.token.controllers.Auth.validate_token_head(). It
> > could be defined in terms of executables, package paths, or line numbers.
> >
> > The definition is likely to change over time (i.e. per stable release).
> > For example, where support for password-based authentication might have
> > been mandated for an essex deployment, a havana deployment has the
> > ability to remove the password auth plugin and replace it with something
> > else.
> >
> > The definition may also be conditional, and require "either A or B." In
> > havana for example, where keystone shipped two "stable" APIs side by
> > side, I wouldn't expect all deployments to enable both (or even bother
> > to update their paste pipeline from a previous release).
>
> That's why I think it's not practical to define which code needs to be
> run (because you never "run" all the code paths or all the drivers at
> the same time), and we should define where *external code* can be
> plugged instead.
>
> Then, in your example, if A and B are both in the code we ship, there is
> no need to talk about them, unless you also allow an external C driver
> to be run instead.
>

+1

Doug



>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Doug Hellmann]

On Thu, Feb 6, 2014 at 8:42 AM, Thierry Carrez wrote:

> Russell Bryant wrote:
> > Perhaps going through this process for a single project first would be
> > helpful.  I agree that some clarification is needed on the details of
> > the expected result.
>
> At this point, I think we can break their request into two separate
> questions.
>
> The first one is high level, simple and technical: "which parts of each
> project have a pluggable interface ?" We should be able to list those in
> an objective fashion, and feed objective input into the second question.
>
> The second question is more subjective: "where, in that list, is it
> acceptable to run an out of tree implementation ?" Where would you say
> you can substitute code in Nova and still consider running the resulting
> beast is running nova ? The scheduler for example was explicitly
> designed so that you can plug your own algorithm -- so I think an out of
> tree scheduler class is fine... so I would exclude the scheduler classes
> (ChanceScheduler and others) from the "designated sections".


> Since that second question is more subjective, I think the answer should
> be a recommendation that the TC would collect and pass to the board.
>
> As a first step, I think we should answer the technical first question.
> There is no imposed format for the answer, so any freeform list will do.


+1 -- having good developer docs for all of our publicly pluggable APIs
will be a good thing anyway.

Doug



>


> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Thierry Carrez]

Dolph Mathews wrote:
> I'm curious about the level of granularity that's envisioned in each
> definition. "Designated sections" could be as broad as keystone.* or as
> narrow as keystone.token.controllers.Auth.validate_token_head(). It
> could be defined in terms of executables, package paths, or line numbers.
> 
> The definition is likely to change over time (i.e. per stable release).
> For example, where support for password-based authentication might have
> been mandated for an essex deployment, a havana deployment has the
> ability to remove the password auth plugin and replace it with something
> else.
> 
> The definition may also be conditional, and require "either A or B." In
> havana for example, where keystone shipped two "stable" APIs side by
> side, I wouldn't expect all deployments to enable both (or even bother
> to update their paste pipeline from a previous release).

That's why I think it's not practical to define which code needs to be
run (because you never "run" all the code paths or all the drivers at
the same time), and we should define where *external code* can be
plugged instead.

Then, in your example, if A and B are both in the code we ship, there is
no need to talk about them, unless you also allow an external C driver
to be run instead.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Dolph Mathews]

On Wed, Feb 5, 2014 at 10:22 AM, Thierry Carrez wrote:

> (This email is mostly directed to PTLs for programs that include one
> integrated project)
>
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
>
> Comments, thoughts ?
>

I'm curious about the level of granularity that's envisioned in each
definition. "Designated sections" could be as broad as keystone.* or as
narrow as keystone.token.controllers.Auth.validate_token_head(). It could
be defined in terms of executables, package paths, or line numbers.

The definition is likely to change over time (i.e. per stable release). For
example, where support for password-based authentication might have been
mandated for an essex deployment, a havana deployment has the ability to
remove the password auth plugin and replace it with something else.

The definition may also be conditional, and require "either A or B." In
havana for example, where keystone shipped two "stable" APIs side by side,
I wouldn't expect all deployments to enable both (or even bother to update
their paste pipeline from a previous release).


>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Thierry Carrez]

Mark Washenberger wrote:
> I don't have any issue defining what I think of as typical extension /
> variation seams in the Glance code base. However, I'm still struggling
> to understand what all this means for our projects and our ecosystem.
> Basically, why do I care? What are the implications of a 0% vs 100%
> designation? Are we hoping to improve interoperability, or encourage
> more upstream collaboration, or what?
> 
> How many deployments do we expect to get the trademark after this core
> definition process is completed?

Yes... what is the end goal ? I agree that's important (and influences a
bit our response here). But that's a separate discussion, one I've
started on the foundation ML:

http://lists.openstack.org/pipermail/foundation/2014-February/001620.html

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Thierry Carrez]

Russell Bryant wrote:
> Perhaps going through this process for a single project first would be
> helpful.  I agree that some clarification is needed on the details of
> the expected result.

At this point, I think we can break their request into two separate
questions.

The first one is high level, simple and technical: "which parts of each
project have a pluggable interface ?" We should be able to list those in
an objective fashion, and feed objective input into the second question.

The second question is more subjective: "where, in that list, is it
acceptable to run an out of tree implementation ?" Where would you say
you can substitute code in Nova and still consider running the resulting
beast is running nova ? The scheduler for example was explicitly
designed so that you can plug your own algorithm -- so I think an out of
tree scheduler class is fine... so I would exclude the scheduler classes
(ChanceScheduler and others) from the "designated sections".

Since that second question is more subjective, I think the answer should
be a recommendation that the TC would collect and pass to the board.

As a first step, I think we should answer the technical first question.
There is no imposed format for the answer, so any freeform list will do.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[John Griffith]

On Wed, Feb 5, 2014 at 5:54 PM, Rochelle.RochelleGrober
 wrote:
> On Wed, Feb 5, 2014 at 12:05 PM, Russell Bryant  wrote:
>
> On 02/05/2014 11:22 AM, Thierry Carrez wrote:
>> (This email is mostly directed to PTLs for programs that include one
>> integrated project)
>>
>> The DefCore subcommittee from the OpenStack board of directors asked the
>> Technical Committee yesterday about which code sections in each
>> integrated project should be "designated sections" in the sense of [1]
>> (code you're actually needed to run or include to be allowed to use the
>> trademark). That determines where you can run alternate code (think:
>> substitute your own private hypervisor driver) and still be able to call
>> the result openstack.
>>
>> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>>
>> PTLs and their teams are obviously the best placed to define this, so it
>> seems like the process should be: PTLs propose designated sections to
>> the TC, which blesses them, combines them and forwards the result to the
>> DefCore committee. We could certainly leverage part of the governance
>> repo to make sure the lists are kept up to date.
>>
>> Comments, thoughts ?
>>
>
> The process you suggest is what I would prefer.  (PTLs writing proposals
> for TC to approve)
>
> Using the governance repo makes sense as a means for the PTLs to post
> their proposals for review and approval of the TC.
>
>
>
> +1
>
>
>
> +1
>
>
>
> Who gets final say if there's strong disagreement between a PTL and the
> TC?  Hopefully this won't matter, but it may be useful to go ahead and
> clear this up front.
>
>
>
> The Board has some say in this, too, right? The proposal [1] is for a set of
> tests to be proposed and for the Board to approve (section 8).
>
>
>
> What is the relationship between that test suite and the designated core
> areas? It seems that anything being tested would need to be designated as
> core. What about the inverse?
>
>
>
> The test suite should validate that the core
> capabilities/behaviors/functionality behave as expected (positive and
> negative testing in an integrated environment).  So, the test suites would
> need to be reviewed for applicability.  Maybe, like Gerrit, there would be
> voting and nonvoting parts of tests based on whether something outside of
> core gets exercised in the process of running some tests.  Whatever the
> case, I doubt that the tests would generate a simple yes/no, but rather a
> score.  An discussion of one of the subsets of capabilities for Nova might
> start with the capabilities highlighted on this page:
>
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix
>
>
>
> The test suite would need to exercise the capabilities in these sorts of
> matrices and might product the A/B/C grades as the rest of the page
> elucidates.
>

Sorry but I think this misses the point of the PTL request being made
here.  The question being asked is not "is the interface compatible",
it's quite possible for somebody to build a cloud without a single
piece of OpenStack code but still provide an OpenStack compatible
interface and mimic behaviors.  IMO compatibility tests already exist
for the most part via the Tempest test suite that we use to gate on.
If I'm incorrect and that is in fact the goal, that's significantly
easier to solve IMO.

The question here as I understand it (and I may be confused again
based on the thread here) is what parts of the code/modules are
required to be used in order for somebody building a cloud to say
"it's an OpenStack cloud"?  The cheat answer for me would be, you have
to be using cinder-api, cinder-scheduler and cinder-volume services
(regardless of driver).  That raises the next layer of detail though,
do those services have to be un-modified?  How much modification is
acceptable etc. What about deployments that may use their own
scheduler?

I think the direction the thread is taking here is that there really
isn't enough information to make this call, and there certainly isn't
enough understanding of the intent, meaning or ramifications.
>
>
> --Rocky
>
>
>
> Doug
>
>
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
>
>
>
>
>
> --
> Russell Bryant
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Rochelle.RochelleGrober]

On Wed, Feb 5, 2014 at 12:05 PM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
On 02/05/2014 11:22 AM, Thierry Carrez wrote:
> (This email is mostly directed to PTLs for programs that include one
> integrated project)
>
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
>
> Comments, thoughts ?
>
The process you suggest is what I would prefer.  (PTLs writing proposals
for TC to approve)

Using the governance repo makes sense as a means for the PTLs to post
their proposals for review and approval of the TC.

+1

+1

Who gets final say if there's strong disagreement between a PTL and the
TC?  Hopefully this won't matter, but it may be useful to go ahead and
clear this up front.

The Board has some say in this, too, right? The proposal [1] is for a set of 
tests to be proposed and for the Board to approve (section 8).

What is the relationship between that test suite and the designated core areas? 
It seems that anything being tested would need to be designated as core. What 
about the inverse?

The test suite should validate that the core 
capabilities/behaviors/functionality behave as expected (positive and negative 
testing in an integrated environment).  So, the test suites would need to be 
reviewed for applicability.  Maybe, like Gerrit, there would be voting and 
nonvoting parts of tests based on whether something outside of core gets 
exercised in the process of running some tests.  Whatever the case, I doubt 
that the tests would generate a simple yes/no, but rather a score.  An 
discussion of one of the subsets of capabilities for Nova might start with the 
capabilities highlighted on this page:
https://wiki.openstack.org/wiki/HypervisorSupportMatrix

The test suite would need to exercise the capabilities in these sorts of 
matrices and might product the A/B/C grades as the rest of the page elucidates.

--Rocky

Doug

[1] https://wiki.openstack.org/wiki/Governance/CoreDefinition



--
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Doug Hellmann]

On Wed, Feb 5, 2014 at 12:05 PM, Russell Bryant  wrote:

> On 02/05/2014 11:22 AM, Thierry Carrez wrote:
> > (This email is mostly directed to PTLs for programs that include one
> > integrated project)
> >
> > The DefCore subcommittee from the OpenStack board of directors asked the
> > Technical Committee yesterday about which code sections in each
> > integrated project should be "designated sections" in the sense of [1]
> > (code you're actually needed to run or include to be allowed to use the
> > trademark). That determines where you can run alternate code (think:
> > substitute your own private hypervisor driver) and still be able to call
> > the result openstack.
> >
> > [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
> >
> > PTLs and their teams are obviously the best placed to define this, so it
> > seems like the process should be: PTLs propose designated sections to
> > the TC, which blesses them, combines them and forwards the result to the
> > DefCore committee. We could certainly leverage part of the governance
> > repo to make sure the lists are kept up to date.
> >
> > Comments, thoughts ?
> >
>
> The process you suggest is what I would prefer.  (PTLs writing proposals
> for TC to approve)
>
> Using the governance repo makes sense as a means for the PTLs to post
> their proposals for review and approval of the TC.
>

+1

Who gets final say if there's strong disagreement between a PTL and the
> TC?  Hopefully this won't matter, but it may be useful to go ahead and
> clear this up front.
>

The Board has some say in this, too, right? The proposal [1] is for a set
of tests to be proposed and for the Board to approve (section 8).

What is the relationship between that test suite and the designated core
areas? It seems that anything being tested would need to be designated as
core. What about the inverse?

Doug

[1] https://wiki.openstack.org/wiki/Governance/CoreDefinition



>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Russell Bryant]

On 02/05/2014 12:54 PM, Jonathan Bryce wrote:
> On Feb 5, 2014, at 11:12 AM, Mark McLoughlin  wrote:
> 
>> I don't have a big issue with the way the Foundation currently enforces
>> "you must use the code" - anyone who signs a trademark agreement with
>> the Foundation agrees to "include the entirety of" Nova's code. That's
>> very vague, but I assume the Foundation can terminate the agreement if
>> it thinks the other party is acting in bad faith.
>>
>> Basically, I'm concerned about us swinging from a rather lax "you must
>> include our code" rule to an overly strict "you must make no downstream
>> modifications to our code”.
> 
> I tend to agree with you for the most part. As they exist today, the 
> trademark licenses include a couple of components: legally agreeing to use 
> the code in the projects specified (requires self certification from the 
> licensee) and passing the approved test suite once it exists (which adds a 
> component requiring external validation of behavior). By creating the test 
> suite and selecting required capabilities that can be externally validated 
> through the test suite, we would take a step in tightening up the usage and 
> consistency enforceable by our existing legal framework.
> 
> I think that "designated sections” could provide a useful construct for 
> better general guidance on where the extension points to the codebase are. 
> From a practical standpoint, it would probably be pretty difficult to 
> efficiently audit an overly strict definition of the designated sections and 
> this would still be a self certifying requirement on the licensee.

Another thing to consider is that like many other implementation
details, this stuff is rapidly evolving.  I'm a bit worried about the
nightmare of trying to keep the definitions up to date, much less agreed
upon by all parties involved.

The vague "include the entirety of" statement is in line with what I
feel is appropriate for Nova.  I suspect that I would disagree with some
interpretations of that, though.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Mark Washenberger]

On Wed, Feb 5, 2014 at 8:22 AM, Thierry Carrez wrote:

> (This email is mostly directed to PTLs for programs that include one
> integrated project)
>
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
>
> Comments, thoughts ?
>

I don't have any issue defining what I think of as typical extension /
variation seams in the Glance code base. However, I'm still struggling to
understand what all this means for our projects and our ecosystem.
Basically, why do I care? What are the implications of a 0% vs 100%
designation? Are we hoping to improve interoperability, or encourage more
upstream collaboration, or what?

How many deployments do we expect to get the trademark after this core
definition process is completed?


>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Jonathan Bryce]

On Feb 5, 2014, at 11:12 AM, Mark McLoughlin  wrote:

> I don't have a big issue with the way the Foundation currently enforces
> "you must use the code" - anyone who signs a trademark agreement with
> the Foundation agrees to "include the entirety of" Nova's code. That's
> very vague, but I assume the Foundation can terminate the agreement if
> it thinks the other party is acting in bad faith.
> 
> Basically, I'm concerned about us swinging from a rather lax "you must
> include our code" rule to an overly strict "you must make no downstream
> modifications to our code”.

I tend to agree with you for the most part. As they exist today, the trademark 
licenses include a couple of components: legally agreeing to use the code in 
the projects specified (requires self certification from the licensee) and 
passing the approved test suite once it exists (which adds a component 
requiring external validation of behavior). By creating the test suite and 
selecting required capabilities that can be externally validated through the 
test suite, we would take a step in tightening up the usage and consistency 
enforceable by our existing legal framework.

I think that "designated sections” could provide a useful construct for better 
general guidance on where the extension points to the codebase are. From a 
practical standpoint, it would probably be pretty difficult to efficiently 
audit an overly strict definition of the designated sections and this would 
still be a self certifying requirement on the licensee.

Jonathan


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Thierry Carrez]

Russell Bryant wrote:
> Who gets final say if there's strong disagreement between a PTL and the
> TC?  Hopefully this won't matter, but it may be useful to go ahead and
> clear this up front.

I suspect that would be as usual. PTL has final say over his project
matters. The TC can just wield the nuclear weapon of removing a project
from the integrated release... but I seriously doubt we'd engage in such
an extreme solution over that precise discussion.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Mark McLoughlin]

On Wed, 2014-02-05 at 17:22 +0100, Thierry Carrez wrote:
> (This email is mostly directed to PTLs for programs that include one
> integrated project)
> 
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
> 
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
> 
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
> 
> Comments, thoughts ?

I think what would be useful to the board is if we could describe at a
high level which parts of each project have a pluggable interface and
whether we encourage out-of-tree implementations of those pluggable
interfaces.

That's actually a pretty tedious thing to document properly - think
about e.g. whether we encourage out-of-tree WSGI middlewares.

There's a flip-side to this "designated sections" thing that bothers me
after talking it through with Michael Still - I think it's perfectly
reasonable for vendors to e.g. backport fixes to their products without
that backport ever seeing the light of day upstream (say it was too
invasive for the stable branch).

This can't be a case of e.g. enforcing the sha1 sums of files. If we
want to go that route, let's just use the AGPL :)

I don't have a big issue with the way the Foundation currently enforces
"you must use the code" - anyone who signs a trademark agreement with
the Foundation agrees to "include the entirety of" Nova's code. That's
very vague, but I assume the Foundation can terminate the agreement if
it thinks the other party is acting in bad faith.

Basically, I'm concerned about us swinging from a rather lax "you must
include our code" rule to an overly strict "you must make no downstream
modifications to our code".

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Russell Bryant]

On 02/05/2014 11:55 AM, Doug Hellmann wrote:
> 
> 
> 
> On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez  > wrote:
> 
> (This email is mostly directed to PTLs for programs that include one
> integrated project)
> 
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
> 
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
> 
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
> 
> Comments, thoughts ?
> 
> 
> How specific do those designations need to be? The question of the
> impact of this designation system on code organization came up, but
> wasn't really answered clearly. Do we have any cases where part of the
> code in one module might be designated core, but another part wouldn't?
> 
> For example, I could envision a module that contains code for managing
> data with CRUD operations where the delete is handled through an
> operational job rather than a public API (keystone tokens come to mind
> as an example of that sort of data, as does the data collected by
> ceilometer). While it's likely that the operational job for pruning the
> database would be used in any real deployment, is that tool part of
> "core"? Does that mean a deployer could not use an alternate mechanism
> to manage database's growth? If the pruning tool is not core, does that
> mean the delete code is also not? Does it have to then live in a
> different module from the implementations of the other operations that
> are core?
> 
> It seems like the intent is to draw the lines between common project
> code and "drivers" or other sorts of plugins or extensions, without
> actually using those words because all of them are tied to
> implementation details. It seems better technically, and closer to the
> need of someone wanting to customize a deployment, to designate a set of
> "customization points" for each app (be they drivers, plugins,
> extensions, whatever) and say that the rest of the app is core.

Perhaps going through this process for a single project first would be
helpful.  I agree that some clarification is needed on the details of
the expected result.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Russell Bryant]

On 02/05/2014 11:22 AM, Thierry Carrez wrote:
> (This email is mostly directed to PTLs for programs that include one
> integrated project)
> 
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
> 
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
> 
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
> 
> Comments, thoughts ?
> 

The process you suggest is what I would prefer.  (PTLs writing proposals
for TC to approve)

Using the governance repo makes sense as a means for the PTLs to post
their proposals for review and approval of the TC.

Who gets final say if there's strong disagreement between a PTL and the
TC?  Hopefully this won't matter, but it may be useful to go ahead and
clear this up front.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTL] Designating "required use" upstream code

[Doug Hellmann]

On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez wrote:

> (This email is mostly directed to PTLs for programs that include one
> integrated project)
>
> The DefCore subcommittee from the OpenStack board of directors asked the
> Technical Committee yesterday about which code sections in each
> integrated project should be "designated sections" in the sense of [1]
> (code you're actually needed to run or include to be allowed to use the
> trademark). That determines where you can run alternate code (think:
> substitute your own private hypervisor driver) and still be able to call
> the result openstack.
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
> PTLs and their teams are obviously the best placed to define this, so it
> seems like the process should be: PTLs propose designated sections to
> the TC, which blesses them, combines them and forwards the result to the
> DefCore committee. We could certainly leverage part of the governance
> repo to make sure the lists are kept up to date.
>
> Comments, thoughts ?
>

How specific do those designations need to be? The question of the impact
of this designation system on code organization came up, but wasn't really
answered clearly. Do we have any cases where part of the code in one module
might be designated core, but another part wouldn't?

For example, I could envision a module that contains code for managing data
with CRUD operations where the delete is handled through an operational job
rather than a public API (keystone tokens come to mind as an example of
that sort of data, as does the data collected by ceilometer). While it's
likely that the operational job for pruning the database would be used in
any real deployment, is that tool part of "core"? Does that mean a deployer
could not use an alternate mechanism to manage database's growth? If the
pruning tool is not core, does that mean the delete code is also not? Does
it have to then live in a different module from the implementations of the
other operations that are core?

It seems like the intent is to draw the lines between common project code
and "drivers" or other sorts of plugins or extensions, without actually
using those words because all of them are tied to implementation details.
It seems better technically, and closer to the need of someone wanting to
customize a deployment, to designate a set of "customization points" for
each app (be they drivers, plugins, extensions, whatever) and say that the
rest of the app is core.

Doug



>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [PTL] Designating "required use" upstream code

[Thierry Carrez]

(This email is mostly directed to PTLs for programs that include one
integrated project)

The DefCore subcommittee from the OpenStack board of directors asked the
Technical Committee yesterday about which code sections in each
integrated project should be "designated sections" in the sense of [1]
(code you're actually needed to run or include to be allowed to use the
trademark). That determines where you can run alternate code (think:
substitute your own private hypervisor driver) and still be able to call
the result openstack.

[1] https://wiki.openstack.org/wiki/Governance/CoreDefinition

PTLs and their teams are obviously the best placed to define this, so it
seems like the process should be: PTLs propose designated sections to
the TC, which blesses them, combines them and forwards the result to the
DefCore committee. We could certainly leverage part of the governance
repo to make sure the lists are kept up to date.

Comments, thoughts ?

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev