Open Stack

Thanks guys ☺ 

Andrew – I think it would be highly beneficial if you could detail your thoughts in a specification so the whole community can see. I can definitely offer my time to help you work on this. Perhaps we could sync up one (my morning/your afternoon) time and get it out and ready? I can’t imagine the whole process would take longer than an hour. 

That way we can get some feedback on the proposal, and we can have some direction for end of Ocata/beginning of Pike. 

On 12/7/16, 1:45 AM, "Andrew Beekhof" <abeekhof at redhat.com> wrote:

    On Wed, Dec 7, 2016 at 3:39 AM, Adam Spiers <aspiers at suse.com> wrote:
    
    > 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.
    
    Nod, we've talked about that in the past and I agree.
    
    What I was intending to convey was that I don't think we need to spend
    much time on them, certainly not a chapter or section each.
    Probably a single "If you want the cluster to manage OpenStack
    services" section with a short description and command listing would
    be sufficient.
    Maybe as a peer to a section on how nagios or similar might fit into
    the architecture.
    
    The biggest thing to decide for that section is OCF vs. systemd agents.