Openstack Integration with Apache Camel Project

Masaryk University Faculty of Informatics

OpenStack integration with Apache Camel project

Master’s Thesis

Jan Bouška

Brno, Spring 2017

Masaryk University Faculty of Informatics

OpenStack integration with Apache Camel project

Master’s Thesis

Jan Bouška

Brno, Spring 2017

Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Jan Bouška

Advisor: Mgr. Marek Grác, Ph.D.

Acknowledgement

I would like to thank to my supervisor Mgr. Marek Grác, Ph.D. and my technical supervisor from Red Hat Czech, s.r.o, Ing. Jiří Pechanec, for providing constant feedback during the preparation of this master’s thesis. I would also like to thank to all my other colleagues from Red Hat that expressed their valuable thoughts and helped to make this thesis better.

iii Abstract

The purpose of this master’s thesis is to design and develop new Camel component by integrating two open-source project Apache Camel and OpenStack. This new component will act as OpenStack service provider in the Camel integration framework.

iv Keywords

Apache Camel, OpenStack, component, integration framework, cloud computing

Contents

1 Introduction 1

2 Technologies 3 2.1 Apache Camel ...... 3 2.1.1 Camel core features ...... 3 2.1.2 Camel’s Architecture ...... 6 2.2 OpenStack ...... 10 2.2.1 Why we need OpenStack ...... 10 2.2.2 OpenStack - platform for cloud computing . . . 12 2.2.3 How it works ...... 12

3 Analysis and Design 17 3.0.1 Existing ways to use OpenStack with Camel . . 17 3.0.2 Requirements ...... 17 3.0.3 Use case diagram ...... 20 3.0.4 Component’s Data flow ...... 20 3.0.5 Camel OpenStack URI ...... 21 3.0.6 OpenStack4j ...... 23 3.0.7 Class Diagram ...... 25 3.0.8 Dynamic component loading ...... 26

4 Implementation 27 4.1 Component structure ...... 28 4.1.1 openstack-nova ...... 32 4.1.2 openstack-glance ...... 33 4.1.3 openstack-neutron ...... 34 4.1.4 openstack-keystone ...... 35 4.1.5 openstack-swift ...... 36 4.1.6 openstack-cinder ...... 38 4.2 Testing ...... 39 4.2.1 Unit Tests ...... 39 4.2.2 Integration Tests ...... 40 4.3 Documentation ...... 41

5 Conclusion 43

vii A Sub-components class diagrams 45

B Camel OpenStack documentation 51

C Contents of attached CD 73

Bibliography 75

viii List of Figures

2.1 Construction of the route in Camel DSL 4 2.2 Java DSL 4 2.3 XML DSL 4 2.4 Scala DSL 4 2.5 Camel context 6 2.6 Cloud compute stack 11 2.7 OpenStack software diagram 12 2.8 OpenStack Conceptual View 13 3.1 Camel OpenStack use case diagram 20 3.2 Camel OpenStack Data Flow diagram 21 3.3 Class diagram 26 3.4 Component resources directory 26 4.1 Package diagram 28 4.2 OpenstackConstants 29 4.3 AbstractOpenstackEndpoint 30 4.4 AbstractOpenstackProducer 30 4.5 Component class 31 4.6 Endpoint class 31 4.7 Producer class 32 4.8 Nova producers 32 4.9 Glance producer 34 4.10 Neutron producers 35 4.11 Keystone producers 36 4.12 Swift producers 37 4.13 Cinder producers 38 4.14 Tests structure 40 A.1 openstack-nova class diagram 45 A.2 openstack-glance class diagram 46 A.3 openstack-keystone class diagram 47 A.4 openstack-neutron class diagram 48 A.5 openstack-swift class diagram 49 A.6 openstack-cinder class diagram 50

1 Introduction

The age we live in right now is very often called "The age of Information technologies". This is exactly the term which describes our everyday life. We use information technologies almost everyday and everywhere. There are systems used for weather prediction, systems used in health centers and many other systems which are used for different things. The majority of these systems are constructed in order to produce useful information for us. It is no surprise that if we connect systems we can get much more information and profit from it. Lets imagine for example an airline company. Our company has to find out information about weather, collect information from other airline companies and assemble flight plans, provide their services to the customers over web interface and there are lots of other things to do. It is obvious that those systems should communicate with each other. It does not seem to be a difficult thing but the modern technologies are based on different programming languages, different frameworks and have alot of other differences. The consequence is that these systems don’t have a common language for communication. This is the main purpose of integration frameworks which are designed to solve these problems. The main goal of integration frameworks is to allow communication across different API1, data formats and interfaces. Moreover they are trying to be lightweight, straightforward and easy to learn. One of the integration frameworks is called Apache Camel[1]. This framework is very powerful and user-friendly. This project is developed under Apache and is very popular because it is open source and it has very large developer community. Camel is based on the book called "Enterprise Integration Patterns"[6] or EIP written by Gregor Hohpe and Bobby Wolf. In this book there are described 65 patterns for the use of enterprise application integration and message-oriented middleware. Apache Camel is highly modular because the core module contains only few basic features and the other communication protocols can be used as an extension of the camel-core module. These extensions are called camel components. The modulation helps Camel to be lightweight and nice to use.

1. Application Programming Interface

1 1. Introduction

The main purpose of this thesis is to create a new Camel component which would allow Camel users to communicate and manage services in OpenStack system[11]. Based on community given approach the new component is named Camel OpenStack. OpenStack is free, open source platform for cloud computing. The OpenStack system is also widely used and OpenStack developers could be proud of the similar benefits as Camel developers i.e. user friendliness and modularity. Openstack consists of several components. The main component is called Nova. Nova is designed to manage pools of virtual computers and resources. The other important components are Neutron, Cinder, Glance, Swift and Keystone. This are the six components which the Camel OpenStack component will support. There are other OpenStack components which are not in the frame of this thesis. This thesis is divided into five thematic parts. The first chapter contains brief introduction and the aim of this thesis. The second chapter introduces technologies used in this project (mainly the Apache Camel project and the OpenStack project). It is not indeed to cover these projects to the detail but there are described the most important facts about the projects. You can find more detailed information if you follow the links to the documentation. The third chapter is focused on the analysis and design of the new Camel component. The fourth chapter describes the process of the implementation and testing of camel-openstack component. The last chapter is called Conclusion. This chapter is here to sum up the results and the opportunities to enhance and enlarge the range of functionality of the newly created component.

2 2 Technologies

This chapter describes technologies used for implementation of Camel OpenStack component. The first section of this chapter deals with the Apache Camel project and the second part is about OpenStack system.

2.1 Apache Camel

Apache Camel[2] is open source integration framework written in Java. This framework is based on theory of Enterprise Integration Patterns or EIP, described in the book written by Gregor Hohpe and Bobby Wolf. As well as other integration frameworks Camel mainly focuses on interaction between applications. This interaction is based on the routing exchanges. But there are very many different features which purpose is not routing of exchanges but they could be useful for modifying data or monitoring and maintaining of the whole system. Camel has also very extensible and modular architecture which was designed to allow implementation and seamless plugin support for new protocols. Another fundamental principle of Camel is that data are transported in unified format. This feature is very useful because developers can’t convert data to or from any canonical format. This assumption also allow Camel users to integrate together any kind of systems.

