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 <josephba...@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 <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 >> >> > -- Rackspace Australia
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators