On February 14, 2015 at 5:59:13 PM, Clint Byrum (cl...@fewbar.com) wrote:
Excerpts from Thomas Goirand's message of 2015-02-14 16:48:01 -0800:
> Hi,
>
> I've seen messages in the logs telling that we should move to the
> identity_uri.
>
> I don't really like the identity_uri which contains all of the
> information in a single directive, which means that a script that would
> edit it would need a lot more parsing work than simply a key/value pair
> logic. This is error prone. The fragments don't have this issue.
>
> So, could we decide to:
> 1/ Not remove the auth fragments
> 2/ Remove the deprecation warnings
>
Automation has tended away from parsing and editting files in place for
a long time now. Typically you'd have a source of truth with all the
values, and a tool to turn that into a URL during file generation. This
isn't error prone in my experience.
I don't really know why the single URL is preferred, but I don't think
the argument that "it makes parsing and editting the config file with
external tools" is strong enough to roll this deprecation back.
As far as I know this is a move to avoid needing many configuration values to
figure out how to communicate with Keystone. With the addition of better
discovery, the auth fragements actually make the job of knowing what to do much
more complex (we have to reconstruct them into a URI anyway). This should be a
move towards being able to ask Keystone what it supports and discover how to
interact with it/auth against it from that standpoint instead of needing the
multiple fragments.
Thomas, Can you be more specific about what use-case you’re running into that
makes the fragments better (instead of a URI form such as the SQL connection
string would be)? As Clint outlined, you tend to have a single source of truth
in most tools and do not do editing of files in-place (I’d even go as far as to
assert that editing a file in-place is always prone to errors/has a high level
of parsing needed and shouldn’t be done).
Thanks!
—Morgan
__________________________________________________________________________
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
