Open Stack

On Thu, Feb 6, 2014 at 9:21 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Dolph Mathews wrote:
> > 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).
>
> That's why I think it's not practical to define which code needs to be
> run (because you never "run" all the code paths or all the drivers at
> the same time), and we should define where *external code* can be
> plugged instead.
>
> Then, in your example, if A and B are both in the code we ship, there is
> no need to talk about them, unless you also allow an external C driver
> to be run instead.
>

+1

Doug



>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/da63e418/attachment.html>