1. Strukt, Build Changes and Backend Support Jonathan Custance James Green John Thomson Stuart Simms OnApp Ltd.

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

3. 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.

4. 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

5. 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

6. 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

7. 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

8. Models Phased code generation – goal Categories Models Components Deployment Configuration Code Generation Categories Components DB Schemas Deployment Scripts Deployment Scripts Parser XSDs Parser XSDs Traditional Build Traditional Build

9. 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 state Manual Code Generation Strukt Within Build Process Data Model Driving Strukt Category Generation Component Generation Deployment Generation Models Category Model XMLs Category Model XMLs Code Generation Models Category.h files Category.h files Strukt Models Category.c files Category.c files Traditional Build Traditional Build

10. 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 API CRUDL API Backend Integration Backend System e.g. SQL Component Category

11. 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

12. Questions?