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).

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to