Fabric: v2-совместимые "роли" или аналогичные

Синопсис

На момент написания в ветке v2 есть класс Group который должен быть способен служить в качестве единиц, ранее известных как «роли», иначе говоря, «группа хостов, с помощью которых и с / на которых можно что-то делать».

Однако пока не существует определенного способа организации или маркировки объектов Group ; этого достаточно для случая использования чистого API продвинутыми пользователями, которые хотят использовать свой собственный способ их создания, но не хватает чего-либо для пользователей, ориентированных на CLI, или промежуточных людей, которые хотят построить что-то каркасное.

Другими словами, если вы не работаете исключительно с API, наличие объектов Group, лежащих где-то поблизости, бесполезно, если CLI или биты вызова задач не имеют возможности их найти!

Фон

В v1 роли фактически представляли собой единое плоское пространство имен, сопоставляющее простые строковые метки с тем, что было бы группами в v2, и они могли быть выбраны в CLI во время выполнения ( fab --roles=web,db ) и / или зарегистрированы как цели по умолчанию для задач ( @task('db') \n def migrate(): ), как и хосты.

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

Конкретные варианты использования / потребности / дополнительные функции

• Базовое, наивное сопоставление для использования / ссылки в любом другом месте системы: введите имя, верните несколько итераций из Group s и / или Connection s.
  
  
  
  • Часто псевдонимы хотят присоединиться к этому, поэтому, например, Lexicon вместо dict .
  
  
  • Даже более глубокие конструкции, такие как «связывание», например, у вас есть прямые сопоставления с именами db , web , lb , но затем имя второго уровня называется prod который всегда является объединением трех других. Я забыл, добавил ли я это в Lexicon . Возможно, есть другие подклассы карт, которые уже делают это.
  
  
  • Вдобавок / альтернативно, такие вещи, как подстановка символов или другие строковые синтаксисы, хотя я лично предпочел бы использовать тот факт, что Python не "строго типизирован" ...
  
  
• Полезное «обратное сопоставление», позволяющее определить, к каким группам принадлежит данное соединение.
  
  
  
  • Проблема: поскольку в настоящее время нет глобального общего состояния, наивный ответ на этот вопрос - использование идентификатора - падает, потому что вы можете технически создать несколько идентичных объектов Connection.
  
  
  • Тем более, что Group может создавать их неявно от вашего имени, если вы просто дадите ему сокращенные строки хоста, хотя это только вариант для удобства.
  
  
  • Однако, учитывая это ограничение отсутствия глобального состояния, я не вижу очевидных проблем с использованием вместо этого тестирования равенства, поэтому это должно быть выполнимо, например, if cxn in group будет работать, даже если cxn - отдельный объект от равного члена внутри group .
  
  
  • Единственное, что приходит на ум, - это наличие сильных, отслеживающих состояние ссылок от Соединения к Группе (должны быть группы, во множественном числе), которые удерживают его, а не наоборот, но я не вижу веских причин для этого навскидку.
  
  
• Сильно связано с предыдущим: способность проверять / отображать, что такое «текущая роль» (что-то, чего люди давно хотели в v1, что было нетривиальным из-за его дизайна)
  
  
  
  • Основная проблема заключается в том, что на самом деле это два полуразличных вопроса: «какая роль (роли) является текущей частью хоста, вообще говоря» (в основном, предыдущий вариант использования обратного поиска), но также «какая роль (роли) была машина исполнения специально просила противостоять ".
  
  
  • Другими словами, данный хост 'foo', принадлежащий ролям A, B и C: в рамках данной задачи, контекст которой равен 'foo', но которая была запущена из-за запроса на выполнение роли A, является пользователем, ищущим ответ «A, B и C» (в целом роли «foo») или просто «A» (текущая исполняющая роль)?
  
  
  • Это действительно похоже на два разных вызова API, хотя запросы функций, которые я помню, объединяют их.
  
  
• Выбор цели в интерфейсе командной строки, глобально и / или для каждой задачи
  
  
  
  • Расширение системы CLI Invoke для учета «флагов, которые все задачи получают поверх того, что они определяют», может быть полезным или необходимым для этого. Фактически, это точно относится к территории pyinvoke / invoke # 205, так что это только что получило более высокий приоритет, чем был (который был довольно высоким).
  
  