2.1.1 Camel core features Camel’s main feature is moving data from one application to another and vice versa. This movement is based on the route’s configuration. The routes in Camel are configured with a combination of EIP and Camel’s domain-specific language (DSL).

Domain Specific Language Domain specific language allows users to specify their rules in declar- ative way. This approach helps Camel minimizes number of lines of source code and makes Camel very nice to use. Camel’s DSL was

3 2. Technologies inspired by natural language and helps inexperienced users to understand Camel rules very quickly. Lets show a simple example how Camel’s routes are created with Camel DSL.

Imagine a situation when we have an e-shop. Incoming data are orders from our e-shop and we want to route them to the widget inventory or to the gadget inventory. You can see that Camel DSL is really very close to natural language on Figure 2.1

Figure 2.1: Construction of the route in Camel DSL

Camel is also unique because it offers multiple DSLs. You can specify routes in regular programming languages for example Java, XML, Groovy and Scala. As you can see on Figure 2.2 – 2.4 the syntax is fundamentally equivalent in all those languages.

Figure 2.2: Java DSL

Figure 2.3: XML DSL

Figure 2.4: Scala DSL

4 2. Technologies

Enterprise Integration Patterns (EIPs)

It seems that the integration problems are very diverse, Gregor Hohpe and Bobby Woolf were able to find 65 integration patterns which are very common in integration. They wrote a book called Enterprise Inte- gration Patterns which deals with integration problems and suggests the solutions. Camel is heavily based on EIPs and implements almost all EIPs which could help you to solve your integration problems.

Pluggable architecture

As we mentioned above Camel has very modular architecture. This approach causes that Camel has very lightweight core which with all libraries needed have only about 4.4 MB (version 2.18.0). It makes Camel very easy to deploy anywhere you like. The other features and supported protocols are installed as an extensions (additional modules) of camel-core. Camel provides an extensive library of components which is still growing.

Easy Configuration

Camel follows convention over configuration paradigm. Developers using Camel can focus more on their use case than on Camel configuration. Camel uses very intuitive URI configuration which follows following pattern (see 2.1.2):

scheme: path?option=value&option2=value2 &...

Type converters

Camel also provides very extensive library of type converters. Purpose of this built-in type converters is to convert data between types. This type conversion works under the hood so you don’t need to manage this converters. If you need a new custom converter you can easily add it to the Camel for usage.

5 2. Technologies

2.1.2 Camel’s Architecture

In this chapter we will cover Camel architecture from high-level to the lowest-level and take closer look on the most important Camel parts. This chapter should help to understand how the Camel works[14].

Camel context

CamelContext holds all the context which Camel needs during the runtime. Its behaves like an container and provides all the functionalities to the runtime environment.

Figure 2.5: Camel context

∙ Components – components used by the application

∙ Type converters – type converters (see 2.1.1)

∙ Data formats – data formats loaded into the context

∙ Languages – Expression languages loaded into the context

∙ Registry – camel registry used for beans look up, component configurations etc.

6 2. Technologies

Routes Routing is one of the most important features in Camel. Routing engine moves messages from one endpoint to another by a path called route. Routes are uniquely labeled by identificators and each route has exactly one input and one or more output ends. You can understand routes as a chain of processors where exchanges are going through them.

Processor Processor is another basic concept in Camel. Processors are responsible for creating, modifying or consuming content of the exchanges. As mentioned above the route is a sequence of processors transmitting exchanges. You can imagine concept of routes and processors as a graph with nodes (processors) and edges (routes connecting processors together). Most of implemented EIP uses processor concept.

Component The Component class is the main extension point in Camel. CamelCon- text contains a collection of Component instances. Only components loaded into CamelContext could be used in application. This class is essentially a factory of Endpoint instances. There is only one Compo- nent class for each Camel component in CamelContext therefore if we add some configuration options to this class it will affect all endpoints created from this component.

Endpoint Endpoint class represents sender or receiver of message channel. End- points are configured by URI. As we mentioned above there is a unified format for Camel URIs which is: scheme: path?option=value&option2=value2 &... Now we can focus more on each part of the URI.

∙ scheme – This part identifies which component to use.

7 2. Technologies

∙ path – This is another mandatory part of each URI. This part identifies component context path.

∙ options – Endpoint options. This options affect only single endpoint (on the contrary of the Component configuration).

The key responsibility of the Endpoint class is to be factory for Consumers or Producers.

Consumer Consumer class represents a receiver in Camel. Once Consumer is started it begins with data consumption, creation of new messages and sending them to routes.

There are two types of consumers:

∙ event-driven consumer – This type of consumer is driven by events. You can find this model also in EIP reffered as anasyn- chronous receiver and it represents client-server communication strategy.

∙ pooling consumer – This is type of synchronous consumer. This consumer is basically configured to pull messages from source in time intervals.

Producer This class is a sender. You can use it to create new data or modified existing data and send it to the route. This class plays very important role in CamelOpenstack component because this is the only class which communicates directly with OpenStack system (see more in chapter 4.1)

Exchange This section relates to Message model in Camel. The Exchange instances are consumed by Processor class. The Exchange class is a wrapper for two Message class instances. The first message is an input message – the message which comes to the Processor as an input.

8 2. Technologies

Second message is an output message and represents new message which will be send to the route as an result of the processing of input message. If the output message is null the input message is sent as the result.

Message This is the lowest level in Camel architecture. All data in Camel are transported in Message class instances. This class has two main parts:

∙ body (Message body) – the main part of the message

∙ headers (Message headers) – additional data to the message body

You can find Message also in EIP as a Message pattern.

9 2. Technologies 2.2 OpenStack

OpenStack[8] is a cloud computing system, mostly deployed as an infrastracture-as-a-service. Openstack is open source project, written in Python[12] which is released under the Apache License. The main purpose of OpenStack is controlling and management large pools of hardware, compute, storage and network resources throughout a data center. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure. OpenStack is used in thousands of projects and hundreds of the world biggest companies rely on OpenStack and run their daily business on top of it. OpenStack has modular architecture and we will briefly describe seven of the most important modules in this chapter.

2.2.1 Why we need OpenStack Cloud computing Cloud computing[9] is a type of Internet-based model which provides computer processing, memory or another resources for multiple users on demand. This model is very popular nowadays because it has a lot of benefits for cloud users. We can pick up the most important ones.

∙ Scalability: This is the biggest advantage of the cloud computing. User’s resource requirements are usually very changing. We can introduce two solutions how to cope with this problem.

– without cloud – The only way how you can fulfill the highest requirements on dedicated server is to buy new resources and add them to the system. It costs time and money. Moreover the additional resources are not used in the rest of time ( it is a kind of wasting with resources). – with cloud – Just ask for another resources. Resources are shared between multiple users so when you don’t need the resource, another user can use it.

