Strukt, Build Changes and Backend Support

Jonathan CustanceJames Green

John ThomsonStuart Simms

OnApp Ltd.

Overview• Background• What is needed?• How to proceed• Representing the data model• Phased code generation• Questions

Background• OnApp provide ‘cloud’ control software• OnApp customers have thousands of ‘clouds’

geographically spread• OnApp will offer customers ‘federation’ of ‘cloud’

resource• OnApp engagement with CO led to a joint proposal

for industrial use for ‘federation’• Proposal includes architecture/tool changes, as well

as governance.

What is needed?• Simple, OCCI compatible, data model representation• Open source code generation, part of the build

process – simplify code base• Support of differing backends for categories – allow

flexible CO deployment• Efficient data access – inter-component and for

UI/admin modules• Simple expression of deployment configuration

How to proceed• Provide open build system, extensible by all for any

CO deployment• Data model agreed, specified and version controlled• Phased development plan agreed, leading to

replacement code generation tool• Each development phase reviewed and tested prior

to merge, check CO behaviour unchanged• Phasing hooks in with governance changes and move

to GitHub

Representing the data model #1• Category data model is an XML version of OCCI -

supports kinds, links, mixins & actions• Flexible attribute definition covering:– Types, incl. enums and default values– Units, validation and indexation

• Collection – allow an attribute to specify relationships with other categories

• Backend help to allow category to specify common links and mixins

Representing the data model #2• Components– allow model to specify which categories are within a

component

• Deployment– allow the specific deployment model to be specified

• Configuration– specify backends and their configuration– configure which categories use which backend

Models

Phased code generation – goal

Categories

ModelsComponents

Deployment

Configuration

Models

Code Generation

Categories Components

DB Schemas

DeploymentScripts

ParserXSDs

Code

TraditionalBuild

• Data model and tools within source tree• Auto-generated files removed• Ready for migration to GitHub• autogen build process updated to:

• Try it out – pull master today • New dependency – Python 2.7

Phased code generation – current stateManual Code Generation

Strukt Within Build Process

Data Model Driving Strukt

Category Generation

Component Generation

Deployment Generation

ModelsCategoryModel XMLs

Code Generation

ModelsCategory.h files

StruktModelsCategory

.c filesTraditional

Build

Phased code generation – next steps #1

• Updated category generation– Auto-generate Actions API from

model (not from component)– Split code around CRUDL API to

allow different backends– Backend Integration code

generation– Schema/migration data

generation for Backend System

Manual Code Generation

Strukt Within Build Process

Data Model Driving Strukt

Category Generation

Component Generation

Deployment Generation

REST Server

OCCI Server

Actions APICRUDL API

Backend Integration

Backend System e.g. SQL

Component

Category

Phased code generation – next steps #2

• Component generation– Simple components entirely generated– Simplifies code for components with business logic

• Deployment script generation– Create deployment scripts for chosen deployment model– Ensure category access optimised– Supports: Compact (single process), Small, Large & Scalable

Manual Code Generation

Strukt Within Build Process

Data Model Driving Strukt

Category Generation

Component Generation

Deployment Generation

Questions?