Optimizar la instalación de muchos sitios Plone en un mismo servidor dedicado con el instalador unificado

[spanish]

Hola familia,

Una de las primeras cosas que hice al dar mis primeros pasos con Plone
fue probar la instalación de productos usando buildout y los
correspondientes huevos. Tras instalar uno de ellos y reiniciar Zope,
éste "explotó" (en terminología de Mikel) y todos los sitios Plone de
prueba que había creado dejaron de funcionar. Por fortuna, ninguno
estaba en producción y al quitar el correspondiente huevo de
buildout.cfg, Zope reinició sin problema y todo volvió a la normalidad.

La cuestión es que ahora tenemos ya un par de sitios Plone en producción
y no tardaremos mucho en inaugurar varios más. Así que me preocupa que
la instalación de un producto o cualquier otra operación deje fuera de
línea simultáneamente a todos los sitios Plone (especialmente si algún
día nos encontramos con un problema más grave y difícil de solucionar
que el arriba descrito o tardamos en darnos cuenta de lo que está pasando).

Por ello, me gustaría saber cuál es la mejor manera de poder disfrutar
de muchos sitios Plone en un mismo servidor usando el instalador unificado.

1.- ¿Una instalación unificada con varias instancias y en cada una de
éstas un sitio Plone?

2.- ¿Una instalación unificada con varias instancias con distintos
grupos de productos instalados y en cada una de ellas varios sitios
Plone que vayan a usar exactamente los correspondientes grupos de productos?

3.- ¿Varias instalaciones unificadas con una o varias instancias y
sitios Plone cada una de ellas?

4.- ¿Otra opción?

¿Cuál ofreceria la mejor relación tranquilidad para nosotros/consumo de
recursos del servidor/tiempo dedicado/resolución de problemas?

Gracias por la ayuda y abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Santiago Videla]

Buenas,

2008/10/24 Manuel Gualda Caballero <[hidden email]>

Hola familia,

Una de las primeras cosas que hice al dar mis primeros pasos con Plone
fue probar la instalación de productos usando buildout y los
correspondientes huevos. Tras instalar uno de ellos y reiniciar Zope,
éste "explotó" (en terminología de Mikel) y todos los sitios Plone de
prueba que había creado dejaron de funcionar. Por fortuna, ninguno
estaba en producción y al quitar el correspondiente huevo de
buildout.cfg, Zope reinició sin problema y todo volvió a la normalidad.

Para saber que paso aca, hace falta tener las esquirlas de la explosion... es decir el log del error

¿Cuál ofreceria la mejor relación tranquilidad para nosotros/consumo de
recursos del servidor/tiempo dedicado/resolución de problemas?

No se si hay UNA respuesta para esa pregunta. Me parece que depende de muchas variables que pueden favorecer a una opcion u otra.

Personalmente, me resulta util para empezar, NO usar el instalador unificado. Prefiero el buildout y los eggs.
Para "aislar" cada sitio Plone ante posibles explosiones, lo que hago es armar puntos de montaje de ZODB. Es decir que cada Plone se guarda en un archivo Data.fs independiente del resto.

Esto es util para poder hacer backups de cada Plone Site por separado.

Obviamente que para reducir la posibilidad de problemas, deberian tener replicados los sitios que tienen en produccion, y antes de poner en produccion cualquier cosa, probarlo en los sitios replicados para desarrollo. Y supongo que lo "correcto" seria que tengan los Test de unidad y funcionales para cada producto que agreguen a produccion

Saludos

Gracias por la ayuda y abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

--
Santiago Videla
www.revolucionesweb.com.ar
http://www.linkedin.com/in/svidela

Sigue la mata dando de que hablar siempre abajo y a la izquierda donde el pensamiento que se hace corazón resplandece con la palabra sencilla y humilde que l@s tod@s somos.

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Mikel Larreategi]

El día 25 de octubre de 2008 3:04, Manuel Gualda Caballero
<[hidden email]> escribió:

