Open Stack

Some goodies inline below.

On Thu, Jun 20, 2019 at 12:34 PM Mark Goddard <mark at stackhpc.com> wrote:

> On Thu, 20 Jun 2019 at 17:27, Michael Johnson <johnsomor at gmail.com> wrote:
> >
> > Hi Mark,
> >
> > I wanted to highlight that I wrote a detailed certificate
> > configuration guide for Octavia here:
> > https://docs.openstack.org/octavia/latest/admin/guides/certificates.html
> >
> > This could be used to automate the certificate generation for Kolla
> deployments.
>
> Great, that looks useful.
>

Michael was super awesome creating this after Tobias and I (and a few other
folks) ran into road blocks with this. Many many thanks for that.

>
> > Let me know if you have any questions about the guide or steps,
> > Michael
> >
> > On Thu, Jun 20, 2019 at 7:31 AM Mark Goddard <mark at stackhpc.com> wrote:
> > >
> > > On Thu, 20 Jun 2019 at 15:08, Alex Schultz <aschultz at redhat.com>
> wrote:
> > > >
> > > >
> > > >
> > > > On Thu, Jun 20, 2019 at 8:00 AM Mark Goddard <mark at stackhpc.com>
> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> In the recent kolla meeting [1] we discussed the usability of
> octavia
> > > >> in kolla ansible. We had feedback at the Denver summit [2] that this
> > > >> service is difficult to deploy and requires a number of manual
> steps.
> > > >> Certificates are one of the main headaches. It was stated that OSA
> [3]
> > > >> may have some useful code we could look into.
> > > >
> > > >
> > > > I second that Octavia is very painful to install. There is a
> requirement of a bunch of openstack cloud configurations
> (flavors/images/etc) that must be handled prior to actually configuring the
> service which means it's complex to deploy. IMHO it would have been
> beneficial for some of these items to actually have been rolled into the
> service itself (ie dynamically querying the services for flavor information
> rather than expecting an ID put into a configuration file).  That being
> said, we have managed to get it integrated into tripleo but it's rather
> complex. It does use ansible if you want to borrow some of the concepts for
> os_octavia.
> > > >
> > > >
> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/deployment/octavia
> > > >
> https://opendev.org/openstack/tripleo-common/src/branch/master/playbooks/octavia-files.yaml
> > > >
> https://opendev.org/openstack/tripleo-common/src/branch/master/playbooks/roles
> > > >
> > > > Additionally we're still leveraging some of the puppet-octavia code
> to manage configs/nova flavors.
> > >
> > > Thanks for sharing Alex & Carlos - useful source material.
> > >
>

Most of that bitching in Denver was me. Thanks to John for recording it for
posterity. With Octavia being the defacto LBaaS standard in Openstack we
need to do a much better job deploying it. This proved to be a bit of a
headache with kolla-ansible, but I don't think it's terribly far off.

The main issue, as mentioned in all the reference materials you provided,
is certificate generation. Kolla-ansible presently only supports a single
CA and does not help operators create that in any way. Also, you really
need to have two CAs. Beyond that, Octavia is extremely fussy about its
certificates and getting it right can be a royal pain.

During my first attempt at doing this deployment, I went in search of some
project that had the certificate generation as a component and found that
OSA had the functionality and documented it well. I extracted the needed
bits, ran it, and came out the other side with a working set of
certificates. Then, like most operators, I saw a squirrel and forgot to do
anything more with it.

So with the introduction out of the way, here's what I used. It was
entirely derived from OSA with much love.

https://github.com/emccormickva/octavia-cert-generate

I also had to make a few hacks to kolla-ansible to get everything going.

1) In the octavia config template (octavia.conf.j2) I updated the config
options to use the new certificates as follows:

[certificates]
ca_private_key = /etc/octavia/certs/private/cakey.pem
ca_certificate = /etc/octavia/certs/ca_server_01.pem

[haproxy_amphora]
server_ca = /etc/octavia/certs/ca_server_01.pem
client_cert = /etc/octavia/certs/client.pem

[controller_worker]
client_ca = /etc/octavia/certs/ca_01.pem

2) Update kolla's config-yml to copy over all the certs for each container

  with_items:
    - cakey.pem
    - ca_01.pem
    - ca_server_01.pem
    - client.pem

I think I had to make a few other hacks in Queens, but all of those seem to
have been addressed already (just doing a diff of master vs. my current
configs). If we can incorporate certificate generation, get 2 CAs, and copy
/ configure them properly, I think everything will be great. Maybe others
have additional asks, but this would do it for me. If I can scrap together
some time, I'll see if I can get some commits together to make it happen,
but that's always a dodgy proposition. I'm also always willing to review
whatever or answer questions from someone else who wants to take it on.

Cheers,
Erik


> > >
> > > > Thanks,
> > > > -Alex
> > > >
> > > >>
> > > >>
> > > >> As a starting point to improving this support, I'd like to gather
> > > >> information from people who are using octavia in kolla ansible, and
> > > >> what they have had to do to make it work. Please respond to this
> > > >> email.
> > > >>
> > > >> I've also tagged openstack-ansible and Tripleo - if there is any
> > > >> useful information those teams have to share about this topic, it is
> > > >> most welcome. Alternatively if your support for octavia also falls
> > > >> short perhaps we could collaborate on improvements.
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>
> > > >> [1]
> http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.log.html#l-86
> > > >> [2] https://etherpad.openstack.org/p/DEN-train-kolla-feedback
> > > >> [3] https://opendev.org/openstack/openstack-ansible-os_octavia
> > > >>
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190623/4fcbde8f/attachment.html>