Open Stack

On Mon, Aug 8, 2016 at 1:06 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2016-08-08 11:47:56 -0400 (-0400), James Slagle wrote:
> [...]
>> I suppose it's also possible that we might be pushing too strongly
>> down the multinode path? Is the general concensus in infra that they'd
>> like to help enable project teams to eventually add 3 and 4 (and maybe
>> more) node multinode jobs?
> [...]
>
> We've not outright rejected the idea, but do want to make sure that
> there's been suitable due diligence done explaining how the things
> you'll be able to test with >2 job nodes effectively can't be done
> with <=2.

Our current 2 node job uses the first node as the undercloud which
deploys an AIO Overcloud on the 2nd node. TripleO traditionally has
also been able to deploy standalone Compute, Cinder, Swift, and Ceph
nodes. Additionally in this cycle, a lot of work has gone into making
it fully customizable what services are deployed on which roles. You
can deploy nodes that are just API services, or just a DB server, or
rabbitmq, etc. In order to test the composability feature we need to
deploy to more than one node.

Also, we'd need at least 3 Overcloud nodes to successfully test that
we can deploy a Pacemaker managed cluster successfully.

> Also we want to be sure that projects who are interested
> in multi-node jobs start with just 2 job nodes and get some initial
> tests performing well and returning stable results before trying to
> push past 2.

I think that the 2 node job that we've added has been stable. We've
worked a few issues out that we've hit depending on which cloud
provider we land on, but generally speaking it has been very stable.

We make use of the ovs_vxlan_bridge function from devstack-gate to
configure the private networking among the nodes. I think this was a
good first step since that has been a proven way in the devstack
multinode jobs. I'd like to move to using TripleO's os-net-config in
the future though, since that is the tool used in TripleO. The end
result of the network configuration would be the same (using ovs vxlan
bridges), we'd just use a different tool to get there.

-- 
-- James Slagle
--