Open Stack

----- Original Message -----
> 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...

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
>