This patch is the initial modulesync run, it impacts:
* gitignore: just a sync between projects
* gemfile:
- update and allow to setup facter version and gem source
- split beaker gems with a dedicated group
- switch to rspec-puppet 2.2.0
* rakefile:
- use the new syntax for lint configuration
- add a acceptance target
* acceptance:
- sync nodesets
* spec: added rspec coverage report
Change-Id: Ibfd9b9bc31620a46cb3c7e438f023cab1cfcd31f
Before, when running the Exec which restart Keystone service, we used
$service_name but this is wrong because service_name can be keystone,
openstack-keystone or httpd.
On Ubuntu/Debian, Apache service name is not httpd but apache2.
So the service could never be restarted if we were 1/ running
Ubuntu/Debian 2/ changing the default domain name.
This patch looks up in puppetlabs-apache the real Apache service name
when $service_name is httpd (if WSGI is enabled and eventlet disabled).
That way, we are sure the service name that will be used will the right
one.
Also add some unit tests that validate this change.
Change-Id: I85226d862b63e227867ed43bc35d7fefc9e424cd
Closes-bug: #1479783
Allow to set the same domain name for admin_user_domain and
admin_project_domain.
Due to a logic issue, it was not possible until this patch.
Change-Id: If8a29290271142bb3ac254ed8e504047abc87153
Closes-bug: #1474049
When using Keystone v3 and domains, we need to make sure the default
domain (if its name if not 'Default') is created before any other
domain scoped resource.
By creating a new anchor, we can add the requirement in Keystone types
that need this dependency.
If the default domain name is not modified, the Anchor won't be in the
catalog but it's not an issue when using 'autorequire' in Puppet types.
This patch also change the default domains in acceptance tests, so we
can actually test the feature and make sure resources are created after
having the default domain created.
Change-Id: I2870eaa98f816c92df901ed2fa92e8db89b67656
Closes-bug: #1478037
In order to be able to take an action after all the packages of the
module have been installed/updated or all the services have been
started/restarted, we set a 'keystone-package' and 'keyston-service'
tag for each package and service of this module.
At the moment, there is a generic openstack tag that is not specific
enough if one wants to take action upon a single module change.
Use case :
If an action needs to be taken after all the packages have been
installed or updated : Package <| tag == 'keystone-package' |> -> X
Change-Id: I2de6880ba14ccd07b5d4c1928ddcde821bc9625d
The actual README.md file contains two invalid urls:
1- Section Module Description, wrong url in openstack module
2- Section Setup/Beginning with keystone, wrong url in first openstack module
Change-Id: Ica703f33eba159472dca2aecb0f8b486aa2b5233
- Convert 'should' keyword to 'is_expected.to'
- The old ':should' syntax in rspec 3.x is deprecated in favor of
':expect' syntax.
- Operator matchers:
'1.should == 1' into 'expect(1).to eq(1)'
Change-Id: I84b993065a00f5b5c55bd6834c6d54bc57c249e0
Signed-off-by: Gael Chamoulaud <gchamoul@redhat.com>
Running keystone via eventlet is deprecated as of Kilo in favor of
running in a WSGI server (e.g. mod_wsgi).
Support for keystone under eventlet will be removed in the "M"-Release.
This patch test an upgrade between eventlet to wsgi.
In the future, the eventlet test will be dropped in favor of wsgi which
will be default.
Change-Id: Ieb07473725fbd51aac45e90c9aac1e819b944ee0
Today, Keystone resources (domains, tenants, etc) are created only if
'keystone' service is started.
When running Keystone in WSGI, the autorequire is broken for those
resources.
Adding 'httpd' in autorequire is not enough because it could fail to
orchestration issues if running another httpd resource (Horizon) that
depends on having Keystone started.
This patch is about to create an Anchor (keystone_started) in
keystone::service that require Service['keystone'] resource to be
created.
In resource types, change the autorequire to depend on the new Anchor.
With that patch, we are sure Keystone resources won't be created before
service is actually managed (running or stopped) and other resources
(Horizon, using httpd server) can also depend on this Anchor if needed.
Change-Id: Ie72b65b6be224cadc8730e050bec38d2face5dfd
Closes-bug: #1474059
Kilo oslo.messaging added heartbeating support for RabbitMQ
connections. This patch adds support for this in Puppet modules
by managing the oslo_messaging_rabbit/heartbeat_timeout_threshold
and oslo_messaging_rabbit/heartbeat_rate settings.
Also, update all rabbit-related parameters to move to the
oslo_messaging_rabbit section in keystone.conf, from the DEFAULT
section.
Change-Id: I4d78a3c67396744fe1f643b857d889cb0ee0ca49
Closes-bug: 1467667
This patch implements these parts of the blueprint:
1) Adds an example of a manifest that uses domains.
Adds an example of how to test that v3 authentication is working using
ruby and curl.
Change-Id: I1354c6aeb0f4c25daadc3b7e04bbe4b067f11e03
Implements: blueprint api-v3-support
Adapt functional tests to validate Keystone v3 resources are well
created and managed by the blueprint.
Change-Id: Idbfaa2d2260dedaf21ebb029c18cd1001c27fc4d
Implements: blueprint api-v3-support
This patch implements these parts of the blueprint:
1) Adds support for domains to keystone::endpoint
Users of this resource may specify a different domain for both the user
and the tenant/project, or may specify the default domain which will apply
to both user and tenant.
Change-Id: Ife47a7627a8a4138b022a1cbb1d42f256e5a6c63
Implements: blueprint api-v3-support
This patch implements these parts of the blueprint:
1) Adds support for domains to service_identity.
Users of this resource may specify a different domain for both the user
and the tenant/project, or may specify the default domain which will apply
to both user and tenant.
Change-Id: I4715464ce37dbd287a2700b8cf05705b7d307b50
Implements: blueprint api-v3-support
This patch implements these parts of the blueprint:
1) Adds a new resource keystone::resource::authtoken - this manages
keystone authentication for other puppet modules by managing the
[keystone_authtoken] section in the config. Encapsulating the
authentication configuration in this resource will ensure that we
will be able to support the several new types of authentication coming
in current and future Keystone releases. This supports all of the
authentication options specified at:
http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/
The username and project_name can be passed in with domain, as
"username::domainname" or "project::domainname". The resource will strip
off the domain part and use it for the user_domain_name or
project_domain_name if no other domain is specified.
Implements: blueprint api-v3-support
Change-Id: Ib37f11ae5949e6add10041c108a92fd3de553557
This patch implements these parts of the blueprint:
1) Allows user to specify the default domain
If the user specifies a domain other than 'Default', class keystone
will create that domain, and write the id of the domain to the
[identity] default_domain_id parameter in keystone.conf, using the
keystone_domain { is_default => true } resource.
2) Allows user to specify a separate service domain for service accounts
One of the use cases for v3 is the ability to have the service account
keystone_user resources (e.g. glance, cinder, etc.) to be in a separate
domain from the regular user accounts. keystone::roles::admin allows
to specify this domain.
Implements: blueprint api-v3-support
Change-Id: I3c69ee343e4335f4ce86cd72d6a9e664f7abcf25
Implements: blueprint api-v3-support
This patch implements these parts of the blueprint:
1) Implements the domain aware keystone_user_role resource.
With Keystone v3, you can assign a role to a user on a domain
or a project/tenant. e.g.
assign role 'admin' to user 'admin' for domain 'services'
assign role 'admin' to user 'admin' for project 'services'
That is, domain and project are mutually exclusive - you cannot
assign a role for both a domain and a project at the same time.
Accepts a 'username@thing' name/title in the following formats::
username@project
username::userdomain@::domain
username::userdomain@project::projectdomain
username::userdomain@project
et. al. other combinations. Use the @::domain to assign a role
for a domain. Use the short names wherever possible, when you are
absolutely sure that there is only 1 user or project with the given
name. For example, if you are absolutely sure that there is only 1
user named 'glance' in all domains, and only 1 project named 'services'
in all domains, you can use 'glance@services' as the user role name.
Otherwise, you will have to use the domain qualifier ::domain to
distinguish 'glance::domain1' from 'glance::domain2'.
Note that the user id and project id must be used when assigning
a role for a user for a project for the role add and role delete
commands, which is why #create, #destroy, and #roles= have to look
up the user and project ids (via the convenience #properties method).
Change-Id: I70fad491096d4ad876634aac173cd4e321274d65
Keystone no longer supports tenant/project as a property of user
entries and is deprecating it, so we will also deprecate it.
Change-Id: I1827724a484eb62c3fc2f4411429b45eac4e6f25
Closes-bug: 1472437
Implements: blueprint api-v3-support
This patch implements these parts of the blueprint:
1) Implements the domain aware keystone_user resource.
Adds support for a :domain property of a user, and allows
the domain to be specified as "name::domain" in the :name property.
The new code tries to use the id as much as possible, since it is
the id that uniquely identifies the user among all of
the domains, and using id means that name + domain are not required.
The use of openstack project and role has changed somewhat because
the command line arguments and output are different in v3.
openstack user create --project $project does _not_ add the user
as a member of $project, so that must be done explicitly in
keystone_user.create in order not to break existing manifests that
expect that behavior.
Change-Id: Ie64e03705fa861d3ba5b91b79574a943841319a8
This patch implements these parts of the blueprint:
1) Implements the domain aware keystone_tenant (project) resource.
Adds support for a :domain property of a tenant/project, and allows
the domain to be specified as "name::domain" in the :name property.
The new code tries to use the id as much as possible, since it is
the id that uniquely identifies the project/tenant among all of
the domains, and using id means that name + domain are not required.
Implements: blueprint api-v3-support
Change-Id: I1f703affa6172a3e759e2d62422a87073262acc4
This patch implements these parts of the blueprint:
1) Implements the keystone_domain resource. Domain creation/ensure
has a couple of special cases:
a) When creating a domain that is going to be the default domain,
we need to write the id of that domain to the keystone.conf file
in the [identity] default_domain_id parameter. Since there is no
way to get that id at the puppet level, we have to use the ruby code
to ensure that the parameter has the correct domain id in the
keystone.conf file. Likewise, when removing the default domain,
ensure that we reset the [identity] default_domain_id parameter to
its default value.
b) When deleting a domain, have to disable it first. Keystone does not
allow you to delete an enabled domain.
Implements: blueprint api-v3-support
Change-Id: Idc88fb22de8a9a9c8b1f6dfef8ae018190f254e1
This patch implements these parts of the blueprint:
1) Adds some utility code for domain handling. Puppet code may need
to specify resource titles as "name::domain" e.g. "admin::admin_domain".
The function split_domain is used to split a name in this format into
its ['name', 'domain'] components as an array.
Usually providers will not need to use this, they will use the
name_and_domain method in the keystone.rb provider. This is resource
aware and will try many different ways to get a domain to use for
the provider: resource[:domain], then the domain part of
'name::domain' name/title value.
If keystone.conf is available, it will use [identity]
default_domain_id as the default domain id, and look up the domain
name using the 'domain list' operation to create a mapping.
If all else fails, the domain name will be 'Default' which is the
"default" default domain name used by Keystone.
2) Adds the method domain_name_from_id - the providers and other code
will need to map from the domain id to the name, and this method
provides that mapping.
Implements: blueprint api-v3-support
Change-Id: Ifb8171b78904257f8112e1485d5255f0d0f5aca8
Depends-On: Icafc4cb8ed000fd9d3ed6ffde2afe1a1250d90af
This patch implements these parts of the blueprint:
1) Use v3 api for the keystone_role resource
Implements: blueprint api-v3-support
Change-Id: I055c8c95a1fcfe31ad06ec8fa98342d45a4f870d
Zuul-cloner's behavior is to clone the repository into a subdirectory
under a directory named for the repo namespace. Git's default behavior
is to just clone it directly into the present working directory. This
patch adds an argument to the git clone command to clone it into the
<namespace>/<repo name> directory, so that whether zuul-cloner or git
is used the repo ends up in the same directory relative to the PWD.
Change-Id: Ie3a7a1a483db59f8fe3b9d380130084f7a0ea43d
The final check during the prep stage, where `puppet module list` is
run so that its output can be used for debugging, should run on the
current host in the loop, not the first host in the array.
Change-Id: I664f50fd323cfc0e3828f4198d10ff4a1b50b8b2
- Uses _type_, not the _name_ for resource creation
- Destroy and update (set) now uses resource ID rather its name.
- Offers backward compatibility for type/provider API as much as possible.
Depends-On: Icafc4cb8ed000fd9d3ed6ffde2afe1a1250d90af
Implements: blueprint api-v3-support
Change-Id: I62553ea8406d7a197d0f5f94d302f564077225c8
Since the postgresql module is already installed on nodepool nodes,
r10k it isn't properly purging it before installing our modules to test
with. Let's not trust r10k to do this, let's do it ourselves.
Change-Id: If54a2caeaa58b419610fc558271c436ddce91cfb
This patch updates the spec_helper_acceptance.rb file to use the common
module install script and Puppetfile from the new
openstack/puppet-openstack-integration repo. This will allow us to take
advantage of Zuul's Depends-On feature so that we can test changes
across multiple related modules. This is based on idea 1 from this
brainstorming session[1].
Removes the purging of the modules directory since r10k does that for
us.
This will probably be abstracted out into a separate function or
eventually a separate gem so that it can be more easily shared across
the OpenStack modules and the Infra modules.
[1] https://etherpad.openstack.org/p/puppet-git-dependencies
Co-Authored-By: James E. Blair <jeblair@hp.com>
Co-Authored-By: Spencer Krum <spencer.krum@hp.com>
Change-Id: I0f63df75fd1a206af7452b239840fd466e6ec080
Depends-On: Ide59ef4bdf53a04957e3593815b7514a0e744e0e
When running with BEAKER_provision=no, the following happens:
In Trusty: beaker is running dpkg with '--force' option so even
if Puppet is already installed, the return code will be 0.
In CentOS: beaker is running 'rpm -ivh' the second time and since
the package is already here, the return code will be 1.
Using the new puppet install helper will abort installing puppet
if BEAKER_provision is no, so tests will continue as normal.
Change-Id: I6ccf9c8e1eb9e99838c37ab531e6d0d44da6371b
Co-Authored-By: Colleen Murphy <colleen@gazlene.net>
* Modify default endpoints to use 127.0.0.1 instead of FQDN that might
not be resolvable all the time.
* Drop HTTPS from default endpoints (SSL is not configured).
* Add serverspec tests to validate Keystone resources.
Change-Id: I2e8e5bc9a4969e75eca4912a0c459e8576164f24
Since SELinux is enforced by default, we need to make sure
openstack-selinux is installed from the latest version to have OpenStack
correctly working.
Change-Id: Ica56296f0dd3b64d267a33792eef8a48e8d03e9e
This patch splits out release notes into a separate dedicated file for
consistency with the puppetlabs puppet modules. Additionally, this
patch improves the release notes by:
- Fixing the tense to be consistent with commit message standards ("Add
new feature" instead of "Added new feature" or "Adds new feature")
- Breaking up changes into categories to make it easier for operators
to know what happened in the change: backwards-incompatible changes,
features, bugfixes, and maintenance commits
- Linewrapping to 80 chars
- Adding release dates, formatted according to ISO-8601
- Removed bugfixes notes related to added features in that release
Change-Id: If4a566c1638e4fbeec9129f3b340706ad132b9c0
Install packages from RDO properly, by using regular packages and not
ones from testing repo that are too unstable.
Change-Id: I923e2385499e84d46fa8eb8df08e3baabf64b01d