> Hola familia,
>
> Una de las primeras cosas que hice al dar mis primeros pasos con Plone
> fue probar la instalación de productos usando buildout y los
> correspondientes huevos. Tras instalar uno de ellos y reiniciar Zope,
> éste "explotó" (en terminología de Mikel) y todos los sitios Plone de
> prueba que había creado dejaron de funcionar. Por fortuna, ninguno
> estaba en producción y al quitar el correspondiente huevo de
> buildout.cfg, Zope reinició sin problema y todo volvió a la normalidad.
>
> La cuestión es que ahora tenemos ya un par de sitios Plone en producción
> y no tardaremos mucho en inaugurar varios más. Así que me preocupa que
> la instalación de un producto o cualquier otra operación deje fuera de
> línea simultáneamente a todos los sitios Plone (especialmente si algún
> día nos encontramos con un problema más grave y difícil de solucionar
> que el arriba descrito o tardamos en darnos cuenta de lo que está pasando).
>
> Por ello, me gustaría saber cuál es la mejor manera de poder disfrutar
> de muchos sitios Plone en un mismo servidor usando el instalador unificado.
>
> 1.- ¿Una instalación unificada con varias instancias y en cada una de
> éstas un sitio Plone?
>
> 2.- ¿Una instalación unificada con varias instancias con distintos
> grupos de productos instalados y en cada una de ellas varios sitios
> Plone que vayan a usar exactamente los correspondientes grupos de productos?
>
> 3.- ¿Varias instalaciones unificadas con una o varias instancias y
> sitios Plone cada una de ellas?
>
> 4.- ¿Otra opción?
>
> ¿Cuál ofreceria la mejor relación tranquilidad para nosotros/consumo de
> recursos del servidor/tiempo dedicado/resolución de problemas?
>

Yo tengo un buildout (sólo 1) para controlar cada Plone. Así si
"explota", explota sólo uno.

Y claro, la configuración del buildout está en un SVN para poder
controlar las versiones y todo eso.

Mikel



--
Mikel Larreategi
[hidden email]

CodeSyntax
Azitaingo Industrialdea 3 K
E-20600 Eibar
Tel: [phone]

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Archuby]

Buenas gente alguien sabe si archgenxml 2 genera productos en formato egg
o si solo lo hace a la manera tradicional de Plone 2.5?

Gracias
Gustavo



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Orrillo]

manera tradicional,
saludos

On Mon, Oct 27, 2008 at 1:22 PM, Gustavo Archuby <[hidden email]> wrote:

Buenas gente alguien sabe si archgenxml 2 genera productos en formato egg
o si solo lo hace a la manera tradicional de Plone 2.5?

Gracias
Gustavo



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

--

Gustavo Orrillo
Business Development
Inter-Cultura

[hidden email]
www.inter-cultura.com
[phone]



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Archuby]

Ok, gracias

Gustavo

> manera tradicional,
> saludos
>
> On Mon, Oct 27, 2008 at 1:22 PM, Gustavo Archuby
> <[hidden email]
>> wrote:
>
>> Buenas gente alguien sabe si archgenxml 2 genera productos en formato
>> egg
>> o si solo lo hace a la manera tradicional de Plone 2.5?
>>
>> Gracias
>> Gustavo
>>
>>
>>
>> _______________________________________________
>> Plone-ConoSur mailing list
>> [hidden email]
>> http://lists.plone.org/mailman/listinfo/plone-conosur
>>
>
>
>
> --
>
> Gustavo Orrillo
> Business Development
> Inter-Cultura
>
> [hidden email]
> www.inter-cultura.com
> [phone]
> _______________________________________________
> Plone-ConoSur mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-conosur
>

--
Gustavo Archuby
Area Informática
Facultad de Humanidades y Ciencias de la Educación



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Archuby]

Alguién puede desaznarme respecto de como renmobrar un id en plone 3, en
plone 2.5 lo hacía mediante un mutator y luego un setId, estoy teniendo
problemas con el setId y en realidad es que estoy probando un poco a lo
"mono" ya que no encuentro la documentación...

gracias!!!

> Buenas gente alguien sabe si archgenxml 2 genera productos en formato egg
> o si solo lo hace a la manera tradicional de Plone 2.5?
>
> Gracias
> Gustavo
>
>
>
> _______________________________________________
> Plone-ConoSur mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-conosur
>

--
Gustavo Archuby
Area Informática
Facultad de Humanidades y Ciencias de la Educación



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Santiago Bruno]

On Thu, Oct 30, 2008 at 2:09 AM, Gustavo Archuby
<[hidden email]> wrote:
> Alguién puede desaznarme respecto de como renmobrar un id en plone 3, en
> plone 2.5 lo hacía mediante un mutator y luego un setId, estoy teniendo
> problemas con el setId y en realidad es que estoy probando un poco a lo
> "mono" ya que no encuentro la documentación...

No se en que momento necesitás hacer el renombre. Si es al crear el
objeto redefiniendo _renameAfterCreation, tal vez te esté faltando
hacer un commit antes del setId.

Fijate como lo hace richdocument y Poi:

http://plone.org/documentation/tutorial/richdocument/controlling-creation


El documento es viejo pero sirve igual, lo único que hice diferente
cuando lo usé en Plone 3 es transaction.commit(1) en lugar de
get_transaction().commit(1). Hay que importar transaction si no
estaba.


Saludos,

Santiago.

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Archuby]

Gracias lo voy a mirar, si es cuando lo creo.

Gustavo

> On Thu, Oct 30, 2008 at 2:09 AM, Gustavo Archuby
> <[hidden email]> wrote:
>> Alguién puede desaznarme respecto de como renmobrar un id en plone 3, en
>> plone 2.5 lo hacía mediante un mutator y luego un setId, estoy teniendo
>> problemas con el setId y en realidad es que estoy probando un poco a lo
>> "mono" ya que no encuentro la documentación...
>
> No se en que momento necesitás hacer el renombre. Si es al crear el
> objeto redefiniendo _renameAfterCreation, tal vez te esté faltando
> hacer un commit antes del setId.
>
> Fijate como lo hace richdocument y Poi:
>
> http://plone.org/documentation/tutorial/richdocument/controlling-creation
>
>
> El documento es viejo pero sirve igual, lo único que hice diferente
> cuando lo usé en Plone 3 es transaction.commit(1) en lugar de
> get_transaction().commit(1). Hay que importar transaction si no
> estaba.
>
>
> Saludos,
>
> Santiago.
>
> _______________________________________________
> Plone-ConoSur mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-conosur
>

--
Gustavo Archuby
Area Informática
Facultad de Humanidades y Ciencias de la Educación



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Gustavo Archuby]

Genial Gracias, lo único que es:

        transaction.savepoint(optimistic=True)
en lugar de
        transaction().commit(1)

Gustavo

> On Thu, Oct 30, 2008 at 2:09 AM, Gustavo Archuby
> <[hidden email]> wrote:
>> Alguién puede desaznarme respecto de como renmobrar un id en plone 3, en
>> plone 2.5 lo hacía mediante un mutator y luego un setId, estoy teniendo
>> problemas con el setId y en realidad es que estoy probando un poco a lo
>> "mono" ya que no encuentro la documentación...
>
> No se en que momento necesitás hacer el renombre. Si es al crear el
> objeto redefiniendo _renameAfterCreation, tal vez te esté faltando
> hacer un commit antes del setId.
>
> Fijate como lo hace richdocument y Poi:
>
> http://plone.org/documentation/tutorial/richdocument/controlling-creation
>
>
> El documento es viejo pero sirve igual, lo único que hice diferente
> cuando lo usé en Plone 3 es transaction.commit(1) en lugar de
> get_transaction().commit(1). Hay que importar transaction si no
> estaba.
>
>
> Saludos,
>
> Santiago.
>
> _______________________________________________
> Plone-ConoSur mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-conosur
>

--
Gustavo Archuby
Area Informática
Facultad de Humanidades y Ciencias de la Educación



_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[spanish]

Santiago Videla escribió:
> Para saber que paso aca, hace falta tener las esquirlas de la
> explosion... es decir el log del error

Je, je,... Buena metáfora...

\ ;-)

>     ¿Cuál ofreceria la mejor relación tranquilidad para nosotros/consumo de
>     recursos del servidor/tiempo dedicado/resolución de problemas?
>
>
> No se si hay UNA respuesta para esa pregunta. Me parece que depende de
> muchas variables que pueden favorecer a una opcion u otra.
>
> Personalmente, me resulta util para empezar, NO usar el instalador
> unificado.

¿Por qué?

> Prefiero el buildout y los eggs.

La verdad es que tienen buena pinta...

> Para "aislar" cada sitio Plone ante posibles explosiones, lo que hago es
> armar puntos de montaje de ZODB.

