[Openstack-operators] [openstack-dev] [TripleO] consistency vs packages in TripleO

Clint Byrum clint at fewbar.com
Fri Feb 14 18:53:09 UTC 2014

Excerpts from Robert Collins's message of 2014-02-13 13:27:20 -0800:
> So progressing with the 'and folk that want to use packages can' arc,
> we're running into some friction.
> I've copied -operators in on this because its very relevant IMO to operators :)
> So far:
>  - some packages use different usernames
>  - some put things in different places (and all of them use different
> places to the bare metal ephemeral device layout which requires
> /mnt/).
>  - possibly more in future.
> Now, obviously its a 'small matter of code' to deal with this, but the
> impact on ops folk isn't so small. There are basically two routes that
> I can see:
> # A
>  - we have a reference layout - install from OpenStack git / pypi
> releases; this is what we will gate on, and can document.
>  - and then each distro (both flavor of Linux and also possibly things
> like Fuel that distribution OpenStack) is different - install on X,
> get some delta vs reference.
>  -> we need multiple manuals describing how to operate and diagnose
> issues in such a deployment, which is a matrix that overlays platform
> differences the user selects like 'Fedora' and 'Xen'.

Having read the responses, I'm inclined to support A, with some
additional requirements:

* Reference implementations are always derided as not realistic. I think
  we need to think of a different term. I prefer to just say that this
  is the upstream implementation. We very much expect that a cloud can
  and should operate with this model unmodified. Packagers are doing so
  to fit OpenStack into a greater support model, not because "nobody
  would ever want to run upstream." I think of how a large portion of
  MySQL users tend to just run upstream's binaries. They don't call this
  the reference binaries.

* Documentation can be split into an architecture guide which should be
  a single source of truth and document interfaces only, and an operations
  guide, which will focus on the upstream operations story. Distros should
  provide sub-sections for that story to document their differences.
  They should not, however, be putting distro specific interfaces in the
  architecture documentation, and we would reject such things until they
  are known to work upstream.

More information about the OpenStack-operators mailing list