reutilizando módulos

[Arnau Bria]

Buenas,

estoy rehaciendo el código que tenía y mi idea es reutilizar el máximo
de módulos disponibles. Muchos de ellos cubren mis necesidades, pero
alguno no se ajustan al 100% a lo que quiero hacer. Por poner un
ejmplo, ahora estoy con yum repos
(https://github.com/example42/puppet-yum) y veo que me exige una
estructura de repositoris X, y que ciertas opciones del repositorio no
las puedo especificar (exclude?), etc... Me surge la duda de que haer:

1.-) contactar al desarrollador para que implemente X
2.-) fork + do it yourself (luego pasar tu cambio al desarrollador)
3.-) fork + do it youself pero sin "reportar" los cambios
4.-) hacer el módulo uno mismo
5.-) ...

Entonces, que hacéis normalmente vosotros cuando os encontráis con esto?

Matthias, tu qeu tienes módulos públicos (no se si alguien más también
los tiene), que experiencia tienes con el feedback de la gente que
utiliza tus módulos?

Un saludo,
Arnau

[Juan Sierra Pons]

Buenos tardes,

No se si es la mejor opción pero si estas usando profiles/roles,
puedes poner "un poco" de logica en el perfil o en el rol.

Asi al añadir una capa de abstraccion mas puedes ajustar el
perfil/modulo a tus necesidades sin tocar el codigo o hacer fork de lo
que hay por debajo, etc.

En muchos casos puede que te sirva esta opcion. Si no... te tendras
que manchar las manos :)

Suerte y al toro!

Salu2
--------------------------------------------------------------------------------------
Juan Sierra Pons ju...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00 6E66 E934 3406 A110 F4FE
--------------------------------------------------------------------------------------

> --
> Has recibido este mensaje porque estás suscrito al grupo "puppet-users-barcelona" de Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a puppet-users-barc...@googlegroups.com.
> Para publicar una entrada en este grupo, envía un correo electrónico a puppet-user...@googlegroups.com.

[Alex Muntada]

Arnau Bria:

1.-) contactar al desarrollador para que implemente X

Si tienes suerte tal vez resulte pero si tienes prisa seguro que normalmente no porque dependes del tiempo, ganas y predisposición de otra persona.

 

2.-) fork + do it yourself (luego pasar tu cambio al desarrollador)

Seria como lo anterior pero más pro-activo y puede agilizar la incorporación de cambios. Aquí la clave es saber sintonizar y respetar el espíritu original para que acepten los cambios rápidamente. Con puppet no he tenido oportunidad de probar qué tal responden los autores porque usamos pocos módulos públicos.

 

3.-) fork + do it youself pero sin "reportar" los cambios

Lo hemos usado alguna vez cuando los cambios son minúsculos, estéticos o difíciles de justificar en upstream. Mientras sea fácil mantener el código sincronizado con upstream y publicarlo no aporte valor a nadie, parece razonable.

 

4.-) hacer el módulo uno mismo

Es el que usamos más, a veces incluso tomando una pequeña parte de otro módulo público como base. El problema es que al cabo del tiempo tu base de código es enorme y cuesta de mantener al día o meterle cambios importantes (nosotros tenemos creado 231 módulos propios desde noviembre de 2010 y tenemos un follón de cuidado). En algunos casos no queda otra opción, a veces es mejor alinearse con la forma de trabajar de un módulo público que no intentar que encaje en el universo particular de cada uno.

 

5.-) ...

Otra opción es usar herencia: creas un módulo tuyo que hereda de otro público y cambias lo que no te gusta. Pero me temo que la herencia en Puppet no es exactamente la misma a la que estamos acostumbrados en los lenguajes con OO.

Un saludo,

Alex

[Arnau Bria]

On Wed, 15 Apr 2015 15:14:01 +0200
Juan Sierra Pons wrote:

> Buenos tardes,
Hola!

> No se si es la mejor opción pero si estas usando profiles/roles,
> puedes poner "un poco" de logica en el perfil o en el rol.

Si, si que los utilizo. Estoy tratando de seguir todas las best
practices posibles :-)

(y esto de roles/profiles ya lo teníamos medio implmentado en la 2.X,
lo que le llamaban host_type).

> Asi al añadir una capa de abstraccion mas puedes ajustar el
> perfil/modulo a tus necesidades sin tocar el codigo o hacer fork de lo
> que hay por debajo, etc.

en algún caso si que veo que podré hacerlo (por lo que he leido), pero
en cosas como ésta (donde el módulo que utilizo ya me define el
repositorio y yo debería re-definirlo (*)) no sabía como implementarlo

re-definir no es posible, si podría utilizar su define para crear mis
módulos... De echo, en este caso que hablamos de repos son 4
ficheros que puedo o definir en una classe propia o utilizar
hiera+create_resource, pero la duda vuelve a ser general (ya que estoy
empezandao, prefiero hacerlo "bien" desde ya).

> En muchos casos puede que te sirva esta opcion. Si no... te tendras
> que manchar las manos :)

y en ese caso, devuelves lo modificado?

> Suerte y al toro!
>
> Salu2

Muchas gracias por tu respuetsa,
Un saludo,
Arnau

[Matthias Saou]

