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