Open Stack

On 02/05/2014 11:55 AM, Doug Hellmann wrote:
> 
> 
> 
> On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez <thierry at openstack.org
> <mailto: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.

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