You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

This document describes the goals for development of the Edge Service Enabling Platform in 2023 and how we plan to work towards those goals. Specifically, we focus on the design and implementation of extensions to existing tools, and the technical/architectural decisions which we have made (and those which still need to be made).

Contents:

Motivations

In 2023 we want to start off prototyping an open tool which will help make designing edge services easier. The overall goals of this year's development are as follows:

  • Improve on existing tooling for edge service designers in a substantial way
  • Provide an open source implementation
  • Have something usable in a short (<1year) time frame

Even a relatively small piece of working code can be an anchor for further improvements. We also want to get our ideas "out there" to see what has traction (i.e. what looks useful to other developers and service designers). Hopefully, this can lead to productive partnerships and encourage ongoing development towards implementing the overall vision of the platform.

Focus

We've looked at the landscape of open tools and standards which could be applied to edge services, and have settled, at least for now, on OASIS TOSCA as a potential base technology. TOSCA is already in use in ONAP. It is a relatively mature standard, but still actively under development, and with several implementations. In particular, Eclipse Winery is an open source tool that provides graphical visualization and design tools using TOSCA data structures and formats. XOpera is another tool which provides support for deploying services described by TOSCA CSAR files.

TOSCA is a standard focused firstmost on cloud services. It seems likely that adapting it for use on the edge will require some work. On the other hand, it does provide a firm and extremely flexible foundation for modeling services. For this reason, and because of the availability of open source tooling mentioned above, it seems like a good fit for our project.

Our initial focus will be adding and extending functionality to Eclipse Winery in support of these goals:

  • Reducing complexity for people designing edge services by supporting flexible and reusable service designs (service catalogs) and abstractions of service subsystems (components)
  • Supporting developers of edge-oriented software and hardware offerings by making it possible to provide their products to service designers as service components, with the potential to be simply dropped into a service design with minimal configuration

How we plan to do this will be discussed below.

Basic Design

In this section we describe the approach we will be taking to implementing the new functionality in Eclipse Winery.

TOSCA and Eclipse Winery Fundamentals

The basic elements of a TOSCA design are illustrated in the diagram below, taken from the TOSCA 1.0 specification. A service template contains all the type definitions required by the design plus a topology template. The topology template consists of a set of nodes (or node templates) and relationships (or relationship templates) between those nodes. The topology template represents the structure of the service as it will be deployed. The nodes are abstract functional blocks, representing such things as software applications, libraries, virtual machines (or other "compute" nodes), and so on. Relationships describe dependencies between nodes, which can encompass network connections and APIs, and also such things as which host runs a given piece of software.

Diagram from http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html

Relationships connect a requirement from one node to a capability on another. All of these entities: nodes, requirements, capabilities, and requirements, have types which can define their properties, attributes, and behaviors (i.e. scripts executed when certain events, such as starting the service, occur).

Eclipse Winery supports creating and editing the various type entities used to create service templates through a graphical interface. It also provides a visual topology template editor where the nodes and relationships can be manipulated, as shown below. The rectangles are nodes, and the arrows are relationships between those nodes. On the left, a palette of node types is available to drag and drop into the topology template.

Screen capture of the Eclipse Winery topology template editor

The various pieces of data associated with a node (properties, requirements, capabilities, and so on) can be accessed by enabling them on the toolbar along the top and opening the resulting panels in nodes as shown below.

A screen capture showing properties, requirements, and capabilities editing

Node Substitution

TOSCA has a concept of node substitution, where a node in a service template can be programatically replaced by a group of nodes and relationships (effectively a different service template, but one which defines substitution mappings, external interfaces for the substitution service template that map to the capabilities and relationships of the node they replace). This closely resembles the idea of components which will be described below. Where possible, we hope to make use of the syntax and concepts already developed as part of node substitution to implement support for components. We may even find that node substitution with only minor extensions can be applied directly to support components. Eclipse Winery does not directly support creating or manipulating substitutions at this time. This is an area for ongoing investigation as part of this year's work.

Eclipse Winery File Structures

The service template is the basic file format that TOSCA defines, and almost all parts of it, including the topology template, are technically optional. Eclipse Winery manages "service templates" which include topology templates, and saves type definitions in other files (using the same format, but without topology templates).

In order to keep the service template file from becoming unmanagably large and complex, it can include groups of types by reference from other files. Every node type and relationship type is managed as a separate file in Eclipse Winery and included in the service template by reference. When a service template is packaged in a CSAR (cloud service archive) file, all the files referenced by the service template are also included in the archive.

Support for Components

Describe how components will be modeled in Winery and how they are expected to behave in a service catalog.

Flexible Service Catalogs

Describe what service catalogs are and how they will be implemented in the context of TOSCA and Winery.

Future Development

After the initial pass described above, we hope to continue expanding on the base we will establish this year. A few of the directions we are already considering are described here.

Deploying Services

The initial focus of our work is on improving the tools for design of services. The other half of the process, deploying those services, could be a focus for upcoming work. XOpera has already been mentioned as an orchestration/deployment tool. Even XOpera will probably require some work to integrate our changes, or at the very least testing and verification. We would also like to make our approach as agnostic as possible, supporting multiple tools, possibly through a plugin framework, and even potentially more than one orchestration tool in the same service. Service deployment and management has seen more work in the open source community than service design, so there are many potential tools to choose from.

Our next steps should include selecting one or more orchestration tools to integrate our extensions with, and determining the scope of the development effort required.

Usability Improvements

In our investigation of Eclipse Winery we have encountered several areas where there are potential usability improvements that could be made. Some examples include:

  • improving search and filtering of node and service template lists
  • improving the UX for connecting nodes with relationships (e.g. visually identifying which nodes could satisfy a given requirement)
  • improving the clarity of the connection between input and output parameters of service templates, nodes, and node types

We should evaluate these improvements for inclusion in our next development phase, or even in the current phase if extra resources are available.

Component Connection UX

One area that makes both component and service design complex is understanding the connections between nodes and/or components (the requirements, capabilities, and relationships, in TOSCA terminology). In the mid-to-long term we would like to make setting up these connections easier to understand and possibly automate (or at least automatically suggest) connectivity between components during the service design process. A first step in this direction might be to make it possible to document connection points and refer to that documentation within the tools. It should be possible eventually for Eclipse Winery to perform automatic discovery of compatible interfaces, search for components (or nodes, or node types) that satisfy requirements (or might require a component's capabilities), and offer up selections of components and relationship types when necessary.

Because of the scope of this topic, it will probably need to be broken down into several phases. In the next step of development we should evaluate what parts will fit within the limits of available time and resources, and estimate a timeline for implementing them.

  • No labels