On Tue, Jan 14, 2014 at 11:27 AM, Luis A. Garcia <l...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev