On Wed, Feb 5, 2014 at 10:22 AM, Thierry Carrez <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 ? > 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. 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. 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). > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
