On 02/05/2014 11:55 AM, Doug Hellmann wrote: > > > > On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez <thie...@openstack.org > <mailto:thie...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
