Open Stack

Excerpts from John Griffith's message of 2014-07-25 06:59:38 -0700:
> 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?
> 

John, please be specific when you say "the defaults are in the rest of
OpenStack". We have a stated goal to deploy _with the defaults_. The
default iscsi_helper is tgtadmin. We deploy with that unless another is
selected. As you see below, nothing is asserted there unless a value is
set:

https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/cinder/os-apply-config/etc/cinder/cinder.conf#n41

And the default in the Heat templates that will set that value matches
cinder's current default:

https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-source.yaml#n21

http://git.openstack.org/cgit/openstack/cinder/tree/etc/cinder/cinder.conf.sample#n1017

LIO is used on RHEL, because RHEL doesn't offer TGT. So what is "the LIO
versus Tgt thing?

> 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.

Having two clouds, one for deployment, and one (or "n") for tenants,
isn't a core part of the design, it is a workaround for the scheduler
problems we saw early on. As I understand it, those have been solved
and there is a desire to have a single-cloud TripleO soon.

However, some see it as a feature, since direct access to the hardware
control plane is a sensitive thing, and having an entirely separate
keystone for that is attractive _to some_.

The problem of how to make it _easier_ is not the stated goal of TripleO.

>From https://wiki.openstack.org/wiki/TripleO:

"TripleO is a program aimed at installing, upgrading and operating
OpenStack clouds using OpenStack's own cloud facilities as the foundations
- building on nova, neutron and heat to automate fleet management at
datacentre scale (and scaling down to as few as 2 machines)."

Nobody expects datacenter scale to be easy. We do, however, have a
reasonable expectation that OpenStack can be used to deploy large,
complex applications. If it cannot, OpenStack is in trouble.

The bits where we use tools that aren't traditional is also not the
point of TripleO. We are being tool agnostic so as to not alienate any
one community from OpenStack as a whole.

I personally fought against more options in TripleO early on, and that was
a mistake. It has become clear to me that having packages as an option has
enabled our friends at RedHat to participate in the virtuous circle and
improve OpenStack as a whole for deploying large applications while they
work on the TripleO deployment story. They can do this without having to
"swallow the TripleO pill". There are multiple pills, and they've opted
out of a few of them and cut a few in half. If they can do it, I think
anybody can. But nobody is trying to recruit you.. I just want to make
it clear that we've learned our lesson (I think) and are quite amenable
to alternatives, *if* they are presented in a consumable fashion.