Difference: VOMSEticsConfiguration (1 vs. 6)

Revision 62009-11-06 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

Line: 59 to 59
 
  • Scegliere glite_branch_3_2_0 come project config.
  • Scegliere Scientific Linux 5 32bit e Scientific Linux 5 X86_64 come piattaforme.
Changed:
<
<
RemoteBuildGL32.png
>
>
GL32_remote_build.png
 

Come lockare le configurazioni

Lockare le conf per glite 3.1 contro glite_branch_3_1_0. Lockare le conf per glite 3.2 contro glite_branch_3_2_0.

Changed:
<
<
-- AndreaCeccanti - 03 Nov 2009
>
>
-- AndreaCeccanti - 2009-11-06
 

META FILEATTACHMENT attachment="RemoteBuildSubmit.png" attr="" comment="Remote Build Instructions" date="1220882745" name="RemoteBuildSubmit.png" path="RemoteBuildSubmit.png" size="116950" stream="RemoteBuildSubmit.png" user="Main.AndreaCeccanti" version="1"
Added:
>
>
META FILEATTACHMENT attachment="GL32_remote_build.png" attr="" comment="" date="1257505970" name="GL32_remote_build.png" path="GL32_remote_build.png" size="119755" stream="GL32_remote_build.png" tmpFilename="/usr/tmp/CGItemp13116" user="AndreaCeccanti" version="1"

Revision 52009-11-03 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

Changed:
<
<

Gestione delle configurazione dei componenti

>
>

Gestione delle configurazione per i componenti

  Ogni componente del sottosistema dovrebbe avere due configurazioni per ogni release, una da lockare contro la project configuration glite 3.1 e una contro glite 3.2.
Line: 23 to 23
 
  1. Non lockare la configurazione sino a che non si e' ottenuto un build funzionante
  2. Aggiornare la tabella qui in modo che contenga l'ultima configurazione del componente per il build 3.1 e 3.2
Changed:
<
<

Ricetta generale per il sottosistema

>
>

Ricetta generale per le configurazioni da release del sottosistema

 
  1. Clonare l'ultima configurazione funzionante di sottosistema, e aggiornare il numero di versione. Se si tratta di una configurazione glite 3.2, ricordarsi di aggiungere il suffisso _GL32.
  2. Aggiornare i sottocomponenti a cui la configurazione fa riferimento in maniera coerente col nome della configurazione, ovvero linkando solo configurazioni col suffisso _GL32_ ad una configurazione glite 3.2, e configurazioni senza suffisso ad una configurazione glite 3.1.
  3. Lanciare un remote build della configurazione impostando la project config di riferimento (glite_branch_3_1_0 se si tratta di una conf glite 3.1, glite_branch_3_2_0 se si tratta di glite 3.2).
  4. Non lockare la configurazione sino a che non si e' ottenuto un build funzionante
Changed:
<
<
  1. Aggiornare la tabella qui in modo che contenga l'ultima configurazione del componente per il build 3.1 e 3.2
>
>
  1. Aggiornare la tabella qui in modo che contenga l'ultima configurazione del componente per il build 3.1 e 3.2

Ricetta generale per le configurazioni di sviluppo del sottosistema

Dobbiamo mantenere due configurazioni di sottosistema unlocked che servono per gestire lo sviluppo per glite 3.1 e glite 3.2. Queste configurazioni si chiameranno:

  • glite_voms_branch_3_1_0
  • glite_voms_branch_3_2_0
 
Added:
>
>
e conterranno le versioni piu' recenti che buildano dei componenti cosi' come prese dalle ultime configurazioni di release per glite 3.1 e glite 3.2. Se usiamo solo queste configurazioni (o configurazioni clonate da queste che poi vengono distrutte una volta che buildano e si fa il merge back delle modifiche su queste) non abbiamo bisogno di impazzire per sapere qual'e' l'ultima conf di un componente da linkare alla conf di sottosistema in qualsiasi momento. Ripeto: queste configurazioni non vengono mai lockate, e servono a testare i build prima delle release. L'obiettivo principale e' evitare l'esplosione di configurazioni di sviluppo/testing che abbiamo visto ultimamente.
 

Come sottomettere un remote build

Revision 42009-11-03 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

