On Mon, Aug 8, 2016 at 1:06 PM, Jeremy Stanley <fu...@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 -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
