[openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

Rich Megginson rmeggins at redhat.com
Wed May 20 15:05:27 UTC 2015


On 05/20/2015 12:17 AM, Gilles Dubreuil wrote:
> Hi,
>
> Just wanted to add, for clarification, the need to restructure the
> openstacklib.
>
> The use of resource[:auth] parameter is causing the providers to behave
> differently depending on the context, as expressed earlier in this thread.
>
> I would to highlight the fact that this change is driven by design.
> Therefore the need for a fix, sooner than later, especially at a time of
> the entire stack of provider to shift to Keystone V3. And this is
> actually a critical time because of patches waiting upon this structural
> change.
>
> The bp/auth-consolidation (sorry for the *bad* name) patches show
> authentication doesn't have to be using parameters, the latter was a
> mistake from a types/providers suitability viewpoint.
>
> The restructure (bp/auth-consolidation) is not only working but also
> simplifies the code which is going to make the development/maintenance
> of types/providers faster.

The current proposal for puppet-openstacklib is 
https://review.openstack.org/#/c/180407/

This breaks the published API in Juno as used by puppet-keystone. For 
example, the Juno branch code:
https://github.com/stackforge/puppet-keystone/blob/stable/juno/lib/puppet/provider/openstack.rb

def request(service, action, object, credentials, *properties)

but in the new code, there is no object request method, only self.request:

defself.request(service,action,*args)

Is it ok to break this API?  I don't think anyone is actually using it, 
but I have no idea.

Doing it this way also means that the change cannot be implemented 
incrementally - all of the type/provider/spec/other code has to be 
changed at the same time in a single commit (or live with failing gate 
tests).  Is this ok?

I have been working on the Keystone v3 code for a long time, and had a 
working implementation.
Does the Puppet OpenStack community think that it is the right thing to 
do to wait for the new authentication restructuring code to be merged, 
before the Keystone v3 code is merged?


>
> If anyone has issues/questions with this please speak up!
>
> Thank you,
> Gilles
>
> On 07/05/15 11:50, Gilles Dubreuil wrote:
>>
>> On 07/05/15 11:33, Colleen Murphy wrote:
>>>
>>> On Wed, May 6, 2015 at 6:26 PM, Gilles Dubreuil <gilles at redhat.com
>>> <mailto:gilles at redhat.com>> wrote:
>>>
>>>      It seems ~/.openrc is the only default [...]
>>>
>>> The extras module places it at '/root/openrc' [1], so either the extras
>>> module should be changed or the providers should look in /root/openrc,
>>> either way it should be consistent.
>>>
>> Agreed.
>>
>> Let's use ~/openrc for now then.
>>
>>> Colleen
>>>
>>> [1] http://git.openstack.org/cgit/stackforge/puppet-openstack_extras/tree/manifests/auth_file.pp#n86
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list