On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 09/10/17 12:41 -0700, Emilien Macchi wrote: >> >> On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco <fla...@redhat.com> wrote: >> [...] >>> >>> 1. A repo per role: Each role would have its own repo - this is the way >>> I've >>> been developing it on Github. This model is closer to the ansible way of >>> doing >>> things and it'll make it easier to bundle, ship, and collaborate on, >>> individual >>> roles. Going this way would produce something similar to what the >>> openstack-ansible folks have. >> >> >> +1 on #1 for the composability. >> >> [...] >> >> Have we considered renaming it to something without tripleo in the name? >> Or is it too specific to TripleO that we want it in the name? > > > The roles don't have tripleo in their names. The only role that mentions > tripleo > is tripleo specific. As for the APB, yeah, I had thought about renaming that > repo to something without tripleo in there: Perhaps just `ansible-k8s-apbs`. > > I'm about to refactor this repo to remove all the code duplication. We > should be > able to generate most of the APB code that's in there from a python script. > We > could even have this script in tripleo_common, if it sounds sensible. >
It should be it's own thing and not in tripleo_common. When I was proposing a cookiecutter repo it was because in Puppet we do the same thing to bootstrap the modules[0]. It would be a good idea to establish this upfront with the appropriate repo & zuul v3 configurations that could be used to test these modules. We have a similar getting started with a new module doc[1] that we should probably establish for these ansible-k8s-* roles. Thanks, -Alex [0] https://github.com/openstack/puppet-openstack-cookiecutter [1] https://docs.openstack.org/puppet-openstack-guide/latest/contributor/new-module.html > Thoughts? > Flavio > > -- > @flaper87 > Flavio Percoco > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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