incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "AriaProposal" by ArthurBerezin
Date Fri, 22 Jul 2016 16:48:01 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "AriaProposal" page has been changed by ArthurBerezin:
https://wiki.apache.org/incubator/AriaProposal?action=diff&rev1=9&rev2=10

- 
  === Abstract ===
  AIRA’s mission statement is to drive the adoption of TOSCA by offering an easily consumable
Software Development Kit(SDK) and a Command Line Interface(CLI) to implement TOSCA based solutions
which will help in market consolidation around TOSCA based Orchestration.
  One of the key attributes of the TOSCA specification by OASIS is that it is a vendor neutral
and technology agnostic specification, allowing to describe applications and then to orchestrate
them using various technologies of choice, such as Amazon AWS, Google GCP, OpenStack, VMware,
Puppet, Ansible Chef, etc’. 
@@ -16, +15 @@

  ARIA aims to implement several main use cases, and can be used as a command line tool to
orchestrate TOSCA based application templates serving as a lightweight tool to onboard and
orchestrate applications in a repeatable and robust manner. ARIA can be used by software vendors
and VNF providers as a development environment for creating TOSCA templates for onboarding
and managing the lifecycle of software products and Virtual Network Functions(VNFs). 
  Additionally ARIA can be used for building orchestration platforms and enabling TOSCA based
orchestration using the ARIA TOSCA orchestration engine as the kernel of the orchestrator.
  
- ‘’’ ARIA TOSCA Parser ‘’’
+ ''' ARIA TOSCA Parser '''
  ARIA includes a TOSCA DSL parser, the parser’s role is to interpret the TOSCA template,
create an in-memory graph of the application and validate templates’ correctness. TOSCA
provides a type system of normative node types to describe the possible building blocks for
constructing a service template, as well as relationship types to describe possible kinds
of relations. Both node and relationship types may define lifecycle operations to implement
the behavior an orchestration engine can invoke when instantiating a service template. The
template files are written in declarative YAML language using TOSCA normative types. Technology
specific types can be introduced via ARIA Plugins without any modifications of the parser
code. 
  
  TOSCA Templates include: 
- YAML Topology Template
+ - YAML Topology Template
- Plugins  
+ - Plugins  
- Workflows
+ - Workflows
- Resources such as scripts, etc’
+ - Resources such as scripts, etc’
  
- ‘’’ ARIA Plugins ’’’
+ ''' ARIA Plugins '''
  ARIA Plugins allow extending the TOSCA normative types dynamically by adding new technology
specific node types and relationship types with their implementation, without changing the
code of the ARIA TOSCA Parser. The plugin based types are isolated, allowing different versions
of the same plugin in a single blueprint - for example support OpenStack Kilo and OpenStack
Juno in the same template. It also allows combining types of different technologies - for
example OpenStack nodes with VMware, Amazon, or other types such as Router, Firewall, Kubernetes
and others. The work of interacting with IaaS APIs and running scripts, Configuration Management
tools, Monitoring tools and any other tools used when managing applications is done by the
ARIA Plugins. 
  Plugins can be included as part of the application template package and loaded dynamically.

  ARIA includes plugins that can be used as is or as reference for implementing for new plugins,

- ARIA Includes plugins for the following 
+ ARIA Includes plugins for the following:
- Plugins for IAAS: OpenStack, AWS, VMWAre, GCP Azure 
+ - Plugins for IAAS: OpenStack, AWS, VMWAre, GCP Azure 
- Plugins for CM: Puppet, Chef, Ansible, SaltStack
+ - Plugins for CM: Puppet, Chef, Ansible, SaltStack 
- Plugins for Containers: Kubernetes, Docker, Mesos, Swarm 
+ - Plugins for Containers: Kubernetes, Docker, Mesos, Swarm 
- Plugins for SDN: ODL, ONOS 
+ - Plugins for SDN: ODL, ONOS
- Script Plugin: Bash, Python others 
+ - Script Plugin: Bash, Python others
- Fabric Plugin via SSH 
+ - Fabric Plugin via SSH 
- Custom Plugin 
+ - Custom Plugins
+  
- ‘’’ ARIA Embedded Workflows ‘’’
+ '''ARIA Embedded Workflows'''
  Workflows are automated process algorithms that allow to interact dynamically with the graph
described in the application topology template. Workflows describe the flow of the automation
by determining which tasks will be executed and when. A task may be an operation, optionally
implemented by a plugin, but it may also be other actions, including arbitrary code or scripts.
Workflows can be embedded within the TOSCA Template to be able to access the graph dynamically.
They are implemented as Python code using dedicated APIs and a framework to access the graph
context, the context provide access to the object graph described in the TOSCA template.
  ARIA comes with a number of built-in workflows - these are the workflows for install, uninstall,
