On Tue, Nov 8, 2016 at 4:12 PM, Gage Hugo <gageh...@gmail.com> wrote: > The idea is that a cloud admin could define a list of keys that they need > for their setup within keystone's configuration file, then only those keys > will be valid for storing values in the project properties table. Then each > call would check against the list of valid keys and deny any calls that are > sent with an invalid key.
Please do not do this, it throws fuel onto the interoperability file we still have not put out. One actual technical drawback to doing this is that none of the OpenStack services can depend on any of those keys actually being defined, so this is still effectively just a single-deployment 'extras' field, with the only advance being that all rows may have the same set of keys, depending on how the configuration changes over time. > This idea seems to help with the issue to avoid allowing anyone to throw any > arbitrary values into these project properties vs just a set number of > values. It may feel that way, but it really does not help at all. From a cloud consumer point of view (including tools developed and used by deployers, possibly across multiple cloud deployments) this is no help at all. dt -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev