On Fri, Jul 25, 2014 at 7:59 AM, John Griffith <john.griff...@solidfire.com> wrote:
> > > > On Fri, Jul 25, 2014 at 7:38 AM, Kerrin, Michael <michael.ker...@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:gfide...@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@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev