Вопросы Теги

puppetlabs-postgresql: как установить globals правильно без дублирующихся определений

документация puppetlabs-postgresql рекомендует установить значения в postgresql:: globals как так:

class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}

Однако это не работает:

class { 'postgresql::client: }
class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}

Поскольку postgresql:: клиент наследовался postgresql:: параметры, который наследовался postgresql:: globals. Таким образом, когда это добирается до явного инстанцирования postgresql:: класс globals, это жалуется на дублирующееся определение.

изменяя порядок, это действительно работает:

class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}
class { 'postgresql::client: }

Однако в реальном использовании, моем инстанцировании postgresql:: клиент и postgresql:: сервер находится в различных классах, связанных с классами сервера, которые я использую, и я действительно не хочу создавать необходимое упорядочивание для тех классов. Кроме того, я хочу, чтобы globals определения относились к postgresql:: клиент даже на серверах, которые не выполняют postgresql:: сервер.

Если бы мы использовали марионетку 3.x, то я определил бы необходимые значения globals в hiera, но мы находимся все еще на марионеточных 2.7.

Существует ли способ зафиксировать это, не изменяя puppetlabs распределение? Я в настоящее время думаю, что это может гарантировать отчет об ошибках к puppetlabs, но все еще задаться вопросом, пропускаю ли я просто простое решение.

Править: считав вход @FelixFrank, я создал отчет об ошибках в https://tickets.puppetlabs.com/browse/MODULES-1466.

1
задан 26 October 2014 в 19:38
1 ответ

Да, Hiera будет лучшим решением. Обратите внимание, что вы можете (и должны) добавить Hiera в Pupet 2.7.x в форме плагина.

За исключением этого, ваши возможности ограничены. Связь требует между любыми двумя классами не будет иметь эффекта . Напротив, обратите внимание, что следующий рефакторинг вашего рабочего манифеста также приводит к ошибке: 

class { 'postgresql::server': }
<-
class { 'postgresql::globals':
    encoding => 'UTF8',
    locale   => 'en_NG',
}

Причина в том, что проблема основана на порядке анализа или порядке оценки - порядок, в котором компилятор манифеста встречает объявления классов. Параметры require / before (и стрелки цепочки) только добавляют отношения к создаваемому каталогу для использования марионеточным агентом .

В принципе, вам нужно будет убедиться, что ваш собственный класс сервера PostgreSQL всегда оценивается перед классом клиента, например 

role::posgre_server_with_client {
    include profiles::postgre_server
    include profiles::postgre_client
}

Такой порядок не всегда может быть гарантирован в сложных манифестах (которые могут включать , особенно клиентские функции из различных контекстов). Таким образом, я думаю, что есть веские основания объявлять это ошибкой в ​​модуле. Поскольку паттерны, которые приводят к проблеме, довольно распространены (я думаю), может быть причина подвергнуть сомнению текущую практику проектирования модулей в целом.

Я постараюсь собрать еще несколько мнений сообщества по этому поводу.

1
ответ дан 4 December 2019 в 00:16

Теги

Похожие вопросы