path: root/docker/docker-puppet.py
AgeCommit message (Collapse)AuthorFilesLines
2017-03-22docker-puppet: skip empty volume entriesJuan Antonio Osorio Robles1-1/+2
This allows to optionally add volumes, where we could use a heat conditional to either put the volume path we want or put an empty string which should be safely skipped. Change-Id: I68f91ffdd8ceb14735adad1322fcf124c47b160c
2017-03-13Merge "Pass the DOCKER_* env vars when running docker"Jenkins1-0/+5
2017-03-01Put docker puppet config in puppet_config dictSteve Baker1-0/+3
This approach removes the need for the yaql zip to build the docker-puppet data by building the data in a puppet_config dict. This allows a future change to make docker-puppet.py only accept dict data. Currently the step_config is left where it is and referenced inside puppet_config, but feedback is welcome whether this is necessary or desirable. Change-Id: I4a4d7a6fd2735cb841174af305dbb62e0b3d3e8c
2017-03-01Pass the DOCKER_* env vars when running dockerFlavio Percoco1-0/+5
We should always pass the `DOCKER_*` env vars to all the `docker` commands that are executed in the various scripts as those variables may contain the access data for the docker daemon. Change-Id: Ie719f451350e6ea35cb22d97a8f090ad81fa8141
2017-03-01Switch to dict format for docker_puppet_tasksSteve Baker1-0/+9
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
2017-02-24Add option to diff containers after config stage.Ian Main1-0/+9
This allows you to show the changes made to a container during configuration stage for fast development. Change-Id: Id9c72cf2b07486f0a80bf3572a7ba349888d877f
2017-02-23Add step to docker_puppet_tasksDan Prince1-2/+3
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
2017-02-22Parallelize docker-puppet.pyIan Main1-18/+40
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
2017-02-15Add docker_puppet_tasks initialization on primary nodeDan Prince1-1/+3
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
2017-02-15docker: new hybrid deployment architecture and configurationDan Prince1-0/+210
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