On Thu, Jul 5, 2018 at 1:50 PM, Dan Prince <dpri...@redhat.com> wrote: > Last week I was tinkering with my docker configuration a bit and was a > bit surprised that puppet/services/docker.yaml no longer used puppet to > configure the docker daemon. It now uses Ansible [1] which is very cool > but brings up the question of how should we clearly indicate to > developers and users that we are using Ansible vs Puppet for > configuration? > > TripleO has been around for a while now, has supported multiple > configuration ans service types over the years: os-apply-config, > puppet, containers, and now Ansible. In the past we've used rigid > directory structures to identify which "service type" was used. More > recently we mixed things up a bit more even by extending one service > type from another ("docker" services all initially extended the > "puppet" services to generate config files and provide an easy upgrade > path). > > Similarly we now use Ansible all over the place for other things in > many of or docker and puppet services for things like upgrades. That is > all good too. I guess the thing I'm getting at here is just a way to > cleanly identify which services are configured via Puppet vs. Ansible. > And how can we do that in the least destructive way possible so as not > to confuse ourselves and our users in the process. > > Also, I think its work keeping in mind that TripleO was once a multi- > vendor project with vendors that had different preferences on service > configuration. Also having the ability to support multiple > configuration mechanisms in the future could once again present itself > (thinking of Kubernetes as an example). Keeping in mind there may be a > conversion period that could well last more than a release or two. > > I suggested a 'services/ansible' directory with mixed responces in our > #tripleo meeting this week. Any other thoughts on the matter?
I would almost rather see us organize the directories by service name/project instead of implementation. Instead of: puppet/services/nova-api.yaml puppet/services/nova-conductor.yaml docker/services/nova-api.yaml docker/services/nova-conductor.yaml We'd have: services/nova/nova-api-puppet.yaml services/nova/nova-conductor-puppet.yaml services/nova/nova-api-docker.yaml services/nova/nova-conductor-docker.yaml (or perhaps even another level of directories to indicate puppet/docker/ansible?) Personally, such an organization is something I'm more used to. It feels more similar to how most would expect a puppet module or ansible role to be organized, where you have the abstraction (service configuration) at a higher directory level than specific implementations. It would also lend itself more easily to adding implementations only for specific services, and address the question of if a new top level implementation directory needs to be created. For example, adding a services/nova/nova-api-chef.yaml seems a lot less contentious than adding a top level chef/services/nova-api.yaml. It'd also be nice if we had a way to mark the default within a given service's directory. Perhaps services/nova/nova-api-default.yaml, which would be a new template that just consumes the default? Or perhaps a symlink, although it was pointed out symlinks don't work in swift containers. Still, that could possibly be addressed in our plan upload workflows. Then the resource-registry would point at nova-api-default.yaml. One could easily tell which is the default without having to cross reference with the resource-registry. -- -- James Slagle -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev