Марионеточный беспорядок наследования классов

Я установил STEP7 с инструкциями, описанными в этой статье: http://xuek.ru/eblog/2009/10/step7-at-win7/

Это работает не в виртуальной машине и окнах, совместимый режим не работает правильно. Необходимо отредактировать setup.msi файлы. Setup.ini, вероятно, не имеет значения.

6
задан 4 November 2010 в 00:15
2 ответа

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

  1. Класс может быть включен только однажды (последующий, включают - операторы ничего не сделают),
  2. Порядок выполнения строго не определяется и может даже быть случайным

er-dev и er-bce-dev оба включают класс er. Но класс не может быть включен два раза, таким образом, er класс выполняется только со значением по умолчанию $venvname = "er", или с переопределенным $venvname = "er-dev", но не оба.

Решение: Изменение er класс к определению (см. "Определения" из Марионеточного Учебного руководства по Языку (http://docs.puppetlabs.com/guides/language_tutorial.html)):

modules/django-env/manifests/er.pp

# Create new er resource definition
define django-env::er($vpath="/home/django/virtualenvs", $vname="er") {
    file { "$vpath/$vname" :
        ensure => directory
    }
    # etc ...
}

Нам не нужно $venvname и $venvpath переменные, они указаны как значения по умолчанию в определении. Имя django-env::er добавляет определение в django-env пространство имен и позволяет автоматический импорт (см. ниже).

Импортируйте и включайте

Разница между import и include statemens:

  • import работы с файлами, и не выполняют классы
  • include выполняет классы
  • файлы должны быть импортированы, прежде чем классы могут быть включены

Примечание: существует очень сильное исключение к последнему правилу: Марионеточный поиск модуля. include оператор делает автоматический импорт во многих ситуациях. Вот некоторые из них:

  • include foo попытки импортировать файл module_dir/foo/manifests/init.pp
  • include foo::bar импорт module_dir/foo/manifests/bar.pp

С этим автоматическим импортом и определением ресурса, можно определить несколько виртуальных сред очень легко. Изменение node 'centos-dev':

node 'centos-dev' imports default {
    include django-env
    # The er resource with default values:
    django-env::er { 'er-bce': }
    # Another er resource with different environment name:
    django-env::er { 'er-bce-dev': vname => 'bce-dev'}
}

И можно удалить в основном все import рассмотрение операторов django-env модуль.

Счастливый Puppeting!

11
ответ дан 3 December 2019 в 00:14

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

 /etc/puppet
   /manifests
      /nodes
      site.pp
   /modules
   puppet.conf

Вы должны использовать:

 /etc/puppet
   /environments
     /production
       /manifests
          01_base_node.pp
       /modules
       environment.conf
   puppet.conf

Вместо использования традиционной site.pp config:

import 'nodes/*.pp'

node default {
   classs{'ntp': }
}

вы должны использовать стандартный class (но вы не можете назвать его class default, так как это зарезервированное слово), файл manifets/01_common. pp:

class common {
  classs{'ntp': }
}

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

Затем вместо определения узла типа:

node /^web\d+/ inherits default {
}

используйте скорее (решает классическую проблему множественного наследования, так называемую алмазную проблему), например, определенную в манифестах/веб-пакетах

node /^web\d+/ {
  include common
  # include something_else   
}
0
ответ дан 3 December 2019 в 00:14

Теги

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