Open Stack

Hi, thanks so much for sending this. Replying to the list so that you all
know the docs team would greatly benefit from a defaults-for-production
approach to configuration.


On Mon, May 27, 2013 at 1:23 PM, Robert Collins
<robertc at robertcollins.net>wrote:

> 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.
>
>
I think we've reached a place where there are more deployments than devs
and this is a good time to push for production defaults. However as I've
fielded questions on IRC and ask.openstack.org it's nearly always people
setting up proof-of-concept asking questions. I'm not sure how deployers
are getting their information, other than hiring from other deployers.


> 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'.
>
>
I'll note that we are automating long lists of reference information but I
would like to have sensible defaults automatically documented as well. Not
sure how realistic "work ok everywhere" is though, others might need to
weigh in on that.


> 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 :).
>
>
I like this line of thinking. How are you currently documenting in Triple-O
the changes you've made? How can we start collecting this information for
the doc team to think about automating and documenting?

Anne


> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130528/80d9aebd/attachment.html>