∙ Pay as you go: This advantage is very close to the previous one. You pay the resources you really spend with cloud.

10 2. Technologies

∙ Always up-to-date: You don’t need to maintain the system. System is always up-to-date.

∙ Remote access: Your application and data should be accessible whenever and wherever. Cloud should have enough of redundancy to cope with every failure.

Type of clouds

If we focus on provided service model we can find few different types of cloud:

Figure 2.6: Cloud compute stack

Source: https://support.rackspace.com

∙ Infrastructure as a service (IaaS): This type of cloud provides virtual machines and other resources for cloud users. Open- Stack belongs to this type.

∙ Platform as a service (PaaS): Cloud providers deliver a computing platform, typically including operating system, programming- language execution environment, web server and database.

∙ Software as a service (SaaS): In this model cloud providers operate application software and cloud users access the software from cloud clients. Cloud users don’t manage the cloud infrastructure and platform where the application runs.

11 2. Technologies

2.2.2 OpenStack - platform for cloud computing The OpenStack project was launched in July 2010 by Rackspace Host- ing and NASA. The project was intended to help organizations offer cloud-computing services running on standard hardware. Nowadays OpenStack is maintained by OpenStack Foundation - the non-profit corporate established to promote OpenStack software and its community[10]. OpenStack has also a lot of commercial supports (for example Red Hat OpenStack Platform).

Figure 2.7: OpenStack software diagram

Source: https://www.openstack.org

2.2.3 How it works OpenStack[15] is composed of separate developed projects which could make relationships between OpenStack components very difficult. Each component provides its features for your OpenStack instance and you can install only components you really need in order to keep your deployment as much simple as you can. Components usually use Advanced Message Queuing Protocol (AMQP) typically managed by RabbitMQ1 to communicate with each other. On Figure 2.6 is simplified view of OpenStack architecture and communication between the main components. We will cover all those components in separate section.

1. https://www.rabbitmq.com/

12 2. Technologies

Figure 2.8: OpenStack Conceptual View

Source: http://ken.pepple.info

Horizon - dashboard

Horizon provides graphical interface to access and manage Open- Stack services and resources through data center. The main purpose of Horizon is provisioning complex view of your deployment and user-friendly way to maintain the whole system from one point. The Horizon dashboard is not only one of the ways how OpenStack can be managed. The other ways are command line or REST API.

Nova - compute service

Nova is project which behaves as the primary computing engine behind OpenStack. Nova is designed to manage large pools of computer resources. It can work with virtualization technologies as well as with bare machines.

13 2. Technologies

Keystone - identity service

Keystone is an identity service in OpenStack. If you connect to the OpenStack, Keystone will be probably one of the first modules you will be communicating with. This project can be configured to use standard backends like LDAP or SQL.

Glance - image service

OpenStack image service is called Glance. This project is responsible for discovery, registration and delivery services for disk. Stored images in Glance could be used as templates. This service is also responsible for managing image backup catalog.

Neutron - networking

Neutron was formerly known as Quantum. This project was designed in order to manage networks and IP addresses. You can create your own network configuration, control traffic, connect servers and devices to one or more networks and use common network devices such as routers, VPNs etc.

Swift - object storage

Object storage (Swift) is scalable, redundant storage system. Data are written to multiple disk drives spread throughout servers in the data center. Data are stored with redundancy which allow system to recover data in case of disk (or server) failure. Object storage is also responsible for data integrity.

Cinder - block storage

Cinder provides OpenStack nodes persistent block-level storage and is responsible for creation, attaching and detaching of the block devices to servers. Cinder has also built-in snapshot management which provides functionality for backing up data stored on block storage volumes.

14 2. Technologies

Other services There is a lot of other components which can be used with Open- Stack system. Only the components which we covered above (except Horizon) are supported in Camel OpenStack component.

3 Analysis and Design

This chapter describes software analysis and design of Camel Open- Stack component. Because all Camel Components have to follow common skeleton not every part of software analysis is needed. Due to reasons which we explain in section 3.0.5 we divide OpenStack component[16] into six sub-components. These components share very similar architecture, therefore, there is no reason to talk about each component separately. We need to explain the common structure and focus more on the most important parts of each sub-component.

3.0.1 Existing ways to use OpenStack with Camel There were several ways how to communicate with OpenStack through Camel before implementation OpenStack component. We list two of them in this section. The first is using Rest Component1. Because OpenStack supports REST API this is the most natural way. This method is very difficult because you have to take care about authentication, proper response/request format and a lot of other things on your own. This solution is not optimal because you have to focus more on REST configuration than on your use case. The other way is using Jclouds Component2. This way is also not optimal because this component does not provide full power of OpenStack (only Nova and Swift are supported).

3.0.2 Requirements The purpose of this thesis is to integrate Camel with several Open- Stack components. The integration of this two systems means that users could use OpenStack services through Camel. This component is required by Camel community and is tracked in Apache’s Jira3. As we can see in issue description, community suggests using Open- Stack4j library4. Because OpenStack is really big project we divided

1. http://camel.apache.org/rest.html 2. http://camel.apache.org/jclouds.html 3. https://issues.apache.org/jira/browse/CAMEL-9748 4. http://www.openstack4j.com/ 17 3. Analysis and Design this integration into six parts. Each part is targeted in integration one OpenStack component with Camel project. We will list all the parts and describe basic requirements of each part.

1. openstack-nova Target of this part is to integrate Camel project with OpenStack Nova. Openstack-nova should support common features which could be done through OpenStack Nova REST API. This part will support:

∙ Manage Flavors Flavor defines the compute, memory, and storage capacity of nova computing instances. We can imagine flavor as a template of an available hardware configuration for a server. Openstack-nova component will support following operations: create flavor, delete flavor, get selected flavor and list all flavors. ∙ Manage Servers i.e. create server, get selected server, list all servers, delete server, create server snapshot and force server to do an action (start, stop, pause...). ∙ Manage Keypairs i.e. create and delete keypair, query for existing keypair.

2. openstack-keystone This part is implemented in order to integrate Camel with OpenStack Keystone project. Openstack- keystone should support common features which could be done through OpenStack Keystone REST API. Only Keystone API of version 3 is supported because Keystone API v2 is deprecated nowadays.

∙ Manage Domains i.e. create, update, get selected domain and list all domains. ∙ Manage Groups i.e. create, update, get selected group, list all groups and moreover add an user to group, remove user from group and check if user is in selected group. ∙ Manage Projects i.e. create, update, get project and list all projects.

18 3. Analysis and Design

