Open Stack

On Feb 6, 2014, at 8:08 AM, Dolph Mathews <dolph.mathews at gmail.com> 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