Re: [openstack-dev] 答???: [Neutron] Auth token in context

2014-08-04 Thread Isaku Yamahata
ServiceVM wants auth token.
When creating l3 router which runs inside VM, it launches VM.
So neutron interacts with other projects like serivcevm server or nova.

thnaks,


On Sun, Jul 20, 2014 at 12:14:54AM -0700,
Kevin Benton blak...@gmail.com wrote:

 That makes sense. Shouldn't we wait for something to require it before
 adding it though?
 
 
 On Sat, Jul 19, 2014 at 11:41 PM, joehuang joehu...@huawei.com wrote:
 
   Hello, Kevin
 
 
 
  The leakage risk may be one of the design purpose. But  Nova/Cinder has
  already stored the token into the context, because Nova needs to access
  Neutron.Cinder.Glance, And Cinder interact with Glance
 
 
 
  For Neutron, I think why the token has not been passed to the context, is
  because that Neutron only reactively provide service (exactly PORT ) to
  Nova currently, so Neutron has not call other services' API by using the
  token.
 
 
 
  If the underlying agent or plugin wants to use the token, then the
  requirement will be asked by somebody.
 
 
 
  BR
 
 
 
  Joe
 
 
   --
  *???件人:* Kevin Benton [blak...@gmail.com]
  *???送??:* 2014年7月19日 4:23
 
  *收件人:* OpenStack Development Mailing List (not for usage questions)
  *主???:* Re: [openstack-dev] [Neutron] Auth token in context
 
I suspect it was just excluded since it is authenticating information
  and there wasn't a good use case to pass it around everywhere in the
  context where it might be leaked into logs or other network requests
  unexpectedly.
 
 
  On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill 
  phillip.tooh...@rackspace.com wrote:
 
   It was for more of a potential use to query another service. Don't
  think well go this route though, but was curious why it was one of the only
  values not populated even though there's a field for it.
 
From: Kevin Benton blak...@gmail.com
  Reply-To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Date: Friday, July 18, 2014 2:16 PM
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Auth token in context
 
What are you trying to use the token to do?
 
 
  On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill 
  phillip.tooh...@rackspace.com wrote:
 
  Excellent! Thank you for the response, I figured it was possible, just
  concerned me to why everything else made it to context except for the
  token.
 
  So to be clear, you agree that it should at least be passed to context
  and
  because its not could be deemed a bug?
 
  Thank you
 
  On 7/18/14 2:03 AM, joehuang joehu...@huawei.com wrote:
 
  Hello, Phillip.
  
  Currently, Neutron did not pass the token to the context. But
  Nova/Cinder
  did that. It's easy to do that, just 'copy' from Nova/Cinder.
  
  1.  How Nova/Cinder did that
  class NovaKeystoneContext(wsgi.Middleware)
  ///or CinderKeystoneContext for cinder
  
auth_token = req.headers.get('X_AUTH_TOKEN',
   req.headers.get('X_STORAGE_TOKEN'))
ctx = context.RequestContext(user_id,
   project_id,
   user_name=user_name,
   project_name=project_name,
   roles=roles,
   auth_token=auth_token,
   remote_address=remote_address,
   service_catalog=service_catalog)
  
  2.  Neutron not passed token. Also not good for the third part network
  infrastructure to integrate the authentication with KeyStone.
  class NeutronKeystoneContext(wsgi.Middleware)
  .
  # token not get from the header and not passed to context. Just
  change here like what Nova/Cinder did.
  context.Context(user_id, tenant_id, roles=roles,
user_name=user_name,
  tenant_name=tenant_name,
request_id=req_id)
  req.environ['neutron.context'] = ctx
  
  I think I'd better to report a bug for your case.
  
  Best Regards
  Chaoyi Huang ( Joe Huang )
  -???件原件-
  ???件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
  ???送??: 2014年7月18日 14:07
  收件人: OpenStack Development Mailing List (not for usage questions)
  主???: [openstack-dev] [Neutron] Auth token in context
  
  Hello all,
  
  I am wondering how to get the auth token from a user request passed down
  to the context so it can potentially be used by the plugin or driver?
  
  Thank you
  
  
  ___
  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
  

Re: [openstack-dev] 答???: [Neutron] Auth token in context

2014-08-04 Thread Kevin Benton
That makes sense. Is there a patch up for review to make this available in
the context?


On Mon, Aug 4, 2014 at 8:21 AM, Isaku Yamahata isaku.yamah...@gmail.com
wrote:

 ServiceVM wants auth token.
 When creating l3 router which runs inside VM, it launches VM.
 So neutron interacts with other projects like serivcevm server or nova.

 thnaks,


 On Sun, Jul 20, 2014 at 12:14:54AM -0700,
 Kevin Benton blak...@gmail.com wrote:

  That makes sense. Shouldn't we wait for something to require it before
  adding it though?
 
 
  On Sat, Jul 19, 2014 at 11:41 PM, joehuang joehu...@huawei.com wrote:
 
Hello, Kevin
  
  
  
   The leakage risk may be one of the design purpose. But  Nova/Cinder has
   already stored the token into the context, because Nova needs to access
   Neutron.Cinder.Glance, And Cinder interact with Glance
  
  
  
   For Neutron, I think why the token has not been passed to the context,
 is
   because that Neutron only reactively provide service (exactly PORT ) to
   Nova currently, so Neutron has not call other services' API by using
 the
   token.
  
  
  
   If the underlying agent or plugin wants to use the token, then the
   requirement will be asked by somebody.
  
  
  
   BR
  
  
  
   Joe
  
  
--
   *???件人:* Kevin Benton [blak...@gmail.com]
   *???送??:* 2014年7月19日 4:23
  
   *收件人:* OpenStack Development Mailing List (not for usage questions)
   *主???:* Re: [openstack-dev] [Neutron] Auth token in context
  
 I suspect it was just excluded since it is authenticating information
   and there wasn't a good use case to pass it around everywhere in the
   context where it might be leaked into logs or other network requests
   unexpectedly.
  
  
   On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill 
   phillip.tooh...@rackspace.com wrote:
  
It was for more of a potential use to query another service. Don't
   think well go this route though, but was curious why it was one of
 the only
   values not populated even though there's a field for it.
  
 From: Kevin Benton blak...@gmail.com
   Reply-To: OpenStack Development Mailing List (not for usage
 questions)
   openstack-dev@lists.openstack.org
   Date: Friday, July 18, 2014 2:16 PM
   To: OpenStack Development Mailing List (not for usage questions) 
   openstack-dev@lists.openstack.org
   Subject: Re: [openstack-dev] [Neutron] Auth token in context
  
 What are you trying to use the token to do?
  
  
   On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill 
   phillip.tooh...@rackspace.com wrote:
  
   Excellent! Thank you for the response, I figured it was possible,
 just
   concerned me to why everything else made it to context except for the
   token.
  
   So to be clear, you agree that it should at least be passed to
 context
   and
   because its not could be deemed a bug?
  
   Thank you
  
   On 7/18/14 2:03 AM, joehuang joehu...@huawei.com wrote:
  
   Hello, Phillip.
   
   Currently, Neutron did not pass the token to the context. But
   Nova/Cinder
   did that. It's easy to do that, just 'copy' from Nova/Cinder.
   
   1.  How Nova/Cinder did that
   class NovaKeystoneContext(wsgi.Middleware)
   ///or CinderKeystoneContext for cinder
   
 auth_token = req.headers.get('X_AUTH_TOKEN',
   
 req.headers.get('X_STORAGE_TOKEN'))
 ctx = context.RequestContext(user_id,
project_id,
user_name=user_name,
project_name=project_name,
roles=roles,
auth_token=auth_token,
remote_address=remote_address,
   
 service_catalog=service_catalog)
   
   2.  Neutron not passed token. Also not good for the third part
 network
   infrastructure to integrate the authentication with KeyStone.
   class NeutronKeystoneContext(wsgi.Middleware)
   .
   # token not get from the header and not passed to context. Just
   change here like what Nova/Cinder did.
   context.Context(user_id, tenant_id, roles=roles,
 user_name=user_name,
   tenant_name=tenant_name,
 request_id=req_id)
   req.environ['neutron.context'] = ctx
   
   I think I'd better to report a bug for your case.
   
   Best Regards
   Chaoyi Huang ( Joe Huang )
   -???件原件-
   ???件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
   ???送??: 2014年7月18日 14:07
   收件人: OpenStack Development Mailing List (not for usage questions)
   主???: [openstack-dev] [Neutron] Auth token in context
   
   Hello all,
   
   I am wondering how to get the auth token from a user request passed
 down
   to the context so it can potentially be used by the plugin or
 driver?
   
   Thank you
   
   
   ___
   OpenStack-dev mailing list
   

