[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