puppetlabs_spec_helper recommends rspec-mocks instead of mocha[1] and
it uses rspec-mocks by default instead of mocha since v 5.0.0[2]
This is the prep work to adapt to that migration.
[1] https://github.com/puppetlabs/puppetlabs_spec_helper/#mock_with
[2] 493f0cbc1c
Closes-Bug: #2004135
Change-Id: Idfb4d8344af472aec0c6bbdd9b3600eedd17eb46
After the move to composite namevar a problem could occur if another
module was using indirection to find resource by name.
If the manifest didn't have any
keystone_user/keystone_tenant/keystone_user_role definition, then, the
'Default' domain would be appended to the name.
This patch, fix that by simplifying the rule for calculating the default
domain.
It now strictly follows what is described there https://review.openstack.org/#/c/219127/
Change-Id: Ic2efb51fe76d055307c8c27fa79015764417160b
Closes-Bug: #1517187
First, Keystone_service provider was not able to create service
different by type. So service type computev3 and compute with name nova
could not be created.
Second, on a system with such resource it would not be able to
differentiate between the two. Then if
keystone_service {'nova': type => 'compute'}
was in the catalog, then the service nova/computev3 would be changed to
nova/compute.
Now you can specify:
keystone_service {'service::type'}
or
keystone_service {'service': type => 'type'}
It keeps a full backward compatibility.
Change-Id: I24bbcf8cbf3760fd061e2439f37864ae97ce86f6
Closes-Bug: #1508886
There are two sides on this patch, the user facing one, and the
developer's one.
It gives more flexibility for the interface used by the user for the
Keystone_tenant, Keystone_user and Keystone_user_roles resources. For
instance to specify a user and give the admin role, currently you have
to:
keystone_user { 'new_admin::admin_domain':
ensure => present,
enabled => true,
tenant => 'openstackv3::admin_domain',
email => 'test@example.tld',
password => 'a_big_secret',
}
keystone_user_role { 'new_admin::admin_domain@openstackv3::admin_domain':
ensure => present,
roles => ['admin'],
}
Now you can specify it like this:
keystone_user { 'new_admin':
ensure => present,
enabled => true,
domain => 'admin_domain',
tenant => 'openstackv3::admin_domain',
email => 'test@example.tld',
password => 'a_big_secret',
}
keystone_user_role { 'new_admin@openstackv3':
ensure => present,
user_domain => 'admin_domain',
project_domain => 'admin_domain',
roles => ['admin'],
}
For the developer this simplify the code. Puppet is using composite
namevar to make all the resources unique. So guessing what pattern is
used in the title is no longer required. For instance this :
keystone_tenant { 'project_one': ensure => present }
keystone_tenant { 'meaningless': name => 'project_one', domain => 'Default', ensure => present }
is detected as the same tenant by puppet.
The same is true for dependencies. This is working correctly:
keystone_tenant { 'meaningless': name => 'project_one', domain => 'domain_one', ensure => present }
file {'/tmp/needed': ensure => present, require => Keystone_tenant['project_one::domain_one'] }
In autorequire term in type definition, you just have to pass the fully
qualified name (with the domain suffix for user and tenant) of the
resource and puppet will do the matching, whatever the original title
is. See the examples in user and tenant in keystone_user_role type.
Change-Id: I4deb27dc6f71fb7a7ec6a9c72bd0e1412c2e9a30
This patch aim to update our specs test in order to work with the
rspec-puppet release 2.0.0, in the mean time, we update rspec syntax in
order to be prepared for rspec 3.x move.
In details:
* Use shared_examples "a Puppet::Error" for puppet::error tests
* Convert 'should' keyword to 'is_expected.to' (prepare rspec 3.x)
* Fix spec tests for rspec-puppet 2.0.0
* Upgrade and pin rspec-puppet from 1.0.1 to 2.0.0
* Clean Gemfile (remove over-specificication of runtime deps of puppetlabs_spec_helper)
* Standardize gemfile (add json, webmock)
Change-Id: I35a39d4f3919d56c9448f0a0602cfe284ebc2e9c
Card: https://trello.com/c/eHXc1Ryd/4-investigate-the-necessary-change-to-be-rspec-puppet-2-0-0-compliant
Serving keystone from a wsgi container is recommended for production
setups. SSL is enabled by default.
See the following URLs for explanations:
http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/https://etherpad.openstack.org/havana-keystone-performance
Documentation in manifests/wsgi/apache.pp
Apache can be configured as a drop in replacement for keystone (using
ports 5000 & 35357) or with paths using the standard SSL port. See
examples in examples/apache_*.pp
- Also change some 'real_' prefix into '_real' suffix to respect the
coding guide.
- Added the '--insecure' option to keystone client in the provider to
allow using self-signed certificates.
- Fixed parsing the ssl/enable value in the provider.
There is no integer verification done in the manifests
and to get around a bug in rspec, which has been fixed
in https://github.com/rodjek/rspec-puppet/pull/107,
certain parameters that should be integer are treated as
strings
files/httpd/keystone.py updated with lastest from keystone git repo
Change-Id: Ide8c090d105c1ea75a14939f5e8ddb7d24ca3f1c