Open Stack

On Fri, Jul 25, 2014 at 7:38 AM, Kerrin, Michael <michael.kerrin at hp.com>
wrote:

> Coming back to this.
>
> I have updated the review https://review.openstack.org/#/c/90134/ so that
> it passing CI for ubuntu (obviously failing on fedora) and I am happy with
> it. In order to close this off my plan is to getting feedback on the mysql
> element in this review. Any changes that people request in the next few
> days I will make and test via the CI and internally. Next I will rename
> mysql -> percona and restore the old mysql in this review. At which point
> the percona code will not be tested via CI so I don't want to make any more
> changes at that point so I hope it will get approved. So this review will
> move to adding a percona element.
>
> Then following the mariadb integration I would like to get this
> https://review.openstack.org/#/c/109415/ change to tripleo-incubator
> through that will include the new percona element in ubuntu images. So in
> the CI fedora will us mariadb and ubuntu will use percona.
>
> Looking forward to any feedback,
>
> Michael
>
>
> On 09 July 2014 14:44:15, Sullivan, Jon Paul wrote:
>
>> -----Original Message-----
>>> From: Giulio Fidente [mailto:gfidente at redhat.com]
>>> Sent: 04 July 2014 14:37
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora
>>>
>>> On 07/01/2014 05:47 PM, Michael Kerrin wrote:
>>>
>>>> I propose making mysql an abstract element and user must choose either
>>>> percona or mariadb-rpm element.CI must be setup correctly
>>>>
>>>
>>> +1
>>>
>>> seems a cleaner and more sustainable approach
>>>
>>
>> There was some concern from lifeless around recreating package-style
>> dependencies in dib with element-provides/element-deps, in particular a
>> suggestion that meta-elements are not desirable[1] (I hope I am
>> paraphrasing you correctly Rob).
>>
>> That said, this is exactly the reason that element-provides was brought
>> in, so that the definition of the image could have "mysql" as an element,
>> but that the DIB_*_EXTRA_ARGS variable would provide the correct one, which
>> would then list itself as providing mysql.
>>
>> This would not prevent the sharing of common code through a
>> differently-named element, such as mysql-common.
>>
>>
>> [1] see comments on April 10th in https://review.openstack.org/#/c/85776/
>>
>>  --
>>> Giulio Fidente
>>> GPG KEY: 08D733BA
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Thanks,
>> Jon-Paul Sullivan ☺ Cloud Services - @hpcloud
>>
>> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park,
>> Galway.
>> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John
>> Rogerson's Quay, Dublin 2.
>> Registered Number: 361933
>>
>> The contents of this message and any attachments to it are confidential
>> and may be legally privileged. If you have received this message in error
>> you should delete it from your system immediately and advise the sender.
>>
>> To any recipient of this message within HP, unless otherwise stated, you
>> should consider this message and attachments as "HP CONFIDENTIAL".
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

​So this all sounds like an interesting mess.  I'm not even really sure I
follow all that's going on in the database area with the exception of the
design which it seems is something that takes no account for testing or
commonality across platforms (pretty bad IMO) but I don't have any insight
there so I'll butt out.

The LIO versus Tgt thing however is a bit troubling.  Is there a reason
that TripleO decided to do the exact opposite of what the defaults are in
the rest of OpenStack here?  Also any reason why if there was a valid
justification for this it didn't seem like it might be worthwhile to work
with the rest of the OpenStack community and share what they considered to
be the better solution here?

Sorry, I just haven't swallowed the TripleO pill.  We seem to have taken
the problem of "how to make it easier to install OpenStack" and turned it
into as complex and difficult a thing as possible.  Hey... it's hard to
deploy and manage a cloud; have two!  By the way, we did everything
differently here than anywhere else so everything you thought you knew,
still need it but won't help you here.. best of luck to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/0f86af48/attachment.html>