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 <jamielen...@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 <skoleko...@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-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