Re: [openstack-dev] 答???: [Neutron] Auth token in context

2014-08-04 Thread Mohammad Banikazemi
Yes, Here: https://review.openstack.org/#/c/111756/



From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: isaku.yamah...@gmail.com
Date:   08/04/2014 01:01 PM
Subject:Re: [openstack-dev] 答???: [Neutron] Auth token in context



That makes sense. Is there a patch up for review to make this available in
the context?


On Mon, Aug 4, 2014 at 8:21 AM, Isaku Yamahata isaku.yamah...@gmail.com
wrote:
  ServiceVM wants auth token.
  When creating l3 router which runs inside VM, it launches VM.
  So neutron interacts with other projects like serivcevm server or nova.

  thnaks,


  On Sun, Jul 20, 2014 at 12:14:54AM -0700,
  Kevin Benton blak...@gmail.com wrote:

   That makes sense. Shouldn't we wait for something to require it before
   adding it though?
  
  
   On Sat, Jul 19, 2014 at 11:41 PM, joehuang joehu...@huawei.com wrote:
  
 Hello, Kevin
   
   
   
The leakage risk may be one of the design purpose. But  Nova/Cinder
  has
already stored the token into the context, because Nova needs to
  access
Neutron.Cinder.Glance, And Cinder interact with Glance
   
   
   
For Neutron, I think why the token has not been passed to the
  context, is
because that Neutron only reactively provide service (exactly PORT )
  to
Nova currently, so Neutron has not call other services' API by using
  the
token.
   
   
   
If the underlying agent or plugin wants to use the token, then the
requirement will be asked by somebody.
   
   
   
BR
   
   
   
Joe
   
   
 --
*???件人:* Kevin Benton [blak...@gmail.com]
*???送??:* 2014年7月19日 4:23
   
*收件人:* OpenStack Development Mailing List (not for usage
  questions)
*主???:* Re: [openstack-dev] [Neutron] Auth token in context
   
  I suspect it was just excluded since it is authenticating
  information
and there wasn't a good use case to pass it around everywhere in the
context where it might be leaked into logs or other network requests
unexpectedly.
   
   
On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill 
phillip.tooh...@rackspace.com wrote:
   
 It was for more of a potential use to query another service. Don't
think well go this route though, but was curious why it was one of
  the only
values not populated even though there's a field for it.
   
  From: Kevin Benton blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage
  questions)
openstack-dev@lists.openstack.org
Date: Friday, July 18, 2014 2:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Auth token in context
   
  What are you trying to use the token to do?
   
   
On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill 
phillip.tooh...@rackspace.com wrote:
   
Excellent! Thank you for the response, I figured it was possible,
  just
concerned me to why everything else made it to context except for
  the
token.
   
So to be clear, you agree that it should at least be passed to
  context
and
because its not could be deemed a bug?
   
Thank you
   
On 7/18/14 2:03 AM, joehuang joehu...@huawei.com wrote:
   
Hello, Phillip.

Currently, Neutron did not pass the token to the context. But
Nova/Cinder
did that. It's easy to do that, just 'copy' from Nova/Cinder.

1.  How Nova/Cinder did that
class NovaKeystoneContext(wsgi.Middleware)
///or CinderKeystoneContext for cinder

              auth_token = req.headers.get('X_AUTH_TOKEN',
                                     req.headers.get
  ('X_STORAGE_TOKEN'))
              ctx = context.RequestContext(user_id,
                                     project_id,
                                     user_name=user_name,
                                     project_name=project_name,
                                     roles=roles,
                                     auth_token=auth_token,

  remote_address=remote_address,

  service_catalog=service_catalog)

2.  Neutron not passed token. Also not good for the third part
  network
infrastructure to integrate the authentication with KeyStone.
class NeutronKeystoneContext(wsgi.Middleware)
.
# token not get from the header and not passed to context.
  Just
change here like what Nova/Cinder did.
        context.Context(user_id, tenant_id, roles=roles,
                              user_name=user_name,
tenant_name=tenant_name,
                              request_id=req_id)
        req.environ['neutron.context'] = ctx

I think I'd better to report a bug for your case.

Best Regards
Chaoyi Huang ( Joe Huang )
-???件原件-
???件人