Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
how these may be done by Heat, while Murano should > definitely support this scenarios. > > From: Alexander Tivelkov > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Monday, February 24, 2014 12:18 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Murano] Object-oriented approach for > defining Murano Applications > > Hi Stan, > > It is good that we are on a common ground here :) > > Of course this can be done by Heat. In fact - it will be, in the very > same manner as it always was, I am pretty sure we've discussed this many > times already. When Heat Software config is fully implemented, it will be > possible to use it instead of our Agent execution plans for software > configuration - it the very same manner as we use "regular" heat templates > for resource allocation. > > Heat does indeed support template composition - but we don't want our > end-users to do learn how to do that: we want them just to combine existing > application on higher-level. Murano will use the template composition under > the hood, but only in the way which is designed by application publisher. > If the publisher has decided to configure the software with using Heat > Software Config, then this option will be used. If some other (probably > some legacy ) way of doing this was preferred, Murano should be able to > support that and allow to create such workflows. > > Also, there may be workflow steps which are not covered by Heat by > design. For example, application publisher may include creating instance > snapshots, data migrations, backups etc into the deployment or maintenance > workflows. I don't see how these may be done by Heat, while Murano should > definitely support this scenarios. > > So, as a conclusion, Murano should not be though of as a Heat > alternative: it is a different tool located on the different layer of the > stack, aiming different user audience - and, the most important - using the > Heat underneath. > > > -- > Regards, > Alexander Tivelkov > > > On Mon, Feb 24, 2014 at 8:36 PM, Stan Lagun wrote: > >> Hi Alex, >> >> Personally I like the approach and how you explain it. I just would like >> to know your opinion on how this is better from someone write Heat template >> that creates Active Directory lets say with one primary and one secondary >> controller and then publish it somewhere. Since Heat do supports software >> configuration as of late and has concept of environments [1] that Steven >> Hardy generously pointed out in another mailing thread that can be used for >> composition as well it seems like everything you said can be done by Heat >> alone >> >> [1]: >> http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html >> >> >> On Mon, Feb 24, 2014 at 7:51 PM, Alexander Tivelkov < >> ativel...@mirantis.com> wrote: >> >>> 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 cla
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
Hi Keith, Thank you for bringing up this question. We think that it could be done inside Heat. This is a part of our future roadmap to bring more stuff to Heat and pass all actual work to the heat engine. However it will require a collaboration between Heat and Murano teams, so that is why we want to have incubated status, to start better integration with other projects being a part of OpenStack community. I will understand Heat team when they refuse to change Heat templates to satisfy the requirements of the project which does not officially belong to OpenStack. With incubation status it will be much easier. As for the actual work, backups and snapshots are processes. It will be hard to express them in a good way in current HOT template. We see that we will use Mistral resources defined in Heat which will trig the events for backup and backup workflow associated with the application can be defined outside of Heat. I don't think that Heat team will include workflow definitions as a part of template format, while they can allow us to use resources which reference such workflows stored in a catalog. It can be an extension for HOT Software config for example, but we need to validate this approach with the heat team. The idea of Heat template generation library\engine is exactly what we have implemented. Murano engine uses its own application definition to generate valid Heat templates from snippets. As there is no preliminary knowledge of actual snippet content, Murano package definition language allows application writer to specify application requirements, application constraints, data transformation rules and assertions to make a heat template generation process predictable and manageable. I think this is an essential part of Catalog as it tightly coupled with the way how applications and its resources are defined. Thanks Georgy On Mon, Feb 24, 2014 at 1:44 PM, Keith Bray wrote: > Have you considered writing Heat resource plug-ins that perform (or > configure within other services) instance snapshots, backups, or whatever > other maintenance workflow possibilities you want that don't exist? Then > these maintenance workflows you mention could be expressed in the Heat > template forming a single place for the application architecture > definition, including defining the configuration for services that need to > be application aware throughout the application's life . As you describe > things in Murano, I interpret that you are layering application > architecture specific information and workflows into a DSL in a layer above > Heat, which means information pertinent to the application as an ongoing > concern would be disjoint. Fragmenting the necessary information to wholly > define an infrastructure/application architecture could make it difficult > to share the application and modify the application stack. > > I would be interested in a library that allows for composing Heat > templates from "snippets" or "fragments" of pre-written Heat DSL... The > library's job could be to ensure that the snippets, when combined, create a > valid Heat template free from conflict amongst resources, parameters, and > outputs. The interaction with the library, I think, would belong in > Horizon, and the "Application Catalog" and/or "Snippets Catalog" could be > implemented within Glance. > > >>>Also, there may be workflow steps which are not covered by Heat by > design. For example, application publisher may include creating instance > snapshots, data migrations, backups etc into the deployment or maintenance > workflows. I don't see how these may be done by Heat, while Murano should > definitely support this scenarios. > > From: Alexander Tivelkov > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Monday, February 24, 2014 12:18 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Murano] Object-oriented approach for > defining Murano Applications > > Hi Stan, > > It is good that we are on a common ground here :) > > Of course this can be done by Heat. In fact - it will be, in the very > same manner as it always was, I am pretty sure we've discussed this many > times already. When Heat Software config is fully implemented, it will be > possible to use it instead of our Agent execution plans for software > configuration - it the very same manner as we use "regular" heat templates > for resource allocation. > > Heat does indeed support template composition - but we don't want our > end-users to do learn how to do that: we want them just to combine existing > applicati
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
On Mon, Feb 24, 2014 at 4:20 PM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Hi Keith, > > Thank you for bringing up this question. We think that it could be done > inside Heat. This is a part of our future roadmap to bring more stuff to > Heat and pass all actual work to the heat engine. However it will require a > collaboration between Heat and Murano teams, so that is why we want to have > incubated status, to start better integration with other projects being a > part of OpenStack community. I will understand Heat team when they refuse > to change Heat templates to satisfy the requirements of the project which > does not officially belong to OpenStack. With incubation status it will be > much easier. > As for the actual work, backups and snapshots are processes. It will be > hard to express them in a good way in current HOT template. We see that we > will use Mistral resources defined in Heat which will trig the events for > backup and backup workflow associated with the application can be defined > outside of Heat. I don't think that Heat team will include workflow > definitions as a part of template format, while they can allow us to use > resources which reference such workflows stored in a catalog. It can be an > extension for HOT Software config for example, but we need to validate this > approach with the heat team. > > For what it's worth, there's already precedent for including non-OpenStack resource plugins in Heat, in a "contrib" directory (which is still tested with the CI infrastructure). -- IRC: radix Christopher Armstrong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
Have you considered writing Heat resource plug-ins that perform (or configure within other services) instance snapshots, backups, or whatever other maintenance workflow possibilities you want that don't exist? Then these maintenance workflows you mention could be expressed in the Heat template forming a single place for the application architecture definition, including defining the configuration for services that need to be application aware throughout the application's life . As you describe things in Murano, I interpret that you are layering application architecture specific information and workflows into a DSL in a layer above Heat, which means information pertinent to the application as an ongoing concern would be disjoint. Fragmenting the necessary information to wholly define an infrastructure/application architecture could make it difficult to share the application and modify the application stack. I would be interested in a library that allows for composing Heat templates from "snippets" or "fragments" of pre-written Heat DSL... The library's job could be to ensure that the snippets, when combined, create a valid Heat template free from conflict amongst resources, parameters, and outputs. The interaction with the library, I think, would belong in Horizon, and the "Application Catalog" and/or "Snippets Catalog" could be implemented within Glance. >>>Also, there may be workflow steps which are not covered by Heat by design. >>>For example, application publisher may include creating instance snapshots, >>>data migrations, backups etc into the deployment or maintenance workflows. I >>>don't see how these may be done by Heat, while Murano should definitely >>>support this scenarios. From: Alexander Tivelkov mailto:ativel...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, February 24, 2014 12:18 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications Hi Stan, It is good that we are on a common ground here :) Of course this can be done by Heat. In fact - it will be, in the very same manner as it always was, I am pretty sure we've discussed this many times already. When Heat Software config is fully implemented, it will be possible to use it instead of our Agent execution plans for software configuration - it the very same manner as we use "regular" heat templates for resource allocation. Heat does indeed support template composition - but we don't want our end-users to do learn how to do that: we want them just to combine existing application on higher-level. Murano will use the template composition under the hood, but only in the way which is designed by application publisher. If the publisher has decided to configure the software with using Heat Software Config, then this option will be used. If some other (probably some legacy ) way of doing this was preferred, Murano should be able to support that and allow to create such workflows. Also, there may be workflow steps which are not covered by Heat by design. For example, application publisher may include creating instance snapshots, data migrations, backups etc into the deployment or maintenance workflows. I don't see how these may be done by Heat, while Murano should definitely support this scenarios. So, as a conclusion, Murano should not be though of as a Heat alternative: it is a different tool located on the different layer of the stack, aiming different user audience - and, the most important - using the Heat underneath. -- Regards, Alexander Tivelkov On Mon, Feb 24, 2014 at 8:36 PM, Stan Lagun mailto:sla...@mirantis.com>> wrote: Hi Alex, Personally I like the approach and how you explain it. I just would like to know your opinion on how this is better from someone write Heat template that creates Active Directory lets say with one primary and one secondary controller and then publish it somewhere. Since Heat do supports software configuration as of late and has concept of environments [1] that Steven Hardy generously pointed out in another mailing thread that can be used for composition as well it seems like everything you said can be done by Heat alone [1]: http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html On Mon, Feb 24, 2014 at 7:51 PM, Alexander Tivelkov mailto:ativel...@mirantis.com>> wrote: 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 mai
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
Hi Stan, It is good that we are on a common ground here :) Of course this can be done by Heat. In fact - it will be, in the very same manner as it always was, I am pretty sure we've discussed this many times already. When Heat Software config is fully implemented, it will be possible to use it instead of our Agent execution plans for software configuration - it the very same manner as we use "regular" heat templates for resource allocation. Heat does indeed support template composition - but we don't want our end-users to do learn how to do that: we want them just to combine existing application on higher-level. Murano will use the template composition under the hood, but only in the way which is designed by application publisher. If the publisher has decided to configure the software with using Heat Software Config, then this option will be used. If some other (probably some legacy ) way of doing this was preferred, Murano should be able to support that and allow to create such workflows. Also, there may be workflow steps which are not covered by Heat by design. For example, application publisher may include creating instance snapshots, data migrations, backups etc into the deployment or maintenance workflows. I don't see how these may be done by Heat, while Murano should definitely support this scenarios. So, as a conclusion, Murano should not be though of as a Heat alternative: it is a different tool located on the different layer of the stack, aiming different user audience - and, the most important - using the Heat underneath. -- Regards, Alexander Tivelkov On Mon, Feb 24, 2014 at 8:36 PM, Stan Lagun wrote: > Hi Alex, > > Personally I like the approach and how you explain it. I just would like > to know your opinion on how this is better from someone write Heat template > that creates Active Directory lets say with one primary and one secondary > controller and then publish it somewhere. Since Heat do supports software > configuration as of late and has concept of environments [1] that Steven > Hardy generously pointed out in another mailing thread that can be used for > composition as well it seems like everything you said can be done by Heat > alone > > [1]: > http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html > > > On Mon, Feb 24, 2014 at 7:51 PM, Alexander Tivelkov < > ativel...@mirantis.com> wrote: > >> 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. >>> >>> Window
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
Hi Alex, Personally I like the approach and how you explain it. I just would like to know your opinion on how this is better from someone write Heat template that creates Active Directory lets say with one primary and one secondary controller and then publish it somewhere. Since Heat do supports software configuration as of late and has concept of environments [1] that Steven Hardy generously pointed out in another mailing thread that can be used for composition as well it seems like everything you said can be done by Heat alone [1]: http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html On Mon, Feb 24, 2014 at 7:51 PM, Alexander Tivelkov wrote: > 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
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
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 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
[openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
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
