Open Stack

Hi,

I would like to initiate one more discussion about an approach we selected
to solve a particular problem in Murano.

The problem statement is the following: We have multiple entities like low
level resources and high level application definitions. Each entity does
some specific actions for example to create a VM or deploy application
configuration. We want each entity's workflow code reusable in order to
simplify development for a new application as the current approach with XML
based rules requires significant efforts.

After internal discussions inside Murano team we come up to the solution
which uses a well known programmatic concept - classes, their inheritance
and composition.

In this thread I would like to share our ideas and discuss the
implementation details.

We want to represent each and every entity being manipulated by Murano, as
an instance of some "class". These classes will define structure of the
entities and their behavior. Different entities may be combined together,
interacting with each other, forming a composite environment. The
inheritance may be used to extract common structure and functionality into
generic superclasses, while having their subclasses to define only their
specific attributes and actions.

This approach is better to explain on some example. Let's consider the
Active Directory windows service. This is one of the currently present
Murano Applications, and its structure and deployment workflow is pretty
complex. Let's see how it may be simplified by using the proposed
object-oriented approach.

First, let's just describe an Active Directory service in plain English.

Active Directory service consists of several Controllers: exactly one
Primary Domain Controller and, optionally, several Secondary Domain
Controllers. Controllers (both primary and Secondary) are special Windows
Instances, having an active directory server role activated. Their specific
difference is in the configuration scripts which are executed on them after
the roles are activated. Also, Secondary Domain Controllers have an ability
to join to a domain, while Primary Domain Controller cannot do it.

Windows Instances are regular machines having some limitations on the their
images (it should, obviously, be Windows image) and hardware flavor
(windows is usually demanding on resources). Also, windows machines may
have some specific operations, like configuring windows firewall rules or
defining local administrator password.

And the machines in general (both Windows and any others) are simple
entities which know how to create virtual machines in OpenStack clouds.

Now, let's map this model to object-oriented concept. We get the following
classes:


   1.

   Instance. Defines common properties of virtual machines (flavor, image,
   hostname) and deployment workflow which executes a HEAT template to create
   an instance in the cloud.
   2.

   WindowsInstance - inherits Instance. Defines local administrator account
   password and extends base deployment workflow to set this password and
   configure windows firewall - after the instance is deployed.
   3.

   DomainMember - inherits Windows instance, defines a machine which can
   join an Active Directory. Adds a "join domain" workflow step
   4.

   DomainController - inherits Windows instance, adds an "Install AD Role"
   workflow steps and extends the "Deploy" step to call it.
   5.

   PrimaryController - inherits DomainContoller, adds a "Configure as
   Primary DC" workflow step and extends "Deploy" step to call it. Also adds a
   domainIpAddress property which is set during the deployment.
   6.

   SecondaryController, inherits both DomainMember and DomainController.
   Adds a "Configure as Secondary DC" worflow step and extends Deploy() step
   to call it and the "join domain" step inherited from the "Domain Member"
   class.
   7.

   ActiveDirectory -  a primary class which defines an Active Directory
   application. Defines properties for PrimaryController and
   SecondaryControllers and a "Deploy" workflow which call appropriate
   workflows on the controllers.


The simplified class diagram may look like this:





So, this approach allows to decompose the AD deployment workflow into
simple isolated parts, explicitly manage the state and create reusable
entities (of course classes like Instance, WindowsInstance, DomainMember
may be used by other Murano Applications). For me this looks much, much
better than the current implicit state machine which we run based on XML
rules.

What do you think about this approach, folks? Do you think it will be
easily understood by application developers? Will it be easy to write
workflows this way? Do you see any drawbacks here?

Waiting for your feedback.


--
Regards,
Alexander Tivelkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/bebe3bd2/attachment.html>