Open Stack

Sounds good Mark. Will make appropriate changes.

-- dims

On Mon, May 20, 2013 at 12:12 PM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Sun, 2013-05-19 at 07:51 +0300, Gary Kotton wrote:
>> On 05/18/2013 06:57 PM, Davanum Srinivas wrote:
>> > Gary,
>> >
>> > We are at a stalemate between your -1 and Dolph Mathews's -1 on what
>> > the naming of the group in session.py [1]
>>
>> I'd say that we are between a rock and a hard place :)
>>
>> Below is a partial mapping on how the projects have the section and key
>> names for the SQL database:
>>
>> Nova: Section - DEFAULT; Key - sql_connection
>> Cinder: Section - DEFAULT; Key - sql_connection
>> Glance: Section - DEFAULT; Key - sql_connection
>> Quantum: Section - DATABASE; key - sql_connection
>> Keystone: Section - SQL; key - connection
>>
>> My concern is the upgrade process and being backward compatible to the
>> existing configuration. The code that you have done works great for
>> Nova, Cinder and Glance. Problem is that it does not work for Quantum
>> and Keystone.
>>
>> Is there anyway of ensuring that the Quantum and Keystone configurations
>> are also supported. I am not sure that the common configuration module
>> supports more than one deprecated section and key name. If so great.
>>
>> I am really impartial to the section name. I prefer database but can be
>> easily swayed as it is not something that is written in stone. But What
>> I really do think is important is that we do not break things when going
>> from Grizzly to Havana.
>
> I think 'database' is a fine section name - remember, the section names
> are there to help users rather than a name-spacing tool to keep
> independent pieces of code (like an alternative DB driver) from
> clashing.
>
> If we say that 'database' is the right thing, we can merge this patch
> into oslo-incubator and have Quantum switch over to the common DB code.
>
> Supporting legacy keystone configs with sql.connection using something
> like dims cfg patch makes sense too, but we can do that at a later point
> since it seems like Quantum is the project most eager to adopt the
> common code now.
>
> Cheers,
> Mark.
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com