Bug 1328124

Moving to rhos-11? based on input from engineering - we will re-visit the status of this work following completion of the Newton cycle.

Moving to 12/Pike. While we will continue to collaborate on this feature in the context of upstream development throughout Ocata I do not believe we will be in a position to offer a coherent TripleO supported technology preview in 12.

(In reply to Stephen Gordon from comment #2)
> Moving to 12/Pike. While we will continue to collaborate on this feature in
> the context of upstream development throughout Ocata I do not believe we
> will be in a position to offer a coherent TripleO supported technology
> preview in 12.

Dan any initial predictions for Pike? I think given current state I would be tempted to push technology preview of this to Queens with a view to allowing enough time for the Nova work to land and get some basic TripleO support for multi-cell, thoughts?

We're dangerously close to somewhat academic multi-cell capabilities with what is proposed and expected to merge in ocata. If that happens, I would love to be able to get early feedback on it in pike as a preview.

I'm not sure what the tripleo support will look like, but almost all of the work will be needed in order to support the required bits of ocata anyway.

Perhaps we should huddle with some tripleo people, describe the remaining changes and try to formulate a plan?

(In reply to Dan Smith from comment #5)
> We're dangerously close to somewhat academic multi-cell capabilities with
> what is proposed and expected to merge in ocata. If that happens, I would
> love to be able to get early feedback on it in pike as a preview.
> 
> I'm not sure what the tripleo support will look like, but almost all of the
> work will be needed in order to support the required bits of ocata anyway.

My concern is that for the multi-cell case that is not *really* true, in that while we will have most of the relevant pieces it is going to involve quite a lot of additional work to define the architecture we want to deploy and develop the orchestration to do it when we start talking about adding Cells.

For example currently we still generally deploy a single message broker and database, albeit in HA across three nodes, for the environment and while customizable roles give us increased flexibility in the general case these specific services are examples of ones that are still exceptions to that today. So to me it seems like on face value there would be quite a lot of work here not so much in the plumbing of loading up the new Cell's DB schema, mapping hosts to it etc., but in providing the infrastructure it will rely on in the first place.

> Perhaps we should huddle with some tripleo people, describe the remaining
> changes and try to formulate a plan?

For 12 the focus for Ollie and Sven is likely going to be completing the RT KVM enablement work, and the OOTB live migration epic as a secondary task. I'm going to target this RFE for 13 *but* I think to be in a position to execute that we do indeed need to start thinking about what a multi-cell architecture would look like in the context of TripleO, what work items we need to raise to track that, etc. during the 12 release cycle.

I also think in the 12 timeframe it would be beneficial to work with performance and scale to work out how far we can scale such deployments (albeit doing the plumbing somewhat manually in the absence of TripleO integration) as that will be where we can see if we are delivering operator facing value.

Basically TL;DR we probably need an epic document to track this through multiple releases.

(In reply to Stephen Gordon from comment #6)
> (In reply to Dan Smith from comment #5)
> > We're dangerously close to somewhat academic multi-cell capabilities with
> > what is proposed and expected to merge in ocata. If that happens, I would
> > love to be able to get early feedback on it in pike as a preview.
> > 
> > I'm not sure what the tripleo support will look like, but almost all of the
> > work will be needed in order to support the required bits of ocata anyway.
> 
> My concern is that for the multi-cell case that is not *really* true, in
> that while we will have most of the relevant pieces it is going to involve
> quite a lot of additional work to define the architecture we want to deploy
> and develop the orchestration to do it when we start talking about adding
> Cells.
> 
> For example currently we still generally deploy a single message broker and
> database, albeit in HA across three nodes, for the environment and while
> customizable roles give us increased flexibility in the general case these
> specific services are examples of ones that are still exceptions to that
> today. So to me it seems like on face value there would be quite a lot of
> work here not so much in the plumbing of loading up the new Cell's DB
> schema, mapping hosts to it etc., but in providing the infrastructure it
> will rely on in the first place.

Just to be explicit here, I'm obviously talking about adding *additional* cells beyond the "cell of one" which we obviously have to have.

*** Bug 1094868 has been marked as a duplicate of this bug. ***

Adding Triaged keyword to highlight that while yes this has been open for > 1 year it is something we triaged and intend to pursue.

Moving to 14 as a more realistic target from a director integration POV - which is where a lot of the work would be expected to be once the Nova work is complete.

*** Bug 1694074 has been marked as a duplicate of this bug. ***

note, multicell deployment is right now broken in master due to https://review.opendev.org/665213 .

* AllNodesConfig was removed
* also in the now created information we miss the cell service node names, like we created them before [1]

[1] https://review.opendev.org/#/c/665213/20/network/ports/net_ip_list_map.j2.yaml

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:0283