∙ Manage Regions i.e. create, update, get region and list all regions. ∙ Manage Users i.e. create, update, get, list all users. 3. openstack-glance should support common features which could be done through OpenStack Glance REST API. ∙ Manage Images i.e. create, reserve, update, upload, get, list all and delete image. 4. openstack-neutron should support common features which could be done through OpenStack Neutron REST API. ∙ Manage Networks i.e. create, get, list all and delete network. ∙ Manage Ports i.e. create, update, get, get all and delete port. ∙ Manage Router i.e. create, update, get, list all, delete router, attach interface to router and detach interface. ∙ Manage Subnets i.e. create, update, get, list all and delete subnet. 5. openstack-swift should support common features which could be done through OpenStack Swift REST API. ∙ Manage Containers i.e. create, get, get all, update and delete container. Moreover create and update, get or delete container metadata. ∙ Manage Objects i.e. create, get, get all, update and delete object from container. Moreover create and update, get or delete object metadata. 6. openstack-cinder should support common features which could be done through OpenStack Cinder REST API. ∙ Manage Volumes i.e. create, get, get all, get all types, update and delete volume. ∙ Manage Volume snapshots i.e. create, get, get all, update and delete volume snapshot.

19 3. Analysis and Design

3.0.3 Use case diagram

Diagram 3.1 is a use-case diagram which depicts requirements on newly created component. As we can see in section 3.0.2 there are a lot of requirements and resulting component is very great. Therefore we do not show all the use cases in detail (for more precise description see 3.0.2).

Figure 3.1: Camel OpenStack use case diagram

3.0.4 Component’s Data flow

As is evident from section 3.0.2 there is no need of any consumers. All the responsibilities relies on Producer pattern. The first Data flow diagram shown on Figure 3.2 depicts data flow from Camel route to the OpenStack system and return of the response to the producer.

20 3. Analysis and Design

Figure 3.2: Camel OpenStack Data Flow diagram

3.0.5 Camel OpenStack URI As we mentioned in chapter 2.1.2 there is common scheme of Camel Component URIs. This part of analysis needs more focus due to large size of the whole component. I considered the following three solutions 5.

1) The first solution is the simplest one. There is no identifier of OpenStack project which we will be communicating with. The scheme is just "openstack" and context path is host URI. All configuration options needed are configured by URI options.

openstack: https://host?system=flavors &operation=create &username=xxx &password=xxx &... Pros ∙ This is usual component URI scheme in Camel. ∙ It is the easiest URI scheme which comes to mind first.

5. All examples are configured to create new flavor using OpenStack-Nova project

21 3. Analysis and Design

Cons ∙ In this solution would be very many operation options, each would be valid only for exactly one service/subsystem setting. ∙ Configuration would be very confused and URIs has to bevery long. ∙ We can’t easy identify OpenStack project we are communicating with.

2) This solution is inspired by Jclouds component6. openstack:nova: https://host?system=flavors &operation=create &username=xxx &password=xxx &.. Pros ∙ We can easily recognize OpenStack project we are communicating with. Cons ∙ Context path would have to be parsed into component name part and host URL. ∙ Other cons remains: many options which makes component configuration confused.

3) This solution is inspired by AWS component7. We would divide the big OpenStack component into six separate components. openstack−nova: https://host?system=flavors &operation=create &username=xxx &password=xxx &..

6. http://camel.apache.org/jclouds.html 7. http://camel.apache.org/aws.html

22 3. Analysis and Design

Pros

∙ We can easily recognize OpenStack project we are communicating with.

∙ We can restrict URI options to those which could be really used with selected component.

It may seem that all suggested solutions have too long URIs. Using some library like GraphQL8 seems like a good solution. Unfortunately, using library is not possible. URIs are processed by DefaultEndpoint class9 which is a part of Camel core and OpenStack endpoints inherit from it. Moreover, suggested solutions use the standard Camel component configuration. Using different approach would make configuring OpenStack component a little bit confused for Camel users.

After considering all possibilities and discussing them with the Camel developer community we decided to use the third solution so the result of this thesis is not only one component but six components which scheme is: openstack-nova, openstack-glance, openstack- keystone, openstack-neutron, openstack-swift and openstack-cinder.

3.0.6 OpenStack4j OpenStack system supports communication through REST API. We decided to use this API in Camel OpenStack component. Taking care about this communication on your own is not a good idea because OpenStack is very large system and also the OpenStack API is very complex. Implementing such huge and complex API would be very tricky and it would be probably full of bugs. As we mentioned before OpenStack4j is the library suggested to use by Camel community. There are several other libraries which can be used to communicate with OpenStack system from project written in Java but the OpenStack4j is the most precise and supports all operations needed by Camel OpenStack component.

8. http://graphql.org/ 9. http://static.javadoc.io/org.apache.camel/camel-core/2.18.0/org/ apache/camel/impl/DefaultEndpoint.html

23 3. Analysis and Design

Using OpenStack4j library makes implementing our new component much easier but it also brings several problems. We will talk about the most important ones.

API Mapping To understand this problem we have to insight deeper into Camel’s message model. As we mentioned in chapter 2.1.2 data in Camel are transported in message headers and message body. Because objects which we want to send into OpenStack could be very complex, some- times is not possible to transfer all data in message headers. The other possibility is transfer data in message body as an object. Here we are facing potential issue. There are two possibilities how to do this:

1. Directly use objects which are used by ObenStack4j library. This option is the simplest one. We do not have to deal with any API mapping. We just take an object which is sent by user and send it to the OpenStack4j library. But there are also cons. We force Camel users to use OpenStack4j API directly. This decision make the whole component depen- dent on OpenStack4j because it is almost impossible to change the library behind the component without braking changes in component API.

2. Create new Camel OpenStack API. In this option we would create new API which would be similar to OpenStack4j API. Camel users would be using only Camel API so there would be no problem with using another library. Here we face the following problem. OpenStack4j uses builder pattern[5] which makes almost impossible to use some mapping library like Dozer10 or ModelMapper11. This problem is not easy to solve due to a huge number of necessary configuration classes. We discussed this problem with technical leader of this thesis and we agreed that solution of this problem is code generation.

10. http://dozer.sourceforge.net/ 11. http://modelmapper.org/

24 3. Analysis and Design

During researching how solve this problem other Camel components, we noticed that most of Camel components not solve this problem at all (they use the first solution). This finding lead us toopen a discussion on this topic in Camel community. The Result of this discussion was that the implementation of mapping between Camel OpenStack API and the one for Openstack4j is just another layer and a waste of work. I disagree with this statement but it was a community requirement and therefore we uses the first solution.

OpenStack4j with DevStack

DevStack[4] is series of scripts which are used to download and run complete OpenStack instance. Those scripts download latest versions of OpenStack projects from git master, build those projects and start full instance of OpenStack environment. DevStack was used during testing Camel OpenStack component. DevStack is based on the latest OpenStack version. OpenStack community made minor changes in Keystone v3 API. OpenStack4j can’t keep up with latest community OpenStack projects. This is the reason why OpenStack4j Keystone does not work properly with DevStack. I opened an issue in OpenStack4j project12 and explained my problem to OpenStack4j developers as well as Camel community. At the time this thesis is written Camel openstack-keystone component works properly only with released OpenStack versions (tested with Red Hat OpenStack Platform).

3.0.7 Class Diagram

Camel OpenStack is divided into six sub-components. All those sub- components share very similar structure. We will show this common structure in this section. Possible differences would be explained in chapters 4.1.1 – 4.1.6 .

12. https://github.com/ContainX/openstack4j/issues/902

25 3. Analysis and Design

Figure 3.3: Class diagram

