From dc3099c2af51d470e182fe9804f48835997b2921 Mon Sep 17 00:00:00 2001 From: Dmitry Shulyak Date: Sat, 28 Mar 2015 14:55:01 -0700 Subject: [PATCH] Building block of the deployment Defined profiles/roles/resources entities, and outlined the way they should work. --- schema/services/mariadb.yml | 21 --------- spec/base.spec | 86 ------------------------------------- spec/core_api.spec | 6 --- spec/deployment_blocks.spec | 60 ++++++++++++++++++++++++++ spec/extensions.spec | 6 --- 5 files changed, 60 insertions(+), 119 deletions(-) delete mode 100644 schema/services/mariadb.yml delete mode 100644 spec/base.spec delete mode 100644 spec/core_api.spec create mode 100644 spec/deployment_blocks.spec delete mode 100644 spec/extensions.spec diff --git a/schema/services/mariadb.yml b/schema/services/mariadb.yml deleted file mode 100644 index 874fd9e1..00000000 --- a/schema/services/mariadb.yml +++ /dev/null @@ -1,21 +0,0 @@ ---- - -id: mariadb -type: service -version: v1 -handler: ansible -resources: - - id: mariadb_settings - type: service - handler: ansible - run: - - template: src=mariadb dest=mariadb.conf - parameters: - port: 8000 - host: localhost - password: admin - user: admin - - ref: compose - overwrite: - item: maridb.yml -endpoint: {{node.management.ip}}:4324 diff --git a/spec/base.spec b/spec/base.spec deleted file mode 100644 index 8b99c409..00000000 --- a/spec/base.spec +++ /dev/null @@ -1,86 +0,0 @@ - -First draft of fully functional specification for new deployment tool. -By this specification it is proposed that new solution should be fully -plugable right from the start. - -Fuel should be splitted at least in several repositories. -First one would fuel-api and will store only core api functionality -of the new tool. - -Second one should be named something like fuel-core -(similarly to ansible-core-modules). This is what will be our verified -tools to deploy openstack in a way we want to deploy it. - -Inventory api -============== - -Do we want to reuse existing entities but in a new way? Or we need to -reconsider them? I am sure that we can do better with networking, -current solution just masks bad decisions that was done in past. - -Orchestration api -==================== - -Resources ---------- -Each resource should define deployment logic in a known (to fuel) tool, -and parameters that can be modified by user or another layer of inventory. - -Services --------- -Single or several resources wrapped by additional data structure. -The primary purpose of service is to provide loose coupling between -roles and resources. And that can be achieved by using additional -parameters like endpoints. - -:: - endpoints: {{node.management.ip}}:5000 - -Installing fully functional service is not only a matter of running -docker-compose, but as well we need to execute some additional -tasks on the host system. - -One more challenge - verify that service started to work -(how and when it should be performed?) - -Role ------ -Combination of services and resources. -The main reason to introduce one - is to allow user an easy way -to map nodes in the cluster to the functionality that is desired. - -How to handle primary-{{role}} and {{role}} difference? - -Profiles --------- - -Profile is the main entity that user will work with. - -Several opinionated profile will be provided by us, and they should -be valuable mainly because of our expertise in deploying openstack. - -Each of this entity will have parameter that process provided data -with plugable pythonic architecture - -:: - # profile handler - handler: ansible - -:: - # network_schema will require some amount of modifications and transformations, that is easier to accomplish within python code - handler: network_schema - - -Modular architecture -==================== - -Every piece in fuel-core will be developed in a modular style, -and within that module - developer should be able to add/change -entities like: - - deployment logic (ansible or other deployment code) - - fuel pythonic handlers or other interfaces for pythonic plugins - - resources - - profiles - - services - - diff --git a/spec/core_api.spec b/spec/core_api.spec deleted file mode 100644 index 3fead1e9..00000000 --- a/spec/core_api.spec +++ /dev/null @@ -1,6 +0,0 @@ - -Core API -========== - -1. Register extensions - diff --git a/spec/deployment_blocks.spec b/spec/deployment_blocks.spec new file mode 100644 index 00000000..03a01ca5 --- /dev/null +++ b/spec/deployment_blocks.spec @@ -0,0 +1,60 @@ + + +Profile is a global wrapper for all resources in environment. +Profile is versioned and executed by particular driver. +Profile is a container for resources. +Resources can be grouped by roles entities. + +:: + + id: HA + type: profile + version: 0.1 + # adapter for any application that satisfies our requirements + driver: ansible + + +Role is a logical wrapper of resources. +We will provide "opinionated" wrappers, but user should +be able to compose resource in any way. + +:: + + roles: + - id: controller + type: role + resources: [] + + +Resource should have deployment logic for several events: +main deployment, removal of resource, scale up of resource ? +Resource should have list of input parameters that resource provides. +Resources are isolated, and should be executable as long as +required data provided. + +:: + id: rabbitmq + type: resource + driver: ansible_playbook + actions: + run: $install_rabbitmq_playbook + input: + image: fuel/rabbitmq + port: 5572 + # we need to be able to select ip addresses + listen: [{{management.ip}}, {{public.ip}}] + + +:: + id: nova_compute + type: resource + driver: ansible_playbook + actions: + run: $link_to_ansible_playbook + remove: $link_to_another_playbook_that_will_migrate_vms + maintenance: $link_to_playbook_that_will_put_into_maintenance + input: + image: fuel/compute + driver: kvm + rabbitmq_hosts: [] + diff --git a/spec/extensions.spec b/spec/extensions.spec deleted file mode 100644 index 2d8e75fd..00000000 --- a/spec/extensions.spec +++ /dev/null @@ -1,6 +0,0 @@ - - -Extensions -============ - -