• То же самое по умолчанию на уровне задачи
  
  
  
  • Хотя целевые значения по умолчанию на уровне задачи действительно хотят быть одним из следующих: соединение, соединения, групповые объекты, групповые объекты или имя, оценивающее _to_ групповые объекты (возможно, это единственное, что имеет непосредственное отношение к этому билету)
  
  
• То же самое по умолчанию на уровне коллекции (НОВИНКА в версии 2!)
  
  
  
  • Т.е. "все задачи в подмодуле $ по умолчанию выполняются с ролью db "
  
  
  • То же, что и в предыдущем пункте - это значение по умолчанию позволяет разрешить несколько различных значений, а не только строковый ключ.
  
  
• Есть ли что-нибудь еще новое и захватывающее, связанное с объектно-ориентированным подходом, которое действительно хочет пойти вместе с этим? Помните, что упор следует делать на строительных блоках и предоставлении возможностей для продвинутых пользователей, а не на, например, полностью изобретать системы, такие как Chef или Ansible.

Идеи / проблемы по реализации

• Если мы использовали конфигурационную систему в качестве основного вектора хранилища, значения «хотят» быть примитивами, чтобы их можно было хранить в yaml, json и т. Д., Но это баня червей, заканчивающаяся на «хранить все группы / подключения kwarg в большом ol» list-o-dicts "и др.
• Если мы ожидаем, что определения будут в основном на Python, мы можем просто сказать «создать экземпляры групповых объектов», а затем у нас есть возможность объединить эти данные в систему конфигурации или как-то оставить ее автономной.
  
  
  
  • Я думаю, что предпочитаю последнее, потому что вложение буквально всего во вложенные конфигурационные файлы кажется, что это приведет к плохим новостям.
  
  
• Более глубокие конструкции, такие как псевдоним и объединение, добавляют сложности и проблемы с упорядочением (т.е. представьте себе тривиальную настройку псевдонима, где значение key1 является группой, а значение key2 - key1; теперь вам нужно дважды сканировать структуру, чтобы разрешить или проверить key2)
  
  
  
  • хотя, если мы пойдем в основном на подход «сделай это в питоне», он станет во многом похожим на API системы конфигурации, где вы можете начать с декларативной структуры, но после этой начальной настройки вызовами методов разрешается что-то еще. Не думаю, что это ужасно? РЕДАКТИРОВАТЬ: и я думаю, что именно так работает Lexicon.
  
  
• Независимо от формата, мы должны выяснить, как опытные пользователи захотят генерировать его «на лету» из внешних источников или аналогичных; это плюс проблемы с псевдонимом и тому подобное, подразумевает, что мы, возможно, не хотим, чтобы это было в наивной структуре, «хранящейся» где-то, а как API для некоторого объекта или объектов, который вызывается для его генерации.
  
  
  
  • Я подозреваю, что мы можем захотеть работать «вниз» от выбора ролей / групп, придя к тому, что API самого высокого уровня предназначено для «превращения того, что пользователь предоставил, в действенную единицу целей», потому что наиболее продвинутые пользователи обязательно захотят иметь полный контроль над реализацией этого вызова API. Тогда мы, как всегда, можем предложить то, что кажется полезным общим случаем, но которое четко обозначено как «только один способ сделать это».
  
  
  • У @RedKrieg есть отличная идея в этих строках, где у нас есть @group например @task , а функции не являются исполняемыми единицами работы, а вместо этого выдают объекты Group.
  
  
  • Этот подход изначально повторно использует иерархию задач (Коллекция), что практично (зачем изобретать колесо) и элегантно (потому что в реальных случаях определения ролей / групп часто очень точно соответствуют задачам, использующим их!)
    
    
    
    
    
    • Это также хорошо работает, даже если ваши группы НЕ сопоставляются с вашими задачами, потому что вы можете просто написать определения на уровне своей корневой коллекции. Очень просто.
    
    
    
  
  
  • Мне неясно, лучше ли это возвращать одну группу из каждой функции, или нам нужна возможность создавать несколько групп (или соединений), или лучше всего делать это вообще не как декорированные функции, а просто как вызовы API. Коллекция (например, как хранятся конфигурации уровня коллекции).
  
  
  • Например, вариант использования, когда данные группы / роли являются динамическими и находятся вне Fabric, все еще требует решения (вот почему ранее я отмечал, что мы сначала должны идентифицировать API самого высокого уровня для этого пространства; затем нам нужно увидеть, как это связано с этой идеей среднего уровня.)