Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-16 Thread Flavio Percoco 

On 11/10/17 07:48 +0200, Flavio Percoco wrote:

On 10/10/17 10:34 -0600, Alex Schultz wrote:

On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco  wrote:

On 09/10/17 12:41 -0700, Emilien Macchi wrote:


On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  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.


Yes, I shall work on a cookiecutter repo for these roles. Good thinking.


I've moved ahead with this. I created a cookiecutter template and I've proceeded
to use this repo as the first one to migrate under `openstack/` for this work.

https://review.openstack.org/#/c/512323/

Please, provide feedback there. I'll soon create the governance patch.
Flavio



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-10 Thread Flavio Percoco 

On 10/10/17 10:34 -0600, Alex Schultz wrote:

On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco  wrote:

On 09/10/17 12:41 -0700, Emilien Macchi wrote:


On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  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.


Yes, I shall work on a cookiecutter repo for these roles. Good thinking.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-10 Thread Alex Schultz 
On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco  wrote:
> On 09/10/17 12:41 -0700, Emilien Macchi wrote:
>>
>> On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-10 Thread Emilien Macchi 
On Tue, Oct 10, 2017 at 4:24 AM, Flavio Percoco  wrote:
[...]
> 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`.

This proposal works for me.

> 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.
>
> Thoughts?

++ for removing duplication and using common roles / libraries when possible.
roles should only have service specific bits at the end.

I also see an opportunity to welcome contributors from outside of
TripleO if some are interested by deploying OpenStack with Ansible
apbs.

Thanks,
-- 
Emilien Macchi

__
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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-10 Thread Flavio Percoco 

On 09/10/17 12:41 -0700, Emilien Macchi wrote:

On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  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.

Thoughts?
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-09 Thread Emilien Macchi 
On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  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?
-- 
Emilien Macchi

__
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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-09 Thread Alex Schultz 
On Mon, Oct 9, 2017 at 3:29 AM, Flavio Percoco  wrote:
> Greetings,
>
> I've been working on something called triple-apbs (and it's respective
> roles) in
> the last couple of months. You can find more info about this work
> here[0][1][2]
>
> This work is at the point where I think it would be worth start discussing
> how
> we want these repos to exist under the TripleO umbrella. As far as I can
> tell,
> we have 2 options (please comment with alternatives if there are more):
>
> 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.
>

I think we've proven that this is a better way to handle these types
of things so I would prefer option #1. I would say that it might be
useful to also create a basic cookiecutter template for these repos so
we can quickly bootstrap new ones. One thing that has a been a
repeated problem when you do split these modules is having to do bulk
updates for requirements or shared structure items and making sure we
don't accrue a ton of tech-debt over time.

Thanks,
-Alex


> 2. Everything in a single repo: this would ease the import process and
> integration with the rest of TripleO. It'll make the early days of this work
> a
> bit easier but it will take us in a direction that doesn't serve one of the
> goals of this work.
>
> My preferred option is #1 because one of the goals of this work is to have
> independent roles that can also be consumed standalone. In other words, I
> would
> like to stay closer to the ansible recommended structure for roles. Some
> examples[3][4]
>
> Any thoughts? preferences?
> Flavio
>
> [0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
> [1]
> http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
> [2] https://github.com/tripleo-apb
> [3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
> [4] https://github.com/tripleo-apb/ansible-role-k8s-glance
>
> --
> @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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-09 Thread Jiří Stránský 

On 9.10.2017 11:29, Flavio Percoco wrote:

Greetings,

I've been working on something called triple-apbs (and it's respective roles) in
the last couple of months. You can find more info about this work here[0][1][2]

This work is at the point where I think it would be worth start discussing how
we want these repos to exist under the TripleO umbrella. As far as I can tell,
we have 2 options (please comment with alternatives if there are more):

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.

2. Everything in a single repo: this would ease the import process and
integration with the rest of TripleO. It'll make the early days of this work a
bit easier but it will take us in a direction that doesn't serve one of the
goals of this work.

My preferred option is #1 because one of the goals of this work is to have
independent roles that can also be consumed standalone. In other words, I would
like to stay closer to the ansible recommended structure for roles. Some
examples[3][4]

Any thoughts? preferences?


+1 for option #1. In addition to standalone usage, it feels like a 
better match for "the container way of doing things" in that we'll be 
able to easily mix and match APB versions when necessary. (E.g. having 
problems with bleeding edge Glance APB? Just use a slightly older one 
without being compelled to downgrade the other APBs.) A parallel could 
be drawn to how openstack/puppet-* repos are managed and IMO it's been 
working well that way.


Using APBs this way also seems more "out-of-the-box ready" for APBs that 
don't originate in TripleO project, should we ever want/need to use them 
(e.g. for non-OpenStack services).


Global changes will be harder as they'll require separate commits, and 
in general it's more repos (+ RPMs) to manage, but i hope the 
aforementioned benefits outweigh this.


Jirka


Flavio

[0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
[1] http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
[2] https://github.com/tripleo-apb
[3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
[4] https://github.com/tripleo-apb/ansible-role-k8s-glance

--
@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

[openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-09 Thread Flavio Percoco 

Greetings,

I've been working on something called triple-apbs (and it's respective roles) in
the last couple of months. You can find more info about this work here[0][1][2]

This work is at the point where I think it would be worth start discussing how
we want these repos to exist under the TripleO umbrella. As far as I can tell,
we have 2 options (please comment with alternatives if there are more):

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.

2. Everything in a single repo: this would ease the import process and
integration with the rest of TripleO. It'll make the early days of this work a
bit easier but it will take us in a direction that doesn't serve one of the
goals of this work.

My preferred option is #1 because one of the goals of this work is to have
independent roles that can also be consumed standalone. In other words, I would
like to stay closer to the ansible recommended structure for roles. Some
examples[3][4]

Any thoughts? preferences?
Flavio

[0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
[1] http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
[2] https://github.com/tripleo-apb
[3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
[4] https://github.com/tripleo-apb/ansible-role-k8s-glance

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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