Open Stack

On Fri, Jul 25, 2014 at 7:59 AM, John Griffith <john.griffith at solidfire.com>
wrote:

>
>
>
> 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.
>
> ​Oh.. before the CD flames come my way, yes I know that's something
somebody was interested in.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/0fb64d8d/attachment.html>