-
Notifications
You must be signed in to change notification settings - Fork 0
Maloja project sitrep
| Status: | complete |
|---|---|
| Begins: | 2016-01-27 |
| Ends: | 2016-02-09 |
This sprint enhanced the build command. It focused on a particular scenario identified as useful to customers.
Created a design file based on real-world survey output. This is another step towards formalizing the design file syntax.
Gave the builder the ability to:
- Create networks
- Add VMs into VApps
- Create DNAT/SNAT rules
- Create Firewall rules
We are now able to demonstrate the utility of the build command. There is a tested, documented example for users to follow.
| Status: | complete |
|---|---|
| Begins: | 2016-01-18 |
| Ends: | 2016-01-26 |
This mini-sprint provided some missing elements to allow a formal release to a customer (Maloja 0.4.0).
- Clearer logging
- survey from either console or CLI
- Apache 2.0 licence
| Status: | complete |
|---|---|
| Begins: | 2016-01-11 |
| Ends: | 2016-01-15 |
This mini-sprint provided enhancements to the survey mode.
The survey output creates a deeper tree structure with better signposting of networks and catalogs. This makes it easier for an unfamiliar user to navigate the survey data.
These changes impacted the search function, which was modified accordingly.
Survey now records these extra details:
- Network DHCP pool
- RASD elements:
- Memory
- CPU
- Hard disk
The Implementation of the survey function was refactored, giving better testability and more code re-use.
| Status: | complete |
|---|---|
| Begins: | 2016-01-04 |
| Ends: | 2016-01-08 |
This mini-sprint is to consolidate the work so far.
The rapid development of the first few weeks has resulted in code which requires some tidying. In order to make the project accessible to other developers, we'd like to conform to commonly accepted coding standards, eg: PEP8.
We need to improve the experience for users. This means:
- Permit users to install Maloja using pip
- A more formal definition of the CLI
By the end of the sprint we are aiming to have a full set of HTML documentation covering:
- Installation
- Basic use
- Design implementation as a reference for developers
| Status: | complete |
|---|---|
| Begins: | 2015-12-28 |
| Ends: | 2015-12-31 |
This is a very short sprint between Christmas and New Year (4 days only).
The Builder module needs more work to make it useful. However, we also require further input from the customer. This sprint will concentrate on making the Builder good enough to demonstrate in order to solicit opinion on how best to use it.
I'll create a simple screencast to demonstrate:
- Maloja console
- survey command
| Status: | complete |
|---|---|
| Begins: | 2015-12-09 |
| Ends: | 2015-12-18 |
Customers have been interested in the possibilities of using the Maloja survey files as a means of defining a new set of assets, or modifying existing ones. We now have a provisional example of such a `design file`_ which can be created in a text editor from the output of a survey.
This sprint focused on a particular customer use case. The objective is to compose a new VApp from a number of Vms and to make firewalling and networking changes based on their IP addresses. This scenario is moderately complex and will likely take multiple sprints to fully implement. We are using this scenario to bring maturity to the Maloja toolkit.
Maloja now has a new command: build.
The Builder module takes a customer's design files as input, and progressively builds the corresponding assets in the cloud. Currently, this module is only a simple prototype and will develop in future sprints.
| Status: | complete |
|---|---|
| Begins: | 2015-11-30 |
| Ends: | 2015-12-08 |
In order to manipulate assets in your cloud, and reference one from another, you first have to find them. We have created a command with a very simple syntax which lets you search for objects by type and attribute. When multiple objects are returned you can select from the list in the console.
We want customers to be able to achieve very sophisticated site-specific tasks in Maloja. Now you can write your own module and have it plug in alongside the main library. Your plugin declares what objects it needs to work properly. When such objects have been found in search, you can invoke your plugin from the Maloja console.
A very simple plugin module intended as a demo and guide for plugin developers. From a selected Vdc and template, VApplicator will instantiate a VApp for you.
| Status: | complete |
|---|---|
| Begins: | 2015-11-16 |
| Ends: | 2015-11-27 |
We are some way from fully understanding what the Maloja CLI will look like. While we learn this, the main interface for invoking Maloja will be an interactive session, similar to a command shell.
This allows us to prototype functionality in a flexible, stateful process environment. The console is functional and supports some simple commands.
The first Maloja command to be implemented is survey. It asynchronously and recursively explores the assets of your cloud and caches the structure in a local project space on your PC.
We have adopted YAML as a flexible syntax to store data objects. Artifacts of the vCloud Director API such as Orgs, Templates, VApps and Vms can now be stored as human readable/editable files.