Open Stack

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.yamahata at 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 <blak111 at 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 <joehuang at 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 [blak111 at 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.toohill at 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 <blak111 at gmail.com>
> > >> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> > >> <openstack-dev at lists.openstack.org>
> > >> Date: Friday, July 18, 2014 2:16 PM
> > >> To: "OpenStack Development Mailing List (not for usage questions)" <
> > >> openstack-dev at 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.toohill at 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" <joehuang at 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.toohill at 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 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
> > >>>
> > >>
> > >>
> > >>
> > >>  --
> > >> Kevin Benton
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >>
> > >
> > >
> > >  --
> > > Kevin Benton
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> >
> > --
> > Kevin Benton
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Isaku Yamahata <isaku.yamahata at gmail.com>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140804/04120036/attachment-0001.html>