Open Stack

That way all gate tests will patch and at the end when Quantum references
all group names in lowercase, we can remove the duplicated inisets in
devstack.

s/patch/pass/g


On Thu, May 23, 2013 at 11:41 AM, Zhongyue Luo <zhongyue.nah at intel.com>wrote:

> Hi team,
>
> First of all, I apologize to the QA team for not communicating with you.
> I implemented oslo bp cfg-lowercase-group and caused the frustration of
> Quantum not working well with Devstack.
>
> Let me first share what I was thinking when writing the Quantum patches to
> change group names to lowercase.
> As of oslo.config 1.2.0, all group names in conf files will be normalized
> to lowercase in order to have consistent group name formats across
> OpenStack projects.
> And since the conf files had to be backwards compatible, the original plan
> was to normalize the group names when read from the conf files and
> referenced in the code.
> However, we decided to only normalize group names when read since projects
> which were using capital group names can fix to reference lowercase group
> names in Havana.
> And the patch merged in oslo.config
>
> Now Quantum trunk had to reference group names in lowercase in order to
> use oslo.config 1.2.0.
> And to ease code reviewing load, I started changing each capital letter
> group names to lowercase.
> This went well until I realized I didn't consider devstack in gating.
>
> So here is the solution I propose.
>
> #1
> To resolve this situation I was planning to write patches to DevStack
> where it does the same iniset of quantum options in capital letter groups
> again in lowercase groups.
> That way all gate tests will patch and at the end when Quantum references
> all group names in lowercase, we can remove the duplicated inisets in
> devstack.
>
> #2
> Another solution is for me to send in one huge patch to Quantum which 1)
> updates oslo.config to 1.2.0 and 2) changes all group name references in to
> lowercase.
>
> Sorry again for the confusion. Let me know what you think.
>
>
>
> On Thu, May 23, 2013 at 10:19 AM, Clark Boylan <clark.boylan at gmail.com>wrote:
>
>> On Wed, May 22, 2013 at 6:51 PM, Robert Collins
>> <robertc at robertcollins.net> wrote:
>> >> So should devstack be doing this? And even if it did, I think this
>> >> will break the way Robert is deploying. I think this change may
>> >> need some more thought it appears.
>> >
>> > I believe that is because Quantum still only lists 1.1.0 as a
>> > dependency: the gate uses trunk rather than the pip installed
>> > dependencies, which means the gate couldn't detect this (assuming
>> > 1.1.1 does fix it).
>> >
>> > FWIW we don't deploy via devstack, but the process is fairly similar:
>> > grab trunk, install it with deps from pypi + packages for openvswitch
>> > etc, then go : so while there weren't tests to trigger it, my concern
>> > is that the gate setup wouldn't detect the problem *even with tests*,
>> > because the problem is a requirement file that isn't being honoured
>> > due to the gate setup.
>> >
>> I double checked this by reading the devstack-gate logs and checking
>> the projects list at [1]. And as far as I can tell oslo.config is
>> installed as a normal dependency with pip from pypi (or our mirror).
>> oslo.config would need to be in that projects list for it to be
>> installed from source in the gate. So not quite trunk, but it isn't
>> 1.1.0 either as 1.1.1 is available and pip prefers to use that
>> version.
>>
>> [1]
>> https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L22
>>
>> Clark
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> *Intel SSG/SSD/STO/DCST/CIT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
> China
> +862161166500
>



-- 
*Intel SSG/SSD/STO/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130523/af7db70e/attachment.html>