<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 11:22 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(This email is mostly directed to PTLs for programs that include one<br>
integrated project)<br>
<br>
The DefCore subcommittee from the OpenStack board of directors asked the<br>
Technical Committee yesterday about which code sections in each<br>
integrated project should be "designated sections" in the sense of [1]<br>
(code you're actually needed to run or include to be allowed to use the<br>
trademark). That determines where you can run alternate code (think:<br>
substitute your own private hypervisor driver) and still be able to call<br>
the result openstack.<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Governance/CoreDefinition" target="_blank">https://wiki.openstack.org/wiki/Governance/CoreDefinition</a><br>
<br>
PTLs and their teams are obviously the best placed to define this, so it<br>
seems like the process should be: PTLs propose designated sections to<br>
the TC, which blesses them, combines them and forwards the result to the<br>
DefCore committee. We could certainly leverage part of the governance<br>
repo to make sure the lists are kept up to date.<br>
<br>
Comments, thoughts ?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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?</div>

<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div>

<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>

<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>