3.0.8 Dynamic component loading Another very important thing is Camel’s dynamic component loading. New components do not have to be registered. Camel loads components dynamically. Camel component providers are identified by placing a provider-configuration file META-INF/services. Therefore we created following files in this directory:

Figure 3.4: Component resources directory

File name identifies component URI scheme part.

26 4 Implementation

This chapter summarizes implementation of the Camel OpenStack component. The whole component is divided into six sub-components. In the first section of this chapter we will talk about common parts which all sub-components shares. In the second section we focus more on each component and will talk about each component separately.

List of technologies and libraries used ∙ Java 1.8 – Apache Camel’s target is Java 1.8 from Camel version 2.18

∙ Apache Maven version: 3.3.3 – build automation tool

∙ camel-core version: 2.19.0 – newly created component will be available from Camel 2.19

∙ openstack4j-core version: 3.0.2 – OpenStack4j library core

∙ openstack4j-okhttp version: 3.0.2 – OpenStack4j okhttp con- nector

Testing:

∙ camel-test version: 2.19.0 – Camel test module

∙ mockito-core version: 1.10.19 – Mockito library used for mocking OpenStack4j library in unit tests

The whole process of development new Camel component was tracked at GitHub as well as the whole Apache Camel project1. The source code of the new component was written in programming language Java[7][13]. Camel community has very strict source code con- ventions which our new component has to follow.

1. https://github.com/apache/camel

27 4. Implementation Quick start

The easiest way how to start with writing new Camel component[3] is using Maven archetype generator. Following command will generate new Maven project. mvnarchetype:generate \ −DarchetypeGroupId=org.apache.camel. archetypes \ −DarchetypeArtifactId=camel−archetype−component \ −DarchetypeVersion=2.9.0 \ −DgroupId=myGroupId \ −DartifactId=myArtifactId

The project is functional HelloWorld component which is ready to be used with Camel.

4.1 Component structure

Figure 4.1: Package diagram

The whole component is divided into six sub-components and this structure is followed by component package names. We can list sub- component names and the packages that are located in: openstack-nova– org.apache.camel.component.openstack.nova openstack-keystone– org.apache.camel.component.openstack.keystone openstack-glance– org.apache.camel.component.openstack.glance openstack-neutron– org.apache.camel.component.openstack.neutron

28 4. Implementation

openstack-swift– org.apache.camel.component.openstack.swift

openstack-cinder– org.apache.camel.component.openstack.cinder

There is another additional package which is called org.apache.camel.component.openstack.common. Classes that are shared between all sub-modules are located in this package.

Component classes

org.apache.camel.component.openstack.common

Classes that are shared between all sub-modules are located in this package.

OpenstackConstants

Figure 4.2: OpenstackConstants

This class is used for storing constants which are shared between all sub-components.

29 4. Implementation

AbstractOpenstackEndpoint

Figure 4.3: AbstractOpenstackEndpoint

This class is intended to be parent of all Endpoint classes in Camel OpenStack component. The most important method in this class is createClient() which returns authenticated OpenStack client which is used as a mediation engine between OpenStack and Camel.

AbstractOpenstackProducer

Figure 4.4: AbstractOpenstackProducer

This class is intended to be parent of all Producer classes in Camel OpenStack component and provide utility methods to each producer.

Similar classes splitted through the component There is a lot of classes which are split through the whole component and have very similar purpose. We can focus on them at once.

30 4. Implementation

Component (NovaComponent, GlanceComponent, KeystoneComponent, Neutron- Component, SwiftComponent, CinderComponent)

Figure 4.5: Component class

This class is intended to be factory of Endpoint class. There is only one method which returns Endpoint class instance for each sub- component.

Endpoint (NovaEndpoint, GlanceEndpoint, KeystoneEndpoint, NeutronEnd- point, SwiftEndpoint, CinderEndpoint)

Figure 4.6: Endpoint class

This class is intended to be property placeholder for endpoint configuration and factory of Producer class or Consumer class. Wedo not support any consumer so method createConsumer() will always throw an exception. More interested is createProducer() method. This method returns producer class based on the subsystem option from Endpoint class.

31 4. Implementation

Producer (producer classes are listed in each sub-component separately)

Figure 4.7: Producer class

Producer class is the component’s connection point with Open- Stack system. Camel messages are transformed and sent to OpenStack system, OpenStack responses are transformed back into messages and sent back to Camel’s route. OpenStack component tries to be user-friendly and provides Camel users as much freedom as they can have. Users can specify their requirements in message headers as well as in message body. Another producer’s responsibility is to ensure that this two ways will always have the same result.

4.1.1 openstack-nova Full class diagram of openstack-nova could be found in Appendix A (Sub-components class diagrams).

Nova producers

Figure 4.8: Nova producers

32 4. Implementation

NovaEndpoint creates Producer class according to endpoint subsystem option. Each producer is responsible for communication with one OpenStack Nova sub-module.

URI scheme

openstack−nova://hosturl[?options]

You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Nova component supports 9 endpoint options which are listed below:

Option name Description host Required OpenStack host url subsystem Required OpenStack Nova subsystem password Required OpenStack password username Required OpenStack username project Required The project ID apiVersion OpenStack API version config OpenStack configuration domain Authentication domain operation The operation to do

4.1.2 openstack-glance

Full class diagram of openstack-glance could be found in Appendix A (Sub-components class diagrams).

33 4. Implementation

Glance producer

Figure 4.9: Glance producer

URI scheme openstack−glance://hosturl[?options]

You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Glance component supports 8 endpoint options which are listed below:

Option name Description host Required OpenStack host url password Required OpenStack password username Required OpenStack username project Required The project ID apiVersion OpenStack API version config OpenStack configuration domain Authentication domain operation The operation to do

4.1.3 openstack-neutron Full class diagram of openstack-neutron could be found in Appendix A (Sub-components class diagrams).

34 4. Implementation

Neutron producers

Figure 4.10: Neutron producers

URI scheme

openstack−glance://hosturl[?options]

You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Neutron component supports 9 endpoint options which are listed below:

Option name Description host Required OpenStack host url subsystem Required OpenStack Neutron subsystem password Required OpenStack password username Required OpenStack username project Required The project ID apiVersion OpenStack API version config OpenStack configuration domain Authentication domain operation The operation to do

4.1.4 openstack-keystone

Full class diagram of openstack-keystone could be found in Appendix A (Sub-components class diagrams).

35 4. Implementation

Keystone producers

Figure 4.11: Keystone producers

Only v3 API is supported in Camel openstack-keystone because v2 API is deprecated nowadays. Component is designed to allow a simply extension of another API versions.

URI scheme openstack−glance://hosturl[?options] You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Keystone component supports 8 endpoint options which are listed below: Option name Description host Required OpenStack host url subsystem Required OpenStack Keystone subsystem password Required OpenStack password username Required OpenStack username project Required The project ID config OpenStack configuration domain Authentication domain operation The operation to do

4.1.5 openstack-swift Full class diagram of openstack-swift could be found in Appendix A (Sub-components class diagrams).

