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. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
