Page tree
Skip to end of metadata
Go to start of metadata

Airship-based Infrastructure Deployment and Lifecycle Management Project Proposal

Project Name:

  • Proposed name for the project: Airship-based Infrastructure Deployment and Lifecycle Management
  • Proposed name for the repository: airship

Project description:

Airship-based Infrastructure Deployment and Lifecycle Management is an installer with the goal of of deploying and managing the lifecycle of cloud and NFV infrastructure in order to support VNFs testing and certification on top of the infrastructure. This project intends to cover:

  • Reference Implementation of cloud and NFV infrastructure according to industry infrastructure architecture model(s), e.g. Akraino blueprints, that Airship fits.
  • Support of the VNF Testing and Certification running on top of the cloud and NFV infrastructure if so specified in the model(s).

Scope:

There is a market need to:

  • Implement the cloud and NFV infrastructure according to industry infrastructure architecture model.
  • Implement and perform VNF testing and certification on top of the cloud and NFV infrastructure.

The scope of Airship-based Infrastructure Deployment and Lifecycle Management project will focus on implementing the market need. More specifically:

  • Develop declarative description in YAML according to industry infrastructure model(s) that Airship fits
  • Use upstream open source tool Airship to deploy and manage the lifecycle of Cloud and NFV infrastructure according to industry model(s) that Airship fits
  • Support of VNF testing and certification if so specified in the model(s).
  • Necessary YAML and integration tools as needed
  • Integration with OPNFV's CI/CD pipeline according to long term evolution path

Testability:

  • This project intends to follow and adhere to the gates and quality criteria used by OPNFV.
  • This project intends to support additional deployment quality criteria if so specified in the model(s).

Documentation:

Documentation will be available on official OPNFV Documentation portal and will include:

  • Deployment Guide
  • User Guide
  • Reference to Upstream Airship documentations

Dependencies:

  • Upstream open source project Airship (Release 1.0 on April 25th, 2019)
  • Industry standard models, e.g. Akraino blueprints (Release 1.0 on May 30th, 2019), that Airship fits
  • Other industry models that Airship fits as they will be developed and matured

Committers and Contributors:

Committers (alphabetically according to last name)

  • Parker Berberian (UNH-IOL)
  • Trevor Cooper (Intel)

  • Bin Hu (AT&T)

  • Greg Oberfield (AT&T)

  • Cedric Ollivier (Orange)
  • Prakash Ramchandran (Dell)

  • Sridhar Rao (Spirent)
  • Kaspars Skels (AT&T)
  • Bin Yang (Wind River)

Contributors (alphabetically according to last name)

  • Jay Ahn, SK Telecom
  • Mark Beierl, VMWare
  • Jonathan Beltran, AT&T
  • Manuel Buil, SUSE
  • Vladyslav Drok, Mirantis
  • Stanislav Egorov, Mirantis
  • Stephen Gooch, Wind River
  • Pankaj Goyal, AT&T
  • Gil Hellmann, Wind River
  • Tom Komuro, NTT Communications
  • Jian Li, SK Telecom
  • Jared Miller, Mirantis
  • Pavlo Shchelokovskyy, Mirantis
  • Sanho Shin, SK Telecom
  • Mark Shostak, AT&T
  • Svetlana Shturm, Mirantis
  • Andrey Volkov, Mirantis

Planned deliverables:

  • Declarative description in YAML according to industry standard infrastructure model(s)
  • A script that will use Airship with YAML to deploy and manage the lifecycle of cloud and NFV infrastructure
  • Integration with OPNFV’s CI/CD pipeline according to long term evolution path
  • Optionally, necessary YAML and integration tools as needed.

Proposed Release Schedule:

  • This project is planned for the first release in 09/2019.

  • This project will follow the Continuous Delivery (CD) release model of OPNFV, and monthly release cadence.

Key Project Facts

Project Name: Airship-based Infrastructure Deployment and Lifecycle Management
Repo name: airship
Lifecycle State: Proposal
Primary Contact: Bin Hu
Project Lead: Bin Hu
Jira Project Name: AIRSHIP
Jira Project Prefix: [AIRSHIP]
Mailing list tag [airship]
Committers:

  • Parker Berberian (UNH-IOL)
  • Trevor Cooper (Intel)

  • Bin Hu (AT&T)

  • Greg Oberfield (AT&T)

  • Cedric Ollivier (Orange)
  • Prakash Ramchandran (Dell)

  • Sridhar Rao (Spirent)
  • Kaspars Skels (AT&T)
  • Bin Yang (Wind River)

Link to TSC approval: http://meetbot.opnfv.org/meetings/opnfv-meeting/2019/opnfv-meeting.2019-07-02-12.55.html
Link to approval of additional submitters: <TBD>

  • No labels