36 4. Implementation

Swift producers

Figure 4.12: Swift producers

URI scheme

openstack−swift://hosturl[?options]

You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Swift component supports 9 endpoint options which are listed below:

Option name Description host Required OpenStack host url subsystem Required OpenStack Swift subsystem password Required OpenStack password username Required OpenStack username project Required The project ID config OpenStack configuration domain Authentication domain apiVersion OpenStack API version operation The operation to do

37 4. Implementation

4.1.6 openstack-cinder

Full class diagram of openstack-cinder could be found in Appendix A (Sub-components class diagrams).

Cinder producers

Figure 4.13: Cinder producers

URI scheme

openstack−swift://hosturl[?options]

You can append query options to the URI in the following format ?options=value& option2=value& ... The OpenStack Cinder component supports 9 endpoint options which are listed below:

38 4. Implementation

Option name Description host Required OpenStack host url subsystem Required OpenStack Cinder subsystem password Required OpenStack password username Required OpenStack username project Required The project ID config OpenStack configuration domain Authentication domain apiVersion OpenStack API version operation The operation to do

4.2 Testing

4.2.1 Unit Tests

OpenStack component communicates with third party system. Unit testing should focus only on tested unit therefore this communication must be eliminated in component unit tests. The solution of this problem is Mocking. All classes from OpenStack4j library used in Camel OpenStack component are mocked in all unit tests. This approach ensures that we will test only component classes (not library classes). Mocking also eliminates the communication between Camel and OpenStack. The most important parts of the whole component are Producer classes. Therefore all producer classes are covered by unit tests. Due to mocking unit tests have also a little complicated structure which we will depict on Figure 4.14.

39 4. Implementation

Figure 4.14: Tests structure

AbstractProducerTestSupport – Mock OSClient and Exchange classes «Comp»ProducerTestSupport – Mock client services used in «Comp»2

4.2.2 Integration Tests Because Camel OpenStack is really large component there is a lot of places where could be an integration bug. In order to ensure that resulting component will work as expected we have implemented several integration tests. These tests need more configuration and (that is the biggest problem) running OpenStack instance. For this reason integration tests can’t be run in every component build and therefore those tests are not a part of the source code of Camel OpenStack component that you can find in Camel’s repository. These tests are

2. «Comp» should be substituted by the component name

40 4. Implementation

available only on CD attached to this thesis and they are disabled by default. If you want to run them, follow these steps: 1. Configure parameters in OpenstackTestProperties.properties file. Logging parameters:

