Merge pull request #2 from xarses/deployment

Building blocks of the deployment

schema/services/mariadb.yml

@@ -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

spec/base.spec

@@ -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
-
-

spec/core_api.spec

@@ -1,6 +0,0 @@
-
-Core API
-==========
-
-1. Register extensions
-

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: []
+

spec/extensions.spec

@@ -1,6 +0,0 @@
-
-
-Extensions
-============
-
-