[openstack-dev] [TripleO] test environment requirements

Dan Prince dprince at redhat.com
Fri Mar 21 16:25:42 UTC 2014

----- Original Message -----
> From: "Robert Collins" <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Thursday, March 13, 2014 5:51:30 AM
> Subject: [openstack-dev] [TripleO] test environment requirements
> So we already have pretty high requirements - its basically a 16G
> workstation as minimum.
> Specifically to test the full story:
>  - a seed VM
>  - an undercloud VM (bm deploy infra)
>  - 1 overcloud control VM
>  - 2 overcloud hypervisor VMs
> ====
>    5 VMs with 2+G RAM each.
> To test the overcloud alone against the seed we save 1 VM, to skip the
> overcloud we save 3.
> However, as HA matures we're about to add 4 more VMs: we need a HA
> control plane for both the under and overclouds:
>  - a seed VM
>  - 3 undercloud VMs (HA bm deploy infra)
>  - 3 overcloud control VMs (HA)
>  - 2 overcloud hypervisor VMs
> ====
>    9 VMs with 2+G RAM each == 18GB
> What should we do about this?
> A few thoughts to kick start discussion:
>  - use Ironic to test across multiple machines (involves tunnelling
> brbm across machines, fairly easy)
>  - shrink the VM sizes (causes thrashing)
>  - tell folk to toughen up and get bigger machines (ahahahahaha, no)
>  - make the default configuration inline the hypervisors on the
> overcloud with the control plane:
>    - a seed VM
>    - 3 undercloud VMs (HA bm deploy infra)
>    - 3 overcloud all-in-one VMs (HA)
>   ====
>      7 VMs with 2+G RAM each == 14GB
> I think its important that we exercise features like HA and live
> migration regularly by developers, so I'm quite keen to have a fairly
> solid systematic answer that will let us catch things like bad
> firewall rules on the control node preventing network tunnelling
> etc...

I'm all for supporting HA development and testing within devtest. I'm *against* forcing it on all users as a default.

I can imaging wanting to cut corners and have configurations flexible on both ends (undercloud and overcloud). I may for example deploy a single all-in-one undercloud when I'm testing overcloud HA. Or vice versa.

I think I'm one of the few (if not the only) developer who uses almost exclusive baremetal (besides seed VM) when test/developing TripleO. Forcing users who want to do this to have 6-7 real machines is a bit much I think. Arguably wasteful even. By requiring more machines to run through devtest you actually make it harder for people to test it on real hardware which is usually harder to come by. Given deployment on real bare metal is sort of the point or TripleO I'd very much like to see more developers using it rather than less.

So by all means lets support HA... but lets do it in a way that is configurable (i.e. not forcing people to be wasters)


> e.g. we benefit the more things are split out like scale
> deployments are. OTOH testing the micro-cloud that folk may start with
> is also a really good idea....
> -Rob
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list