Open Stack

On February 14, 2015 at 5:59:13 PM, Clint Byrum (clint at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150214/a59b1d37/attachment.html>