Clouni substitution mapping proposal

Сейчас clouni работает так:

1. Получает на вход TOSCA-шаблон с абстрактной tosca.nodes.Compute нодой
2. Зная, какой провайдер нужен (например --provider openstack), транслирует шаблон в ненормативные типы
3. Пользуясь своей конфигурацией маппинга, переводит одни параметры шаблона в другие
4. Получает ненормативный шаблон, потому что внутри шаблона содержатся куски jinja вида:

tosca_server_example_security_group_rule:
  properties:
    direction: '{{ initiator[item | int] | default(omit) }}'
    port_range_max: '{{ port[item | int] | default(omit) }}'
    port_range_min: '{{ port[item | int] | default(omit) }}'
    protocol: '{{ protocol[item | int] | default(omit) }}'
    remote_ip_prefix: 0.0.0.0
  requirements:
  - security_group:
      node: tosca_server_example_security_group
  type: openstack.nodes.SecurityGroupRule

3. По полученному шаблону генерирует ansible скрипт, и запускает его

Как clouni может работать:

1. Получает на вход TOSCA-шаблон с абстрактной tosca.nodes.Compute нодой, которая помечена абстрактной с помощью directives: [ substitute ]
2. На основе тегов, выбранных пользователем (см. fake-orchestrator.py:9), в том числе провайдера, подбирает подходящие шаблоны из тех, которые он знает (папка templates)
   1. С помощью описанной в стандарте TOSCA схемы substitution mapping сопоставляет параметры
   2. Вообще не генерирует новый шаблон. Это вопрос дискуссионный, т.к. понятен запрос на вариативность конфигурации. Но вот несколько примеров:
      • Пользователь хочет создать инстанс в опенстеке без публичного IP: выбирает шаблон, где floating ip не присваивается
      • Пользователь хочет создать инстанс в опенстеке с публичным IP: точно так же выбирает шаблон, но уже другой, где есть floating ip
      • Пользователь хочет более глубокой конфигурации: он создает новый шаблон для substitution mapping, пользуясь типами из профиля опенстека, а затем использует свой шаблон
3. Разворачивает через interfaces валидный TOSCA шаблон, который “был подставлен” на место абстрактного (на самом деле просто развёрнут как отдельный шаблон + оркестратор запомнил связь в instance model)

В чём clouni лучше:

• С точки зрения трансляции одних штук в другие clouni гораздо универсальнее, т.к. может, например, из одного property (например какой-нибудь сложный map) сделать 2 TOSCA-ноды (или N TOSCA-нод)
• генерирует ansible скрипты

В чём clouni уступает:

• полученные шаблоны в промежуточном представлении ненормативны и могут быть развёрнуты только с помощью clouni
• полученный ansible невозможно дебажить и анализировать, потому что он сгенерирован

Предложенный подход может быть не менее универсальным, чем текущий в clouni, потому что:

• базовые конфигурации удовлетворяются парой substitution-шаблонов
• более сложные конфигурации удовлетворяются абстрактными tosca.nodes.network.Port и tosca.nodes.network.Network, которые тоже можно перевести в ненормативные Openstack типы через substitution mapping (да, подстановок больше, но их можно решить через эффективный поиск подходящих шаблонов)
• в текущем описании нормативного типа tosca.nodes.Compute вообще нет properties. Можно только выставить параметры одного Endpoint’а, который семантически вынесен как единственная точка доступа для администратора. А attributes, по моему представлению (тут я могу ошибаться), лучше не выставлять руками: семантически они обозначают параметры, которые становятся известны в рантайме

3.6.10.1 Attribute and Property reflection

The actual state of the entity, at any point in its lifecycle once instantiated, is reflected by Attribute definitions.  TOSCA orchestrators automatically create an attribute for every declared property (with the same symbolic name) to allow introspection of both the desired state (property) and actual state (attribute).

3.6.12.4 Additional Requirements

Values for the default keyname MUST be derived or calculated from other attribute or operation output values (that reflect the actual state of the instance of the corresponding resource) and not hard-coded or derived from a property settings or inputs (i.e., desired state).