[openstack-dev] Less option

Flavio Percoco flavio at redhat.com
Fri Jan 10 11:16:13 UTC 2014


On 10/01/14 11:28 +0100, Thierry Carrez wrote:
>Flavio Percoco wrote:
>> On 09/01/14 23:56 +0100, Julien Danjou wrote:
>>> I also think projects should try to minimize configuration options at
>>> their minimum so operators are completely lost. Opening the sample
>>> nova.conf and seeing 696 options is not what I would call user friendly.
>>>
>>> And also having working default. I know it's hard, but we should really
>>> try to think about that sometimes.
>>>
>>> Sorry to hijack the thread a bit.
>>
>> IMHO, not a hijack!
>
>It's a hijack, because it deserves a thread of its own, rather than be
>lost in the last breaths of the configserver thread.

I didn't consider it "a bad hijack" because it's still relevant to
what was being discussed in the previous thread. Anyway, thanks for
creating a new one.

>Adding a config option is a good way to avoid saying NO - you just say
>"yes, not by default and enabled with a config option" instead. The
>trouble begins when the sheer number of options make it difficult to
>document, find and configure the right options, and the trouble
>continues when you're unable to test the explosive matrix of option
>combinations. Classifying options between basic and advanced are a way
>to mitigate that, but not a magic bullet.

Agreed, differentiating the options sounds like a good idea. I don't
think the issue is just related to whether the option is
well-documented or not. Good documentation helps for sure but it's
still difficult to know all the options when there are so many.

One thing that should be considered is that we have to make sure the
default values are sane. By sane I mean they've to be good enough to
support rather big deployments. I've seen - and unfortunately I don't
have a reference to this because my memory sucks - default values that
are good just to 'get it running' which basically means that all
'serious' deployments will have to tweak that value. This is something
we should all keep in mind.

>Personally I think we should (and we can) say NO more often. As we get
>stronger as a dev community it becomes easier, and I think we see more
>"opinionated" choices in younger projects. That said, it's just harder
>for old projects which already have a lot of options to suddenly start
>denying someone's feature instead of just adding another option...

I've seen NOs flying around, which is a good sign. I think one of the
issues right now is that we already have many configuration options in
some projects and we should try to shrink them, if possible.

I also think we should keep things as much non-opinionated as
possible. Unless the new project is very specific, this is something
that it should stick to.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140110/84311970/attachment.pgp>


More information about the OpenStack-dev mailing list