I've been using packstack to build an allinone controller and then add compute nodes.  I do some modification of cinder backend/size, nova networking, openvswitch, neutron, vlans and interface NICs.  I modify settings after packstack so I exclude previously configured nodes from being modified when I add a new compute node.

We develop an application that uses the openstack APIs and it is very useful to be stand up an allinone and a compute node the same way every time.  It's more important for us to have multiple clouds than multiple nodes.  Having 2 nodes means we can do some internode work that won't be on an allinone.

We can also use this setup for a customer POC to see our software run w/o spending lots on a real cloud.  Some will only purchase on physical system so it's important that we don't require a 2nd system just to standup the cloud.  Running off a DVD with no internet access in a customer lab means they see our software run.

I am interested in KVM on KVM.  It would let me have more cloud controllers :-)

I've been able to stand up a slow allinone in virtualbox or vmware with 1 GB RAM, 1 CPU and 20 GB.  I haven't been able to get a compute node to go with it.  Probably because connecting the compute NICs on layer 2 isn't done quite right in the hypervisor.



On Mon, Sep 21, 2015 at 9:57 AM, Adam Young <ayoung@redhat.com> wrote:
On 09/21/2015 09:51 AM, Rich Bowen wrote:


On 09/18/2015 05:04 PM, Perry Myers wrote:
What is the minimum amount of RAM you need for the undercloud node?

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

If we allow for "not very useful" as a stated caveat of the all-in-one,
then we could probably get away with

I think we need to more clearly define what "not very useful" means.

>From my limited PoV, useful would be the ability to run 1 or two
Instances just to try out the system end to end. Those Instances could
be very very slimmed down Fedora images or even Cirros images.


Yes, that would be my definition of "minimal required usefulness" - run a couple of instances, and be able to connect to them from "outside". Not running any actual workloads.

Related, it would be awesome to have, some day, a Trystack-ish service for experimenting with RDO-Manager. (I know this has been mentioned before.)

One way that I routinely use packstack is on top of an existing OpenStack instance.

I think it would be a very powerful tool if we could run the overcloud install on top of an existing OpenStack instance.  We should use the existing openstack deployment as the undercloud, to minimize degrees of nesting of virt.







However, for someone else useful might mean a whole other host of
things. So we should be careful to identify specific personas here, and
map a specific install footprint to that particular persona's view of useful

3GB and swap for both overcloud VMs and 4GB for the undercloud.

It's possible to go lower for the undercloud if you have a lot of swap
and are patient. It may lead to timeouts/broken-ness, so I wouldn't
recommend it.

Ack

_______________________________________________
Rdo-list mailing list
Rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscribe@redhat.com




_______________________________________________
Rdo-list mailing list
Rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscribe@redhat.com