Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160512/2f61db46/attachment.html>