Open Stack

On Oct 31, 2015, at 7:18 PM, Meyer, Jim <jim.meyer at hpe.com <mailto:jim.meyer at hpe.com>> wrote:

> I was reading this:
> 
> Debian dropping the Linux Standard Base [LWN.net <http://lwn.net/>]
> https://lwn.net/Articles/658809/ <https://lwn.net/Articles/658809/>
> 
> … and was struck by the parallels behind both the intent of LSB and DefCore (provide assurances around common functionality and interoperability delivered in a distro) as well as implementation (standard trails implementation, etc.). The article is a 5-10 minute read; in the comments, read the first from michaeljt; then pick up near the bottom, starting with the one by criswell, to the end.
> 
> I see two interesting ways to angles from which to view this:
> 
> 1. LSB was successful at driving convergence for 20+ years and is beginning to die out.
> 2. LSB failed to reach effectiveness in 20+ years of trying and is beginning to die out.
> 
> The case for #1 seems suspect. The article and comments, as well as the relative lack of applications which successfully adopted LSB as the primary or sole basis of specifying their dependencies, seem to indicate otherwise.
> 
> The question here: how is DefCore different, and how will we succeed where LSB failed?

Hi Jim

The primary difference is in the trademark application. Application
of the Linux Sublicense is managed by the Linux Trademark Institute
and does not require that a distribution implement the Linux Standard
Base (LSB) program [1]. The Linux Foundation provides LSB and LSB
Certified trademark programs [2] which does require compliance with
the program. The marks are seperate though, so loss of the LSB mark
does not cause loss of the Linux mark.

The OpenStack Foundation is taking a different approach.
Use of the OpenStack Powered trademark requires conforming to the
DefCore guideline, which includes using designated sections of
OpenStack code, and providing capabilities that can be independently
checked with must-pass tests [3][4].

As the OpenStack Powered trademark is the only mark that can be
applied to products running OpenStack, the incentive to conform
to the program is much greater. A distribution or service could
not apply an OpenStack trademark without passing DefCore.

The surface area of the DefCore standard is smaller than the LSB. 
Right now it only enforces components for core projects and explicitly
tests across Keystone, Nova, and Swift (with implicit tests for networking,
block storage, and image storage). End users can independently test a
cloud using the DefCore tests. Interoperability is defined against a set
of APIs that is built by the developer community, and the DefCore
"lagging" indicators is designed to move at the pace of new API
introduction and adoption, including criteria to consider future Technical
Committee directives [4].

The real proof of the program will be seen in the next year or
two as we refine the guidelines to ensure capabilities that
guarantee a base level of interoperability for applications
written by developers and users.

We're starting small, limiting our scope to a set of core
projects, and quickly refining the guideline to address issues
that the entire community: users, developers, and vendors; are
finding. From my point of view, the DefCore process has already
had a positive impact on API maturity in the development community
and in encoraging vendors to not make breaking changes to deployed
APIs. This is feeding into efforts to support our application
development community in building easily deployable apps that
run on Openstack.

If we do DefCore correctly, it will become a boring standard that
is easy to enforce because it is easy to deploy upstream while
tracking how the needs of the community is expressed through the
evolving APIs (which themselves take time to be successfully
deployed and adopted).

Chris Hoge
Interop Engineer
OpenStack Foundation

[1] http://www.linuxfoundation.org/programs/legal/trademark/sublicense-agreement <http://www.linuxfoundation.org/programs/legal/trademark/sublicense-agreement>
[2] http://www.linuxfoundation.org/about/linux-foundation-trademark-usage-guidelines <http://www.linuxfoundation.org/about/linux-foundation-trademark-usage-guidelines>
[3] https://openstack.org/brand/interop <https://openstack.org/brand/interop>
[4] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json <http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json>
[5] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst <http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst>


> --j
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org <mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee <http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20151102/2992daa1/attachment.html>