Um beispielsweise einer besonderen Storagekonfiguration gerecht zu werden, dass man eben zwei Storages betreibt, die nicht miteinander interagieren bzw. nicht jeweils aus dem anderen DC erreicht werden können, werden zwei getrennte Cinder Nodes notwendig.

Ab OpenStack 10 können neben den etablierten 5 Rollen weitere Rollen definiert werden.

Quellen:

https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/paged/advanced-overcloud-customization/chapter-6-composable-services-and-custom-roles Ab Kapitel 6.5

http://tripleo-docs.readthedocs.io/en/latest/tht_walkthrough/tht_walkthrough.html

http://hardysteven.blogspot.de/2016/10/tripleo-composablecustom-roles.html

Laut RedHat Support findet ein Matching über Namen der jeweiligen Komponenten statt.


Bitte nicht durch die vordefinierten Namen verwirren lassen. Hier ist es scheinbar in irgendeiner Form hardcoded wie der Zusammenhang zwischen dem Flavor und dem Rollennamen stattfindet bzw. der Befehl

openstack overcloud deploy --block-storage-flavor

setzt das entsprechende Flavor für diese mitgelieferte Rolle.

openstack overcloud deploy -h

liefert noch weitere Optionen dafür . Ganz klar ist dann aber auch vermerkt, dass diese Option DEPRECATED ist und man dafür ein Yaml als environment file angeben soll.

Dieses Environment File pro Rolle liegt vorbereitet unter

/usr/share/openstack-tripleo-heat-templates/puppet

Dort können dann entsprechende Flavors innerhalb des Templates angegeben werden.

Der Name in der roles_data.yml ist unterschiedlich zum Namen des Flavors bzw. dessen Tag. Von daher darf man sich dadurch nicht verwirren lassen !!

Neue Rollen matchen über den Namen aus der roles_data.yml.


Folgende Dateien bzw. Konfigurationen hängen miteinander zusammen:

  • Tagnamen definieren: Bsp.: wurst-cinder

Dieser Tag wird nun der Reihe nach den importierten Nodes, einem neu anzulegenden Flavor und in der roles_data.yml hinzugefügt.

  • Baremetal Node via Tag:

Man hat drei Möglichkeiten die Nodes zu taggen.

  1. Über die Defintion in der instackenv.json beim Import der Nodes.

Im entsprechenden Nodebereich das Tag setzen:

        {

            "mac":[

                "ff:ff:ff:a6:96:19"

            ],

            "disk":"100",

            "name":"kuerzel-rolle",

            "arch":"x86_64",

            "pm_type":<power management type,see documentation>,

            "capabilities":"profile:wurst-cinder,boot_option:local"

        }

  1. Über Policies

Dafür verweise ich hierauf, da ich es noch nicht gemacht habe. Ich finde die Werte nach denen man klassifizieren kann bisher auch nicht sehr aussagekräftig bzw. in Kombination eindeutig:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/9/html/director_installation_and_usage/appe-automatic_profile_tagging

  1. Manuell via Befehl

!!! Achtung: Vorher via openstack node show <UUID> die werte für die "property" "capabilities" anzeigen lassen. Diese Eigenschaft enthält nämlich widerum ebenfalls eine Liste mit Eigenschaften, die aber nicht einzeln aktualisiert oder ergänzt werden können, sondern werden alle als ein Wert der Eigenschaft "capabilities" gesehen.

openstack baremetal node set --property capabilities='profile:wurst-cinder,boot_option:local' <UUID>

  • Flavor via Tag -> Baremetal Node Tag
    1. Flavor erstellen am Beispiel "wurst-cinder"

openstack flavor create --ram 4096 --disk 40 --vcpus 1 wurst-cinder

  1. Flavor taggen:

openstack flavor set --property "capabilities:boot_option"="local" --property "capabilities:profile"="wurst-cinder" wurst-cinder

  • Roles_data.yml Rollenname -> Flavor Tag

Jetzt die Datei editieren und eine entsprechende Rolle mit den Diensten erstellen

- name: wurst-cinder

  CountDefault: 2

  ServicesDefault:

    - OS::TripleO::Services::CACerts

    - OS::TripleO::Services::Kernel

    - OS::TripleO::Services::Ntp

    - OS::TripleO::Services::Timezone

    - OS::TripleO::Services::Snmp

    - OS::TripleO::Services::TripleoPackages

    - OS::TripleO::Services::TripleoFirewall

    - OS::TripleO::Services::SensuClient

    - OS::TripleO::Services::FluentdClient

    - OS::TripleO::Services::VipHosts

    - OS::TripleO::Services::CinderApi

    - OS::TripleO::Services::CinderBackup

    - OS::TripleO::Services::CinderScheduler

    - OS::TripleO::Services::CinderVolume