On Wed, 15 Apr 2015 15:05:23 +0200
Arnau Bria <arnau...@gmail.com> wrote:

> 1.-) contactar al desarrollador para que implemente X
> 2.-) fork + do it yourself (luego pasar tu cambio al desarrollador)
> 3.-) fork + do it youself pero sin "reportar" los cambios
> 4.-) hacer el módulo uno mismo
> 5.-) ...

Creo que Alex ha contestado eso muy bien. Resumen :

1. Mejor n°2
2. Lo ideal si los cambios son relevantes
3. Solo si los cambios no son relevantes, idealmente haciendolo bien
con un branch interno haciendo rebase con upstream de vez en cuando
4. Si es lo que mas sentido tiene, por ejemplo para gestionar datos de
cuentas, claves ssh, certificados ssl, etc. es lo que hay

> Matthias, tu qeu tienes módulos públicos (no se si alguien más también
> los tiene), que experiencia tienes con el feedback de la gente que
> utiliza tus módulos?

Recibo mucho feedback que me gusta. Acepto facilmente pequenyas mejoras
faciles de repasar, probar, e incluir siempre y cuando no cambian nada
para los desplieges existentes. Si haces un pull request con un cambio
de este tipo, explicando bien tu caso de uso, creo que no tendras
problemas en que se incluya!

Igualmente, para tu caso, no te sirve simplemente el tipo 'yumrepo'?
https://docs.puppetlabs.com/references/stable/type.html#yumrepo

Si quieres un ejemplo de "wrapper" o "capa de abstraccion" para
extender un modulo existente como lo sugeria Juan, mira por ejemplo lo
que he hecho para mi necesidad de aplicar reglas de firewall para IPv4 y
IPv6 a la vez (algo que el modulo puppetlabs-firewall no hace) :

https://github.com/thias/puppet-rhel/blob/master/manifests/firewall/dualstack.pp

...no es muy bonito, pero se entiende y hace lo que dice :-)
De hecho, todos estos rhel::firewall::* han sido creados cuando he
migrado de mi proprio modulo iptables hacia el oficial de PuppetLabs.
Necesitaba cosas repetitivas i adicionales como eso o crear reglas a
partir de un array de direcciones IP, y ha sido mi forma de hacerlo. Lo
que si que tenia sentido cambiar "upstream" se ha hecho también, por
ejemplo :
https://github.com/puppetlabs/puppetlabs-firewall/pull/387

Suerte con tus cambios! ;-)

Matthias

--
Matthias Saou ██ ██
██ ██
Web: http://matthias.saou.eu/ ██████████████
Mail/XMPP: matt...@saou.eu ████ ██████ ████
██████████████████████
GPG: 4096R/E755CC63 ██ ██████████████ ██
8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██
21A9 7A51 7B82 E755 CC63 ████ ████

[Arnau Bria]

On Wed, 15 Apr 2015 18:51:21 +0200
Matthias Saou wrote:

Hola!

> Creo que Alex ha contestado eso muy bien. Resumen :

Si, moltes gràcies Àlex!

[...]

> > Matthias, tu qeu tienes módulos públicos (no se si alguien más
> > también los tiene), que experiencia tienes con el feedback de la
> > gente que utiliza tus módulos?
>
> Recibo mucho feedback que me gusta. Acepto facilmente pequenyas
> mejoras faciles de repasar, probar, e incluir siempre y cuando no
> cambian nada para los desplieges existentes. Si haces un pull request
> con un cambio de este tipo, explicando bien tu caso de uso, creo que
> no tendras problemas en que se incluya!
>
> Igualmente, para tu caso, no te sirve simplemente el tipo 'yumrepo'?
> https://docs.puppetlabs.com/references/stable/type.html#yumrepo

Si, si. La verdad es que son dudas más generales que otra cosa. En
este caso, con 4 repos (de los que ya tengo el código) está hecho. Pero
en mi nueva idea de utilizar al máximo módulos genéricos me voy preimro
a buscar algo ya hecho (en este caso, este módulo tiene repos extra que
a veces me interesan y me sería muy fácil añadir).

Pero bueno, que como estoy empezando la migración me van surgiendo
dudas que no quiero plantearme cuando esté más liado con ella.

> Si quieres un ejemplo de "wrapper" o "capa de abstraccion" para
> extender un modulo existente como lo sugeria Juan, mira por ejemplo lo
> que he hecho para mi necesidad de aplicar reglas de firewall para
> IPv4 y IPv6 a la vez (algo que el modulo puppetlabs-firewall no
> hace) :
>
> https://github.com/thias/puppet-rhel/blob/master/manifests/firewall/dualstack.pp
>
> ...no es muy bonito, pero se entiende y hace lo que dice :-)
> De hecho, todos estos rhel::firewall::* han sido creados cuando he
> migrado de mi proprio modulo iptables hacia el oficial de PuppetLabs.
> Necesitaba cosas repetitivas i adicionales como eso o crear reglas a
> partir de un array de direcciones IP, y ha sido mi forma de hacerlo.
> Lo que si que tenia sentido cambiar "upstream" se ha hecho también,
> por ejemplo :
> https://github.com/puppetlabs/puppetlabs-firewall/pull/387
>
> Suerte con tus cambios! ;-)

muchas gracias!

> Matthias
salu2,
Arnau