Age | Commit message (Collapse) | Author | Files | Lines |
|
This change gives the option of docker-puppet.py data to be in a dict
as well as a list. This allows docker_puppet_tasks data to use the
same keys as the top level puppet config data.
If the yaql fu can be worked out to build the top level data,
docker-puppet.py can later drop the list format entirely.
Change-Id: I7e2294c6c898d2340421c93516296ccf120aa6d2
|
|
This allows you to show the changes made to a container during
configuration stage for fast development.
Change-Id: Id9c72cf2b07486f0a80bf3572a7ba349888d877f
|
|
This patch sets the step correctly for docker_puppet_tasks.
This is now required in order to match the 'step' in some
puppet manifests explicitly so that things like keystone
initialization run correctly.
Closes-bug: #1667454
Change-Id: If2bdd0b1051125674f116f895832b48723d82b3a
|
|
Use a pool of worker processes to run the puppet modules so they
can all be done in parallel. Defaults to cpu count processes.
Change-Id: I083d302b8cf6538569e4d165221c21df152266bc
|
|
This patch adds a new (optional) section to the docker post.j2.yaml
that collects any 'docker_puppet_tasks' data from enabled
services and applies it on the primary role node (the
first node in the primary (first) role).
The use case for this is although we are generally only using
puppet for configuration there are several exceptions that we
desire to make use of today for parity with baremetal. This
includes things like database creation and keystone endpoint
initialization which we rely on configuration via hiera variables
controlled by the puppet services.
Change-Id: Ic14ef48f26de761b0d0eabd0e1c0eae52d90e68a
|
|
This patch implements a new docker deployment architecture that
should us to install docker services in a stepwise manner alongside
of baremetal puppet services. This works by using Yaql to select
docker specific services (docker/services/*.yaml) vs the puppet
specific ones and then applying the selected Json to relevant Heat
software deployments for docker and baremetal puppet in a stepwise
fashion.
Additionally the new architecture
leverages new composable services interfaces from Newton to
allow configuration of per-service container configuration
sets (directories that are bind mounted into kolla containers) by
using the Kolla containers themselves. It does this by spinning up
a throw away "configuration only" version of the container being
configured itself, then running the puppet apply in that container and
copying the generated config files into /var/lib/config-data. This
avoids having to install all of the OpenStack dependency packages
in the heat-agent-container itself (our previous approach) and should
allow us to configure a much wider variety of container config files
that would otherwise be impossible with the previous shared approach.
The new approach (combined) should allow us to configure containers in
both the undercloud and overcloud and incrementally add CI coverage to
services as we containerize them.
Co-Authored-By: Martin André <m.andre@redhat.com>
Co-Authored-By: Ian Main <imain@redhat.com>
Co-Authored-By: Flavio Percoco <flavio@redhat.com>
Change-Id: Ibcff99f03e6751fbf3197adefd5d344178b71fc2
|