Open Stack

> From: Dan Prince [mailto:dprince at redhat.com]
> Sent: 24 March 2014 16:53
> Subject: Re: [openstack-dev] [TripleO] test environment requirements
> 
> > From: "Clint Byrum" <clint at fewbar.com>
> > To: "openstack-dev" <openstack-dev at lists.openstack.org>
> > Sent: Sunday, March 23, 2014 9:02:23 PM
> > Subject: Re: [openstack-dev] [TripleO] test environment requirements
> >
> > Excerpts from Dan Prince's message of 2014-03-21 09:25:42 -0700:
> > >
> > > ----- 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)
> > >
> > > Dan
> > >
> >
> > I don't think anybody wants to force it on _users_. But a predominance
> > of end users will require HA, and thus we need our developers to be
> > able to develop with HA.
> >
> > This is for the _benefit_ of developers. I imagine we've all been in
> > situations where our dev environment is almost nothing like CI, and
> > then when CI runs you find that you have missed huge problems.. and
> > now to test for those problems you either have to re-do your dev
> > environment, or wait.. a lot.. for CI.
> 
> All good points. Running an exactly copy of the upstream CI environment
> seems to be getting more and more costly though. My goal is that I'd
> like developers to be able to choose what they want to test as much as
> they can. Streamline things where appropriate. Take the overcloud today:
> I actually like to idea of going the other way here and running an all-
> in-one version of it from time to time to save resources.
> 
> If I know I need to dev test on an HA cloud then by all means I'll try
> to do that. But in many cases I may not need to go to such lengths.
> Furthermore, some testing is better than no testing at all because we've
> set the resources bar too high.
> 
> Again, all for supporting the HA test and dev path in the devtest
> scripts. Ideally making it as configurable as we can...

This is where I was suggesting a small number (2-3)  of differing "standard" configurations that developers could select from given what their change is and what resources they have available.

Something like "overcloud-only", "non-ha" and "ha", or similar.

This seems very much related to https://etherpad.openstack.org/p/tripleo-devtest.sh-refactoring-blueprint and https://etherpad.openstack.org/p/tripleo-incubator-rationalise-ui imho.

> 
> Dan
> 
> 
> >
> > I don't have any really clever answers to this problem. We're testing
> > an end-to-end cloud deployment. If we can't run a small, accurate
> > simulation of such an environment as developers, then we will end up
> going very slow.
> > The problem is that this small simulation is still massive compared to
> > the usual development paradigm which involves at most two distinct
> > virtual machines.
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks, 
Jon-Paul Sullivan ☺ Cloud Services - @hpcloud
	
Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. 
Registered Number: 361933
 
The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as "HP CONFIDENTIAL".