2012-06-01 24 views
5

Próbuję rozwiązać następujący problem z Puppet:Zamawianie biegunów dla klas opcjonalnych

Mam wiele węzłów. Każdy węzeł zawiera kolekcję klas. Na przykład istnieje klasa mysql i klasa webserver. node1 to tylko serwer WWW, node2 to webserver + mysql.

Chcę określić, że jeśli węzeł ma zarówno serwer WWW, jak i mysql, instalacja mysql nastąpi przed serwerem WWW. Nie można mieć zależności Class[mysql] -> Class[webserver], ponieważ obsługa MySQL jest opcjonalna.

Próbowałem używać etapów, ale wydają się wprowadzać zależności między moimi klasami, więc jeśli mam np. to:

Stage[db] -> Stage[web] 
class { 
'webserver': 
    stage => web ; 
'mysql': 
    stage => db ; 
} 

i obejmują klasę serwera WWW w moim węzła

node node1 { 
    include webserver 
} 

.. klasa mysql zostaje zawarte, jak również! Nie tego chcę.

Jak mogę zdefiniować porządek na lekcjach opcjonalnych?

Edycja: tutaj jest rozwiązanie:

class one { 
    notify{'one':} 
} 

class two { 
    notify{'two':} 
} 

stage { 'pre': } 

Stage['pre'] -> Stage['main'] 

class { 
    one: stage=>pre; 
    # two: stage=>main; #### BROKEN - will introduce dependency even if two is not included! 
} 

# Solution - put the class in the stage only if it is defined 
if defined(Class['two']) { 
    class { 
      two: stage=>main; 
    } 
} 

node default { 
    include one 
} 

Wynik:

notice: one 
notice: /Stage[pre]/One/Notify[one]/message: defined 'message' as 'one' 
notice: Finished catalog run in 0.04 seconds 

~

+0

Dlaczego twoja klasa serwera sieciowego w ogóle zależy od twojej klasy mysql? Jaka jest rzeczywista zależność? –

+0

@CodeGnome Próbowałem wyjaśnić to bardzo prosto. Mam etapy w przybliżeniu równoważne "nagiej maszynie" - "cała sieć w górę" - "wszystkie dostępne źródła danych" - "różne narzędzia wsparcia lalek zainstalowane" - "teraz możemy wykonać rzeczywistą pracę". –

Odpowiedz

5

Jeśli Class [mysql] nie jest obowiązkowe, to można spróbować sprawdzenie czy istnieje z określoną funkcją():

if defined(Class['mysq'l]) { 
    Class['mysql'] -> Class['webserver'] 
} 

Oto niektóre przykładowy kod Kiedyś to sprawdzić na:

class optional { 
    notify{'Applied optional':} 
} 

class afterwards { 
    notify{'Applied afterwards':} 
} 

class another_optional { 
    notify{'Applied test2':} 
} 

class testbed { 

    if defined(Class['optional']) { 
      notify{'You should see both notifications':} 
      Class['optional'] -> Class['afterwards'] 
    } 


    if defined(Class['another_optional']) { 
      notify{'You should not see this':} 
      Class['another_optional'] -> Class['afterwards'] 
    } 
} 

node default { 
    include optional 
    include afterwards 
    include testbed 
} 

Po wykonaniu z „lalek zastosować test.pp”, generuje to wyjście:

notice: You should see both notifications 
notice: /Stage[main]/Testbed/Notify[You should see both notifications]/message: defined 'message' as 'You should see both notifications' 
notice: Applied optional 
notice: /Stage[main]/Optional/Notify[Applied optional]/message: defined 'message' as 'Applied optional' 
notice: Applied afterwards 
notice: /Stage[main]/Afterwards/Notify[Applied afterwards]/message: defined 'message' as 'Applied afterwards' 
notice: Finished catalog run in 0.06 seconds 

testowałem z lalek 2.7 .1 na Ubuntu 11.10

+0

Wygląda to bardzo obiecująco. Pozwól mi przetestować to podejście etapami - jeśli zdefiniuje się klasę, ustawię jej etap ... Myślę, że to by się świetnie sprawdziło! Przyjmuję to rozwiązanie, gdy już to przetestuję. –