[openstack-dev] [oslo] About app-agnostic-logging-parameters

Fujita, Daisuke fuzita.daisuke at jp.fujitsu.com
Fri Jun 26 12:58:34 UTC 2015


Hi, Doug Hellmann,

Thank you for your reply.

> -----Original Message-----
> From: Doug Hellmann [mailto:doug at doughellmann.com]
> Sent: Friday, June 26, 2015 1:04 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [oslo] About app-agnostic-logging-parameters
> 
> Excerpts from Fujita, Daisuke's message of 2015-06-25 10:42:05 +0000:
> > Hi, Doug Hellmann, and oslo.log team members,
> >
> > I'm Daisuke Fujita of Fujitsu.
> >
> > May I ask you about this Blueprint?
> >
> > https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
> >
> > This patch has been already implemented in master branch of oslo_log.
> > But, blueprint status is " Started".
> >
> > Is this feature already available?
> 
> We have started it, but need to ensure that all projects are using the
> request class in oslo.context as the base class for their request
> contexts, to ensure the API expected by oslo.log is maintained. That
> will take some more research to understand how each project is currently
> different, and what properties and attributes need to be passed where. I
> would welcome help with that work, if you are interested in
> participating.
> 
I think that BP is very nice approach for logging.
I want to definitely cooperate with you.

About the following projects, it seem to have been already using 
the request class in oslo.context as the base class.
 * nova
 * neutron
 * cinder
 * glance
 * heat
 * ironic

> >
> > And, in my understanding it is necessary to add "%resource" to logging_context_format_string(etc) of the config-file
> when I use this feature.
> > Is that correct?
> 
> The goal is to set up the default log format string to be the same in
> all projects, and have the context class provide application-specific
> values. So nova might set an instance as the resource but neutron might
> set a network or port as the resource. The deployer would still be able
> to rearrange the format string as they want, and always use the name
> "resource" in the location where they want the UUID of the thing being
> operated on.
> 
I understand your goal image.
So, I try to about the following approach.

 1. Adding "resource"(type and UUID) for neutron when new resource is created.
    * When new resource is created(POST), I think it is most important to output the uuid.
      Because user has already known the uuid when PUT/DELETE/GET operation.
 2. Adding "resource"(type and UUID) for other core projects when new resource is created.
    * This change would be accepted by each project's members because 
      existing processing is not affected unless "resource" is specified
      in logging_context_format_string(etc).
    * If user want to output this "resource", user has to set the config-file.
 3. After getting other developers' consent, we will change the default format.
 4. Changing the Documentation.
 5. Adding "resource"(type and UUID) for all projects when resource is operated.

Best Regards,
Daisuke Fujita

> >
> > Because I would like to suggest a draft amendment to output a UUID when resource is created, I want to confirm about
> that BP.
> >
> > Best Regards,
> > Daisuke Fujita
> >
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list