Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
This sets the flag create_domain_entry for the ldap_backend resource,
which will create the domain for the ldap backend (this was previously
not the case since only the configuration was created). Furtherly, this
flag will also refresh the keystone server, so the changes come into
effect.
Note that this is only done in step 3, so the domains are created there
and the refresh happens in that step. Also, this is only done for the
bootstrap node, since when the other nodes start, they will already have
the domains available in the keystone database and there won't be a need
to restart.
Related-Bug: #1677603
Depends-On: Ib6c633b6a975e4b760c10a2aef3c252885b05e28
Change-Id: Id879cf5c5ae39d37bf58b73c78733001d2b03d9c
|
|
This patch adds the appropriate include to make sure that appropriate
keystone user, services, etc. are created when octavia is selected.
Closes-bug: #1680588
Change-Id: I0b6d657a0300538292223923d8808c23f936c193
|
|
Ldap_backend is a define so we need a resource to talk it. If
ldap_backend_enable set by tripleo-heat-templates, we call the
ldap_backend as a resource.
Given an environment such as the following:
parameter_defaults:
KeystoneLdapDomainEnable: true
KeystoneLDAPBackendConfigs:
tripleoldap:
url: ldap://192.0.2.250
user: cn=openstack,ou=Users,dc=redhat,dc=example,dc=com
password: Secrete
suffix: dc=redhat,dc=example,dc=com
user_tree_dn: ou=Users,dc=redhat,dc=example,dc=com
user_filter: "(memberOf=cn=OSuser,ou=Groups,dc=redhat,dc=example,dc=com)"
user_objectclass: person
user_id_attribute: cn
user_allow_create: false
user_allow_update: false
user_allow_delete: false
ControllerExtraConfig:
nova::keystone::authtoken::auth_version: v3
cinder::keystone::authtoken::auth_version: v3
It would then create a domain called tripleoldap with an LDAP
configuration as defined by the hash. The parameters from the
hash are defined by the keystone::ldap_backend resource in
puppet-keystone.
More backends can be added as more entries to that hash.
Partial-Bug: 1677603
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Co-Authored-By: Guillaume Coré <gucore@redhat.com>
Signed-off-by: Cyril Lopez <cylopez@redhat.com>
Change-Id: I1593c6a33ed1a0ea51feda9dfb6e1690eaeac5db
|
|
Ceilometer user is needed for other ceilometer services to
authenticate with keystone even when API is not present.
So the data can be dispatched to gnocchi. Lets keep these
separate so user always exists even when api is not.
Depends-On: Iffebd40752eafb1d30b5962da8b5624fb9df7d48
Closes-bug: #1677354
Change-Id: I8f4e543a7cef5e50a35a191fe20e276d518daf20
|
|
|
|
This is now the job of the certmonger_user profile. So these bits are
not needed anymore in the service profiles.
Change-Id: Iaa3137d7d13d5e707f587d3905a5a32598c08800
Depends-On: Ibf58dfd7d783090e927de6629e487f968f7e05b6
|
|
This commit conditionally includes messaging amqp class for the
oslo.messaging AMQP 1.0 driver to support notifications.
This patch:
* include keystone::messaging::amqp class for oslo_messaging_amqp opts
Change-Id: I8eb23a21d2499795c3a76ae3197bda7773165a8c
|
|
|
|
os_transport_url was updated to allow receiving
a string or an integer as parameter.
Fixes the workarounds in puppet-tripleo
Change-Id: I50993514048bf96b5a42b3425a7d6f98778fe694
Depends-On: I9e56f8e2de542b20fe9e6995506cff5bb435e220
|
|
This includes a new ironic-inspector profile, and updates
to the mysql and keystone profiles so that a database
and endpoints are also created when the inspector
is enabled.
Change-Id: I4a71a95efb87a10528df0600277768969a32117b
|
|
This commit adds the transport_url for specifying the oslo.messaging
rpc and notify transport schemes. The rpc or notification backend
can be one of rabbit, amqp, zmq, etc. Oslo.messaging is deprecating
the host, port and auth configuration options. All drivers will
get the options via the transport_url.
This patch:
* Adds transport_url to base services
* Updates the corresponding specs
* Adds to default hierdata
Depends-On: I1cf93d2caebfa1f7373c16754a2ad9bd15eb1a40
Change-Id: Iea5607dbb3ee6b1dd50acc1395de52dc920aa915
|
|
1. Manage Keystone resources only at step 3. Don't verify them
at step 4 and 5, it's a huge loss of time.
2. Don't require Keystone resources for Gnocchi services, they are
already ready at Step 5.
Related-Bug: #1664418
Change-Id: I9879718a1a86b862e5eb97e6f938533c96c9f5c8
|
|
We need to run nova-cell_v2-discover_hosts at the very end of the
deployment because nova database needs to be aware of all registred
compute hosts.
1. Move keystone resources management at step 3.
2. Move nova-compute service at step 4.
3. Move nova-placement-api at step 3.
5. Run nova-cell_v2-discover_hosts at step 5 on one nova-api node.
6. Run neutron-ovs-agent at step 5 to avoid racy deployments where
it starts before neutron-server when doing HA deployments.
With that change, we expect Nova aware of all compute services deployed
in TripleO during an initial deployment.
Depends-On: If943157b2b4afeb640919e77ef0214518e13ee15
Change-Id: I6f2df2a83a248fb5dc21c2bd56029eb45b66ceae
Related-Bug: #1663273
Related-Bug: #1663458
|
|
1. Move keystone resources management at step 4.
2. Move nova-compute startup at step 5.
That way, we make sure nova-compute will start when all Keystone
resources are ready.
Change-Id: I6e153e11b8519254d2a67b9142bf774a25bce69d
Closes-Bug: #1663273
|
|
Change-Id: Ic74ccd5fa7b3b04ca810416e5160463252f17474
Signed-off-by: Dan Radez <dradez@redhat.com>
|
|
Change-Id: I3d6bbc05644e840395f87333ec80e3b844f69903
|
|
Change-Id: If4b091e1ca02f43aa9c65392baf8ceea007b7cfb
|
|
Allow TripleO to deploy Nova Placement API with a new profile.
Change-Id: I5e25a50f3d7a9b39f4146a61cb528963ee09e90c
|
|
This replaces the services' IP-based RabbitMQ configuration and uses
FQDNs instead.
Change-Id: I2be81aecacf50839a029533247981f5edf59cb7f
|
|
|
|
Change-Id: I035c26e0f50e4b3fc0f6085fa5a4bf524e4852b7
|
|
These are now passed via the heat profiles in t-h-t (via
heat-base.yaml and heat-engine.yaml) and use the actual names of
keystone parameters instead.
Change-Id: Id0f5dd03b6757df989339c93b58a5b7eac3402a2
Depends-On: I0e5124d57fdc519262fdec2dbeaaac85afaeebdf
|
|
Change-Id: I35f283bdf8dd0ed979c65633724f0464695130a4
|
|
This patch changes the rabbit_hosts config generation to work properly
with IPv6 addresses.
Closes-Bug: #1639881
Change-Id: I07cd983880a4a75a051e081dcb96134cb5c6f5e8
|
|
Rather than use the heat::keystone::domain class which also includes the
configuration options, we should just create the user for heat in
keystone independently of the configuration.
Change-Id: I7d42d04ef0c53dc1e62d684d8edacfed9fd28fbe
Related-Bug: #1638350
Closes-Bug: #1638626
|
|
|
|
|
|
This optionally enables TLS for keystone in the internal network.
If internal TLS is enabled, each node that is serving the keystone
service will use certmonger to request its certificate.
This, in turn should also configure a command that should be ran when
the certificate is refreshed (which requires the service to be
restarted).
bp tls-via-certmonger
Change-Id: I303f6cf47859284785c0cdc65284a7eb89a4e039
|
|
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Change-Id: If2804b469eb3ee08f3f194c7dd3290d23a245a7a
|
|
We use the rabbit_hosts configuration for most of our services but we
haven't been adding the configured port. This patch appends the IP port
used provided to the service's heat template to the IPs in the list.
Note: while we could use the value set for the rabbitmq server in
rabbitmq::port, it doesn't allow for dealing with SSL. This also is also
backwards compatible with the RabbitClientPort parameters used in the
heat templates.
Change-Id: I0000f039144a6b0e98c0a148dc69324f60db3d8b
Closes-Bug: #1633580
|
|
Change-Id: Ie215289a7be681a2b1aa5495d3f965c005d62f52
Depends-On: Ia863b38bbac1aceabe6b7deb6939c9db693ff16d
|
|
This needs to happen on the node running keystone, or things break
when you try to deploy e.g the heat_engine service on a non Controller
role. We check the enabled flag for heat engine so this only happens
if the heat_engine service is running on some (any) role.
Partial-Bug: #1631130
Change-Id: Ib088a572b384b479f51d56555734d78ab840a1f3
|
|
This patch moves the various DB syncs into the MySQL role.
Database creation needs to occur on the MySQL server to
avoid permission issues.
This patch also moves database creation to step 2 so we can
guarantee that all per-service databases exist at this time.
This avoids complex ordering needed during step 3 where
services, on different hosts, can run their own db sync's
in a distributed fashion.
Change-Id: I05cc0afa9373429a3197c194c3e8f784ae96de5f
Partial-bug: #1620595
|
|
|
|
Instead of hard-coded yaml aliases in t-h-t, make each service
profile that requires rabbit default to the list of rabbit ips.
Note this could still be extended in future to e.g enable per
service rabbit clusters, but the default is to lookup the
hiera which should be logically equivalent to current t-h-t.
Change-Id: Ie53c93456529420588eb1927703ea91b54095d87
Partially-Implements: blueprint custom-roles
|
|
Shares the same (ssl)port with Swift Proxy
Change-Id: I2e1de1a3fa6ad62895a1e972e43858f23c08bbea
|
|
|
|
The new tripleo::profile::base::ui profile installs the
openstack-tripleo-ui RPM package and setup CORS for required services.
Change-Id: Ib9d8643da3f51171495fcb8b64d1a7ca86cd66bc
|
|
This commit enables the configuration of the service users and
keystone endpoints in the keystone profile. Since with the
composable services work, we can't assure that the APIs will be in
the same node as keystone, this needs to be done from the keystone
profile.
Depends-On: I62273f403838893602816204d9bc50d516c0057f
Change-Id: I36e1c478e7c92be61da6a0d710e9025d4d354072
|
|
As we are staring to manually check overcloud services
the first step is to check that the puppet profiles
are all aligned.
Changes applied:
No logic added or removed in this submission.
Removed unused parameters.
Align header comments structure.
All profiles parameters sorted following:
"Mandatory params first sorted alphabetically
then optional params sorted alphabetically."
Note: Following submissions will check pacemaker,
cinder, mistral and redis services in the base profiles
as some of them has the $pacemaker_master parameter
defaulted to true.
Change-Id: I2f91c3f6baa33f74b5625789eec83233179a9655
|
|
We don't currently offer any parameter interface to enable
PKI certs, and these have all been deprecated by keystone, so
remove them.
Change-Id: I8232262b928c91dcde7bea2f23fa2a7c2660719e
|
|
In the Next Generation HA architecture a number of active/active services
will be run via systemd. In order for this to work we need to make sure that
the sync_db operation only takes place on the bootstrap node, just like it is
done today for the pacemaker profiles.
We do this by removing sync_db as a parameter and instead set it to true
or false depending if the hostname matches the bootstrap_node as it is done
today in the pacemaker role.
Note that we call hiera('bootstrap_nodeid', undef) because if a profile
is included on a non controller node that variable will be undefined.
The following testing was done:
- HA puppet-pacemaker.yaml scenario with three computes
- NonHA with one controller
- NonHA with three controllers
Fixes-Bug: 1600149
Co-Author: cmsj@tenshu.net
Change-Id: I04a7b9e3c18627ea512000a34357acb7f27d6e0e
Implements: blueprint ha-lightweight-architecture
|
|
Before, we had bootstrap_master set to 'undef' by default that was
used to whether or not run keystone bootstrap exec during deployment.
Setting the value to undef was a mistake, because enable_bootstrap in
puppet-keystone is set to true by default, so bootstrap was running
on all controllers at step 4 for HA scenario, while we want it to run on
a single controller (pacemaker_master) at step 4, like we do for
db-sync.
This patch:
* removes bootstrap_master.
* re-use sync_db to whether or not run keystone bootstrap.
so it will only run on a single node when database is ready and
db-sync done (orchestration dones by anchors in puppet-keystone).
Change-Id: I1042862f7c346d1c358b908c33eae0f33afd5e9f
|
|
|
|
Since keystone is being run under apache, the signing keys should notify
apache and not the keystone service. The keystone service is actually
disabled, so if the keys get updated nothing happens.
Change-Id: Idfebeabf03d010956569c32b24437245e2b93c2a
Related-Bug: #1581591
|
|
These can be controlled via the specific Pacemaker role template.
Depends-On: I91a4267f0fc230f63df3333747d28463c7ae55fe
Change-Id: I8ef7bb94e048b998712b3534ceb51a7d10d016e9
|
|
Before the roles we could make the create db operation depend on a
'galera-ready' resource [1]. We can't do it anymore from the role so
we need to do create in step 3, when we do sync as well.
1. https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/manifests/overcloud_controller_pacemaker.pp#L382
Change-Id: Id065a9180f1f1a41ab225ec5f755498ec7d9a827
|
|
This change moves the database creation and sync with the role
profile, so that it's only executed when the role is enabled and
by the role itself.
It also calls the non-pacemaker profiles out of the 'step'
conditional because the non-pacemaker profiles know how to deal with
'step' already.
Change-Id: I6c752cb53090e7ef8e0319bade462f2453ed7660
Related-Bug: 1572952
|