scale and heal. Additionally it is possible to write custom workflows. Built-in workflows
are not special in any way - they use the same API and framework as any custom workflow is
able to use.  
  
@@ -61, +61 @@

  === Current Status ===
  ARIA 0.1 release with it’s initial code is based on Cloudify 3.4 mature core orchestration
libraries, with rich set of plugins capable of orchestrating most major private and public
clouds.
  As the project's goal is to offer a robust software library and a TOSCA SDK, ARIA is being
refactored to become a general purpose library for TOSCA Orchestration. The refactoring process
includes alignment with most recent OASIS TOSCA DSL specification, reflecting the workflow
engine which drives the execution of the described TOSCA templates, Aiming for initial 1.0
release in November 2016.
+ 
  === Meritocracy ===
  ARIA being a reference implementation of a vendor independent and neutral standard specification,
we strongly believes in meritocracy, where individual committers and companies can help drive
the implementation of the standard and take leading roles in steering the project. ARIA’s
started it’s life as the Kernel of Cloudify, an open source and open platform orchestration
product, we intend to bring our experience operating in open source communities to create
an open governance structure for project leadership to encourage individual and company involvement
and contributions. 
  
@@ -69, +70 @@

  Cloudify fosters live community discussion over google groups, a mailing list, IRC, and
SLACK. It is important to foster and expand this community and attract
  more diversity to the core team.
  For ARIA community to thrive and success It is important to plug into dependent communities
that consumes ARIA(such as Cloudify, Open-O and others) encourage and facilitate discussions
and joint contributions. 
+ 
- `===  Core Developers ===
+ ===  Core Developers ===
  Lior Mizrahi, Tal Liron, Maxim Orlov, Ran Ziv.
  New core developers (initial committers) for the ARIA project are welcome to join the community
by code contributions, broad involvement in the community through code reviews, mailing lists
and IRC.
  
  === Alignment ===
  Project ARIA’s main goal is to become a healthy, neutral, open-governance open-source
project, we strongly believe that the Apache Software Foundation provides the most substantial
framework to achieve such community.
  === Known Risks ===
- ====Orphaned products====
+ ==== Orphaned products ====
  Starting from ARIA’s first release is the core orchestration library in Cloudify, commercially
offered by GigaSpaces. There’s a strong commitment by GigaSpaces to keep a leadership role
in the ARIA community, to maintain and advance the project. 
  ==== Inexperience with Open Source ====
  The team behind ARIA has vast experience in many open source communities, and has been working
on Cloudify, an open source project of it’s own since 2013. All development is  in public
on GitHub, backed up by mailing lists on Google groups and IRC. The team of committers are
committed to the principles of open source, and count amongst their number existing Apache
committers.
@@ -101, +103 @@

  www.ARIATOSCA.org
  Complete project documentation is being planned for upcoming releases. 
  
-  === Initial Source ===
+ === Initial Source ===
  The initial source of ARIA 0.1  is based on Cloudify 3.4 mature code base. Reaching to ARIA
1.0 release after refactoring to make ARIA easily consumable library(and corresponding Cloudify
3.5 release which consumes ARIA as the Orchestration Kernel) all core orchestration capabilities
are developed in ARIA.
  
  === Source and Intellectual Property Submission Plan ===
@@ -113, +115 @@

  
  === External Dependencies ===
  The dependencies all have Apache compatible licenses. These include BSD, CDDL, CPL, MPL
and MIT licensed dependencies.
+ 
  === Cryptography ===
+ 
-  === Required Resources ===
+ === Required Resources ===
+ 
-  === Mailing lists ===
+ ==== Mailing lists ====
  We seek "ARIA-Dev" and "ARIA-User" lists to replace the lists currently in use. In alignment
with Apache's standard practices, we would also have a "ARIA-Private" list for the PMC members.

+ 
- === Source Control ===
+ ==== Source Control ====
  We would require a Git repository named "ARIA-TOSCA" to hold the ARIA source code, and "ARIA-SITE"
to hold the web site source code. We would like these to be mirrored to GitHub repositories,
where we intend to follow the same model currently used by Apache projects.
  
- === Issue Tracking ===
+ ==== Issue Tracking ====
- 
  Jira, with a project name of "ARIA-TOSCA".
   
  === Initial Committers ===
@@ -130, +135 @@

  Maxim
  Tal Liron
  
- 
  == Affiliations ==
  The majority of the commits to the project so far have been made by
  people who were employees of GigaSpaces at the time of the contribution, and the vast majority
of those commits were in the line of their employment. All named initial committers are employees
of GigaSpaces.
  As stated in the Known Risks section, we appreciate that this cannot continue long term,
and a key goal of the podling will be to encourage people not affiliated with GigaSpaces to
join the project as committers and PMC members.
+ 
  === Sponsors ===
  TBD
  === Champion ===

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message