There is also a golang library that can validate tokens.. http://gophercloud.io/docs/identity/v3/
On Thu, May 12, 2016 at 11:25 PM, David Medberry <openst...@medberry.net> wrote: > There's a jython implementation of keystone and I thought there was other > work to validate tokens from within Java. Added Jim Baker to the thread. > > -d > > On Thu, May 12, 2016 at 5:06 PM, Michael Still <mi...@stillhq.com> wrote: > >> I'm just going to reply to myself here with another status update. >> >> The design seems largely settled at this point, with one exception -- how >> does nova authenticate with the external microservice? >> >> The current proposal is to have nova use the client's keystone token to >> authenticate with the external microservice. This is a neat solution >> because its what nova does when talking to other services in your OpenStack >> deployment, so its consistent and well understood. >> >> The catch here is that it means your external microservice needs to know >> how to do keystone authentication. That's well understood for python >> microservices, and I can provide sample code for that case using the >> keystone wsgi middleware. On the other hand, its harder for things like >> Java where I'm not sure I'm aware of any keystone auth implementation. Is >> effectively requiring the microservices to be written in python a >> particular problem? I'm hoping not given that all the current plugins are >> written in python by definition. >> >> Cheers, >> Michael >> >> >> >> >> On Wed, May 4, 2016 at 7:37 AM, Michael Still <mi...@stillhq.com> wrote: >> >>> Hey, >>> >>> I just wanted to let people know that the review is progressing, but we >>> have a question. >>> >>> Do operators really need to call more than one external REST service to >>> collect vendordata? We can implement that in nova, but it would be nice to >>> reduce the complexity to only having one external REST service. If you >>> needed to call more than one service you could of course write a REST >>> service that aggregated REST services. >>> >>> Does anyone in the operator community have strong feelings either way? >>> Should nova be able to call more than one external vendordata REST service? >>> >>> Thanks, >>> Michael >>> >>> >>> >>> >>> On Sat, Apr 30, 2016 at 4:11 AM, Michael Still <mi...@stillhq.com> >>> wrote: >>> >>>> So, after a series of hallway track chats this week, I wrote this: >>>> >>>> https://review.openstack.org/#/c/310904/ >>>> >>>> Which is a proposal for how to implement vendordata in a way which >>>> would (probably) be acceptable to nova, whilst also meeting the needs of >>>> operators. I should reinforce that because this week is so hectic nova core >>>> hasn't really talked about this yet, but I am pretty sure I understand and >>>> have addressed Sean's concerns. >>>> >>>> I'd be curious as to if the proposed solution actually meets your needs. >>>> >>>> Michael >>>> >>>> >>>> >>>> >>>> On Mon, Apr 18, 2016 at 10:55 AM, Fox, Kevin M <kevin....@pnnl.gov> >>>> wrote: >>>> >>>>> We've used it too to work around the lack of instance users in nova. >>>>> Please keep it until a viable solution can be reached. >>>>> >>>>> Thanks, >>>>> Kevin >>>>> ------------------------------ >>>>> *From:* David Medberry [openst...@medberry.net] >>>>> *Sent:* Monday, April 18, 2016 7:16 AM >>>>> *To:* Ned Rhudy >>>>> *Cc:* openstack-operators@lists.openstack.org >>>>> >>>>> *Subject:* Re: [Openstack-operators] Anyone else use >>>>> vendordata_driver in nova.conf? >>>>> >>>>> Hi Ned, Jay, >>>>> >>>>> We use it also and I have to agree, it's onerous to require users to >>>>> add that functionality back in. Where was this discussed? >>>>> >>>>> On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) < >>>>> erh...@bloomberg.net> wrote: >>>>> >>>>>> Requiring users to remember to pass specific userdata through to >>>>>> their instance at every launch in order to replace functionality that >>>>>> currently works invisible to them would be a step backwards. It's an >>>>>> alternative, yes, but it's an alternative that adds burden to our users >>>>>> and >>>>>> is not one we would pursue. >>>>>> >>>>>> What is the rationale for desiring to remove this functionality? >>>>>> >>>>>> From: jaypi...@gmail.com >>>>>> Subject: Re: [Openstack-operators] Anyone else use vendordata_driver >>>>>> in nova.conf? >>>>>> >>>>>> On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote: >>>>>> > I noticed while reading through Mitaka release notes that >>>>>> > vendordata_driver has been deprecated in Mitaka >>>>>> > (https://review.openstack.org/#/c/288107/) and is slated for >>>>>> removal at >>>>>> > some point. This came as somewhat of a surprise to me - I searched >>>>>> > openstack-dev for vendordata-related subject lines going back to >>>>>> January >>>>>> > and found no discussion on the matter (IRC logs, while available on >>>>>> > eavesdrop, are not trivially searchable without a little scripting >>>>>> to >>>>>> > fetch them first, so I didn't check there yet). >>>>>> > >>>>>> > We at Bloomberg make heavy use of this particular feature to inject >>>>>> > dynamically generated JSON into the metadata service of instances; >>>>>> the >>>>>> > content of the JSON differs depending on the instance making the >>>>>> request >>>>>> > to the metadata service. The functionality that adds the contents >>>>>> of a >>>>>> > static JSON file, while remaining around, is not suitable for our >>>>>> use case. >>>>>> > >>>>>> > Please let me know if you use vendordata_driver so that I/we can >>>>>> present >>>>>> > an organized case for why this option or equivalent functionality >>>>>> needs >>>>>> > to remain around. The alternative is that we end up patching the >>>>>> > vendordata driver directly in Nova when we move to Mitaka, which I'd >>>>>> > like to avoid; as a matter of principle I would rather see more >>>>>> > classloader overrides, not fewer. >>>>>> >>>>>> Wouldn't an alternative be to use something like Chef, Puppet, >>>>>> Ansible, >>>>>> Saltstack, etc and their associated config variable storage services >>>>>> like Hiera or something similar to publish custom metadata? That way, >>>>>> all you need to pass to your instance (via userdata) is a URI or >>>>>> connection string and some auth details for your config storage >>>>>> service >>>>>> and the instance can grab whatever you need. >>>>>> >>>>>> Thoughts? >>>>>> -jay >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-operators mailing list >>>>>> OpenStack-operators@lists.openstack.org >>>>>> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-operators mailing list >>>>>> OpenStack-operators@lists.openstack.org >>>>>> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-operators mailing list >>>>> OpenStack-operators@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>>> >>>>> >>>> >>>> >>>> -- >>>> Rackspace Australia >>>> >>> >>> >>> >>> -- >>> Rackspace Australia >>> >> >> >> >> -- >> Rackspace Australia >> > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators