Open Stack

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 <openstack at 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 <mikal at 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 <mikal at 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 <mikal at 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.Fox at 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 [openstack at medberry.net]
>>>>> *Sent:* Monday, April 18, 2016 7:16 AM
>>>>> *To:* Ned Rhudy
>>>>> *Cc:* openstack-operators at 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) <
>>>>> erhudy at 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: jaypipes at 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 at lists.openstack.org
>>>>>>
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-operators mailing list
>>>>>> OpenStack-operators at lists.openstack.org
>>>>>>
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160513/e81d9ecf/attachment.html>