Open Stack

On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez <thierry at openstack.org>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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/b11aa2ff/attachment.html>