12 Comments

  1. Just a question, does this not also fall under the edge cloud project?  I guess I am wondering if this is independent enough to be its own project, or if we should use the edge cloud as a master project for integration of things like Airship and StarlingX?

  2. I don't see anything that tells me that Starling-X is doing with Respect to Edge Cloud Project. Refer - H release plan

    However Airship clearly is looking for resources to execute part of Provisionig and testing sample VNF onboarding here  using community lab(s).

  3. I don't think the edge cloud project moved forward on StarlingX, but they were looking at taking on edge based installers, which I why I was wondering if the edge cloud project would make a good umbrella for both Airship and StarlingX, in an attempt to make sure edge deployments don't fragment.

    1. Unlike StarlingX, I don't think Airship is explicitly targeting edge at the moment

  4. Agree with Manuel. Airship is not explicitly targeting edge. It is a general-purpose tool of deployment and lifecycle management. For Airship itself, the evolution is in OpenStack. So whatever it is Edge or Starling X, it needs to be addressed in Airship project in OpenStack.

    The project proposal here in OPNFV is to "use" Airship to implement industry standard models. The models could be NFV, or Edge NFV, or anything else from industry consortium etc. We don't limit ourselves to any particular model as long as industry needs. If industry needs common telco NFVi, then we can certainly "use" airship to implement that model.

    Example: think about Airship as Java language developed in JCP (Java Community Process). Here in OPNFV, we "use" this Java language (Airship) to implement industry standard models. The evolution of Java itself (e.g. Edge support?) needs to be addressed in JCP.

    Hope it helps.

  5. To Mark Beierllast question, if Edge Project can produce a "model", they can certainly collaborate with this project. We are happy to generate related YAML and use Airship to deploy it. Just like we are happy to use Java language to implement that model.

    But the language tool (Airship) is orthogonal with the model (Edge domain, NFV domain etc.). So it is not appropriate to have Edge has an umbrella, just like Edge is not an umbrella for Java.

    1. Yes and no. The current intent-driven nature of Airship allows to easily expand it into new areas, however if Airship wants to address edge, it will have to start fulfilling edge requirements. For example being able to deploy on non-x86 hardware (I think, it is not possible today as Airship only supports Ubuntu in x86 deployed through drydock+maas), deploy nodes which might be far away and not L2-connected, manage a distributed cluster with large latency... These are problems that StarlingX is trying to address but Airship is not (today)

  6. That's right. Those are being discussed as part of Airship 2.0 features in OpenStack. So those who are interested in addressing the specific support of Edge, and how to make StarlingX work with Airship, are very encouraged to participate in the upstream Airship 2.0 work in OpenStack.

  7. Thank you guys for mention edge cloud project.

    Agree with Manuel, I think Airship is more like a tool focusing on programmable cloud deployment, but cloud itself is not included in its scope (please correct me if I'm wrong). For telco edge, besides what Manuel has mentioned, another thing that need to be cover is the deployment of multiple related cloud (could be multi-region OpenStack or several independent OpenStack ), and heterogeneous cloud. And I think currently StarlingX focuses more on cloud (containerized OpenStack deployment included) and O&M. The edge cloud team are learning more about StarlingX and Airship, and willing to participate in future edge related activities.

    But if airship is doing cloud deployment, is it overlapped with OPNFV installers?

  8. Thank you Quhui for the good summary. I am glad that your team is looking into StarlingX and Airship, and may contribute to Airship 2.0 in the future. Note that Edge is a topic for Airship 2.0 in OpenStack now. So the earlier your team can participate, the better opportunity your requirement of Edge support can be fully discussed and potentially supported there.

    Regarding your question of other OPNFV installers, it is actually the advantage of having more installers so that end users will have more choices on market, and more easily switch from one installer to another whenever business needs.

    Let me give an example. As I mentioned above, if we see Airship as Java, other installers are C, C++, Python, etc. Different language can be used to implement the same thing, e.g. TCP/IP, RTP/RTSP, etc. Users will have multiple choices to choose from different implementations of different languages. There is no overlapping of languages. Users and market decide which one to use.

    Another example is that if you want to travel from San Francisco to Los Angeles, you have many choices too. If Airship is "by car", other installers are "by air", "by train", "by taxi", "by uber" etc. Even for "by air", there are many airlines. Then you will have many choices, and not be locked in by one transportation method, or locked in by a single transportation company. There is no overlapping of transportation methods or companies. The more, the better for consumers.

    We all know, being a consumer, if we are locked in by a single transportation company, what we will get.

    So having more installers will encourage the technology innovation so that end users will have more choices on market based on business needs. Let alone there are many end users globally, and each end user will have different preferences because of different business nature. Thus more installers will meet the variety of needs of end users on market. Just like more airlines, and other train, taxi and uber drivers will meet the variety of needs of consumers.

    Hope it helps and thank you.

    Bin

  9. Thank you Bin Hu for clarifying your view and for promoting choice with respect to installers.

    In that spirit, would it be possible to adapt the language of the project description to avoid giving the impression that Airship implemented "industry standard infrastructure architecture models" or that it was unique in the approach of fully declarative infrastructure models or goal of VNF Testing and Certification support and reference architecture?

    For example, in the Akraino project we currently have 11 blueprint families, only 2 of which are Airship-based; others use different installers that work in similar ways, each with their own pros and cons relative to Airship.

    It is important to acknowledge that blueprints / declarative infrastructure architecture data models are installer-specific: One cannot apply a blueprint designed for Airship to another installer and vice-versa.

    In Akraino, we've been discussing how to create synergies between installers by creating a higher-level abstraction / information model from which installer-specific models / blueprints could be derived. Interestingly, this is somewhat repeating the learning experience and insights of the installer discussions in the early days of OPNFV...

    Point being: If you write that Airship implemented "industry standard models", you're implying it was an "industry standard installer" and potentially more suitable to be a reference implementation than other installers.

    Does this make sense?

    Thanks – Frank

  10. Thank you Frank for your suggestion. That's a good point.

    How about "industry infrastructure architecture models, e.g. Akraino blueprints, that Airship fits"?

    So the word "standard" is removed, and limited to "that Airship fits" which means some other installers fit other blueprints and other models.

    Let me know if you suggest other better wording to avoid the confusion.

    Thank you

    Bin