[openstack-dev] [keystone] [puppet] [neutron] Deprecating nova_admin_ options in puppet-neutron

[Sergey Kolekonov]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [puppet] [neutron] Deprecating nova_admin_ options in puppet-neutron

[Jamie Lennox]

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  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  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [puppet] [neutron] Deprecating nova_admin_ options in puppet-neutron

[Jamie Lennox]

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  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev