Age | Commit message (Collapse) | Author | Files | Lines |
|
Depends-On: Ice921f0fdd4bec6de50e62c39c447ee40dc0e8f5
Change-Id: I4109ac83c32ee2365695611009579a8b117134ff
|
|
Depends-On: I53b156505e08625d56ed6a302cf5b5c30e8e288c
Change-Id: Id9791d8a19a74c1f0855e794170f66542f88a548
|
|
|
|
|
|
|
|
|
|
It turns out the puppet-mistral change this depends on broke
introspection, so we need to back it out for now.
This reverts commit ed029e5bf279945e82bff8766af4093856a7ac6a.
Change-Id: I828478267935cdc68aa24de8c9dc2d12fcadb631
|
|
|
|
|
|
We can't run this during the upgrade steps, because there are things
which need to happen before any role configuration happens, e.g
installing the new hiera heat-config hook, which must be done before
e.g "ControllerDeployment" runs or the stack update hangs.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I365b57513590662c3f78a33dc625747f457c48c5
|
|
|
|
|
|
We could already pass metadata to the nova server instances (on
creation) via the ServerMetadata parameter, however, there was no
way of doing this per-role. This introduces that by adding a
{{role}}ServerMetadata parameter for each role. This parameter gets
merged with the ServerMetadata parameter and allows this
functionality.
Note that both default to {}, and so does the result of merging those
parameters with their default values. So nothing changes for the
default settings.
Change-Id: I334edcc51ce7ee82fc13b6cf4c0d74ccb7db099c
|
|
The RabbitMQ's puppet manifest configures the node's IP and port through
environment variables. While this would usually be fine, it doesn't
allow us to use TLS-only, since it will always try to start a TCP
listener. So, by setting these values through the config file, when
setting ssl_only for rabbitmq, they will effectively be discarded and
thus allow us to use an SSL listener on the same port.
Change-Id: I33d051a8c740baf69b99517378e1f9b0f3cc1681
|
|
This reads makes Django take the X-Forwarded-Proto header into account
when forming URLs.
Change-Id: Ice64de9a11d7819ae7f380279ff356342d9b6673
Depends-On: Ifed7d4c3409419c01c5b20c707221c1fc76ea09e
|
|
The upstream puppet module is adding the proper keystone authtoken
middleware support. This change updates THT to use the keystone
authtoken class rather than the deprecated settings. This also allows
for proper keystone v3 integration.
Change-Id: Iaf82716122a25e3e0785de1250d24edaaa5e4d04
Depends-On: I71969ef09018f9daa5f81c4f3bcbdb0b0974446c
|
|
Change-Id: I75815a4bcbf421597abb86226238b74a9afffc0d
Depends-On: Iffb8c2cfed53d8b29e777c35cee44921194239e9
|
|
This is based on previous work [1] and it's what I've been using to
test the TLS-everywhere work.
This introduces a template that will run on every node to enroll
them to FreeIPA and acquire a ticket (authenticate) in order to be
able to request certificates.
Enrollment is done via the ipa-client-install command and it does
the following:
* Get FreeIPA's CA certificate and trust it.
* Authenticate to FreeIPA using an OTP and get a kerberos keytab.
* Set up several configurations that are needed for FreeIPA (sssd,
kerberos, certmonger)
The keytab is then used to authenticate and get an actual TGT
(Ticket-Granting-Ticket) from Kerberos
The previous implementation used a PreConfig hook, however, here it
was modified to use NodeTLSCAData. This has the advantage that it
runs on every node as opposed to the PreConfig hook where we had to
specify the role type so it's a usability improvement. And, on the
other hand, this does set up necessary things for the usage of
FreeIPA as a CA, such as getting the certificate and enrolling to the
CA.
[1] https://github.com/JAORMX/freeipa-tripleo-incubator
bp tls-via-certmonger
Change-Id: Iac94b3b047dca1bcabd464ea8eed6f1220c844f1
|
|
example for
- NeutronSriovNumVFs
- NeutronPhysicalDevMappings
as given, causes parsing error.
Change-Id: I71fb42f10dac70afa02244cd6629b3439f418d63
Closes-Bug: #1648351
|
|
|
|
Change-Id: I299f8f33b0bac40d331084df37f690dc2a279677
|
|
It's no longer available in Neutron (removed in Mitaka). See:
I2a879213c3b095a007a4531f430a33cea9fdf1bd
Change-Id: I044c648eb8c4933667b8ea2c9159a30e5ebb7df3
|
|
We now fetch the name argument from the correctly named SwiftStorage
object.
Change-Id: I885505eadfc778ab57793c97af4d1c6739ec9614
Closes-Bug: #1647716
|
|
|
|
|
|
|
|
|
|
The script tries to download all artifact URLs with a single
request, instead of downloading each URL on its own if
multiple DeployArtifactURLs were given.
Change-Id: I6a8be699aff7023a67702bb1d3ddc2273984cd08
|
|
This seems to have broken the updates job, causing it to fail
with following error:
Can't set long node name!\nPlease check your configuration\n
Related-Bug: 1646873
This reverts commit 3e9fcfd09320ace07bc1bd4cb57feb98cd057332.
Change-Id: I72ba891cd9cd8c4f1bc204144f46aaabbdfd3647
|
|
|
|
There were several instances where the short-names/FQDNs where being
gotten in the same way in the role's templates. So this introduces a
mapping to get these values in order to reduce clutter.
Change-Id: Ie7df360bb69d56655f3e0fcbbf4d297db39b7a26
|
|
|
|
|
|
|
|
'user' is required or puppet-ceph will complain that the Keystone_user
has no title:
Evaluation Error: Missing title. The title expression resulted in undef
at /etc/puppet/modules/ceph/manifests/rgw/keystone/auth.pp
The value is set to Swift, as we use the same credentials as Swift
service.
Closes-Bug: #1642524
Change-Id: Ib4a7c07086b0b3354c8e589612f330ecdffdc637
|
|
|
|
|
|
|
|
This shows how we could wire in the upgrade steps using Ansible
as was previously proposed e.g in https://review.openstack.org/#/c/321416/
but it's more closely integrated with the new composable services
architecture.
It's also very similar to the approach taken by SpinalStack where
ansible snippets per-service were combined then run in a series of
steps using Ansible tags.
This patch just enables upgrade of keystone - we'll add support for
other patches in subsequent patches.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I39f5426cb9da0b40bec4a7a3a4a353f69319bdf9
|
|
|
|
|
|
Change-Id: Iee1afeced0b210a46b273aafc0d40e99d6ee6d4e
|
|
This changes how we get the network-based FQDNs for the specific
services, from using the custom fact, to the new hiera entries.
Change-Id: Iae668a5d89fb7bee091db4a761aa6c91d369b276
|
|
Currently, one can get the network-based FQDNs via a custom puppet
fact. This is currently unreliable, as it's based on the ::hostname
fact which we assume it's set correctly by nova. However, this is not
necessarily the case (for instance, if you use pre-deployed services
such as we do with the multinode-jobs). In these cases, the
::hostname fact will return something other than what we specified in
nova, and effectively breaks the configurations in we relly too much
on the network-based FQDN facts.
By using hiera instead, we avoid this issue as we set those values to
be exactly what we expect (as we set them in the OS::TripleO::Server
resource.
Change-Id: I6ce31237098f57bdc0adfd3c42feef0073c224fb
|
|
This patch optimizes how we deploy hiera by using a new
heat hook specifically designed to help compose hiera
within heat templates. As part of this change:
- we update all the 'hiera' software configurations to set the group to hiera
instead of os-apply-config.
- The new format uses JSON instead of YAML. The hook actually writes
out the hiera JSON directly so no conversion takes place. Arrays,
Strings, Booleans all stay in their native formats. As such we can avoid
having to do many of the awkward string and list conversions in t-h-t to
support the previous YAML formatting.
- The new hook prefers JSON over YAML so upgrading users will have the
new files prefered. (we will post a cleanup routine for the old files
soon but this isn't a new behavior, JSON is now simply prefered.)
- A lot of services required edits to account for default settings that
worked in YAML that no longer work correctly in the native JSON
format. In almost all these cases I think the resulting codes looks
cleaner and is more explicit with regards to what is getting
configured in hiera on the actual nodes.
Depends-On: I6a383b1ad4ec29458569763bd3f56fd3f2bd726b
Closes-bug: #1596373
Change-Id: Ibe7e2044e200e2c947223286fdf4fd5bcf98c2e1
|
|
This patch adds a local version of our template processing
routine so that developers can more quickly view the templates
that are actually getting generated. I've noticed multiple developers
now do a full deployment with 'overcloud deploy' only to download
the swift container with the generated templates. This simple task
avoids that step by allowing developers to generate it locally.
It also aims to preserve the ability to use t-h-t templates directly
with Heat (instead of going through Mistral) should users wish to do that.
The new undercloud heat installer requires the ability to generate
templates without requiring Mistral and Swift to do so.
Ideally the Mistral API workflow would use this same code
so perhaps in the future we might modify that routine to:
-download swift tarball containing the templates
-run this local routine that lives in t-h-t
-re-upload the tarball of templates to the swift container
Change-Id: Ie664c9c5f455b7320a58a26f35bc403355408d9b
|
|
Currently we only support one dispatcher at a time. But ceilometer
config supports dispatching data to multiple destinations at the
same time. Update the param to support this.
Change-Id: Ie7d854928513239a5903862623df12af1d02b642
|
|
|
|
The parameter type is invalid making it impossible to enable monitoring-environment.
Change-Id: I835d1e82480edb0b6d082a7496d7ceebb1781728
Closes-Bug: #1641080
Closes-Bug: rhbz#1392473
|
|
|