For centos, we should be using the RDO repositories to provide
rabbitmq-server. This version is updated with bug fixes and provides
a more stable experience then using rabbitmq.com builds.
Co-Authored-by: Jeffrey Zhang <zhang.lei.fly@gmail.com>
Co-Authored-by: Michal (inc0) Jastrzebski <inc007@gmail.com>
Closes-Bug: #1621460
Change-Id: Ib0eafc5da4397756fbdd837520b15543180ce229
This patch changes version of ceph from hammer to jewel. Also removed
versionlock as it seems we don't use it in ubuntu, and actually might be
risky if we miss security patch on ceph.
Change-Id: Ib8f88c2f914a4b635e59a509fa0194605eb73165
Implements: blueprint upgrade-ceph-to-jewel
Collectd-ceilometer-plugin is essential for further
more detailed metrics collection, smarter scheduling and service
assurance.
Change-Id: I8da572980de370517ec120d745ad1d36e316b465
Implements: blueprint collectd-ceilometer-plugin
Since customizations are done for most of services, I think we can make
it an official feature and close whole blueprint. Good work team!
Change-Id: I44de0204261cd04b2564ce62a5d10b1e0a4fd4bf
Implements: blueprint dockerfile-customizations
Implements: blueprint third-party-plugin-support
- This change extends kolla-ansible
with a deploy-server command to enroll and deploy
physical servers with bifrost.
Change-Id: Iaa9f34b00e676569f6e3df679b7454b1ec0b8e34
Implements: blueprint bifrost-support
- This change addes the ability to deploy
and bootstrap bifrost.
- This change introduces a deploy-bifrost
command to kolla-ansible.
Change-Id: I62afcf348661add900c98904e90a15a0eddffd4b
Implements: blueprint bifrost-support
- This change adds support for building and deploying
a bifrost container for baremetal provisioning.
- This change documents how to manually deploy and bootstrap
the bifrost container.
Implements: blueprint bifrost-support
Change-Id: I7d895839b11cbf916be33225875465c3358b5aa4
New option enable_neutron_agent_ha added to enable/disable dhcp/l3 agent
high availability, dhcp_agents_per_network is default to 2 and it's
configurable.
Implement blueprint: support-network-ha
Change-Id: Id4742aa67c80584634b923195545bf2b654172f3
An unwitting user may apply the KOLLA_CEPH_OSD[_CACHE]_BOOTSTRAP label
to a partition assuming it will only use that partition for Ceph, and
end up wiping out their disk.
This change adds a layer of checking to this scenario to try and help
avoid a disaster scenario.
Closes-Bug: 1599103
DocImpact
Change-Id: Ibb9fb42f87a76bc02165ec0b93b60234bad8747a
In order for Murano to be operational the core library package must be
imported [0]
Add Ansible tasks to do this idempotently.
[0] http://docs.openstack.org/developer/murano/install/manual.html
TrivialFix
Change-Id: I2c49e9d663595650b885267839012b543505337a
This addresses the ansible aspects of fernet key bootstrapping as
well as distributed key rotation.
- Bootstrapping is handled in the same way as keystone bootstrap.
- A new keystone-fernet and keystone-ssh container is created to allow
the nodes to communicate with each other (taken from nova-ssh).
- The keystone-fernet is a keystone container with crontab installed.
This will handle key rotations through keystone-manage and trigger
an rsync to push new tokens to other nodes.
- Key rotation is setup to be balanced across the keystone nodes using
a round-robbin style. This ensures that any node failures will not
stop the keys from rotating. This is configured by a desired token
expiration time which then determines the cron scheduling for each
node as well as the number of fernet tokens in rotation.
- Ability for recovered node to resync with the cluster. When a node
starts it will run sanity checks to ensure that its fernet tokens
are not stale. If they are it will rsync with other nodes to ensure
its tokens are up to date.
The Docker component is implemented in:
https://review.openstack.org/#/c/349366
Change-Id: I15052c25a1d1149d364236f10ced2e2346119738
Implements: blueprint keystone-fernet-token
Normally, when you launch a Docker container, the process you're
executing becomes PID 1, giving it the quirks and responsibilities that
come with being the init system for the container.
There are two common issues this presents:
* In most cases, signals won't be handled properly.
* Orphaned zombie processes aren't properly reaped.
the dumb-init acting like a simple init system. It launches a single
process and then proxies all received signals to a session rooted at
that child process.
Closes-Bug: #1614509
Change-Id: I9d3d04648e151ddc7c6732b92ffd3b6c9fe467ec
Add the following prechecks for network_interface:
* Check it exists on the node
* Check its up
* Check it has an IP associated
TrivialFix
Change-Id: I86f1d79d8592a3b108822e7d19541f91a1c0d716
Co-Authored-By: James McCarthy <james.m.mccarthy@oracle.com>
Add needed library packages and Dockerfile to build vmtp container.
Co-Authored-By: Larry Rensing <lr699s@att.com>
Partially implements: bp vmtp-container
Change-Id: I54340947f3bdf61d3e4f54884fed90ac318124ff