Open Stack

Just an update on this work.

The punch line is that I think this code is unlikely to land in Newton. It
has until Wednesday to be finalized, and I don't see that happening in
time. That said, I'm still _trying_ to land it.

The current sticking point is that nova-core doesn't want to pass
system-metadata to plugins, as the internal format of that changes between
releases and isn't intended to be versioned. Instead, we want to pass just
the specific bits people need.

So -- what things are you using from system-metadata specifically?

Michael




On Fri, May 13, 2016 at 10:15 PM, Joseph Bajin <josephbajin at gmail.com>
wrote:

> 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
>>
>>
>


-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160712/c77a2712/attachment.html>