∙ OPENSTACK_URI - URL of openstack instance (for example: http://127.0.0.1:5000/v3) ∙ OPENSTACK_USERNAME - OpenStack username (will be used by IT tests) ∙ OPENSTACK_PASSWORD - user password ∙ PROJECT_ID - test project ID

Following parameters are used in ServerITTest: (those parameters will be used for creating new server instances)

∙ IMAGE_ID - image ID ∙ FLAVOR_ID - flavor ID ∙ NETWORK_ID - network ID

2. Run tests with Maven Integration tests are managed by Maven Failsafe Plugin3. You should run Maven build with it-test profile in order to enable execution of these tests. $ mvn clean install −Pit−t e s t

Integration tests strongly relies on OpenStack configuration - it is possible that some test fails. In that case revise your OpenStack instance configuration (especially available resources etc.).

4.3 Documentation

Another Camel’s community requirement is writing documentation of newly created component. This requirement is natural because only the person who writes the component source code has enough

3. http://maven.apache.org/surefire/maven-failsafe-plugin/

41 4. Implementation knowledge to write component documentation. This documentation will be available at Camel’s manual web pages. This full documentation is available as an appendix B (Camel OpenStack documentation) and also can be found in docs folder on appended CD in AsciiDoc4 format.

4. http://www.methods.co.nz/asciidoc/

42 5 Conclusion

The main goal of this thesis was to write a new big Camel component which will allow Camel users to communicate with and configure OpenStack system. This component was required byCamel community and was tracked on Camel’s jira. All source code files are available at GitHub as well as an attachment of this thesis. This component should support six the most relevant OpenStack modules, other modules are left for further expansion. Camel OpenStack component was successfully developed. The outcome of this thesis met my requirements as well as requirements of Camel community and was successfully merged into Camel project. As was mentioned in chapter 3.0.1 there was no way how to use OpenStack via Camel which allowed users straightforward use of full power of OpenStack system. I assume that Camel OpenStack would be really useful and popular in Camel. Newly created component is properly tested, well documented in various sources available online and offline. I met several issues when working on this thesis. I had to discuss them with Camel community1, OpenStack4j community2,3 and mostly with this thesis technical leader from Red Hat. I think that this thesis was a great opportunity to improve my programming skills and technical experience. I was delighted to partici- pate on useful and important project which has really great developer community. Camel developers were willing to help me with every problem during component implementation. I also had to get familiar with OpenStack system. This knowledge is also very useful nowadays because OpenStack is very common type of cloud computing system. Various cloud systems are used in the most of modern systems and companies and my personal opinion is that cloud computing is the future of IT.

1. https://issues.apache.org/jira/browse/CAMEL-9748 2. https://github.com/ContainX/openstack4j/issues/902 3. https://github.com/ContainX/openstack4j/issues/899

A Sub-components class diagrams

Figure A.1: openstack-nova class diagram

45 A. Sub-components class diagrams

Figure A.2: openstack-glance class diagram

46 A. Sub-components class diagrams

Figure A.3: openstack-keystone class diagram

47 A. Sub-components class diagrams

Figure A.4: openstack-neutron class diagram

48 A. Sub-components class diagrams

49 Figure A.5: openstack-swift class diagram A. Sub-components class diagrams

Figure A.6: openstack-cinder class diagram

50 B Camel OpenStack documentation

51 Openstack Component

Available as of Camel 2.19

The openstack component is a component for managing your OpenStack applications.

Maven users will need to add the following dependency to their pom.xml for this component:

org.apache.camel camel-openstack x.x.x

OpenStack service Camel Component Description OpenStack Cinder openstack-cinder Component to maintain OpenStack cinder. OpenStack Glance openstack-glance Component to maintain OpenStack glance. OpenStack Keystone openstack-keystone Component to maintain OpenStack keystone. OpenStack Neutron openstack-neutron Component to maintain OpenStack neutron. OpenStack Nova openstack-nova Component to maintain OpenStack nova. OpenStack Swift openstack-swift Component to maintain OpenStack swift.

See Also

• Configuring Camel

• Component

• Endpoint

• Getting Started

• openstack Component

1 OpenStack Nova Component

Available as of Camel version 2.19

The openstack-nova component allows messages to be sent to an OpenStack compute services.

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-nova://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Nova component has no options.

The OpenStack Nova component supports 10 endpoint options which are listed below:

Name Group Default Java Type Description host producer String Required OpenStack host url apiVersion producer V3 String OpenStack API version config producer Config OpenStack configuration domain producer default String Authentication domain operation producer String The operation to do password producer String Required OpenStack password project producer String Required The project ID subsystem producer String Required OpenStack Nova subsystem username producer String Required OpenStack username

2 Name Group Default Java Type Description synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

You can use following settings for each subsystem: flavors

Operations you can perform with the Flavor producer

Operation Description create Create new flavor. get Get the flavor. getAll Get all flavors. delete Delete the flavor.

Message headers evaluated by the Flavor producer

Header Type Description operation String The operation to perform. ID String ID of the flavor. name String The flavor name. VCPU Integer The number of flavor VCPU. ram Integer Size of RAM. disk Integer Size of disk. swap Integer Size of swap. rxtxFactor Integer Rxtx Factor.

If you need more precise flavor settings you can create new object of the type org.openstack4j.model.compute.Flavor and send in the message body. servers

Operations you can perform with the Server producer

Operation Description create Create new server. createSnapshot Create snapshot of the server.

3 Operation Description get Get the server. getAll Get all servers. delete Delete the server. action Perform an action on the server.

Message headers evaluated by the Server producer

Header Type Description operation String The operation to perform. ID String ID of the server. name String The server name. ImageId String The Image ID. FlavorId String The ID of flavor which will be used. KeypairName String The Keypair name. NetworkId String The network ID. AdminPassword String Admin password of the new server. action org.openstack4j.model.compute.Action An action to perform.

If you need more precise server settings you can create new object of the type org.openstack4j.model.compute.ServerCreate and send in the message body. keypairs

Operations you can perform with the Keypair producer

Operation Description create Create new keypair. get Get the keypair. getAll Get all keypairs. delete Delete the keypair.

Message headers evaluated by the Keypair producer

Header Type Description operation String The operation to perform. name String The keypair name.

4 OpenStack Glance Component

Available as of Camel version 2.19

The openstack-glance component allows messages to be sent to an OpenStack image services.

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-glance://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Glance component has no options.

The OpenStack Glance component supports 9 endpoint options which are listed below:

Name Group Default Java Type Description host producer String Required OpenStack host url apiVersion producer V3 String OpenStack API version config producer Config OpenStack configuration domain producer default String Authentication domain operation producer String The operation to do password producer String Required OpenStack password project producer String Required The project ID username producer String Required OpenStack username

5 Name Group Default Java Type Description synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

Operation Description reserve Reserve image. create Create new image. update Update image. upload Upload image. get Get the image. getAll Get all image. delete Delete the image.

Message headers evaluated by the Glance producer

Header Type Description operation String The operation to perform. ID String ID of the flavor. name String The flavor name. diskFormat org.openstack4j.model.image.DiskFormat The number of flavor VCPU. containerFormat org.openstack4j.model.image.ContainerFormat Size of RAM. owner String Image owner. isPublic Boolean Is public. minRam Long Minimum ram. minDisk Long Minimum disk. size Long Size. checksum String Checksum. properties Map Image properties.

6 OpenStack Keystone Component

Available as of Camel version 2.19

The openstack-keystone component allows messages to be sent to an OpenStack identity services.

The openstack-keystone component supports only Identity API v3!

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-keystone://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Keystone component has no options.

The OpenStack Keystone component supports 9 endpoint options which are listed below:

Name Group Default Java Type Description host producer String Required OpenStack host url config producer Config OpenStack configuration domain producer default String Authentication domain operation producer String The operation to do password producer String Required OpenStack password project producer String Required The project ID subsystem producer String Required OpenStack Keystone subsystem

7 Name Group Default Java Type Description username producer String Required OpenStack username synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

You can use following settings for each subsystem: domains

Operations you can perform with the Domain producer

Operation Description create Create new domain. get Get the domain. getAll Get all domains. update Update the domain. delete Delete the domain.

Message headers evaluated by the Domain producer

Header Type Description operation String The operation to perform. ID String ID of the domain. name String The domain name. description String Domain description.

If you need more precise domain settings you can create new object of the type org.openstack4j.model.identity.v3.Domain and send in the message body. groups

Operations you can perform with the Group producer

Operation Description create Create new group. get Get the group. getAll Get all groups. update Update the group.

8 Operation Description delete Delete the group. addUserToGroup Add the user to the group. checkUserGroup Check whether is the user in the group. removeUserFromGrou Remove the user from the group. p

Message headers evaluated by the Group producer

Header Type Description operation String The operation to perform. groupId String ID of the group. name String The group name. userId String ID of the user. domainId String ID of the domain. description String Group description.

If you need more precise group settings you can create new object of the type org.openstack4j.model.identity.v3.Group and send in the message body. projects

Operations you can perform with the Project producer

Operation Description create Create new project. get Get the project. getAll Get all projects. update Update the project. delete Delete the project.

Message headers evaluated by the Project producer

Header Type Description operation String The operation to perform. ID String ID of the project. name String The project name. description String Project description. domainId String ID of the domain. parentId String The parent project ID.

9 If you need more precise project settings you can create new object of the type org.openstack4j.model.identity.v3.Project and send in the message body. regions

Operations you can perform with the Region producer

Operation Description create Create new region. get Get the region. getAll Get all regions. update Update the region. delete Delete the region.

Message headers evaluated by the Region producer

Header Type Description operation String The operation to perform. ID String ID of the region. description String Region description.

If you need more precise region settings you can create new object of the type org.openstack4j.model.identity.v3.Region and send in the message body. users

Operations you can perform with the User producer

Operation Description create Create new user. get Get the user. getAll Get all users. update Update the user. delete Delete the user.

Message headers evaluated by the User producer

Header Type Description operation String The operation to perform. ID String ID of the user. name String The user name.

10 Header Type Description description String User description. domainId String ID of the domain. password String User’s password. email String User’s email.

If you need more precise user settings you can create new object of the type org.openstack4j.model.identity.v3.User and send in the message body.

11 OpenStack Neutron Component

Available as of Camel version 2.19

The openstack-neutron component allows messages to be sent to an OpenStack network services.

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-neutron://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Neutron component has no options.

The OpenStack Neutron component supports 10 endpoint options which are listed below:

Name Group Default Java Type Description host producer String Required OpenStack host url apiVersion producer V3 String OpenStack API version config producer Config OpenStack configuration domain producer default String Authentication domain operation producer String The operation to do password producer String Required OpenStack password project producer String Required The project ID subsystem producer String Required OpenStack Neutron subsystem username producer String Required OpenStack username

12 Name Group Default Java Type Description synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

You can use following settings for each subsystem: networks

Operations you can perform with the Network producer

Operation Description create Create new network. get Get the network. getAll Get all networks. delete Delete the network.

Message headers evaluated by the Network producer

Header Type Description operation String The operation to perform. ID String ID of the network. name String The network name. tenantId String Tenant ID. adminStateUp Boolean AdminStateUp header. networkType org.openstack4j.model.network.NetworkType Network type. physicalNetwork String Physical network. segmentId String Segment ID. isShared Boolean Is shared. isRouterExternal Boolean Is router external.

If you need more precise network settings you can create new object of the type org.openstack4j.model.network.Network and send in the message body. subnets

Operations you can perform with the Subnet producer

13 Operation Description create Create new subnet. get Get the subnet. getAll Get all subnets. delete Delete the subnet. action Perform an action on the subnet.

Message headers evaluated by the Subnet producer

Header Type Description operation String The operation to perform. ID String ID of the subnet. name String The subnet name. networkId String Network ID. enableDHCP Boolean Enable DHCP. gateway String Gateway.

If you need more precise subnet settings you can create new object of the type org.openstack4j.model.network.Subnet and send in the message body. ports

Operations you can perform with the Port producer

Operation Description create Create new port. get Get the port. getAll Get all ports. update Update the port. delete Delete the port.

Message headers evaluated by the Port producer

Header Type Description operation String The operation to perform. name String The port name. networkId String Network ID. tenantId String Tenant ID. deviceId String Device ID. macAddress String MAC address.

14 routers

Operations you can perform with the Router producer

Operation Description create Create new router. get Get the router. getAll Get all routers. update Update the router. delete Delete the router. attachInterface Attach an interface. detachInterface Detach an interface.

Message headers evaluated by the Port producer

Header Type Description operation String The operation to perform. name String The router name. routerId String Router ID. subnetId String Subnet ID. portId String Port ID. interfaceType org.openstack4j.model.network.AttachInterfac Interface type. eType

tenantId String Tenant ID.

15 OpenStack Swift Component

Available as of Camel version 2.19

The openstack-swift component allows messages to be sent to an OpenStack object storage services.

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-swift://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Swift component has no options.

The OpenStack Swift component supports 10 endpoint options which are listed below:

Name Group Default Java Type Description host producer String Required OpenStack host url apiVersion producer V3 String OpenStack API version config producer Config OpenStack configuration domain producer default String Authentication domain operation producer String The operation to do password producer String Required OpenStack password project producer String Required The project ID subsystem producer String Required OpenStack Swift subsystem username producer String Required OpenStack username

16 Name Group Default Java Type Description synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

You can use following settings for each subsystem: containers

Operations you can perform with the Container producer

Operation Description create Create new container. get Get the container. getAll Get all containers. update Update the container. delete Delete the container. getMetadata Get metadata. createUpdateMetada Create/update metadata. ta

deleteMetadata Delete metadata.

Message headers evaluated by the Volume producer

Header Type Description operation String The operation to perform. name String The container name. X-Container-Meta- Map Container metadata prefix. X-Versions- String Versions location. Location

X-Container-Read String ACL - container read. X-Container-Write String ACL - container write. limit Integer List options - limit. marker String List options - marker. end_marker String List options - end marker. delimiter Characte List options - delimiter. r

path String List options - path.

17 If you need more precise container settings you can create new object of the type org.openstack4j.model.storage.object.options.CreateUpdateContainerOptions (in case of create or update operation) or org.openstack4j.model.storage.object.options.ContainerListOptions for listing containers and send in the message body. objects

Operations you can perform with the Object producer

Operation Description create Create new object. get Get the object. getAll Get all objects. update Get update the object. delete Delete the object. getMetadata Get metadata. createUpdateMetada Create/update metadata. ta

Message headers evaluated by the Object producer

Header Type Description operation String The operation to perform. containerName String The container name. objectName String The object name.

18 OpenStack Cinder Component

Available as of Camel version 2.19

The openstack-cinder component allows messages to be sent to an OpenStack block storage services.

Dependencies

Maven users will need to add the following dependency to their pom.xml. pom.xml

org.apache.camel camel-openstack ${camel-version} where ${camel-version} must be replaced by the actual version of Camel.

URI Format

openstack-cinder://hosturl[?options]

You can append query options to the URI in the following format ?options=value&option2=value&…

URI Options

The OpenStack Cinder component has no options.

The OpenStack Cinder component supports 10 endpoint options which are listed below:

19 Name Group Default Java Type Description username producer String Required OpenStack username synchronous advanced false boolean Sets whether synchronous processing should be strictly used or Camel is allowed to use asynchronous processing (if supported).

Usage

You can use following settings for each subsystem: volumes

Operations you can perform with the Volume producer

Operation Description create Create new volume. get Get the volume. getAll Get all volumes. getAllTypes Get volume types. update Update the volume. delete Delete the volume.

Message headers evaluated by the Volume producer

Header Type Description operation String The operation to perform. ID String ID of the volume. name String The volume name. description String Volume description. size Integer Size of volume. volumeType String Volume type. imageRef String ID of image. snapshotId String ID of snapshot. isBootable Boolean Is bootable.

If you need more precise volume settings you can create new object of the type org.openstack4j.model.storage.block.Volume and send in the message body.

20 snapshots

Operations you can perform with the Snapshot producer

Operation Description create Create new snapshot. get Get the snapshot. getAll Get all snapshots. update Get update the snapshot. delete Delete the snapshot.

Message headers evaluated by the Snapshot producer

Header Type Description operation String The operation to perform. ID String ID of the server. name String The server name. description String The snapshot description. VolumeId String The Volume ID. force Boolean Force.

If you need more precise server settings you can create new object of the type org.openstack4j.model.storage.block.VolumeSnapshot and send in the message body.

21 C Contents of attached CD

∙ master’s thesis in PDF format

∙ source code of the thesis in LATEX ∙ source code of camel-openstack component (including unit tests and integration tests)

∙ component documentation in AsciiDoc format

Bibliography

[1] Apache Camel. url: http : / / camel . apache . org/ (visited on 03/03/2017). [2] Ibsen Claus and Anstey Jonathan. Camel in Action. 2010. isbn: 19-351-8236-6. [3] Creating a new Camel Component. url: http://camel.apache. org / creating - a - new - camel - component . html (visited on 03/03/2017). [4] DevStack. url: https : / / docs . openstack . org / developer / devstack/ (visited on 03/03/2017). [5] Gamma Erich, Vlissides John, and Helm Richard. Design Pat- terns: Elements of Reusable Object-Oriented Software. 1994. isbn: 0201633612. [6] Bobby Woolf Gregor Hohpe. Enterprise Integration Patterns. 2003. isbn: 978-0321200686. [7] Java. url: https://www.java.com/ (visited on 03/03/2017). [8] Pepple Ken. Deploying OpenStack. 2011. isbn: 978-1-4493-1105-6. [9] Jamsa Kris. Cloud Computing. 2012. isbn: 1449647391. [10] OpenStack Community Welcome Guide. url: https://www.openstack. org / assets / welcome - guide / OpenStackWelcomeGuide . pdf (visited on 03/03/2017). [11] OpenStack Documentation. url: https://docs.openstack.org/ (visited on 03/03/2017). [12] Python. url: https://www.python.org/ (visited on 03/03/2017). [13] Martin Robert Cecil. Clean Code. 2008. isbn: 0132350882. [14] Cranton Scott and Korab Jakub. Apache Camel Developer’s Cook- book. 2013. isbn: 9781782170303. [15] Fifield Tom et al. OpenStack Operations Guide. 2014. isbn: 9781491946954. [16] Bumgardner V.K. Cody. OpenStack in Action. 2016. isbn: 1617292168.