¿Dónde puedo ampliar información sobre esto? Es que he buscado "armar
puntos de montaje de ZODB" en Google y no veo nada relevante (aparte de
este mismo tema de debate). ¿Tiene otro nombre en español? ¿Cómo se
diría en inglés?

> Es decir que cada Plone se guarda en un archivo Data.fs independiente del resto.
> Esto es util para poder hacer backups de cada Plone Site por separado.

Parece una solución muy buena.

\ ;-)

> Obviamente que para reducir la posibilidad de problemas, deberian tener
> replicados los sitios que tienen en produccion, y antes de poner en
> produccion cualquier cosa, probarlo en los sitios replicados para
> desarrollo.

Entiendo que no te refieres a sitios espejo, sino a sitios de prueba con
las mismas versiones de software (python, zope, plone y productos).
¿Correcto?

> Y supongo que lo "correcto" seria que tengan los Test de
> unidad y funcionales para cada producto que agreguen a produccion

¡Guau! Esto tendré que investigar qué es...

Gracias por la ayuda y abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[spanish]

Mikel Larreategi escribió:
>
> Yo tengo un buildout (sólo 1) para controlar cada Plone. Así si
> "explota", explota sólo uno.

\ ;-P

> Y claro, la configuración del buildout está en un SVN para poder
> controlar las versiones y todo eso.

Gracias, me empollaré bien estas cosas, trastearé en local para no
cargarme nada y ya os daré la lata con las dudas que me surjan...

Abrazos calentitos desde el Sur:

Manuel

> Mikel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Santiago Videla]

Buenas

>
> Personalmente, me resulta util para empezar, NO usar el instalador
> unificado.

¿Por qué?

Supongo que es cuestion de gusto, :)

Durante el desarrollo, se me hace mas facil actualizar paquetes o versiones, probar productos que estan en desarrollo y los bajo directamente desde algun svn.

Ademas, trabajando con otras personas es bien simple replicar todo el entorno.

Inclusive para actualizar el mismo Plone. Vienen saliendo actualizaciones de Plone muy seguido, si empezaras un desarrollo de 5 o 6 meses, con el instalador unificado, terminarias tu desarrollo con una version un poco atrasada y necesitarias probar todo devuelta. Con el buildout, vas desarrollando con el Plone estable mas alto.

Pero eso lo se ahora que lo uso hace un tiempo, cuando lo empeze a usar fue simplemente siguiendo la corriente de los que saben :P

¿Dónde puedo ampliar información sobre esto? Es que he buscado "armar
puntos de montaje de ZODB" en Google y no veo nada relevante (aparte de
este mismo tema de debate). ¿Tiene otro nombre en español? ¿Cómo se
diría en inglés?

http://plone.org/documentation/how-to/mount-zeo-into-plonesite
http://plone.org/documentation/how-to/multiple-plone-sites-per-zope-instance-using-separate-data-fs-files-for-each-one

> Obviamente que para reducir la posibilidad de problemas, deberian tener
> replicados los sitios que tienen en produccion, y antes de poner en
> produccion cualquier cosa, probarlo en los sitios replicados para
> desarrollo.

Entiendo que no te refieres a sitios espejo, sino a sitios de prueba con
las mismas versiones de software (python, zope, plone y productos).
¿Correcto?

correcto
 

> Y supongo que lo "correcto" seria que tengan los Test de
> unidad y funcionales para cada producto que agreguen a produccion

¡Guau! Esto tendré que investigar qué es...

http://plone.org/documentation/tutorial/testing
 

Gracias por la ayuda y abrazos:

Saludos
 

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

--
Santiago Videla
www.revolucionesweb.com.ar
http://www.linkedin.com/in/svidela

Sigue la mata dando de que hablar siempre abajo y a la izquierda donde el pensamiento que se hace corazón resplandece con la palabra sencilla y humilde que l@s tod@s somos.

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[spanish]

Santiago Videla escribió:
>     > Personalmente, me resulta util para empezar, NO usar el instalador
>     > unificado.
>
> (...)
>
> Con el buildout, vas desarrollando con el Plone estable mas alto.
>
> Pero eso lo se ahora que lo uso hace un tiempo, cuando lo empeze a usar
> fue simplemente siguiendo la corriente de los que saben :P

Por lo que he leído en el libro de Martin Aspelli (he seguido vuestros
sabios consejos), los buildouts pueden crearse de tres formas:

1.- Con sus propias instalaciones de Zope2 y Productos Plone.

2.- Compartiendo ambos tipos de recursos.

3.- Compartiendo uno solo de estos dos tipos de recursos.

Una diferencia evidente entre estas tres opciones, es el tamaño de los
respectivos buildouts.

¿Hay otras diferencias relevantes en cuanto al consumo de recursos del
servidor dedicado (RAM, CPU, ancho de banda,...)?

Quienes usáis buildouts: ¿cuál de estas formas de creación usáis? ¿Por qué?

Aparte, pero relacionado con el fondo de la cuestión: según tengo
entendido, hay algunos productos incompatibles entre sí (eso me han
dicho en relación con Plone Survey y Press Room). Si el administrador de
un sitio Plone instalara dos productos incompatibles o realizara
cualquier otra acción que generara un malfuncionamiento de su sitio, ¿se
verían afectados el resto de sitios de los buildouts que compartan los
mismos Productos Plone? Imagino que no, pero más vale preguntar a los
expertos y estar seguro...

>     ¿Dónde puedo ampliar información sobre esto? Es que he buscado "armar
>     puntos de montaje de ZODB" en Google y no veo nada relevante (aparte de
>     este mismo tema de debate). ¿Tiene otro nombre en español? ¿Cómo se
>     diría en inglés?
>
>
> http://plone.org/documentation/how-to/mount-zeo-into-plonesite
> http://plone.org/documentation/how-to/multiple-plone-sites-per-zope-instance-using-separate-data-fs-files-for-each-one

Finalmente creo que no necesitaré esto, ya que si uso buildouts cada uno
tendrá su propio Data.fs. ¿Correcto?

Gracias por la ayuda y abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Mikel Larreategi]

Manuel Gualda Caballero(e)k dio:

> Santiago Videla escribió:
>>     > Personalmente, me resulta util para empezar, NO usar el instalador
>>     > unificado.
>>
>> (...)
>>
>> Con el buildout, vas desarrollando con el Plone estable mas alto.
>>
>> Pero eso lo se ahora que lo uso hace un tiempo, cuando lo empeze a usar
>> fue simplemente siguiendo la corriente de los que saben :P
>
> Por lo que he leído en el libro de Martin Aspelli (he seguido vuestros
> sabios consejos), los buildouts pueden crearse de tres formas:
>
> 1.- Con sus propias instalaciones de Zope2 y Productos Plone.
>
> 2.- Compartiendo ambos tipos de recursos.
>
> 3.- Compartiendo uno solo de estos dos tipos de recursos.
>
> Una diferencia evidente entre estas tres opciones, es el tamaño de los
> respectivos buildouts.
>
> ¿Hay otras diferencias relevantes en cuanto al consumo de recursos del
> servidor dedicado (RAM, CPU, ancho de banda,...)?
>
> Quienes usáis buildouts: ¿cuál de estas formas de creación usáis? ¿Por qué?

Yo no comparto ni instalaciones de Productos ni instalaciones de Zope.
La principal razón es que la configuración es más fácil :)

La segunda es la reproducibilidad (toma palabro). En mi máquina local no
tendría problemas para compartir instalaciones de zope, pero cuando subo
el buildout al servidor de producción, como allí sólo va a haber un
buildout (un buildout = 1 plone en mi caso), la instalación de zope se
tiene que hacer de todas formas, por lo que no tampoco cuesta nada tener
esa propia instalación también en local.

>
> Aparte, pero relacionado con el fondo de la cuestión: según tengo
> entendido, hay algunos productos incompatibles entre sí (eso me han
> dicho en relación con Plone Survey y Press Room). Si el administrador de
> un sitio Plone instalara dos productos incompatibles o realizara
> cualquier otra acción que generara un malfuncionamiento de su sitio, ¿se
> verían afectados el resto de sitios de los buildouts que compartan los
> mismos Productos Plone? Imagino que no, pero más vale preguntar a los
> expertos y estar seguro...

En teoría no.

>
> Finalmente creo que no necesitaré esto, ya que si uso buildouts cada uno
> tendrá su propio Data.fs. ¿Correcto?
>

Correcto.


Mikel

--
Mikel Larreategi
[hidden email]

CodeSyntax
Azitaingo Industrialdea 3 K
E-20600 Eibar
Tel: [phone]

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[spanish]

Mikel Larreategi escribió:

> Manuel Gualda Caballero(e)k dio:
>> Quienes usáis buildouts: ¿cuál de estas formas de creación usáis? ¿Por
>> qué?
>
> Yo no comparto ni instalaciones de Productos ni instalaciones de Zope.
> La principal razón es que la configuración es más fácil :)
>
> La segunda es la reproducibilidad (toma palabro). En mi máquina local no
> tendría problemas para compartir instalaciones de zope, pero cuando subo
> el buildout al servidor de producción, como allí sólo va a haber un
> buildout (un buildout = 1 plone en mi caso), la instalación de zope se
> tiene que hacer de todas formas, por lo que no tampoco cuesta nada tener
> esa propia instalación también en local.

Gracias, Mikel.

Voy a optar por lo siguiente:

Buildouts 100% autónomos para los sitios de proyectos en los que estamos
implicadas muchas organizaciones o que requieren productos adicionales
complejos; y compartir Zope2 y/o Products en el resto.

Así podré familiarizarme con las distintas opciones, reduciendo al
mínimo la gravedad de los daños potenciales.

O sea: que os voy a dar la lata desde todos los puntos de vista posibles.

\ ;-D

Abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Mikel Larreategi]

Manuel Gualda Caballero(e)k dio:
> Gracias, Mikel.
>
> Voy a optar por lo siguiente:
>
> Buildouts 100% autónomos para los sitios de proyectos en los que estamos
> implicadas muchas organizaciones o que requieren productos adicionales
> complejos; y compartir Zope2 y/o Products en el resto.

Añado una cosita más:

Utiliza SVN (o CVS o git o lo que sea), para guardar los archivos del
buildout, crea tags cuando subas el buildout a producción y tal.
Funciona como si fuera un módulo más del proyecto. Además, con ZopeSkel
lo puedes hacer automágicamente:

$ paster create -t plone3_buildout --svn-repository=http://my/svn/

Mikel


--
Mikel Larreategi
[hidden email]

CodeSyntax
Azitaingo Industrialdea 3 K
E-20600 Eibar
Tel: [phone]

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[spanish]

Mikel Larreategi escribió:
> Manuel Gualda Caballero(e)k dio:
>> Gracias, Mikel.
>>
>> Voy a optar por lo siguiente:
>>
>> Buildouts 100% autónomos para los sitios de proyectos en los que estamos
>> implicadas muchas organizaciones o que requieren productos adicionales
>> complejos; y compartir Zope2 y/o Products en el resto.

La estructura será la siguiente (para teclear menos):

