Sorry folks, I didn't put the proper image url. Here it is:
https://creately.com/diagram/hrxk86gv2/kvbckU5hne8C0r0sofJDdtYgxc%3D -- Regards, Alexander Tivelkov On Mon, Feb 24, 2014 at 7:39 PM, Alexander Tivelkov <ativel...@mirantis.com>wrote: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
