[Rdo-list] RDO-Manager "quickstart"

[James Slagle]

On Fri, Sep 18, 2015 at 03:49:39PM -0400, Perry Myers wrote:
> On 09/18/2015 03:35 PM, Rich Bowen wrote:
> > One of the goals of the RDO Packstack Quickstart is to give people a
> > successful and easy first-time experience deploying OpenStack, even if
> > what they're left with (an --allinone deployment) might not be, strictly
> > speaking, *useful* for much.
> > 
> > Today on IRC I asked if we might possibly work towards a similar
> > quickstart for RDO-Manager, where we make a bunch of assumptions and
> > automate whatever parts of it we can, and end up with a "do these three
> > steps" kind of thing, like the Packstack quickstart.
> > 
> > I've included the transcript of the conversation below, but since IRC
> > transcripts can be confusing after the fact, to summarize, slagle opined
> > that it might be feasible to have two paths - the full-featured path
> > that we currently have, but also something as I described above for your
> > first time.
> > 
> > I wanted to toss this out here for a larger audience to see whether this
> > seems like a reasonable goal to pursue?
> 
> +1
> 
> I think it's critical to have something that's easy to work for _very_
> constrained use cases. But I also agree with the below sentiments that
> we need to properly document and enable folks to do more complex
> deployments after they've had their first success with the minimal
> deployment option

The quickstart idea was kind of what I was going for with this a while back:
https://www.rdoproject.org/TripleO_VM_Setup
(***now outdated***).

It might still look like a lot of commands to run, but it could be way less
verbose with some simple tooling. I wasn't trying to hide all the details when
I originally wrote that.

Anyway, I do think we could so something similar again for RDO-Manager.

> 
> One thing to consider in all of this is... what is the minimum
> deployment footprint? I think we have to assume virtual, since most
> folks won't have a lab with 6 nodes sitting around.
> 
> A few options:
> 
> a Undercloud on one VM, single overcloud controller on another VM,
>   single compute node on another VM (using nested virt, or just plain
>   emulation)

I try to stay away from nested KVM. Every now and then I or someone will come
along and try it, report it works for a bit, but ends up in various kernel
crashes/panics if the environment stays up for too long.

We did try with it enabled in an OpenStack cloud itself during a hackfest
event, and had planned on giving each participant a 32 GB vm (spawned by nova),
that had KVM support. They would then use that to do an rdo-manager HA
deployment in virt. It hummed along quite nicely initially, but started
experiencing hard lockups before long.

> 
> b 2nd variation on the above would be to run the 3 node controller HA
>   setup, which means 1 undercloud, 3 overcloud controllers + 1 compute
> 
> The question is... what is the minimum amount of RAM that you can run an
> overcloud controller with?  4GB?  Or can that be squeezed to 2 or 3GB
> just for playing around purposes?
> 
> What is the minimum amount of RAM you need for the undercloud node?

4GB, and that now results in OOM'ing after a couple deployments without swap
enabled on the undercloud.

> 
> If 4GB per VM, then a) maybe can be done on a 16GB system, while b)
> needs 32GB

You can do a) with 12GB max (I do on my laptop) since not all of the memory is
in use, and you can give the compute node much less than 4GB even. KSM also
helps.

> 
> If we could squeeze controller and undercloud nodes into 3GB each, then

We haven't honestly spent a lot (any) time tuning for memory optimization, so
it might be possible, but I'm a little doubtful.

> it might be possible to run b) on a 16GB machine, opening up
> experimentation with RDO Manager in a real HA configuration to lots more
> people

If you have swap enabled on the host, I've done b) on a 16GB host. I don't
recall how much swap ended up getting used.

> 
> Perry
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
--
-- James Slagle
--