Open Stack

Hi all,

Thanks a lot for starting this worthwhile discussion and
revitalization!

Matt Kassawara <mkassawara at gmail.com> wrote:
> The HA guide, similar to our other operational guides, needs contributions
> from operators or developers of deployment tools that implement HA.

IIUC a lot of the contributions historically were from consultants
such as Hastexo, and distro vendors such as Red Hat and SUSE.  But
yes, I agree 100% that more contributions from operators with
real-world experience would be really worthwhile.

> Without recent relevant content, we're just restructuring defunct
> content and/or making assumptions that don't benefit our audience.

I don't think I really agree with this.  It sounds like you are
assuming that there is a high level of natural "bit-rot" with this
information - i.e. that if it is not well maintained then information
quickly becomes inaccurate.  That is often true elsewhere but actually
in this HA context it doesn't hold so much.

I think the majority of the information currently in the guide is
still accurate and useful, even though as Andrew pointed out it is
probably suffering from scope creep and could be pared down to avoid
needless duplication with (say) Pacemaker documentation.
Additionally, in general HA architecture for OpenStack control planes
has been pretty stable for the last few years; not much has
fundamentally changed except for neutron L3 HA and several additional
services which behave similarly to existing services.

One area still in flux is HA of the compute plane, but the guide
deliberately points elsewhere for that information anyway.

> At this point, the HA guide needs a rip-and-replace by people who
> also commit themselves to keeping the content fresh... or just
> archive it.

I'm *strongly* against a rip-and-replace, and even more strongly
against archiving it.  Firstly, as I've already said there is plenty
of useful information in here.  Even outdated information is more
useful than none, as long as there are suitable caveats in place to
stop the information being dangerous.

Secondly, it's hard enough to find people with enough time to maintain
the existing work.  Starting from scratch would require way more
effort, so the chance of finding people who would be willing to do
that seems minimal to non-existent.  And even if there were such
people, such a rewrite would be needlessly throwing away decent
content.

Anyway, big thanks to Alex for her recent reviews (which are high on
my TODO list once my current emergency is dealt with), and also +1 to
most of what Andrew proposed.  The only bit I think is premature with
regards to paring things down would be removing the description of
controlling OpenStack's active/active services (e.g. APIs) via
Pacemaker:

On 12/6/16, 3:53 AM, "Andrew Beekhof" <abeekhof at redhat.com> wrote:
> Most OpenStack services no longer need any hand-holding from a
> cluster manager and don't need to be covered

Even though I agree with most of the details of the next-generation
architecture Andrew is proposing (and I've had many worthwhile
discussions with him on it), I believe there are still plenty of
scenarios in which it's still valid to have these services managed by
Pacemaker.  So I'd prefer to keep that stuff covered by the guide
until such a point that the next-generation architecture is widely
adopted and well proven.

Thanks again!
Adam