<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 10: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>I'm curious about the level of granularity that's envisioned in each definition. "Designated sections" could be as broad as keystone.* or as narrow as keystone.token.controllers.Auth.validate_token_head(). It could be defined in terms of executables, package paths, or line numbers.</div>

<div><br></div><div><div>The definition is likely to change over time (i.e. per stable release). For example, where support for password-based authentication might have been mandated for an essex deployment, a havana deployment has the ability to remove the password auth plugin and replace it with something else.</div>

<div><br></div><div>The definition may also be conditional, and require "either A or B." In havana for example, where keystone shipped two "stable" APIs side by side, I wouldn't expect all deployments to enable both (or even bother to update their paste pipeline from a previous release).</div>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>