[openstack-dev] [TripleO] test environment requirements

Derek Higgins derekh at redhat.com
Fri Mar 21 15:57:01 UTC 2014


On 13/03/14 16:12, James Slagle wrote:
> On Thu, Mar 13, 2014 at 2:51 AM, Robert Collins
> <robertc at robertcollins.net> wrote:
>> 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... 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....
> 
> 
> The idea I was thinking was to make a testenv host available to
> tripleo atc's. Or, perhaps make it a bit more locked down and only
> available to a new group of tripleo folk, existing somewhere between
> the privileges of tripleo atc's and tripleo-cd-admins.  We could
> document how you use the cloud (Red Hat's or HP's) rack to start up a
> instance to run devtest on one of the compute hosts, request and lock
> yourself a testenv environment on one of the testenv hosts, etc.
> Basically, how our CI works. Although I think we'd want different
> testenv hosts for development vs what runs the CI, and would need to
> make sure everything was locked down appropriately security-wise.

I like this idea, I think it could work, my only concern is the extra
capacity we would need to pull it off. At the moment we are probably
falling short on capacity to do what we want for CI so adding to this
would make the situation worse (how much worse I don't know). So unless
we get to the point where we have spare hardware doing nothing I think
its a non runner.

> 
> Some other ideas:
> 
> - Allow an option to get rid of the seed VM, or make it so that you
> can shut it down after the Undercloud is up. This only really gets rid
> of 1 VM though, so it doesn't buy you much nor solve any long term
> problem.
> 
> - Make it easier to see how you'd use virsh against any libvirt host
> you might have lying around.  We already have the setting exposed, but
> make it a bit more public and call it out more in the docs. I've
> actually never tried it myself, but have been meaning to.

this could work as an option

> 
> - I'm really reaching now, and this may be entirely unrealistic :),
> but....somehow use the fake baremetal driver and expose a mechanism to
> let the developer specify the already setup undercloud/overcloud
> environment ahead of time.
> For example:
> * Build your undercloud images with the vm element since you won't be
> PXE booting it
> * Upload your images to a public cloud, and boot instances for them.
> * Use this new mechanism when you run devtest (presumably running from
> another instance in the same cloud)  to say "I'm using the fake
> baremetal driver, and here are the  IP's of the undercloud instances".
> * Repeat steps for the overcloud (e.g., configure undercloud to use
> fake baremetal driver, etc).
> * Maybe it's not the fake baremetal driver, and instead a new driver
> that is a noop for the pxe stuff, and the power_on implementation
> powers on the cloud instances.
> * Obviously if your aim is to test the pxe and disk deploy process
> itself, this wouldn't work for you.
> * Presumably said public cloud is OpenStack, so we've also achieved
> another layer of "On OpenStack".
> 
> 




More information about the OpenStack-dev mailing list