Open Stack

On re-reading the original email i've been thinking of auth_token
middleware rather than nova_admin_* options (i haven't done much
neutron config). I think everything still applies though and hopefully
this can be a mechanism that's reused across modules.

On 15 October 2015 at 10:37, Jamie Lennox <jamielennox at redhat.com> wrote:
> TL;DR: you can fairly easily convert existing puppet params into auth
> plugin format for now, but we're going to need the hash based config
> soon.
>
> I think as a first step it is a good idea to replace the deprecated
> options and use the password, v2password or v3password plugins*
> because you will need to maintain compatibility with the existing
> auth_user, auth_tenant etc options.
>
> However I would like to suggest all the puppet projects start to look
> at some way of passing around a hash of this information. We are
> currently at the stage where we have both kerberos and x509 auth_token
> middleware authentication working and IMO this will become the
> preferred deployment mechanism for service authentication in
> environments that have this infrastructure. (SAML and other auth
> mechanisms have also been proven to work here but are less likely to
> be used for service users). Note that this will not only apply to
> auth_token service users, but any service who has admin credentials
> configured in their conf file.
>
> I don't think it's necessary for puppet to validate the contents of
> these hashes, but i think it will be a loosing battle to add all the
> options required for all upcoming authentication types to each
> service.
>
> I'm not sure if this makes it easier for you or not, but for
> situations exactly like this loading auth plugins from a config file
> take an auth_section option so you can do:
>
> [keystone_authtoken]
> auth_section = my_authentication_conf
>
> [my_authentication_conf]
> auth_plugin = password
> ...
>
> and essentially dump that hash straight into config without fear of
> having them conflict with existing options. It would also let you
> share credentials if you configure for example the nova service user
> in multiple places in the same config file, you can point multiple
> locations to the same auth_section.
>
>
>
> * The difference is that password queries keystone for available
> versions and uses the discovered urls for the correct endpoint and so
> expects the auth_url to be 'http://keystone.url:5000/' v2 and v3 are
> v2 and v3 specific and so expect the URL to be of the /v2.0 or /v3
> form. Password will work with /v2.0 or /v3 urls because those
> endpoints return only the current url as part of discovery and so it
> is preferred. For the smallest possible change v2password is closer to
> what the old options provide but then you'll have a bigger step to get
> to v3 auth - which we want fast.
>
> On 14 October 2015 at 22:20, Sergey Kolekonov <skolekonov at mirantis.com> wrote:
>> Hi folks,
>>
>> Currently puppet-neutron module sets nova_admin_* options in neutron.conf
>> which are deprecated since Kilo release. I propose to replace them, but we
>> need to discuss how to do it better. I raised this question at
>> puppet-openstack weekly meeting yesterday [0]. So the main concern here is
>> that we need to switch to Keystone auth plugins to get rid of these options
>> [1] [2], but there's a possibility to create a custom plugin, so all
>> required parameters are unknown in general case.
>>
>> It seems reasonable to support only basic plugin (password), or also token
>> as the most common cases, otherwise an ability to pass all required
>> parameters as a hash should be added. which looks like a bit overkill.
>>
>> What do you think?
>>
>> Thanks.
>>
>> [0]
>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-13-15.00.log.html
>> [1] https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L783
>> [2]
>> http://docs.openstack.org/developer/python-keystoneclient/authentication-plugins.html
>> --
>> Regards,
>> Sergey Kolekonov
>>
>> __________________________________________________________________________
>> 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
>>