This release reorganizes the code into a python package and adds support for out-of-tree drivers.

Provisioners and pool drivers are now available for Huawei Dorado storage arrays.

This release adds a http/2 api to the daemon, user management, jwt/basic/x509 authentication and RBAC. New volume objects can be created to give services data a different lifecycle. Storage pools can be configured to spawn volumes from. Backend networks can be configured to give services internal ip addresses. Envoy-based Ingress Gateway can be configured to expose services with internal ip addresses to the world. Cluster configuration can now be stored in a synchronized configuration file.

This new driver add HA to the lxd stack, and make use of the excellent lxc container provisioning features.

This release extends the CRM features with a daemon responsible of heartbeating, cluster communications, and services orchestration.

The collector can act as docker private registries v2 authenticator, access controller, logger and search provider.

Other products, like SuSE Portus or Cesenta docker auth, are available to assume these roles. The OpenSVC implementation has the following distinctive features:

• No additional service integration for users with a private collector or using the public collector
• All other collector features available (services and assets management, service monitoring, configuration management, nodes config file versioning, reporting, forms and workflows, ...)
• Zero maintenance ACLs : the collector already knows about users, groups, apps responsibles, apps publications, services' app
• Zero maintenance user management : the collector already has a user base and authentication mecanism, either internal, LDAP, AD, radius, ...
• Provide a service login and ACLs in addition to user login and ACLs, so users don't have to let docker store their own credentials on the nodes for pull ops.
• Working docker search on private registries, with results honoring the ACLs
• Expose the registries ops through the collector Rest API and CLI, honoring ACLs

Full documentation at http://docs.opensvc.com/collector.docker.registries.html

The zpool disk resource, zfs fs resource, zfs sync resource, zpool and zfs checkers are now supported on Linux. Ubuntu 16.04 LTS ships zfs.

This new branch is focused on standard filesystem hierarchy and python3 support.

After a collector upgrade, client browsers cache needed to be flushed for the new version of static files to be loaded. This was causing confusion and made collector upgrades a not very smooth experience. Up-to-date collectors now provide the clients with the code revision number, and the client uses this code to seed the loaded static files urls, circumventing the browser's and proxies cache strategies.

Advanced forms features like using submitted form data as rest requests data, directly or after mangling by a javascript function, used to be executed by the client browser. As a consequences these features were not available when the forms were submitted throught the rest api. This limitation has been lifted. Mangling script execution and rest api requests are all done server-side. Manglers are executed in a nodejs sandbox subprocess. With these changes, it is now possible to submit through the rest api a form that formats multiple service configurations, creates the services, creates and attachs compliance rulesets.

A single OpenSVC collector is now able to handle more than 50k nodes and services, using redis to store the asynchronous messages received from the agents. Scaling to more nodes and services is still possible with additionnal collectors.

Forms are the entry-point of automation : they are served through a portal for end-user use, or through the rest api for tiers automation. They natively offer autocompletion and input validation using the rest api to fetch the objects from the collector's database, and they produce a dataset fed to routines like rest request, mailing, chaining with other forms, script execution. The generated dataset structures were limited to flat dictionnaries, lists of strings or numbers and lists of flat dictionnaries. The recent collector forms codebase now supports embedding forms in forms. This new feature allows the forms to produce arbitrarily complex dataset structures. Forms have also gained the ability to mangle the dataset with a user-defined javascript function embedded in the forms definition. The typical use-case is dataset templating. Read more in the documentation at http://docs.opensvc.com/collector.forms.html

The agent scheduler is a complex subsystem of the agent. It now has its own documentation section explaining its design, the schedule syntax and giving useful examples: http://docs.opensvc.com/agent.scheduler.html

Collector forms now support the new 'checklist' type input. Like other input types, the candidates can be fetched from an arbitrary call on the collector rest api, with arguments and variables read from other form inputs current value. Typical use-case, presenting a checkbox list of known fibre channel port names for the selected node in a LUN provisioning form.

The collector exposes a Rest API. This API has now more than 380 handlers covering all features accessible through the web front-end. The front-end now uses this API for data management. This API enables:

• Data feeding to and from external databases (cmdb, network cmdb, dns, monitoring, ...)
• Orchestration and automation of OpenSVC collector and agents functions from a tiers orchestrator
• Design, attachement, audit and remediation of configuration management rules

The Rest API documentation is embedded in the collector. Our live collector exposes it at https://collector.opensvc.com/init/rest/doc

OpenSVC now has ip address and volume drivers for amazon ec2. These drivers allow clustering between ec2 instances. Also check out http://docs.opensvc.com/agent.service.provisioning.html to see how to provision a full clustered service in a single OpenSVC command.

We will be presenting OpenSVC at the 22th April 2015 IT Innovation Forum. We look forward to the opportunity to describe the benefits of our solutions to the CRiP members and to collect their feedback. The event details are hosted at www.itiforums.com

A comment we often get from OpenSVC users is that usr/share/doc/template.env is not really helping when you need to add a new resource to a service : too unstructured and outdated at places. Fine, issue tackled. usr/share/doc/ now contains per-resource configlets automatically generated from the agent keyword dictionnary classes. As these classes are used by the service and resource provisioning features, they are guaranteed up-to-date and the configlets structure is strict. The result can be seen in the online documentation at http://docs.opensvc.com/agent.template.env.html

The OpenSVC agent now embeds drivers to handle rados block devices as services resources. A disk group driver handles mapping, unmapping, locking, unlocking and provisioning. A snapshot and a clone resource drivers are also available. The provisioning capability is of special interest here, as it allows end-to-end service provisioning in a single command : from storage allocation to the application deployment.

The internet-hosted OpenSVC collector is now upgraded to the lastest codebase and uses OpenSVC and docker for the software stack integration. The DRP replication is handled by the OpenSVC btrfs send/receive driver. We consider btrfs and docker have matured enough to trust them some of our serious production services at OVH. If you are interested in how to setup similar services, please get in touch: we are happy to share.