Open Stack

TripleO recently passed a fairly key milestone - while we've been
working with virtual machines for a while now, we have enough of the
'full story' together that we started a proof of concept on -shock,
horror- actual hardware.

This is very cool : we've now got a repeatable one-heat-command to
turn on new nova-compute nodes, with Quantum ovs, fully parameterised.
\o/.

On the other hand, we're finding a large chunk of the work we're doing
is changing defaults.

If we were changing them down from 'this works for prod clouds' to
'this works for a test cloud' - that would be fine. But we're changing
them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger
quotas for end users.

Another large chunk of the bring up is determining private network
details w/in Quantum - something that isn't (typically) exposed to
either the real world *or* other machines w/in the datacentre.

So I find myself asking two questions:

a) why aren't the defaults suitable for production? Where they are not
suitable, it's just friction waiting to trip new deployers up.

b) perhaps we can document - or even automate - some defaults for
things like Quantum topology, which will work ok everywhere, and which
we can tell folk who are just getting going 'follow this, it will work
well enough for you to get experience with the rest of the system'.

To a degree, a and b are both catered to by the 'how to install
*release* guide' documents that folk put out : but everything in those
documents that varies from the upstream default is IMO a bug :).

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services