On 15 February 2014 12:15, Dirk Müller wrote:
> I agree, and changing defaults has a cost as well: Every deployment
> solution out there has to detect the value change, update their config
> templates and potentially also migrate the setting from the old to the
> new default for existing deployme
>Have the folks creating our puppet modules and install recommendations
taken a >close look at all the options and determined
>that the defaults are appropriate for deploying RHEL OSP in the
configurations we >are recommending?
If by our puppet modules you mean the ones in stackforge, in the vast
>> were not appropriate for real deployment, and our puppet modules were
>> not providing better values
>> https://bugzilla.redhat.com/show_bug.cgi?id=1064061.
I'd agree that raising the caching timeout is a not a good "production
default" choice. I'd also argue that the underlying issue is fixed
On Fri, 2014-02-14 at 11:30 -0800, Greg C wrote:
>
> On Thu, Feb 13, 2014 at 6:38 AM, David Kranz
> wrote:
>
> Defaults in conf files seem to be one of the following:
>
> - Generic, appropriate for most situations
> - Appropriate for devstack
> -
Excerpts from Jay Pipes's message of 2014-02-13 07:19:18 -0800:
> * Identify settings that need to scale with the size of the underlying
> VM or host capabilities, and provide patches to the configuration file
> comments that clearly indicate a recommended scaling factor. Remember
> that folks writ
On Thu, Feb 13, 2014 at 6:38 AM, David Kranz wrote:
>
> Defaults in conf files seem to be one of the following:
>
> - Generic, appropriate for most situations
> - Appropriate for devstack
> - Appropriate for small, distro-based deployment
> - Approprate for large deployment
>
In my experiences
2014-02-13 23:19 GMT+08:00 Jay Pipes :
> On Thu, 2014-02-13 at 09:38 -0500, David Kranz wrote:
> > I was recently bitten by a case where some defaults in keystone.conf
> > were not appropriate for real deployment, and our puppet modules were
> > not providing better values
> > https://bugzilla.red
On 2014-02-13 09:01, Clint Byrum wrote:
Excerpts from David Kranz's message of 2014-02-13 06:38:52 -0800:
I was recently bitten by a case where some defaults in keystone.conf
were not appropriate for real deployment, and our puppet modules were
not providing better values
https://bugzilla.redhat
On Thu, 2014-02-13 at 09:38 -0500, David Kranz wrote:
> I was recently bitten by a case where some defaults in keystone.conf
> were not appropriate for real deployment, and our puppet modules were
> not providing better values
> https://bugzilla.redhat.com/show_bug.cgi?id=1064061. Since there ar
David,
Good that you rise this topic. It is actually sad that you have to make a
big investigation of OpenStack config params, before you are able to use
OpenStack. I think that this work should be done mostly inside upstream.
So I have a couple of ideas how we can simplify investigation of how
Excerpts from David Kranz's message of 2014-02-13 06:38:52 -0800:
> I was recently bitten by a case where some defaults in keystone.conf
> were not appropriate for real deployment, and our puppet modules were
> not providing better values
> https://bugzilla.redhat.com/show_bug.cgi?id=1064061.
J
I was recently bitten by a case where some defaults in keystone.conf
were not appropriate for real deployment, and our puppet modules were
not providing better values
https://bugzilla.redhat.com/show_bug.cgi?id=1064061. Since there are
hundreds (thousands?) of options across all the services. I
12 matches
Mail list logo
