Open Stack

Except for the fact that the person who implemented this was told to
change the option name in other projects because it conflicted with a
different option. We can keep this if we’re worried about being too
obvious (to the point of becoming the Department of Redundancy Department)
with our naming. I don’t think other projects will be very happy having to
change their naming especially if the original name was already a problem.

On 12/2/14, 06:12, "Zhi Yan Liu" <lzy.dev at gmail.com> wrote:

>I totally agreed to make it to be consistent cross all projects, so I
>propose to change other projects.
>
>But I think keeping it as-it is clear enough for both developer and
>operator/configuration, for example:
>
>[profiler]
>enable = True
>
>instead of:
>
>[profiler]
>profiler_enable = True
>
>Tbh, the "profiler" prefix is redundant to me still from the
>perspective of operator/configuration.
>
>zhiyan
>
>
>On Tue, Dec 2, 2014 at 7:44 PM, Louis Taylor <kragniz at gmail.com> wrote:
>> On Tue, Dec 02, 2014 at 12:16:44PM +0800, Zhi Yan Liu wrote:
>>> Why not change other services instead of glance? I see one reason is
>>> "glance is the only one service use this option name", but to me one
>>> reason to keep it as-it in glance is that original name makes more
>>> sense due to the option already under "profiler" group, adding
>>> "profiler" prefix to it is really redundant, imo, and in other
>>> existing config group there's no one go this naming way. Then in the
>>> code we can just use a clear way:
>>>
>>>     CONF.profiler.enabled
>>>
>>> instead of:
>>>
>>>     CONF.profiler.profiler_enabled
>>>
>>> thanks,
>>> zhiyan
>>
>> I agree this looks nicer in the code. However, the primary consumer of
>>this
>> option is someone editing it in the configuration files. In this case, I
>> believe having something more verbose and consistent is better than the
>>Glance
>> code being slightly more elegant.
>>
>> One name or the other doesn't make all that much difference, but
>>consistency in
>> how we turn osprofiler on and off across projects would be best.
>>
>> - Louis
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev