2015-01-02 2 views
0

Кукольный будет содержать все определенные типы, объявленные внутри другого определенного типа (или класса). Насколько я понимаю, это означает, что любой заявленный источник будет зависеть от контейнера. Это приведет к петле зависимостей:Puppet: объявить ресурс без содержания

define user { 
} 
define bar { 
    user { $name: } 
    -> 
    Bar[$name] 
} 

bar { 'foo': } 
 
Error: Could not apply complete catalog: Found 1 dependency cycle: 
(User[foo] => Bar[foo] => User[foo]) 

Есть ли способ избежать этого? У меня есть один конкретный случай, где я бы предпочел, чтобы после объявления Bar[$name] было объявлено также User[$name], но Bar[$name] зависит от User[$name], а не наоборот. В основном такое же поведение, как и require, но для зависимости определенного типа.

Есть ли какой-либо способ сделать это, или это единственное решение, чтобы иметь манифест об объявлении Bar[$name] объявить User[$name], а также (и затем добавить зависимость от любого тела bar или в объявлении манифеста?


более реалистичный пример:

define servize {} 
define appserver { 
    user { $name: } 
    -> 
    servize { $name: } 
} 

appserver { 'app': } 

# the deploy application needs a directory owned by itself on startup 
file { '/tmp/foobar': 
    ensure => directory, 
    owner => 'app', # auto-require 
} 
-> 
Appserver['app'] 
+0

Не совсем вычислит. 'User [$ name]' объявляется 'Bar [$ name]', поэтому вам действительно нужно иметь * все ресурсы, объявленные * Bar [$ name] '*, которые не являются *' User [$ name] 'зависит от' User [$ name] ', правильно? Не будет ли прямо выражать это? –

+0

@FelixFrank Я уже это делаю. Но зависимость 'user' от' appserver' по-прежнему остается проблемой. Мой пример немного упрощен. Проверьте мое редактирование. В этом случае вы можете разбить цикл, добавив зависимость вместо «Servize» (и далее разрушите абстракцию ...), но в более сложных сценариях я иногда по-прежнему получаю циклы из зависимостей службы. Просто не нужно и нежелательно «зависящий от пользователя» сервер приложений. Хотелось бы, чтобы это был вариант создания/обеспечения_ресурсов, который создавал бы ресурсы и позволял им плавать в графе (например, классы). – Artefacto

ответ

1

Прежде всего, пожалуйста, не переопределять встроенные типы Список всех встроенных типов:.. https://docs.puppetlabs.com/references/latest/type.html

Если у вас есть только один конкретный случай, когда $ Bar[$name] зависит от User[$name] вы можете удалить пользователя из определения бара и создать ordered_bar

define ordered_bar { 
    user { $name: } 
    -> 
    bar {$name : } 
    } 

Что вам нужно всего лишь создать экземпляр ordered_bar.
Просьба также ознакомиться с документом об упорядочении ресурсов в кукольном виде: https://docs.puppetlabs.com/learning/ordering.html

+0

Это усиливает пословицу, что все проблемы действительно могут быть решены с помощью дополнительного слоя косвенности. Благодарю. – Artefacto

0

Вы можете создать проблемный ресурс как виртуальный. Возможность этого зависит от структуры вашего уровня данных.

define servize {} 

user { 'app': } 

define appserver { 
    User<| title == $name |> 
    -> 
    servize { $name: } 
} 

appserver { 'app': } 

# the deploy application needs a directory owned by itself on startup 
file { '/tmp/foobar': 
    ensure => directory, 
    owner => 'app', # still auto-require, but no ill effect 
} 
-> 
Appserver['app'] 
Смежные вопросы