/home/plone/a/buildouts-a
/home/plone/c/p/buildouts-cp
/home/plone/c/pz/buildouts-cpz
/home/plone/c/z/buildouts-cz
/home/zope/*

a = autónomos
c = comparten
p = Products
z = Zope
* = versiones instaladas

Entiendo que si en algún momento quisiera cambiar de "categoría" un
buildout (por ejemplo, convertir en autónomo uno que comparta Zope),
sólo tendría que modificar su buildout.cfg y ejecutar bin/buildout
(teniendo cuidado con el tema de las versiones). ¿Correcto?

Una pregunta más: ¿Cuál sería la ubicación ideal para los Products que
vayan a ser compartidos (lo que hay que indicar tras el "paster create
-t plone3_buildout ...")? ¿Un buildout iniciado y en producción? ¿Un
buildout iniciado "virgen"? ¿Un buildout sin iniciar? ¿Algún directorio
de Zope? ¿Una referencia externa (find-link o similar)? ¿Otra ubicación?

> Añado una cosita más:
>
> Utiliza SVN (o CVS o git o lo que sea), para guardar los archivos del
> buildout,

Aunque nunca lo he usado, entiendo que SVN es la opción de futuro, ¿no?.
Así que he empezado a estudiar los manuales y demás.

> crea tags cuando subas el buildout a producción y tal.
> Funciona como si fuera un módulo más del proyecto. Además, con ZopeSkel
> lo puedes hacer automágicamente:
>
> $ paster create -t plone3_buildout --svn-repository=http://my/svn/

¿Esto se hace para crear un repositorio general dentro del cual haya un
proyecto por cada buildout o hay que hacerlo para cada buildout por
separado? ¿Se puede hacer sobre un buildout que ya exista o debe de
hacerse antes o durante la creación del mismo? ¿Tengo que hacerlo en mi
portátil, en el servidor dedicado o en ambas máquinas?

Imagino que ZopeSkel pondrá los nombres del SVN en inglés (trunk,
branches y tags), pero me gustaría saber si pueden estar en español
(tronco, ramas y revisiones): no es para los sitios web, sino para usar
Subversion en otras cosas (pertenezco a varias plataformas ciudadanas a
las que les vendría muy bien usar SVN para ciertas cosas, pero la mayor
parte de los representantes de asociaciones tienen de 45 años para
arriba y el inglés no es su fuerte -en aquella época a los que tenían la
suerte de poder estudiar, les enseñaban francés-).

Gracias y abrazos:

Manuel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Mikel Larreategi]

Manuel Gualda Caballero(e)k dio:
>> Añado una cosita más:
>>
>> Utiliza SVN (o CVS o git o lo que sea), para guardar los archivos del
>> buildout,
>
> Aunque nunca lo he usado, entiendo que SVN es la opción de futuro, ¿no?.
> Así que he empezado a estudiar los manuales y demás.

Yo utilizo SVN.

>
>> crea tags cuando subas el buildout a producción y tal.
>> Funciona como si fuera un módulo más del proyecto. Además, con ZopeSkel
>> lo puedes hacer automágicamente:
>>
>> $ paster create -t plone3_buildout --svn-repository=http://my/svn/
>
> ¿Esto se hace para crear un repositorio general dentro del cual haya un
> proyecto por cada buildout o hay que hacerlo para cada buildout por
> separado? ¿Se puede hacer sobre un buildout que ya exista o debe de
> hacerse antes o durante la creación del mismo? ¿Tengo que hacerlo en mi
> portátil, en el servidor dedicado o en ambas máquinas?

Eso simplemente crea una carpeta con un archivo buildout.cfg y todo lo
que necesita para ejecutar el buildout (bootstrap.py etc) y sube esa
carpeta al SVN, no hace nada más.

>
> Imagino que ZopeSkel pondrá los nombres del SVN en inglés (trunk,
> branches y tags), pero me gustaría saber si pueden estar en español
> (tronco, ramas y revisiones): no es para los sitios web, sino para usar
> Subversion en otras cosas (pertenezco a varias plataformas ciudadanas a
> las que les vendría muy bien usar SVN para ciertas cosas, pero la mayor
> parte de los representantes de asociaciones tienen de 45 años para
> arriba y el inglés no es su fuerte -en aquella época a los que tenían la
> suerte de poder estudiar, les enseñaban francés-).

Los nombres trunk, tags y branches son una convención que se utiliza
cuando utilizas SVN, de jecho ZopeSkel utiliza esa convención cuando
subes un proyecto al SVN, pero nada te impide utilizar otros nombres.


Mikel


--
Mikel Larreategi
[hidden email]

CodeSyntax
Azitaingo Industrialdea 3 K
E-20600 Eibar
Tel: [phone]

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur

[Israel Saeta Pérez]

2008/11/6 Manuel Gualda Caballero wrote:
> Aunque nunca lo he usado, entiendo que SVN es la opción de futuro, ¿no?.
> Así que he empezado a estudiar los manuales y demás.

Pregúntale a Linus Torvalds a ver qué te dice... :P

No, en serio, SVN es el que más establecido está actualmente, pero te
recomiendo echar un ojo a alternativas como git, mercurial o bazaar y
elegir el que más cómodo te parezca.

Respecto a compartir productos entre varios buildouts, tienes varias
alternativas, según yo lo veo:
 1) Usar SVN Externals, que es lo que hacen en Plone, si no me equivoco.
 2) Empaquetar tus productos como eggs de Python e instalarlos en
todos los buildouts que lo necesiten, de forma parecida a cómo
instalas "eggified products" como Products.RichDocument mediante
buildout.

Espero que te sirva.

-- Israel

_______________________________________________
Plone-ConoSur mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-conosur