Age | Commit message (Collapse) | Author | Files | Lines |
|
The port parameter to puppetlabs-firewall is actually deprecated[1].
This adds support for using the new parameter names dport and sport. The
port parameter is still retained in puppet-tripleo for backwards
compatibily for anyone using that interface. It is marked deprecated in
the documentation, however no deprecation warning is needed because
there is already a warning from from puppetlabs-firewall.
blueprint undercloud-elements
Change-Id: I0598007f90018f80a3266193bb24dbf112de49b7
|
|
Specifying a destination cidr is already supported by
puppetlabs-firewall, we just need to pass through the parameter in
rule.pp in puppet-tripleo.
This will allow creating iptables rules that forward network traffic for
a given cidr via puppet-tripleo.
Change-Id: I23582a55cd97248be52f45e14de7e813ff499ff7
|
|
Change the workflow to be:
Upgrade all packages before any services that is notified & managed by
Puppet.
It also disable the Exec timeout so we rely on Heat timeout and not on
the 300s that are the default in Puppet [1]
Example: we upgrade and OpenStack config will change (obviously).
Puppet catalog will contain 3 important things:
* config resources
* service resources
* package-upgrade Exec resource
with that patch, what will happen:
* puppet will update config first or second and notify
services
* puppet will run package-upgrade first or second but before
the package-upgrade Exec resource
* at the very end, puppet will restart services
That way, we avoid complications with Puppet dependency cycle issues.
[1] https://docs.puppetlabs.com/references/latest/type.html#exec-attribute-timeout
Closes-Bug: 1536349
Change-Id: I07310bdfc5b07b03ac9fa5f8c13e87eaa2bfef4d
|
|
This updates tripleo::packages so that when enable_upgrade
is used it will:
1) upgrade puppet managed packages (will trigger puppet dependencies)
2) then upgrade all packages via exec
3) then restart services
NOTE: the intention here is that the Exec['update-packages'] will
always execute if enable_upgrade is set. It is not idempotent
in this regard because I think we always want to execute it
if enable_upgrade is set.
Change-Id: I02f7cf07792765359f19fdf357024d9e48690e42
Related-bug: #1522943
|
|
Switch to locp/cassandra module since it has much more options than
midonet/puppet-cassandra and it is already defined on the
openstack-puppet-modules packages in RHEL. More info:
https://bugzilla.redhat.com/show_bug.cgi?id=1285718
Depends-On: I72f21036fda795b54312a7d39f04c30bbf16c41b
Change-Id: Icea9bd96e4c80a26b9e813d383f84099c736d7bf
|
|
Change-Id: Ie2f3e29005570805fbf2ca75a930fab746f5f299
Related-bug: #1517805
Signed-off-by: Gael Chamoulaud <gchamoul@redhat.com>
|
|
|
|
Change-Id: I10c0d35b473026a5e1ede265099f73c803402adc
Related-bug: #1517805
Signed-off-by: Gael Chamoulaud <gchamoul@redhat.com>
|
|
Provide TripleO overcloud manifests to deploy MidoNet and the cluster
services that needs to run.
Change-Id: I24f852e74fc4652d4609e1a71897e813448055fe
|
|
Currently firewalling is implemented in tripleo/init.pp this commit
moves it to its own scope tripleo/firewall.pp.
This is done so that in tripleo-heat-templates we can have a simple and
generic `include tripleo::firewall` in every manifest - unconditional.
The rest of the behavior will all be managed by hiera.
If a user wants to enable firewalling:
```
tripleo::firewall::manage_firewall: true
```
If a user wants to specify firewall rules:
```
tripleo::firewall::firewall_rules:
'103 mongod':
port: 27017
```
Change-Id: I144c60db2a568a94dce5b51257f1d10980173325
|
|
* Provide a Define function which will allow to manage IPtables rules.
* Manage rules in 'pre' and 'post' Puppet stages, it allows to create
rules before and after regular Puppet stages (ie: to make sure no rule
exists *before* and everything is blocked *after* regular Puppet
stages)
Change-Id: I84fc79096f6fc3db76a61d012d8cb62dd12bdd89
|