Open Stack

Based on the discussion with the other PTLs at the release meeting
yesterday, I'm going to recommend that we create an example logging.conf
file and documentation to go with it, and not add the new option.

Doug


On Wed, Jan 15, 2014 at 12:00 PM, Brant Knudson <blk at acm.org> wrote:

>
> It might help if we knew from operators whether they tended to use the
> service config file or logging.conf to configure logging for their
> installations. Maybe the service config file logging options are limited
> enough that installations all use logging.conf.
>
> It might make it a lot easier for developers if this option was in the
> service config file. I run with devstack and that sets up logging.conf
> (incorrectly for keystone IMO... I need to submit a patch). So I don't
> think developer convenience is a good reason here.
>
> - Brant
>
>
>
> On Tue, Jan 14, 2014 at 12:33 PM, Doug Hellmann <
> doug.hellmann at dreamhost.com> wrote:
>
>>
>>
>>
>> On Tue, Jan 14, 2014 at 11:27 AM, Luis A. Garcia <luis at linux.vnet.ibm.com
>> > wrote:
>>
>>> On 1/14/2014 6:59 AM, Doug Hellmann wrote:
>>>
>>>>
>>>> [snip]
>>>>
>>>>
>>>>     I think the reason for this is simply user convenience. It's easier
>>>>     for the user to just set one of those log properties from the
>>>>     project.conf, and the "heavy lifting" such the creation of specific:
>>>>     Logger, LogHandler, LogFormatter, LogAdapters, etc. is done behind
>>>>     the scenes. For that reason I think having this option is useful for
>>>>     our users so they can use the new log feature we implemented.
>>>>
>>>>
>>>> It is more convenient for the user if we make them start from scratch,
>>>> which is why I proposed that we deliver a sample configuration file
>>>> specifically for this feature.
>>>>
>>>
>>> I really don't think having users start from scratch is more convenient
>>> for them.
>>
>>
>> Sorry, you're right, that was a typo. I mean "it is *not* more
>> convenient...". They won't be starting from scratch, because they will be
>> given an example configuration file.
>>
>> My main concern with adding another option is that I don't know how many
>>>> deployers will really want to log in more than one language at a time.
>>>> Those deployers who do want it may want more control over where those
>>>> logs are written than the simple option proposed will give them, too.
>>>> The logging.conf file gives them complete control for advanced
>>>> configurations, and a sample file gives them an easy way to turn on
>>>> simple file logging in multiple languages.
>>>>
>>>>
>>> We can address this by allowing the property to accept more than one
>>> language at a time. Now yes, the logging.conf gives complete control
>>> including where the translated log will go to (e.g. file, console, etc.)
>>> however this is a quick and easy way to start using the translated log
>>> feature with very sensible defaults. For those people currently not using
>>> logging.conf it is not just a quick and easy way, it is the only way of
>>> configuring it, without having to redo all their log configuration in a
>>> logging.conf.
>>>
>>
>> Users can have translated logs simply by setting their locale properly.
>> This option enables *dual logging*. That's exactly the sort of thing the
>> logging.conf file is meant to support.
>>
>>
>>
>>>
>>>
>>> This configuration option allows a quick way to use the feature, and
>>> provides consistency with every single other log option. I think those
>>> reasons are valid and the property provides value for users in the form of
>>> simplicity for using the feature, just like every other log option out
>>> there in the project.confs.
>>
>>
>> I don't want to base this decision on the past options. There are already
>> more options than we want. Adding more doesn't help solve that problem.
>>
>>
>>
>>>
>>>
>>> Thank you,
>>>
>>> --
>>> Luis A. García
>>> Cloud Solutions & OpenStack Development
>>> IBM Systems and Technology Group
>>> Ph: (915) 307-6568 | T/L: 363-6276
>>>
>>> "Everything should be made as simple as possible, but not simpler."
>>>                                         - Albert Einstein
>>>
>>> "Simple can be harder than complex: You have to work hard to get
>>> your thinking clean to make it simple."
>>>                                         – Steve Jobs
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140115/67ae5dce/attachment.html>