Gestione delle configurazione dei componenti

Changed:
<
<
Ogni componente del sottosistema dovrebbe avere due configurazione per ogni release, una da lockare contro la project configuration glite 3.1 e una contro glite 3.2. La configurazione per glite 3.2 si distingue da quella per 3.1 grazie al suffisso _GL32.
>
>
Ogni componente del sottosistema dovrebbe avere due configurazioni per ogni release, una da lockare contro la project configuration glite 3.1 e una contro glite 3.2.

N.B.: La configurazione per glite 3.2 si distingue da quella per 3.1 grazie al suffisso _GL32.

  Esempio:
Line: 14 to 15
 
Voms admin server 2.0.18-1 voms-admin-server_R_2_0_18_1 voms-admin-server_R_2_0_18_1_GL32
Changed:
<
<

Glite 3.1

>
>

Ricetta generale per il componente

  1. Clonare l'ultima configurazione funzionante, e aggiornare il numero di versione. Se si tratta di una configurazione glite 3.2, ricordarsi di aggiungere (o mantenere) il suffisso _GL32.
  2. Aggiornare il tag o branch a cui la configurazione fa riferimento in maniera coerente col nome della configurazione.
  3. Lanciare un remote build della configurazione impostando la project config di riferimento (glite_branch_3_1_0 se si tratta di una conf glite 3.1, glite_branch_3_2_0 se si tratta di glite 3.2).
  4. Non lockare la configurazione sino a che non si e' ottenuto un build funzionante
  5. Aggiornare la tabella qui in modo che contenga l'ultima configurazione del componente per il build 3.1 e 3.2

Ricetta generale per il sottosistema

  1. Clonare l'ultima configurazione funzionante di sottosistema, e aggiornare il numero di versione. Se si tratta di una configurazione glite 3.2, ricordarsi di aggiungere il suffisso _GL32.
  2. Aggiornare i sottocomponenti a cui la configurazione fa riferimento in maniera coerente col nome della configurazione, ovvero linkando solo configurazioni col suffisso _GL32_ ad una configurazione glite 3.2, e configurazioni senza suffisso ad una configurazione glite 3.1.
  3. Lanciare un remote build della configurazione impostando la project config di riferimento (glite_branch_3_1_0 se si tratta di una conf glite 3.1, glite_branch_3_2_0 se si tratta di glite 3.2).
  4. Non lockare la configurazione sino a che non si e' ottenuto un build funzionante
  5. Aggiornare la tabella qui in modo che contenga l'ultima configurazione del componente per il build 3.1 e 3.2
 
Deleted:
<
<

Glite 3.2

 
Added:
>
>

Come sottomettere un remote build

 
Added:
>
>

Glite 3.1

  • Scegliere glite_branch_3_1_0 come project config.
  • Scegliere CERN SLC4 32 e CERN SLC4 X86_64 come piattaforme.
 
Deleted:
<
<
  1. Clonare l'ultima conf funzionante (i.e. che builda correttamente su tutte le piattaforme) del sottosistema org.glite.voms.
  2. Clonare l'ultima conf funzionante dei pacchetti che devono costituire il sottosistema. Non e' necessario aggiornare le dipendenze fra i pacchetti all'interno del sottosistema, basta aggiornare il TAG del CVS per quei pacchetti che ne hanno bisogno, come descritto nella tabella in fondo alla pagina.
  3. Linkare le nuove configurazioni a quella di sottosistema
  4. Lanciare un remote build per le piattaforme slc4_ia32_gcc346 e slc4_ia64_gcc346, mettendo come project config glite-branch-3_1_0, come illustrato qui sotto:
 RemoteBuildSubmit.png
Changed:
<
<

Tabella moduli e Tag

nome conf Ulimo TAG CVS funzionante N. B.
org.glite.security.voms glite-security-voms_R_1_8_7
org.glite.security.voms-api-java glite-security-voms_R_1_8_7 usa tag sul codice sorgente di org.glite.security.voms
org.glite.security.voms-mysql glite-security-voms-mysql_R_3_0_7  
org.glite.security.voms-oracle glite-security-voms-oracle_R_3_1_2  
org.glite.security.voms-api <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-c <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-cpp <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-noglobus <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-clients <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-server <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-config <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-admin glite-security-voms-admin_R_2_0_15_1 per l'admin basta solo questo modulo
>
>

Glite 3.2

  • Scegliere glite_branch_3_2_0 come project config.
  • Scegliere Scientific Linux 5 32bit e Scientific Linux 5 X86_64 come piattaforme.

RemoteBuildGL32.png

Come lockare le configurazioni

Lockare le conf per glite 3.1 contro glite_branch_3_1_0. Lockare le conf per glite 3.2 contro glite_branch_3_2_0.

 
Added:
>
>
-- AndreaCeccanti - 03 Nov 2009
 
Deleted:
<
<
-- AndreaCeccanti - 08 Sep 2008
 
META FILEATTACHMENT attachment="RemoteBuildSubmit.png" attr="" comment="Remote Build Instructions" date="1220882745" name="RemoteBuildSubmit.png" path="RemoteBuildSubmit.png" size="116950" stream="RemoteBuildSubmit.png" user="Main.AndreaCeccanti" version="1"

Revision 32009-11-03 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

Added:
>
>

Gestione delle configurazione dei componenti

Ogni componente del sottosistema dovrebbe avere due configurazione per ogni release, una da lockare contro la project configuration glite 3.1 e una contro glite 3.2. La configurazione per glite 3.2 si distingue da quella per 3.1 grazie al suffisso _GL32.

Esempio:

Componente Conf glite 3.1 Conf glite 3.2
Voms admin server 2.0.18-1 voms-admin-server_R_2_0_18_1 voms-admin-server_R_2_0_18_1_GL32

Glite 3.1

Glite 3.2

 
  1. Clonare l'ultima conf funzionante (i.e. che builda correttamente su tutte le piattaforme) del sottosistema org.glite.voms.
  2. Clonare l'ultima conf funzionante dei pacchetti che devono costituire il sottosistema. Non e' necessario aggiornare le dipendenze fra i pacchetti all'interno del sottosistema, basta aggiornare il TAG del CVS per quei pacchetti che ne hanno bisogno, come descritto nella tabella in fondo alla pagina.
  3. Linkare le nuove configurazioni a quella di sottosistema

Revision 22009-11-03 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

Revision 12008-09-08 - AndreaCeccanti

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="InternalDiscussion"

Regole per la creazione delle configurazioni VOMS

  1. Clonare l'ultima conf funzionante (i.e. che builda correttamente su tutte le piattaforme) del sottosistema org.glite.voms.
  2. Clonare l'ultima conf funzionante dei pacchetti che devono costituire il sottosistema. Non e' necessario aggiornare le dipendenze fra i pacchetti all'interno del sottosistema, basta aggiornare il TAG del CVS per quei pacchetti che ne hanno bisogno, come descritto nella tabella in fondo alla pagina.
  3. Linkare le nuove configurazioni a quella di sottosistema
  4. Lanciare un remote build per le piattaforme slc4_ia32_gcc346 e slc4_ia64_gcc346, mettendo come project config glite-branch-3_1_0, come illustrato qui sotto:
RemoteBuildSubmit.png

Tabella moduli e Tag

nome conf
<-- -->
Sorted ascending
Ulimo TAG CVS funzionante N. B.
org.glite.security.voms glite-security-voms_R_1_8_7
org.glite.security.voms-admin glite-security-voms-admin_R_2_0_15_1 per l'admin basta solo questo modulo
org.glite.security.voms-api <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-c <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-cpp <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-java glite-security-voms_R_1_8_7 usa tag sul codice sorgente di org.glite.security.voms
org.glite.security.voms-api-noglobus <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-clients <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-config <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-mysql glite-security-voms-mysql_R_3_0_7  
org.glite.security.voms-oracle glite-security-voms-oracle_R_3_1_2  
org.glite.security.voms-server <nome-modulo>_R_1_8_3 non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente

-- AndreaCeccanti - 08 Sep 2008

META FILEATTACHMENT attachment="RemoteBuildSubmit.png" attr="" comment="Remote Build Instructions" date="1220882745" name="RemoteBuildSubmit.png" path="RemoteBuildSubmit.png" size="116950" stream="RemoteBuildSubmit.png" user="Main.AndreaCeccanti" version="1"
 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback