Лезет в чужие стэйджи

1) Ты, похоже, не понимаешь что такое «наследование». У тебя нода mail-new.example.local наследуется от «default» ( ИМХО, я бы вообще так не делал, но не суть важно ). И получает все классы, определённые в node default, в т.ч. class fedora-nginx.

2) Классы - всего лишь средство ИМЕНОВАТЬ часть конфига, а не определить без реализации. Т.е. если ты в ноде написал

package {«nginx» : [.....] }

и

class fedora-nginx { package {«nginx» : [.....] } }

, то это одно и тоже. НО. Если ты используешь ноды, а не один общий конфиг, то классы, определённы на БЕЗНОДОВОМ уровне, не применяются к нодам. Т.е. если ты просто хочешь подключить описания классов, но не применять их, import'ы и include'ы делай вне описания нод:

import 'dist/fedora.pp'

node default {
 [... ]
}

node "nginx.example.local" {
 [...]
  include fedora-nginx
}

2-й пункт написал сумбурно, нужно пояснение. Если ты хочешь определить классы, а применять только к отдельным нодам, определяй их вне описания нод, а в описаниях нод - include.Классы, определённые вне нод, сами по себе, без include, применяться не будут.

Классы, определённые внутри ноды, автоматически применяются к самой ноде и к её потомкам

З.Ы. ЕМНИП, state'и только определяют порядок выполнения правил. Сами по себе они ничего в манифест ноды не включают.

Спасибо - стало понятней =)

что-касается ноды default - по задумке я туда скидывал общие для всех нод пакеты/настройки (типа mc/ssh/ntpd)

видимо чтоб избежать такой фигни - мне надо сделать

class fedora-default { ... }
node ''foo.bar" {
    include fedora-default
}

вместо inherits default

Попробую! Спасибо!

P.S.: А стейты мне и нужны, что бы определять порядок применения классов при первоначальном развертывании. Типа: Пакеты -> Юзеры -> Файлы -> Сервайсы

А то без них пуппет срёт в консоль сообщениями типа - не могу применить правила на файлы. т.к. ещё нет юзера/не установлен пакет. И приходится горогить require'ы =)

Скорее, вынести import 'dist/fedora.pp' из node default, раз тебе это наследование нужно.

Никак не могу понять, почему теперь паппет лезет в чужую ноду:

site.pp - http://pastebin.com/1vCDW5tk stages.pp - http://pastebin.com/4bj6u698 fedora.pp - http://pastebin.com/y7M6kXV3 db.pp - http://pastebin.com/wxJMw5UJ mail.pp - http://pastebin.com/DnLJsjXr

когда запускаю паппет на Mail-new опять же получаю сообщения типа:

notice: /Stage[files]/Db::Files-mysql-server/File[/etc/my.cnf]: Dependency Mount[/mnt/Storage] has failures: true

и никак не могу понять - какого он лезет в обсолютно чужую ноду

P.S.: А стейты мне и нужны, что бы определять порядок применения классов при первоначальном развертывании. Типа: Пакеты -> Юзеры -> Файлы -> Сервайсы

Ну так так и определяй через зависимости. Я при работе с паппетом сделал для себя два вывода:
1) Не использовать import, т.к. он влечет за собой труднодиагностируемые ошибки и требует перезапуска puppetmaster при изменениях в импортируемых файлах.
2) Стараюсь не исполльзовать стейджи, т.к. я в них так толком не разобрался. Вместо них я использую зависимости, так получается намного наглядней и проще.
Например:

Package['ntp']->File['/etc/ntp.conf']~>Service['ntp']

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

node 'fileservk16.blabla' {
  include common
  include ntp

  class {'smart':}
  class {'zabbix::client':
    hostname        => 'fileservk16',
    user_parameters => ['softraid.status,egrep \"\\[.*_.*\\]\" /proc/mdstat|wc -l',
                        'disk.temp[*],sudo hddtemp -n $1',]
    }
  class { 'sudo': }
  sudo::conf { 'zabbix':
    priority => 10,
    content  => "zabbix   ALL=NOPASSWD:  /usr/sbin/hddtemp\n",
    }
  service {'apt-cacher-ng':
    ensure     => running,
    enable     => true,
    hasrestart => true,
    hasstatus  => false,
    }
  }

Хотя без импорта со временем начнутся проблемы с раздутым site.pp, частично наверное придется выносить описания нод во внешние файлы.

P.S.: А стейты мне и нужны, что бы определять порядок применения классов при первоначальном развертывании. Типа: Пакеты -> Юзеры -> Файлы -> Сервайсы

А то без них пуппет срёт в консоль сообщениями типа - не могу применить правила на файлы. т.к. ещё нет юзера/не установлен пакет. И приходится горогить require'ы =)

Это все от непонимания того, как работает puppet. Порядок применения как раз и определяется «горожением» require. Если хочется простого последовательного выполнения «сверху вниз», то выбран не тот инструмент.

Спасибо =) Попробую переписать без стейджев =)

Я правильно понял синтаксис? типа:

class 'MyNginx' {
  package { 'nginx' : ensure => installed, }
  file '{ '/etc/nginx': .... } '
  service { 'nginx' : enable => true, ensure => running, }
  Package['nginx']->File['/etc/nginx']~>Service['nginx']
}

И ламерский вопрос, не понял из мана, чем отличаются конструкции "->" и «~>» ?

До стейджев кстати, мой огород с импортами и зависимостями («inherits») работал правильно. Кстати, в Fedora 17 puppet не требует перезапуска puppetmaster при изменении в импортируемых файлах, всё применяется отлично.

А пихать всё в site.pp не хочу, на данный момент вижу архитектуру как: 1 надо - 1 файл, плюс общие для всех части вынесены отдельно.

Ни к чему не призываю, просто для меня это удобно.

http://docs.puppetlabs.com/guides/language_guide.html#chaining-resources

-> = Require
~> = Notice

Ты проверял коректность твоих конфигов?

Можешь скинуть вывод с Mail-new

service puppet restart; tail -f /var/log/messages | grep -i puppet

т.е. лог перезапуска клиента puppet и применения своего конфига.

Если клиент puppet не может получить новый манифест ( или в новом содержатся ошибки ), он применяет старый, который предусмотрительно хранит :)

1) Не использовать import, т.к. он влечет за собой труднодиагностируемые ошибки и требует перезапуска puppetmaster при изменениях в импортируемых файлах.

У меня с import проблем не было, но я никогда не пытался делать import внутри node. В корне site.pp импорт, в нодах - только include. И ни разу не возникала необходимость перезапуска процессов master'а при добавлении модуля или class/*.pp. Работает на debian squeeze и wheezy и rhel ( и его клонах ) 5.x, 6.x

мой site.pp:

# включаем все из /etc/puppet/manifest/classes/*.pp
import "classes/*"

# подключаем модули из /etc/puppet/modules/<имя модуля>/
import "mail"
import "secure"
import "monitoring"
import "ntp"
import "repository"

# подключаем конфиг с нодами. Да, он у меня отдельный, для наглядности.
import "nodes.pp"

Извини, уже всё переписал без стейджев. Разрулив порядок реквайрами - сейчас всё работает.

Большое спасибо за подсказки и советы!

У меня с import проблем не было, но я никогда не пытался делать import внутри node. В корне site.pp импорт, в нодах - только include. И ни разу не возникала необходимость перезапуска процессов master'а при добавлении модуля или class/*.pp.

Я конкретно вот про это говорил: http://docs.puppetlabs.com/puppet/3/reference/lang_import.html#inability-to-r... Сам не пробовал, но на этапе чтения документации для себя отметил, что импортируемые манифесты не всосутся после редактирования, если не отредактировать site.pp или не рестартануть master. С модулями-то нет никаких проблем.

У меня редактирование nodes.pp или class/*.pp не требует ни рестарта мастера, ни изменнения даты редактирования site.pp

Кстати, рекомендую начать использовать модули. И делить на модули максимально мелко, впоследствии это будет очень полезно.

Ну значит документация врет. А я в нее верил. :(

Плюсую этого господина. При грамотной организации ввод новой ноды будет сводиться к подключению к ней определенных модулей, фактически без делания чего-либо руками.

Уже примерно так делаю, вынося общее для всех нод в отдельные классы. Типа

class fedora::nfs-Storage ($res) {
        file { '/mnt/Storage' : 
                ensure => directory, 
                force => true, }
        mount { '/mnt/Storage' :
                require => [File['/mnt/Storage'], Package['nfs-utils']],
                remounts => false,
                atboot => true,
                ensure => mounted,
                device => "srv:/data/sec/Storage/$res",
                fstype => "nfs4",
                options => "rw,soft,nolock,bg,intr,tcp,auto", }
}

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

Начни переделывать в модули прямо сейчас! Это проще, чем может казаться.