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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 [[email protected]] >>>> *Sent:* Monday, April 18, 2016 7:16 AM >>>> *To:* Ned Rhudy >>>> *Cc:* [email protected] >>>> >>>> *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) < >>>> [email protected]> 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: [email protected] >>>>> 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 >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-operators mailing list >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-operators mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>> >>>> >>> >>> >>> -- >>> Rackspace Australia >>> >> >> >> >> -- >> Rackspace Australia >> > > > > -- > Rackspace Australia >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
