search.json

{"entries":[{"title":"1.1.0 About","baseurl":"","url":"/documentation/1.1.0/about.html","date":null,"categories":[],"body":"Alien4Cloud means Application LIfecycle ENablement for Cloud. It is a project started by FastConnect in order to help enterprises adopting the cloud for their new or even existing applications in an Open way meaning with Open-Source model and standardization support in mind. Why Cloud Computing is becoming prime development and deployment model for a number of applications. New applications being developed want to benefit from the agility and sometimes cost reduction implied by usage of Cloud technologies. Existing applications want to benefit as well from this model to be able to allow development and operations teams, managing the applications, to accelerate new features or maintenance pace. This requires to implement agility principles and leverage proper tools, not only in development, but as well on the deployment phase along all the application lifecycle. As well agility is reached when proper collaboration between Dev and Ops teams, and their business sponsor, is achieved. Even if a large number of solutions exist in the Cloud ecosystem, the ecosystem is not consolidated. Architectures, APIs, technologies and infrastructures are still evolving a lot. It leaves a lot of choice to the one willing to develop and deploy applications in the Cloud, but very often, the will to reach agility creates a lock-in to the choosen provider at some level : SaaS, PaaS or IaaS. Knowing the investment term in the Applications from development to deployment (usually several years), and the legacy, it is important to protect the investment in the Application lifecycle, from moving parts, at any level possible. What Alien4Cloud aims at addressing some of these problems by providing the following capabilities : Ease the design and portability of Applications by leveraging TOSCA (an emerging standard driven by OASIS foundation) Isolate the application evolution from deployment technologies and infrastructures, allowing to integrate with any deployment layer and infrastructure Accelerate Application Infrastructure Design and improve reusability by providing a Components and Blueprints catalog Ease collaboration between Development and Deployment teams across the Application lifecycle in creating the Components and Blueprints to fill the catalog Integrate with existing Enterprise systems (Dev and Ops) through REST API and pluggable strategies Check current roadmap for details on where we are and where we go. Standard support Alien4Cloud supports OASIS TOSCA an emerging standard addressing applications portability in the cloud. We believe that applications cloud enablement should be done in an open way, free of any lock-in. No lock-in meaning that the application should freely move from one environment to the other with smallest effort possible. Therefore, it needs to abstract itself from the underlying infrastructure technical adherence, and define its infrastructure requirements and architecture, independently from each Cloud Provider’s Infrastructure Catalog. If not done, even if, technical compability between vendors could exist in theory (yet to be confirmed by reality), Infrastructure Catalog alignment between providers is very unlikely to happen as each provider is focusing in delivering best value to its customers and does not spend time aligning with others, especially when they may be competitors. As an analogy, can you easily compare your Telecom providers offerings ? We bet that the same will happen with Cloud providers, and it has already started. TOSCA enables the expression of Application Requirements on the Infrastructure and its QOS/SLA, in an open way, opening the door to optimized placement of Applications in the Cloud Infrastructures based on customer choice at its heart. We know about Infrastructure As Code, with TOSCA, we enter in to the era of “Application Requirements as Code” easing Application lifecycle management across several Cloud infrastructures. By increasing service and application portability in a vendor-neutral ecosystem, TOSCA will enable : Portable deployment to any compliant cloud Smoother migration of existing applications to the cloud Flexible bursting (consumer choice) Dynamic, multi-cloud provider applications Note: TOSCA Simple profile is a working draft and is not released yet to public. Current Alien 4 Cloud version is using a Alien 4 Cloud’s specific DSL that is really close to the latest TOSCA Simple Profile in YAML TC work. Open-Source We decided to build Alien4Cloud and give it to the community in order to allow Application Requirements modelling in a TOSCA format, in a collaborative way, between all participants involved in Application Infrastructure Requirements definition. It is provided with an Apache 2 license in order to favour contributions from external teams or individuals. Please check our Contribute page to see how you can help. What it is not Alien4Cloud focuses on Design, Collaboration, Application Lifecycle Management and later Governance, but leverages other existing open source projects that help orchestrating cloud applications and which focus on runtime aspects such as Cloudify . Alien4Cloud does not aim to provide applications deployment runtime. We believe that there are already a number of viable options there (some of them not being TOSCA compliant, btw) and we want to integrate more than replace. We do it in an open way through plug-in approach to allow you to leverage your best tools or skills. Status 1.1.0 version is being developped but still can be used for all new projects and POCs. Which version to choose ? Basically the question depends on your timeframe, on the features you are looking from and on the support level you need. * 1.0.0 is our most stable version and is the latest version that we support. * 1.1.0 is still in development and things can change if you start using it. On the other hand all new features are developed in 1.1.0 so you may get more by choosing to start working with this version. We especially recommend that new POCs or project that will really start after we released the 1.1.0 (check our roadmap . Supported platforms To get more informations about the supported platforms, please refer to this section . "},{"title":"1.0.0 About","baseurl":"","url":"/documentation/1.0.0/about.html","date":null,"categories":[],"body":" Alien4Cloud means Application LIfecycle ENablement for Cloud. It is a project started by FastConnect in order to help enterprises adopting the cloud for their new or even existing applications in an Open way meaning with Open-Source model and standardization support in mind. Why Cloud Computing is becoming prime development and deployment model for a number of applications. New applications being developed want to benefit from the agility and sometimes cost reduction implied by usage of Cloud technologies. Existing applications want to benefit as well from this model to be able to allow development and operations teams, managing the applications, to accelerate new features or maintenance pace. This requires to implement agility principles and leverage proper tools, not only in development, but as well on the deployment phase along all the application lifecycle. As well agility is reached when proper collaboration between Dev and Ops teams, and their business sponsor, is achieved. Even if a large number of solutions exist in the Cloud ecosystem, the ecosystem is not consolidated. Architectures, APIs, technologies and infrastructures are still evolving a lot. It leaves a lot of choice to the one willing to develop and deploy applications in the Cloud, but very often, the will to reach agility creates a lock-in to the choosen provider at some level : SaaS, PaaS or IaaS. Knowing the investment term in the Applications from development to deployment (usually several years), and the legacy, it is important to protect the investment in the Application lifecycle, from moving parts, at any level possible. What Alien4Cloud aims at addressing some of these problems by providing the following capabilities : Ease the design and portability of Applications by leveraging TOSCA (an emerging standard driven by OASIS foundation) Isolate the application evolution from deployment technologies and infrastructures, allowing to integrate with any deployment layer and infrastructure Accelerate Application Infrastructure Design and improve reusability by providing a Components and Blueprints catalog Ease collaboration between Development and Deployment teams across the Application lifecycle in creating the Components and Blueprints to fill the catalog Integrate with existing Enterprise systems (Dev and Ops) through REST API and pluggable strategies Check current roadmap for details on where we are and where we go. Standard support Alien4Cloud supports OASIS TOSCA an emerging standard addressing applications portability in the cloud. We believe that applications cloud enablement should be done in an open way, free of any lock-in. No lock-in meaning that the application should freely move from one environment to the other with smallest effort possible. Therefore, it needs to abstract itself from the underlying infrastructure technical adherence, and define its infrastructure requirements and architecture, independently from each Cloud Provider’s Infrastructure Catalog. If not done, even if, technical compability between vendors could exist in theory (yet to be confirmed by reality), Infrastructure Catalog alignment between providers is very unlikely to happen as each provider is focusing in delivering best value to its customers and does not spend time aligning with others, especially when they may be competitors. As an analogy, can you easily compare your Telecom providers offerings ? We bet that the same will happen with Cloud providers, and it has already started. TOSCA enables the expression of Application Requirements on the Infrastructure and its QOS/SLA, in an open way, opening the door to optimized placement of Applications in the Cloud Infrastructures based on customer choice at its heart. We know about Infrastructure As Code, with TOSCA, we enter in to the era of “Application Requirements as Code” easing Application lifecycle management across several Cloud infrastructures. By increasing service and application portability in a vendor-neutral ecosystem, TOSCA will enable : Portable deployment to any compliant cloud Smoother migration of existing applications to the cloud Flexible bursting (consumer choice) Dynamic, multi-cloud provider applications Note: TOSCA Simple profile is a working draft and is not released yet to public. Current Alien 4 Cloud version is using a Alien 4 Cloud’s specific DSL that is really close to the latest TOSCA Simple Profile in YAML TC work. Open-Source We decided to build Alien4Cloud and give it to the community in order to allow Application Requirements modelling in a TOSCA format, in a collaborative way, between all participants involved in Application Infrastructure Requirements definition. It is provided with an Apache 2 license in order to favour contributions from external teams or individuals. Please check our Contribute page to see how you can help. What it is not Alien4Cloud focuses on Design, Collaboration, Application Lifecycle Management and later Governance, but leverages other existing open source projects that help orchestrating cloud applications and which focus on runtime aspects such as Cloudify . Alien4Cloud does not aim to provide applications deployment runtime. We believe that there are already a number of viable options there (some of them not being TOSCA compliant, btw) and we want to integrate more than replace. We do it in an open way through plug-in approach to allow you to leverage your best tools or skills. Status Alien 4 Cloud is now released in 1.0.0 version. This version is used in real-life projets inside FastConnect in order to provide self-service, industrialisation and collaboration in the design and management of applications blueprints. We especially use version 1.0.0 to deploy hadoop cluster (see Hadoop Self Service project page ) Which version to choose ? Basically the question depends on your timeframe, on the features you are looking from and on the support level you need. * 1.0.0 is our most stable version and is the latest version that we support. * 1.1.0 is still in development and things can change if you start using it. On the other hand all new features are developed in 1.1.0 so you may get more by choosing to start working with this version. We especially recommend that new POCs or project that will really start after we released the 1.1.0 (check our roadmap . Supported platforms To get more informations about the supported platforms, please refer to this section . "},{"title":"Advanced configuration","baseurl":"","url":"/documentation/1.1.0/admin/advanced_configuration.html","date":null,"categories":[],"body":" Using SSL By default Alien 4 Cloud starts using http rather than https enabling SSL is however really simple. Just edit the alien4cloud-config.yml and replace: server : port : 8080 by server : port : 8443 ssl : key-store : keystore.jks key-store-password : ****** key-password : ****** Make sure that you have your key store placed along-side the alien4cloud war file: ├── start.sh ├── alien4cloud-ui- { version } -standalone.war ├── keystore.jks ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml Elastic Search configuration ALIEN 4 Cloud uses ElasticSearch as it’s data store and indexing service. By default ALIEN 4 Cloud starts up an embedded ElasticSearch node. Of course when running in production it is recommended to use a remote cluster (ideally with high availability configured). Common configuration Common configuration allows you to configure the name of the elasticsearch cluster ( clusterName ), as well as the prefix_max_expansions (performance setting used for prefix queries). We recommend that you don’t change the default prefix_max_expansions value. If you wish to change one of the parameters, you should open the alien4cloud-config.yml file and go to the elasticSearch configuration section. elasticSearch : clusterName : escluster local : false client : false resetData : false prefix_max_expansions : 10 local and resetData should be left to false. Configure the embedded Elastic Search The embedded Elastic Search configuration elasticsearch.yml is a native elastic search configuration and you can find plenty of information on elastic search website on how you can configure it. However the main element you may wish to configure is elastic search storage directories: path : data : ${user.home}/.alien/elasticsearch/data work : ${user.home}/.alien/elasticsearch/work logs : ${user.home}/.alien/elasticsearch/logs Configure a remote Elastic Search (throw a no data node) In order to configure a remote Elastic Search, you should edit the following: In alien4cloud-config.yml file, edit the elasticSearch section and change client from false to true: elasticSearch : clusterName : escluster local : false client : true resetData : false prefix_max_expansions : 10 In the elasticsearch.yml make sure that the connection parameters matches the ones of your elasticsearch cluster. Example: discovery.zen.ping.multicast.enabled : false discovery.zen.ping.unicast.enabled : true discovery.zen.ping.unicast.hosts : 129.185.67.112 In this mode, a ‘client’ node is initialized and joins the cluster. It doesn’t store any data and act as a proxy. The machines must be visible for each other (in other words, they should be into the same network). Configure a remote Elastic Search (using a standalone transport client) In this mode, we use a simple standalone client that can be in another network as long as the cluster can be reachable. In alien4cloud-config.yml file, edit the elasticSearch section and set ‘client’ and ‘transportClient’ to true, and indicate the cluster host and port: elasticSearch : clusterName : escluster local : false client : true transportClient : true # a comma separated list of host:port couples hosts : 129.185.67.112:9300 resetData : false prefix_max_expansions : 10 In the elasticsearch.yml make sure that the cluster name is well defined (should be the same than the cluster). cluster.name : escluster Directories configuration ALIEN 4 Cloud store various files on the hard drive. Cloud Service archives, Artifacts overriden in the topologies, plugins archives etc. Directories can be configured in the alien4cloud-config.yml file. By default, ALIEN 4 Cloud stores data in the user home directory in a .alien folder. # Configuration of Alien 4 Cloud's CSAR repository, temporary folder and upload settings. directories : # Alien 4 cloud main directory (other directories are relative path to this one) alien : ${user.home}/.alien # directory in which alien 4 cloud stores Cloud Service Archives csar_repository : csar # directory in which alien 4 cloud stores uploaded artifacts (war etc.). artifact_repository : artifacts # temporary directory for alien 4 cloud upload_temp : upload # directory in which alien 4 cloud unzips loaded plugins. plugins : plugins Admin user initialization In case there is no admin user in it’s repository, ALIEN 4 Cloud can automatically create a user with ADMIN rights. The user name and password are configured in the alien4cloud-config.yml file. Of course if an ADMIN user already exists in ALIEN then no user is created and this section is ignored. # Configuration of default admin ensurer, if true it creates a default admin user if no admin can be found in the system. users : admin : # Alien 4 cloud checks that an admin user is defined at the application launch. ensure : true username : admin password : admin email : admin@mycompany.com LDAP configuration See specific sub-section . Component search boost ALIEN 4 Cloud is managing a custom way to rank components when searching for them. In order to compute the boost for a component we get the number of topologies that uses the component and multiply it by the usage factor. Then, if a component is the latest version we add a fixed version boost, finally if a component is marked as default for at least one of it’s capability, we add another default fixed boost. In order to change the default weights you can edit the following configuration: # configure the boost factors for tosca elements in the search, elements with the highest boost factor appears first in search results # the total boost factor for a component is the sum of the following boost factors. components.search.boost : # boost components that are used in topologies by (number of active topologies that uses the component * usage) usage : 1 # components that exist in latest version get a boost factor regarding other components. Note that this factor should be very high as every component # with latest version will be boosted. version : 1000 # components that are configured as default for at least 1 capability get the following a boost factor. default : 10 "},{"title":"Advanced configuration","baseurl":"","url":"/documentation/1.0.0/admin/advanced_configuration.html","date":null,"categories":[],"body":" Alien 4 Cloud contains a basic configuration that is good enough for test environment. However in order to move into production or in order to integrate with other systems (as LDAP for example), you need to define an advanced configuration. In order to provide configuration to Alien 4 Cloud, you must place an Alien configuration file in a config folder along-side to the Alien 4 Cloud war. ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml You can find default configurations for both files in the GitHub repository: alien4cloud-config.yml elasticsearch.yml You can also add a simple start script: ├── start.sh ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml cd ` dirname $0 ` JAVA_OPTIONS = \"-server -showversion -XX:+AggressiveOpts -Xmx2g -Xms2g -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError\" java $JAVA_OPTIONS -jar alien4cloud-ui-1.0.0- { version } -standalone.war If you need to customize log4j (in order to activate some loggers, change the log file location …) add a log4j.properties in the config folder and specify the classpath for java : java $JAVA_OPTIONS -cp config/:alien4cloud-ui-1.0.0- { version } -standalone.war org.springframework.boot.loader.WarLauncher You can find a log4j sample configuration file at log4j.properties Using SSL By default Alien 4 Cloud starts using http rather than https enabling SSL is however really simple. Just edit the alien4cloud-config.yml and replace: server : port : 8080 by server : port : 8443 ssl : key-store : keystore.jks key-store-password : ****** key-password : ****** Make sure that you have your key store placed along-side the alien4cloud war file: ├── start.sh ├── alien4cloud-ui- { version } -standalone.war ├── keystore.jks ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml Elastic Search configuration ALIEN 4 Cloud uses ElasticSearch as it’s data store and indexing service. By default ALIEN 4 Cloud starts up an embedded ElasticSearch node. Of course when running in production it is recommended to use a remote cluster (ideally with high availability configured). Common configuration Common configuration allows you to configure the name of the elasticsearch cluster ( clusterName ), as well as the prefix_max_expansions (performance setting used for prefix queries). We recommend that you don’t change the default prefix_max_expansions value. If you wish to change one of the parameters, you should open the alien4cloud-config.yml file and go to the elasticSearch configuration section. elasticSearch : clusterName : escluster local : false client : false resetData : false prefix_max_expansions : 10 local and resetData should be left to false. Configure the embedded Elastic Search The embedded Elastic Search configuration elasticsearch.yml is a native elastic search configuration and you can find plenty of information on elastic search website on how you can configure it. However the main element you may wish to configure is elastic search storage directories: path : data : ${user.home}/.alien/elasticsearch/data work : ${user.home}/.alien/elasticsearch/work logs : ${user.home}/.alien/elasticsearch/logs Configure a remote Elastic Search (throw a no data node) Please note that you are encouraged to use the same version on client and cluster sides. You may hit some incompatibility issues when mixing major versions. In order to configure a remote Elastic Search, you should edit the following: In alien4cloud-config.yml file, edit the elasticSearch section and change client from false to true: elasticSearch : clusterName : escluster local : false client : true resetData : false prefix_max_expansions : 10 In the elasticsearch.yml make sure that the connection parameters matches the ones of your elasticsearch cluster. Example: discovery.zen.ping.multicast.enabled : false discovery.zen.ping.unicast.enabled : true discovery.zen.ping.unicast.hosts : 129.185.67.112 In this mode, a ‘client’ node is initialized and joins the cluster. It doesn’t store any data and act as a proxy. The machines must be visible for each other (in other words, they should be into the same network). Configure a remote Elastic Search (using a standalone transport client) In this mode, we use a simple standalone client that can be in another network as long as the cluster can be reachable. In alien4cloud-config.yml file, edit the elasticSearch section and set ‘client’ and ‘transportClient’ to true, and indicate the cluster host and port: elasticSearch : clusterName : escluster local : false client : true transportClient : true # a comma separated list of host:port couples hosts : 129.185.67.112:9300 resetData : false prefix_max_expansions : 10 In the elasticsearch.yml make sure that the cluster name is well defined (should be the same than the cluster). cluster.name : escluster Directories configuration ALIEN 4 Cloud store various files on the hard drive. Cloud Service archives, Artifacts overriden in the topologies, plugins archives etc. Directories can be configured in the alien4cloud-config.yml file. By default, ALIEN 4 Cloud stores data in the user home directory in a .alien folder. # Configuration of Alien 4 Cloud's CSAR repository, temporary folder and upload settings. directories : # Alien 4 cloud main directory (other directories are relative path to this one) alien : ${user.home}/.alien # directory in which alien 4 cloud stores Cloud Service Archives csar_repository : csar # directory in which alien 4 cloud stores uploaded artifacts (war etc.). artifact_repository : artifacts # temporary directory for alien 4 cloud upload_temp : upload # directory in which alien 4 cloud unzips loaded plugins. plugins : plugins Admin user initialization In case there is no admin user in it’s repository, ALIEN 4 Cloud can automatically create a user with ADMIN rights. The user name and password are configured in the alien4cloud-config.yml file. Of course if an ADMIN user already exists in ALIEN then no user is created and this section is ignored. # Configuration of default admin ensurer, if true it creates a default admin user if no admin can be found in the system. users : admin : # Alien 4 cloud checks that an admin user is defined at the application launch. ensure : true username : admin password : admin email : admin@mycompany.com LDAP configuration See specific sub-section . Component search boost ALIEN 4 Cloud is managing a custom way to rank components when searching for them. In order to compute the boost for a component we get the number of topologies that uses the component and multiply it by the usage factor. Then, if a component is the latest version we add a fixed version boost, finally if a component is marked as default for at least one of it’s capability, we add another default fixed boost. In order to change the default weights you can edit the following configuration: # configure the boost factors for tosca elements in the search, elements with the highest boost factor appears first in search results # the total boost factor for a component is the sum of the following boost factors. components.search.boost : # boost components that are used in topologies by (number of active topologies that uses the component * usage) usage : 1 # components that exist in latest version get a boost factor regarding other components. Note that this factor should be very high as every component # with latest version will be boosted. version : 1000 # components that are configured as default for at least 1 capability get the following a boost factor. default : 10 "},{"title":"Application(s) management","baseurl":"","url":"/documentation/1.1.0/user_guide/application_management.html","date":null,"categories":[],"body":" To understand the application concept, please refer to this section . Create new application To create an application, go in the application list page and click on the New application button. You can directly create an application from a topology template if you have one. Configure versions In the version page you can create, edit or delete a version. As we already say in the application concept page, if you remove the ‘SNAPSHOT’ qualifier, your version will be released and the associated topology not editable. Configure environments In the environment management page you can create, edit or delete an environment. The version and the cloud are the most important informations. An environment cannot be deleted when it’s application is still deploy. Manage roles Application’s roles These roles defines actions allowed by role on a given application : Role Description APPLICATION_MANAGER Application manager can manage the application configuration, it’s versions and environments as well as user management for the application. APPLICATION_DEVOPS Dev ops role should be given to the applications developer. In ALIEN users with devops role on an application can edit the topologies of every SNAPSHOT versions. In addition to the applications roles, Application manager can specify some roles related to every single environment defined for the application. Environment’s roles These roles defines actions allowed by role on a given environment : Role Description APPLICATION_USER An application user on an environment is allowed to see the environment status as well as having access to the deployment output properties (URL for example so he can directly reach the deployed application). DEPLOYMENT_MANAGER Deployment manager for an environment is responsible for configuration and deployment/undeployment of an environment. In order to be able to deploy/undeply the environment the user must also have a CLOUD_DEPLOYER role on the cloud that is associated with the environment. CLOUD_DEPLOYER role is configured on the cloud configuration by any user having the global ADMIN role. Advanced inputs This section describe how you can use internal variables defined in cloud , application or environment . Those parameters could be used as inputs for nodetemplate properties. Our target for this feature is to allow internal prefixes to target meta-properties over different elements : Targeted element Implemented Internal prefix Incoming Internal prefix Description cloud cloud_meta_ cloud_tags_ Target meta-properties or tags defined on a cloud application app_meta_ , app_tags_   Target meta-properties or tags defined on an application environment   env_meta_ , env_tags_ Target meta-properties or tags defined on an environment Define a property as an internal input When you define a topology, you may want to define some node properties as inputs. An input is by default a value required to the user in order complete the topology and deploy. You can define any property as input and then set its value in the deployment page or indicate that the input is using a internal variable defined on cloud , application or environment for example. Here, in our example let’s say that we want to use one of the meta property defined on our cloud instance : MYMETACLOUD_1 MYMETACLOUD_2 The way to do that is to prefix the cloud meta property name by one of the internal prefixes define above and give the good name to have the good targeted value : cloud_meta_ MYMETACLOUD_1 cloud_meta_ MYMETACLOUD_2 If you have some tags or meta-properties defined on your application, same syntax : app_tags_ MYAPP_TAG1 app_tags_ MYAPP_TAG2 app_meta_ MYAPP_META1 app_meta_ MYAPP_META2 Meta property naming Note : avoid dot . caracter in you meta-property name (e.g. my.meta.1) Missing values We have two possible cases regarding an input and the targeted meta-property : requirted property : if the provided value doesn’t exist as input the property will stay marked as missing and the topology not deployable optional property : if the provided value doesn’t exist you will have a warning but the deployment will still be possible In fact, the deploying page will handle warnings and tasks list to help you in having a good deployment setup. Deploy your application To deploy an application you need to configure some parameters, you can do this in the Applications > Deployments submenu. The next capture will explain the different areas of this page. Zone A : Select an environment and a cloud Here you need to select the environment of your application and the cloud. Zone B : Provider properties In this area you need to configure the properties who depends on the provider implementation. You usualy have default settings. Zone C : Topology required settings Here you need to select the value for your inputs . If they are some missing configuration in your topology, a todo list will be displayed. Zone D : Cloud resources matching In this part, you will be able to check matching cloud resources and possible matching errors. This should not happen if your cloud is well configured. Runtime view On this submenu view Application > Runtime , you can have the detailed deployment progress. The previous picture was taken during a Wordpress deployement, to deploy your own Wordpress, please refer to this section . "},{"title":"Application(s) management","baseurl":"","url":"/documentation/1.0.0/user_guide/application_management.html","date":null,"categories":[],"body":" To understand the application concept, please refer to this section . Create new application To create an application, go in the application list page and click on the New application button. You can directly create an application from a topology template if you have one. Configure versions In the version page you can create, edit or delete a version. As we already say in the application concept page, if you remove the ‘SNAPSHOT’ qualifier, your version will be released and the associated topology not editable. Configure environments In the environment management page you can create, edit or delete an environment. The version and the cloud are the most important informations. An environment cannot be deleted when it’s application is still deploy. Manage roles Application’s roles These roles defines actions allowed by role on a given application : Role Description APPLICATION_MANAGER Application manager can manage the application configuration, it’s versions and environments as well as user management for the application. APPLICATION_DEVOPS Dev ops role should be given to the applications developer. In ALIEN users with devops role on an application can edit the topologies of every SNAPSHOT versions. In addition to the applications roles, Application manager can specify some roles related to every single environment defined for the application. Environment’s roles These roles defines actions allowed by role on a given environment : Role Description APPLICATION_USER An application user on an environment is allowed to see the environment status as well as having access to the deployment output properties (URL for example so he can directly reach the deployed application). DEPLOYMENT_MANAGER Deployment manager for an environment is responsible for configuration and deployment/undeployment of an environment. In order to be able to deploy/undeply the environment the user must also have a CLOUD_DEPLOYER role on the cloud that is associated with the environment. CLOUD_DEPLOYER role is configured on the cloud configuration by any user having the global ADMIN role. Advanced inputs This section describe how you can use internal variables defined in cloud , application or environment . Those parameters could be used as inputs for nodetemplate properties. Our target for this feature is to allow internal prefixes to target meta-properties over different elements : Targeted element Implemented Internal prefix Incoming Internal prefix Description cloud cloud_meta_ cloud_tags_ Target meta-properties or tags defined on a cloud application app_meta_ , app_tags_   Target meta-properties or tags defined on an application environment   env_meta_ , env_tags_ Target meta-properties or tags defined on an environment Internal input prefixes In the cloud, the name of the target element should begin by the internal prefix to be accessible. Define a property as an internal input When you define a topology, you may want to define some node properties as inputs. An input is by default a value required to the user in order complete the topology and deploy. You can define any property as input and then set its value in the deployment page or indicate that the input is using a internal variable defined on cloud , application or environment for example. Here, in our example let’s say that we want to use one of the meta property defined on our cloud instance : MYMETACLOUD_1 MYMETACLOUD_2 The way to do that is to prefix the cloud meta property name by one of the internal prefixes define above and give the good name to have the good targeted value : cloud_meta_ MYMETACLOUD_1 cloud_meta_ MYMETACLOUD_2 If you have some tags or meta-properties defined on your application, same syntax : app_tags_ MYAPP_TAG1 app_tags_ MYAPP_TAG2 app_meta_ MYAPP_META1 app_meta_ MYAPP_META2 Meta property naming Note : avoid dot . caracter in you meta-property name (e.g. my.meta.1) Missing values We have two possible cases regarding an input and the targeted meta-property : requirted property : if the provided value doesn’t exist as input the property will stay marked as missing and the topology not deployable optional property : if the provided value doesn’t exist you will have a warning but the deployment will still be possible In fact, the deploying page will handle warnings and tasks list to help you in having a good deployment setup. "},{"title":"Applications","baseurl":"","url":"/documentation/1.1.0/concepts/applications.html","date":null,"categories":[],"body":"Alien 4 Cloud aims at managing application lifecycle and their related deployments. Applications in Alien 4 Cloud are visible only by users that have some roles within the application. In Alien 4 Cloud every application can have one or more versions and one or more environments. Versions A version represents a given state for the application topology. As we explained already a topology contains versioned informations for all components required to deploy the application meaning that a defined version of an application can be moved from a cloud to another with guaranty on the deployment content and insurance that the same components will be deployed. Snapshot and release When you create an application, Alien 4 Cloud creates a default version 0.1.0-SNAPSHOT . The qualifier SNAPSHOT is really important and means somehow In development . Indeed Alien 4 Cloud will prevent any modification of an application topology that is not a SNAPSHOT version. When you are ready to release a version just rename it and remove the SNAPSHOT qualifier (for example rename 0.1.0-SNAPSHOT to 0.1.0 ). Alien will then consider the version as released and it will not be possible to update the version. If you want to change the topology you will have to create a new version for your application (based on the previous version if you like). Environments An environment represents a deployment target for an application (of course an environment is linked to a cloud on which to deploy the environment). Like for application version, a default application environment named “Environment” is created when you create your application. This new environment is configured to target the default created version but without any associated cloud. You can specify the cloud in the environment management page or in the deployment page. You can also add a type to your environment and write a description. Application environment is a good way to design your application lifecycle accross the different environments and, eventually, clouds. For example you can design one or more development environments for your developers (on EC2 for example), and the pre-production and production environments on your own OpenStack(s). You can then move a version from an environment to another by switching the version on the environments and re-deploying it. Application lifecycle management In summary, the combination of version and environment concepts offers the ability of manage the lifecycle of your application. "},{"title":"Applications","baseurl":"","url":"/documentation/1.0.0/concepts/applications.html","date":null,"categories":[],"body":"Alien 4 Cloud aims at managing application lifecycle and their related deployments. Applications in Alien 4 Cloud are visible only by users that have some roles within the application. In Alien 4 Cloud every application can have one or more versions and one or more environments. Versions A version represents a given state for the application topology. As we explained already a topology contains versioned informations for all components required to deploy the application meaning that a defined version of an application can be moved from a cloud to another with guaranty on the deployment content and insurance that the same components will be deployed. Snapshot and release When you create an application, Alien 4 Cloud creates a default version 0.1.0-SNAPSHOT . The qualifier SNAPSHOT is really important and means somehow In development . Indeed Alien 4 Cloud will prevent any modification of an application topology that is not a SNAPSHOT version. When you are ready to release a version just rename it and remove the SNAPSHOT qualifier (for example rename 0.1.0-SNAPSHOT to 0.1.0 ). Alien will then consider the version as released and it will not be possible to update the version. If you want to change the topology you will have to create a new version for your application (based on the previous version if you like). Environments An environment represents a deployment target for an application (of course an environment is linked to a cloud on which to deploy the environment). Like for application version, a default application environment named “Environment” is created when you create your application. This new environment is configured to target the default created version but without any associated cloud. You can specify the cloud in the environment management page or in the deployment page. You can also add a type to your environment and write a description. Application environment is a good way to design your application lifecycle accross the different environments and, eventually, clouds. For example you can design one or more development environments for your developers (on EC2 for example), and the pre-production and production environments on your own OpenStack(s). You can then move a version from an environment to another by switching the version on the environments and re-deploying it. Application lifecycle management In summary, the combination of version and environment concepts offers the ability of manage the lifecycle of your application. "},{"title":"Artifact definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/artifact_definition.html","date":null,"categories":[],"body":"An artifact definition defines a named, typed file that can be associated with Node Type or Node Template and used by orchestration engine to facilitate deployment and implementation of interface operations. Keynames Keyname Type Required Description type no string The optional data type for the artifact definition. description no string The optional description for the artifact definition. mime_type no string The optional Mime type for finding the correct artifact definition when it is not clear from the file extension. deploy_path no string The file path the associated file would be deployed into within the target node’s container. Current implementation of Alien 4 Cloud does not take the deploy_path in account but rather keeps the archive layout for scripts copy. Grammar # Simple form - type and mime inferred from file URI <artifact_name> : <artifact_file_URI> # Qualified form - type and mime explicit <artifact_name> : <artifact_file_URI> type : <artifact_type_name> description : <artifact_description> mime_type : <artifact_mime_type_name> Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : artifacts : - scripts_directory : scrips type : tosca.artifacts.File description : Directory that contains all scripts. "},{"title":"Artifact definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/artifact_definition.html","date":null,"categories":[],"body":"An artifact definition defines a named, typed file that can be associated with Node Type or Node Template and used by orchestration engine to facilitate deployment and implementation of interface operations. Keynames Keyname Type Required Description type no string The optional data type for the artifact definition. description no string The optional description for the artifact definition. mime_type no string The optional Mime type for finding the correct artifact definition when it is not clear from the file extension. deploy_path no string The file path the associated file would be deployed into within the target node’s container. Current implementation of Alien 4 Cloud does not take the deploy_path in account but rather keeps the archive layout for scripts copy. Grammar # Simple form - type and mime inferred from file URI <artifact_name> : <artifact_file_URI> # Qualified form - type and mime explicit <artifact_name> : <artifact_file_URI> type : <artifact_type_name> description : <artifact_description> mime_type : <artifact_mime_type_name> Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : artifacts : - scripts_directory : scrips type : tosca.artifacts.File description : Directory that contains all scripts. "},{"title":"Artifact type","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/artifact_type.html","date":null,"categories":[],"body":"An Artifact Type is a reusable entity that defines the type of one or more files which Node Types or Node Templates can have dependent relationships and used during operations such as during installation or deployment. Keynames Keyname Type Required Description derived_from string no An optional parent Artifact Type name the Artifact Type derives from. description string no An optional description for the Artifact Type. mime_type string yes The required mime type property for the Artifact Type. file_ext string[] yes The required file extension property for the Artifact Type. properties property definitions no An optional list of property definitions for the Artifact Type. Grammar <artifact_type_name> : derived_from : <parent_artifact_type_name> description : <artifact_description> mime_type : <mime_type_string> file_ext : [ <file_extension_1> , ... , <file_extension_n> ] properties : <property_definitions> See: property_definitions Example The following example shows how to define a node type with operation: my_artifact_type : description : Java Archive artifact type derived_from : tosca.artifact.Root mime_type : application/java-archive file_ext : [ jar ] "},{"title":"Artifact type","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/artifact_type.html","date":null,"categories":[],"body":"An Artifact Type is a reusable entity that defines the type of one or more files which Node Types or Node Templates can have dependent relationships and used during operations such as during installation or deployment. Keynames Keyname Type Required Description derived_from string no An optional parent Artifact Type name the Artifact Type derives from. description string no An optional description for the Artifact Type. mime_type string yes The required mime type property for the Artifact Type. file_ext string[] yes The required file extension property for the Artifact Type. properties property definitions no An optional list of property definitions for the Artifact Type. Grammar <artifact_type_name> : derived_from : <parent_artifact_type_name> description : <artifact_description> mime_type : <mime_type_string> file_ext : [ <file_extension_1> , ... , <file_extension_n> ] properties : <property_definitions> See: property_definitions Example The following example shows how to define a node type with operation: my_artifact_type : description : Java Archive artifact type derived_from : tosca.artifact.Root mime_type : application/java-archive file_ext : [ jar ] "},{"title":"Attribute definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/attribute_definition.html","date":null,"categories":[],"body":"An attribute definition defines a named, typed value that can be associated with an entity defined in this specification (e.g., a Node Type or Relationship Type). Specifically, it is used to expose a value that is set by the orchestrator after the entity has been instantiated (as part of an instance model). Typically, this value can be retrieved via a function from the instance model and used as inputs to other entities or implementation artifacts. Keynames Keyname Type Required Description type string yes The required data type for the attribute. description string no The optional description for the attribute. default N/A no An optional key that may provide a value to be used as a default if not provided by another means. This value SHALL be type compatible with the type declared by the attribute definition’s type keyname. Grammar <attribute_name> : type : <attribute_type> description : <attribute_description> default : <attribute_default_value> Example The following example shows how to define a node type with attributes: node_types : fastconnect.nodes.AttributeSample : attributes : property_1 : type : string property_2 : type : string description : this is the second attribute of the node default : This is the default value of the attribute property_3 : type : integer default : 45 "},{"title":"Attribute definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/attribute_definition.html","date":null,"categories":[],"body":"An attribute definition defines a named, typed value that can be associated with an entity defined in this specification (e.g., a Node Type or Relationship Type). Specifically, it is used to expose a value that is set by the orchestrator after the entity has been instantiated (as part of an instance model). Typically, this value can be retrieved via a function from the instance model and used as inputs to other entities or implementation artifacts. Keynames Keyname Type Required Description type string yes The required data type for the attribute. description string no The optional description for the attribute. default N/A no An optional key that may provide a value to be used as a default if not provided by another means. This value SHALL be type compatible with the type declared by the attribute definition’s type keyname. Grammar <attribute_name> : type : <attribute_type> description : <attribute_description> default : <attribute_default_value> Example The following example shows how to define a node type with attributes: node_types : fastconnect.nodes.AttributeSample : attributes : property_1 : type : string property_2 : type : string description : this is the second attribute of the node default : This is the default value of the attribute property_3 : type : integer default : 45 "},{"title":"Backup and restore","baseurl":"","url":"/documentation/1.1.0/admin/backup_restore.html","date":null,"categories":[],"body":" Alien 4 Cloud uses several places to store it’s data. Cloud service archives Artifacts that may have been uploaded to build topologies Indexed data (stored in elastic-search) Plugins binaries Eventually you should make sure to backup also your alien4cloud yaml configuration file as well as your elastic search configuration file Backup In order to backup Alien 4 Cloud you must backup elastic search indexes as well as disk-based data. For more informations on how to backup an elasticsearch cluster please refer the elastic search documentation The following bash script gives an example on how alien4cloud data should be backed-up. It assumes that you kept the defaut directory hierarchy for alien data. # Directory in which alien stores it's disk base data. export ALIEN_DIR = ~/.alien # Url to access ElasticSearch rest api. export ES_URL = \"http://localhost:9200\" # Backup target directories export BACKUP_DIR = ~/tmp/alien_backups export BACKUP_NAME = ` date '+%d_%m_%Y_%H_%M' ` export ES_BACKUP_DIR = $BACKUP_DIR /elasticsearch export FS_BACKUP_DIR = $BACKUP_DIR /filesystem/ $BACKUP_NAME # setup elastic search snapshot repository curl -XPUT \"$ES_URL/_snapshot/alien_backup\" -d \"{ \\\"type\\\": \\\"fs\\\", \\\"settings\\\": { \\\"location\\\": \\\"$ES_BACKUP_DIR\\\", \\\"compress\\\": true } }\" # trigger elastic search data backup (asynchronous) RESULT = ` curl -XPUT \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME?wait_for_completion=false\" ` SUCCESS = $( echo \"$RESULT\" | grep \"{\\\"accepted\\\":true}\" ) if [ -z \"$SUCCESS\" ] ; then echo \"Failed to backup Elastic Search\" echo $RESULT else # Copy file system data mkdir -p $FS_BACKUP_DIR /artifacts mkdir -p $FS_BACKUP_DIR /csar mkdir -p $FS_BACKUP_DIR /plugins cp -r $ALIEN_DIR /artifacts $FS_BACKUP_DIR /artifacts cp -r $ALIEN_DIR /csar $FS_BACKUP_DIR /csar cp -r $ALIEN_DIR /plugins $FS_BACKUP_DIR /plugins # wait until elastic search backup is complete curl -XGET \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME/_status\" fi Restore We recommend users to stop alien 4 cloud but not ElasticSearch in order to perform the restore. Alien 4 Cloud should be restarted once restore is completed. However, if you 100% sure that restore operation has no impact on clouds or plugins configuration you can perform a ‘hot restore’ and don’t need to stop neither Alien 4 Cloud or ElasticSearch. In order to perform a restore with elasticsearch up and alien down you should be running in a classical production setup where elasticsearch process is independant from alien 4 cloud. See advanced configuration for more details. To restore a snapshot you should restore the elaticsearch index and put back the actual files required for Alien 4 Cloud. Before to run the script below you should make sure that alien 4 cloud is stopped and elastic-search is running. # Name of the backup to restore export BACKUP_NAME = $1 echo \"Prepare to restore $BACKUP_NAME\" # Directory in which alien stores it's disk base data. export ALIEN_DIR = ~/.alien # Url to access ElasticSearch rest api. export ES_URL = \"http://localhost:9200\" # Backup target directories export BACKUP_DIR = ~/tmp/alien_backups export FS_BACKUP_DIR = $BACKUP_DIR /filesystem/ $BACKUP_NAME # close indexes before restore operation curl -XPOST \"$ES_URL/_all/_close\" # trigger elastic search data restore RESULT = ` curl -XPOST \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME/_restore\" ` SUCCESS = $( echo \"$RESULT\" | grep \"{\\\"accepted\\\":true}\" ) if [ -z \"$SUCCESS\" ] ; then echo \"Failed to restore Elastic Search\" echo $RESULT else # Copy file system data rm -r $ALIEN_DIR /artifacts rm -r $ALIEN_DIR /csar rm -r $ALIEN_DIR /plugins cp -r $FS_BACKUP_DIR /artifacts $ALIEN_DIR /artifacts cp -r $FS_BACKUP_DIR /csar $ALIEN_DIR /csar cp -r $FS_BACKUP_DIR /plugins $ALIEN_DIR /plugins fi Once data is restored you can restart alien 4 cloud server. "},{"title":"Backup and restore","baseurl":"","url":"/documentation/1.0.0/admin/backup_restore.html","date":null,"categories":[],"body":"Alien 4 Cloud uses several places to store it’s data. Cloud service archives Artifacts that may have been uploaded to build topologies Indexed data (stored in elastic-search) Plugins binaries Eventually you should make sure to backup also your alien4cloud yaml configuration file as well as your elastic search configuration file Backup In order to backup Alien 4 Cloud you must backup elastic search indexes as well as disk-based data. For more informations on how to backup an elasticsearch cluster please refer the elastic search documentation The following bash script gives an example on how alien4cloud data should be backed-up. It assumes that you kept the defaut directory hierarchy for alien data. # Directory in which alien stores it's disk base data. export ALIEN_DIR = ~/.alien # Url to access ElasticSearch rest api. export ES_URL = \"http://localhost:9200\" # Backup target directories export BACKUP_DIR = ~/tmp/alien_backups export BACKUP_NAME = ` date '+%d_%m_%Y_%H_%M' ` export ES_BACKUP_DIR = $BACKUP_DIR /elasticsearch export FS_BACKUP_DIR = $BACKUP_DIR /filesystem/ $BACKUP_NAME # setup elastic search snapshot repository curl -XPUT \"$ES_URL/_snapshot/alien_backup\" -d \"{ \\\"type\\\": \\\"fs\\\", \\\"settings\\\": { \\\"location\\\": \\\"$ES_BACKUP_DIR\\\", \\\"compress\\\": true } }\" # trigger elastic search data backup (asynchronous) RESULT = ` curl -XPUT \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME?wait_for_completion=false\" ` SUCCESS = $( echo \"$RESULT\" | grep \"{\\\"accepted\\\":true}\" ) if [ -z \"$SUCCESS\" ] ; then echo \"Failed to backup Elastic Search\" echo $RESULT else # Copy file system data mkdir -p $FS_BACKUP_DIR /artifacts mkdir -p $FS_BACKUP_DIR /csar mkdir -p $FS_BACKUP_DIR /plugins cp -r $ALIEN_DIR /artifacts $FS_BACKUP_DIR /artifacts cp -r $ALIEN_DIR /csar $FS_BACKUP_DIR /csar cp -r $ALIEN_DIR /plugins $FS_BACKUP_DIR /plugins # wait until elastic search backup is complete curl -XGET \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME/_status\" fi Restore We recommend users to stop alien 4 cloud but not ElasticSearch in order to perform the restore. Alien 4 Cloud should be restarted once restore is completed. However, if you 100% sure that restore operation has no impact on clouds or plugins configuration you can perform a ‘hot restore’ and don’t need to stop neither Alien 4 Cloud or ElasticSearch. In order to perform a restore with elasticsearch up and alien down you should be running in a classical production setup where elasticsearch process is independant from alien 4 cloud. See advanced configuration for more details. To restore a snapshot you should restore the elaticsearch index and put back the actual files required for Alien 4 Cloud. Before to run the script below you should make sure that alien 4 cloud is stopped and elastic-search is running. # Name of the backup to restore export BACKUP_NAME = $1 echo \"Prepare to restore $BACKUP_NAME\" # Directory in which alien stores it's disk base data. export ALIEN_DIR = ~/.alien # Url to access ElasticSearch rest api. export ES_URL = \"http://localhost:9200\" # Backup target directories export BACKUP_DIR = ~/tmp/alien_backups export FS_BACKUP_DIR = $BACKUP_DIR /filesystem/ $BACKUP_NAME # close indexes before restore operation curl -XPOST \"$ES_URL/_all/_close\" # trigger elastic search data restore RESULT = ` curl -XPOST \"$ES_URL/_snapshot/alien_backup/$BACKUP_NAME/_restore\" ` SUCCESS = $( echo \"$RESULT\" | grep \"{\\\"accepted\\\":true}\" ) if [ -z \"$SUCCESS\" ] ; then echo \"Failed to restore Elastic Search\" echo $RESULT else # Copy file system data rm -r $ALIEN_DIR /artifacts rm -r $ALIEN_DIR /csar rm -r $ALIEN_DIR /plugins cp -r $FS_BACKUP_DIR /artifacts $ALIEN_DIR /artifacts cp -r $FS_BACKUP_DIR /csar $ALIEN_DIR /csar cp -r $FS_BACKUP_DIR /plugins $ALIEN_DIR /plugins fi Once data is restored you can restart alien 4 cloud server. "},{"title":"Defaut Blockstorage","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/blockstorage.html","date":null,"categories":[],"body":"Here are informations about the default normative type Blockstorage support. tosca.nodes.BlockStorage type You should add the node type tosca.nodes.BlockStorage to your topology, and attach it to a compute node. Node properties volumeId The provider can attach to a compute a created and formatted storage. Thus, you need to provide it for the ID of the volume you would like to attach, through the node property volumeId . size If no volumeId is provided, the provider will check for the size property, and use it to match a storage compute configured in the used cloud. Then, it will create a new volume, and format it ( default file system is ext4 ). How it works provider configuration If you have storage templates defined in your Clouify cloud’s file, you can configure them in the provider. Flow First you should add a BlockStorage node to your topology, attach it to a Compute node, and fill in if necessary the properties volumeId and size . When the provider process the topology for deployment, If the volumeId is defined , the provider will: try to locate the storage attach it to the compute mount it to the /mountedStorage directory. Else, if the size is defined , it will: Try to determin a storage template matching the exact given size. Create a volume based on the choosen template Format it using ext4 file system attach it to the compute mount it to the /mountedStorage directory. When the volume is created, his Id is updated in the deployed topology , so that it could be reused fro the next deployment. If neither the volumeId nor the size are defined, the provider will use the storage template difined with the lowest size to create the volume. When undeploying the application, the provider will: unmount the strorage detach it from the compute node to set free the resource. Note that the data are not deleted . Working with scaling policy If you are deploying the application with more than one instance, you can provide comma separated volumes Ids, ordered by instances id. Let take an example for illustration: deploying with the following configuations: minInstances : 1 maxInstance : 3 initialInstances : 3 volumeId : a,b,c Then, the instance 1,2,3 will use respectively the Ids a,b,c . As for the instance 4 , if a size is specified, it will be used to find the matching storage template (if not the default template is used) and create a volume ( d ). After then, the volumeId property will be updated to a,b,c,d . As stated previously, a storage created with the type tosca.nodes.BlockStorage is not deleted when undeploying the concerned application. However, if you want a storage auto-deletable, you can use the type alien.nodes.DeletableBlockStorage . That will ensure that the volume is destroyed, but of course the topology won’t be updated with the created volumeId. "},{"title":"Capability definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/capability_definition.html","date":null,"categories":[],"body":"A capability definition defines a named, typed set of data that can be associated with Node Type or Node Template to describe a transparent capability or feature of the software component the node describes. Keynames Keyname Type Required Description type string yes Type of capability or node that is required by the current node. description string no The optional description of the Capability Type. properties list of properties values no Properties values for the properties defined on the capability type. attributes list of attributes values no Attributes values for the attributes defined on the capability type. upper_bound integer (or unbounded string) no Specifies the upper boundary of client requirements the defined capability can serve. A value of unbounded indicates that there is no upper boundary. Defaults to unbounded. upper_bound is an Alien specific property that is currently not part of the official specification for the TOSCA simple profile in YAML. Grammar # Simple definition is as follows: <capability_defn_name> : <capability_type> # The full definition is as follows: <capability_defn_name> : type : <capability_type> description : <capability_defn_description> properties : <property_values> attributes : <attribute_values> upper_bound : <upper_bound> Example node_types : fastconnect.nodes.CapabilitySample : capabilities : # Simple form, no properties defined or augmented test_capability : mytypes.mycapabilities.MyCapabilityTypeName # Full form, augmenting properties of the referenced capability type some_capability : type : mytypes.mycapabilities.MyCapabilityTypeName properties : limit : 100 upper_bound : 3 "},{"title":"Capability definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/capability_definition.html","date":null,"categories":[],"body":"A capability definition defines a named, typed set of data that can be associated with Node Type or Node Template to describe a transparent capability or feature of the software component the node describes. Keynames Keyname Type Required Description type string yes Type of capability or node that is required by the current node. description string no The optional description of the Capability Type. properties list of properties values no Properties values for the properties defined on the capability type. attributes list of attributes values no Attributes values for the attributes defined on the capability type. upper_bound integer (or unbounded string) no Specifies the upper boundary of client requirements the defined capability can serve. A value of unbounded indicates that there is no upper boundary. Defaults to unbounded. upper_bound is an Alien specific property that is currently not part of the official specification for the TOSCA simple profile in YAML. Grammar # Simple definition is as follows: <capability_defn_name> : <capability_type> # The full definition is as follows: <capability_defn_name> : type : <capability_type> description : <capability_defn_description> properties : <property_values> attributes : <attribute_values> upper_bound : <upper_bound> Example node_types : fastconnect.nodes.CapabilitySample : capabilities : # Simple form, no properties defined or augmented test_capability : mytypes.mycapabilities.MyCapabilityTypeName # Full form, augmenting properties of the referenced capability type some_capability : type : mytypes.mycapabilities.MyCapabilityTypeName properties : limit : 100 upper_bound : 3 "},{"title":"Capability type","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/capability_type.html","date":null,"categories":[],"body":"A Capability Type is a reusable entity that describes a kind of capability that a Node Type can declare to expose. Requirements (implicit or explicit) that are declared as part of one node can be matched to (i.e., fulfilled by) the Capabilities declared by other node. Keynames Keyname Type Required Description derived_from string no An optional parent Capability Type name the Capability Type derives from. description string no An optional description for the Capability Type. properties property definitions no An optional list of property definitions for the Capability Type. Grammar <capability_type_name> : derived_from : <parent_capability_type_name> description : <capability_description> properties : <property_definitions> See: property_definitions Example The following example shows how to define a node type with operation: mycompany.mytypes.myapplication.MyFeature : derived_from : tosca.capabilities.Feature description : a custom feature of my company’s application properties : my_feature_setting : type : string my_feature_value : type : integer "},{"title":"Capability type","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/capability_type.html","date":null,"categories":[],"body":"A Capability Type is a reusable entity that describes a kind of capability that a Node Type can declare to expose. Requirements (implicit or explicit) that are declared as part of one node can be matched to (i.e., fulfilled by) the Capabilities declared by other node. Keynames Keyname Type Required Description derived_from string no An optional parent Capability Type name the Capability Type derives from. description string no An optional description for the Capability Type. properties property definitions no An optional list of property definitions for the Capability Type. Grammar <capability_type_name> : derived_from : <parent_capability_type_name> description : <capability_description> properties : <property_definitions> See: property_definitions Example The following example shows how to define a node type with operation: mycompany.mytypes.myapplication.MyFeature : derived_from : tosca.capabilities.Feature description : a custom feature of my company’s application properties : my_feature_setting : type : string my_feature_value : type : integer "},{"title":"Cloud(s) management","baseurl":"","url":"/documentation/1.1.0/user_guide/cloud_management.html","date":null,"categories":[],"body":" To understand the cloud concept, please refer to this section . Requirement for cloud creation Alien 4 cloud is not responsible for actual deployment orchestration but rather interact with existing orchestration technologies. In order to define a cloud you must configure plugins that will be used to actually perform deployment(s) on the defined cloud. Orchestrator plugins are refered in alien as PaaS Provider plugins. In order to configure a cloud you must have installed a paas provider plugin first see plugin management . Supported orchestrators We are currently supporting the opensource orchestrators cloudify 3 (Full re-written engine with new DSL - much better and flexible but that we felt prior to the up-comming 3.2 a bit light for production use). Cloud creation Once you have installed a plugin the admin can go on the cloud page and configure cloud. Remember that you can use the Alien 4 Cloud contextual help in order to be guided directly within the application. To create a cloud, just go in the cloud list page and click on the New cloud button. Cloud global configuration To configure a cloud, select it in the cloud list page and go to C onfiguration tab. Naming policy On every cloud, you can configure a naming policy that Alien 4 Cloud will use when deploying an application on a cloud. The naming policy will be used to identify the deployment on the cloud’s orchestrator (PaaS Provider). Most of the PaaS Providers will leverage this naming policy to name the resources used at the IaaS level also. To compose your own application naming policy, you can use the following entities and properties : environment : the environment linked to the deployment id name description environmentType : OTHER, DEVELOPMENT, INTEGRATION_TESTS, USER_ACCEPTANCE_TESTS, PRE_PRODUCTION, PRODUCTION application : deployed application id name creationDate lastUpdateDate metaProperties [‘PROPERTY_NAME’] : meta-properties defined on the application time : current date at format yyyyMMddHHmm The default naming policy setting for any cloud is : environment.name + application.name Deployment name unicity The deployment name must be unique at a given time, the cloud administrator is responsible for choosing a pattern that should be unique or some application(s) may not be deployed (if a deployment with the same name is already running). Note that in we guaranty that an application name is unique across all applications and that an environment name is unique for a given application. However, when generating the application paaSId (final application name on the PaaS), all space character will be replaced by an _ . Therefore and as an example, if your naming policy involves the application name, you can not deploy simultaneously two applications named “ Test App ” and “ Test_App ” on the same cloud, as the generated paaSId will be in conflict. The main pattern to define a naming policy is to use + to concat different properties or text, for examples : environment.name + application.name + time application.id + environment.environmentType + '-US_ZONE' time + '__' + application.creationDate 'MY_APP' + '-WORDPRESS-' + time metaProperties['PROPERTY_NAME'] + '-' + time Empty meta properties Any empty property used in the naming policy expression will cause a deployment failure. Advanced use : the policy expression is based on SpEL ( Spring Expression Language ) and you could use its capabilities if you are familiar with it. Note : do not use the # Meta properties This feature allows you to define meta-properties on your cloud and then use them in your topology as an internal variable defined by your administrator. Obviously as a CLOUD_DELOYER , APPLICATION_USER or APPLICATION_MANAGER you won’t be able to change this value. At this stage, we assume that you’ve read the tutorial part to create global meta-properties as an ADMIN, to be more specific you know how to create meta-properties targeting cloud, application or environment. In global configuration in the meta-properties part you should be able to define a value for any cloud targeted meta-properties. Fill the desired values in order to use it later as in get_input for a property. Regarding your meta-property definition, you can add constraint on a meta property. In this case you must see constraint violation error if any in this cloud meta-properties form. PaaS Provider configuration The configuration tab on the cloud view allows to setup the provider specific configuration. It is mostly used to configure the provider connexion parameters so Alien 4 Cloud can communicate with the orchestrator engine server. This configuration may be specific to the orchestrator used and you should refer to the orchestrator specific guide. The next capture show the driver configuration of cloudify 2. More informations for cloudify 3 can be found on her specific documentation. Cloud resources setup Once created you must configure the cloud. Configuring a cloud requires several steps: Configure cloud resources (images and flavors) used for resources matching at deployment time. Configure the properties of the PaaS provider (that depends of the chosen one). Configure cloud resources Images In this page you need to add images to your cloud. An image describes the informations of a virtual machine template , you need to resume the images of your PaaS. For example, here the screen of a cloud with Ubuntu Vivid Vervet (the cloud is not enabled at this moment). Flavors Flavor is a combination of informations to describe the hardware templates used by the PaaS. They are 3 informations: number of core disk size RAM size Lot of flavors offer the flexibility for APPLICATION_MANAGER to choose the appropriate resources for an application. Like for images, here a screen of the flavor page (the cloud is not enabled at this moment). Configure PaaS templates For the next step, you need to enable your cloud. Just go in the details page and click one the enable button. If the startup has failed, check your PaaS driver configuration. When the cloud is enabled, go to image page to set the PaaS resource ID of your images. Once all images are complete, the alert icon on image tab will be deleted : After this, do the same thing with the flavor. When an ID is set, the number of template is updated : When the cloud is enabled, go to image page to set the PaaS resource ID of your images. Once all images are complete, the alert icon on image tab will be deleted : After this, do the same thing with the flavor. When an ID is set, the number of template is updated : More informations for the PaaS template of cloudify 3 can be found on her specific documentation. "},{"title":"Cloud(s) management","baseurl":"","url":"/documentation/1.0.0/user_guide/cloud_management.html","date":null,"categories":[],"body":" To understand the cloud concept, please refer to this section . Requirement for cloud creation Alien 4 cloud is not responsible for actual deployment orchestration but rather interact with existing orchestration technologies. In order to define a cloud you must configure plugins that will be used to actually perform deployment(s) on the defined cloud. Orchestrator plugins are refered in alien as PaaS Provider plugins. In order to configure a cloud you must have installed a paas provider plugin first see plugin management . Supported orchestrators We are currently supporting the opensource orchestrators cloudify 2 and cloudify 3 (Full re-written engine with new DSL - much better and flexible but that we felt prior to the up-comming 3.2 a bit light for production use). Cloud creation Once you have installed a plugin the admin can go on the cloud page and configure cloud. Remember that you can use the Alien 4 Cloud contextual help in order to be guided directly within the application. To create a cloud, just go in the cloud list page and click on the New cloud button. Cloud global configuration To configure a cloud, select it in the cloud list page and go to C onfiguration tab. Naming policy On every cloud, you can configure a naming policy that Alien 4 Cloud will use when deploying an application on a cloud. The naming policy will be used to identify the deployment on the cloud’s orchestrator (PaaS Provider). Most of the PaaS Providers will leverage this naming policy to name the resources used at the IaaS level also. To compose your own application naming policy, you can use the following entities and properties : environment : the environment linked to the deployment id name description environmentType : OTHER, DEVELOPMENT, INTEGRATION_TESTS, USER_ACCEPTANCE_TESTS, PRE_PRODUCTION, PRODUCTION application : deployed application id name creationDate lastUpdateDate metaProperties [‘PROPERTY_NAME’] : meta-properties defined on the application time : current date at format yyyyMMddHHmm The default naming policy setting for any cloud is : environment.name + application.name Deployment name unicity The deployment name must be unique at a given time, the cloud administrator is responsible for choosing a pattern that should be unique or some application(s) may not be deployed (if a deployment with the same name is already running). Note that in we guaranty that an application name is unique across all applications and that an environment name is unique for a given application. However, when generating the application paaSId (final application name on the PaaS), all space character will be replaced by an _ . Therefore and as an example, if your naming policy involves the application name, you can not deploy simultaneously two applications named “ Test App ” and “ Test_App ” on the same cloud, as the generated paaSId will be in conflict. The main pattern to define a naming policy is to use + to concat different properties or text, for examples : environment.name + application.name + time application.id + environment.environmentType + '-US_ZONE' time + '__' + application.creationDate 'MY_APP' + '-WORDPRESS-' + time metaProperties['PROPERTY_NAME'] + '-' + time Empty meta properties Any empty property used in the naming policy expression will cause a deployment failure. Advanced use : the policy expression is based on SpEL ( Spring Expression Language ) and you could use its capabilities if you are familiar with it. Note : do not use the # Meta properties This feature allows you to define meta-properties on your cloud and then use them in your topology as an internal variable defined by your administrator. Obviously as a CLOUD_DELOYER , APPLICATION_USER or APPLICATION_MANAGER you won’t be able to change this value. At this stage, we assume that you’ve read the tutorial part to create global meta-properties as an ADMIN, to be more specific you know how to create meta-properties targeting cloud, application or environment. In global configuration in the meta-properties part you should be able to define a value for any cloud targeted meta-properties. Fill the desired values in order to use it later as in get_input for a property. Regarding your meta-property definition, you can add constraint on a meta property. In this case you must see constraint violation error if any in this cloud meta-properties form. PaaS Provider configuration The configuration tab on the cloud view allows to setup the provider specific configuration. It is mostly used to configure the provider connexion parameters so Alien 4 Cloud can communicate with the orchestrator engine server. This configuration may be specific to the orchestrator used and you should refer to the orchestrator specific guide. The next capture show the driver configuration of cloudify 2. More informations for cloudify 2 or cloudify 3 can be found on her specific documentation. Cloud resources setup Once created you must configure the cloud. Configuring a cloud requires several steps: Configure cloud resources (images and flavors) used for resources matching at deployment time. Configure the properties of the PaaS provider (that depends of the chosen one). Configure cloud resources Images In this page you need to add images to your cloud. An image describes the informations of a virtual machine template , you need to resume the images of your PaaS. For example, here the screen of a cloud with Ubuntu Vivid Vervet (the cloud is not enabled at this moment). Flavors Flavor is a combination of informations to describe the hardware templates used by the PaaS. They are 3 informations: number of core disk size RAM size Lot of flavors offer the flexibility for APPLICATION_MANAGER to choose the appropriate resources for an application. Like for images, here a screen of the flavor page (the cloud is not enabled at this moment). Configure PaaS templates For the next step, you need to enable your cloud. Just go in the details page and click one the enable button. If the startup has failed, check your PaaS driver configuration. When the cloud is enabled, go to image page to set the PaaS resource ID of your images. Once all images are complete, the alert icon on image tab will be deleted : After this, do the same thing with the flavor. When an ID is set, the number of template is updated : When the cloud is enabled, go to image page to set the PaaS resource ID of your images. Once all images are complete, the alert icon on image tab will be deleted : After this, do the same thing with the flavor. When an ID is set, the number of template is updated : More informations for the PaaS template of cloudify 2 or cloudify 3 can be found on her specific documentation. "},{"title":"Customizing Cloudify","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/cloudify.html","date":null,"categories":[],"body":"Before everything, you need a running instance of Cloudify. The instance can be launched wherever you want, but make sure to have access to the REST API’s URL, which will be needed later on. Setup Make sure you have installed a Java JDK 1.6 or higher and set your JAVA_HOME properly. The recommended version is JDK 7u45 Download and unzip the Cloudify distribution file. Now for this driver to work, you have to customize your instaled Cloudify. Custom events In order to handle Cloudify lifecycle events, and to emit our own events, we need the alien4cloud-cloudify-custom-events . This provides a REST API and uses the Gigaspace management space to store the events. Download the zip archive and unzip it into the folder of your prefered cloud driver (e.g. gigaspaces-cloudify-2.7.0-ga/clouds/openstack-havana ) 1.0.0 If working with a secured manager: create a file events.properties and place it either next or into the events folder Edit it with the following entries (replace “cdfy_username” and “cdfy_password” by proper values): cloudUsername = <cdfy_username> cloudPassword = <cdfy_password> In the upload folder, edit the bootstrap-management.sh : Locate the line cat < ( crontab -l ) < ( echo \"@reboot export EXT_JAVA_OPTIONS=$EXT_JAVA_OPTIONS; nohup ~/gigaspaces/tools/cli/cloudify.sh $START_COMMAND $START_COMMAND_ARGS\" ) | crontab - Right after that line, add the following snippet if [ \"$GSA_MODE\" = \"lus\" ] ; then exportJavaHome = \"\" if [ ! -z ${ JAVA_HOME } ] ; then exportJavaHome = \"export JAVA_HOME=${JAVA_HOME}; \" fi cat < ( crontab -l ) < ( echo \"@reboot ${exportJavaHome} export LUS_IP_ADDRESS=$LUS_IP_ADDRESS; chmod +x ${WORKING_HOME_DIRECTORY}/events/bin/gsDeployEventsWar.sh; nohup ${WORKING_HOME_DIRECTORY}/events/bin/gsDeployEventsWar.sh\" ) | crontab - fi Locate the line ./cloudify.sh $START_COMMAND $START_COMMAND_ARGS Right after that line, add the following snippet if [ \"$GSA_MODE\" = \"lus\" ] ; then EVENTS_PATH = \"${WORKING_HOME_DIRECTORY}/..\" chmod +x ${ EVENTS_PATH } /events/bin/gsDeployEventsWar.sh ${ EVENTS_PATH } /events/bin/gsDeployEventsWar.sh fi A command tree on your cloud folder should look like this: The <cdfy_username> and <cdfy_password> are the credentials to provide to the custom events application, used to connect via REST API to the manager. Make sure to provide good credentials if working with a secured manager. If not, they are optional. Persistence If you want to use cloudify in a persistent mode, you should override the cloulify management space: in the configure section of your cloud (in the .groovy cloud configuration file)), set a value for the property persistentStoragePath cloud { name = \"your_cloud_name\" ... configuration { ... //for persistence of management space persistentStoragePath \"path/to/persist/data\" } } Under the upload folder of your prefered cloud driver, create (if not exists) the path cloudify-overrides/tools/management-space Download the custom management space jar and store it into the newly created folder. Rename it if needed into management-space.jar . High Availability (HA) Alien4Cloud has a feature which will allow him to manage HA deploiements: deploy an application on a cloud, but in more than one availability zone (AZ). Currently, it is not possible to generate cloudify compute templates customized with a particular AZ. Thus, you’ll have to defined them explicetelly in the cloudCompute templates section of your cloud configuration file. First of all, you should make an inventory of all the AZ you want to be managed. Then, For every template defined in the cloudCompute section of of your cloud, define a HA equivalent for every managed AZ. To do so: copy & paste the template definition rename it following the pattern: _<TEMPLATE_NAME>_AZ_<AZ_name> modify (or add if not yet) the property “locationId” and set its value to the name of the AZ. At the end of the operation, given you have n cloudify templates and m AZ to manage, you shoud have n + (n x m) entries in the cloudCompute templates section. Exemple : with a template SMALL_LINUX and two AZ zone1 and zone2, we hould end up with 3 templates entries: cloud { name = \"your_cloud_name\" ... cloudCompute { templates ([ SMALL_LINUX : computeTemplate { ... }, _SMALL_LINUX_AZ_zone1 : computeTemplate { ... locationId zone1 ... }, _SMALL_LINUX_AZ - zone2 : computeTemplate { ... locationId zone2 ... } ]) } } Bootstraping Bootstrap your cloud, and when done, note the REST API URL (Rest service bellow) Rest service is avalaible at: http://management_ip:8100 Webui service is avalaible at: http://management_ip:8099 Typing http://management_ip:8081/events/test in a web browser should display the message : is running Now that you have a JAVA_HOME set and a customized running instance of Cloudify, you can move to the next step, how to install and configure the driver . If you want to use the provider’s blockStorage feature, in addition to the storage configuration of you cloud, you must make sure to have the property privileged true in all of your compute templates’ definitions. "},{"title":"Cloudify 3 Plugin","baseurl":"","url":"/developer_guide/cloudify_3_plugin.html","date":null,"categories":[],"body":"Cloudify 3 plugin allows deployments of TOSCA topologies defined in Alien 4 Cloud to a cloudify 3 manager. This section is not dedicated to users of the plugin but to developers who have created Cloudify 3 plugins and want to integrate them with Alien 4 Cloud. Adding a new location type When defining a cloudify 3 plugin to support a new location type (openstack, azure, amazon etc.) users will define their types, for example the official openstack plugin defines the following types (amongst others): - cloudify.openstack.nodes.Server - cloudify.openstack.nodes.FloatingIP - cloudify.openstack.nodes.Network - cloudify.openstack.nodes.Subnet - cloudify.openstack.nodes.Volume In order to integrate these types with alien 4 cloud two solutions exists: - Map them to normative types so a normative topology can be configured. - Map them to pure cloudify types (this solution is actually not supported by Alien 4 Cloud official cloudify 3 plugin) Define location types into Alien 4 Cloud Define mapping rules from TOSCA types to Location types Define mapping rules from Location Types to the cloudify types DSL mapping Mapping of types from tosca nodes to the cloudify dsl is done through velocity. When the type exposed to the tosca world is matching the same definition as the one in the cloudify world mapping is straightforward and it is possible to use the generic mapping: For more advanced mapping (properties getting placed elseware etc.) you can use a more advanced mapping by providing your own velocity template. It is even possible to map a single node from TOSCA into multiple nodes in cloudify. For example the tosca.nodes.Network type can be mapped to various definitions: Attributes mapping In cloudify all attributes are actually runtime properties. Some naming in cloudify are not the same as in the TOSCA world. Cloudify 3 plugin allows mapping of the attributes so they match the required TOSCA normative naming. In order to do so developer of a location can add some attribute mapping in a TOSCA way when they define the location types. Theses attributes will be reused by cloudify 3 plugin to generate mapping code. TODO EXAMPLE WITH THE COMPUTE NODE FROM CLOUDIFY 3 "},{"title":"Clouds","baseurl":"","url":"/documentation/1.0.0/concepts/clouds.html","date":null,"categories":[],"body":"In Alien 4 Cloud every deployment is done on what we call a Cloud . Clouds are used to describe a logical deployment target that offers a set of resources (e.g. machines, storage, network, firewalls etc.). A cloud may refer to a real cloud , to a specific tenant on a cloud , to a set of physical machines (BYON), or even docker containers. You can create and configure as many clouds as you like to have as many deployment targets (environments) as required. For example a cloud can refer to an Amazon configuration using a specific account while another cloud could be configured to work on a specific Tenant on an OpenStack cloud. To make it simple a cloud is a logical set of available resources that Alien 4 Cloud can use to deploy applications. In order to do so A4C relies on orchestration technologies that are easily pluggable. Note We are currently supporting the opensource orchestrators cloudify 2 and cloudify 3 (Full re-written engine with new DSL - much better and flexible but that we felt prior to the up-comming 3.2 a bit light for production use). Role and security Only a user with the global ADMIN role can define, configure, enable and grant deployment role to other users or groups on a cloud. To find more on clouds and how to configure them in Alien 4 Cloud please look at the Getting started guide if you don’t already have an Alien instance running and at the cloud setup guide in order to learn cloud configuration. A cloud supported the following resources : Compute: TOSCA node who represents a real or virtual machine or ‘server’ Storage: TOSCA node who represents a server-local block storage device Availability zone: Alien feature to separate your node into separate geographic area Network: Alien feature based on the TOSCA expressiveness to control the mapping of software component to the network "},{"title":"Components","baseurl":"","url":"/documentation/1.0.0/concepts/components.html","date":null,"categories":[],"body":"Components are building blocks that directly refers to TOSCA’s Node Types. Alien4Cloud maintain a catalog of Components that is shared across the platform users. Alien’s component catalog is indexed allowing users to browse, search and use filtering to find the components they need. Thanks to the components available in the platform, architect and application developers will be able to define application topologies (or blueprints). There is multiple types of components in Alien 4 Cloud that directly refers to the TOSCA specification, below is explained the different types of components that you can find and extend. Node Types Node Types are used to define some cloud resources elements (Compute - machine, Block-Storage - persistent disk, Network etc.) as well as software components (Database, WebServer etc.). TOSCA Simple profile in YAML provides some pre-defined Node Types, more informations on the various pre-defined node types can be found here . A node type as every component may expose some capabilities (things that the node provides and that other nodes will be able to consume) and requirements (things that nodes actually requires in order to work correctly). For example a Compute node type (that represents a Machine) has the capability to host some softwares and a Software Component (or any inherited node) requires a Compute on which to be hosted on (installed and run). Relationship Types Relationship types are used to connect nodes. A relationship in TOSCA and Alien is directional, it connects the requirement of a source node to the capability of a target node. In order to be used in the right context only, a relationship can specify what type of capability (thus requirement) it can connects. "},{"title":"Components","baseurl":"","url":"/documentation/1.1.0/concepts/components.html","date":null,"categories":[],"body":"Components are building blocks that directly refers to TOSCA’s Node Types. Alien4Cloud maintain a catalog of Components that is shared across the platform users. Alien’s component catalog is indexed allowing users to browse, search and use filtering to find the components they need. Thanks to the components available in the platform, architect and application developers will be able to define application topologies (or blueprints). There is multiple types of components in Alien 4 Cloud that directly refers to the TOSCA specification, below is explained the different types of components that you can find and extend. Node Types Node Types are used to define some cloud resources elements (Compute - machine, Block-Storage - persistent disk, Network etc.) as well as software components (Database, WebServer etc.). TOSCA Simple profile in YAML provides some pre-defined Node Types, more informations on the various pre-defined node types can be found here . A node type as every component may expose some capabilities (things that the node provides and that other nodes will be able to consume) and requirements (things that nodes actually requires in order to work correctly). For example a Compute node type (that represents a Machine) has the capability to host some softwares and a Software Component (or any inherited node) requires a Compute on which to be hosted on (installed and run). Relationship Types Relationship types are used to connect nodes. A relationship in TOSCA and Alien is directional, it connects the requirement of a source node to the capability of a target node. In order to be used in the right context only, a relationship can specify what type of capability (thus requirement) it can connects. "},{"title":"Components catalog","baseurl":"","url":"/documentation/1.0.0/user_guide/components_management.html","date":null,"categories":[],"body":" To understand the components concept, please refer to this section . Components catalog In Alien 4 Cloud you can design your applications by adding multiple components to a topology and defining relationships between them. The definition of components and topologies is based on TOSCA standard. Alien 4 Cloud allow you to add components into the indexed catalog. For more informations on TOSCA and supported archive format please go here . Uploading new components You cannot upload the same archive (same id and version) mutliple times. If you changed an archive, you must increment the version number so you can upload it to Alien. Create your own component If you want create your own component please go here . Roles and security In order to be able to add components to the repository you must have the COMPONENT_MANAGER role. Note that if the archive you wish to upload contains both nodes and relationship types and both a topology template, then you must have both the COMPONENT_MANAGER and ARCHITECT role There are three ways to upload components descriptions in ALIEN regarding you browser capabilities : Drag you archive file > Drop it on the dash dotted area Click on [Upload CSAR] > Select your archive (The file is automaticly uploaded) Once upload has been completed successfully you should be able to see the node types contained in the archive in the components browsing panel. You can now browse and search for components . Upload issues Alien 4 Cloud performs validation of your archive agains the TOSCA specification. The following image shows the upload of an archive with an error : Components search Alien4Cloud provides ways to browse the uploaded components, with a search engine allowing filters. Users with role COMPONENT_MANAGER can browse and search for components. How to make a simple search On the left of the components list page, there is a search pannel (see figure above: A ). For a simple search, just type the searched text in the seach field and press the magnifier next to it (or press the Enter keybord instead). The result of your research will be displayed on the center pannel (see figure above: B ). How to make a filtered search You might wish to filter your search or results, for there are too many components corresponding to the simple search. Still on the left search pannel, you can select one or more filters (facets). You can also remove them if they do not fit you. Note that when more than one filter are selected, Alien4Cloud applies an AND policy. Component overview After the search, you can have an overview of the component. Just move the mouse on one component and you will have the right pannel display its summary:(see figure above: C ). If it is the one you are looking for, or if you want further informations about it, you can now select it and see its details. "},{"title":"Components catalog","baseurl":"","url":"/documentation/1.1.0/user_guide/components_management.html","date":null,"categories":[],"body":" To understand the components concept, please refer to this section . Components catalog In Alien 4 Cloud you can design your applications by adding multiple components to a topology and defining relationships between them. The definition of components and topologies is based on TOSCA standard. Alien 4 Cloud allow you to add components into the indexed catalog. For more informations on TOSCA and supported archive format please go here . Uploading new components You cannot upload the same archive (same id and version) mutliple times. If you changed an archive, you must increment the version number so you can upload it to Alien. Create your own component If you want create your own component please go here . Roles and security In order to be able to add components to the repository you must have the COMPONENT_MANAGER role. Note that if the archive you wish to upload contains both nodes and relationship types and both a topology template, then you must have both the COMPONENT_MANAGER and ARCHITECT role There are three ways to upload components descriptions in ALIEN regarding you browser capabilities : Drag you archive file > Drop it on the dash dotted area Click on [Upload CSAR] > Select your archive (The file is automaticly uploaded) Git repository hierarchie In order to be able to import components properly, this feature required a folder organisation based on TOSCA recommendation For example, if you want to import one of the Samples repository, the folder to import musn’t contains a Yaml file at its root. See apache archive for examples Github apache example . If the folder is based on an older TOSCA recommandation, please ensure you have a folder named TOSCA-Metadata and the YAML file to import in another folder See recipes archive for examples Gitblit recipes example . Click on create new CSAR > Fill the modal and click on New CSAR . Fill the modal by typing expected values and click on create . In the Archive’s name text field : put the name of the folder containing the yaml file for example apache to import Apache component in the Samples repository . You can also leave this text filed empty : it will import all the folders if its contains a yaml file . Credentials text fields can be used to access private repository. Click on Save the repository locally if you want the repository to be stored on your computer, this will enable the versionning manager on it. Now you should be able to see the Csargit created in the tab below Click on the icon Import to trigger the import process Now you should be able to see the imported Csar in the Csars added tab and the related import result in the tab below. Once upload has been completed successfully you should be able to see the node types contained in the archive in the components browsing panel. You can now browse and search for components . Upload issues Alien 4 Cloud performs validation of your archive agains the TOSCA specification. The following image shows the upload of an archive with an error : Components search Alien4Cloud provides ways to browse the uploaded components, with a search engine allowing filters. Users with role COMPONENT_MANAGER can browse and search for components. How to make a simple search On the left of the components list page, there is a search pannel (see figure above: A ). For a simple search, just type the searched text in the seach field and press the magnifier next to it (or press the Enter keybord instead). The result of your research will be displayed on the center pannel (see figure above: B ). How to make a filtered search You might wish to filter your search or results, for there are too many components corresponding to the simple search. Still on the left search pannel, you can select one or more filters (facets). You can also remove them if they do not fit you. Note that when more than one filter are selected, Alien4Cloud applies an AND policy. Component overview After the search, you can have an overview of the component. Just move the mouse on one component and you will have the right pannel display its summary:(see figure above: C ). If it is the one you are looking for, or if you want further informations about it, you can now select it and see its details. "},{"title":"concat","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/concat_definition.html","date":null,"categories":[],"body":"The concat function is used to concatenate two or more string values within a TOSCA service template. Use this function for attributes ## Keynames Keyname Type Required Description string_value_expressions_* list of string or string value expressions yes A list of one or more strings (or expressions that result in a string value) which can be concatenated together into a single string. Grammar concat : [ <string_value_expressions_*> ] Example The following example shows how to define an attribute using concat function: node_types : fastconnect.nodes.FunctionSample : properties : myName : type : string port : type : string attributes : url : { concat : [ \"http://\" , get_attribute : [ SELF , public_ip_address ], \":\" , get_property : [ SELF , port ]] } interfaces : [ ... ] "},{"title":"concat","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/concat_definition.html","date":null,"categories":[],"body":"The concat function is used to concatenate two or more string values within a TOSCA service template. Use this function for attributes ## Keynames Keyname Type Required Description string_value_expressions_* list of string or string value expressions yes A list of one or more strings (or expressions that result in a string value) which can be concatenated together into a single string. Grammar concat : [ <string_value_expressions_*> ] Example The following example shows how to define an attribute using concat function: node_types : fastconnect.nodes.FunctionSample : properties : myName : type : string port : type : string attributes : url : { concat : [ \"http://\" , get_attribute : [ SELF , public_ip_address ], \":\" , get_property : [ SELF , port ]] } interfaces : [ ... ] "},{"title":"Concepts","baseurl":"","url":"/documentation/1.1.0/concepts/concepts.html","date":null,"categories":[],"body":"Let us introduce you to concepts in Alien 4 Cloud. Alien 4 Cloud is an application that allows people in the enterprise to collaborate in order to provide self-service deployment of complex applications taking in account the different experts through a rôle based portal. Alien 4 Cloud want to provide self-service no only for users but also for development teams that want to build and deploy complex applications and leverage cloud resources to deploy their environments in minutes. In order to provide enterprise self-service portal, alien 4 cloud leverages the following concept: Cloud : Deployment target (cloud or set of physical machines) Components : Software components to deploy Topologies (or blueprints): Description of multiple software components assembled together (to build an application). Applications : Actual applications to deploy with environments and versions each of them being associated with a topology. TOSCA : An emerging standard to describe service components and their relationships On top of these notions Alien 4 Cloud provide a comprehensive set of roles that can be mapped in flexible manners to the people and structure of an enterprise IT department. "},{"title":"Concepts","baseurl":"","url":"/documentation/1.0.0/concepts/concepts.html","date":null,"categories":[],"body":"Let us introduce you to concepts in Alien 4 Cloud. Alien 4 Cloud is an application that allows people in the enterprise to collaborate in order to provide self-service deployment of complex applications taking in account the different experts through a rôle based portal. Alien 4 Cloud want to provide self-service no only for users but also for development teams that want to build and deploy complex applications and leverage cloud resources to deploy their environments in minutes. In order to provide enterprise self-service portal, alien 4 cloud leverages the following concept: Cloud : Deployment target (cloud or set of physical machines) Components : Software components to deploy Topologies (or blueprints): Description of multiple software components assembled together (to build an application). Applications : Actual applications to deploy with environments and versions each of them being associated with a topology. TOSCA : An emerging standard to describe service components and their relationships On top of these notions Alien 4 Cloud provide a comprehensive set of roles that can be mapped in flexible manners to the people and structure of an enterprise IT department. "},{"title":"Constraint clause","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/constraints.html","date":null,"categories":[],"body":"A constraint clause defines an operation along with one or more compatible values that can be used to define a constraint on a property’s or parameter’s allowed values. Available constraints The following is the list of recognized operators (keynames) when defining constraint clauses: Operator Type Value type Description equal scalar all Constrains a property or parameter to a value equal to (‘=’) the value declared. greater_than scalar comparable Constrains a property or parameter to a value greater than (‘>’) the value declared. greater_or_equal scalar comparable Constrains a property or parameter to a value greater than or equal to (‘>=’) the value declared. less_than scalar comparable Constrains a property or parameter to a value less than (‘<’) the value declared. less_or_equal scalar comparable Constrains a property or parameter to a value less than or equal to (‘<=’) the value declared. in_range dual scalar comparable Constrains a property or parameter to a value in range of (inclusive) the two values declared. valid_values list all Constrains a property or parameter to a value that is in the list of declared values. length scalar string Constrains the property or parameter to a value of a given length. min_length scalar   string Constrains the property or parameter to a value to a minimum length. max_length scalar string Constrains the property or parameter to a value to a maximum length. pattern regex string Constrains the property or parameter to a value that is allowed by the provided regular expression. The value type comparable refers to integer, float , timestamp and version types, while all refers to any type allowed in the TOSCA simple profile in YAML. Regular expression language in Alien 4 Cloud (not specified in TOSCA currently) is Java regex. Grammar # Scalar grammar <operator> : <scalar_value> # Dual scalar grammar <operator> : [ <scalar_value_1> , <scalar_value_2> ] # List grammar <operator> : [ <value_1> , <value_2> , ... , <value_n> ] # Regular expression (regex) grammar pattern : <regular_expression_value> Example The following example shows how to define a node type with constraints on properties: node_types : fastconnect.nodes.ConstraintSample : properties : property_1 : type : string constraints : - length : 6 property_2 : type : string constraints : - min_length : 4 - max_length : 8 property_3 : type : integer constraints : - in_range : [ 2 , 10 ] property_4 : type : integer constraints : - valid_values : [ 2 , 4 , 6 , 8 , 16 , 24 , 32 ] "},{"title":"Constraint clause","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/constraints.html","date":null,"categories":[],"body":"A constraint clause defines an operation along with one or more compatible values that can be used to define a constraint on a property’s or parameter’s allowed values. Available constraints The following is the list of recognized operators (keynames) when defining constraint clauses: Operator Type Value type Description equal scalar all Constrains a property or parameter to a value equal to (‘=’) the value declared. greater_than scalar comparable Constrains a property or parameter to a value greater than (‘>’) the value declared. greater_or_equal scalar comparable Constrains a property or parameter to a value greater than or equal to (‘>=’) the value declared. less_than scalar comparable Constrains a property or parameter to a value less than (‘<’) the value declared. less_or_equal scalar comparable Constrains a property or parameter to a value less than or equal to (‘<=’) the value declared. in_range dual scalar comparable Constrains a property or parameter to a value in range of (inclusive) the two values declared. valid_values list all Constrains a property or parameter to a value that is in the list of declared values. length scalar string Constrains the property or parameter to a value of a given length. min_length scalar   string Constrains the property or parameter to a value to a minimum length. max_length scalar string Constrains the property or parameter to a value to a maximum length. pattern regex string Constrains the property or parameter to a value that is allowed by the provided regular expression. The value type comparable refers to integer, float , timestamp and version types, while all refers to any type allowed in the TOSCA simple profile in YAML. Regular expression language in Alien 4 Cloud (not specified in TOSCA currently) is Java regex. Grammar # Scalar grammar <operator> : <scalar_value> # Dual scalar grammar <operator> : [ <scalar_value_1> , <scalar_value_2> ] # List grammar <operator> : [ <value_1> , <value_2> , ... , <value_n> ] # Regular expression (regex) grammar pattern : <regular_expression_value> Example The following example shows how to define a node type with constraints on properties: node_types : fastconnect.nodes.ConstraintSample : properties : property_1 : type : string constraints : - length : 6 property_2 : type : string constraints : - min_length : 4 - max_length : 8 property_3 : type : integer constraints : - in_range : [ 2 , 10 ] property_4 : type : integer constraints : - valid_values : [ 2 , 4 , 6 , 8 , 16 , 24 , 32 ] "},{"title":"Operations on Applications","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-controller.html","date":null,"categories":[],"body":"Create a new application in the system. POST /rest/applications Description If successfull returns a rest response with the id of the created application in data. If not successful a rest response with an error content is returned. Role required [ APPLICATIONS_MANAGER ]. By default the application creator will have application roles [APPLICATION_MANAGER, DEPLOYMENT_MANAGER] Parameters Type Name Description Required Schema Default BodyParameter request request true CreateApplicationRequest   Responses HTTP Code Description Schema 201 Created RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for applications POST /rest/applications/search Description Returns a search result with that contains applications matching the request. A application is returned only if the connected user has at least one application role in [ APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true SearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get an application based from its id. GET /rest/applications/{applicationId} Description Returns the application details. Application role required [ APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Application» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Updates by merging the given request into the given application . PUT /rest/applications/{applicationId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter applicationUpdateRequest applicationUpdateRequest true UpdateApplicationRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an application from its id. DELETE /rest/applications/{applicationId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Updates the image for the application. POST /rest/applications/{applicationId}/image Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   FormDataParameter file image true file   Responses HTTP Code Description Schema 200 OK RestResponse«string» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes multipart/form-data Produces application/json "},{"title":"Manage opertions on deployed application.","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-deployment-controller.html","date":null,"categories":[],"body":"Deploys the application on the configured Cloud. POST /rest/applications/deployment Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default BodyParameter deployApplicationRequest deployApplicationRequest true DeployApplicationRequest   Responses HTTP Code Description Schema 200 OK RestResponse«object» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the deployment status for the environements that the current user is allowed to see for a given application. POST /rest/applications/statuses Description Returns the current status of an application list from the PaaS it is deployed on for all environments. Parameters Type Name Description Required Schema Default BodyParameter applicationIds applicationIds true string array   Responses HTTP Code Description Schema 200 OK RestResponse«Map«string,Map«string,EnvironmentStatusDTO»»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get active deployment for the given application on the given cloud. GET /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/active-deployment Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Deployment» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Un-Deploys the application on the configured PaaS. DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment Description The logged-in user must have the [ APPLICATION_MANAGER ] role for this application. Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get detailed informations for every instances of every node of the application on the PaaS. GET /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment/informations Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ APPLICATION_USER DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK DeferredResult«RestResponse«Map«string,Map«string,InstanceInformation»»»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json switchMaintenanceModeOff DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment/maintenance Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json switchMaintenanceModeOn POST /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment/maintenance Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json switchInstanceMaintenanceModeOff DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment/{nodeTemplateId}/{instanceId}/maintenance Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter nodeTemplateId nodeTemplateId true string   PathParameter instanceId instanceId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json switchInstanceMaintenanceModeOn POST /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/deployment/{nodeTemplateId}/{instanceId}/maintenance Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter nodeTemplateId nodeTemplateId true string   PathParameter instanceId instanceId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Scale the application on a particular node. POST /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/scale/{nodeTemplateId} Description Returns the detailed informations of the application on the PaaS it is deployed. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter nodeTemplateId nodeTemplateId true string   QueryParameter instances instances true integer (int32)   Responses HTTP Code Description Schema 200 OK DeferredResult«RestResponse«Void»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Launch a given workflow. POST /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/workflows/{workflowName} Parameters Type Name Description Required Schema Default PathParameter applicationId Application id. true string   PathParameter applicationEnvironmentId Deployment id. true string   PathParameter workflowName Workflow name. true string   Responses HTTP Code Description Schema 200 OK DeferredResult«RestResponse«Void»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Manages application's environments","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-environment-controller.html","date":null,"categories":[],"body":"Create a new application environment POST /rest/applications/{applicationId}/environments Description If successfull returns a rest response with the id of the created application environment in data. If not successful a rest response with an error content is returned. Role required [ APPLICATIONS_MANAGER ]By default the application environment creator will have application roles [ APPLICATION_MANAGER, DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter request request true ApplicationEnvironmentRequest   Responses HTTP Code Description Schema 201 Created RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for application environments POST /rest/applications/{applicationId}/environments/search Description Returns a search result with that contains application environments DTO matching the request. A application environment is returned only if the connected user has at least one application role in [ APPLICATION_USER DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter searchRequest searchRequest true SearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult«ApplicationEnvironmentDTO»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get an application environment from its id GET /rest/applications/{applicationId}/environments/{applicationEnvironmentId} Description Returns the application environment. Application role required [ APPLICATION_USER DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«ApplicationEnvironment» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Updates by merging the given request into the given application environment PUT /rest/applications/{applicationId}/environments/{applicationEnvironmentId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   BodyParameter request request true UpdateApplicationEnvironmentRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an application environment from its id DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get an application environment from its id GET /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/status Description Returns the application environment. Application role required [ APPLICATION_USER DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the id of the topology linked to the environment GET /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/topology Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationEnvironmentId applicationEnvironmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Manages application's environments","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-environment-roles-controller.html","date":null,"categories":[],"body":"Add a role to a group on a specific application environment PUT /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/roles/groups/{groupId}/{role} Description Any user with application role APPLICATION_MANAGER can assign any role to a group of users. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role of a group on a specific application environment DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/roles/groups/{groupId}/{role} Description Any user with application role APPLICATION_MANAGER can un-assign any role to a group. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a user on a specific application environment PUT /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/roles/users/{username}/{role} Description Any user with application role APPLICATION_MANAGER can assign any role to another user. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role to a user on a specific application environment DELETE /rest/applications/{applicationId}/environments/{applicationEnvironmentId}/roles/users/{username}/{role} Description Any user with application role APPLICATION_MANAGER can unassign any role to another user. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationEnvironmentId applicationEnvironmentId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Operations on Application's meta-properties","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-meta-property-controller.html","date":null,"categories":[],"body":"upsertProperty POST /rest/applications/{applicationId}/properties Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter propertyRequest propertyRequest true Request to update or check the value of a property.   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Operations on applications roles","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-roles-controller.html","date":null,"categories":[],"body":"Add a role to a group on a specific application PUT /rest/applications/{applicationId}/roles/groups/{groupId}/{role} Description Any user with application role APPLICATION_MANAGER can assign any role to a group of users. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role of a group on a specific application DELETE /rest/applications/{applicationId}/roles/groups/{groupId}/{role} Description Any user with application role APPLICATION_MANAGER can un-assign any role to a group. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a user on a specific application PUT /rest/applications/{applicationId}/roles/users/{username}/{role} Description Any user with application role APPLICATION_MANAGER can assign any role to another user. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role to a user on a specific application DELETE /rest/applications/{applicationId}/roles/users/{username}/{role} Description Any user with application role APPLICATION_MANAGER can unassign any role to another user. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Application Tags Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-tags-controller.html","date":null,"categories":[],"body":"Update/Create a tag for the application. POST /rest/applications/{applicationId}/tags Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter updateApplicationTagRequest updateApplicationTagRequest true UpdateTagRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete a tag for the application. DELETE /rest/applications/{applicationId}/tags/{tagId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter tagId tagId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Manages application's versions","baseurl":"","url":"/documentation/1.1.0/rest/controller_application-version-controller.html","date":null,"categories":[],"body":"Get the first snapshot application version for an application. GET /rest/applications/{applicationId}/versions Description Return the first snapshot application version for an application. Application role required [ APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   Responses HTTP Code Description Schema 200 OK RestResponse«ApplicationVersion» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Create a new application version. POST /rest/applications/{applicationId}/versions Description If successfull returns a rest response with the id of the created application version in data. If not successful a rest response with an error content is returned. Role required [ APPLICATIONS_MANAGER ]. By default the application version creator will have application roles [APPLICATION_MANAGER] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter request request true ApplicationVersionRequest   Responses HTTP Code Description Schema 201 Created RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search application versions POST /rest/applications/{applicationId}/versions/search Description Returns a search result with that contains application versions matching the request. A application version is returned only if the connected user has at least one application role in [ APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter searchRequest searchRequest true SearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult«ApplicationVersion»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get an application version based from its id. GET /rest/applications/{applicationId}/versions/{applicationVersionId} Description Returns the application version details. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationVersionId applicationVersionId true string   Responses HTTP Code Description Schema 200 OK RestResponse«ApplicationVersion» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Updates by merging the given request into the given application version PUT /rest/applications/{applicationId}/versions/{applicationVersionId} Description Updates by merging the given request into the given application version. The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationVersionId applicationVersionId true string   BodyParameter request request true ApplicationVersionRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an application version from its id DELETE /rest/applications/{applicationId}/versions/{applicationVersionId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   PathParameter applicationVersionId applicationVersionId true string   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Audit Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_audit-controller.html","date":null,"categories":[],"body":"Get audit configuration GET /rest/audit/configuration Description Get the audit configuration object. Audit configuration is only accessible to user with role [ ADMIN ] Responses HTTP Code Description Schema 200 OK RestResponse«AuditConfigurationDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Enable/Disable audit on a list of methods POST /rest/audit/configuration/audited-methods Description Audit configuration update is only accessible to user with role [ ADMIN ] Parameters Type Name Description Required Schema Default BodyParameter methods methods true AuditedMethod array   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Enable/Disable audit POST /rest/audit/configuration/enabled Description Audit configuration update is only accessible to user with role [ ADMIN ] Parameters Type Name Description Required Schema Default QueryParameter enabled enabled true boolean   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Reset the audit configuration POST /rest/audit/configuration/reset Description Reset the audit configuration to its default state. Audit search is only accessible to user with role [ ADMIN ] Responses HTTP Code Description Schema 200 OK RestResponse«AuditConfigurationDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for audit trace POST /rest/audit/search Description Returns a search result with that contains auti traces matching the request. Audit search is only accessible to user with role [ ADMIN ] Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true FilteredSearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Auth Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_auth-controller.html","date":null,"categories":[],"body":"Get the current authentication status and user’s roles. GET /rest/auth/status Description Return the current user’s status and it’s roles. Responses HTTP Code Description Schema 200 OK RestResponse«UserStatus» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Basic Error Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_basic-error-controller.html","date":null,"categories":[],"body":"error GET /error Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / error PUT /error Responses HTTP Code Description Schema 200 OK object 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / error DELETE /error Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / error POST /error Responses HTTP Code Description Schema 200 OK object 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / error PATCH /error Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / "},{"title":"Cloud Service Archive Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_cloud-service-archive-controller.html","date":null,"categories":[],"body":"Upload a csar zip file. POST /rest/csars Parameters Type Name Description Required Schema Default FormDataParameter file csar true file   Responses HTTP Code Description Schema 200 OK RestResponse«CsarUploadResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes multipart/form-data Produces application/json Search for cloud service archives. POST /rest/csars/search Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true SearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get a CSAR given its id. GET /rest/csars/{csarId} Description Returns a CSAR. Parameters Type Name Description Required Schema Default PathParameter csarId csarId true string   Responses HTTP Code Description Schema 200 OK RestResponse«CsarInfoDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete a CSAR given its id. DELETE /rest/csars/{csarId} Parameters Type Name Description Required Schema Default PathParameter csarId csarId true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«Usage»» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get active deployment for the given csar snapshot’s test topology on the given cloud. GET /rest/csars/{csarId}/active-deployment Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter csarId csarId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Deployment» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Add dependency to the csar with given id. POST /rest/csars/{csarId}/dependencies Parameters Type Name Description Required Schema Default PathParameter csarId csarId true string   BodyParameter dependency dependency true CSARDependency   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Component Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_component-controller.html","date":null,"categories":[],"body":"Verify that a component (tosca element) exists in alien’s repository. POST /rest/components/exist Parameters Type Name Description Required Schema Default BodyParameter checkElementExistRequest checkElementExistRequest true ElementFromArchiveRequest   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get details for a component (tosca type). POST /rest/components/getInArchives Parameters Type Name Description Required Schema Default BodyParameter checkElementExistRequest checkElementExistRequest true ElementFromArchiveRequest   Responses HTTP Code Description Schema 200 OK RestResponse«IndexedToscaElement» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Set the given node type as default for the given capability. POST /rest/components/recommendation Parameters Type Name Description Required Schema Default BodyParameter recommendationRequest recommendationRequest true RecommendationRequest   Responses HTTP Code Description Schema 200 OK RestResponse«IndexedNodeType» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get details for an indexed node type.. GET /rest/components/recommendation/{capability} Parameters Type Name Description Required Schema Default PathParameter capability capability true string   Responses HTTP Code Description Schema 200 OK RestResponse«IndexedNodeType» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Search for components (tosca types) in alien. POST /rest/components/search Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true SearchRequest   QueryParameter queryAllVersions queryAllVersions false boolean   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a recommendation for a node type. POST /rest/components/unflag Description If a node type is set as default for a given capability, you can remove this setting by calling this operation with the right request parameters. Parameters Type Name Description Required Schema Default BodyParameter recommendationRequest recommendationRequest true RecommendationRequest   Responses HTTP Code Description Schema 200 OK RestResponse«IndexedNodeType» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update or insert a tag for a component (tosca element). POST /rest/components/{componentId}/tags Parameters Type Name Description Required Schema Default PathParameter componentId componentId true string   BodyParameter updateTagRequest updateTagRequest true UpdateTagRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete a tag for a component (tosca element). DELETE /rest/components/{componentId}/tags/{tagId} Parameters Type Name Description Required Schema Default PathParameter componentId componentId true string   PathParameter tagId tagId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get details for a component (tosca type). GET /rest/components/{id} Parameters Type Name Description Required Schema Default PathParameter id id true string   Responses HTTP Code Description Schema 200 OK RestResponse«IndexedToscaElement» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Csar Git Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_csar-git-controller.html","date":null,"categories":[],"body":"Retrieve information on a registered TOSCA CSAR git repository using the csar url as id. GET /rest/csarsgit Parameters Type Name Description Required Schema Default BodyParameter url Url of the csar git repository to get true string   Responses HTTP Code Description Schema 200 OK RestResponse«CsarGitRepository» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Delete a registered TOSCA CSAR git repository using the csar url as id. DELETE /rest/csarsgit Parameters Type Name Description Required Schema Default BodyParameter url Url of the csar git repository to delete true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / Create a new CSARGit from a Git location in ALIEN. POST /rest/csarsgit Parameters Type Name Description Required Schema Default BodyParameter request request true Request for creation of a new csar git repository.   Responses HTTP Code Description Schema 200 OK RestResponse«string» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Update a CSARGit by url. POST /rest/csarsgit/update/{url} Parameters Type Name Description Required Schema Default BodyParameter request request true Request for creation of a new csar git repository.   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Retrieve information on a registered TOSCA CSAR git repository. GET /rest/csarsgit/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the csar git repository to get true string   Responses HTTP Code Description Schema 200 OK RestResponse«CsarGitRepository» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Update a CSARGit by id. PUT /rest/csarsgit/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the csar git repository to delete true string   BodyParameter request request true Request for creation of a new csar git repository.   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Delete a registered TOSCA CSAR git repository. DELETE /rest/csarsgit/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the csar git repository to delete true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / Specify a CSAR from Git and proceed to its import in Alien. POST /rest/csarsgit/{id} Parameters Type Name Description Required Schema Default PathParameter id id true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«ParsingResult«Csar»»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Deployment Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_deployment-controller.html","date":null,"categories":[],"body":"Get deployments for an orchestrator. GET /rest/deployments Parameters Type Name Description Required Schema Default QueryParameter orchestratorId Id of the orchestrator for which to get deployments. If not provided, get deployments for all orchestrators false string   QueryParameter sourceId Id of the application for which to get deployments. if not provided, get deployments for all applications false string   QueryParameter includeSourceSummary include or not the source (application or csar) summary in the results false boolean   QueryParameter from Query from the given index. false integer (int32)   QueryParameter size Maximum number of results to retrieve. false integer (int32)   Responses HTTP Code Description Schema 200 OK RestResponse«List«DeploymentDTO»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json getEvents GET /rest/deployments/{applicationEnvironmentId}/events Parameters Type Name Description Required Schema Default PathParameter applicationEnvironmentId Id of the environment for which to get events. true string   QueryParameter from Query from the given index. false integer (int32)   QueryParameter size Maximum number of results to retrieve. false integer (int32)   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get deployment status from its id. GET /rest/deployments/{deploymentId}/status Parameters Type Name Description Required Schema Default PathParameter deploymentId Deployment id. true string   Responses HTTP Code Description Schema 200 OK DeferredResult«RestResponse«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Undeploy deployment from its id. GET /rest/deployments/{deploymentId}/undeploy Parameters Type Name Description Required Schema Default PathParameter deploymentId Deployment id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Manage configuration of an application before deploying it.","baseurl":"","url":"/documentation/1.1.0/rest/controller_deployment-topology-controller.html","date":null,"categories":[],"body":"Get the deployment topology of an application given an environment. GET /rest/applications/{appId}/environments/{environmentId}/deployment-topology Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   Responses HTTP Code Description Schema 200 OK RestResponse«DeploymentTopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Updates by merging the given request into the given application’s deployment topology. PUT /rest/applications/{appId}/environments/{environmentId}/deployment-topology Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   BodyParameter updateRequest updateRequest true UpdateDeploymentTopologyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«object» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Set location policies for a deployment. Creates if not yet the {@link DeploymentTopology} object linked to this deployment. POST /rest/applications/{appId}/environments/{environmentId}/deployment-topology/location-policies Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   BodyParameter request request true SetLocationPoliciesRequest   Responses HTTP Code Description Schema 200 OK RestResponse«DeploymentTopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Substitute a specific node by the location resource template in the topology of an application given an environment. POST /rest/applications/{appId}/environments/{environmentId}/deployment-topology/substitutions/{nodeId} Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] and Application environment role required [ DEPLOYMENT_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   PathParameter nodeId nodeId true string   QueryParameter locationResourceTemplateId locationResourceTemplateId true string   Responses HTTP Code Description Schema 200 OK RestResponse«DeploymentTopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Update substitution’s capability property. POST /rest/applications/{appId}/environments/{environmentId}/deployment-topology/substitutions/{nodeId}/capabilities/{capabilityName}/properties Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   PathParameter nodeId nodeId true string   PathParameter capabilityName capabilityName true string   BodyParameter updateRequest updateRequest true UpdatePropertyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«object» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / Update substitution’s property. POST /rest/applications/{appId}/environments/{environmentId}/deployment-topology/substitutions/{nodeId}/properties Parameters Type Name Description Required Schema Default PathParameter appId appId true string   PathParameter environmentId environmentId true string   PathParameter nodeId nodeId true string   BodyParameter updateRequest updateRequest true UpdatePropertyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«DeploymentTopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Endpoint Mvc Adapter","baseurl":"","url":"/documentation/1.1.0/rest/controller_endpoint-mvc-adapter.html","date":null,"categories":[],"body":"invoke GET /rest/admin/autoconfig Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/beans Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/configprops Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/dump Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/info Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/mappings Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke GET /rest/admin/trace Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Environment Mvc Endpoint","baseurl":"","url":"/documentation/1.1.0/rest/controller_environment-mvc-endpoint.html","date":null,"categories":[],"body":"invoke GET /rest/admin/env Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / value GET /rest/admin/env/{name} Parameters Type Name Description Required Schema Default PathParameter name name true string   Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Group Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_group-controller.html","date":null,"categories":[],"body":"Create a new group in ALIEN. POST /rest/groups Parameters Type Name Description Required Schema Default BodyParameter request request true CreateGroupRequest   Responses HTTP Code Description Schema 200 OK RestResponse«string» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get multiple groups from their ids. POST /rest/groups/getGroups Description Returns a rest response that contains the list of requested groups. Parameters Type Name Description Required Schema Default BodyParameter ids ids true string array   Responses HTTP Code Description Schema 200 OK RestResponse«List«Group»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for user’s registered in alien. POST /rest/groups/search Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true FilteredSearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get a group based on it’s id. GET /rest/groups/{groupId} Description Returns a rest response that contains the group’s details. Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Group» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update a group by merging the groupUpdateRequest into the existing group PUT /rest/groups/{groupId} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   BodyParameter groupUpdateRequest groupUpdateRequest true UpdateGroupRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an existing group from the repository. DELETE /rest/groups/{groupId} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a group. PUT /rest/groups/{groupId}/roles/{role} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role from a group. DELETE /rest/groups/{groupId}/roles/{role} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a user to a group. PUT /rest/groups/{groupId}/users/{username} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   PathParameter username username true string   Responses HTTP Code Description Schema 200 OK RestResponse«User» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a user from a group. DELETE /rest/groups/{groupId}/users/{username} Parameters Type Name Description Required Schema Default PathParameter groupId groupId true string   PathParameter username username true string   Responses HTTP Code Description Schema 200 OK RestResponse«User» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Health Mvc Endpoint","baseurl":"","url":"/documentation/1.1.0/rest/controller_health-mvc-endpoint.html","date":null,"categories":[],"body":"invoke GET /rest/admin/health Parameters Type Name Description Required Schema Default BodyParameter principal principal false Principal   Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke PUT /rest/admin/health Parameters Type Name Description Required Schema Default BodyParameter principal principal false Principal   Responses HTTP Code Description Schema 200 OK object 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke DELETE /rest/admin/health Parameters Type Name Description Required Schema Default BodyParameter principal principal false Principal   Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / invoke POST /rest/admin/health Parameters Type Name Description Required Schema Default BodyParameter principal principal false Principal   Responses HTTP Code Description Schema 200 OK object 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / invoke PATCH /rest/admin/health Parameters Type Name Description Required Schema Default BodyParameter principal principal false Principal   Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces / "},{"title":"Get matching options for a given topology.","baseurl":"","url":"/documentation/1.1.0/rest/controller_location-matching.html","date":null,"categories":[],"body":"Retrieve the list of locations on which the current user can deploy the topology. GET /rest/topologies/{topologyId}/locations Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«LocationMatch»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Update values for meta-properties associated with locations.","baseurl":"","url":"/documentation/1.1.0/rest/controller_location-meta-properties.html","date":null,"categories":[],"body":"upsertMetaProperty POST /rest/orchestrators/{orchestratorId}/locations/{locationId}/properties Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which the location is defined. false string   PathParameter locationId Id of the location to get true string   BodyParameter propertyRequest Id of the location to get true Request to update or check the value of a property.   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Location Roles Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_location-roles-controller.html","date":null,"categories":[],"body":"Add a role to a group on a specific location PUT /rest/orchestrators/{orchestratorId}/locations/{locationId}/roles/groups/{groupId}/{role} Description Only user with ADMIN role can assign any role to a group of users. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter locationId locationId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role of a group on a specific location DELETE /rest/orchestrators/{orchestratorId}/locations/{locationId}/roles/groups/{groupId}/{role} Description Only user with ADMIN role can unassign any role to a group. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter locationId locationId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a user on a specific location PUT /rest/orchestrators/{orchestratorId}/locations/{locationId}/roles/users/{username}/{role} Description Only user with ADMIN role can assign any role to another user. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter locationId locationId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role to a user on a specific location DELETE /rest/orchestrators/{orchestratorId}/locations/{locationId}/roles/users/{username}/{role} Description Only user with ADMIN role can unassign any role to another user. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter locationId locationId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Metrics Mvc Endpoint","baseurl":"","url":"/documentation/1.1.0/rest/controller_metrics-mvc-endpoint.html","date":null,"categories":[],"body":"invoke GET /rest/admin/metrics Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / value GET /rest/admin/metrics/{name} Parameters Type Name Description Required Schema Default PathParameter name name true string   Responses HTTP Code Description Schema 200 OK object 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Get and update orchestrator configuration.","baseurl":"","url":"/documentation/1.1.0/rest/controller_orchestrator-configuration.html","date":null,"categories":[],"body":"Get an orchestrator configuration. GET /rest/orchestrators/{id}/configuration Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator to get true string   Responses HTTP Code Description Schema 200 OK RestResponse«OrchestratorConfiguration» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update the configuration for an orchestrator. PUT /rest/orchestrators/{id}/configuration Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator for which to update the configuration. true string   BodyParameter configuration The configuration object for the orchestrator - Type depends of the selected orchestrator. true object   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Manages locations for a given orchestrator.","baseurl":"","url":"/documentation/1.1.0/rest/controller_orchestrator-location-resources.html","date":null,"categories":[],"body":"Add resource template to a location. POST /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to add resource template. true string   PathParameter locationId Id of the location of the orchestrator to add resource template. true string   BodyParameter resourceTemplateRequest resourceTemplateRequest true Request for creation of a new location’s resource.   Responses HTTP Code Description Schema 200 OK RestResponse«LocationResourceTemplate» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Auto configure the resources, if the location configurator plugin provides a way for. GET /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources/auto-configure Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to Auto configure the resources. true string   PathParameter locationId Id of the location of the orchestrator to Auto configure the resources. true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«LocationResourceTemplate»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update location’s resource. PUT /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources/{id} Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to update resource template. true string   PathParameter locationId Id of the location of the orchestrator to update resource template. true string   PathParameter id Id of the location’s resource. true string   BodyParameter mergeRequest mergeRequest true Request to update a location resource.   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete location’s resource. DELETE /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources/{id} Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to delete resource template. true string   PathParameter locationId Id of the location of the orchestrator to delete resource template. true string   PathParameter id Id of the location’s resource. true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Update location’s resource’s capability template capability property. POST /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources/{id}/template/capabilities/{capabilityName}/properties Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to update resource template capability property. true string   PathParameter locationId Id of the location of the orchestrator to update resource template capability property. true string   PathParameter id Id of the location’s resource. true string   PathParameter capabilityName Id of the location’s resource template capability. true string   BodyParameter updateRequest updateRequest true Request to update a location resource template property.   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update location’s resource’s template property. POST /rest/orchestrators/{orchestratorId}/locations/{locationId}/resources/{id}/template/properties Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to update resource template property. true string   PathParameter locationId Id of the location of the orchestrator to update resource template property. true string   PathParameter id Id of the location’s resource. true string   BodyParameter updateRequest updateRequest true Request to update a location resource template property.   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Orchestrator Roles Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_orchestrator-roles-controller.html","date":null,"categories":[],"body":"Add a role to a group on all locations of a specific orchestrator PUT /rest/orchestrators/{orchestratorId}/roles/groups/{groupId}/{role} Description Only user with ADMIN role can assign any role to a group of users. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role of a group on all locations of a specific orchestrator DELETE /rest/orchestrators/{orchestratorId}/roles/groups/{groupId}/{role} Description Only user with ADMIN role can unassign any role to a group. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter groupId groupId true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a user on all locations of a specific orchestrator PUT /rest/orchestrators/{orchestratorId}/roles/users/{username}/{role} Description Only user with ADMIN role can assign any role to another user. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role to a user on all locations of a specific orchestrator DELETE /rest/orchestrators/{orchestratorId}/roles/users/{username}/{role} Description Only user with ADMIN role can unassign any role to another user. Parameters Type Name Description Required Schema Default PathParameter orchestratorId orchestratorId true string   PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Manages locations for a given orchestrator.","baseurl":"","url":"/documentation/1.1.0/rest/controller_orchestrators-locations.html","date":null,"categories":[],"body":"Get all locations for a given orchestrator. GET /rest/orchestrators/{orchestratorId}/locations Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which to get all locations. false string   Responses HTTP Code Description Schema 200 OK RestResponse«List«LocationDTO»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Create a new location. POST /rest/orchestrators/{orchestratorId}/locations Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which the location is defined. false string   BodyParameter locationRequest Request for location creation true Request for creation of a new location.   Responses HTTP Code Description Schema 201 Created RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get a location from it’s id. GET /rest/orchestrators/{orchestratorId}/locations/{id} Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which the location is defined. false string   PathParameter id Id of the location to get true string   Responses HTTP Code Description Schema 200 OK RestResponse«LocationDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update the name of an existing location. PUT /rest/orchestrators/{orchestratorId}/locations/{id} Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which the location is defined. false string   PathParameter id Id of the location to update true string   BodyParameter updateRequest Location update request, representing the fields to updates and their new values. true UpdateLocationRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an existing location. DELETE /rest/orchestrators/{orchestratorId}/locations/{id} Parameters Type Name Description Required Schema Default PathParameter orchestratorId Id of the orchestrator for which the location is defined. false string   PathParameter id Id of the location to delete. true string   Responses HTTP Code Description Schema 200 OK RestResponse«boolean» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Manages orchestrators.","baseurl":"","url":"/documentation/1.1.0/rest/controller_orchestrators.html","date":null,"categories":[],"body":"Search for orchestrators. GET /rest/orchestrators Parameters Type Name Description Required Schema Default QueryParameter query Query text. false string   QueryParameter connectedOnly If true only connected orchestrators will be retrieved. false boolean   QueryParameter from Query from the given index. false integer (int32)   QueryParameter size Maximum number of results to retrieve. false integer (int32)   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult«Orchestrator.»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Create a new orchestrators. POST /rest/orchestrators Parameters Type Name Description Required Schema Default BodyParameter orchestratorRequest Request for orchestrators creation true Request for creation of a new orchestrators.   Responses HTTP Code Description Schema 201 Created RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get an orchestrators from it’s id. GET /rest/orchestrators/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator to get true string   Responses HTTP Code Description Schema 200 OK RestResponse«Orchestrator.» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update the name of an existing orchestrators. PUT /rest/orchestrators/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrators to update. true string   BodyParameter request Orchestrator update request, representing the fields to updates and their new values. true Orchestrator update request.   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an existing orchestrators. DELETE /rest/orchestrators/{id} Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrators to delete. true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get information on the artifacts that an orchestrator can support. GET /rest/orchestrators/{id}/artifacts-support Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator for which to get artifact support informations true string   Responses HTTP Code Description Schema 200 OK RestResponse«Array«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Disable an orchestrator. Destroys the instance of the orchestrator connector. DELETE /rest/orchestrators/{id}/instance Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator to enable true string   QueryParameter force This parameter is useful only when trying to disable the orchestrator, if deployments are performed using this orchestrator disable operation will fail unnless the force flag is true false boolean   QueryParameter clearDeployments In case an orchestrator with deployment is forced to be disabled, the user may decide to mark all deployments managed by this orchestrator as ended. false boolean   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Enable an orchestrator. Creates the instance of orchestrator if not already created. POST /rest/orchestrators/{id}/instance Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator to enable true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get information on the locations that an orchestrator can support. GET /rest/orchestrators/{id}/locationsupport Parameters Type Name Description Required Schema Default PathParameter id Id of the orchestrator for which to get location support informations true string   Responses HTTP Code Description Schema 200 OK RestResponse«LocationSupport» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Allow to query for enabled plugin components.","baseurl":"","url":"/documentation/1.1.0/rest/controller_plugin-components.html","date":null,"categories":[],"body":"Search for plugin components. GET /rest/plugincomponents Parameters Type Name Description Required Schema Default QueryParameter type Type of plugin component to query for. true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«Result for a request for specific plugin components.»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Manages plugins.","baseurl":"","url":"/documentation/1.1.0/rest/controller_plugins.html","date":null,"categories":[],"body":"Search for plugins registered in ALIEN. GET /rest/plugins Parameters Type Name Description Required Schema Default QueryParameter query Query text. false string   QueryParameter from Query from the given index. false integer (int32)   QueryParameter size Maximum number of results to retrieve. false integer (int32)   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult«Plugin»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Upload a plugin archive. POST /rest/plugins Description Content of the zip file must be compliant with the expected alien 4 cloud plugin structure. Parameters Type Name Description Required Schema Default FormDataParameter file Zip file that contains the plugin. true file   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes multipart/form-data Produces application/json Remove a plugin. DELETE /rest/plugins/{pluginId} Description Remove a plugin (and unloads it if enabled). Note that if the plugin is used (deployment plugin for example) it won’t be disabled but will be marked as deprecated. In such situation an error code 350 is returned as part of the error and a list of plugin usages will be returned as part of the returned data. Role required [ ADMIN ] Parameters Type Name Description Required Schema Default PathParameter pluginId pluginId true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«PluginUsage»» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Get a plugin configuration object. GET /rest/plugins/{pluginId}/config Description Retrieve a plugin configuration object. Role required [ ADMIN ] Parameters Type Name Description Required Schema Default PathParameter pluginId pluginId true string   Responses HTTP Code Description Schema 200 OK RestResponse«object» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Save a configuration object for a plugin. POST /rest/plugins/{pluginId}/config Description Save a configuration object for a plugin. Returns the newly saved configuration. Role required [ ADMIN ] Parameters Type Name Description Required Schema Default PathParameter pluginId pluginId true string   BodyParameter configObjectRequest configObjectRequest true object   Responses HTTP Code Description Schema 200 OK RestResponse«object» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Disable a plugin. GET /rest/plugins/{pluginId}/disable Description Disable a plugin (and unloads it if enabled). Note that if the plugin is used (deployment plugin for example) it won’t be disabled but will be marked as deprecated. In such situation an error code 350 is returned as part of the error and a list of plugin usages will be returned as part of the returned data. Role required [ ADMIN ] Parameters Type Name Description Required Schema Default PathParameter pluginId pluginId true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«PluginUsage»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Enable a plugin. GET /rest/plugins/{pluginId}/enable Description Enable and load a plugin. Role required [ ADMIN ] Parameters Type Name Description Required Schema Default PathParameter pluginId pluginId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Quick Search Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_quick-search-controller.html","date":null,"categories":[],"body":"Search for applications or tosca elements in ALIEN’s repository. POST /rest/quicksearch Parameters Type Name Description Required Schema Default BodyParameter requestObject requestObject true BasicSearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«GetMultipleDataResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Runtime Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_runtime-controller.html","date":null,"categories":[],"body":"Get runtime (deployed) topology of an application on a specific cloud. GET /rest/runtime/{applicationId}/environment/{applicationEnvironmentId}/topology Parameters Type Name Description Required Schema Default PathParameter applicationId Id of the application for which to get deployed topology. true string   PathParameter applicationEnvironmentId Id of the environment for which to get deployed topology. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Trigger a custom command on a specific node template of a topology . POST /rest/runtime/{applicationId}/operations Description Returns a response with no errors and the command response as data in success case. Application role required [ APPLICATION_MANAGER ] Parameters Type Name Description Required Schema Default PathParameter applicationId applicationId true string   BodyParameter operationRequest operationRequest true OperationExecRequest   Responses HTTP Code Description Schema 200 OK DeferredResult«RestResponse«object»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Shutdown Mvc Endpoint","baseurl":"","url":"/documentation/1.1.0/rest/controller_shutdown-mvc-endpoint.html","date":null,"categories":[],"body":"invoke POST /rest/admin/shutdown Responses HTTP Code Description Schema 200 OK object 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces / "},{"title":"Tag Configuration Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_tag-configuration-controller.html","date":null,"categories":[],"body":"Save tag configuration. POST /rest/metaproperties Parameters Type Name Description Required Schema Default BodyParameter configuration configuration true MetaPropConfiguration   Responses HTTP Code Description Schema 200 OK RestResponse«TagConfigurationSaveResponse» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for tag configurations registered in ALIEN. POST /rest/metaproperties/search Parameters Type Name Description Required Schema Default BodyParameter request request true SearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get tag configuration. GET /rest/metaproperties/{tagConfigurationId} Parameters Type Name Description Required Schema Default PathParameter tagConfigurationId tagConfigurationId true string   Responses HTTP Code Description Schema 200 OK RestResponse«MetaPropConfiguration» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove tag configuration. DELETE /rest/metaproperties/{tagConfigurationId} Parameters Type Name Description Required Schema Default PathParameter tagConfigurationId tagConfigurationId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Topology Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_topology-controller.html","date":null,"categories":[],"body":"Retrieve a topology from it’s id. GET /rest/topologies/{topologyId} Description Returns a topology with it’s details. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Un-associate an artifact from the input artifact. DELETE /rest/topologies/{topologyId}/inputArtifacts/{inputArtifactId} Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter inputArtifactId inputArtifactId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Rename input artifact id. POST /rest/topologies/{topologyId}/inputArtifacts/{inputArtifactId} Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter inputArtifactId inputArtifactId true string   QueryParameter newId newId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Updates the deployment artifact of the node template. POST /rest/topologies/{topologyId}/inputArtifacts/{inputArtifactId}/upload Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter inputArtifactId inputArtifactId true string   FormDataParameter file artifactFile true file   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes multipart/form-data Produces application/json Check if a topology is valid or not. GET /rest/topologies/{topologyId}/isvalid Description Returns true if valid, false if not. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   QueryParameter environmentId environmentId false string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyValidationResult» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json updateGroupName PUT /rest/topologies/{topologyId}/nodeGroups/{groupName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter groupName groupName true string   QueryParameter newName newGroupName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json deleteNodeGroup DELETE /rest/topologies/{topologyId}/nodeGroups/{groupName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter groupName groupName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Remove a node from a node group. DELETE /rest/topologies/{topologyId}/nodeGroups/{groupName}/members/{nodeName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter groupName groupName true string   PathParameter nodeName nodeName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a node to a node group. If the group doesn’t exists, it’s created. POST /rest/topologies/{topologyId}/nodeGroups/{groupName}/members/{nodeName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter groupName groupName true string   PathParameter nodeName nodeName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Add a new node template in a topology. POST /rest/topologies/{topologyId}/nodetemplates Description Returns the details of the node template (computed from it’s type). Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   BodyParameter nodeTemplateRequest nodeTemplateRequest true NodeTemplateRequest   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete a node tempalte from a topology DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName} Description If successful returns a result containing the list of impacted nodes (that will loose relationships). Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Updates the deployment artifact of the node template. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/artifacts/{artifactId} Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter artifactId artifactId true string   FormDataParameter file artifactFile true file   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes multipart/form-data Produces application/json Reset the deployment artifact of the node template. PUT /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/artifacts/{artifactId}/reset Description The logged-in user must have the application manager role for this application. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter artifactId artifactId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Un-associate an artifact from the input artifact. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/artifacts/{artifactId}/{inputArtifactId} Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter artifactId artifactId true string   PathParameter inputArtifactId inputArtifactId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Associate an artifact to an input artifact (create it if it doesn’t exist). POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/artifacts/{artifactId}/{inputArtifactId} Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter artifactId artifactId true string   PathParameter inputArtifactId inputArtifactId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the list of input artifacts candidates for this node’s artifact. GET /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/artifacts/{artifactName}/inputcandidates Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter artifactName artifactName true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove an attribute from the output attributes list. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/attributes/{attributeName}/output Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter attributeName attributeName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Activate an attribute as an output attribute. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/attributes/{attributeName}/output Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter attributeName attributeName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a capability property from the output property list. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/property/{propertyId}/isOutput Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter capabilityId capabilityId true string   PathParameter propertyId propertyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Activate a capability property as an output property. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/property/{propertyId}/isOutput Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter propertyId propertyId true string   PathParameter capabilityId capabilityId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update a relationship property value. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/updateProperty Description Returns a topology with it’s details. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter capabilityId capabilityId true string   BodyParameter updatePropertyRequest updatePropertyRequest true UpdateIndexedTypePropertyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update properties values. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/properties Description Returns a topology with it’s details. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   BodyParameter updatePropertyRequest updatePropertyRequest true UpdatePropertyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a property from the output property list. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/property/{propertyName}/isOutput Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter propertyName propertyName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Activate a property as an output property. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/property/{propertyName}/isOutput Description Returns a response with no errors and no data in success case. Application role required [ APPLICATION_MANAGER ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter propertyName propertyName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete a relationship from a node template. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationships/{relationshipName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter relationshipName relationshipName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a relationship to a node template. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationships/{relationshipName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter relationshipName relationshipName true string   BodyParameter relationshipTemplateRequest relationshipTemplateRequest true AddRelationshipTemplateRequest   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Change the name of a node template in a topology. PUT /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationships/{relationshipName}/updateName Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter relationshipName relationshipName true string   QueryParameter newName newRelationshipName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update a relationship property value. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationships/{relationshipName}/updateProperty Description Returns a topology with it’s details. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter relationshipName relationshipName true string   BodyParameter updatePropertyRequest updatePropertyRequest true UpdateIndexedTypePropertyRequest   Responses HTTP Code Description Schema 200 OK RestResponse«ConstraintInformation» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get possible replacement indexedNodeTypes for a node template. GET /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/replace Description Returns An array of indexedNodeType which can replace the node template. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   Responses HTTP Code Description Schema 200 OK RestResponse«Array«IndexedNodeType»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Replace a node template possible with another one. PUT /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/replace Description Returns the details of the new node template (computed from it’s type). Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   BodyParameter nodeTemplateRequest nodeTemplateRequest true NodeTemplateRequest   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Change the name of a node template in a topology. PUT /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/updateName/{newNodeTemplateName} Description Returns a response with no errors in case of success. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter nodeTemplateName nodeTemplateName true string   PathParameter newNodeTemplateName newNodeTemplateName true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the version of application or topology related to this topology. GET /rest/topologies/{topologyId}/version Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«AbstractTopologyVersion» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json getYaml GET /rest/topologies/{topologyId}/yaml Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«string» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Topology Inputs Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_topology-inputs-controller.html","date":null,"categories":[],"body":"Change the name of an input parameter. PUT /rest/topologies/{topologyId}/inputs/{inputId} Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter inputId The name of the old input. true string   QueryParameter newInputId The name of the new input. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove an input from a topology. DELETE /rest/topologies/{topologyId}/inputs/{inputId} Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter inputId The name of the input. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Activate a property as an input property. POST /rest/topologies/{topologyId}/inputs/{inputId} Description Activate a property as an input property. Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter inputId The name of new input. true string   BodyParameter newPropertyDefinition The property definition of the new input. true PropertyDefinition   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Associate the property of a capability template to an input of the topology. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter capabilityId The capability template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Associate the property of a capability template to an input of the topology. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   QueryParameter inputId The name of the input. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter capabilityId The capability template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the possible inputs candidates to be associated with this capability property. GET /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/capability/{capabilityId}/property/{propertyId}/inputcandidats Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter capabilityId The capability template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Disassociated the property of a node template to an input of the topology. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Associate the property of a node template to an input of the topology. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   QueryParameter inputId The name of the input. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the possible inputs candidates to be associated with this property. GET /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/property/{propertyId}/inputcandidats Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Disassociated the property of a relationship template to an input of the topology. DELETE /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationship/{relationshipId}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter relationshipId The relationship template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Associate the property of a relationship template to an input of the topology. POST /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationship/{relationshipId}/property/{propertyId}/input Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   QueryParameter inputId The name of the input. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter relationshipId The relationship template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get the possible inputs candidates to be associated with this relationship property. GET /rest/topologies/{topologyId}/nodetemplates/{nodeTemplateName}/relationship/{relationshipId}/property/{propertyId}/inputcandidats Description Application role required [ APPLICATION_MANAGER APPLICATION_DEVOPS ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter nodeTemplateName The node temlate id. true string   PathParameter propertyId The property id. true string   PathParameter relationshipId The relationship template id. true string   Responses HTTP Code Description Schema 200 OK RestResponse«List«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"Topology Substitutions Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_topology-substitutions-controller.html","date":null,"categories":[],"body":"Expose the given capability as a capability for the substitution type associated with this topology. PUT /rest/topologies/{topologyId}/substitutions/capabilities/{substitutionCapabilityId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionCapabilityId The substitution capability name. true string   QueryParameter nodeTemplateName The node template id. true string   QueryParameter capabilityId The source node capability id. true string   Responses HTTP Code Description Schema 201 Created RestResponse«TopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove the substitution capability from the substitution type. DELETE /rest/topologies/{topologyId}/substitutions/capabilities/{substitutionCapabilityId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionCapabilityId The substitution capability name. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Update the substitution capability (typically change it’s name). POST /rest/topologies/{topologyId}/substitutions/capabilities/{substitutionCapabilityId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionCapabilityId The substitution capability name. true string   QueryParameter newCapabilityId The new capability name. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Expose the given requirement as a requirement for the substitution type associated with this topology. PUT /rest/topologies/{topologyId}/substitutions/requirements/{substitutionRequirementId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionRequirementId The substitution requirement name. true string   QueryParameter nodeTemplateName The node template id. true string   QueryParameter requirementId The source node requirement id. true string   Responses HTTP Code Description Schema 201 Created RestResponse«TopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove the requirement from the substitution type associated to this topology. DELETE /rest/topologies/{topologyId}/substitutions/requirements/{substitutionRequirementId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionRequirementId The substitution requirement name. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Update the substitution requirement (typically change it’s name). POST /rest/topologies/{topologyId}/substitutions/requirements/{substitutionRequirementId} Description Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId The topology id. true string   PathParameter substitutionRequirementId The substitution requirement name. true string   QueryParameter newRequirementId The new substution requirement name. true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Define the type this topology can substitute. When this method is called, a new type is created : it is derived from this one. PUT /rest/topologies/{topologyId}/substitutions/type Description Returns a topology with it’s details. Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   QueryParameter elementId elementId true string   Responses HTTP Code Description Schema 201 Created RestResponse«TopologyDTO» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove the substitution type, delete the corresponding type (if not already used) DELETE /rest/topologies/{topologyId}/substitutions/type Description Returns a topology with it’s details. Role required [ ARCHITECT ] Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«TopologyDTO» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Topology Workflow Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_topology-workflow-controller.html","date":null,"categories":[],"body":"getWorkflows GET /rest/topologies/{topologyId}/workflows Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Set«string»» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json createWorkflow POST /rest/topologies/{topologyId}/workflows Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json removeWorkflow DELETE /rest/topologies/{topologyId}/workflows/{workflowName} Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json renameWorkflow POST /rest/topologies/{topologyId}/workflows/{workflowName} Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   QueryParameter newName newName true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json addActivity POST /rest/topologies/{topologyId}/workflows/{workflowName}/activities Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   BodyParameter activityRequest activityRequest true TopologyWorkflowAddActivityRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json removeEdge DELETE /rest/topologies/{topologyId}/workflows/{workflowName}/edges/{from}/{to} Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter from from true string   PathParameter to to true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json initWorkflow POST /rest/topologies/{topologyId}/workflows/{workflowName}/init Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json removeStep DELETE /rest/topologies/{topologyId}/workflows/{workflowName}/steps/{stepId} Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter stepId stepId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json renameStep POST /rest/topologies/{topologyId}/workflows/{workflowName}/steps/{stepId} Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter stepId stepId true string   QueryParameter newStepName newStepName true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json connectStepFrom POST /rest/topologies/{topologyId}/workflows/{workflowName}/steps/{stepId}/connectFrom Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter stepId stepId true string   BodyParameter stepNames stepNames true string array   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json connectStepTo POST /rest/topologies/{topologyId}/workflows/{workflowName}/steps/{stepId}/connectTo Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter stepId stepId true string   BodyParameter stepNames stepNames true string array   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json swap POST /rest/topologies/{topologyId}/workflows/{workflowName}/steps/{stepId}/swap Parameters Type Name Description Required Schema Default PathParameter topologyId topologyId true string   PathParameter workflowName workflowName true string   PathParameter stepId stepId true string   QueryParameter targetId targetId true string   Responses HTTP Code Description Schema 200 OK RestResponse«Workflow» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json "},{"title":"User Controller","baseurl":"","url":"/documentation/1.1.0/rest/controller_user-controller.html","date":null,"categories":[],"body":"Create a new user in ALIEN. POST /rest/users Parameters Type Name Description Required Schema Default BodyParameter request request true CreateUserRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get multiple users from their usernames. POST /rest/users/getUsers Description Returns a rest response that contains the list of requested users. Parameters Type Name Description Required Schema Default BodyParameter usernames usernames true string array   Responses HTTP Code Description Schema 200 OK RestResponse«List«User»» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Search for user’s registered in alien. POST /rest/users/search Parameters Type Name Description Required Schema Default BodyParameter searchRequest searchRequest true UserSearchRequest   Responses HTTP Code Description Schema 200 OK RestResponse«FacetedSearchResult» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Get a user based on it’s username. GET /rest/users/{username} Description Returns a rest response that contains the user’s details. Parameters Type Name Description Required Schema Default PathParameter username username true string   Responses HTTP Code Description Schema 200 OK RestResponse«User» 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Update an user by merging the userUpdateRequest into the existing user PUT /rest/users/{username} Parameters Type Name Description Required Schema Default PathParameter username username true string   BodyParameter userUpdateRequest userUpdateRequest true UpdateUserRequest   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Delete an existing user from the internal user’s repository. DELETE /rest/users/{username} Parameters Type Name Description Required Schema Default PathParameter username username true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json Add a role to a user. PUT /rest/users/{username}/roles/{role} Parameters Type Name Description Required Schema Default PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 201 Created No Content 401 Unauthorized No Content 403 Forbidden No Content 404 Not Found No Content Consumes application/json Produces application/json Remove a role from a user. DELETE /rest/users/{username}/roles/{role} Parameters Type Name Description Required Schema Default PathParameter username username true string   PathParameter role role true string   Responses HTTP Code Description Schema 200 OK RestResponse«Void» 401 Unauthorized No Content 204 No Content No Content 403 Forbidden No Content Consumes application/json Produces application/json "},{"title":"Customised Blockstorage","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/custom_blockstorage.html","date":null,"categories":[],"body":" Note that the driver only supports groovy scripts for all these scripts. Some times you might need to provide your own way to manage the storage lifecycle. This is for example if you have a custom way to create, attach, format, mount it. For that, you can provide every node of type tosca.nodes.BlockStorage with the lifcycle operation create and configure . And for the destroy process, you’ll use the delete operation. alien.test.nodes.UbuntuBlockStorage : derived_from : tosca.nodes.BlockStorage description : > A custom storage for Ubuntu OS. interfaces : Standard : create : scripts/createAttach.groovy configure : scripts/formatMount.groovy delete : scripts/unmountDelete.groovy [ ... ] Create and attach Provide your custom way to create and attach the storage to your compute in the create TOSCA Standard’s operation. Environment variables In addition to the provided base node environment variables SELF, HOST, SERVICE_NAME : Keyword Description volumeId if provided, the Id of the volume to attach. This might be null storageTemplate The Id of the storage template to use to create a volume, base on the size provided. This is never null. Return The script must return a map <String –> String> containing the keys: volumeId : id of the created (or provided) volume, device : device name on which the volume is attached Example import org.cloudifysource.utilitydomain.context.ServiceContextFactory def context = ServiceContextFactory . getServiceContext () def device = \"/dev/vdb\" //Creating the volume if ( volumeId == null ){ volumeId = context . storage . createVolume ( storageTemplate ) } //attaching the volume context . storage . attachVolume ( volumeId , device ) //return the map return [ volumeId: volumeId , device: device ] Format and mount Provide your custom way to format and mount the storage on your compute in the configure TOSCA Standard’s operation. Environment variables In addition to the provided base node environment variables SELF, HOST, SERVICE_NAME : Keyword Description device device name on which the volume is attached Return The script must return a string value: location : location path where the device is mounted on the compute Example import org.cloudifysource.utilitydomain.context.ServiceContextFactory def context = ServiceContextFactory . getServiceContext () def location = \"/mountTest\" denew AntBuilder (). sequential { chmod ( dir: \"${context.serviceDirectory}/scripts\" , perm: \"+x\" , includes: \"*.sh\" ) exec ( executable: \"${context.serviceDirectory}/scripts/formatStorage.sh\" , failonerror: \"true\" ) { arg ( value: \"${device}\" ) } mkdir ( dir: location ) exec ( executable: \"${context.serviceDirectory}/scripts/mountStorage.sh\" , failonerror: \"true\" ) { arg ( value: \"${device}\" ) arg ( value: \"${location}\" ) } } //return the mounted path name return location Unmount and delete Provide your custom way to unmount and/or delete the storage in the delete TOSCA Standard’s operation. Environment variables In addition to the provided base node environment variables SELF, HOST, SERVICE_NAME : Keyword Description volumeId if provided, the Id of the attached volume. device device name on which the volume is attached Return No need to return anything for this script. Example import org.cloudifysource.utilitydomain.context.ServiceContextFactory def context = ServiceContextFactory . getServiceContext () println \"Storage volume: volumeId <${volumeId}>, device <${device}>\" println \"deletable-unmountDelete.groovy: unmounting storage volume... \" context . storage . unmount ( device ) println \"deletable-unmountDelete.groovy: detaching storage volume... \" context . storage . detachVolume ( volumeId ) "},{"title":"Definitions document","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/definitions_file.html","date":null,"categories":[],"body":"The root element of a definition file is called the Service Template. A TOSCA Definitions YAML document contains element definitions of building blocks for cloud application, or complete models of cloud applications. This section describes the top-level structural elements (i.e., YAML keys) which are allowed to appear in a TOSCA Definitions YAML document. Keynames A TOSCA Definitions file contains the following element keynames: Keyname Required Description tosca_definitions_version yes Defines the version of the TOSCA Simple Profile specification the template (grammar) complies with. tosca_default_namespace no Defines the namespace of the TOSCA schema to use for validation. template_name yes* Declares the name of the template. template_author no Declares the author(s) of the template. template_version yes* Declares the version string for the template. description no Declares a description for this Service Template and its contents. imports no Declares import statements external TOSCA Definitions documents (files). dsl_definitions no Declares optional DSL-specific definitions and conventions. For example, in YAML, this allows defining reusable YAML macros (i.e., YAML alias anchors) for use throughout the TOSCA Service Template. node_types no This section contains a set of node type definitions for use in service templates. Such type definitions may be used within the node_templates section of the same file, or a TOSCA Definitions file may also just contain node type definitions for use in other files. relationship_types no This section contains a set of relationship type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain relationship type definitions for use in other files. capability_types no This section contains an optional list of capability type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain capability type definitions for use in other files. artifact_types no This section contains an optional list of artifact type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain capability type definitions for use in other files. topology_template no Defines the topology template of an application or service, consisting of node templates that represent the application’s or service’s components, as well as relationship templates representing relations between the components. (*) In Alien 4 Cloud the template name and versions are required as we supports versioning of the templates and indexing of elements in a catalog. In TOSCA specification they are optional. Grammar The overall structure of a TOSCA Service Template and its top-level key collations using the TOSCA Simple Profile is shown below: tosca_definitions_version : # Required TOSCA Definitions version string tosca_default_namespace : # Optional. default namespace (schema, types version) template_name : # Optional name of this service template template_author : # Optional author of this service template template_version : # Optional version of this service template description : A short description of the definitions inside the file. imports : # list of import statements for importing other definitions files dsl_definitions : # list of YAML alias anchors (or macros) node_types : # list of node type definitions capability_types : # list of capability type definitions relationship_types : # list of relationship type definitions artifact_types : # list of artifact type definitions topology_template : # Topology template definition tosca_definitions_version This required element provides a means to include a reference to the TOSCA Simple Profile specification within the TOSCA Definitions YAML file. It is an indicator for the version of the TOSCA grammar that should be used to parse the remainder of the document. Keyword tosca_definitions_version Grammar tosca_definitions_version : <tosca_simple_profile_version> Examples: TOSCA Simple Profile version 1.0 specification using the defined namespace alias: tosca_definitions_version : tosca_simple_yaml_1_0_0 TOSCA Simple Profile version 1.0 specification using the fully defined (target) namespace: tosca_definitions_version : http://docs.oasis-open.org/tosca/simple/1.0 template_name This optional element declares the optional name of service template as a single-line string value. Keyword template_name Grammar template_name : <name string> Example template_name : My service template Notes Some service templates are designed to be referenced and reused by other service templates. Therefore, in these cases, the template_name value SHOULD be designed to be used as a unique identifier through the use of namespacing techniques. template_author This optional element declares the optional author(s) of the service template as a single-line string value. Keyword template_author #### Grammar template_author : <author string> Example template_author : My service template template_version This element declares the optional version of the service template as a single-line string value. Grammar template_version : <version> Example template_version : 2.0.17 Some service templates are designed to be referenced and reused by other service templates and have a lifecycle of their own. Therefore, in these cases, a template_version value SHOULD be included and used in conjunction with a unique template_name value to enable lifecycle management of the service template and its contents. description This optional element provides a means to include single or multiline descriptions within a TOSCA Simple Profile template as a scalar string value. imports This optional element provides a way to import a block sequence of one or more TOSCA Definitions documents. TOSCA Definitions documents can contain reusable TOSCA type definitions (e.g., Node Types, Relationship Types, Artifact Types, etc.) defined by other authors. This mechanism provides an effective way for companies and organizations to define normative types and/or describe their software applications for reuse in other TOSCA Service Templates. In Alien 4 Cloud you can import libraries from the repository instead of having to package every required elements within your archives. This also allows a better management of versioning and dependencies. In order to support this scenario the import element supports an additional non-normative definition. Of course when you export artifacts from Alien 4 Cloud you can ask Alien 4 Cloud to export a pure normative package (Alien will package all elements required together in a single archive and use normative relative imports). Grammar imports : - <tosca_definitions_file_1> - ... - <tosca_definitions_file_n> Alien 4 Cloud specific grammar for catalog imports based on Definitions template names and versions. imports : - <tosca_template_name_1>:<tosca_template_version_1> - ... - <tosca_template_name_n>:<tosca_template_version_n> Example # An example import of definitions files from a location relative to the # file location of the service template declaring the import. imports : - relative_path/my_defns/my_typesdefs_1.yaml - ... - relative_path/my_defns/my_typesdefs_n.yaml Alien 4 Cloud specific. imports : - <tosca-normative-types>:<1.1.0> - ... - <apache-server>:<2.0.3> dsl_definitions This optional element provides a section to define macros. A macro can be reused elsewhere by referencing it. Example In the following example, we define a ‘macro’ named ‘my_compute_node_props’ which defines a property ‘os_type’ and it’s value. It is used for the both nodes compute1 and compute2. dsl_definitions : my_compute_node_props : &my_compute_node_props os_type : linux topology_template : node_templates : compute1 : type : tosca.nodes.Compute properties : *my_compute_node_props compute2 : type : tosca.nodes.Compute properties : *my_compute_node_props node_types This element lists the Node Types that provide the reusable type definitions for software components that Node Templates can be based upon. Grammar node_types : <node_types_defn_1> ... <node_type_defn_n> Example node_types : my_webapp_node_type : derived_from : WebApplication properties : my_port : type : integer my_database_node_type : derived_from : Database capabilities : mytypes.myfeatures.transactSQL The node types listed as part of the node_types block can be mapped to the list of NodeType definitions as described by the TOSCA v1.0 specification. relationship_types This element lists the Relationship Types that provide the reusable type definitions that can be used to describe dependent relationships between Node Templates or Node Types. Grammar relationship_types : <relationship_type_defn_1> ... <relationship type_defn_n> Example relationship_types : mycompany.mytypes.myCustomClientServerType : derived_from : tosca.relationships.HostedOn properties : # more details ... mycompany.mytypes.myCustomConnectionType : derived_from : tosca.relationships.ConnectsTo properties : # more details ... capability_types This element lists the Capability Types that provide the reusable type definitions that can be used to describe features Node Templates or Node Types can declare they support. Grammar capability_types : <capability_type_defn_1> ... <capability type_defn_n> Example capability_types : mycompany.mytypes.myCustomEndpoint : derived_from : tosca.capabilities.Endpoint properties : # more details ... mycompany.mytypes.myCustomFeature : derived_from : tosca.capabilites.Feature properties : # more details ... topology_template see: - Topology template "},{"title":"Definitions document","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/definitions_file.html","date":null,"categories":[],"body":"The root element of a definition file is called the Service Template. A TOSCA Definitions YAML document contains element definitions of building blocks for cloud application, or complete models of cloud applications. This section describes the top-level structural elements (i.e., YAML keys) which are allowed to appear in a TOSCA Definitions YAML document. Keynames A TOSCA Definitions file contains the following element keynames: Keyname Required Description tosca_definitions_version yes Defines the version of the TOSCA Simple Profile specification the template (grammar) complies with. tosca_default_namespace no Defines the namespace of the TOSCA schema to use for validation. template_name yes* Declares the name of the template. template_author no Declares the author(s) of the template. template_version yes* Declares the version string for the template. description no Declares a description for this Service Template and its contents. imports no Declares import statements external TOSCA Definitions documents (files). dsl_definitions no Declares optional DSL-specific definitions and conventions. For example, in YAML, this allows defining reusable YAML macros (i.e., YAML alias anchors) for use throughout the TOSCA Service Template. node_types no This section contains a set of node type definitions for use in service templates. Such type definitions may be used within the node_templates section of the same file, or a TOSCA Definitions file may also just contain node type definitions for use in other files. relationship_types no This section contains a set of relationship type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain relationship type definitions for use in other files. capability_types no This section contains an optional list of capability type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain capability type definitions for use in other files. artifact_types no This section contains an optional list of artifact type definitions for use in service templates. Such type definitions may be used within the same file, or a TOSCA Definitions file may also just contain capability type definitions for use in other files. topology_template no Defines the topology template of an application or service, consisting of node templates that represent the application’s or service’s components, as well as relationship templates representing relations between the components. (*) In Alien 4 Cloud the template name and versions are required as we supports versioning of the templates and indexing of elements in a catalog. In TOSCA specification they are optional. Grammar The overall structure of a TOSCA Service Template and its top-level key collations using the TOSCA Simple Profile is shown below: tosca_definitions_version : # Required TOSCA Definitions version string tosca_default_namespace : # Optional. default namespace (schema, types version) template_name : # Optional name of this service template template_author : # Optional author of this service template template_version : # Optional version of this service template description : A short description of the definitions inside the file. imports : # list of import statements for importing other definitions files dsl_definitions : # list of YAML alias anchors (or macros) node_types : # list of node type definitions capability_types : # list of capability type definitions relationship_types : # list of relationship type definitions artifact_types : # list of artifact type definitions topology_template : # Topology template definition tosca_definitions_version This required element provides a means to include a reference to the TOSCA Simple Profile specification within the TOSCA Definitions YAML file. It is an indicator for the version of the TOSCA grammar that should be used to parse the remainder of the document. Keyword tosca_definitions_version Grammar tosca_definitions_version : <tosca_simple_profile_version> Examples: TOSCA Simple Profile version 1.0 specification using the defined namespace alias: tosca_definitions_version : tosca_simple_yaml_1_0_0 TOSCA Simple Profile version 1.0 specification using the fully defined (target) namespace: tosca_definitions_version : http://docs.oasis-open.org/tosca/simple/1.0 template_name This optional element declares the optional name of service template as a single-line string value. Keyword template_name Grammar template_name : <name string> Example template_name : My service template Notes Some service templates are designed to be referenced and reused by other service templates. Therefore, in these cases, the template_name value SHOULD be designed to be used as a unique identifier through the use of namespacing techniques. template_author This optional element declares the optional author(s) of the service template as a single-line string value. Keyword template_author #### Grammar template_author : <author string> Example template_author : My service template template_version This element declares the optional version of the service template as a single-line string value. Grammar template_version : <version> Example template_version : 2.0.17 Some service templates are designed to be referenced and reused by other service templates and have a lifecycle of their own. Therefore, in these cases, a template_version value SHOULD be included and used in conjunction with a unique template_name value to enable lifecycle management of the service template and its contents. description This optional element provides a means to include single or multiline descriptions within a TOSCA Simple Profile template as a scalar string value. imports This optional element provides a way to import a block sequence of one or more TOSCA Definitions documents. TOSCA Definitions documents can contain reusable TOSCA type definitions (e.g., Node Types, Relationship Types, Artifact Types, etc.) defined by other authors. This mechanism provides an effective way for companies and organizations to define normative types and/or describe their software applications for reuse in other TOSCA Service Templates. In Alien 4 Cloud you can import libraries from the repository instead of having to package every required elements within your archives. This also allows a better management of versioning and dependencies. In order to support this scenario the import element supports an additional non-normative definition. Of course when you export artifacts from Alien 4 Cloud you can ask Alien 4 Cloud to export a pure normative package (Alien will package all elements required together in a single archive and use normative relative imports). Grammar imports : - <tosca_definitions_file_1> - ... - <tosca_definitions_file_n> Alien 4 Cloud specific grammar for catalog imports based on Definitions template names and versions. imports : - <tosca_template_name_1>:<tosca_template_version_1> - ... - <tosca_template_name_n>:<tosca_template_version_n> Example # An example import of definitions files from a location relative to the # file location of the service template declaring the import. imports : - relative_path/my_defns/my_typesdefs_1.yaml - ... - relative_path/my_defns/my_typesdefs_n.yaml Alien 4 Cloud specific. imports : - <tosca-normative-types>:<1.0.0> - ... - <apache-server>:<2.0.3> dsl_definitions This optional element provides a section to define macros. A macro can be reused elsewhere by referencing it. Example In the following example, we define a ‘macro’ named ‘my_compute_node_props’ which defines a property ‘os_type’ and it’s value. It is used for the both nodes compute1 and compute2. dsl_definitions : my_compute_node_props : &my_compute_node_props os_type : linux topology_template : node_templates : compute1 : type : tosca.nodes.Compute properties : *my_compute_node_props compute2 : type : tosca.nodes.Compute properties : *my_compute_node_props node_types This element lists the Node Types that provide the reusable type definitions for software components that Node Templates can be based upon. Grammar node_types : <node_types_defn_1> ... <node_type_defn_n> Example node_types : my_webapp_node_type : derived_from : WebApplication properties : my_port : type : integer my_database_node_type : derived_from : Database capabilities : mytypes.myfeatures.transactSQL The node types listed as part of the node_types block can be mapped to the list of NodeType definitions as described by the TOSCA v1.0 specification. relationship_types This element lists the Relationship Types that provide the reusable type definitions that can be used to describe dependent relationships between Node Templates or Node Types. Grammar relationship_types : <relationship_type_defn_1> ... <relationship type_defn_n> Example relationship_types : mycompany.mytypes.myCustomClientServerType : derived_from : tosca.relationships.HostedOn properties : # more details ... mycompany.mytypes.myCustomConnectionType : derived_from : tosca.relationships.ConnectsTo properties : # more details ... capability_types This element lists the Capability Types that provide the reusable type definitions that can be used to describe features Node Templates or Node Types can declare they support. Grammar capability_types : <capability_type_defn_1> ... <capability type_defn_n> Example capability_types : mycompany.mytypes.myCustomEndpoint : derived_from : tosca.capabilities.Endpoint properties : # more details ... mycompany.mytypes.myCustomFeature : derived_from : tosca.capabilites.Feature properties : # more details ... topology_template see: - Topology template "},{"title":"Deployment properties","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/deployment_properties.html","date":null,"categories":[],"body":"The Alien4Cloud cloudify 2.X provider provides some properties to setup or customize a deployment: Property Default Value Possible values Description startDetection_timeout_inSecond 600 (Seconds) > 0 Cloudify startDetection timeout: Timeout for the application to be fully started disable_self_healing No(False) Yes(True), No(False) Whether to disable or not the cloudify’s self-healing mechanism for this deployment. events_lease_inHour 2 (hour)) > 0 Lease time in hour for alien4cloud events. After this time, events will e deleted. deletable_blockstorage No(False) Yes(True), No(False) Whether to delete or not the created volumes when undeploying. log_level INFO OFF, ERROR, INFO, DEBUG Log level for this deployment. "},{"title":"Dev Ops Guide","baseurl":"","url":"/documentation/1.0.0/devops_guide/dev_ops_guide.html","date":null,"categories":[],"body":"This section contains reference to the TOSCA Simple profile in YAML specification as it is now supported in Alien. TOSCA is a standard specification that allow dev_ops and architects to define reusable components and topologies that can be easily ported across clouds and orchestrators. Alien 4 Cloud is designed so you can easily add your own components and leverage your existing scripts, puppet or chef recipes, using the TOSCA YAML based DSL. TOSCA Alien 4 Cloud is compliant with OASIS’s TOSCA standard to model it’s different components (nodes, relationships, capabilities and requirements). In order to define components in TOSCA you can use the XML or YAML profile (TOSCA Simple Profile). We recommend using the simple profile and thus this documentation describe only the way to configure elements using the simple profile. Tosca support in ALien 4 Cloud Alien 4 Cloud only supports TOSCA Simple Profile in YAML. Simple profile v1 is not released yet and still evolves, a release is planned by the TC for half of 2015. We currently have a partial support of the latest working drafts, being closer to wd03 than wd05. Our goal is to maintain support for the various Simple profile releases but we don’t intend to support all working drafts as they are won’t be used by the community. "},{"title":"Dev Ops Guide","baseurl":"","url":"/documentation/1.1.0/devops_guide/dev_ops_guide.html","date":null,"categories":[],"body":"This section contains reference to the TOSCA Simple profile in YAML specification as it is now supported in Alien. TOSCA is a standard specification that allow dev_ops and architects to define reusable components and topologies that can be easily ported across clouds and orchestrators. Alien 4 Cloud is designed so you can easily add your own components and leverage your existing scripts, puppet or chef recipes, using the TOSCA YAML based DSL. TOSCA Alien 4 Cloud is compliant with OASIS’s TOSCA standard to model it’s different components (nodes, relationships, capabilities and requirements). In order to define components in TOSCA you can use the XML or YAML profile (TOSCA Simple Profile). We recommend using the simple profile and thus this documentation describe only the way to configure elements using the simple profile. Tosca support in ALien 4 Cloud Alien 4 Cloud only supports TOSCA Simple Profile in YAML. Simple profile v1 is not released yet and still evolves, a release is planned by the TC for half of 2015. We currently have a partial support of the latest working drafts, being closer to wd03 than wd05. Our goal is to maintain support for the various Simple profile releases but we don’t intend to support all working drafts as they are won’t be used by the community. "},{"title":"Function definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/function_definition.html","date":null,"categories":[],"body":"Work in progress, details the functions that can be applied to properties and function input parameters. A function definition defines a named function to evaluate at runtime, and that can be used as property, attribute or input parameter. It is used to dynamically retrieve a value from property definition defined on an entity. Reserved function keywords The following keywords may be used in some TOSCA function in place of a TOSCA Node or Relationship Template name. They will be interpreted when evaluation the function at runtime. Keyword Valid context Description SELF Node Template or Relationship Template Node or Relationship Template instance that contains the function at the time the function is evaluated. SOURCE Relationship Template only Node Template instance that is at the source end of the relationship that contains the referencing function. TARGET Relationship Template only Node Template instance that is at the target end of the relationship that contains the referencing function. HOST Node Template only Node that “hosts” the node using this reference (i.e., as identified by its HostedOn relationship). Supported functions in Alien4Cloud are: get_property get_attribute get_operation_output concat "},{"title":"Function definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/function_definition.html","date":null,"categories":[],"body":"Work in progress, details the functions that can be applied to properties and function input parameters. A function definition defines a named function to evaluate at runtime, and that can be used as property, attribute or input parameter. It is used to dynamically retrieve a value from property definition defined on an entity. Reserved function keywords The following keywords may be used in some TOSCA function in place of a TOSCA Node or Relationship Template name. They will be interpreted when evaluation the function at runtime. Keyword Valid context Description SELF Node Template or Relationship Template Node or Relationship Template instance that contains the function at the time the function is evaluated. SOURCE Relationship Template only Node Template instance that is at the source end of the relationship that contains the referencing function. TARGET Relationship Template only Node Template instance that is at the target end of the relationship that contains the referencing function. HOST Node Template only Node that “hosts” the node using this reference (i.e., as identified by its HostedOn relationship). Supported functions in Alien4Cloud are: get_property get_attribute get_operation_output concat "},{"title":"get_attribute","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/get_attribute_definition.html","date":null,"categories":[],"body":"The get_attribute function is used to retrieve the values of named attributes declared by the referenced node or relationship template name. Use this function for inputs parameters. Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from.Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST attribute_name string yes Name of the attribute definition the function will return the value from. Grammar get_attribute : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , <attribute_name> ] Example The following example shows how to define an input parameter on relationship using get_attribute function: relationship_types : fastconnect.relationship.FunctionSample interfaces : configure : add_target : inputs : TARGET_IP : { get_attribute : [ TARGET , ip_address ] } implementation : add_target.sh "},{"title":"get_attribute","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/get_attribute_definition.html","date":null,"categories":[],"body":"The get_attribute function is used to retrieve the values of named attributes declared by the referenced node or relationship template name. Use this function for inputs parameters. Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from.Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST attribute_name string yes Name of the attribute definition the function will return the value from. Grammar get_attribute : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , <attribute_name> ] Example The following example shows how to define an input parameter on relationship using get_attribute function: relationship_types : fastconnect.relationship.FunctionSample interfaces : configure : add_target : inputs : TARGET_IP : { get_attribute : [ TARGET , ip_address ] } implementation : add_target.sh "},{"title":"get_input","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/get_input.html","date":null,"categories":[],"body":"The get_input function is used to retrieve the values of properties declared within the inputs section of a TOSCA Service Template. Grammar get_input : <input_property_name> Example inputs : cpus : type : integer node_templates : my_server : type : tosca.nodes.Compute properties : num_cpus : { get_input : cpus } "},{"title":"get_input","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/get_input.html","date":null,"categories":[],"body":"The get_input function is used to retrieve the values of properties declared within the inputs section of a TOSCA Service Template. Grammar get_input : <input_property_name> Example inputs : cpus : type : integer node_templates : my_server : type : tosca.nodes.Compute properties : num_cpus : { get_input : cpus } "},{"title":"get_operation_output","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/get_operation_output_definition.html","date":null,"categories":[],"body":"The get_operation_output function is used to retrieve the values of variables exposed / exported from an interface operations. Use this function for inputs parameters and/or attributes. Keynames Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that implements the named interface and operation. Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST interface_name string yes The required name of the interface which defines the operation. operation_name string yes The required name of the operation whose output value we would like to retrieve. output_variable_name string yes The required name of the output variable that is exposed / exported by the operation. Grammar get_operation_output : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , <interface_name> , <operation_name> , <output_variable_name> ] Example The following example shows how to define an attribute and an input parameter using get_operation_output function: node_types : fastconnect.nodes.FunctionSample : attributes : port : { get_operation_output : [ SELF , Standard , configure , bound_port ]} interfaces : Standard : configure : config.sh #the config.sh script should expose an environment variable (output) named \"bound_port\" start : inputs : PORT : { get_operation_output : [ SELF , Standard , configure , bound_port ]} implementation : start.sh "},{"title":"get_operation_output","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/get_operation_output_definition.html","date":null,"categories":[],"body":"The get_operation_output function is used to retrieve the values of variables exposed / exported from an interface operations. Use this function for inputs parameters and/or attributes. Keynames Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that implements the named interface and operation. Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST interface_name string yes The required name of the interface which defines the operation. operation_name string yes The required name of the operation whose output value we would like to retrieve. output_variable_name string yes The required name of the output variable that is exposed / exported by the operation. Grammar get_operation_output : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , <interface_name> , <operation_name> , <output_variable_name> ] Example The following example shows how to define an attribute and an input parameter using get_operation_output function: node_types : fastconnect.nodes.FunctionSample : attributes : port : { get_operation_output : [ SELF , Standard , configure , bound_port ]} interfaces : Standard : configure : config.sh #the config.sh script should expose an environment variable (output) named \"bound_port\" start : inputs : PORT : { get_operation_output : [ SELF , Standard , configure , bound_port ]} implementation : start.sh "},{"title":"get_property","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/get_property_definition.html","date":null,"categories":[],"body":"The get_property function is used to retrieve property values between modelable entities defined in the same service template. Use this function for inputs parameters. Keynames Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from.Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST capability_name string no The optional name of a capability within the modelable entity that contains the named property definition the function will return the value from. property_name string yes Name of the property definition the function will return the value from. Grammar get_property : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , [ <capability_name> ], <property_name> ] Example The following example shows how to define an input parameter using get_property function: node_types : fastconnect.nodes.FunctionSample : properties : myName : type : string interfaces : Standard : configure : inputs : MY_NAME : { get_property : [ SELF , myName ] } CAPA_PORT : { get_property : [ SELF , endpoint , port ] } implementation : config.sh "},{"title":"get_property","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/get_property_definition.html","date":null,"categories":[],"body":"The get_property function is used to retrieve property values between modelable entities defined in the same service template. Use this function for inputs parameters. Keynames Keyname Type Required Description modelable_entity_name string yes The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from.Can be one of the reserved keywords: SELF, SOURCE, TARGET, HOST capability_name string no The optional name of a capability within the modelable entity that contains the named property definition the function will return the value from. property_name string yes Name of the property definition the function will return the value from. Grammar get_property : [ <modelable_entity_name | SELF | SOURCE | TARGET | HOST> , [ <capability_name> ], <property_name> ] Example The following example shows how to define an input parameter using get_property function: node_types : fastconnect.nodes.FunctionSample : properties : myName : type : string interfaces : Standard : configure : inputs : MY_NAME : { get_property : [ SELF , myName ] } CAPA_PORT : { get_property : [ SELF , endpoint , port ] } implementation : config.sh "},{"title":"Getting started","baseurl":"","url":"/documentation/1.0.0/getting_started/getting_started.html","date":null,"categories":[],"body":"To begin with Alien you have two choices : the 30 min Start Guide! or the Step by step guide The first guide is like a demo, the best way if you want to try Alien in no time but you need an active AWS account. The second guide will explain how to take in charge Alien in details and configure it for your uses. Important: security issue Alien used a version of ElasticSearch concern by a security issue. To prevent an attack, make sure to secure the port of ES (9200 as default). 1. Prerequisites: Download and install VirtualBox (Working with version >= 4.3.26) Download and install Vagrant (Working with version >= 1.7.2) Install triggers plugin for Vagrant: vagrant plugin install vagrant-triggers (Working with version >= 0.5.0) An active AWS account. Make sure you have all the account informations we will need later (user key, access key, key file and key pair) 2. VM Automated Install: Download and unzip the package vm-alien4cloud-1.0.0 (for other version, see on the page footer). As a result, a subdirectory vm-alien4cloud should be created Copy your .pem file to the directory vm-alien4cloud/vm/key Edit the file vm-alien4cloud/puppet/manifests/install.pp and set your aws “user key” and “access key” ( user and apiKey parameters), key file name and key pair ( keyFile and keyPair parameters) and finally change machineNamePrefix and managementGroup . Change your working directory: cd vm-alien4cloud/vm/centos-6 Execute the following command to build a new VM: vagrant up At the first run, vagrant will download the base box which will be used to create the alien4cloud VM, then provision the VM with Puppet. The time needed to create a VM is around 30 minutes and depends on your internet connection speed. At the end of the installation, you’ll see a message ==> alien4cloud: Notice: Finished catalog run in 1648.89 seconds . You can then access Alien4Cloud Web interface from a browser on the following address: http://192.168.32.10:8088 . Use the default account admin with the password admin to login into Alien. 3. Deploy your application: To deploy this new application, just go on Applications > Deployments submenu. Zone A : Select an environment and a cloud Keep the default environment Environment and select your cloud OpenStackCloud created above. Zone B : Provider properties Those properties depends on the provider implementation. You usualy have default settings. Zone C : Topology required settings Those basic settings are required for Compute nodes. Zone D : Cloud resources matching In this part, you will be able to check matching cloud resources and possible matching errors. This should not happen if your cloud is well configured. 4. Check that your application is up and running: Runtime view: On this submenu view Application > Runtime , you can have the detailed deployment progress. Wordpress url Go back in the Application > Informations submenu to get the Wordpress application url and test it ! And voilà ! 5. How to Uninstall: If you would like to de-provision the VM and the associated cloud created by Alien4Cloud, just execute the following commands: Change your working directory: cd vm-alien4cloud/vm/centos-6 Run the following command: vagrant destroy Older versions: vm-alien4cloud-1.0.0-RC1 vm-alien4cloud-SM23 vm-alien4cloud-SM24 vm-alien4cloud-SM25 vm-alien4cloud-SM26 vm-alien4cloud-SM27 1. Prerequisites: Ensure that you have at least JAVA version 7 or higher installed on your working station. If not, just install java following instructions here . You can get Cloudify in version : 2.7.1 here . 3.2 here . In order to start using alien 4 cloud you have to download Alien. Two versions are available : standalone : starts an embedded jetty server deployable : war file that can be deployed within a war container We recommend using the Alien standalone with Cloudify 2.7.1. 2. Check your access to a cloud: To try Alien 4 Cloud with provider plugin Cloudify 2.x or 3.x you will need a cloud ready to use with your credentials. If not, we advice you to use trystack , a personal an free to use OpenStack. For this tutorial we recommend to use OpenStack. 3. Configure and start Cloudify: Regarding your choice between providers for Cloudify 2 or 3, please refer to those following sections : Configure and start Cloudify 2 Configure and start Cloudify 3 4. Start and configure Alien 4 Cloud : Assuming you have downloaded the standalone version in the prerequisite step you will only have to execute the following command in your shell : java -XX:MaxPermSize = 512m -jar alien4cloud-ui-VERSION-standalone.war --spring.profiles.active = security-demo The command option --spring.profiles.active=security-demo allows you to have Alien 4 Cloud started with default settings such as the default user admin we will use later. 5. Check that Alien4Cloud is working : After connecting via your browser (for standalone version, default port is 8088 on the machine hosting A4C), you should see the following Authentication splash screen 6. Install and configure provider plugin: In this step, you will have to import the chosen provider plugin and then configure it. Refer to the following sections : Cloudify 2 plugin Cloudify 3 plugin In our tutorial, let’s call the configured cloud OpenStackCloud . 7. Import components in Alien 4 Cloud: Regardless the used provider, read the following section to know how to import your components archive : import components Normative types The TOSCA specification used by Alien 4 Cloud is defining normative types . As a language, you can use those components as is or extend it to suit to your needs. You can find our implementation for these types on github here : normative types on github This download link will provide a zip with a subfolder. Ensure that this subfolder doest not exist or the component upload will fail. You must have a zip with this file tree : ├── images │   ├── compute.png │   ├── loadbalancer.png │   ├── network.png │   ├── objectstore.png │   ├── relational_db.png │   ├── root.png │   ├── router.png │   ├── software.png │   └── volume.png ├── normative-types.yml └── README.md Required types for Wordpress The Wordpress topology is using custom types, we have to upload them first. Find those types on github here : samples repository apache : the webserver here php : the php interperter here mysql : the database required by Wordpress here wordpress : the blog component here Zip the content of each folder like you did for normative types and upload each zipped file in this order. Wordpress topology In order to have an full application ready to deploy through Alien 4 Cloud, just download the yaml description of the topology here : Wordpress topology . When you have this file, zip it, then you will be able to import it into Alien 4 Cloud as an topology template . Find detailed informations about the wordpress topology here . 7. Create an Wordpress application: Now we have the Wordpress template ready to use, we can create an application based on it : The application creation should redirect you on the Application > Informations page. 8. Setup and deploy your application: To deploy this new application, just go on Applications > Deployments submenu. Zone A : Select an environment and a cloud Keep the default environment Environment and select your cloud OpenStackCloud created above. Zone B : Provider properties Those properties depends on the provider implementation. You usualy have default settings. Zone C : Topology required settings Those basic settings are required for Compute nodes. Zone D : Cloud resources matching In this part, you will be able to check matching cloud resources and possible matching errors. This should not happen if your cloud is well configured. 9. Check that your application is up and running: Runtime view On this submenu view Application > Runtime , you can have the detailed deployment progress. Wordpress url Go back in the Application > Informations submenu to get the Wordpress application url and test it ! And voilà ! "},{"title":"Getting started","baseurl":"","url":"/documentation/1.1.0/getting_started/getting_started.html","date":null,"categories":[],"body":"To begin with Alien you have two choices : the 30 min Start Guide! or the Step by step guide The first guide is like a demo, the best way if you want to try Alien in no time but you need an active AWS account. The second guide will explain how to take in charge Alien in details and configure it for your uses. Important: security issue Alien used a version of ElasticSearch concern by a security issue. To prevent an attack, make sure to secure the port of ES (9200 as default). 1. Prerequisites: Download and install VirtualBox (Working with version >= 4.3.26) Download and install Vagrant (Working with version >= 1.7.2) Install triggers plugin for Vagrant: vagrant plugin install vagrant-triggers (Working with version >= 0.5.0) An active AWS account. Make sure you have all the account informations we will need later (user key, access key, key file and key pair) 2. VM Automated Install: Download and unzip the package vm-alien4cloud-1.1.0-SM3 (for other version, see on the page footer). As a result, a subdirectory vm-alien4cloud should be created Copy your .pem file to the directory vm-alien4cloud/vm/key Edit the file vm-alien4cloud/puppet/manifests/install.pp and set your aws “user key” and “access key” ( user and apiKey parameters), key file name and key pair ( keyFile and keyPair parameters) and finally change machineNamePrefix and managementGroup . Change your working directory: cd vm-alien4cloud/vm/centos-6 Execute the following command to build a new VM: vagrant up At the first run, vagrant will download the base box which will be used to create the alien4cloud VM, then provision the VM with Puppet. The time needed to create a VM is around 30 minutes and depends on your internet connection speed. At the end of the installation, you’ll see a message ==> alien4cloud: Notice: Finished catalog run in 1648.89 seconds . You can then access Alien4Cloud Web interface from a browser on the following address: http://192.168.32.10:8088 . Use the default account admin with the password admin to login into Alien. 3. Deploy your application: To deploy this new application, go on Applications > Deployments submenu and : Select the os_arch of your computes Select your cloud Select the template who matches with your computers And click on the Deploy button To understand all configuration available for the deployment page, please refer to this section . 4. Check that your application is up and running: Runtime view: On this submenu view Application > Runtime , you can have the detailed deployment progress. Wordpress url When all nodes are deployed, go back in the Application > Informations submenu to get the Wordpress application url and test it ! And voilà ! 5. How to Uninstall: If you would like to de-provision the VM and the associated cloud created by Alien4Cloud, just execute the following commands: Change your working directory: cd vm-alien4cloud/vm/centos-6 Run the following command: vagrant destroy Older versions: vm-alien4cloud-1.1.0-SM2 1. Prerequisites: Ensure that you have at least JAVA version 7 or higher installed on your working station. If not, just install java following instructions here . You can get Cloudify in version 3.2 here . In order to start using alien 4 cloud you have to download Alien. Two versions are available : standalone : starts an embedded jetty server deployable : war file that can be deployed within a war container We recommend using the Alien standalone with Cloudify 3.2. 2. Check your access to a cloud: To try Alien 4 Cloud with provider plugin Cloudify 3.x you will need a cloud ready to use with your credentials. If not, we advice you to use trystack , a personal an free to use OpenStack. For this tutorial we recommend to use OpenStack. 3. Configure and start Cloudify: Please refer to those following sections : configure and start Cloudify 3 4. Start and configure Alien 4 Cloud : Assuming you have downloaded the standalone version in the prerequisite step you will only have to execute the following command in your shell : java -XX:MaxPermSize = 512m -jar alien4cloud-ui-VERSION-standalone.war --spring.profiles.active = security-demo The command option --spring.profiles.active=security-demo allows you to have Alien 4 Cloud started with default settings such as the default user admin we will use later. 5. Check that Alien4Cloud is working : After connecting via your browser (default port is 8088 on the machine hosting A4C), you should see the following Authentication splash screen 6. Install and configure provider plugin: In this step, you will have to import the provider plugin and then configure it. Refer to the following sections : Cloudify 3 plugin In our tutorial, let’s call the configured cloud OpenStackCloud . 7. Import components in Alien 4 Cloud: Regardless the used provider, read the following section to know how to import your components archive : import components Normative types The TOSCA specification used by Alien 4 Cloud is defining normative types . As a language, you can use those components as is or extend it to suit to your needs. You can find our implementation for these types on github here : normative types on github This download link will provide a zip with a subfolder. Ensure that this subfolder doest not exist or the component upload will fail. You must have a zip with this file tree : ├── images │   ├── compute.png │   ├── loadbalancer.png │   ├── network.png │   ├── objectstore.png │   ├── relational_db.png │   ├── root.png │   ├── router.png │   ├── software.png │   └── volume.png ├── normative-types.yml └── README.md Required types for Wordpress The Wordpress topology is using custom types, we have to upload them first. Find those types on github here : samples repository apache : the webserver here php : the php interperter here mysql : the database required by Wordpress here wordpress : the blog component here Zip the content of each folder like you did for normative types and upload each zipped file in this order. Wordpress topology In order to have an full application ready to deploy through Alien 4 Cloud, just download the yaml description of the topology here : Wordpress topology . When you have this file, zip it, then you will be able to import it into Alien 4 Cloud as an topology template . Find detailed informations about the wordpress topology here . 7. Create an Wordpress application: Now we have the Wordpress template ready to use, we can create an application based on it : The application creation should redirect you on the Application > Informations page. 8. Setup and deploy your application: To deploy this new application, go on Applications > Deployments submenu and : Select the os_arch of your computes Select your cloud Select the template who matches with your computers And click on the Deploy button To understand all configuration available for the deployment page, please refer to this section . In this part, you will be able to check matching cloud resources and possible matching errors. This should not happen if your cloud is well configured. If you need help to configure your cloud, please refer to this section . 9. Check that your application is up and running: Runtime view On this submenu view Application > Runtime , you can have the detailed deployment progress. Wordpress url When all nodes are deployed, go back in the Application > Informations submenu to get the Wordpress application url and test it ! And voilà ! "},{"title":"ALIEN 4 Cloud","baseurl":"","url":"/community/index.html","date":null,"categories":[],"body":" Twitter We are on on twitter , so feel free to follow us and get the latest news on Alien 4 Cloud. Source code ALIEN 4 Cloud is open source under the Apache 2 License. The code is hosted on GitHub . You are welcome to clone, fork and submit pull-requets. The documentation is also hosted on github and you can also help us to improve it. Slack If you need help now, or want to discuss matters in real time, join our public slack! Issues Issues and feature requests can be filled in directly on the project's GitHub issue management . "},{"title":"ALIEN 4 Cloud","baseurl":"","url":"/roadmap/index.html","date":null,"categories":[],"body":" Roadmap The following represents current view of Alien4Cloud development team of its product development cycle and future directions. It is intended for information purposes only, and should not be interpreted as a commitment, though we do our best to reach the dates and features set mentioned below. Premium features, support and certifications are available under a subscription, delivered by FastConnect , a Bull, Atos technologies subsidiary. Contact us for more details. We deliver 4 major releases per year. Please note that we also deliver intermediate sprint releases in Alien4Cloud GitHub repo , every 3 weeks, in order to get feedback on features while still in development. early Q3 2015 v 1.0.0 Core Dev & Ops Self-Service TOSCA Catalog TOSCA Import Export Applications Versions & Environments Pluggable UI H.A. Policies and Availability Zones support Maintenance mode trigger (based on orchestrator support) Audit Infrastructure and orchestrators certifications Cloudify v2 and v3.1 (compatible with Cloudify 3.2) Amazon OpenStack BYON Note: Almost all infrastructures and orchestrators, in the roadmap are already functional and some have been deployed, but we highlight here certification Artefacts support SH BAT Cloudify v2 groovy Note: Some artefacts are already working though not fully tested/supported TOSCA Simple profile in YAML support (Spec is still evolving so support of it is incremental within Alien4Cloud) Normative and extended types, topologies Groups and policies early Q4 2015 v 1.1.0 Core PaaSProvider v2 for increased platforms and policies support Pluggable Matching Algorithm SSH keys Management Git integration UI improvements Infrastructure and orchestrators certifications Cloudify v3.2 Artefacts support Python TOSCA Topology Substitution Improvements of Simple profile support based on spec evolutions Premium features Simplified startup and configuration v1.0 to v1.1 Migration tools early Q1 2016 v 1.2.0 Core Network support improvements Pluggable Location Matching H.A policies on single scalable nodes Infrastructure and orchestrators certifications Cloudify v3.3 Azure vCloud Artefacts support Puppet Chef TOSCA Simple profile in YAML v1 Premium features Governance Dashboards Catalog Portability Insights v1.1 to v1.2 Migration tools To be defined Future through Core Custom workflows Promotion workflow Infrastructure and orchestrators support & certifications Apache Brooklyn Docker (native) - already supported through partners orchestrators (cloudify / apache brooklyn), Kubernetes, Swarm/Machine Mesos (Marathon) Ambari Google Cloud OpenStack latest releases Premium features Workspaces TOSCA Types ui designer Simplified Self Service Artifact(s) Repositories Management If you want to propose other features and/or if you are willing to contribute, please contact us . "},{"title":"Cloudify 2 PaaS Provider","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/index.html","date":null,"categories":[],"body":"ALIEN allows, via the plugin mechanism, to provide extensions. An extension could be a driver to manage a specific cloud, rendering ALIEN to be able to perfom operations on the related cloud. This section gives a focus to Cloudify driver for ALIEN, a plugin to manage deployment on various cloud using the PaaS factory Cloudify . In this documentation, we will assume you have access to the GUI of a running instance of ALIEN 4 Cloud. Also, make sure you have the proper rights when needed. Start with the prerequisites . "},{"title":"Cloudify 3 PaaS Provider","baseurl":"","url":"/documentation/1.0.0/cloudify3_driver/index.html","date":null,"categories":[],"body":"This section gives a focus to Cloudify 3 driver for ALIEN, a plugin to manage deployment on various cloud using the PaaS factory Cloudify 3.x . In this documentation, we will assume you have access to the GUI of a running instance of ALIEN 4 Cloud. Also, make sure you have the proper rights when needed. Start with the prerequisites . "},{"title":"ALIEN 4 Cloud - 1.0.0 - Documentation","baseurl":"","url":"/documentation/1.0.0/index.html","date":null,"categories":[],"body":"Welcome on Alien 4 Cloud documentation. You will find here resources to use alien 4 cloud. This includes: Concepts of Alien 4 Cloud Installation and configuration Creation of cloud services archives (including an overview of OASIS TOSCA concepts) ALIEN for Cloud High level concept ALIEN for Cloud (Application LIfecycle ENabler for cloud) is a tool that aims to provide management for enterprise cloud and help enterprise to onboard their applications to a cloud, leverage it’s benefits and, based on project constraints, reach continuous delivery. As moving to the cloud for an enterprise is a structural change, ALIEN for Cloud leverage the TOSCA standard that is the most advanced and supported standard for the cloud. The Goal of ALIEN for Cloud is to enable the benefits of a cloud migration in enterprise by easing the DevOps collaboration taking in account the capabilities of each of the IT expert in the enterprise. This is done by providing a single platform where every expert can contribute and share it’s effort and feedback with others. ALIEN provides three main features: Composable PaaS & DevOps collaboration Application lifecycle enablement Cloud governance Collaboration Collaboration in ALIEN for cloud is done by giving the ability to each expert to work on it’s field of expertise, and for other experts to benefits from his work and reuse it in a simple and declarative way. TOSCA standard is a great start point to enable such collaboration. ALIEN for Cloud add user roles management in order to increase the ability to easily collaborate on the platform. Composable PaaS Topology definition in ALIEN for cloud The first aspect of ALIEN for cloud is related to the core of the cloud interoperability: defining an application topology that we can deploy on any cloud. It takes in account critical requirements for an enterprise: reusability extensibility flexibility consistency evolvability (Very) Quick introduction to TOSCA In the TOSCA model, an Application Topology is created by declaration of some components (nodes) instances (templates) based on some existing types. The types defines the meta-model of a component (properties, operations, capabilities and requirements) and it’s implementation artifacts. A TOSCA container can then deploy the declared topology on a cloud and orchestrated it. Collaboration in a TOSCA model is easy as someone that want’s to build an application topology can reuse components created by the experts. Typically an application architect will be able to reuse software and cloud components defined by the operational teams in the enterprise. Application lifecycle enablement Alien 4 Cloud allows users to define multiple versions and environments for an application, each environment has an associated version allowing you to move a version from a development environment to the production environment through all required environments in your lifecycle. Cloud governance As ALIEN for cloud manages the topologies of applications as well as their deployments, it keeps many informations that will enable governance of your cloud, a better vision of your applications, their lifecycle, the ability of your projects to deliver fast etc. It enables features like rationalisation of the SI capacity planning management of middleware support and expiration dates etc. "},{"title":"ALIEN 4 Cloud - 1.1.0 - Documentation","baseurl":"","url":"/documentation/1.1.0/index.html","date":null,"categories":[],"body":" This version is still in development Welcome on Alien 4 Cloud documentation. You will find here resources to use alien 4 cloud. This includes: Concepts of Alien 4 Cloud Installation and configuration Creation of cloud services archives (including an overview of OASIS TOSCA concepts) ALIEN for Cloud High level concept ALIEN for Cloud (Application LIfecycle ENabler for cloud) is a tool that aims to provide management for enterprise cloud and help enterprise to onboard their applications to a cloud, leverage it’s benefits and, based on project constraints, reach continuous delivery. As moving to the cloud for an enterprise is a structural change, ALIEN for Cloud leverage the TOSCA standard that is the most advanced and supported standard for the cloud. The Goal of ALIEN for Cloud is to enable the benefits of a cloud migration in enterprise by easing the DevOps collaboration taking in account the capabilities of each of the IT expert in the enterprise. This is done by providing a single platform where every expert can contribute and share it’s effort and feedback with others. ALIEN provides three main features: Composable PaaS & DevOps collaboration Application lifecycle enablement Cloud governance Collaboration Collaboration in ALIEN for cloud is done by giving the ability to each expert to work on it’s field of expertise, and for other experts to benefits from his work and reuse it in a simple and declarative way. TOSCA standard is a great start point to enable such collaboration. ALIEN for Cloud add user roles management in order to increase the ability to easily collaborate on the platform. Composable PaaS Topology definition in ALIEN for cloud The first aspect of ALIEN for cloud is related to the core of the cloud interoperability: defining an application topology that we can deploy on any cloud. It takes in account critical requirements for an enterprise: reusability extensibility flexibility consistency evolvability (Very) Quick introduction to TOSCA In the TOSCA model, an Application Topology is created by declaration of some components (nodes) instances (templates) based on some existing types. The types defines the meta-model of a component (properties, operations, capabilities and requirements) and it’s implementation artifacts. A TOSCA container can then deploy the declared topology on a cloud and orchestrated it. Collaboration in a TOSCA model is easy as someone that want’s to build an application topology can reuse components created by the experts. Typically an application architect will be able to reuse software and cloud components defined by the operational teams in the enterprise. Application lifecycle enablement Alien 4 Cloud allows users to define multiple versions and environments for an application, each environment has an associated version allowing you to move a version from a development environment to the production environment through all required environments in your lifecycle. Cloud governance As ALIEN for cloud manages the topologies of applications as well as their deployments, it keeps many informations that will enable governance of your cloud, a better vision of your applications, their lifecycle, the ability of your projects to deliver fast etc. It enables features like rationalisation of the SI capacity planning management of middleware support and expiration dates etc. "},{"title":"Developer Guide","baseurl":"","url":"/developer_guide/index.html","date":null,"categories":[],"body":"ALIEN has been designed to be easily extended and integrated with other systems. It uses a plugin mechanism in order to provide extensions, and the REST API makes it easy to integrate. The REST API documentation can be browsed directly on ALIEN’s server ( http://\\<alien-url\\>/api-doc/index.html , e.g. http://localhost:8088/api-doc/index.html ) and this section will not provides more details about it. This section gives a focus to ALIEN extensions through the plugin mechanism. In order to understand plugins it is important to know how ALIEN is designed and how plugins are managed by ALIEN. Mock plugin If you want to try out Alien 4 Cloud but not use a real cloud for deployments you can use the mock PaaS Provider plugin. This is a plugin that we use for our tests and that mock the PaaS orchestrator. The mock plugin does not allow you to test any of your components as it do not deploy anything or even call your scripts. To do so you should use a real PaaS Provider plugin like cloudify plugin and deploy on a local cloud technology like Virtua Box or Docker (note that docker support will come with support of cloudify 3). "},{"title":"Release Notes","baseurl":"","url":"/release_notes/index.html","date":null,"categories":[],"body":""},{"title":"Cloudify 3 PaaS Provider","baseurl":"","url":"/documentation/1.1.0/cloudify3_driver/index.html","date":null,"categories":[],"body":"This section gives a focus to Cloudify 3 driver for ALIEN, a plugin to manage deployment on various cloud using the PaaS factory Cloudify 3.x . In this documentation, we will assume you have access to the GUI of a running instance of ALIEN 4 Cloud. Also, make sure you have the proper rights when needed. Start with the prerequisites . "},{"title":"Administration Guide","baseurl":"","url":"/documentation/1.1.0/admin_guide/index.html","date":null,"categories":[],"body":"This section contains the guide for Alien 4 Cloud installation and configuration. Alien 4 Cloud requires orchestrator(s) in order to deploy on the configured clouds. Orchestrators plugins are currently not able to install the related orchestrator and deploy it on the runtime clouds. Important: security issue Alien used a version of ElasticSearch concern by a security issue. To prevent an attack, make sure to secure the port of ES (9200 as default). "},{"title":"Administration Guide","baseurl":"","url":"/documentation/1.0.0/admin_guide/index.html","date":null,"categories":[],"body":"This section contains the guide for Alien 4 Cloud installation and configuration. Alien 4 Cloud requires orchestrator(s) in order to deploy on the configured clouds. Orchestrators plugins are currently not able to install the related orchestrator and deploy it on the runtime clouds. "},{"title":"ALIEN 4 Cloud","baseurl":"","url":"/index.html","date":null,"categories":[],"body":" Application LIfecycle ENabler 4 Cloud application management on the cloud for enterprise. More about ALIEN for Cloud » Start in Less than 30 minutes! » Compose Create or reuse portable TOSCA blueprints and components. Leverage your existing shell, chef or puppet scripts. Collaborate Manage your deployments targets (clouds or byon), components, topologies, applications and deployments globally. Provide access to users to things they are interested in only and secure IT resources across the enterprise through a our rôle based portal. Deliver Integrate with multiple IaaS and PaaS technologies to deploy the same blueprints on any environment. Manage application lifecycle, environments and versions, build advanced flows to help reach continuous delivery. "},{"title":"Inputs and others variables","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/inputs_env_vars.html","date":null,"categories":[],"body":"Your implementations scripts can be defined with inputs. Find here how to properly define an input, and what other information is available in the execution environment. We will have for illustrations purposes a topology consisting of one Compute node, one Tomcat and two War nodes. input parameters Follow the parameter definition section for how to define your input parameters. The defined inputs are evaluated if needed at runtime, and set as environment variables. Thus, you can access them using their defined name. relationship type alien.relationships.cloudify.WarHostedOnTomcat , defined with a post_configure_source script:. alien.relationships.cloudify.WarHostedOnTomcat : [ ... ] interfaces : configure : post_configure_source : inputs : CONTEXT_PATH : { get_property : [ SOURCE , contextPath ] } TOMCAT_IP : { get_attribute : [ TARGET , ip_address ] } implementation : relationshipScripts/warHostedOnTomcat_post_configure_source.groovy [ ... ] The function concat is not supported on operation’s input parameter. And as consequence, you cannot use on input parameters, the get_attribute function referencing an attribute which value is a concat evaluation. Other available environment variables Prior to the inputs parameters, some useful informations are available in the script execution environment: Keyword Node Template Relationship Template Description Example SELF Yes No Node name . War, serveurWeb HOST Yes No Name of the node that “hosts” the current node. For node War: Tomcat SERVICE_NAME Yes No Cloudify service name in which the node related to the script is hosted (the root compute node name without spaces and in lowercase). for War and War_2: serveurweb SOURCE_NAME No Yes Node name of the source of the relationship. War, War_2 SOURCE No Yes Node id of the source of the relationship. The id is the node name without spaces and in lowercase, postfixed with the instance id War:(war_1 or war_2), War_2:(war_2_1 or war_2_2) SOURCE_SERVICE_NAME No Yes Cloudify service name in which the source node related to the relationship script is hosted (the root compute node name without spaces and in lowercase). for War and War_2: serveurweb SOURCES No Yes Comma-separated list of Node id of all the nodes currently the source of the relationship. war_1,war_2,war_n TARGET_NAME No Yes Same as SOURCE_NAME, but for the target. Tomcat TARGET No Yes Same as SOURCE, but for the target. tomcat_1 or tomcat_2 TARGET_SERVICE_NAME No Yes Cloudify service name in which the target node related to the relationship script is hosted (the compute nodeId). for Tomcat: serveurweb TARGETS No Yes Comma-separated list of Node id of all the nodes currently target of the relationship. tomcat_1,tomcat_2,tomcat_n When a node has some defined artifacts (overridable or not), their absolute location paths are available as environment variables ( their names ) of the operations scripts. Limitation : artifacts paths are not available when working with a relationship binding two nodes each on different compute. Relationships and get_attribute inputs the input TOMCAT_IP , as an environment variable that will hold the IP address of the target being processed will be provided to the warHostedOnTomcat_post_configure_source.groovy script. In addition, the IP addresses of all current tomcat members will be provided as environment variables with a naming scheme of tomcat_{instanceId}_TOMCAT_IP . Assuming that the aplication is deployed with 5 instances and the instance 5 is the current one, the following environment variables (plus potentially more variables) would be provided to the warHostedOnTomcat_post_configure_source.groovy script: TARGET = tomcat_5 TARGETS = tomcat_1 , tomcat_2 , tomcat_3 , tomcat_4 , tomcat_5 TOMCAT_IP = 10.0 . 0.5 tomcat_1_TOMCAT_IP = 10.0 . 0.1 tomcat_2_TOMCAT_IP = 10.0 . 0.2 tomcat_3_TOMCAT_IP = 10.0 . 0.3 tomcat_4_TOMCAT_IP = 10.0 . 0.4 tomcat_5_TOMCAT_IP = 10.0 . 0.5 Example Let see the example of the the node War_2: it has an overridable artifact named war_file alien.nodes.cloudify.War [...] artifacts : - war_file : warFiles/helloWorld.war type : alien.artifacts.WarFile [ ... ] This code snippet shows how to use inputs and others informations available in the execution environment of the relationship implementation script (groovy script): def context = ServiceContextFactory . getServiceContext () //printing the env vars println \"warHostedOnTomcat_post_configure_source<${SOURCE}> start.\" println \"warHostedOnTomcat_post_configure_source<${SOURCE}>: Inputs are:\" println \"contextPath : ${CONTEXT_PATH}; tomcatIp : ${TOMCAT_IP}\" println \"Target: ${TARGET}; Target_Service_Name: ${TARGET_SERVICE_NAME},\\n Source: ${SOURCE}, Source_Service_Name: ${SOURCE_SERVICE_NAME}\" println \"SOURCES: ${SOURCES}, TARGETS: ${TARGETS}\" println \"war_file Artifact path: ${war_file}\" //checking and using the war_file source artifact if (! war_file ) return \"war_file is null. So we do nothing.\" def command = \"${TARGET_NAME}_updateWarOnTomcat\" println \"warHostedOnTomcat_post_configure_source<${SOURCE}> invoking ${command} custom command on target tomcat...\" def service = context . waitForService ( TARGET_SERVICE_NAME , 60 , TimeUnit . SECONDS ) def currentInstance = service . getInstances (). find { it . instanceId == context . instanceId } currentInstance . invoke ( command , \"url=${war_file}\" as String , \"contextPath=${CONTEXT_PATH}\" as String ) println \"warHostedOnTomcat_post_configure_source<${SOURCE}> end\" return true Note that for groovy case, the inputs and others are set to the script binding, rather than into the execution environment. This makes them available by typing their names as if they where some groovy var already declared(ex: TOMCAT_IP, war_file). If you want to check the existence of any of them, just use the snippet: binding.variables.containsKey(env_var_name_to_check) . In sh case, access and use them as environment variables. "},{"title":"Installing and configuring","baseurl":"","url":"/documentation/1.1.0/cloudify3_driver/install_config.html","date":null,"categories":[],"body":"Find here how to install and configure the Cloudify 3 driver. Download First step of course is to download the plugin. last stable version works with the latest stable alien version. last build version works with the latest build alien version. Install The driver is packaged as an ALIEN plugin, install it in admin > plugins of your running instance of ALIEN. Configure You need to create a cloud and configure it. Creating the cloud Login as an admin, and create a cloud: admin > clouds > New Cloud . As PaaS provider for this cloud, make sure to select Cloudify 3 PaaS Provider from the list. Validate Configuring the cloud On the cloud list, select and click on the newly created cloud, then go to the configuration tab. Connection Configuration : Change the URL to use the correct IP of your manager that you obtained after the boostrap operation. You must save the configuration, switch back to the Details tab and enable the cloud by clicking on the Enable cloud button. Then you should go to Image tab to configure your cloud’s images. Images Configuration : Here you have to create/configure your cloud’s images. Map your cloud’s created image to the correct identifier on the IaaS (openstack, amazon …) You should now go to Flavor tab to configure your cloud’s flavors. Flavors Configuration : Here you have to create/configure your cloud’s flavors. Map your cloud’s created flavor to the correct identifier on the IaaS (openstack, amazon …) You should now go to Templates tab to see all your cloud’s compute templates. Templates Configuration : Here you can review available templates and disable those that you do not want to use. You should now go to Network tab to configure your cloud’s networks. Networks Configuration : Here you have to create/configure your cloud’s network templates. Map your cloud’s created network to the correct IaaS identifier if you want to reuse existing resource. You should configure an external network (pool of Floating IP) by setting the external network to true. After that, in order to assign a floating IP to a compute, you should connect the compute to a network that you’ll match to this external network. You can also configure application network template by setting the external network to false and providing the CIDR. You should now go to Block Storages tab to configure your cloud’s block storages. Block Storages Configuration : Here you have to create/configure your cloud’s block storage templates. Map your cloud’s created block storage to the correct IaaS identifier if you want to reuse existing resource. Congratulation!! You’ve finished to configure your cloudify3-based cloud. You can now begin to deploy your application with this cloud. "},{"title":"Installing and configuring","baseurl":"","url":"/documentation/1.0.0/cloudify3_driver/install_config.html","date":null,"categories":[],"body":"Find here how to install and configure the Cloudify 3 driver. Download First step of course is to download the plugin. 1.0.0 Install The driver is packaged as an ALIEN plugin, install it in admin > plugins of your running instance of ALIEN. Configure You need to create a cloud and configure it. Creating the cloud Login as an admin, and create a cloud: admin > clouds > New Cloud . As PaaS provider for this cloud, make sure to select Cloudify 3 PaaS Provider from the list. Validate Naming policy For this section, please look at the Cloudify 2 PaaS Provider . Configuring the cloud On the cloud list, select and click on the newly created cloud, then go to the configuration tab. Connection Configuration : Change the URL to use the correct IP of your manager that you obtained after the boostrap operation. You must save the configuration, switch back to the Details tab and enable the cloud by clicking on the Enable cloud button. Then you should go to Image tab to configure your cloud’s images. Images Configuration : Here you have to create/configure your cloud’s images. Map your cloud’s created image to the correct identifier on the IaaS (openstack, amazon …) You should now go to Flavor tab to configure your cloud’s flavors. Flavors Configuration : Here you have to create/configure your cloud’s flavors. Map your cloud’s created flavor to the correct identifier on the IaaS (openstack, amazon …) You should now go to Templates tab to see all your cloud’s compute templates. Templates Configuration : Here you can review available templates and disable those that you do not want to use. You should now go to Network tab to configure your cloud’s networks. Networks Configuration : Here you have to create/configure your cloud’s network templates. Map your cloud’s created network to the correct IaaS identifier if you want to reuse existing resource. You should configure an external network (pool of Floating IP) by setting the external network to true. After that, in order to assign a floating IP to a compute, you should connect the compute to a network that you’ll match to this external network. You can also configure application network template by setting the external network to false and providing the CIDR. You should now go to Block Storages tab to configure your cloud’s block storages. Block Storages Configuration : Here you have to create/configure your cloud’s block storage templates. Map your cloud’s created block storage to the correct IaaS identifier if you want to reuse existing resource. Congratulation!! You’ve finished to configure your cloudify3-based cloud. You can now begin to deploy your application with this cloud. "},{"title":"Installing and configuring","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/install_config.html","date":null,"categories":[],"body":"Find here how to install and configure the Cloudify 2 driver. Download First step of course is to download the plugin. 1.0.0 Install The driver is packaged as an ALIEN plugin, install it in admin > plugins of your running instance of ALIEN. Configure You need to create a cloud and configure it. Creating the cloud Login as an admin, and create a cloud: admin > clouds > New Cloud . As PaaS provider for this cloud, make sure to select Cloudify 2 PaaS Provider from the list. Validate Configuring the cloud On the cloud list, select and click on the newly created cloud, then go to the configuration tab. Connection Configuration : Remember the REST API URL you were told to note when bootstrapping your cloud with Cloudify, here is the place you’ll need it. Fill in one or more “Cloudify URL”, and eventually provide a login (username / password) for the access. You can also define the timeout to try all provided URL before declaring the configuration as not functional. When working with a manager bootstrapped in HA mode (two instances, thus two URL), you should know that when one instance is unavailable, the other one is accessible in read only mode. Then, you will not be able to undeploy installed applications or deploy another application, until both two managers are operational. Switch back to the Details tab and enable the cloud by clicking on the Enable cloud button. Then you should go to Image tab to configure your cloud’s images. Images Configuration : Here you have to create/configure your cloud’s images. Map your cloud’s created image to the correct identifier on the IaaS (openstack, amazon …) You should now go to Flavor tab to configure your cloud’s flavors. Flavors Configuration : Here you have to create/configure your cloud’s flavors. Map your cloud’s created flavor to the correct identifier on the IaaS (openstack, amazon …) You should now go to Templates tab to see all your cloud’s compute templates. Templates Configuration : Here you can review available templates and disable those that you do not want to use. You should now go to Network tab to configure your cloud’s networks. Networks Configuration : Here you have to create/configure your cloud’s network templates. Map your cloud’s created network to the correct identifier of Cloudify 2 (which is defined in the cloudify 2 cloud’s configuration) You must enter the PaaS Resource Id for all created network template or it will not be usable. The notion of external network is not necessary for cloudify 2, your cloudify 2 should be configured to auto-associate floating IP, so please set it to false. You should now go to Block Storages tab to configure your cloud’s block storages. Block Storages Configuration : Here you have to create/configure your cloud’s block storage templates. Map your cloud’s created block storage to the correct identifier of Cloudify 2 (which is defined in the cloudify 2 cloud’s configuration) You must enter the PaaS Resource Id for all created block storage template or it will not be usable. Availability zones Configuration : Here you have to create/configure your cloud’s availability zones. Map your cloud’s created zones to the correct identifier of Cloudify 2 (which is defined in the cloudify 2 cloud’s configuration) You must enter the PaaS Resource Id (the zone name in your IaaS) for all created zones or it will not be usable. NOTE : Make sure you have defined the related template for the couple template, (availability zone) in your cloudify 2. see customizing cloudify2 Congratulation!! You’ve finished to configure your cloudify2-based cloud. You can now begin to deploy your application with this cloud. "},{"title":"Installation and configuration","baseurl":"","url":"/documentation/1.1.0/admin_guide/installation_configuration.html","date":null,"categories":[],"body":" This section describe installation and configuration of Alien 4 Cloud for a production mode. If you whish to use Alien 4 Cloud for a demo or development mode please refer to the getting started guide. Important: security issue Alien 4 Cloud used a version of ElasticSearch concern by a security issue. To prevent an attack, make sure to secure the port of ES (9200 as default). Alien 4 Cloud configuration Alien 4 Cloud contains a basic configuration that is good enough for test environment. However in order to move into production or in order to integrate with other systems (as LDAP for example), you need to define an advanced configuration. In order to provide configuration to Alien 4 Cloud, you must place an Alien configuration file in a config folder along-side to the Alien 4 Cloud war. ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml You can find default configurations for both files in the GitHub repository: alien4cloud-config.yml elasticsearch.yml You can also add a simple start script: ├── start.sh ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml cd ` dirname $0 ` JAVA_OPTIONS = \"-server -showversion -XX:+AggressiveOpts -Xmx2g -Xms2g -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError\" java $JAVA_OPTIONS -jar alien4cloud-ui-1.1.0- { version } -standalone.war Logging configuration If you need to customize log4j (in order to activate some loggers, change the log file location …) add a log4j.properties in the config folder and specify the classpath for java : java $JAVA_OPTIONS -cp config/:alien4cloud-ui-1.1.0- { version } -standalone.war org.springframework.boot.loader.WarLauncher You can find a log4j sample configuration file at log4j.properties For example, to use Alien with the level debug, you need to replace the info keyword by debug in the second line. Audit configuration You can personalize the operations audit in it’s configuration page. You can select for each controller the rest method to monitor. "},{"title":"Installation and configuration","baseurl":"","url":"/documentation/1.0.0/admin_guide/installation_configuration.html","date":null,"categories":[],"body":"This section describe installation and configuration of Alien 4 Cloud for a production mode. If you whish to use Alien 4 Cloud for a demo or development mode please refer to the getting started guide. Important: security issue Alien 4 Cloud used a version of ElasticSearch concern by a security issue. To prevent an attack, make sure to secure the port of ES (9200 as default). Alien 4 Cloud configuration Alien 4 Cloud contains a basic configuration that is good enough for test environment. However in order to move into production or in order to integrate with other systems (as LDAP for example), you need to define an advanced configuration. In order to provide configuration to Alien 4 Cloud, you must place an Alien configuration file in a config folder along-side to the Alien 4 Cloud war. ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml You can find default configurations for both files in the GitHub repository: alien4cloud-config.yml elasticsearch.yml You can also add a simple start script: ├── start.sh ├── alien4cloud-ui- { version } -standalone.war ├── config/alien4cloud-config.yml ├── config/elasticsearch.yml cd ` dirname $0 ` JAVA_OPTIONS = \"-server -showversion -XX:+AggressiveOpts -Xmx2g -Xms2g -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError\" java $JAVA_OPTIONS -jar alien4cloud-ui-1.1.0- { version } -standalone.war Logging configuration If you need to customize log4j (in order to activate some loggers, change the log file location …) add a log4j.properties in the config folder and specify the classpath for java : java $JAVA_OPTIONS -cp config/:alien4cloud-ui-1.1.0- { version } -standalone.war org.springframework.boot.loader.WarLauncher You can find a log4j sample configuration file at log4j.properties For example, to use Alien with the level debug, you need to replace the info keyword by debug in the second line. Audit configuration You can personalize the operations audit in it’s configuration page. You can select for each controller the rest method to monitor. "},{"title":"Interface definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/interface_definition.html","date":null,"categories":[],"body":"An interface definition defines a named interface that can be associated with a Node or Relationship Type. Keynames Keyname Type Required Description inputs string no The optional list of input parameter definitions. description string no Alien 4 Cloud specific key to specify the description of the interface. Current implementation of Alien 4 Cloud doesn’t take in account inputs global to an interface but only inputs specified on opertions. Grammar <interface_definition_name> : inputs : <parameter_definitions> <operation_definition_1> ... <operation_definition_n> Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : interfaces : Standard : desciption : Normative interface that defines a node standard lifecycle. create : /scripts/install.sh configure : description : This is the configuration description. implementation : /scripts/setup.sh inputs : value_input : 4 "},{"title":"Interface definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/interface_definition.html","date":null,"categories":[],"body":"An interface definition defines a named interface that can be associated with a Node or Relationship Type. Keynames Keyname Type Required Description inputs string no The optional list of input parameter definitions. description string no Alien 4 Cloud specific key to specify the description of the interface. Current implementation of Alien 4 Cloud doesn’t take in account inputs global to an interface but only inputs specified on opertions. Grammar <interface_definition_name> : inputs : <parameter_definitions> <operation_definition_1> ... <operation_definition_n> Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : interfaces : Standard : desciption : Normative interface that defines a node standard lifecycle. create : /scripts/install.sh configure : description : This is the configuration description. implementation : /scripts/setup.sh inputs : value_input : 4 "},{"title":"ALIEN internal architecture","baseurl":"","url":"/developer_guide/internal-architecture.html","date":null,"categories":[],"body":"ALIEN is an AngularJS (front) + Spring (back) web-application. Plugins for ALIEN are managed as singular Spring applications context that all share the same parent context (ALIEN core application context). Each plugin uses it’s own classloader to ensure that they don’t collide with each others. Here also all of the plugin’s classloaders have a common parent classloader which is ALIEN’s core classloader. "},{"title":"LAMP Stack Tutorial","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack.html","date":null,"categories":[],"body":" This page is based on an old version and we are working on updating it. We will soon have this updated for 1.1.0 version. This tutorial is based on the well known opensource stack LAMP and aims at getting started with a “real application case”. We will see all steps to go through the stack component definition and have a runnable example. Regarding TOSCA component definition we are using the WD03 version for this tutorial. There is our full alien context to give a try to this tutorial : A4C element Usage TOSCA base types 1.0.0.WD03 A4C WD03 tosca-notmative-types A4C Release 1.0.0-SM18 Standalone WAR or WAR A4C Cloudify2 Driver 1.0.0-SM18 alien4cloud-cloudify2-provider 1.0.0-SM18 TOSCA base types Basicly to build our full application (topology), we will have a set of basic components defined in TOSCA. You will have to inject first this set of components in A4C and then inject your own. More details about normative types . TOSCA definition is in constant evolution, so be sure you are using our fixed implementation given just above. Our components We will basicly define our components and other “relational” items to link those components. This is the main component list : APACHE HTTP Server : http webserver to serve your website MySQL : relational datbase management system (RDBMS) PHP : server-side language used to interact with the database working with your html files This is the basic stack for a LAMP environment and in A4C context we will add one more components : Wordpress : this components will allow to install the Wordpress CMS on the Apache HTTP Server. Wordpress also need a PHP and a Mysql database. Server hosting The L in LAMP stand for Linux, so for our tutorial we assume that we’re working with Ubuntu 14.04 distribution as server. You must have an image on your targeted cloud based on it. We assume that you have an image in your cloud based on Ubuntu 12.04 or 14.04. BlockStorage To persist your data even after your application is undeployed, we will use this default component described in tosca base type wd02 and that allow us to have a volume created, mounted and attached to our server host. MySQL data will be stored on this volume. "},{"title":"LAMP Stack Tutorial","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack.html","date":null,"categories":[],"body":" This full stack application is still under construction / definition . You can follow it right now for a first jump into A4C but it will surely change in next weeks. We will enhance it trying to show the best way and the recommended granularity to target the best component reusability . This tutorial is based on the well known opensource stack LAMP and aims at getting started with a “real application case”. We will see all steps to go through the stack component definition and have a runnable example. Regarding TOSCA component definition we are using the WD03 version for this tutorial. There is our full alien context to give a try to this tutorial : A4C element Usage TOSCA base types 1.0.0.WD03 A4C WD03 tosca-notmative-types A4C Release 1.0.0-SM18 Standalone WAR or WAR A4C Cloudify2 Driver 1.0.0-SM18 alien4cloud-cloudify2-provider 1.0.0-SM18 TOSCA base types Basicly to build our full application (topology), we will have a set of basic components defined in TOSCA. You will have to inject first this set of components in A4C and then inject your own. More details about normative types . TOSCA definition is in constant evolution, so be sure you are using our fixed implementation given just above. Our components We will basicly define our components and other “relational” items to link those components. This is the main component list : APACHE HTTP Server : http webserver to serve your website MySQL : relational datbase management system (RDBMS) PHP : server-side language used to interact with the database working with your html files This is the basic stack for a LAMP environment and in A4C context we will add one more components : Wordpress : this components will allow to install the Wordpress CMS on the Apache HTTP Server. Wordpress also need a PHP and a Mysql database. Server hosting The L in LAMP stand for Linux, so for our tutorial we assume that we’re working with Ubuntu 14.04 distribution as server. You must have an image on your targeted cloud based on it. We assume that you have an image in your cloud based on Ubuntu 12.04 or 14.04. BlockStorage To persist your data even after your application is undeployed, we will use this default component described in tosca base type wd02 and that allow us to have a volume created, mounted and attached to our server host. MySQL data will be stored on this volume. "},{"title":"Component Apache HTTP","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_apache.html","date":null,"categories":[],"body":"Apache HTTP server is a free software of the Apache software Foundation, created in 1995. Apache is the most popular web server on internet and the web server of LAMP bundle. Used version for this tutorial : Apache HTTP Server Definition In the definitions folder, we need to write the TOSCA description of our component. It’s also a YAML file use to describe your component. The first line is the TOSCA definition version of the file. The second is a text description of the component. The tags icon is optional. Namming / description TOSCA assumes the existence of a normative base type set. The TOSCA type of Apache is the tosca.nodes.WebServer . Properties The Apache recipe has only two properties : Property Usage Comment version Mention the Apache HTTP Server version Constant version in our example (v2.4). port Port where to expose the Apache HTTP service The default port is : 80 . You can change it of course without using an already used one. document_root The Root Directory of apache2 The default value is : /var/www Lifecycle and related scripts In the interfaces we defined the script used to create the node. In our case we just use the create operation, see the documentation to see all possible operations. In the artifact, we define the folder that contains the script. As we are using Groovy artifact, we defined this artifact at the end of file. Operation Usage Comment create Executed script to install your apache http server on the Compute Through apt-get on ubuntu image start Start apache2 Restart apache2 if it’s already launched start_detection Detect if apache2 is running Test the port of apache2 Optional : To test this Apache recipe, you could create a simple Topology with a Compute and an Apache : With a well configured PaaS Provider , you will have an Apache HTTP Server deployed on a server and ready to use. "},{"title":"Component Apache HTTP","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_apache.html","date":null,"categories":[],"body":"Apache HTTP server is a free software of the Apache software Foundation, created in 1995. Apache is the most popular web server on internet and the web server of LAMP bundle. Used version for this tutorial : Apache HTTP Server Definition In the definitions folder, we need to write the TOSCA description of our component. It’s also a YAML file use to describe your component. The first line is the TOSCA definition version of the file. The second is a text description of the component. The tags icon is optional. Namming / description TOSCA assumes the existence of a normative base type set. The TOSCA type of Apache is the tosca.nodes.WebServer . Properties The Apache recipe has only two properties : Property Usage Comment version Mention the Apache HTTP Server version Constant version in our example (v2.4). port Port where to expose the Apache HTTP service The default port is : 80 . You can change it of course without using an already used one. document_root The Root Directory of apache2 The default value is : /var/www Lifecycle and related scripts In the interfaces we defined the script used to create the node. In our case we just use the create operation, see the documentation to see all possible operations. In the artifact, we define the folder that contains the script. As we are using Groovy artifact, we defined this artifact at the end of file. Operation Usage Comment create Executed script to install your apache http server on the Compute Through apt-get on ubuntu image start Start apache2 Restart apache2 if it’s already launched start_detection Detect if apache2 is running Test the port of apache2 Optional : To test this Apache recipe, you could create a simple Topology with a Compute and an Apache : With a well configured PaaS Provider , you will have an Apache HTTP Server deployed on a server and ready to use. "},{"title":"Stack Application Topology","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_application.html","date":null,"categories":[],"body":"On this page we will create our topology representing the LAMP stack. Follow instructions step by step and at the end you will have your stack up and running. To be more concret we will use the Wordpress component to install a real CMS. Prerequisites Get, checkout, download all components listed in the main page of this tutorial Import all components in A4C We assume that you are running the A4C you have downloaded in standalone version Once you are logged as admin , you will have the menu on top, select then the Components item You can also see here how to upload your component Configure your cloud plugin PaaS Provider Then compose you topology following the next steps Point 2 : on each page on the right top corner you have a button with a question mark [?]. Click to start a tour to explain what you can do in the current page and how to do it. Create the topology for the Wordpress application We have explained all components of our LAMP stack. Now, we will use these components to deploy a Wordpress on a cloud. To begin just for on Applications menu and create a New application then go on the application sub-menu Topology . You are now ready to compose you application. Let’s do it ! Step 1 : The Compute In this step, drag and drop a Compute into the topology design view. You need to specify two properties for this compute : os_arch : x86_64 os_type : linux Step 2 : The BlockStorage Now, drag and drop a BlockStorage into the view. Select it by click and then attach it the Compute in the right Properties tab. Make sure to select the relation attachment with 1..1 constraint. In these properties tab view, set also the size value to 1 (GB by default). Step 3 : Apache, MySQL, PHP Then, drag and drop a MySQL , a PHP and an Apache onto the Compute existing node. For each new node droped onto Compute you will have to decide a target for the HostedOn relationship (generally just check the relationship name and click Finish ). Change the default value of MySQL or Apache if you want a custom install. Step 4 : The Wordpress The last component to add is the Wordpress . Drag and drop it to the Apache and select the WordpressHostedOn relationship between Wordpress and Apache . After this, create the relationship between Wordpress and MySQL and between Wordpress and PHP . Deployment Now we can deploy our topology into the cloud we’ve defined in prerequisite. The Deploy button is accessible in the Application sub-menu Deployments . To configure your Wordpress at your first run, open your web browser and go to IP_SERVER/CONTEXT_PATH . To configure your Wordpress , specifically for the MySQL settings, be sure you enter the settings you defined in your MySQL configuration. To check you running application, go on application Runtime sub-menu an select the node you want. In the Details tab automatically selected, you just need to select the instance line you want to have more details like ip_address and public_ip_address an try you application. Here we can select the Compute node and get the public IP to run Wordpress for the first time and later. "},{"title":"Stack Application Topology","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_application.html","date":null,"categories":[],"body":"On this page we will create our topology representing the LAMP stack. Follow instructions step by step and at the end you will have your stack up and running. To be more concret we will use the Wordpress component to install a real CMS. Prerequisites Get, checkout, download all components listed in the main page of this tutorial Import all components in A4C We assume that you are running the A4C you have downloaded in standalone version Once you are logged as admin , you will have the menu on top, select then the Components item You can also see here how to upload your component Configure your cloud plugin PaaS Provider Then compose you topology following the next steps Point 2 : on each page on the right top corner you have a button with a question mark [?]. Click to start a tour to explain what you can do in the current page and how to do it. Create the topology for the Wordpress application We have explained all components of our LAMP stack. Now, we will use these components to deploy a Wordpress on a cloud. To begin just for on Applications menu and create a New application then go on the application sub-menu Topology . You are now ready to compose you application. Let’s do it ! Step 1 : The Compute In this step, drag and drop a Compute into the topology design view. You need to specify two properties for this compute : os_arch : x86_64 os_type : linux Step 2 : The BlockStorage Now, drag and drop a BlockStorage into the view. Select it by click and then attach it the Compute in the right Properties tab. Make sure to select the relation attachment with 1..1 constraint. In these properties tab view, set also the size value to 1 (GB by default). Step 3 : Apache, MySQL, PHP Then, drag and drop a MySQL , a PHP and an Apache onto the Compute existing node. For each new node droped onto Compute you will have to decide a target for the HostedOn relationship (generally just check the relationship name and click Finish ). Change the default value of MySQL or Apache if you want a custom install. Step 4 : The Wordpress The last component to add is the Wordpress . Drag and drop it to the Apache and select the WordpressHostedOn relationship between Wordpress and Apache . After this, create the relationship between Wordpress and MySQL and between Wordpress and PHP . Deployment Now we can deploy our topology into the cloud we’ve defined in prerequisite. The Deploy button is accessible in the Application sub-menu Deployments . To configure your Wordpress at your first run, open your web browser and go to IP_SERVER/CONTEXT_PATH . To configure your Wordpress , specifically for the MySQL settings, be sure you enter the settings you defined in your MySQL configuration. To check you running application, go on application Runtime sub-menu an select the node you want. In the Details tab automatically selected, you just need to select the instance line you want to have more details like ip_address and public_ip_address an try you application. Here we can select the Compute node and get the public IP to run Wordpress for the first time and later. "},{"title":"Component BlockStorage","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_blockstorage.html","date":null,"categories":[],"body":"This component represents a storage space / volume. This volume has to be attached to a compute to be used. For more details about this custom component : BlockStorage Used version for this tutorial (defined in normative types): BlockStorage Definition Namming / description Every component should at least inherite from tosca.nodes.Root . As a default normative type it’s the case for BlockStorage . Properties Check details : BlockStorage For the application you will need volume_id or size to be defined. Lifecycle and related scripts There is no lifecycle operation for this component in the default version. "},{"title":"Component BlockStorage","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_blockstorage.html","date":null,"categories":[],"body":"This component represents a storage space / volume. This volume has to be attached to a compute to be used. For more details about this custom component : BlockStorage Used version for this tutorial (defined in normative types): BlockStorage Definition Namming / description Every component should at least inherite from tosca.nodes.Root . As a default normative type it’s the case for BlockStorage . Properties Check details : BlockStorage For the application you will need volume_id or size to be defined. Lifecycle and related scripts There is no lifecycle operation for this component in the default version. "},{"title":"Component MySQL","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_mysql.html","date":null,"categories":[],"body":"This component will install the MySQL RDBMS on the host server. Used version for this tutorial : MySQL This installation is based on Ubuntu distribution with apt-get command. Definition Let’s describe important parts of this full MySQL definition description. Namming / description The node name is important since it’s unique. We follow this template in A4C recipe development : [organisation].nodes.Name tosca_simple_yaml_1_0_0_wd03 : version of tosca used in the definition, let it as is it for the moment Our node name / id : alien.nodes.Mysql The parent : tosca.nodes.Database It’s a good practice to inherit from a base type to create your own component when it’s possible. Here tosca.nodes.Database . Properties All properties required or optional to use the component. MySQL proper properties : Property Usage Comment port port number injected in the MySQL installation Default : 3306 storage_path path where the blockstorage is mounted in the compute Constant value with the Cloudify Driver version we use in this tutorial. All blockstorage attached to a compute will have this mounted volume. bind_address Allow remote access to your server Default : true Properties inherited from its parent : tosca.nodes.Database Here we are overriding those properties from parent component and we describe a database with a user we want to create at initialization. Property Usage Comment db_name Database name we want to create wordpress to match to our final application case db_user Name of the user who will have rights on this database This user will have all privileges on this dedicated database db_password Password for this user … Lifecycle and related scripts The real script you will run during you different component life steps. Two main steps here in operations bloc : Operation Usage Comment create Executed script to install MySQL on the server Through apt-get on you ubuntu image start Executed script to configure MySQL to use a specific storage path (the blockstorage) Configured and started with specific ubuntu hints (rights concerns) start_detection Detects if Mysql is started Test the port "},{"title":"Component MySQL","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_mysql.html","date":null,"categories":[],"body":"This component will install the MySQL RDBMS on the host server. Used version for this tutorial : MySQL This installation is based on Ubuntu distribution with apt-get command. Definition Let’s describe important parts of this full MySQL definition description. Namming / description The node name is important since it’s unique. We follow this template in A4C recipe development : [organisation].nodes.Name tosca_simple_yaml_1_0_0_wd03 : version of tosca used in the definition, let it as is it for the moment Our node name / id : alien.nodes.Mysql The parent : tosca.nodes.Database It’s a good practice to inherit from a base type to create your own component when it’s possible. Here tosca.nodes.Database . Properties All properties required or optional to use the component. MySQL proper properties : Property Usage Comment port port number injected in the MySQL installation Default : 3306 storage_path path where the blockstorage is mounted in the compute Constant value with the Cloudify Driver version we use in this tutorial. All blockstorage attached to a compute will have this mounted volume. bind_address Allow remote access to your server Default : true Properties inherited from its parent : tosca.nodes.Database Here we are overriding those properties from parent component and we describe a database with a user we want to create at initialization. Property Usage Comment db_name Database name we want to create wordpress to match to our final application case db_user Name of the user who will have rights on this database This user will have all privileges on this dedicated database db_password Password for this user … Lifecycle and related scripts The real script you will run during you different component life steps. Two main steps here in operations bloc : Operation Usage Comment create Executed script to install MySQL on the server Through apt-get on you ubuntu image start Executed script to configure MySQL to use a specific storage path (the blockstorage) Configured and started with specific ubuntu hints (rights concerns) start_detection Detects if Mysql is started Test the port "},{"title":"Component PHP","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_php.html","date":null,"categories":[],"body":"This component will install the PHP on the host server. Used version for this tutorial : PHP Definition PHP is the programming language of the LAMP stack, it’s a server-side scripting. On this page, we just explain the recipe of this component. Below, the header of the php-type : Properties The PHP recipe is not so complicated, it has only three properties. The first property is the version, like for Apache recipe, it’s just to be mentioned. The two other properties are booleans to install the PHP Apache 2 module or the PHP MySQL module. Property Usage Comment version Mention the php version Constant version in our example (v5) Lifecycle and related scripts PHP inherite from the tosca base type tosca.nodes.SoftwareComponent Operation Usage Comment create Executed script to install PHP on the Compute Through apt-get on ubuntu image "},{"title":"Component PHP","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_php.html","date":null,"categories":[],"body":"This component will install the PHP on the host server. Used version for this tutorial : PHP Definition PHP is the programming language of the LAMP stack, it’s a server-side scripting. On this page, we just explain the recipe of this component. Below, the header of the php-type : Properties The PHP recipe is not so complicated, it has only three properties. The first property is the version, like for Apache recipe, it’s just to be mentioned. The two other properties are booleans to install the PHP Apache 2 module or the PHP MySQL module. Property Usage Comment version Mention the php version Constant version in our example (v5) Lifecycle and related scripts PHP inherite from the tosca base type tosca.nodes.SoftwareComponent Operation Usage Comment create Executed script to install PHP on the Compute Through apt-get on ubuntu image "},{"title":"Component Wordpress","baseurl":"","url":"/documentation/1.1.0/devops_guide/lamp_stack_tutorial/lamp_stack_wordpress.html","date":null,"categories":[],"body":"Definition The Wordpress is a special component of our LAMP stack. This component will allow to take the last zip of Wordpress to be uploaded on the Apache HTTP Server to be deployed. Used version for this tutorial : Wordpress Properties Wordpress properties : Property Usage Comment context_path Name of folder into the default folder of apache2 Empty as default zip_url URL from where you download the application zip Default : https://wordpress.org/latest.zip Relationship and related scripts Relationship Usage Comment WordpressHostedOnApache Use to describe that the Wordpress is deployed on the targeted Apache server Through apt-get and unzip WordpressConnectToMysql Use to describe the connection between Wordpress and Mysql Set the conf of Mysql into config files of Wordpress WordpressConnectToPHP Use to describe the connection between Wordpress and PHP Install the PHP module for Apache2 To used Wordpress you need to upload the required recipes : Apache2 , Mysql and PHP . When you define a topology, make sure to select a WordpressHostedOn relation between Wordpress and Apache . "},{"title":"Component Wordpress","baseurl":"","url":"/documentation/1.0.0/devops_guide/lamp_stack_tutorial/lamp_stack_wordpress.html","date":null,"categories":[],"body":"Definition The Wordpress is a special component of our LAMP stack. This component will allow to take the last zip of Wordpress to be uploaded on the Apache HTTP Server to be deployed. Used version for this tutorial : Wordpress Properties Wordpress properties : Property Usage Comment context_path Name of folder into the default folder of apache2 Empty as default zip_url URL from where you download the application zip Default : https://wordpress.org/latest.zip Relationship and related scripts Relationship Usage Comment WordpressHostedOnApache Use to describe that the Wordpress is deployed on the targeted Apache server Through apt-get and unzip WordpressConnectToMysql Use to describe the connection between Wordpress and Mysql Set the conf of Mysql into config files of Wordpress WordpressConnectToPHP Use to describe the connection between Wordpress and PHP Install the PHP module for Apache2 To used Wordpress you need to upload the required recipes : Apache2 , Mysql and PHP . When you define a topology, make sure to select a WordpressHostedOn relation between Wordpress and Apache . "},{"title":"LDAP integration","baseurl":"","url":"/documentation/1.0.0/admin/ldap.html","date":null,"categories":[],"body":"Alien 4 Cloud can interface with an external LDAP server in order to retrieve users and perform authentication. When using an LDAP server, the Alien admin can still manage ‘local’ users inside Alien while LDAP users should be managed inside the LDAP repository. It is possible also to delegate global rôle management inside Alien even for LDAP users or to define a mapping from roles inside LDAP to roles within Alien. LDAP configuration In order to plug-in ALIEN to your LDAP repository, you must configure the ldap section of the alien4cloud-config.yml file. Enable LDAP Enabling ldap is as easy as updating the ldap configuration section and changing the enabled flag to true. ### Ldap Configuration ldap : enabled : true ... ### End Ldap Configuration Configure LDAP Server The first step in order to configure LDAP in Alien 4 Cloud is to configure the server parameters: Keynames Keyname Required Description anonymousReadOnly yes Some LDAP server setups allow anonymous read-only access. If you want to use anonymous Contexts for read-only operations, set the anonymousReadOnly property to true. url yes Url of the ldap server. userDn yes Dn of the user to use in order to connect to the LDAP server. password yes Password of the user to use in order to connect to the LDAP server. Example ldap : ... anonymousReadOnly : true url : ldap://ldap.fastconnect.fr:389 userDn : uid=admin,ou=system password : secret ... Configure users retrieval In order to retrieve users from the LDAP you must specify the base in which to look for users as well as an optional filter to retrieve only the users entries (and filter inactive if you have some for example). Keynames Keyname Required Description base yes The base in which to look for users within your LDAP filter yes A filter query to be processed by your LDAP server to filter users retrieved into Alien 4 Cloud. Example ldap : ... base : ou=People,dc=fastconnect,dc=fr filter : (&(objectClass=person)(!(objectClass=CalendarResource))(accountStatus=active)) ... Configure user mapping Now that you can retrieve users from LDAP it is critical to define a Mapping from your LDAP user entry attributes to Alien 4 Cloud properties for a user. Keynames Keyname Required Description mapping:   id: yes Name of the LDAP attribute that contains the unique id for the user within ldap that should be used as user’s login (username) within Alien 4 Cloud. mapping:   firstname: yes Name of the LDAP attribute that contains the user’s firstname mapping:   lastname: yes Name of the LDAP attribute that contains the user’s lastname mapping:   email: yes Name of the LDAP attribute that contains the user’s email mapping:   active:     key: no Name of the LDAP attribute that allows to know if a user is active. mapping:   active:     value: no Value of the LDAP attribute for which the user is considered as active. mapping:   roles:     defaults: yes Roles to use when importing a user when no rôle mapping is defined. Note: this roles are used only on user import. When no role mapping is defined the roles of users can be managed in Alien4Cloud. mapping:   roles:     key: no Name of the LDAP attribute that contains the user’s roles. If this key is not specified, user roles will be managed inside alien. Note: at import users will be created inside alien with the default roles. mapping:   roles:     key: no Mapping of a LDAP rôle to an ALIEN rôle. Note that it is not currently possible to map a single LDAP rôle to multiple Alien roles. ### Ldap Configuration ldap : ... mapping : id : uid firstname : givenName lastname : sn email : mail # optional mapping key and value to dertermine if the user is active active : key : accountStatus value : active roles : defaults : COMPONENTS_BROWSER # optional configuration for role mapping (when you want to manage roles in ldap and not in alien for ldap users). #key: description #mapping: ROLE_CLOUDADMINS=ADMIN,ROLE_CLOUDCOMPONENTS=COMPONENTS_MANAGER ### End Ldap Configuration Limitations and known issues Even when a user has roles managed in LDAP an Alien admin can edit it’s roles. However when the user will log-in the roles from LDAP will be reloaded into alien. Roles changed in LDAP will not appear in Alien as long as the User doesn’t log-in. "},{"title":"LDAP integration","baseurl":"","url":"/documentation/1.1.0/admin/ldap.html","date":null,"categories":[],"body":"Alien 4 Cloud can interface with an external LDAP server in order to retrieve users and perform authentication. When using an LDAP server, the Alien admin can still manage ‘local’ users inside Alien while LDAP users should be managed inside the LDAP repository. It is possible also to delegate global rôle management inside Alien even for LDAP users or to define a mapping from roles inside LDAP to roles within Alien. LDAP configuration In order to plug-in ALIEN to your LDAP repository, you must configure the ldap section of the alien4cloud-config.yml file. Enable LDAP Enabling ldap is as easy as updating the ldap configuration section and changing the enabled flag to true. ### Ldap Configuration ldap : enabled : true ... ### End Ldap Configuration Configure LDAP Server The first step in order to configure LDAP in Alien 4 Cloud is to configure the server parameters: Keynames Keyname Required Description anonymousReadOnly yes Some LDAP server setups allow anonymous read-only access. If you want to use anonymous Contexts for read-only operations, set the anonymousReadOnly property to true. url yes Url of the ldap server. userDn yes Dn of the user to use in order to connect to the LDAP server. password yes Password of the user to use in order to connect to the LDAP server. Example ldap : ... anonymousReadOnly : true url : ldap://ldap.fastconnect.fr:389 userDn : uid=admin,ou=system password : secret ... Configure users retrieval In order to retrieve users from the LDAP you must specify the base in which to look for users as well as an optional filter to retrieve only the users entries (and filter inactive if you have some for example). Keynames Keyname Required Description base yes The base in which to look for users within your LDAP filter yes A filter query to be processed by your LDAP server to filter users retrieved into Alien 4 Cloud. Example ldap : ... base : ou=People,dc=fastconnect,dc=fr filter : (&(objectClass=person)(!(objectClass=CalendarResource))(accountStatus=active)) ... Configure user mapping Now that you can retrieve users from LDAP it is critical to define a Mapping from your LDAP user entry attributes to Alien 4 Cloud properties for a user. Keynames Keyname Required Description mapping:   id: yes Name of the LDAP attribute that contains the unique id for the user within ldap that should be used as user’s login (username) within Alien 4 Cloud. mapping:   firstname: yes Name of the LDAP attribute that contains the user’s firstname mapping:   lastname: yes Name of the LDAP attribute that contains the user’s lastname mapping:   email: yes Name of the LDAP attribute that contains the user’s email mapping:   active:     key: no Name of the LDAP attribute that allows to know if a user is active. mapping:   active:     value: no Value of the LDAP attribute for which the user is considered as active. mapping:   roles:     defaults: yes Roles to use when importing a user when no rôle mapping is defined. Note: this roles are used only on user import. When no role mapping is defined the roles of users can be managed in Alien4Cloud. mapping:   roles:     key: no Name of the LDAP attribute that contains the user’s roles. If this key is not specified, user roles will be managed inside alien. Note: at import users will be created inside alien with the default roles. mapping:   roles:     key: no Mapping of a LDAP rôle to an ALIEN rôle. Note that it is not currently possible to map a single LDAP rôle to multiple Alien roles. ### Ldap Configuration ldap : ... mapping : id : uid firstname : givenName lastname : sn email : mail # optional mapping key and value to dertermine if the user is active active : key : accountStatus value : active roles : defaults : COMPONENTS_BROWSER # optional configuration for role mapping (when you want to manage roles in ldap and not in alien for ldap users). #key: description #mapping: ROLE_CLOUDADMINS=ADMIN,ROLE_CLOUDCOMPONENTS=COMPONENTS_MANAGER ### End Ldap Configuration Limitations and known issues Even when a user has roles managed in LDAP an Alien admin can edit it’s roles. However when the user will log-in the roles from LDAP will be reloaded into alien. Roles changed in LDAP will not appear in Alien as long as the User doesn’t log-in. "},{"title":"Lifecycles specifics for Cloudify","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/lifecycle_spec.html","date":null,"categories":[],"body":"There are some specifics concerning some lifecycle events when developing a Cloudify recipe for the ALIEN driver. Supported lifecycles events This provider does not yet support the implementation of all of the Cloudify livecycle events, but it is constantly evolving. The events supported are: Archive Interface operation Standard install (as create ), start , stop fastconnect.cloudify.extensions startDetection (as start_detection ), StopDetection (as stop_detection ), locator Note that the driver only supports groovy scripts for the fastconnect.cloudify.extensions interface’s operations. Also, you must be aware that the routine will be executed as a goovy closure. Therefore, you MUST NOT use the ServiceContextFactory class to get the service context, it has been injected automatically so that you can directly use it via the variable context . Example: interfaces : [ ... ] fastconnect.cloudify.extensions : start_detection : scripts/tomcat_startDetection.groovy stop_detection : scripts/tomcat_stopDetection.groovy locator : scripts/alien_tomcat_locator.groovy startDetection You can provide a start detection routine, and it should be written in a groovy file, and must return a boolean: True if the routine ended well, and false if not. The routine will be executed as a Cloudify closure, in the service descriptor file. Therefore, as stated in the Cloudify documentation, you shouldn’t use the ServiceContextFactory class to get the service context. The context has been injected automatically so that you can directly use it via the variable context . Example: def config = new ConfigSlurper (). parse ( new File ( \"${context.serviceDirectory}/scripts/tomcat-service.properties\" ). toURL ()) def result = ServiceUtils . arePortsOccupied ([ config . port , config . ajpPort ]) return result stopDetection Similar to the case of start detection, written in a groovy file, the stopDetection routine will be executed as a closure must and return a boolean value. Example: def config = new ConfigSlurper (). parse ( new File ( \"${context.serviceDirectory}/scripts/tomcat-service.properties\" ). toURL ()) def result = ServiceUtils . arePortsFree ([ config . port , config . ajpPort ]) return result Locators The locator allows you to specify the proccesses that Cloudify should monitor to determine if the application is stopped, and therefore perform some actions for the failover. Written in a groovy file, the locator will be executed as a closure, and must return a list of processes Pids to monitor. Example: import org.cloudifysource.dsl.utils.ServiceUtils def myPids = ServiceUtils . ProcessUtils . getPidsWithQuery ( \"State.Name.eq=java,Args.*.eq=org.apache.catalina.startup.Bootstrap\" ) return myPids "},{"title":"ALIEN data model","baseurl":"","url":"/developer_guide/model.html","date":null,"categories":[],"body":"The following schema details the model that is manipulated in Alien 4 Cloud and the relations between the different objects manipulated. From a code perspective we are working with denormalized schema and fetching related data should be done through dao queries when needed. From a performance perspective we don’t have critical requirements and plan to leverage caching mechanisms rather than implementing ORM solutions on top of ElasticSearch. ElasticSearch indices "},{"title":"Node template","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/node_template.html","date":null,"categories":[],"body":"A Node Template specifies the occurrence of a manageable software component as part of an application’s topology model which is defined in a TOSCA Service Template. A Node template is an instance of a specified Node Type and can provide customized properties, constraints or operations which override the defaults provided by its Node Type and its implementations. Keynames The following is the list of recognized keynames recognized for a TOSCA Node Template definition and parsed by Alien4Cloud: Keyname Required Description type yes The required name of the Node Type the Node Template is based upon. requirements no An optional sequenced list of requirement definitions for the Node Template. properties no An optional list of property values for the node template. capabilities no An optional map of capabilities for the node template. Grammar The overall structure of a TOSCA Node Template and its top-level key collations using the TOSCA Simple Profile is shown below: <node_template_name> : type : <node_type_name> properties : <property_definitions> requirements : <requirement_definitions> capabilities : <capability_definitions> type Represents the name of the Node Type the Node Template is based upon. This Node Type must be found in the archive itself or in the declared dependencies of the service template. requirements To define relationships between node templates, you can describe the requirements that points to targets’ capability. Named requirement definitions have one of the following grammars: short notation (node only) <requirement_name> : <template_name> When using this short notation: the must match to the name of the requirement in the type definition. the points to another node template in the topology template (relationship target). the type of the node template target must have a capability named like the requirement. Here is an example : topology_template : node_templates : compute : type : tosca.nodes.Compute apache : type : alien.nodes.Apache requirements : # the alien.nodes.Apache type defines a requirement named 'host' # the tosca.nodes.Compute type defines a capability named 'host' - host : compute short notation (with relationship or capability) In some situations, the short notation is not enough, for example when the capability name doesn’t match the requirement name (in this case, you must specify the capability type), or when you want to define relationship properties values. The following grammar would be used if either a relationship or capability is needed to describe the requirement: <requirement_name> : node : <template_name> capability : <capability_type> relationship : <relationship_type> In such notation the keywords are: Keyname Required Description node yes The relationship target node template name. capability yes The type of the target node type capability that should be used to build the relationship. relationship no Optionally, the name of the relationship type that should be used to build the relationship (if not defined in the requirement definition or must be specified). properties no An optional list of property values for the relationship (non TOSCA). In the following example, the relationship type is found in the requirement ‘database’ of the type alien.nodes.Wordpress. The capability is found by the specified type ‘alien.capabilities.MysqlDatabase’ : node_templates : wordpress : type : alien.nodes.Wordpress requirements : - host : apache - database : node : mysql capability : alien.capabilities.MysqlDatabase - php : node : php capability : alien.capabilities.PHPModule In the following example, the relationship is specified: node_templates : compute : type : tosca.nodes.Compute requirements : - network : node : network capability : tosca.capabilities.Connectivity relationship : tosca.relationships.Network network : type : tosca.nodes.Network properties The property values can either be: a scalar value a function: a reference to an input In the following example, 2 properties are defined for the node ‘compute1’ (1 referencing an input, and the other defined using a scalar value): topology_template : inputs : os_type : type : string constraints : - valid_values : [ \"linux\" , \"aix\" , \"mac os\" , \"windows\" ] description : The host Operating System (OS) type. node_templates : compute1 : type : tosca.nodes.Compute properties : os_type : { get_input : os_type } mem_size : 1024 capabilities In the following example, we define the value of the property ‘port’ for the capability named ‘database_endpoint’ of the node ‘mysql_database’: topology_template : node_templates : mysql_database : type : tosca.nodes.Database capabilities : database_endpoint : properties : port : 3306 Note that the property value can also be a get_input function: topology_template : inputs : mysql_port : type : string node_templates : mysql_database : type : tosca.nodes.Database capabilities : database_endpoint : properties : port : { get_input : mysql_port } "},{"title":"Node template","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/node_template.html","date":null,"categories":[],"body":"A Node Template specifies the occurrence of a manageable software component as part of an application’s topology model which is defined in a TOSCA Service Template. A Node template is an instance of a specified Node Type and can provide customized properties, constraints or operations which override the defaults provided by its Node Type and its implementations. Keynames The following is the list of recognized keynames recognized for a TOSCA Node Template definition and parsed by Alien4Cloud: Keyname Required Description type yes The required name of the Node Type the Node Template is based upon. requirements no An optional sequenced list of requirement definitions for the Node Template. properties no An optional list of property values for the node template. capabilities no An optional map of capabilities for the node template. Grammar The overall structure of a TOSCA Node Template and its top-level key collations using the TOSCA Simple Profile is shown below: <node_template_name> : type : <node_type_name> properties : <property_definitions> requirements : <requirement_definitions> capabilities : <capability_definitions> type Represents the name of the Node Type the Node Template is based upon. This Node Type must be found in the archive itself or in the declared dependencies of the service template. requirements To define relationships between node templates, you can describe the requirements that points to targets’ capability. Named requirement definitions have one of the following grammars: short notation (node only) <requirement_name> : <template_name> When using this short notation: the must match to the name of the requirement in the type definition. the points to another node template in the topology template (relationship target). the type of the node template target must have a capability named like the requirement. Here is an example : topology_template : node_templates : compute : type : tosca.nodes.Compute apache : type : alien.nodes.Apache requirements : # the alien.nodes.Apache type defines a requirement named 'host' # the tosca.nodes.Compute type defines a capability named 'host' - host : compute short notation (with relationship or capability) In some situations, the short notation is not enough, for example when the capability name doesn’t match the requirement name (in this case, you must specify the capability type), or when you want to define relationship properties values. The following grammar would be used if either a relationship or capability is needed to describe the requirement: <requirement_name> : node : <template_name> capability : <capability_type> relationship : <relationship_type> In such notation the keywords are: Keyname Required Description node yes The relationship target node template name. capability yes The type of the target node type capability that should be used to build the relationship. relationship no Optionally, the name of the relationship type that should be used to build the relationship (if not defined in the requirement definition or must be specified). properties no An optional list of property values for the relationship (non TOSCA). In the following example, the relationship type is found in the requirement ‘database’ of the type alien.nodes.Wordpress. The capability is found by the specified type ‘alien.capabilities.MysqlDatabase’ : node_templates : wordpress : type : alien.nodes.Wordpress requirements : - host : apache - database : node : mysql capability : alien.capabilities.MysqlDatabase - php : node : php capability : alien.capabilities.PHPModule In the following example, the relationship is specified: node_templates : compute : type : tosca.nodes.Compute requirements : - network : node : network capability : tosca.capabilities.Connectivity relationship : tosca.relationships.Network network : type : tosca.nodes.Network properties The property values can either be: a scalar value a function: a reference to an input In the following example, 2 properties are defined for the node ‘compute1’ (1 referencing an input, and the other defined using a scalar value): topology_template : inputs : os_type : type : string constraints : - valid_values : [ \"linux\" , \"aix\" , \"mac os\" , \"windows\" ] description : The host Operating System (OS) type. node_templates : compute1 : type : tosca.nodes.Compute properties : os_type : { get_input : os_type } mem_size : 1024 capabilities In the following example, we define the value of the property ‘port’ for the capability named ‘database_endpoint’ of the node ‘mysql_database’: topology_template : node_templates : mysql_database : type : tosca.nodes.Database capabilities : database_endpoint : properties : port : 3306 Note that the property value can also be a get_input function: topology_template : inputs : mysql_port : type : string node_templates : mysql_database : type : tosca.nodes.Database capabilities : database_endpoint : properties : port : { get_input : mysql_port } "},{"title":"Node type","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/node_type.html","date":null,"categories":[],"body":"A Node Type is a reusable entity that defines the type of one or more Node Templates. As such, a Node Type defines the structure of observable properties via a Properties Definition, the Requirements and Capabilities of the node as well as its supported interfaces. Keynames Keyname Type Required Description abstract* boolean no Optional flag to specify if a component is abstract and has no valid implementation. Defaults to false.  derived_from string no* An optional parent Relationship Type name the Relationship Type derives from. description string no An optional description for the Relationship Type. properties property definitions no An optional list of property definitions for the Relationship Type. attributes attribute definitions no An optional list of attribute definitions for the Relationship Type. requirements requirement definitions no An optional sequenced list of requirement definitions for the Node Type. capabilities capability definitions no An optional list of capability definitions for the Node Type. artifacts artifact definitions no An optional sequenced list of named artifact definitions for the Node Type. interfaces interface definitions no An optional list of named interfaces for the Relationship Type. Abstract flag is specific to Alien 4 Cloud and is not part of TOSCA Simple Profile in YAML. derived_from is not required however node types SHOULD all extends from a normative type (tosca.nodes.Root, tosca.nodes.SoftwareComponent etc.). Grammar <node_type_name> : derived_from : <parent_node_type_name> description : <node_type_description> properties : <property_definitions> attributes : <attribute_definitions> requirements : - <requirement_definition_1> ... - <requirement_definition_n> capabilities : <capability_definitions> interfaces : <interface_definitions> artifacts : <artifact_definitions> See: property_definitions attribute definitions requirement definitions capability definitions artifact definitions interface definitions Example my_company.my_types.my_app_node_type : derived_from : tosca.nodes.SoftwareComponent description : My company’s custom applicaton properties : my_app_password : type : string description : application password constraints : - min_length : 6 - max_length : 10 my_app_port : type : number description : application port number requirements : - host : tosca.nodes.Compute interfaces : [ Standard ] "},{"title":"Node type","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/node_type.html","date":null,"categories":[],"body":"A Node Type is a reusable entity that defines the type of one or more Node Templates. As such, a Node Type defines the structure of observable properties via a Properties Definition, the Requirements and Capabilities of the node as well as its supported interfaces. Keynames Keyname Type Required Description abstract* boolean no Optional flag to specify if a component is abstract and has no valid implementation. Defaults to false.  derived_from string no* An optional parent Relationship Type name the Relationship Type derives from. description string no An optional description for the Relationship Type. properties property definitions no An optional list of property definitions for the Relationship Type. attributes attribute definitions no An optional list of attribute definitions for the Relationship Type. requirements requirement definitions no An optional sequenced list of requirement definitions for the Node Type. capabilities capability definitions no An optional list of capability definitions for the Node Type. artifacts artifact definitions no An optional sequenced list of named artifact definitions for the Node Type. interfaces interface definitions no An optional list of named interfaces for the Relationship Type. Abstract flag is specific to Alien 4 Cloud and is not part of TOSCA Simple Profile in YAML. derived_from is not required however node types SHOULD all extends from a normative type (tosca.nodes.Root, tosca.nodes.SoftwareComponent etc.). Grammar <node_type_name> : derived_from : <parent_node_type_name> description : <node_type_description> properties : <property_definitions> attributes : <attribute_definitions> requirements : - <requirement_definition_1> ... - <requirement_definition_n> capabilities : <capability_definitions> interfaces : <interface_definitions> artifacts : <artifact_definitions> See: property_definitions attribute definitions requirement definitions capability definitions artifact definitions interface definitions Example my_company.my_types.my_app_node_type : derived_from : tosca.nodes.SoftwareComponent description : My company’s custom applicaton properties : my_app_password : type : string description : application password constraints : - min_length : 6 - max_length : 10 my_app_port : type : number description : application port number requirements : - host : tosca.nodes.Compute interfaces : [ Standard ] "},{"title":"Operation definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/operation_definition.html","date":null,"categories":[],"body":"An operation definition defines a named function or procedure that can be bound to an implementation artifact (e.g., a script). Keynames Keyname Type Required Description description string no The optional description string for the associated named operation. implementation string no The optional implementation artifact name (e.g., a script file name within a TOSCA CSAR file). inputs string no The optional list of input parameter definitions. Grammar <operation_name> : description : <operation_description> implementation : <implementation_artifact_name> inputs : <parameter_definition> In addition, the following simplified grammar may also be used (where a full definition is not necessary): <operation_name> : <implementation_artifact_name> implementation_artifact_name must be the path to a file and is resolved starting from the archive root. The artifact must be related to an artifact type. The way artifacts are related to artifact types is based on the implementation artifact name extension. This refers directly to the artifact types file_ext property that may have been defined. If no artifact type matches the extension Alien 4 Cloud will not allow parsing of the artifact. Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : interfaces : Standard : create : /scripts/install.sh configure : description : This is the configuration description. implementation : /scripts/setup.sh inputs : value_input : 4 "},{"title":"Operation definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/operation_definition.html","date":null,"categories":[],"body":"An operation definition defines a named function or procedure that can be bound to an implementation artifact (e.g., a script). Keynames Keyname Type Required Description description string no The optional description string for the associated named operation. implementation string no The optional implementation artifact name (e.g., a script file name within a TOSCA CSAR file). inputs string no The optional list of input parameter definitions. Grammar <operation_name> : description : <operation_description> implementation : <implementation_artifact_name> inputs : <parameter_definition> In addition, the following simplified grammar may also be used (where a full definition is not necessary): <operation_name> : <implementation_artifact_name> implementation_artifact_name must be the path to a file and is resolved starting from the archive root. The artifact must be related to an artifact type. The way artifacts are related to artifact types is based on the implementation artifact name extension. This refers directly to the artifact types file_ext property that may have been defined. If no artifact type matches the extension Alien 4 Cloud will not allow parsing of the artifact. Example The following example shows how to define a node type with operation: node_types : fastconnect.nodes.OperationSample : interfaces : Standard : create : /scripts/install.sh configure : description : This is the configuration description. implementation : /scripts/setup.sh inputs : value_input : 4 "},{"title":"Operations outputs","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/operation_outputs.html","date":null,"categories":[],"body":"Operations can also expose values at the end of their execution, called outputs. According to TOSCA norm, these so called operations outputs should be exposed as environment variables by the implementation script of the related operation. Export the output Export the outputs as environment variable using the good way depending on the file type. For shell : export OUTPUT_NAME = \"value\" For bat/cmd : set OUTPUT_NAME = \"value\" For groovy : Here we will export it as a property, as there is no way to modify environment in this case OUTPUT_NAME = \"value\" // or setProperty ( \"OUTPUT_NAME\" , \"value\" ) // //but definitely NOT def OUTPUT_NAME = \"value\" //this will create a local variable instead There is a known limitation: some characters are not supported in the output value: \",\" , \"=\", [space] . Use the output see get_operation_output for more details. Be aware that use of the get_operation_output function on relationships operations add[remove]_source[target] input parameters might result with null or wrong computed inputs values. The best practice would be to define an attribute on the node that will hold the useful output, and then using it as an input for the relationships operation with get_attribute function. </br> On the other side, the usage on the node template interfaces operations is fully supported. "},{"title":"Orchestrator plugins","baseurl":"","url":"/developer_guide/orchestrator_plugins.html","date":null,"categories":[],"body":"Orchestrator plugins are used to effectively deploy topologies on location(s) through the orchestrator technology backed up by the plugin. TODO Interface to implement TODO Orchestrator and Locations Writing a plugin requires to be familiar with Alien 4 Cloud concepts. As you know an orchestrator instance in alien 4 cloud is supposed to connect to an orchestrator engine. This orchestrator engine may be able to support deployments on one or multiple locations. Some orchestrator implementations like the current cloudify implementation can only manage an deploy to a single location. Some other like brooklyn allows the configuration of multiple locations for a single orchestrator. Every location has a location type, the plugin is responsible for exposing the different supported types. This is done by implementing the plugin interface method TODO Method to be implemented TODO Definition of supported types. The plugin may support normative types or just support it’s own specific types. If so it won’t be able to deploy TOSCA topologies but only specific topologies that will loose the portability of the normative TOSCA. As specified a plugin may supports it’s own types, a subset of TOSCA or the full TOSCA normative types. In any case the plugin is responsible to declare the supported types. "},{"title":"Orchestrators and locations","baseurl":"","url":"/documentation/1.1.0/concepts/orchestrators_locations.html","date":null,"categories":[],"body":"Orchestrator and locations are the fundamental concepts that allows alien 4 cloud to bring deployment’s portability across various technologies (orchestrators) and targets (locations). Orchestrators An orchestrator is a deployment technology that will orchestrate (and eventually maintain) the deployment and undeployment of a topology. There is various orchestrators on the market and Alien 4 Cloud can easily integrate with them through a plugin mechanism. Every deployment in alien 4 cloud is done through an orchestrator on a Location configured for and managed by an orchestrator . Locations In Alien 4 Cloud every deployment is done on what we call a Location . Locations are used to describe a logical deployment target that offers a set of resources (e.g. machines, storage, network, firewalls etc.). A location may refer to a cloud , to a specific tenant on a cloud , to a set of physical machines (BYON), or even docker containers. For example a location can refer to an Amazon configuration using a specific account while another location could be configured to work on a specific Tenant on an OpenStack cloud. To make it simple a location is a logical set of available resources that Alien 4 Cloud can use to deploy applications. In order to do so A4C relies on orchestration technologies that are easily pluggable. You can create and configure as many locations as you like to have as many deployment targets (environments) as required. Location’s supported resources As we stated a location may refer to some very different targets from clouds to containers or physical machines. This means that you may have differences in the resources supported by theses locations. More the configuration of this resources may not be the same from one location to another. Alien 4 Cloud has been designed to allow portability of a given application or to be precise to a given topology to deploy. However we never wanted to limit the user because of portability. The location’s defined resources are there exactly for this purpose. Every location now exposes their own and specific definitions of the generic components (or nodes) that lies into TOSCA. They can also expose some components that are not at all in relation with the normative nodes so people can choose to create non-portable topologies if they feel that they will get more benefits from it that portability. We really wanted in 1.1.0 to provide user with flexibility and ability to benefits from the best of orchestrator technologies. Note We are currently supporting the opensource orchestrators cloudify 3 but are also working in collaboration with Apache Brooklyn on an orchestration plugin currently in incubation state. Role and security Only a user with the global ADMIN role can define, configure, enable and grant deployment role to other users or groups on a locations. To find more on locations and how to configure them in Alien 4 Cloud please look at the Getting started guide if you don’t already have an Alien instance running and at the cloud setup guide in order to learn cloud configuration. "},{"title":"Other specifics interfaces","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/other_interfaces.html","date":null,"categories":[],"body":"Here are informations concerning some specific interfaces. custom interface Note that the driver only supports groovy scripts for this interface’s operations. Also, you must be aware that the routine will be executed as a goovy closure. Therefore, you MUST NOT use the ServiceContextFactory class to get the service context, it has been injected automatically so that you can directly use it via the variable context . Cloudify allows user to interact with their deployment via custom commands. This interface is design to support custom commands, in form of operations. Example: alien.nodes.cloudify.Tomcar [...] interfaces : [ ... ] custom : updateWarOnTomcat : inputs : catalinaBase : { get_attribute : [ SELF , catalinaBase ] } installDir : { get_attribute : [ SELF , installDir ] } url : type : string required : true contextPath : type : string required : true implementation : scripts/updateWarOnTomcat.groovy alien.nodes.cloudify.War [ ... ] interfaces : [ ... ] custom : updateWarFile : inputs : contextPath : { get_property : [ SELF , contextPath ] } warUrl : type : string description : url of the war to upload to update the current one required : true implementation : warScripts/updateWarFile.groovy Example of custom command scripts: alien.nodes.cloudify.War updateWarFile: assert warUrl && ! warUrl . trim (). isEmpty (), \"requires warUrl parameter\" //when invoking a command defined in another node, prefix it with his name. Here, War is hosted on Tomcat, thus the HOST env var has the Tomcat node name. def command = \"${HOST}_updateWarOnTomcat\" println \"updateWarFile.groovy: warUrl is ${warUrl} and contextPath is ${contextPath}...\" println \"updateWarFile.groovy: invoking ${command} custom command ...\" //SERVICE_NAME env var represent the cloudify service name def service = context . waitForService ( SERVICE_NAME , 60 , TimeUnit . SECONDS ) def currentInstance = service . getInstances (). find { it . instanceId == context . instanceId } //as the inputs are no more accessible via args[], but rather named and available in the env var, we should trigger the custom command with a \"name=value\" instead of \"value\" argument syntax currentInstance . invoke ( command , \"url=${warUrl}\" as String , \"contextPath=${contextPath}\" as String ) return \"war updated.\" "},{"title":"Rest API","baseurl":"","url":"/documentation/1.1.0/rest/overview.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-audit-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-audit-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-metaproperties-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-metaproperties-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-orchestrator-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-orchestrator-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-plugin-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-plugin-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"admin-user-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_admin-user-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"applications-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_applications-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"components-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_components-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"other-apis","baseurl":"","url":"/documentation/1.1.0/rest/overview_other-apis.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"topology-editor-api","baseurl":"","url":"/documentation/1.1.0/rest/overview_topology-editor-api.html","date":null,"categories":[],"body":"ALIEN 4 Cloud API Overview This section contains documentation of Alien 4 Cloud REST API. Version information Version: 1.1.0 "},{"title":"Parameter definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/parameter_definition.html","date":null,"categories":[],"body":"A parameter definition is map used to declare a name for a parameter along with its value to be used as inputs for operations. This value can either be a fixed value or one that is evaluated from a function or expression. Alien 4 Cloud allow users to specify also a property definition as the parameter value. This is possible only for operations that are not part of the automatic lifecycle but that will be triggered upon user request. Grammar <parameter_name> : <value> | <function_definition> See function_definition . For Alien 4 Cloud property definition syntax support you can refer to the property_definition page . Example node_types : fastconnect.nodes.PropertiesSample : interfaces : custom : do_something : inputs : value_input : 4 function_input : { get_property : [ my_host , mem_size ] } property_input : type : string description : An input that will have to be provided on operation call. constraints : - min_length : 4 - max_length : 8 "},{"title":"Parameter definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/parameter_definition.html","date":null,"categories":[],"body":"A parameter definition is map used to declare a name for a parameter along with its value to be used as inputs for operations. This value can either be a fixed value or one that is evaluated from a function or expression. Alien 4 Cloud allow users to specify also a property definition as the parameter value. This is possible only for operations that are not part of the automatic lifecycle but that will be triggered upon user request. Grammar <parameter_name> : <value> | <function_definition> See function_definition . For Alien 4 Cloud property definition syntax support you can refer to the property_definition page . Example node_types : fastconnect.nodes.PropertiesSample : interfaces : custom : do_something : inputs : value_input : 4 function_input : { get_property : [ my_host , mem_size ] } property_input : type : string description : An input that will have to be provided on operation call. constraints : - min_length : 4 - max_length : 8 "},{"title":"ALIEN plugins","baseurl":"","url":"/developer_guide/plugin.html","date":null,"categories":[],"body":"Alien 4 Cloud allows developer to extends the application by adding plugins. Actually most of features in a4c are packaged as plugins allowing a great flexibility in the way we build the application. A plugin may contains some java services, some REST controllers and UI elements. Directory hierarchy s ALIEN plugins are package as a zip archive that must contains the following hierarchy: The root folder contains java classes and resources (basically it will be added to the classpath of the plugin). The lib folder (optional) must contain all java archives (jar) required for the plugin to run. They will be added to the plugin classloader. Of course you should not add ALIEN 4 cloud jars here as they will be loaded through the plugin parent classloader. META-INF/plugin.yml contains the plugin description and entry point informations (the plugin descriptor). The ui folder contains all ui elements including javascript files, css html and any other static files. The plugin descriptor The plugin descriptor is mandatory and is the entry point of the plugin for ALIEN. As many other configuration elements it is a YAML file that allows to describe your plugin. grammar As detailed in the architecture section, a ALIEN plugin is actually a Spring sub-context; As so it requires a Spring context configuration entry point. For ALIEN plugins we have decided to allow only java based configuration and thus a plugin must specify a configuration class in it’s descriptor. The configuration class is the only mandatory class in a plugin so it can be loaded by ALIEN. example Plugin context entry point As described higher, a plugin in ALIEN is a spring context that inherits from ALIEN context. This allows you to build plugin that have full access to the repository or any other component in ALIEN. When loading a plugin, ALIEN for cloud will create the spring context based on the spring java configuration class defined in the plugin descriptor. It will then lookup the spring context for plugin beans matching one of a supported plugin type (like a bean that implements IPaaSProvider for example). Below is an example of a plugin spring context java configuration that acts as an entry point for the cloudify plugin. @Configuration @ComponentScan ( \"alien.paas.cloudify\" ) @ImportResource ( \"classpath:properties-config.xml\" ) public class PluginContextConfiguration { } Plugin configuration ALIEN provides an easy way to configure a plugin by generating the UI based on a configuration object using introspection. It also manages persistency of the configuration. In order to enable plugin configuration, one of the bean in your spring context must implements the IPluginConfigurator interface. This interface (see signature below) allow to provide a POJO that will act as the configuration object for the whole plugin. /** Interface for plugin configuration objects. */ public interface IPluginConfigurator < T > { /** * Get an instance of T that is the default configuration object of the plugin. * * @return A configuration object of type T. */ T getDefaultConfiguration (); /** * Set / apply a configuration for a plugin. * * @param configuration The configuration object as edited by the user. */ void setConfiguration ( T configuration ); } Current version of ALIEN 4 Cloud does not supports more than a single configuration. Thus you should make sure that a single IPluginConfigurator exists in your plugin spring context. "},{"title":"Plugin(s) management","baseurl":"","url":"/documentation/1.0.0/user_guide/plugin_management.html","date":null,"categories":[],"body":" Plugins provides some additional functionalities to Alien 4 Cloud. We currently support paas provider plugins (orchestrators interface with Alien 4 Cloud) but aims to provide much more plugins with various functionalities and even UI components. PaaS Providers (Orchestrators) Alien 4 Cloud is not managing actual runtime state of deployments by itself. In order to do so it delegates runtime to orchestrators, as well refered in Alien 4 Cloud as PaaS Providers . A PaaS Provider in A4C is a plugin that will be associated with Clouds . It is possible of course to have multiple clouds using the same PaaS Provider as well a multiple clouds with different PaaS Providers. We currently support Cloudify 2 and Cloudify 3 orchestrators as PaaS Providers. Cloudify 3 is recommended for new projects while we still recommends using Cloudify 2 as long as the version 3.2 is not released and supported in Alien 4 Cloud. Installing plugin in Alien 4 Cloud Drag you archive file > Drop it on the dash dotted area Click on [Upload plugin] > Select your archive (The file is automaticly uploaded) Plugin configuration Some plugins may requires specific configuration that is global to the plugin. In case a plugin can be configured you will see the following icon : Advanced plugins configurations The configuration detailed in the previous section is global for the plugin. Some plugins may requires some specific configurations that you can find at other places in the application. Your should refer to the plugin specific documentation to know more about it. For example, PaaS providers plugins actually are able to manage multiple instances of orchestrators, the specific configuration for each instance is managed at the cloud level. Plugin creation If you want to create new plugins for Alien 4 Cloud please refer to the developer guide . "},{"title":"Plugin(s) management","baseurl":"","url":"/documentation/1.1.0/user_guide/plugin_management.html","date":null,"categories":[],"body":" Plugins provides some additional functionalities to Alien 4 Cloud. We currently support paas provider plugins (orchestrators interface with Alien 4 Cloud) but aims to provide much more plugins with various functionalities and even UI components. PaaS Providers (Orchestrators) Alien 4 Cloud is not managing actual runtime state of deployments by itself. In order to do so it delegates runtime to orchestrators, as well refered in Alien 4 Cloud as PaaS Providers . A PaaS Provider in A4C is a plugin that will be associated with Clouds . It is possible of course to have multiple clouds using the same PaaS Provider as well a multiple clouds with different PaaS Providers. We currently support Cloudify 3 orchestrators as PaaS Providers. Installing plugin in Alien 4 Cloud Drag you archive file > Drop it on the dash dotted area Click on [Upload plugin] > Select your archive (The file is automaticly uploaded) Plugin configuration Some plugins may requires specific configuration that is global to the plugin. In case a plugin can be configured you will see the following icon : Advanced plugins configurations The configuration detailed in the previous section is global for the plugin. Some plugins may requires some specific configurations that you can find at other places in the application. Your should refer to the plugin specific documentation to know more about it. For example, PaaS providers plugins actually are able to manage multiple instances of orchestrators, the specific configuration for each instance is managed at the cloud level. Plugin creation If you want to create new plugins for Alien 4 Cloud please refer to the developer guide . "},{"title":"Plugins Management","baseurl":"","url":"/admin_guide/plugins.html","date":null,"categories":[],"body":"This section details Alien 4 Cloud’s Plugins management. For more information about what is a plugin, please see ALIEN plugins How to navigate to Plugins Management view Log in with admin credentials > Click on your user’s name on the right top corner > Click on drop-down link Plugins . You’ll arrive to the plugins management view, for the moment the page is empty as you haven’t uploaded any plugin yet. Empty plugins management view Upload a new plugin Drag plugin archive into the below dash dotted area. For browser which does not support drag & drop feature, you’ll see a button instead to choose the archive to upload. Once plugin uploaded, you’ll be able to see it in the browser. Plugins list Id : unique identifier of the plugin Version : version of the plugin Name : name of the plugin Description : the plugin’s description Enabled : indicate if the plugin is available for deployment Plugin managements Actions available to manage plugins can be found in the button group on the right hand side : delete, disable, configure. When you hover the mouse cursor on these buttons you’ll have tooltips explaining their functionality. Delete Click on the button below to delete the plugin. All related resources to the plugin will be cleaned up. Disable Click on the button below to disable a plugin. The plugin resource will not be cleaned up, this action will just make the plugin unavailable for deployment, you can always re-enable the plugin later. Click again on the button to enable the plugin. Configure Click on the button below to open configuration modal dialog. You can begin to edit the plugin configuration Plugin configure action This view is specific to each plugin, the above image is just a mock. For more information on how to configure your plugin, please refer to the specific section concerning your plugin. "},{"title":"Policy","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/policy.html","date":null,"categories":[],"body":"A policy applies on a group of nodes in a topology template. Only one policy type is currently supported in A4C : tosca.policy.ha This policy is not described by TOSCA (policies are actually a WIP). We have defined this one to support high availability features. Keynames The following is the list of recognized keynames recognized for a TOSCA Policy definition and parsed by Alien4Cloud: Keyname Required Description name yes The required name of the policy. type yes The type of the policy. Several notation are availables to express policy. Standard Grammar name : <policy_name> type : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - name : my_scaling_ha_policy type : tosca.policy.ha Shortcut Grammar <policy_name> : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - my_scaling_ha_policy : tosca.policy.ha TOSCA Samples Grammar This grammar has been used in TOSCA simple profile example. We support it for compatibility but don’t recommend it. <policy_name> : type : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - my_scaling_ha_policy : type : tosca.policy.ha "},{"title":"Policy","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/policy.html","date":null,"categories":[],"body":"A policy applies on a group of nodes in a topology template. Only one policy type is currently supported in A4C : tosca.policy.ha This policy is not described by TOSCA (policies are actually a WIP). We have defined this one to support high availability features. Keynames The following is the list of recognized keynames recognized for a TOSCA Policy definition and parsed by Alien4Cloud: Keyname Required Description name yes The required name of the policy. type yes The type of the policy. Several notation are availables to express policy. Standard Grammar name : <policy_name> type : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - name : my_scaling_ha_policy type : tosca.policy.ha Shortcut Grammar <policy_name> : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - my_scaling_ha_policy : tosca.policy.ha TOSCA Samples Grammar This grammar has been used in TOSCA simple profile example. We support it for compatibility but don’t recommend it. <policy_name> : type : <policy_type_name> Example node_templates : server1 : type : tosca.nodes.Compute server2 : type : tosca.nodes.Compute groups : server_group_1 : members : [ server1 , server2 ] policies : - my_scaling_ha_policy : type : tosca.policy.ha "},{"title":"Ports requirements","baseurl":"","url":"/documentation/1.0.0/admin_guide/ports_requirements.html","date":null,"categories":[],"body":"This section describes all the necessary ports for Alien4Cloud to work. Network traffic must be unrestricted on all of them for the involved servers. Note : Cloudify ports are only written here as an indication. If you have any doubt about Cloudify required ports, or are using an unmentioned version of Cloudify, please check the cloudify documentation Component - Port description Port number/range Component Version Alien4Cloud - standalone GUI port 8088 1.0.0,1.1.0 Cloudify - Management server ports 8099,8100,22,443,80 3.2 Cloudify - Management server ports for Agent/manager communication 5672,8101,53229 3.2 "},{"title":"Ports requirements","baseurl":"","url":"/documentation/1.1.0/admin_guide/ports_requirements.html","date":null,"categories":[],"body":"This section describes all the necessary ports for Alien4Cloud to work. Network traffic must be unrestricted on all of them for the involved servers. Note : Cloudify ports are only written here as an indication. If you have any doubt about Cloudify required ports, or are using an unmentioned version of Cloudify, please check the cloudify documentation Component - Port description Port number/range Component Version Alien4Cloud - standalone GUI port 8088 1.0.0,1.1.0 Cloudify - Management server ports 8099,8100,22,443,80 3.2 Cloudify - Management server ports for Agent/manager communication 5672,8101,53229 3.2 "},{"title":"Prerequisites","baseurl":"","url":"/documentation/1.0.0/cloudify3_driver/prerequisites.html","date":null,"categories":[],"body":"Here are some prerequisite steps that need to be done in order to use the cloudify 3 driver. Install Cloudify 3.1 How to install cloudify 3.1 is described here. We recommend to use the method from PyPi as it will be the only supported method by Cloudify from the version 3.2. Bootstrap your manager For the moment Alien only supports Openstack. How to bootstrap cloudify 3.1 is described here. You should customize the manager’s blueprint in order to expose the port 8100 of the management server as it’s the entry point for Cloudify Rest API. Cloudify 3 only support bootstraping on Ubuntu Precise, if you want to bootstrap on other distribution, please see Bootstraping using Docker An example of Openstack manager blueprint that we use for our test can be found here. "},{"title":"Prerequisites","baseurl":"","url":"/documentation/1.1.0/cloudify3_driver/prerequisites.html","date":null,"categories":[],"body":"Here are some prerequisite steps that need to be done in order to use the cloudify 3 driver. Install Cloudify 3.1 How to install cloudify 3.1 is described here. We recommend to use the method from PyPi as it will be the only supported method by Cloudify from the version 3.2. Bootstrap your manager For the moment Alien only supports Openstack. How to bootstrap cloudify 3.1 is described here. You should customize the manager’s blueprint in order to expose the port 8100 of the management server as it’s the entry point for Cloudify Rest API. Cloudify 3 only support bootstraping on Ubuntu Precise, if you want to bootstrap on other distribution, please see Bootstraping using Docker An example of Openstack manager blueprint that we use for our test can be found here. "},{"title":"Prerequisites","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/prerequisites.html","date":null,"categories":[],"body":"Here are listed the prerequisites to satisfy before using this driver. Related Topics "},{"title":"Property definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/property_definition.html","date":null,"categories":[],"body":"A property definition defines a named, typed value that can be associated with an entity defined in this specification. It is used to associate a transparent property or characteristic of that entity which can either be set (configured) on or retrieved from it. Keynames Keyname Type Required Description type string yes The required data type for the property. description string no The optional description for the property. required boolean no (default true) Optional key to define if the property is requied (true) or not (false). If this key is not declared for the property definition, then the property SHALL be considered required by default. default N/A no An optional key that may provide a value to be used as a default if not provided by another means. This value SHALL be type compatible with the type declared by the property definition’s type keyname. constraints list of constraints no The optional list of sequenced constraints for the property. Grammar <property_name> : type : <property_type> description : <property_description> required : <property_required> default : <property_default_value> constraints : - <property_constraint_1> - ... - <property_constraint_n> See: constraints Example The following example shows how to define a node type with properties: node_types : fastconnect.nodes.PropertiesSample : properties : property_1 : type : string property_2 : type : string required : false default : This is the default value of the property description : this is the second property of the node constraints : - min_length : 4 - max_length : 8 property_3 : type : integer default : 45 "},{"title":"Property definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/property_definition.html","date":null,"categories":[],"body":"A property definition defines a named, typed value that can be associated with an entity defined in this specification. It is used to associate a transparent property or characteristic of that entity which can either be set (configured) on or retrieved from it. Keynames Keyname Type Required Description type string yes The required data type for the property. description string no The optional description for the property. required boolean no (default true) Optional key to define if the property is requied (true) or not (false). If this key is not declared for the property definition, then the property SHALL be considered required by default. default N/A no An optional key that may provide a value to be used as a default if not provided by another means. This value SHALL be type compatible with the type declared by the property definition’s type keyname. constraints list of constraints no The optional list of sequenced constraints for the property. Grammar <property_name> : type : <property_type> description : <property_description> required : <property_required> default : <property_default_value> constraints : - <property_constraint_1> - ... - <property_constraint_n> See: constraints Example The following example shows how to define a node type with properties: node_types : fastconnect.nodes.PropertiesSample : properties : property_1 : type : string property_2 : type : string required : false default : This is the default value of the property description : this is the second property of the node constraints : - min_length : 4 - max_length : 8 property_3 : type : integer default : 45 "},{"title":"Relationship type","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/relationship_type.html","date":null,"categories":[],"body":"A Relationship Type is a reusable entity that defines the type of one or more relationships between Node Types or Node Templates. Keynames Keyname Type Required Description abstract* boolean no Optional flag to specify if a component is abstract and has no valid implementation. Defaults to false.  derived_from string no* An optional parent Relationship Type name the Relationship Type derives from. description string no An optional description for the Relationship Type. properties property definitions no An optional list of property definitions for the Relationship Type. attributes attribute definitions no An optional list of attribute definitions for the Relationship Type. interfaces interface definitions no An optional list of named interfaces for the Relationship Type. valid_sources string[] no An optional list of one or more valid target entities or entity types (i.e., a Node Types or Capability Types). valid_targets string[] yes A required list of one or more valid target entities or entity types (i.e., a Node Types or Capability Types). Abstract flag is specific to Alien 4 Cloud and is not part of TOSCA Simple Profile in YAML. derived_from is not required however relationship types SHOULD all extends from a normative type (ConnectsTo or HostedOn for example). Grammar <relationship_type_name> : derived_from : <parent_relationship_type_name> description : <relationship_description> properties : <property_definitions> attributes : <attribute_definitions> interfaces : <interface_definitions> valid_targets : [ <entity_name_or_type_1> , ... , <entity_name_or_type_n> ] See: property_definitions attribute definitions interface definitions Example mycompanytypes.myrelationships.AppDependency : derived_from : tosca.relationships.DependsOn valid_targets : [ mycompanytypes.mycapabilities.SomeAppCapability ] "},{"title":"Relationship type","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/relationship_type.html","date":null,"categories":[],"body":"A Relationship Type is a reusable entity that defines the type of one or more relationships between Node Types or Node Templates. Keynames Keyname Type Required Description abstract* boolean no Optional flag to specify if a component is abstract and has no valid implementation. Defaults to false.  derived_from string no* An optional parent Relationship Type name the Relationship Type derives from. description string no An optional description for the Relationship Type. properties property definitions no An optional list of property definitions for the Relationship Type. attributes attribute definitions no An optional list of attribute definitions for the Relationship Type. interfaces interface definitions no An optional list of named interfaces for the Relationship Type. valid_sources string[] no An optional list of one or more valid target entities or entity types (i.e., a Node Types or Capability Types). valid_targets string[] yes A required list of one or more valid target entities or entity types (i.e., a Node Types or Capability Types). Abstract flag is specific to Alien 4 Cloud and is not part of TOSCA Simple Profile in YAML. derived_from is not required however relationship types SHOULD all extends from a normative type (ConnectsTo or HostedOn for example). Grammar <relationship_type_name> : derived_from : <parent_relationship_type_name> description : <relationship_description> properties : <property_definitions> attributes : <attribute_definitions> interfaces : <interface_definitions> valid_targets : [ <entity_name_or_type_1> , ... , <entity_name_or_type_n> ] See: property_definitions attribute definitions interface definitions Example mycompanytypes.myrelationships.AppDependency : derived_from : tosca.relationships.DependsOn valid_targets : [ mycompanytypes.mycapabilities.SomeAppCapability ] "},{"title":"Requirement definition","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/requirement_definition.html","date":null,"categories":[],"body":"A requirement definition allows specification of a requirement that a node need to fulfill to be instanciated. Keynames Keyname Type Required Description type (Alien 4 Cloud supports also relationship_type) string no The optional reserved keyname used to provide a named Relationship Type to use when fulfilling the associated named requirement. lower_bound integer no Lower boundary by which a requirement MUST be matched. Valid values are any positive number, 0 meaning that the requirement is optional. Defaults to 1. upper_bound integer (or unbounded string) no Upper boundary by which a requirement MUST be matched for Node Templates. Valid values are any positive number or unbounded string that means that there is no upper limit. Defaults to 1. Grammar # using type <requirement_name> : <capability_type or node_type> type : <relationship_type> lower_bound : <lower_bound> upper_bound : <upper_bound> # alien 4 cloud specific support more meaningful <requirement_name> : <capability_type or node_type> relationship_type : <relationship_type> lower_bound : <lower_bound> upper_bound : <upper_bound> Example node_types : fastconnect.nodes.RequirementSample : requirements : - host : tosca.nodes.Compute relationship_type : tosca.relationships.HostedOn lower_bound : 0 upper_bound : unbounded "},{"title":"Requirement definition","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/requirement_definition.html","date":null,"categories":[],"body":"A requirement definition allows specification of a requirement that a node need to fulfill to be instanciated. Keynames Keyname Type Required Description type (Alien 4 Cloud supports also relationship_type) string no The optional reserved keyname used to provide a named Relationship Type to use when fulfilling the associated named requirement. lower_bound integer no Lower boundary by which a requirement MUST be matched. Valid values are any positive number, 0 meaning that the requirement is optional. Defaults to 1. upper_bound integer (or unbounded string) no Upper boundary by which a requirement MUST be matched for Node Templates. Valid values are any positive number or unbounded string that means that there is no upper limit. Defaults to 1. Grammar # using type <requirement_name> : <capability_type or node_type> type : <relationship_type> lower_bound : <lower_bound> upper_bound : <upper_bound> # alien 4 cloud specific support more meaningful <requirement_name> : <capability_type or node_type> relationship_type : <relationship_type> lower_bound : <lower_bound> upper_bound : <upper_bound> Example node_types : fastconnect.nodes.RequirementSample : requirements : - host : tosca.nodes.Compute relationship_type : tosca.relationships.HostedOn lower_bound : 0 upper_bound : unbounded "},{"title":"Roles","baseurl":"","url":"/documentation/1.0.0/concepts/roles.html","date":null,"categories":[],"body":"Roles in Alien can be mapped to any user and a user can of course have any rôle and multiple ones on any resource, however we will explain here how we defined the roles and how they can map to an enterprise organization by giving to every people involved in IT creation and/or deployment and/or consumption the right focus, visibility and access to resources. In a standard IT organization we have identified several experts profile: Some people working at a cross business and applications level: Platform admin are responsible of setting up the clouds or deployment environments. Dev-Ops ensure that software can be easily deployed on platforms and follow the company best-practices. It is important to note that a single software may be composed of several elements that have to run on multiple machines. This is especially true when we want to ensure that the software will be able to support H.A. and scalability requirements. Software Architects are responsible to software architectures, they build application topologies and ensure that best-practices are followed by the various teams in the enterprise. And some working on dedicated application(s) and project(s) Project management team (product owner, scrum master etc.) is responsible for an application. they coordinates the teams interracting on the application, plan versions and releases, define the environment requirements etc. Developer(s) are responsible for building the application and creation of the next versions. Support Engineers want to be able to deploy any version currently used by clients (or business teams) to be able to reproduce issues, find workaround etc. Q.A. Engineers are responsible to test the up-comming release and make sure that it pass the quality standard of the enterprise and won’t create issues. Of course test automation is a critical aspect of their jobs and being able to deploy complex applications easily is a part of this automation. Production Ops are responsible for running the production of one or multiple project. They are the one responsible for everything that is related to a production environment, tuning, deployments, version upgrade, solving live issues etc. Users , well they use the application… What they want is to find an easy way to access their application and find resources they need. Of course these profiles are not exclusive and a single person can handle or be expert in several profiles, for example it is quite common to have a Production Ops being also Dev-Ops. Alien 4 Cloud intend to provide a platform that will help all these people to collaborate to build the enterprise IT in a flexible manner. So the question you all want to know is: How does we map this into Alien 4 Cloud ? ADMIN will be able to configure one or multiple deployments targets ( clouds ). And of course associate deployment roles to specific users. COMPONENTS_MANAGERS will be able to define packages on how to install, configure, start and connect components (mapped as node types). ARCHITECTS will be able to define global topologies of applications by reusing building blocks (node types defined by components managers). APPLICATION_MANAGERS will be able to define applications with it’s own topologies that can be linked to a global topology from architects and that can reuse components defined by the components managers. At the application level, several users will be able to collaborate. "},{"title":"Roles","baseurl":"","url":"/documentation/1.1.0/concepts/roles.html","date":null,"categories":[],"body":"Roles in Alien can be mapped to any user and a user can of course have any rôle and multiple ones on any resource, however we will explain here how we defined the roles and how they can map to an enterprise organization by giving to every people involved in IT creation and/or deployment and/or consumption the right focus, visibility and access to resources. In a standard IT organization we have identified several experts profile: Some people working at a cross business and applications level: Platform admin are responsible of setting up the clouds or deployment environments. Dev-Ops ensure that software can be easily deployed on platforms and follow the company best-practices. It is important to note that a single software may be composed of several elements that have to run on multiple machines. This is especially true when we want to ensure that the software will be able to support H.A. and scalability requirements. Software Architects are responsible to software architectures, they build application topologies and ensure that best-practices are followed by the various teams in the enterprise. And some working on dedicated application(s) and project(s) Project management team (product owner, scrum master etc.) is responsible for an application. they coordinates the teams interracting on the application, plan versions and releases, define the environment requirements etc. Developer(s) are responsible for building the application and creation of the next versions. Support Engineers want to be able to deploy any version currently used by clients (or business teams) to be able to reproduce issues, find workaround etc. Q.A. Engineers are responsible to test the up-comming release and make sure that it pass the quality standard of the enterprise and won’t create issues. Of course test automation is a critical aspect of their jobs and being able to deploy complex applications easily is a part of this automation. Production Ops are responsible for running the production of one or multiple project. They are the one responsible for everything that is related to a production environment, tuning, deployments, version upgrade, solving live issues etc. Users , well they use the application… What they want is to find an easy way to access their application and find resources they need. Of course these profiles are not exclusive and a single person can handle or be expert in several profiles, for example it is quite common to have a Production Ops being also Dev-Ops. Alien 4 Cloud intend to provide a platform that will help all these people to collaborate to build the enterprise IT in a flexible manner. So the question you all want to know is: How does we map this into Alien 4 Cloud ? ADMIN will be able to configure one or multiple deployments targets ( clouds ). And of course associate deployment roles to specific users. COMPONENTS_MANAGERS will be able to define packages on how to install, configure, start and connect components (mapped as node types). ARCHITECTS will be able to define global topologies of applications by reusing building blocks (node types defined by components managers). APPLICATION_MANAGERS will be able to define applications with it’s own topologies that can be linked to a global topology from architects and that can reuse components defined by the components managers. At the application level, several users will be able to collaborate. "},{"title":"Runtime","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/runtime.html","date":null,"categories":[],"body":"Find here useful information on how the provider implements the lifecycles and how it works at runtime. Related Topics "},{"title":"Testing custom components","baseurl":"","url":"/documentation/1.0.0/devops_guide/design_tutorial/snapshot_topology_test.html","date":null,"categories":[],"body":"ALIEN rest api provides methods to test your topology during development. In fact you can package a CSAR file with a topology test and then run the deployment test on this archive. Prerequisites Prepare your archive You need first to correctly create your archive (more details about archive here ) Just add a specific test folder to this archive to have a tree as follow ├── Definitions │   ├── java-types.yaml │   └── tosca-base-types.yaml ├── images │   ├── compute.png │   └── ... ├── test │   └── sample-application.yaml └── TOSCA-Metadata └── ALIEN-META.yaml This test folder should contain at least one yaml file topology description Only the first found yaml file is tested In your topology written in yaml format, you can use components already integrated in ALIEN or put yours in the snapshot archive Like for other CSAR file, yaml files under Definitions folder will be loaded into ALIEN at archive upload For example, in this demo archive we bring our own java-types and tosca-base-types components (self-sufficient archive) Archive naming Another important file in this test archive is the ALIEN-META.yaml . In fact in this file you have 2 informations used to run the topology deployment test : name version name : \"topology-test\" version : \"2.0-SNAPSHOT\" license : \"Apache v2.0\" created_by : \"FastConnect\" ... Only SNAPSHOT archive version can be used to run test. We suppose that in “development mode” we only handle snapshot version which we can override at anytime and then run other test. How to test your topology For this section we’ll use our “hello world” topology archive test : hello-world-topology.zip This archive contains a yaml file corresponding to the following topology in test directory : You need first an actived cloud A “cloud” is based on a plugin (driver), so first upload your plugin jar with the ADMIN role Then you will have the following plugin administration page where you can create a cloud and activate it From the cloud details page you want to target, you have to get the cloud id Upload your snapshot archive Just upload your snapshot archive in the components view After the upload you’ll see all components contained in the snapshot archive listed in the components view Run rest command to test Get any REST client or just go on the api document http://localhost:8080/ api-doc/index.html from where you can send request Look for cloud-service-archive-controller and the operation : You need 3 parameters to run the test : csarId , csarVersion , cloudId (id recovered from cloud details page) Final request example : http://localhost:8080/rest/csars/ topology-test /version/ 2.0-SNAPSHOT /cloudid/ 7ede236c-0456-478b-b68c-502474c45987 Test the result From the step 3 you’ll obtain a deployment id only if your deployment test is successful (UUID form, e.g : 391e5d07-e2b0-44ea-bf87-81cdc080a9e1) Errors from the deployment are not really “meaningful” in the version (to improve) You have 2 other services you must use during your topology test process in deployment-controller You can recover the status from your deployment id, the same way you’ve launched the test in step 3 Example : http://localhost:8080/rest/deployments/ 391e5d07-e2b0-44ea-bf87-81cdc080a9e1 /status Possible results : ‘DEPLOYED’ or ‘UNDEPLOYED’ or ‘DEPLOYMENT_IN_PROGRESS’ or ‘UNDEPLOYMENT_IN_PROGRESS’ or ‘WARNING’ or ‘FAILURE’ or ‘UNKNOWN’ The status should be at state DEPLOYED for a correct deployment To finish we advice you to clean your deployment “stack” manually with the undeploy request Example : http://localhost:8080/rest/deployments/ 391e5d07-e2b0-44ea-bf87-81cdc080a9e1 /undeploy Undeployment success : no result You might have different states of your deployment regarding the moment you launch the status request. "},{"title":"Testing custom components","baseurl":"","url":"/documentation/1.1.0/devops_guide/design_tutorial/snapshot_topology_test.html","date":null,"categories":[],"body":"ALIEN rest api provides methods to test your topology during development. In fact you can package a CSAR file with a topology test and then run the deployment test on this archive. Prerequisites Prepare your archive You need first to correctly create your archive (more details about archive here ) Just add a specific test folder to this archive to have a tree as follow ├── Definitions │   ├── java-types.yaml │   └── tosca-base-types.yaml ├── images │   ├── compute.png │   └── ... ├── test │   └── sample-application.yaml └── TOSCA-Metadata └── ALIEN-META.yaml This test folder should contain at least one yaml file topology description Only the first found yaml file is tested In your topology written in yaml format, you can use components already integrated in ALIEN or put yours in the snapshot archive Like for other CSAR file, yaml files under Definitions folder will be loaded into ALIEN at archive upload For example, in this demo archive we bring our own java-types and tosca-base-types components (self-sufficient archive) Archive naming Another important file in this test archive is the ALIEN-META.yaml . In fact in this file you have 2 informations used to run the topology deployment test : name version name : \"topology-test\" version : \"2.0-SNAPSHOT\" license : \"Apache v2.0\" created_by : \"FastConnect\" ... Only SNAPSHOT archive version can be used to run test. We suppose that in “development mode” we only handle snapshot version which we can override at anytime and then run other test. How to test your topology For this section we’ll use our “hello world” topology archive test : hello-world-topology.zip This archive contains a yaml file corresponding to the following topology in test directory : You need first an actived cloud A “cloud” is based on a plugin (driver), so first upload your plugin jar with the ADMIN role Then you will have the following plugin administration page where you can create a cloud and activate it From the cloud details page you want to target, you have to get the cloud id Upload your snapshot archive Just upload your snapshot archive in the components view After the upload you’ll see all components contained in the snapshot archive listed in the components view Run rest command to test Get any REST client or just go on the api document http://localhost:8080/ api-doc/index.html from where you can send request Look for cloud-service-archive-controller and the operation : You need 3 parameters to run the test : csarId , csarVersion , cloudId (id recovered from cloud details page) Final request example : http://localhost:8080/rest/csars/ topology-test /version/ 2.0-SNAPSHOT /cloudid/ 7ede236c-0456-478b-b68c-502474c45987 Test the result From the step 3 you’ll obtain a deployment id only if your deployment test is successful (UUID form, e.g : 391e5d07-e2b0-44ea-bf87-81cdc080a9e1) Errors from the deployment are not really “meaningful” in the version (to improve) You have 2 other services you must use during your topology test process in deployment-controller You can recover the status from your deployment id, the same way you’ve launched the test in step 3 Example : http://localhost:8080/rest/deployments/ 391e5d07-e2b0-44ea-bf87-81cdc080a9e1 /status Possible results : ‘DEPLOYED’ or ‘UNDEPLOYED’ or ‘DEPLOYMENT_IN_PROGRESS’ or ‘UNDEPLOYMENT_IN_PROGRESS’ or ‘WARNING’ or ‘FAILURE’ or ‘UNKNOWN’ The status should be at state DEPLOYED for a correct deployment To finish we advice you to clean your deployment “stack” manually with the undeploy request Example : http://localhost:8080/rest/deployments/ 391e5d07-e2b0-44ea-bf87-81cdc080a9e1 /undeploy Undeployment success : no result You might have different states of your deployment regarding the moment you launch the status request. "},{"title":"Tests with jenkins plugin","baseurl":"","url":"/documentation/1.0.0/devops_guide/design_tutorial/snapshot_topology_test_jenkins_plugin.html","date":null,"categories":[],"body":"We have seen here that we can use the ALIEN REST API to archive tests. Based on it, a jenkins plugin has been developed (and still being improved) to automate all the test routine. The plugin is written in JAVA language, and can ca lunch a serie of BDD (Behaviour Driven Development) tests with the help of Cucumber framework. The tests are lunched via configurables Jenkins “FreeStyle” jobs. You can then configure the ALIEN instance on which to perform tests, the cloud, the credential to be used, and also specify whether or not to undeploy the test application before endind the job. Prerequisites Prepare your archive Follow the same instructions as the ones explained here . in addition, add in the “ test ” folder your cucumbr file (a .feature file). Your archive should look like: ├── Definitions │   ├── java-types.yaml │   └── tosca-base-types.yaml ├── images │   ├── compute.png │   └── ... ├── test │   ├── sample-application.yaml └── tests.feature └── TOSCA-Metadata └── ALIEN-META.yaml The cucumber (.feature) file In this file, you will have to describe what you whant to test and the way the tests should be proceeded. Currently, we only support a few steps: Feature: Install Tomcat application and test status Scenario: I install an application Given a cloud \" cloud \" created When i deploy the test application Then i have application \" deployed \" within 10000 milliseconds Package and Install the plugin Fist you need to clone the repository and package the plugin to have a .hpi file. Then install the plugin in your running instance of Jenkins. (For more information, see the Readme file in the plugin repository). How to test your topology Archive and location After preparing the archive, you have to put it at jenkins disposal. For now the solution is to upload the folder content (unzipped) on a git or svn. For the next steps, you should make sure you have a running instance of Alien 4 Cloud (copy its URL), and a cloud created and activated (note its name) Jenkins job First you must create a “FreeStyle” job on jenkins. Configure the job. In the “ Source Code Management ” section, select your provider and fill in the repository URL where you’ve uploded the content of your archive. Next, configure the build environment, by checking the option Setup Alien4Cloud test environment. This will set up some variables for the tests. Also optionnaly check the sub-option if you want the job to automatically undeploy the test application at the end. Add a build step. From the lists, Select “ALIEN 4 Cloud arhives tests”. And configure the parameters. Note that some of them might be required for the job to run well. You can now save the job config, and run it. Check for the job output to see how tests are going. If you didn’t check the option to automatically undeploy the application at the end, you might have to do it manually. Thus, you need the deployment Id, which you can find checking the job logs. Actually, we only support deployment and checking of it status. More steps will be added later. "},{"title":"Tests with jenkins plugin","baseurl":"","url":"/documentation/1.1.0/devops_guide/design_tutorial/snapshot_topology_test_jenkins_plugin.html","date":null,"categories":[],"body":"We have seen here that we can use the ALIEN REST API to archive tests. Based on it, a jenkins plugin has been developed (and still being improved) to automate all the test routine. The plugin is written in JAVA language, and can ca lunch a serie of BDD (Behaviour Driven Development) tests with the help of Cucumber framework. The tests are lunched via configurables Jenkins “FreeStyle” jobs. You can then configure the ALIEN instance on which to perform tests, the cloud, the credential to be used, and also specify whether or not to undeploy the test application before endind the job. Prerequisites Prepare your archive Follow the same instructions as the ones explained here . in addition, add in the “ test ” folder your cucumbr file (a .feature file). Your archive should look like: ├── Definitions │   ├── java-types.yaml │   └── tosca-base-types.yaml ├── images │   ├── compute.png │   └── ... ├── test │   ├── sample-application.yaml └── tests.feature └── TOSCA-Metadata └── ALIEN-META.yaml The cucumber (.feature) file In this file, you will have to describe what you whant to test and the way the tests should be proceeded. Currently, we only support a few steps: Feature: Install Tomcat application and test status Scenario: I install an application Given a cloud \" cloud \" created When i deploy the test application Then i have application \" deployed \" within 10000 milliseconds Package and Install the plugin Fist you need to clone the repository and package the plugin to have a .hpi file. Then install the plugin in your running instance of Jenkins. (For more information, see the Readme file in the plugin repository). How to test your topology Archive and location After preparing the archive, you have to put it at jenkins disposal. For now the solution is to upload the folder content (unzipped) on a git or svn. For the next steps, you should make sure you have a running instance of Alien 4 Cloud (copy its URL), and a cloud created and activated (note its name) Jenkins job First you must create a “FreeStyle” job on jenkins. Configure the job. In the “ Source Code Management ” section, select your provider and fill in the repository URL where you’ve uploded the content of your archive. Next, configure the build environment, by checking the option Setup Alien4Cloud test environment. This will set up some variables for the tests. Also optionnaly check the sub-option if you want the job to automatically undeploy the test application at the end. Add a build step. From the lists, Select “ALIEN 4 Cloud arhives tests”. And configure the parameters. Note that some of them might be required for the job to run well. You can now save the job config, and run it. Check for the job output to see how tests are going. If you didn’t check the option to automatically undeploy the application at the end, you might have to do it manually. Thus, you need the deployment Id, which you can find checking the job logs. Actually, we only support deployment and checking of it status. More steps will be added later. "},{"title":"Application start process","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/start_process.html","date":null,"categories":[],"body":"Node start process The following diagram shows how the provider process the start of a node: Global start assertion In addition to the process above, a global start detection is executed to assert that the application on his entirety is started. This is: Executing all the provided startDetection scripts and making sure they all pass; Checking that every nodes has reached at least the started state. Only then will Cloudify consider the application as fully started. Note that the timeout mentioned in the diagram above is the 9/10 of the global timeout provided by the startDetection_timeout_inSecond deployment property . This is a known limitation, as we are currently thinking of the best way to provide as intall / start timeout per component. "},{"title":"Storage volumes","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/storage.html","date":null,"categories":[],"body":"The Alien4Cloud cloudify 2.X provider supports TOSCA Blockstorage feature. Find here usefull information about how to implement it and how the provider handles it. Related Topics "},{"title":"Supported platforms","baseurl":"","url":"/documentation/1.1.0/admin/supported_platforms.html","date":null,"categories":[],"body":"Client Alien supports these different web browsers : Name Version Firefox 31 and higher Chrome 37 and higher Other browsers like Safari or the lasted IE version may work but are not automatically tested . Server Java virtual machine Alien 4 Cloud is written in java for the backend and requires a JVM 7 or higher (Oracle or OpenJDK). Orchestrators and deployment artefacts Orchestrators Deployment artefacts Cloudify 3 .bat ( alien.artifacts.BatchScript ), .sh ( tosca.artifacts.ShellScript ) Some Alien users deployed also Puppet artifact through grooving script. "},{"title":"Supported platforms","baseurl":"","url":"/documentation/1.0.0/admin/supported_platforms.html","date":null,"categories":[],"body":"Client Alien supports these different web browsers : Name Version Firefox 31 and higher Chrome 37 and higher Other browsers like Safari or the lasted IE version may work but are not automatically tested . Server Java virtual machine Alien 4 Cloud is written in java for the backend and requires a JVM 7 or higher (Oracle or OpenJDK). Orchestrators and deployment artefacts Orchestrators Deployment artefacts Cloudify 2 .bat ( alien.artifacts.BatchScript ), .sh ( tosca.artifacts.ShellScript ), .groovy ( tosca.artifacts.GroovyScript ) Cloudify 3 .bat ( alien.artifacts.BatchScript ), .sh ( tosca.artifacts.ShellScript ) Some Alien users deployed also Puppet artifact through grooving script. "},{"title":"Topologies","baseurl":"","url":"/documentation/1.0.0/concepts/topologies.html","date":null,"categories":[],"body":"A topology (or TOSCA’s service template or blueprint) describe a deployment or a subset of a deployment. A topology is a composition of multiple nodes that may be connected through relationships. TOSCA normative types provide several types of relationships that are used to model the different component interactions that exists "},{"title":"Topologies","baseurl":"","url":"/documentation/1.1.0/concepts/topologies.html","date":null,"categories":[],"body":"A topology (or TOSCA’s service template or blueprint) describe a deployment or a subset of a deployment. A topology is a composition of multiple nodes that may be connected through relationships. TOSCA normative types provide several types of relationships that are used to model the different component interactions that exists "},{"title":"Topology management","baseurl":"","url":"/documentation/1.1.0/user_guide/topology_management.html","date":null,"categories":[],"body":" To understand the topology concept, please refer to this section . Topology template A topology template allows you to create an application structure which we may use for a real application root. You can access to this feature on menu Topology templates and start to create a new template with the topology composer or upload a zip file with your template. Create a new topology giving at least a template name and if you want a description . This template name will identify your template and must be unique. And then compose your template in this view : Just drag and drop your zipped topology in the upload area : Topology templates list Once you have created / uploaded a template you should be able to see it in the template list : From now you can use any template when creating a new application . Topology substitution / composition A topology template can also be used in another template as a type. In order to do this, you must: define the type it will inherit from (“subsitution” panel in topology composer). choose the capabilities/requirements you want to expose (as capabilities/requirements for the new type). eventually define inputs and outputs that will become respectively properties and attributes for the created type. The created type is named like the template and is usable in another template or an application topology. It’s content will be wired at runtime stage. Topology version In the topology version page you can create, edit or delete a version. As we already say in the application concept page, if you remove the ‘SNAPSHOT’ qualifier, your topology will be not editable. "},{"title":"Topology management","baseurl":"","url":"/documentation/1.0.0/user_guide/topology_management.html","date":null,"categories":[],"body":" To understand the topology concept, please refer to this section . Topology template A topology template allows you to create an application structure which we may use for a real application root. You can access to this feature on menu Topology templates and start to create a new template with the topology composer or upload a zip file with your template. Create a new topology giving at least a template name and if you want a description . This template name will identify your template and must be unique. And then compose your template in this view : Just drag and drop your zipped topology in the upload area : Topology templates list Once you have created / uploaded a template you should be able to see it in the template list : From now you can use any template when creating a new application . Topology substitution / composition A topology template can also be used in another template as a type. In order to do this, you must: define the type it will inherit from (“subsitution” panel in topology composer). choose the capabilities/requirements you want to expose (as capabilities/requirements for the new type). eventually define inputs and outputs that will become respectively properties and attributes for the created type. The created type is named like the template and is usable in another template or an application topology. It’s content will be wired at runtime stage. Topology version In the topology version page you can create, edit or delete a version. As we already say in the application concept page, if you remove the ‘SNAPSHOT’ qualifier, your topology will be not editable. "},{"title":"Topology template","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_grammar/topology_template.html","date":null,"categories":[],"body":"This section defines the topology template of a cloud application. The main ingredients of the Topology Template are node templates representing components of the application. Keynames A Topology Template contains the following element keynames: Keyname Required Description description no Declares a description for this Service Template and its contents. inputs no Defines a set of global input parameters passed to the template when its instantiated. This provides a means for template authors to provide points of variability to users of the template in order to customize each instance within certain constraints. input_artifacts no Define artifacts as inputs. substitution_mappings no Describe how this topology can be used as a type in another one. node_templates yes Defines a list of Node template s that model the components of an application or service’s topology within the Service Template. relationship_templates no Defines a list of Relationship Templates that are used to model the relationships (e.g., dependencies, links, etc.) between components (i.e., Node Templates) of an application or service’s topology within the Service Template. outputs no This optional section allows for defining a set of output parameters provided to users of the template. For example, this can be used for exposing the URL for logging into a web application that has been set up during the instantiation of a template. groups no This is an optional section that contains grouping definition for node templates. Grammar The overall structure of a TOSCA Topology Template and its top-level key collations using the TOSCA Simple Profile is shown below: topology_template description : a description of the topology template inputs : # list of global input parameters input_artifacts : # map of artifacts defined as inputs (non TOSCA) substitution_mappings : # define substitution mapping node_templates : # list of node templates relationship_templates : # list of relationship templates groups : # list of groups defined in service template outputs : # list of output parameters description This optional element provides a means to include single or multiline descriptions within a TOSCA Simple Profile template as a scalar string value. inputs This optional element provides a means to define parameters, their allowed values via constraints and default values within a TOSCA Simple Profile template. This section defines template-level input parameter section. Inputs here would ideally be mapped to BoundaryDefinitions in TOSCA v1.0. Treat input parameters as fixed global variables (not settable within template) If not in input take default (nodes use default) Grammar inputs : <property_definition_1> ... <property_definition_n> Examples Simple example without any constraints: inputs : fooName : type : string description : Simple string typed property definition with no constraints. default : bar Example with constraints: inputs : SiteName : type : string description : string typed property definition with constraints default : My Site constraints : - min_length : 9 The parameters (properties) that are listed as part of the inputs block could be mapped to PropertyMappings provided as part of BoundaryDefinitions as described by the TOSCA v1.0 specification. input_artifacts This section defines template-level input artifacts. Such artifacts can be shared by several nodes. Their content is defined at deployment time. The section input_artifacts and the function get_input_artifact are not yet defined in TOSCA. Examples In this example, an input artifact is defined and shared by two different nodes: topology_template : input_artifacts : my_war_file : type : alien.artifacts.WarFile node_templates : War1 : type : alien.nodes.cloudify.War artifacts : war_file : implementation : { get_input_artifact : my_war_file } type : alien.artifacts.WarFile War2 : type : alien.nodes.cloudify.War artifacts : war_file : implementation : { get_input_artifact : my_war_file } type : alien.artifacts.WarFile substitution_mappings Substitution allows you to compose topologies by combining templates. To be usable in another topology, you must define what a topology template will expose: capabilities requirements properties attributes Examples In the example below, the topology template define 2 nodes. It’s exposed as a tosca.nodes.Root (this means that the created type will inherit tosca.nodes.Root ). It will have: a capability named ‘host’ that will be wired to the capability ‘host’ of the node ‘Mysql’. a requirement named ‘network’ that will be wired to the requirement ‘network’ of the node ‘Compute’ Since inputs and outputs are defined for this template, it will also have: a property named ‘db_port’ an attribute named ‘Mysql_database_endpoint_port’ topology_template : inputs : db_port : type : integer required : true default : 3306 description : The port on which the underlying database service will listen to data. substitution_mappings : node_type : tosca.nodes.Root capabilities : host : [ Mysql , host ] requirements : network : [ Compute , network ] node_templates : Mysql : type : alien.nodes.Mysql properties : db_port : { get_input : db_port } requirements : - host : node : Compute capability : tosca.capabilities.Container relationship : tosca.relationships.HostedOn Compute : type : tosca.nodes.Compute outputs : Mysql_database_endpoint_port : value : { get_property : [ Mysql , database_endpoint , port ] } node_templates This element lists the Node Templates that describe the (software) components that are used to compose cloud applications. Grammar node_templates : <node_template_defn_1> ... <node_template_defn_n> Example node_templates : my_webapp_node_template : type : WebApplication my_database_node_template : type : Database The node templates listed as part of the node_templates block can be mapped to the list of NodeTemplate definitions provided as part of TopologyTemplate of a ServiceTemplate as described by the TOSCA v1.0 specification. see: Node template relationship_templates Not yet supported In Alien 4 Cloud groups The group construct is a composition element used to group one or more node templates within a TOSCA Service Template. It is mainly used to apply a Policy onto a group of nodes. Grammar groups : <group_name_A> : members : [ node1 , ... nodeN ] policies : - <policy_defn_A_1> ... - <policy_defn_A_n> <group_name_B> members : [ node1 , ... nodeN ] policies : - <policy_defn_B_1> ... - <policy_defn_B_n> Example node_templates : server1 : type : tosca.nodes.Compute # more details ... server2 : type : tosca.nodes.Compute # more details ... server3 : type : tosca.nodes.Compute # more details ... groups : server_group_1 : members : [ server1 , server2 ] policies : - name : my_scaling_ha_policy type : tosca.policy.ha see: Policy outputs This optional element provides a means to define the output parameters that are available from a TOSCA Simple Profile service template. Grammar outputs : <property_definitions> Example outputs : server_ip : description : The IP address of the provisioned server. value : { get_attribute : [ my_server , ip_address ] } "},{"title":"Topology template","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_grammar/topology_template.html","date":null,"categories":[],"body":"This section defines the topology template of a cloud application. The main ingredients of the Topology Template are node templates representing components of the application. Keynames A Topology Template contains the following element keynames: Keyname Required Description description no Declares a description for this Service Template and its contents. inputs no Defines a set of global input parameters passed to the template when its instantiated. This provides a means for template authors to provide points of variability to users of the template in order to customize each instance within certain constraints. input_artifacts no Define artifacts as inputs. substitution_mappings no Describe how this topology can be used as a type in another one. node_templates yes Defines a list of Node template s that model the components of an application or service’s topology within the Service Template. relationship_templates no Defines a list of Relationship Templates that are used to model the relationships (e.g., dependencies, links, etc.) between components (i.e., Node Templates) of an application or service’s topology within the Service Template. outputs no This optional section allows for defining a set of output parameters provided to users of the template. For example, this can be used for exposing the URL for logging into a web application that has been set up during the instantiation of a template. groups no This is an optional section that contains grouping definition for node templates. Grammar The overall structure of a TOSCA Topology Template and its top-level key collations using the TOSCA Simple Profile is shown below: topology_template description : a description of the topology template inputs : # list of global input parameters input_artifacts : # map of artifacts defined as inputs (non TOSCA) substitution_mappings : # define substitution mapping node_templates : # list of node templates relationship_templates : # list of relationship templates groups : # list of groups defined in service template outputs : # list of output parameters description This optional element provides a means to include single or multiline descriptions within a TOSCA Simple Profile template as a scalar string value. inputs This optional element provides a means to define parameters, their allowed values via constraints and default values within a TOSCA Simple Profile template. This section defines template-level input parameter section. Inputs here would ideally be mapped to BoundaryDefinitions in TOSCA v1.0. Treat input parameters as fixed global variables (not settable within template) If not in input take default (nodes use default) Grammar inputs : <property_definition_1> ... <property_definition_n> Examples Simple example without any constraints: inputs : fooName : type : string description : Simple string typed property definition with no constraints. default : bar Example with constraints: inputs : SiteName : type : string description : string typed property definition with constraints default : My Site constraints : - min_length : 9 The parameters (properties) that are listed as part of the inputs block could be mapped to PropertyMappings provided as part of BoundaryDefinitions as described by the TOSCA v1.0 specification. input_artifacts This section defines template-level input artifacts. Such artifacts can be shared by several nodes. Their content is defined at deployment time. The section input_artifacts and the function get_input_artifact are not yet defined in TOSCA. Examples In this example, an input artifact is defined and shared by two different nodes: topology_template : input_artifacts : my_war_file : type : alien.artifacts.WarFile node_templates : War1 : type : alien.nodes.cloudify.War artifacts : war_file : implementation : { get_input_artifact : my_war_file } type : alien.artifacts.WarFile War2 : type : alien.nodes.cloudify.War artifacts : war_file : implementation : { get_input_artifact : my_war_file } type : alien.artifacts.WarFile substitution_mappings Substitution allows you to compose topologies by combining templates. To be usable in another topology, you must define what a topology template will expose: capabilities requirements properties attributes Examples In the example below, the topology template define 2 nodes. It’s exposed as a tosca.nodes.Root (this means that the created type will inherit tosca.nodes.Root ). It will have: a capability named ‘host’ that will be wired to the capability ‘host’ of the node ‘Mysql’. a requirement named ‘network’ that will be wired to the requirement ‘network’ of the node ‘Compute’ Since inputs and outputs are defined for this template, it will also have: a property named ‘db_port’ an attribute named ‘Mysql_database_endpoint_port’ topology_template : inputs : db_port : type : integer required : true default : 3306 description : The port on which the underlying database service will listen to data. substitution_mappings : node_type : tosca.nodes.Root capabilities : host : [ Mysql , host ] requirements : network : [ Compute , network ] node_templates : Mysql : type : alien.nodes.Mysql properties : db_port : { get_input : db_port } requirements : - host : node : Compute capability : tosca.capabilities.Container relationship : tosca.relationships.HostedOn Compute : type : tosca.nodes.Compute outputs : Mysql_database_endpoint_port : value : { get_property : [ Mysql , database_endpoint , port ] } node_templates This element lists the Node Templates that describe the (software) components that are used to compose cloud applications. Grammar node_templates : <node_template_defn_1> ... <node_template_defn_n> Example node_templates : my_webapp_node_template : type : WebApplication my_database_node_template : type : Database The node templates listed as part of the node_templates block can be mapped to the list of NodeTemplate definitions provided as part of TopologyTemplate of a ServiceTemplate as described by the TOSCA v1.0 specification. see: Node template relationship_templates Not yet supported In Alien 4 Cloud groups The group construct is a composition element used to group one or more node templates within a TOSCA Service Template. It is mainly used to apply a Policy onto a group of nodes. Grammar groups : <group_name_A> : members : [ node1 , ... nodeN ] policies : - <policy_defn_A_1> ... - <policy_defn_A_n> <group_name_B> members : [ node1 , ... nodeN ] policies : - <policy_defn_B_1> ... - <policy_defn_B_n> Example node_templates : server1 : type : tosca.nodes.Compute # more details ... server2 : type : tosca.nodes.Compute # more details ... server3 : type : tosca.nodes.Compute # more details ... groups : server_group_1 : members : [ server1 , server2 ] policies : - name : my_scaling_ha_policy type : tosca.policy.ha see: Policy outputs This optional element provides a means to define the output parameters that are available from a TOSCA Simple Profile service template. Grammar outputs : <property_definitions> Example outputs : server_ip : description : The IP address of the provisioned server. value : { get_attribute : [ my_server , ip_address ] } "},{"title":"TOSCA","baseurl":"","url":"/documentation/1.1.0/concepts/tosca.html","date":null,"categories":[],"body":"TOSCA specification allows users to specify a cloud application’s topology by defining a set of nodes that are connected to other using relationships. The goal of the TOSCA specification is to focus on a good meta-definition of cloud applications and their components and focus on the following goals: Reusability of components Interoperability of TOSCA archive through the different TOSCA containers In order to manage reusability of components and defined recipes, TOSCA allows definition of NodeTypes that specify the available components and eventually their implementation (for example a Java NodeType and the script implementation to install it on a virtual server). The defined NodeTypes can then be reused when a developer or application architect want to define the topology of a cloud application. TOSCA Simple Profile in YAML TOSCA Simple profile in YAML allows definition of TOSCA elements in a YAML format rather than XML. The YAML format is simpler to write and offers some shorter ways to defined a TOSCA definition. Note: TOSCA Simple profile is a working draft and is not released yet to public. Current Alien 4 Cloud version is using a Alien 4 Cloud’s specific DSL that is really close to the latest TOSCA Simple Profile in YAML TC work. This may be subject to some updates in the future. TOSCA in Alien 4 Cloud In Alien 4 Cloud, TOSCA can be used to define both Types (catalog elements) and Applications topologies (Templates). Alien 4 Cloud tools like the topology editor allows you to create Application topologies that can be exported to Tosca Templates. Alien 4 Cloud support a slightly modified version of TOSCA Simple Profile in YAML in order to add features that are specific to Alien 4 Cloud context. However we are able to load pure TOSCA compliant templates and also export topologies as pure TOSCA templates. Export feature will be available in the next release. Cloud Service Archive Every elements in TOSCA must be contained into a Cloud Service Archive (CSAR). A Cloud Service Archive is a folder or a zip file that contains types and templates definitions and any other files required for elements implementations. ├── my-definition-file.yml ├── images │   ├── component-icon.png │   └── ... ├── scripts │   └── install.sh ├── lib │   └── tosca-normative-types.yml The entry point for the Cloud Service Archive are the definitions files that are placed at the root of the Archive. Basically this is any .yaml or .yml file that can be found at the Archive root. To create your own CSAR, please refer to this section . Alien 4 Cloud currently supports only a single service definitions file at the root level. This definition file can however reference other definitions files within the archive through the imports feature. "},{"title":"TOSCA","baseurl":"","url":"/documentation/1.0.0/concepts/tosca.html","date":null,"categories":[],"body":"TOSCA specification allows users to specify a cloud application’s topology by defining a set of nodes that are connected to other using relationships. The goal of the TOSCA specification is to focus on a good meta-definition of cloud applications and their components and focus on the following goals: Reusability of components Interoperability of TOSCA archive through the different TOSCA containers In order to manage reusability of components and defined recipes, TOSCA allows definition of NodeTypes that specify the available components and eventually their implementation (for example a Java NodeType and the script implementation to install it on a virtual server). The defined NodeTypes can then be reused when a developer or application architect want to define the topology of a cloud application. TOSCA Simple Profile in YAML TOSCA Simple profile in YAML allows definition of TOSCA elements in a YAML format rather than XML. The YAML format is simpler to write and offers some shorter ways to defined a TOSCA definition. Note: TOSCA Simple profile is a working draft and is not released yet to public. Current Alien 4 Cloud version is using a Alien 4 Cloud’s specific DSL that is really close to the latest TOSCA Simple Profile in YAML TC work. This may be subject to some updates in the future. TOSCA in Alien 4 Cloud In Alien 4 Cloud, TOSCA can be used to define both Types (catalog elements) and Applications topologies (Templates). Alien 4 Cloud tools like the topology editor allows you to create Application topologies that can be exported to Tosca Templates. Alien 4 Cloud support a slightly modified version of TOSCA Simple Profile in YAML in order to add features that are specific to Alien 4 Cloud context. However we are able to load pure TOSCA compliant templates and also export topologies as pure TOSCA templates. Export feature will be available in the next release. Cloud Service Archive Every elements in TOSCA must be contained into a Cloud Service Archive (CSAR). A Cloud Service Archive is a folder or a zip file that contains types and templates definitions and any other files required for elements implementations. ├── my-definition-file.yml ├── images │   ├── component-icon.png │   └── ... ├── scripts │   └── install.sh ├── lib │   └── tosca-normative-types.yml The entry point for the Cloud Service Archive are the definitions files that are placed at the root of the Archive. Basically this is any .yaml or .yml file that can be found at the Archive root. To create your own CSAR, please refer to this section . Alien 4 Cloud currently supports only a single service definitions file at the root level. This definition file can however reference other definitions files within the archive through the imports feature. "},{"title":"Developing TOSCA Types","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/tosca_archive.html","date":null,"categories":[],"body":"Here are informations about how to adapt your TOSCA archives. You might first want to go check about TOSCA guide before continuing, as we assume here that you are familiar with those concepts. Related Topics "},{"title":"TOSCA definitions","baseurl":"","url":"/documentation/1.0.0/cloudify2_driver/tosca_archive_definitions.html","date":null,"categories":[],"body":"The Cloudify driver for ALEIN 4 CLOUD allows you to deploy applications on several clouds, using Cloudify 2.7. Thus you have to design TOSCA archives containing nodes , and upload them in your ALIEN instance. If your archive contains deployable nodes, you might have to add to their definitions some artifacts and interfaces. Standard interface As its name states, the Standard interface allows you to define some lifecycle events for your node. Both Cloudify and TOSCA have this iterface in their specifications, with diferent operations names. Yet, it is possible to make a mapping from TOSCA to Cloudify lifecycle. Operations TOSCA Cloudify Supported Description create install YES  Allows to define the way to create / install your node when deploying configure - YES  Specify the routine to run to configure the node start start YES  Allows to define the way to start the node stop stop YES  Specify the routine to run to stop the node delete - NO  Specify the routine to run to cleanup after Example: interfaces : Standard : create : scripts/tomcat_installCalm.groovy start : scripts/tomcat_start.groovy stop : scripts/tomcat_stop.sh The artifact_type s tosca.artifacts.GroovyScript , tosca.artifacts.ShellScript and fastconnect.artifacts.ResourceDirectory are provided by ALIEN in a base package. For the Standard interface, you can use both Groovy and Shell scripts. Your scripts folder The operations implementation’s scripts are automatically copied along with your node on deployment. However, if they are not independant, meaning they rely on, or call other files, you must reference these latest as artifacts. The simplest way is to define an artifact of type tosca.artifacts.File referencing the folder where are stored all of your scripts. artifacts : - scripts : scripts type : tosca.artifacts.File fastconnect.cloudify.extensions interface Aside of the above operations, Cloudify also provides various lifecycle events. All of them are not mappable to a TOSCA Standard event. Therefore, ALIEN defined an interface, fastconnect.cloudify.extensions to help handling some of those operations. The ones currently supported by ALIEN are: StartDetection StopDetection locator Note that the driver only supports groovy scripts for this interface’s operations . See Cloudify specifics about them. "},{"title":"TOSCA concepts","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_concepts.html","date":null,"categories":[],"body":" To understand all TOSCA concepts, please refer to this section . TOSCA in Alien 4 Cloud In Alien 4 Cloud, TOSCA can be used to define both Types (catalog elements) and Applications topologies (Templates). Alien 4 Cloud tools like the topology editor allows you to create Application topologies that can be exported to Tosca Templates. Alien 4 Cloud support a slightly modified version of TOSCA Simple Profile in YAML in order to add features that are specific to Alien 4 Cloud context. However we are able to load pure TOSCA compliant templates and also export topologies as pure TOSCA templates. Export feature will be available in the next release. "},{"title":"TOSCA guide","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_concepts.html","date":null,"categories":[],"body":" To understand all TOSCA concepts, please refer to this section . TOSCA in Alien 4 Cloud In Alien 4 Cloud, TOSCA can be used to define both Types (catalog elements) and Applications topologies (Templates). Alien 4 Cloud tools like the topology editor allows you to create Application topologies that can be exported to Tosca Templates. Alien 4 Cloud support a slightly modified version of TOSCA Simple Profile in YAML in order to add features that are specific to Alien 4 Cloud context. However we are able to load pure TOSCA compliant templates and also export topologies as pure TOSCA templates. Export feature will be available in the next release. "},{"title":"Writing custom types","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_concepts_types_custom.html","date":null,"categories":[],"body":"TOSCA specification allows definition of a cloud application by defining a set of nodes that are connected to other using relationships. In order to improve reusability of components and defined recipes, TOSCA allow the definition of NodeTypes that defines components and eventually their implementation (for example a Java NodeType and the script implementation to install it on a virtual server). The defined NodeTypes can then be reused when a developer or application architect want to define the topology of a cloud application. TOSCA and thus Alien 4 Cloud allows you to define some abstract types (basically meta-types without implementation). This allows of course to dissociate the specific technical implementations from the actual definition of a component (writing an abstract Java node and several implementations with chef, puppet etc.). This can also be leveraged in order to meta-model your applications for the cloud even if you don’t need to deploy them right now. Alien 4 Cloud advisory features for moving to the cloud leverage this to quiclky map your Information System and get feedback on your application’s cloud maturity and migration advisory. The sub-sections details how you can write your own Capability Types, Node Types and Relationship Types to extends the one that Alien 4 Cloud already provides to you. Definition of Node Types and other elements in TOSCA should be done in a definition file and packaged in a Cloud Service Archive "},{"title":"Writing custom types","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_concepts_types_custom.html","date":null,"categories":[],"body":"TOSCA specification allows definition of a cloud application by defining a set of nodes that are connected to other using relationships. In order to improve reusability of components and defined recipes, TOSCA allow the definition of NodeTypes that defines components and eventually their implementation (for example a Java NodeType and the script implementation to install it on a virtual server). The defined NodeTypes can then be reused when a developer or application architect want to define the topology of a cloud application. TOSCA and thus Alien 4 Cloud allows you to define some abstract types (basically meta-types without implementation). This allows of course to dissociate the specific technical implementations from the actual definition of a component (writing an abstract Java node and several implementations with chef, puppet etc.). This can also be leveraged in order to meta-model your applications for the cloud even if you don’t need to deploy them right now. Alien 4 Cloud advisory features for moving to the cloud leverage this to quiclky map your Information System and get feedback on your application’s cloud maturity and migration advisory. The sub-sections details how you can write your own Capability Types, Node Types and Relationship Types to extends the one that Alien 4 Cloud already provides to you. Definition of Node Types and other elements in TOSCA should be done in a definition file and packaged in a Cloud Service Archive "},{"title":"Normative Types","baseurl":"","url":"/documentation/1.1.0/devops_guide/normative_types/tosca_concepts_types_normative.html","date":null,"categories":[],"body":"TOSCA Specification defines some basic root types (TOSCA Normative types). There is default types for the Infrastructure and for the appliction. Most of the application components however are not part of normative types but should extends from the TOSCA root types. This allows the container to leverage the default nodes lifecycle in order to automate Plan creation. If you add some custom nodes that doesn’t extends from the Normative types, the container will not be able to include them in an auto-generated plan, every application that uses such types will require a custom defined plan. Even if it is possible to do so this is not recommended. Normative Lifecycle TOSCA Normative types defines the root nodes and default lifecycle to ease writing and using TOSCA for real applications. The default lifecycle can be extended and improved through the creation of custom plans but should fit most usages. "},{"title":"Normative Types","baseurl":"","url":"/documentation/1.0.0/devops_guide/normative_types/tosca_concepts_types_normative.html","date":null,"categories":[],"body":"TOSCA Specification defines some basic root types (TOSCA Normative types). There is default types for the Infrastructure and for the appliction. Most of the application components however are not part of normative types but should extends from the TOSCA root types. This allows the container to leverage the default nodes lifecycle in order to automate Plan creation. If you add some custom nodes that doesn’t extends from the Normative types, the container will not be able to include them in an auto-generated plan, every application that uses such types will require a custom defined plan. Even if it is possible to do so this is not recommended. Normative Lifecycle TOSCA Normative types defines the root nodes and default lifecycle to ease writing and using TOSCA for real applications. The default lifecycle can be extended and improved through the creation of custom plans but should fit most usages. "},{"title":"Capabilities","baseurl":"","url":"/documentation/1.1.0/devops_guide/normative_types/tosca_concepts_types_normative_capabilities.html","date":null,"categories":[],"body":"Normatives capability types in TOSCA tosca.capabilities.Root This is the default (root) TOSCA Capability Type definition that all other TOSCA Capability Types derive from. Definition capability_types : tosca.capabilities.Root : description : > This is the default (root) TOSCA Capability Type definition that all other TOSCA Capability Types derive from. tosca.capabilities.Container The Container capability, when included on a Node Type or Template definition, indicates that the node can act as a container for (or a host for) one or more other declared Node Types. Properties Name Required Type Constraints Description valid_node_types true string[] A list of one or more names of Node Types that are supported as containees that declare the Container type as a Capability.   Definition tosca.capabilities.Container : derived_from : tosca.capabilities.Root properties : valid_node_types : type : string[] required : true description : Array of node types that are valid node types to be contained. description : > A list of one or more names of Node Types that are supported as containees that declare the Container type as a Capability. tosca.capabilities.Endpoint This is the default TOSCA type that should be used or extended to define a network endpoint capability. Properties Name Required Type Constraints Description protocol yes string None The name of the protocol (i.e., the protocol prefix) that the endpoint accepts. Examples: http, https, tcp, udp, etc. port yes integer greater_or_equal:1 less_or_equal:65535 The port of the endpoint. secure no boolean default = false Indicates if the endpoint is a secure endpoint. Definition tosca.capabilities.Endpoint : derived_from : tosca.capabilities.Feature properties : protocol : type : string default : http port : type : integer constraints : - greater_or_equal : 1 - less_or_equal : 65535 secure : type : boolean default : false tosca.capabilities.DatabaseEndpoint This is the default TOSCA type that should be used or extended to define a specialized database endpoint capability. Definition tosca.capabilities.DatabaseEndpoint : derived_from : tosca.capabilities.Endpoint tosca.capabilities.Attachment This is the default TOSCA type that should be used or extended to define a network endpoint capability. Definition tosca.capabilities.Attachment : derived_from : tosca.capabilities.Root "},{"title":"Capabilities","baseurl":"","url":"/documentation/1.0.0/devops_guide/normative_types/tosca_concepts_types_normative_capabilities.html","date":null,"categories":[],"body":"Normatives capability types in TOSCA tosca.capabilities.Root This is the default (root) TOSCA Capability Type definition that all other TOSCA Capability Types derive from. Definition capability_types : tosca.capabilities.Root : description : > This is the default (root) TOSCA Capability Type definition that all other TOSCA Capability Types derive from. tosca.capabilities.Container The Container capability, when included on a Node Type or Template definition, indicates that the node can act as a container for (or a host for) one or more other declared Node Types. Properties Name Required Type Constraints Description valid_node_types true string[] A list of one or more names of Node Types that are supported as containees that declare the Container type as a Capability.   Definition tosca.capabilities.Container : derived_from : tosca.capabilities.Root properties : valid_node_types : type : string[] required : true description : Array of node types that are valid node types to be contained. description : > A list of one or more names of Node Types that are supported as containees that declare the Container type as a Capability. tosca.capabilities.Endpoint This is the default TOSCA type that should be used or extended to define a network endpoint capability. Properties Name Required Type Constraints Description protocol yes string None The name of the protocol (i.e., the protocol prefix) that the endpoint accepts. Examples: http, https, tcp, udp, etc. port yes integer greater_or_equal:1 less_or_equal:65535 The port of the endpoint. secure no boolean default = false Indicates if the endpoint is a secure endpoint. Definition tosca.capabilities.Endpoint : derived_from : tosca.capabilities.Feature properties : protocol : type : string default : http port : type : integer constraints : - greater_or_equal : 1 - less_or_equal : 65535 secure : type : boolean default : false tosca.capabilities.DatabaseEndpoint This is the default TOSCA type that should be used or extended to define a specialized database endpoint capability. Definition tosca.capabilities.DatabaseEndpoint : derived_from : tosca.capabilities.Endpoint tosca.capabilities.Attachment This is the default TOSCA type that should be used or extended to define a network endpoint capability. Definition tosca.capabilities.Attachment : derived_from : tosca.capabilities.Root "},{"title":"Nodes","baseurl":"","url":"/documentation/1.1.0/devops_guide/normative_types/tosca_concepts_types_normative_nodes.html","date":null,"categories":[],"body":"The nodes on this page follow the exact TOSCA normative types except the added tags section that we use in ALIEN to specify additional tags on a components. One of them being a specific tag that we use to package the icon that will be used in the UI for a given component. Normatives node types in TOSCA tosca.nodes.Root This is the Root TOSCA Node Type that other nodes extends from. This allows to have a consistent set of features for modeling and management (e.g., consistent definitions for requirements, capabilities and lifecycle interfaces). All Node Type definitions SHOULD extends from the TOSCA Root Node Type. This allows your custom nodes to be included in the default lifecycle generation (based on the root node lifecycle interface). Interfaces The Root node uses the lifecycle interface. See more informations on normative types lifecycle. Definition node_types : tosca.nodes.Root : abstract : true description : > This is the default (root) TOSCA Node Type that all other TOSCA nodes should extends. This allows all TOSCA nodes to have a consistent set of features for modeling and management (e.g, consistent definitions for requirements, capabilities, and lifecycle interfaces). tags : icon : /images/root.png requirements : dependency : type : tosca.capabilities.Root lower_bound : 0 upper_bound : unbounded interfaces : lifecycle : description : Default lifecycle for nodes in TOSCA. operations : create : description : Basic lifecycle create operation. configure : description : Basic lifecycle configure operation. start : description : Basic lifecycle start operation. stop : description : Basic lifecycle stop operation. delete : description : Basic lifecycle delete operation. tosca.nodes.Compute Represents a real or virtual machine or ‘server’. Informations specified on the Compute node will be used to find the machine that fits the given requirements in the cloud available machines. If no sizing informations are specified the cloud’s provider default machine will be used. It is strongly recommended to specify the required cpus and memory at least. Properties Name Required Type Constraints Description num_cpus no integer >= 1 Number of (actual or virtual) CPUs associated with the Compute node. disk_size no integer >=0 Size of the loal disk, in Gigabytes (GB), available to applications running on the Compute node. mem_size no integer >=0 Size of memory, in Megabytes (MB), available to applications running on the Compute node. os_arch yes string none The host Operating System (OS) architecture. Example of valid values includes: x86_32, x86_64, etc. os_type yes string none The hots Operating System (OS) type. Example of valid values includes: linux, windows, aix, macos, etc. os_distribution no string none The host Operating System (OS) distribution. Example of valid values includes: debian, fedora, rhel, and ubuntu os_version no string none  The host Operating System (OS) version. Attributes Name Required Type Description ip_address no string  The primary IP address assigned by the cloud provider that applications may use to access the Compute node. Definition node_types : tosca.nodes.Compute : derived_from : tosca.nodes.Root description : > Represents a real or virtual machine or ‘server’. Informations specified on the Compute node will be used to find the machine that fits the given requirements in the cloud available machines. If no sizing informations are specified the cloud’s provider default machine will be used. It is strongly recommended to specify the required cpus and memory at least. properties : num_cpus : type : integer constraints : - greater_than : 0 description : Number of (actual or virtual) CPUs associated with the Compute node. mem_size : type : integer constraints : - greater_than : 0 description : Size of memory, in Megabytes (MB), available to applications running on the Compute node. disk_size : type : integer constraints : - greater_than : 0 description : Size of the local disk, in Gigabytes (GB), available to applications running on the Compute node. os_arch : type : string required : true constraints : - valid_values : [ \"x86_32\" , \"x86_64\" ] description : The host Operating System (OS) architecture. os_type : type : string required : true constraints : - valid_values : [ \"linux\" , \"aix\" , \"mac os\" , \"windows\" ] description : The host Operating System (OS) type. os_distribution : type : string description : The host Operating System (OS) distribution. os_version : type : string description : The host Operating System version. attributes : ip_address : type : string description : > The primary IP address assigned by the cloud provider that applications may use to access the Compute node. Note: This is used by the platform provider to convey the primary address used to access the compute node. Future working drafts will address implementations that support floating or multiple IP addresses. capabilities : host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.SoftwareComponent ] tosca.nodes.BlockStorage The TOSCA BlockStorage node currently represents a server-local block storage device (i.e., not shared) offering evenly sized blocks of data from which raw storage volumes can be created. Properties Name Required Type Constraints Description size no string None The requested storage size in MegaBytes (MB). volume_id no integer >0 ID of an existing volume (that is in the accessible scope of the requesting application). snapshot_id no integer >0 Some identifier that represents an existing snapshot that should be used when creating the block storage (volume). Attributes Name Required Type Constraints Description volume_id no integer >0 ID provided by the orchestrator for newly created volumes. Definition node_types : tosca.nodes.BlockStorage : derived_from : tosca.nodes.Root description : > The TOSCA BlockStorage node currently represents a server-local block storage device (i.e., not shared) offering evenly sized blocks of data from which raw storage volumes can be created. tags : icon : /images/volume.png properties : size : type : integer constraints : - greater_than : 0 description : The requested storage size in MegaBytes (MB). volume_id : type : string description : ID of an existing volume (that is in the accessible scope of the requesting application). snapshot_id : type : string description : Some identifier that represents an existing snapshot that should be used when creating the block storage (volume). attributes : volume_id : type : string description : ID provided by the orchestrator for newly created volumes. requirements : attachment : type : tosca.capabilities.Attachment tosca.nodes.ObjectStorage The TOSCA ObjectStorage node represents storage that provides the ability to store data as objects (or BLOBs of data) without consideration for the underlying filesystem or devices. Properties Name Required Type Constraints Description store_name yes string None The logical name of the object store (or container). store_size no integer >=0 The requested initial storage size in Gigabytes (GB). store_maxsize no integer >=0 The requested maximum storage size in Gigabytes (GB). Definition node_types : tosca.nodes.ObjectStorage : abstract : true derived_from : tosca.nodes.Root description : > The TOSCA ObjectStorage node represents storage that provides the ability to store data as objects (or BLOBs of data) without consideration for the underlying filesystem or devices. tags : icon : /images/objectstore.png properties : store_name : type : string required : true description : The logical name of the object store (or container). store_size : type : integer constraints : - greater_or_equal : 0 description : The requested initial storage size in Gigabytes. store_maxsize : type : integer constraints : - greater_than : 0 description : The requested maximum storage size in Gigabytes. tosca.nodes.SoftwareComponent The TOSCA SoftwareComponent node represents a generic software component that can be managed and run by a TOSCA Compute Node Type. Properties Name Required Type Constraints Description version no version None The software component’s version. Definition node_types : tosca.nodes.SoftwareComponent : abstract : true derived_from : tosca.nodes.Root description : > The TOSCA SoftwareComponent Node Type represents a generic software component that can be managed and run by a TOSCA Compute Node Type. requirements : host : type : tosca.nodes.Compute relationship_type : tosca.relationships.HostedOn tags : icon : /images/software.png tosca.nodes.WebServer The TOSCA WebServer Node Type represents an abstract software component or service that is capable of hosting and providing management operations for one or more WebApplication nodes. Definition node_types : tosca.nodes.WebServer : abstract : true derived_from : tosca.nodes.SoftwareComponent description : > The TOSCA WebServer Node Type represents an abstract software component or service that is capable of hosting and providing management operations for one or more WebApplication nodes capabilities : http_endpoint : type : tosca.capabilities.Endpoint https_endpoint : type : tosca.capabilities.Endpoint host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.WebApplication ] tosca.nodes.WebApplication The TOSCA WebApplication node represents a software application that can be managed and run by a TOSCA WebServer node. Specific types of web applications such as Java, etc. could be derived from this type. Definition node_types : tosca.nodes.WebApplication : derived_from : tosca.nodes.Root description : > The TOSCA WebApplication node represents a software application that can be managed and run by a TOSCA WebServer node. Specific types of web applications such as Java, etc. could be derived from this type. requirements : host : type : tosca.nodes.WebServer relationship_type : tosca.relationships.HostedOn tosca.nodes.DBMS The TOSCA DBMS node represents a typical relational, SQL Database Management System software component or service. Properties Name Required Type Constraints Description dbms_port yes integer None The port the DBMS service will listen to for data and requests. dbms_root_password no string None The user account used for the DBMS administration. Definition node_types : tosca.nodes.DBMS : abstract : true derived_from : tosca.nodes.SoftwareComponent description : > The TOSCA DBMS node represents a typical relational, SQL Database Management System software component or service. tags : icon : /images/relational_db.png properties : dbms_root_password : type : string description : the root password for the DBMS service. dbms_port : type : integer description : the port the DBMS service will listen to for data and requests capabilities : host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.Database ] tosca.nodes.Database Base type for the schema and content associated with a DBMS. The TOSCA Database node represents a logical database that can be managed and hosted by a TOSCA DBMS node. Properties Name Required Type Constraints Description db_user yes string None The special user account used for database administration. db_password yes string None The password associated with the user account provided in the ‘db_user’ property. db_port yes integer None The port the database service will use to listen for incoming data and requests. db_name yes string None The logical database name. Definition node_types : tosca.nodes.Database : derived_from : tosca.nodes.Root description : > Base type for the schema and content associated with a DBMS. The TOSCA Database node represents a logical database that can be managed and hosted by a TOSCA DBMS node. tags : icon : /images/relational_db.png properties : db_user : type : string required : true description : The special user account used for database administration. db_password : type : string required : true description : The password associated with the user account provided in the ‘db_user’ property. db_name : type : string required : true description : The logical name of the database. "},{"title":"Nodes","baseurl":"","url":"/documentation/1.0.0/devops_guide/normative_types/tosca_concepts_types_normative_nodes.html","date":null,"categories":[],"body":"The nodes on this page follow the exact TOSCA normative types except the added tags section that we use in ALIEN to specify additional tags on a components. One of them being a specific tag that we use to package the icon that will be used in the UI for a given component. Normatives node types in TOSCA tosca.nodes.Root This is the Root TOSCA Node Type that other nodes extends from. This allows to have a consistent set of features for modeling and management (e.g., consistent definitions for requirements, capabilities and lifecycle interfaces). All Node Type definitions SHOULD extends from the TOSCA Root Node Type. This allows your custom nodes to be included in the default lifecycle generation (based on the root node lifecycle interface). Interfaces The Root node uses the lifecycle interface. See more informations on normative types lifecycle. Definition node_types : tosca.nodes.Root : abstract : true description : > This is the default (root) TOSCA Node Type that all other TOSCA nodes should extends. This allows all TOSCA nodes to have a consistent set of features for modeling and management (e.g, consistent definitions for requirements, capabilities, and lifecycle interfaces). tags : icon : /images/root.png requirements : dependency : type : tosca.capabilities.Root lower_bound : 0 upper_bound : unbounded interfaces : lifecycle : description : Default lifecycle for nodes in TOSCA. operations : create : description : Basic lifecycle create operation. configure : description : Basic lifecycle configure operation. start : description : Basic lifecycle start operation. stop : description : Basic lifecycle stop operation. delete : description : Basic lifecycle delete operation. tosca.nodes.Compute Represents a real or virtual machine or ‘server’. Informations specified on the Compute node will be used to find the machine that fits the given requirements in the cloud available machines. If no sizing informations are specified the cloud’s provider default machine will be used. It is strongly recommended to specify the required cpus and memory at least. Properties Name Required Type Constraints Description num_cpus no integer >= 1 Number of (actual or virtual) CPUs associated with the Compute node. disk_size no integer >=0 Size of the loal disk, in Gigabytes (GB), available to applications running on the Compute node. mem_size no integer >=0 Size of memory, in Megabytes (MB), available to applications running on the Compute node. os_arch yes string none The host Operating System (OS) architecture. Example of valid values includes: x86_32, x86_64, etc. os_type yes string none The hots Operating System (OS) type. Example of valid values includes: linux, windows, aix, macos, etc. os_distribution no string none The host Operating System (OS) distribution. Example of valid values includes: debian, fedora, rhel, and ubuntu os_version no string none  The host Operating System (OS) version. Attributes Name Required Type Description ip_address no string  The primary IP address assigned by the cloud provider that applications may use to access the Compute node. Definition node_types : tosca.nodes.Compute : derived_from : tosca.nodes.Root description : > Represents a real or virtual machine or ‘server’. Informations specified on the Compute node will be used to find the machine that fits the given requirements in the cloud available machines. If no sizing informations are specified the cloud’s provider default machine will be used. It is strongly recommended to specify the required cpus and memory at least. properties : num_cpus : type : integer constraints : - greater_than : 0 description : Number of (actual or virtual) CPUs associated with the Compute node. mem_size : type : integer constraints : - greater_than : 0 description : Size of memory, in Megabytes (MB), available to applications running on the Compute node. disk_size : type : integer constraints : - greater_than : 0 description : Size of the local disk, in Gigabytes (GB), available to applications running on the Compute node. os_arch : type : string required : true constraints : - valid_values : [ \"x86_32\" , \"x86_64\" ] description : The host Operating System (OS) architecture. os_type : type : string required : true constraints : - valid_values : [ \"linux\" , \"aix\" , \"mac os\" , \"windows\" ] description : The host Operating System (OS) type. os_distribution : type : string description : The host Operating System (OS) distribution. os_version : type : string description : The host Operating System version. attributes : ip_address : type : string description : > The primary IP address assigned by the cloud provider that applications may use to access the Compute node. Note: This is used by the platform provider to convey the primary address used to access the compute node. Future working drafts will address implementations that support floating or multiple IP addresses. capabilities : host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.SoftwareComponent ] tosca.nodes.BlockStorage The TOSCA BlockStorage node currently represents a server-local block storage device (i.e., not shared) offering evenly sized blocks of data from which raw storage volumes can be created. Properties Name Required Type Constraints Description size no string None The requested storage size in MegaBytes (MB). volume_id no integer >0 ID of an existing volume (that is in the accessible scope of the requesting application). snapshot_id no integer >0 Some identifier that represents an existing snapshot that should be used when creating the block storage (volume). Attributes Name Required Type Constraints Description volume_id no integer >0 ID provided by the orchestrator for newly created volumes. Definition node_types : tosca.nodes.BlockStorage : derived_from : tosca.nodes.Root description : > The TOSCA BlockStorage node currently represents a server-local block storage device (i.e., not shared) offering evenly sized blocks of data from which raw storage volumes can be created. tags : icon : /images/volume.png properties : size : type : integer constraints : - greater_than : 0 description : The requested storage size in MegaBytes (MB). volume_id : type : string description : ID of an existing volume (that is in the accessible scope of the requesting application). snapshot_id : type : string description : Some identifier that represents an existing snapshot that should be used when creating the block storage (volume). attributes : volume_id : type : string description : ID provided by the orchestrator for newly created volumes. requirements : attachment : type : tosca.capabilities.Attachment tosca.nodes.ObjectStorage The TOSCA ObjectStorage node represents storage that provides the ability to store data as objects (or BLOBs of data) without consideration for the underlying filesystem or devices. Properties Name Required Type Constraints Description store_name yes string None The logical name of the object store (or container). store_size no integer >=0 The requested initial storage size in Gigabytes (GB). store_maxsize no integer >=0 The requested maximum storage size in Gigabytes (GB). Definition node_types : tosca.nodes.ObjectStorage : abstract : true derived_from : tosca.nodes.Root description : > The TOSCA ObjectStorage node represents storage that provides the ability to store data as objects (or BLOBs of data) without consideration for the underlying filesystem or devices. tags : icon : /images/objectstore.png properties : store_name : type : string required : true description : The logical name of the object store (or container). store_size : type : integer constraints : - greater_or_equal : 0 description : The requested initial storage size in Gigabytes. store_maxsize : type : integer constraints : - greater_than : 0 description : The requested maximum storage size in Gigabytes. tosca.nodes.SoftwareComponent The TOSCA SoftwareComponent node represents a generic software component that can be managed and run by a TOSCA Compute Node Type. Properties Name Required Type Constraints Description version no version None The software component’s version. Definition node_types : tosca.nodes.SoftwareComponent : abstract : true derived_from : tosca.nodes.Root description : > The TOSCA SoftwareComponent Node Type represents a generic software component that can be managed and run by a TOSCA Compute Node Type. requirements : host : type : tosca.nodes.Compute relationship_type : tosca.relationships.HostedOn tags : icon : /images/software.png tosca.nodes.WebServer The TOSCA WebServer Node Type represents an abstract software component or service that is capable of hosting and providing management operations for one or more WebApplication nodes. Definition node_types : tosca.nodes.WebServer : abstract : true derived_from : tosca.nodes.SoftwareComponent description : > The TOSCA WebServer Node Type represents an abstract software component or service that is capable of hosting and providing management operations for one or more WebApplication nodes capabilities : http_endpoint : type : tosca.capabilities.Endpoint https_endpoint : type : tosca.capabilities.Endpoint host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.WebApplication ] tosca.nodes.WebApplication The TOSCA WebApplication node represents a software application that can be managed and run by a TOSCA WebServer node. Specific types of web applications such as Java, etc. could be derived from this type. Definition node_types : tosca.nodes.WebApplication : derived_from : tosca.nodes.Root description : > The TOSCA WebApplication node represents a software application that can be managed and run by a TOSCA WebServer node. Specific types of web applications such as Java, etc. could be derived from this type. requirements : host : type : tosca.nodes.WebServer relationship_type : tosca.relationships.HostedOn tosca.nodes.DBMS The TOSCA DBMS node represents a typical relational, SQL Database Management System software component or service. Properties Name Required Type Constraints Description dbms_port yes integer None The port the DBMS service will listen to for data and requests. dbms_root_password no string None The user account used for the DBMS administration. Definition node_types : tosca.nodes.DBMS : abstract : true derived_from : tosca.nodes.SoftwareComponent description : > The TOSCA DBMS node represents a typical relational, SQL Database Management System software component or service. tags : icon : /images/relational_db.png properties : dbms_root_password : type : string description : the root password for the DBMS service. dbms_port : type : integer description : the port the DBMS service will listen to for data and requests capabilities : host : type : tosca.capabilities.Container properties : valid_node_types : [ tosca.nodes.Database ] tosca.nodes.Database Base type for the schema and content associated with a DBMS. The TOSCA Database node represents a logical database that can be managed and hosted by a TOSCA DBMS node. Properties Name Required Type Constraints Description db_user yes string None The special user account used for database administration. db_password yes string None The password associated with the user account provided in the ‘db_user’ property. db_port yes integer None The port the database service will use to listen for incoming data and requests. db_name yes string None The logical database name. Definition node_types : tosca.nodes.Database : derived_from : tosca.nodes.Root description : > Base type for the schema and content associated with a DBMS. The TOSCA Database node represents a logical database that can be managed and hosted by a TOSCA DBMS node. tags : icon : /images/relational_db.png properties : db_user : type : string required : true description : The special user account used for database administration. db_password : type : string required : true description : The password associated with the user account provided in the ‘db_user’ property. db_name : type : string required : true description : The logical name of the database. "},{"title":"Relationships","baseurl":"","url":"/documentation/1.1.0/devops_guide/normative_types/tosca_concepts_types_normative_relationships.html","date":null,"categories":[],"body":"Normatives relationship types in TOSCA tosca.relationships.Root This is the default (root) TOSCA Relationship Type definition that all other TOSCA Relationship Types derive from. Definition tosca.relationships.Root : # The TOSCA root relationship type has no property mappings interfaces : tosca.interfaces.relationship.Configure : documentation : > Default lifecycle for nodes in TOSCA. operations : pre_configure_source : documentation : Operation to pre-configure the source endpoint. pre_configure_target : documentation : Operation to pre-configure the target endpoint. post_configure_source : documentation : Operation to post-configure the source endpoint. post_configure_target : documentation : Operation to post-configure the target endpoint. add_target : documentation : Operation to add a target node. remove_target : documentation : Operation to remove a target node. tosca.relationships.DependsOn This type represents a general dependency relationship between two nodes. Depends on impacts the TOSCA default lifecycle. A node that depends from a target node will be started after the target node has been actually started. Definition tosca.relationships.DependsOn : derived_from : tosca.relationships.Root valid_targets : [ tosca.capabilities.Root ] tosca.relationships.HostedOn This type represents a hosting relationship between two nodes. Definition tosca.relationships.HostedOn : derived_from : tosca.relationships.DependsOn valid_targets : [ tosca.capabilities.Container ] tosca.relationships.ConnectsTo This type represents a network connection relationship between two nodes. Definition tosca.relationships.ConnectsTo : derived_from : tosca.relationships.DependsOn valid_targets : [ tosca.capabilities.Endpoint ] tosca.relationships.AttachTo This type represents an attachment relationship between two nodes. For example, an AttachTo relationship type would be used for attaching a storage node to a Compute node. Properties Definition tosca.relationships.AttachTo : derived_from : tosca.relationships.Root valid_targets : [ tosca.capabilities.Attachement ] properties : location : type : string constraints : min_length : 1 device : type : string "},{"title":"Relationships","baseurl":"","url":"/documentation/1.0.0/devops_guide/normative_types/tosca_concepts_types_normative_relationships.html","date":null,"categories":[],"body":"Normatives relationship types in TOSCA tosca.relationships.Root This is the default (root) TOSCA Relationship Type definition that all other TOSCA Relationship Types derive from. Definition tosca.relationships.Root : # The TOSCA root relationship type has no property mappings interfaces : tosca.interfaces.relationship.Configure : documentation : > Default lifecycle for nodes in TOSCA. operations : pre_configure_source : documentation : Operation to pre-configure the source endpoint. pre_configure_target : documentation : Operation to pre-configure the target endpoint. post_configure_source : documentation : Operation to post-configure the source endpoint. post_configure_target : documentation : Operation to post-configure the target endpoint. add_target : documentation : Operation to add a target node. remove_target : documentation : Operation to remove a target node. tosca.relationships.DependsOn This type represents a general dependency relationship between two nodes. Depends on impacts the TOSCA default lifecycle. A node that depends from a target node will be started after the target node has been actually started. Definition tosca.relationships.DependsOn : derived_from : tosca.relationships.Root valid_targets : [ tosca.capabilities.Root ] tosca.relationships.HostedOn This type represents a hosting relationship between two nodes. Definition tosca.relationships.HostedOn : derived_from : tosca.relationships.DependsOn valid_targets : [ tosca.capabilities.Container ] tosca.relationships.ConnectsTo This type represents a network connection relationship between two nodes. Definition tosca.relationships.ConnectsTo : derived_from : tosca.relationships.DependsOn valid_targets : [ tosca.capabilities.Endpoint ] tosca.relationships.AttachTo This type represents an attachment relationship between two nodes. For example, an AttachTo relationship type would be used for attaching a storage node to a Compute node. Properties Definition tosca.relationships.AttachTo : derived_from : tosca.relationships.Root valid_targets : [ tosca.capabilities.Attachement ] properties : location : type : string constraints : min_length : 1 device : type : string "},{"title":"Workflows","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_concepts_workflows.html","date":null,"categories":[],"body":"TOSCA Specification defines the notion of Plans . Plans are basically workflows that the tosca container will be able to leverage to administrate the defined tosca application. The specification defines two basic workflow (plans): build : Used to instanciate and start a topology. terminate : Used to tear down a topology. In order to ease TOSCA usage the normative types specification include default lifecycle operations on node types and relationship types that can be used in order to automatically generate workflows (plans). This is why most of users won’t have to define plans. Workflow definition Workflow definition is inspired by BPMN2 but focus on required events, gateways and activities for TOSCA. The following section defines the available elements and the way to define them in a TOSCA Simple profile in YAML. Definition of elements is also adapted to match the TOSCA Simple profile in YAML concepts. Events Start event Every plan should start with the start event, if omitted the container will automatically add it as first element of the workflow. Graphical representation The following symbol represents the start event. Grammar workflows : <flow_id> : <id> : startEvent End event Every plan should finish with the end event, if omitted the container will automatically add it as last element of the workflow. Graphical representation The following symbol represents the end event. Grammar workflows : <flow_id> : <id> : endEvent Update State send message event Update the state of a node template or relationship template. Graphical representation The following symbol represents the end event. target: state Grammar workflows : <flow_id> : # Simple notation <id> : stateUpdate:<target>#<state> # Detailed notation <id> : stateUpdate : target : <target> state : <state> Update State receive message event Receive a state update to trigger next operation. Graphical representation The following symbol represents the end event. target: state Grammar workflows : <flow_id> : # Simple notation <id> : receiveStateUpdate:<target>#<state> # Detailed notation <id> : receiveStateUpdate : target : <target> state : <state> Activities The single activity a TOSCA plan can contains is a specific execute operation Task activity. Execute task Execute allows to execute an operation defined on an entity’s (node or relationship) interface. Graphical representation Grammar workflows : <flow_id> : # Simple notation <id> : execute : <target>#<interface>#<operation> # Detailed notation <id> : execute : target : <target> interface : <interface> operation : <operation> Gateways The only gateways used to define the TOSCA workflows is the parallel gateway. A parallel gateway can be diverging or converging. To ease configuration of the flow the two gateways are considered here a separate elements. Parallel Diverging gateway A parallel diverging gateway allows to specify subflows that will run concurrently. Note that if a task is specified in the flow after a Parallel Diverging Gateway, a Parallel Converging Gateway including all elements from the previous converging gateway is automatically added to the flow. Graphical representation Grammar workflows : <flow_id> : <id> : divergingGateway : <subflow_id_1> : <task_id>... <subflow_id_2> <task_id>... ... <subflow_id_n> <task_id>... Parallel Converging gateway A Parallel Converging gateway allows Graphical representation Grammar workflows : <flow_id> : <id> : convergingGateway : <id_1> <id_2> ... <id_n> "},{"title":"Workflows","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_concepts_workflows.html","date":null,"categories":[],"body":"TOSCA Specification defines the notion of Plans . Plans are basically workflows that the tosca container will be able to leverage to administrate the defined tosca application. The specification defines two basic workflow (plans): build : Used to instanciate and start a topology. terminate : Used to tear down a topology. In order to ease TOSCA usage the normative types specification include default lifecycle operations on node types and relationship types that can be used in order to automatically generate workflows (plans). This is why most of users won’t have to define plans. Workflow definition Workflow definition is inspired by BPMN2 but focus on required events, gateways and activities for TOSCA. The following section defines the available elements and the way to define them in a TOSCA Simple profile in YAML. Definition of elements is also adapted to match the TOSCA Simple profile in YAML concepts. Events Start event Every plan should start with the start event, if omitted the container will automatically add it as first element of the workflow. Graphical representation The following symbol represents the start event. Grammar workflows : <flow_id> : <id> : startEvent End event Every plan should finish with the end event, if omitted the container will automatically add it as last element of the workflow. Graphical representation The following symbol represents the end event. Grammar workflows : <flow_id> : <id> : endEvent Update State send message event Update the state of a node template or relationship template. Graphical representation The following symbol represents the end event. target: state Grammar workflows : <flow_id> : # Simple notation <id> : stateUpdate:<target>#<state> # Detailed notation <id> : stateUpdate : target : <target> state : <state> Update State receive message event Receive a state update to trigger next operation. Graphical representation The following symbol represents the end event. target: state Grammar workflows : <flow_id> : # Simple notation <id> : receiveStateUpdate:<target>#<state> # Detailed notation <id> : receiveStateUpdate : target : <target> state : <state> Activities The single activity a TOSCA plan can contains is a specific execute operation Task activity. Execute task Execute allows to execute an operation defined on an entity’s (node or relationship) interface. Graphical representation Grammar workflows : <flow_id> : # Simple notation <id> : execute : <target>#<interface>#<operation> # Detailed notation <id> : execute : target : <target> interface : <interface> operation : <operation> Gateways The only gateways used to define the TOSCA workflows is the parallel gateway. A parallel gateway can be diverging or converging. To ease configuration of the flow the two gateways are considered here a separate elements. Parallel Diverging gateway A parallel diverging gateway allows to specify subflows that will run concurrently. Note that if a task is specified in the flow after a Parallel Diverging Gateway, a Parallel Converging Gateway including all elements from the previous converging gateway is automatically added to the flow. Graphical representation Grammar workflows : <flow_id> : <id> : divergingGateway : <subflow_id_1> : <task_id>... <subflow_id_2> <task_id>... ... <subflow_id_n> <task_id>... Parallel Converging gateway A Parallel Converging gateway allows Graphical representation Grammar workflows : <flow_id> : <id> : convergingGateway : <id_1> <id_2> ... <id_n> "},{"title":"Workflow generation","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_concepts_workflows_default.html","date":null,"categories":[],"body":"TOSCA containers uses the default normative types to automatically generate a default workflow. This ease the definition of TOSCA topologies as in most of situations entities are extending from tosca.nodes.Root and tosca.relationships.Root . This section details how the default workflow is generated. "},{"title":"Workflow generation","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_concepts_workflows_default.html","date":null,"categories":[],"body":"TOSCA containers uses the default normative types to automatically generate a default workflow. This ease the definition of TOSCA topologies as in most of situations entities are extending from tosca.nodes.Root and tosca.relationships.Root . This section details how the default workflow is generated. "},{"title":"Normative Lifecycle","baseurl":"","url":"/documentation/1.1.0/devops_guide/tosca_normative_lifecycle.html","date":null,"categories":[],"body":"TOSCA normative lifecycle is automatically generated by the TOSCA container based on the normative node and relationship types. Note that the TOSCA specification on lifecycle is still being written so this may be subject to changes before v1 release. Lifecycle is based on the normative node interface (tosca.interfaces.node.lifecycle.Standard) and relationship interface (tosca.interfaces.relationship.Configure). Node Lifecycle generation wait for all node that is a target of a DependsOn relationship to reach the started state (current node being source of the relationship). call the node’s create operation call the relationships pre_configure_source (if the node is the relationship source) or pre_configure_target (if the node is the relationship target) call the node’s configure operation call the relationships post_configure_source (if the node is the relationship source) or post_configure_target (if the node is the relationship target) call the node’s start operation call the relationships add_target (on the nodes sources) and add_source (on the nodes targets) operations. "},{"title":"Normative Lifecycle","baseurl":"","url":"/documentation/1.0.0/devops_guide/tosca_normative_lifecycle.html","date":null,"categories":[],"body":"TOSCA normative lifecycle is automatically generated by the TOSCA container based on the normative node and relationship types. Note that the TOSCA specification on lifecycle is still being written so this may be subject to changes before v1 release. Lifecycle is based on the normative node interface (tosca.interfaces.node.lifecycle.Standard) and relationship interface (tosca.interfaces.relationship.Configure). Node Lifecycle generation wait for all node that is a target of a DependsOn relationship to reach the started state (current node being source of the relationship). call the node’s create operation call the relationships pre_configure_source (if the node is the relationship source) or pre_configure_target (if the node is the relationship target) call the node’s configure operation call the relationships post_configure_source (if the node is the relationship source) or post_configure_target (if the node is the relationship target) call the node’s start operation call the relationships add_target (on the nodes sources) and add_source (on the nodes targets) operations. "},{"title":"Create your own components","baseurl":"","url":"/documentation/1.0.0/devops_guide/design_tutorial/tutorials.html","date":null,"categories":[],"body":" This documentation section is not complete. We recommend you to start with the lamp stack tutorials that have been upgraded more recently. Components Design of a component (Tomcat server) Implementation of a component Topologies Designing a topology in ALIEN Application Creation of an application and running it on a cloud using cloudify PaaS "},{"title":"Create your own components","baseurl":"","url":"/documentation/1.1.0/devops_guide/design_tutorial/tutorials.html","date":null,"categories":[],"body":" This documentation section is not complete. We recommend you to start with the lamp stack tutorials that have been upgraded more recently. Components Design of a component (Tomcat server) Implementation of a component Topologies Designing a topology in ALIEN Application Creation of an application and running it on a cloud using cloudify PaaS "},{"title":"Component design","baseurl":"","url":"/documentation/1.1.0/devops_guide/design_tutorial/tutorials_component_design.html","date":null,"categories":[],"body":"Target: Middleware experts, architects, operations teams. Goal: Explain how to start with component design. In this tutorial, the component we will focus on is Tomcat Application Server. Define the node type A component in ALIEN is a tosca node type. Information on TOSCA and the grammar can be found on OASIS TC pages and in ALIEN documentation in the components section. This tutorial doesn’t focus on the grammar but on the methodology to define components. The first step to define the component is to define it’s id. In our case, we will define a ‘fastconnect.nodes.Tomcat’ node. This component will be abstract as we don’t plan to include an implementation for now (another member of the team may provide an implementation). More, while an implementation may not be compliant with any Operating System (Linux shell scripts that won’t run on windows) or PaaS (Cloudify specific scripts) etc. The abstract type allows to define an agnostic view of the middleware. A same node may have different implementations, for example a Tomcat Node may have an implementation based on puppet and another based on chef, or even pure shell script. Definition of abstract types is also a good way also to provide separation of concern and to let an Architect define a middleware and let the implementation to the experts. Second step when defining a node is to find from which parent type it should extends, it can be an existing type already uploaded in ALIEN or one of TOSCA normative type . There is multiple reasons to extends from the normative types (or another type that itself extends from a normative type): Workflow automatic generation is based on the fact that the node uses the default lifecycle interfaces that are defined on the normative types. Using normative types is also a good way to leverage ALIEN 4 Cloud facet search (for example I will be able to filter on all ApplicationServer nodes). Finally extending from normative types allows to bootstrap your node with some properties, capabilities and requirements. For example as our Tomcat extends from tosca.nodes.SoftwareComponents it will have a version property that should be specified a host requirement (as a software component must be installed on a compute node). the default feature requirement and relationship that are used to established depends on relationships (to impact the lifecycle generation). In the case of a Tomcat server the normative type that we should extends from is tosca.nodes.ApplicationServer . This node extends itself from tosca.nodes.SoftwareComponents . fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). It is possible here to create another parent abstract type that supports any Java Application Server. This would allow for any Java Application Server to just extends from the node and leverage common properties, requirements and capabilties (Java requirement, War capability, Java arguments properties etc.). Extension is not mandatory as this will just allow to simplify the definition of multiple bean but will not impact the topology creation. In order to keep this tutorial simple we will just extend our Tomcat from the tosca.nodes.ApplicationServer node type. Properties The first property we want to define is the version of tomcat that this tomcat definition supports. Indeed all the tomcat versions doesn’t have the same capabilities, for example tomcat 7.x supports web-sockets while this is not supported in tomcat 5.x for example. Version property as stated earlier is already defined in SoftwareComponent, it is possible however to override it to add an additional constraint. In this example we want to describe a tomcat node for all versions 7 so we will redefine the version property (with the same version type) and add constraints . Second property that we want to add in this tutorial is the java options to use to startup the Tomcat server. This will allow users to specify the java memory requirements and garbage collection settings. Name Type Required Default Constraints version version true 7 Between 7 (inclusive) and 8 exclusive java_ops string false None None fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string Tomcat node with the version between [7 and 8) Of course we could add more properties to the tomcat node in order to allow configuration of other server related properties. In this tutorial we will just use the properties mentioned above. Note that as ALIEN supports the versioning of the archives it is easy to add properties later in a next version of the component. Requirements Next important section to describe on the Tomcat type is the list of requirements. As Tomcat inherit from SoftwareComponent it has an inherited requirement over a Compute node (this requirement can be fulfilled in a topology by using an hosted_on relationship). The other requirement for a Tomcat node is to have a java installed. We will model this by adding a java requirement to the tomcat node. A requirements can express constraints on some of the target capability or node, properties. Here we reference a requirement on a Java Node and specify a constraint on the version of the java node. Name Type Lower bound Upper bound Constraints Notes host tosca.nodes.Compute 1 (default) 1 (default)   Inherited from tosca.nodes.SoftwareComponent java fastconnect.nodes.Java 1 (default) 1 (default) Greater or equal than 7   fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string requirements : java : type : fastconnect.nodes.Java constraints : version : { greater_or_equal : 1.7 } Tomcat node inherit from the requirement on a hosting compute node that is defined by the SoftwareComponent TOSCA normative node. Here we define an abstract Tomcat node that doesn’t have any specific requirement for the compute node (os type etc.) so we don’t have to override the parent requirement. Of course it is possible to override a parent requirement to specify more advanced constraints. Capabilities Tomcat has multiple capabilities and the two main capabilities that we want to define in this tutorial are the ability to hort some War node(s) on top of Tomcat as well as it’s http endpoint. Name Type Lower bound Upper bound http tosca.capabilities.Endpoint 0 (default) unbounded (default) war_host fastconnect.nodes.War 0 (default) unbounded (default) In case of the http capability we want to define the port of the tosca.capabilties.Endpoint to be actually the one define in the fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string requirements : java : type : fastconnect.nodes.Java constraints : version : { greater_or_equal : 1.7 } capabilties : http : type : tosca.capabilities.Endpoint properties : port : 8080 war_host : type : fastconnect.capabilities.War Conclusion Following the tutorial you should be able to define your own types to be added in ALIEN repository. TOSCA’s requirement and capabilties mechanisms as well as constraint validations allows users to leverage your types so they can easily build topologies and minimize errors in configurations. The next step is to actually implement the type in order to have a type that can indeed be instantiated in a topology. "},{"title":"Component design","baseurl":"","url":"/documentation/1.0.0/devops_guide/design_tutorial/tutorials_component_design.html","date":null,"categories":[],"body":"Target: Middleware experts, architects, operations teams. Goal: Explain how to start with component design. In this tutorial, the component we will focus on is Tomcat Application Server. Define the node type A component in ALIEN is a tosca node type. Information on TOSCA and the grammar can be found on OASIS TC pages and in ALIEN documentation in the components section. This tutorial doesn’t focus on the grammar but on the methodology to define components. The first step to define the component is to define it’s id. In our case, we will define a ‘fastconnect.nodes.Tomcat’ node. This component will be abstract as we don’t plan to include an implementation for now (another member of the team may provide an implementation). More, while an implementation may not be compliant with any Operating System (Linux shell scripts that won’t run on windows) or PaaS (Cloudify specific scripts) etc. The abstract type allows to define an agnostic view of the middleware. A same node may have different implementations, for example a Tomcat Node may have an implementation based on puppet and another based on chef, or even pure shell script. Definition of abstract types is also a good way also to provide separation of concern and to let an Architect define a middleware and let the implementation to the experts. Second step when defining a node is to find from which parent type it should extends, it can be an existing type already uploaded in ALIEN or one of TOSCA normative type . There is multiple reasons to extends from the normative types (or another type that itself extends from a normative type): Workflow automatic generation is based on the fact that the node uses the default lifecycle interfaces that are defined on the normative types. Using normative types is also a good way to leverage ALIEN 4 Cloud facet search (for example I will be able to filter on all ApplicationServer nodes). Finally extending from normative types allows to bootstrap your node with some properties, capabilities and requirements. For example as our Tomcat extends from tosca.nodes.SoftwareComponents it will have a version property that should be specified a host requirement (as a software component must be installed on a compute node). the default feature requirement and relationship that are used to established depends on relationships (to impact the lifecycle generation). In the case of a Tomcat server the normative type that we should extends from is tosca.nodes.ApplicationServer . This node extends itself from tosca.nodes.SoftwareComponents . fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). It is possible here to create another parent abstract type that supports any Java Application Server. This would allow for any Java Application Server to just extends from the node and leverage common properties, requirements and capabilties (Java requirement, War capability, Java arguments properties etc.). Extension is not mandatory as this will just allow to simplify the definition of multiple bean but will not impact the topology creation. In order to keep this tutorial simple we will just extend our Tomcat from the tosca.nodes.ApplicationServer node type. Properties The first property we want to define is the version of tomcat that this tomcat definition supports. Indeed all the tomcat versions doesn’t have the same capabilities, for example tomcat 7.x supports web-sockets while this is not supported in tomcat 5.x for example. Version property as stated earlier is already defined in SoftwareComponent, it is possible however to override it to add an additional constraint. In this example we want to describe a tomcat node for all versions 7 so we will redefine the version property (with the same version type) and add constraints . Second property that we want to add in this tutorial is the java options to use to startup the Tomcat server. This will allow users to specify the java memory requirements and garbage collection settings. Name Type Required Default Constraints version version true 7 Between 7 (inclusive) and 8 exclusive java_ops string false None None fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string Tomcat node with the version between [7 and 8) Of course we could add more properties to the tomcat node in order to allow configuration of other server related properties. In this tutorial we will just use the properties mentioned above. Note that as ALIEN supports the versioning of the archives it is easy to add properties later in a next version of the component. Requirements Next important section to describe on the Tomcat type is the list of requirements. As Tomcat inherit from SoftwareComponent it has an inherited requirement over a Compute node (this requirement can be fulfilled in a topology by using an hosted_on relationship). The other requirement for a Tomcat node is to have a java installed. We will model this by adding a java requirement to the tomcat node. A requirements can express constraints on some of the target capability or node, properties. Here we reference a requirement on a Java Node and specify a constraint on the version of the java node. Name Type Lower bound Upper bound Constraints Notes host tosca.nodes.Compute 1 (default) 1 (default)   Inherited from tosca.nodes.SoftwareComponent java fastconnect.nodes.Java 1 (default) 1 (default) Greater or equal than 7   fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string requirements : java : type : fastconnect.nodes.Java constraints : version : { greater_or_equal : 1.7 } Tomcat node inherit from the requirement on a hosting compute node that is defined by the SoftwareComponent TOSCA normative node. Here we define an abstract Tomcat node that doesn’t have any specific requirement for the compute node (os type etc.) so we don’t have to override the parent requirement. Of course it is possible to override a parent requirement to specify more advanced constraints. Capabilities Tomcat has multiple capabilities and the two main capabilities that we want to define in this tutorial are the ability to hort some War node(s) on top of Tomcat as well as it’s http endpoint. Name Type Lower bound Upper bound http tosca.capabilities.Endpoint 0 (default) unbounded (default) war_host fastconnect.nodes.War 0 (default) unbounded (default) In case of the http capability we want to define the port of the tosca.capabilties.Endpoint to be actually the one define in the fastconnect.nodes.Tomcat : abstract : true derived_from : tosca.nodes.ApplicationServer documentation : Tomcat application server is an application server that supports deployment of java web applications (war). properties : version : type : version constraints : - greater_or_equal : 7 - less_than : 8 java_ops : type : string requirements : java : type : fastconnect.nodes.Java constraints : version : { greater_or_equal : 1.7 } capabilties : http : type : tosca.capabilities.Endpoint properties : port : 8080 war_host : type : fastconnect.capabilities.War Conclusion Following the tutorial you should be able to define your own types to be added in ALIEN repository. TOSCA’s requirement and capabilties mechanisms as well as constraint validations allows users to leverage your types so they can easily build topologies and minimize errors in configurations. The next step is to actually implement the type in order to have a type that can indeed be instantiated in a topology. "},{"title":"Component implementation","baseurl":"","url":"/documentation/1.0.0/devops_guide/design_tutorial/tutorials_component_implementation.html","date":null,"categories":[],"body":"Target: Middleware experts, operations teams. Goal: Explain how to implement a type. This tutorial follows the component design tutorial and we will describe how to implement the component designed in the previous tutorial. In this tutorial we also covers how the component archive can be added and tested through ALIEN. Pre-requisite: A git repository will hold the source code for the component archive. We will also use a Jenkins CI instance in order to demonstrate how we can continuously test our archives and develop components following quality best-practices. Prepare the archive Elements in TOSCA and ALIEN are defined in definitions files that can be packed in a Cloud Service Archive (CSAR). The first task therefore is to prepare the directory structure of our Cloud Service Archive. Then we create a tomcat-definition.yml file that will contain the actual tomcat node type definition. Before starting to fill-in the file we will first create the ALIEN-META.yaml file that must be in the TOSCA-Metadata folder of our archive directory structure. This file defines the archive name and version as well as the location of the definitions files that the archive contains. This is the entry point of the archive. The content of the file is the following: # Define the current archive id and version. name : \"fastconnect-tomcat-types\" version : \"1.0\" license : \"Apache v2.0\" created_by : \"FastConnect\" # List of definitions file in the archive. definitions : - /Definitions/tomcat-definition.yml Now that we have a cloud service archive with a definition file, we can edit it to define TOSCA elements. In our case we will focus on creating types. When creating type it is important to correctly defines the meta-informations of the type, and to try to reuse existing nodes, capabilities and requirements. "},{"title":"Component implementation","baseurl":"","url":"/documentation/1.1.0/devops_guide/design_tutorial/tutorials_component_implementation.html","date":null,"categories":[],"body":"Target: Middleware experts, operations teams. Goal: Explain how to implement a type. This tutorial follows the component design tutorial and we will describe how to implement the component designed in the previous tutorial. In this tutorial we also covers how the component archive can be added and tested through ALIEN. Pre-requisite: A git repository will hold the source code for the component archive. We will also use a Jenkins CI instance in order to demonstrate how we can continuously test our archives and develop components following quality best-practices. Prepare the archive Elements in TOSCA and ALIEN are defined in definitions files that can be packed in a Cloud Service Archive (CSAR). The first task therefore is to prepare the directory structure of our Cloud Service Archive. Then we create a tomcat-definition.yml file that will contain the actual tomcat node type definition. Before starting to fill-in the file we will first create the ALIEN-META.yaml file that must be in the TOSCA-Metadata folder of our archive directory structure. This file defines the archive name and version as well as the location of the definitions files that the archive contains. This is the entry point of the archive. The content of the file is the following: # Define the current archive id and version. name : \"fastconnect-tomcat-types\" version : \"1.0\" license : \"Apache v2.0\" created_by : \"FastConnect\" # List of definitions file in the archive. definitions : - /Definitions/tomcat-definition.yml Now that we have a cloud service archive with a definition file, we can edit it to define TOSCA elements. In our case we will focus on creating types. When creating type it is important to correctly defines the meta-informations of the type, and to try to reuse existing nodes, capabilities and requirements. "},{"title":"UI plugins","baseurl":"","url":"/developer_guide/ui_plugins.html","date":null,"categories":[],"body":""},{"title":"User Guide","baseurl":"","url":"/documentation/1.0.0/user_guide/user_guide.html","date":null,"categories":[],"body":"Welcome to Alien’s user guide! This section will explain you how to use Alien 4 Cloud it is organized based on the concepts but you can find below links to sections you may be interested in based on the roles you have. As a Platform admin you probably should read first the Administration Guide in order to install and setup Alien 4 Cloud. Once done you will be interested in Plugin management as well a Cloud management . As a Dev-Ops we suggest you to read the Components management section and to get familiar with TOSCA reference you can also look at our LAMP Stack Tutorial that provides a good kickoff on building components with TOSCA. "},{"title":"User Guide","baseurl":"","url":"/documentation/1.1.0/user_guide/user_guide.html","date":null,"categories":[],"body":"Welcome to Alien’s user guide! This section will explain you how to use Alien 4 Cloud it is organized based on the concepts but you can find below links to sections you may be interested in based on the roles you have. As a Platform admin you probably should read first the Administration Guide in order to install and setup Alien 4 Cloud. Once done you will be interested in Plugin management as well a Cloud management . As a Dev-Ops we suggest you to read the Components management section and to get familiar with TOSCA reference you can also look at our LAMP Stack Tutorial that provides a good kickoff on building components with TOSCA. "},{"title":"User management","baseurl":"","url":"/admin_guide/user_management.html","date":null,"categories":[],"body":"This section details Alien 4 Cloud’s ROLES and permissions by role. General Alien 4 Cloud roles This role list describes basic roles you can grant to a user. From his/her roles Alien 4 Cloud will display and allow some operations. For example, the navigation bar on top is configured regarding the user roles : Role Description ADMIN Manages users, plugins, configure clouds + all other roles. APPLICATIONS_MANAGER Create new application(s). ARCHITECT Create and edit topology template(s). COMPONENTS_BROWSER Can list components and see details for any of them COMPONENTS_MANAGER COMPONENTS_BROWSER rights + upload a CSAR archive to add components A user with no roles can log-in and view the resources for which he has been granted. For example a user with no roles but being listed as user in an application, can look at this application and do any operations he is authorized to perform for the application. Application’s roles This role list defines actions allowed by role on a given application : Role Description APPLICATION_MANAGER Almost all operations on his proper application. By default an application manager will also have deploy / undeploy right APPLICATION_USER Basic access like read (see details), search and get application’s status APPLICATION_DEVOPS APPLICATION_USER rights + topology handling DEPLOYMENT_MANAGER Mainly deploy / undeploy an application and basic access to a topology Application’s rights grid ( A )   APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER create         read X X X X search X X X X delete X       updateImage X       upsertTag X       deleteTag X       deploy       X undeploy       X getDeploymentStatus X X X X addApplicationUserRole X       removeApplicationUserRole X       Topologies’s rights grid ( T )   APPLICATION_MANAGER APPLICATION_USER APPLICATION_DEVOPS DEPLOYMENT_MANAGER create X       get X   X X addNodeTemplate X   X   updateNodeTemplateName X   X   addRelationshipTemplate X   X   deleteNodeTemplate X   X   updatePropertyValue X   X   isDeployable X     X Operations list A. Application’s operations create : Create a new application in the system read : Get an application based from its id search : Search for applications delete : Delete an application from its id updateImage : Application’s image update upsertTag : Update/Create a tag for the application deleteTag : Delete a tag for the application deploy : Deploys the application on the configured PaaS undeploy : Un-Deploys the application on the configured PaaS. getDeploymentStatus : Get the current status of the application on the PaaS addApplicationUserRole : Add a role to a user on a specific application removeApplicationUserRole : Remove a role to a user on a specific application T. Topologies’s operations create : Create a new empty topology get : Retrieve a topology from its id addNodeTemplate : Add a new node template in a topology updateNodeTemplateName : Change the name of a node template in a topology addRelationshipTemplate : Add a relationship to a node template deleteNodeTemplate : Delete a node tempalte from a topology updatePropertyValue : Update properties values isDeployable : Check if a topology is deployable or not "},{"title":"User(s) and Roles management","baseurl":"","url":"/documentation/1.1.0/user_guide/user_management.html","date":null,"categories":[],"body":" LDAP integration If you wish to integrate with an LDAP directory please go here . Note that you can use LDAP for users and eventually role management. You can also manage roles in Alien even for LDAP user if you wish. In addition you can have users managed in LDAP and create some additional user that will be managed within Alien. Roles In order to edit users in Alien 4 Cloud you must have the ADMIN role. Default username and password when starting alien 4 cloud are admin / admin User(s) In order to manage users go the to page by clicking on the button in the navigation bar. Then click on the user tab of the administration side navigation bar or on the user main icon. The user page allows you to manage both users and groups. On the user tab you can search users and see the list of users matching your request. Create user In order to create a new user within Alien just click on the New User button . The create user modal appears and allows you fill-in initial data for your user. Admin is responsible for setting up the username (that will be used for login) and the password of the user. Limitations We are working on adding the ability for a user to edit it’s details but this is currently not an available feature. Changing user details can now be done only by an ADMIN user through the REST API. Of course when using LDAP integration the password are managed by LDAP and there is no requirement for any management in Alien. Search user Remove user Grant role(s) to a user Group(s) Create a group To create a new group within Alien just click on Add/Remove a user to/from a group Roles in Alien 4 Cloud To understand the roles concept, please refer to this section . These roles describes global roles you can grant to a user. From his/her roles Alien 4 Cloud will display and allow some operations. Role Description ADMIN Manages users, plugins, configure clouds + all other roles. APPLICATIONS_MANAGER Create new application(s). ARCHITECT Create and edit topology template(s). COMPONENTS_BROWSER [Deprecated] Not used anymore for validation. Can list components and see details for any of them COMPONENTS_MANAGER Manage TOSCA cloud service archives to add/remove components from the catalog. A user with no roles can log-in and view the resources for which he has been granted. For example a user with no global roles can still access and manage applications on which he has resources roles (see application and environments roles). "},{"title":"User(s) and Roles management","baseurl":"","url":"/documentation/1.0.0/user_guide/user_management.html","date":null,"categories":[],"body":" LDAP integration If you wish to integrate with an LDAP directory please go here . Note that you can use LDAP for users and eventually role management. You can also manage roles in Alien even for LDAP user if you wish. In addition you can have users managed in LDAP and create some additional user that will be managed within Alien. Roles In order to edit users in Alien 4 Cloud you must have the ADMIN role. Default username and password when starting alien 4 cloud are admin / admin User(s) In order to manage users go the to page by clicking on the button in the navigation bar. Then click on the user tab of the administration side navigation bar or on the user main icon. The user page allows you to manage both users and groups. On the user tab you can search users and see the list of users matching your request. Create user In order to create a new user within Alien just click on the New User button . The create user modal appears and allows you fill-in initial data for your user. Admin is responsible for setting up the username (that will be used for login) and the password of the user. Limitations We are working on adding the ability for a user to edit it’s details but this is currently not an available feature. Changing user details can now be done only by an ADMIN user through the REST API. Of course when using LDAP integration the password are managed by LDAP and there is no requirement for any management in Alien. Search user Remove user Grant role(s) to a user Group(s) Create a group To create a new group within Alien just click on Add/Remove a user to/from a group Roles in Alien 4 Cloud To understand the roles concept, please refer to this section . These roles describes global roles you can grant to a user. From his/her roles Alien 4 Cloud will display and allow some operations. Role Description ADMIN Manages users, plugins, configure clouds + all other roles. APPLICATIONS_MANAGER Create new application(s). ARCHITECT Create and edit topology template(s). COMPONENTS_BROWSER [Deprecated] Not used anymore for validation. Can list components and see details for any of them COMPONENTS_MANAGER Manage TOSCA cloud service archives to add/remove components from the catalog. A user with no roles can log-in and view the resources for which he has been granted. For example a user with no global roles can still access and manage applications on which he has resources roles (see application and environments roles). "},{"title":"What's new in 1.1.0 ?","baseurl":"","url":"/documentation/1.1.0/whatsnew.html","date":null,"categories":[],"body":" Orchestrator and Locations “Cloud” concept as it existed in 1.0.0 has been replaced by Orchestrator and Location concepts that reflects in a better way our actual supports. “Cloud” name was also not a great choice as it could refer to a “cloud” but also to some BYON deployments for example that people doesn’t really consider as clouds (even if that may be discussed). Anyway “location” sounds much better and can be easily understood. The refactoring also allows to give a much nicer support for orchestrators that can deploy to multiple locations (like Apache Brooklyn) and bring great features and openings like the Location Matching. It was also a mandatory step to open us to multi-location deployments and other very cool features that we want to support in future releases. More details on Orchestrators and Locations are provided in the Concept section. Location matching Location matching allows to match a topology against locations and provide choices of the best locations for the topology. Default implementation is simple and just provides all locations on which the current user has the deployer role. Plugin system allows to create advanced location matching, overriding the location matching logic and event the choice selection ui. Node matching Node matching is an existing feature of Alien 4 Cloud but 1.1.0 introduce more possibilities thanks to the location refactoring and related custom types. Moreover node matching is now pluggable so you can override our logic with more advanced or custom logic. Custom Workflows BlockStorage support Block storage support has changed in 1.1.0. In 1.0.0 when a block storage was defined and attached to a Compute node in a topology, the storage was automatically attached, partitioned, formatted and mounted. This behavior has changed and the Block Storage is now attached but neither partitioned, formatted and mounted. In order to do so we created a separate TOSCA node LinuxFileSystem (right now available for linux only). TOSCA support improvements We have upgraded our normative types support to be closer to TOSCA. In 1.1.0 we recommend people to use the following version of the normative types: “1.1.0.wd06.alien”. It basically is a version derived from the TOSCA Simple Profile in YAML Working Draft 06 to match our Alien TOSCA like DSL (there is still some effort planned for 1.2.0 to increase TOSCA support). Deprecated usages Addition to TOSCA We received complains and realized also on our end that TOSCA currently has some limitations that makes quite complex to manage some modelings. As TOSCA doesn’t have yet an API to access the runtime model from scripts (both to read and update attributes for example) it leverage the definition of inputs on the scripts and get_attribute or get_properties functions. This model is very nice as people don’t have to build TOSCA clients or uses REST calls but can just expect the TOSCA orchestrator to retrieve attributes for them. Using get_attribute and get_property in conjunction with inputs does a pretty good job. Our main complain however is related to the get_operation_output function. Cloudify 2 End Of Life GigaSpaces doesn’t support cloudify 2 anymore, as a consequence we stopped investing efforts on our cloudify 2 provider and it won’t work with alien 1.1.0. Hopefully if all your artifacts uses only portable scripts and no orchestrator specific logic migration to cloudify 3 should not be painful for you! "}]}