Thanks for the proposal. We're excited to add Vagrant into oVirt's portfolio of SDKs and modules/providers! Starting with the v4 ruby SDK makes sense to me. CC-in some relevant guys to share their thoughts. Thanks! Oved On Sun, Oct 9, 2016 at 6:03 PM, Marc Young <3vilpenguin(a)gmail.com&gt; wrote: > Project Proposal - Vagrant Provider > > A vagrant provider for oVirt v4 > > Abstract > > This will be a provider plugin for the Vagrant suite that allows > command-line ease of virtual machine provisioning and lifecycle > management. > > Proposal > > This Vagrant provider plugin will interface with the oVirt REST API > (version 4 and higher) using the oVirt provided ruby SDK > 'ovirt-engine-sdk-ruby'. This allows users to abstract the user > interface and experience into a set of command line abilities to > create, provision, destroy and manage the complete lifecycle of > virtual machines. It also allows the use of external configuration > management and configuration files themselves to be committed into > code. > > Background > > I have previously forked and maintained the 'vagrant-ovirt' gem as > 'vagrant-ovirt3' due to Gems requiring unique names. The original > author has officially abandoned the project. For the last few years > all code to maintain this project has been maintained by myself and a > few ad-hoc github contributors. This provider interfaced directly with > oVirt v3 using fog and rbovirt. The new project would be a fresh start > using the oVirt provided ruby SDK to work directly with version 4. > > Rationale > > The trend in configuration management, operations, and devops has been > to maintain as much of the development process as possible in terms of > the virtual machines and hosts that they run on. With software like > Terraform the tasks of creating the underlying infrastructure such as > network rules, etc have had great success moving into 'Infrastructure > as code'. The same company behind Terraform got their reputation from > Vagrant which aims to utilize the same process for virtual machines > themselves. The core software allows for standard commands such as > 'up', 'provision', 'destroy' to be used across a provider framework. A > provider for oVirt makes the process for managing VMs easier and able > to be controlled through code and source control. > > Initial Goals > > The initial goal is to get the base steps of 'up', 'down' (halt), and > 'destroy' to succeed using the oVirt provided ruby SDK for v4. > Stretch/followup goals would be to ensure testability and alternate > commands such as 'provision' and allow configuration management suites > like puppet to work via 'userdata' (cloud-init). > > Current Status > > The version 3 of this software has been heavily utilized. The original > fork known as 'vagrant-ovirt' has been abandoned with no plans to > communicate or move forward. My upstream fork has had great success > with nearly 4x the downloads from rubygems.org . Until my github fork > has more 'stars' I cannot take over it completely so the gem was > renamed 'vagrant-ovirt3'. This is also true for rubygems.org since > gems are not namespaced, therefore could not be published without a > unique name. The v4 provider is still pending my initial POC commit > but there are no current barriers except initial oVirt hosting. The > hosting of oVirt v3 for testing is a laptop on a UPS at my home, and > v4 is also a different pc attached to a UPS. > > External Dependencies > > RHEVM/oVirt REST API - This provider must interact with the API itself > to manage virtual machines. > > Initial Committers > > Marcus Young ( 3vilpenguin at gmail dot com ) > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel