<div dir="ltr"><div><span style="font-size:12.8px">All:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This project was initially proposed for review on Oct. 9. It has been reviewed for major issues and having heard no objections, it's now time to formally vote on accepting this as an official oVirt incubator subproject. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The last time we voted on one of these was during an IRC weekly meeting, so I believe it is appropriate to post a Call for Vote on the Devel and Board lists. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes should be received to formalize this project as an incubator subproject. Please use the following vote process:</span></div><div><span style="font-size:12.8px"><br></span></div>+1<div>Yes, agree, or the action should be performed. On some issues, this vote must only be given after the voter has tested the action on their own system(s).<br><br>±0</div><div>Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental affects if too many people abstain.<br><br>-1</div><div>No, I veto this action. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void.</div><div><br></div><div>Thank you!</div><div>Brian Proffitt</div><div><br></div><div><br></div><div>---</div><div><br></div><div><span style="font-size:12.8px">Project Proposal - Vagrant Provider</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">A vagrant provider for oVirt v4</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Abstract</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">This will be a provider plugin for the Vagrant suite that allows</span><br style="font-size:12.8px"><span style="font-size:12.8px">command-line ease of virtual machine provisioning and lifecycle</span><br style="font-size:12.8px"><span style="font-size:12.8px">management.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Proposal</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">This Vagrant provider plugin will interface with the oVirt REST API</span><br style="font-size:12.8px"><span style="font-size:12.8px">(version 4 and higher) using the oVirt provided ruby SDK</span><br style="font-size:12.8px"><span style="font-size:12.8px">'ovirt-engine-sdk-ruby'. This allows users to abstract the user</span><br style="font-size:12.8px"><span style="font-size:12.8px">interface and experience into a set of command line abilities to</span><br style="font-size:12.8px"><span style="font-size:12.8px">create, provision, destroy and manage the complete lifecycle of</span><br style="font-size:12.8px"><span style="font-size:12.8px">virtual machines. It also allows the use of external configuration</span><br style="font-size:12.8px"><span style="font-size:12.8px">management and configuration files themselves to be committed into</span><br style="font-size:12.8px"><span style="font-size:12.8px">code.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Background</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">I have previously forked and maintained the 'vagrant-ovirt' gem as</span><br style="font-size:12.8px"><span style="font-size:12.8px">'vagrant-ovirt3' due to Gems requiring unique names. The original</span><br style="font-size:12.8px"><span style="font-size:12.8px">author has officially abandoned the project. For the last few years</span><br style="font-size:12.8px"><span style="font-size:12.8px">all code to maintain this project has been maintained by myself and a</span><br style="font-size:12.8px"><span style="font-size:12.8px">few ad-hoc github contributors. This provider interfaced directly with</span><br style="font-size:12.8px"><span style="font-size:12.8px">oVirt v3 using fog and rbovirt. The new project would be a fresh start</span><br style="font-size:12.8px"><span style="font-size:12.8px">using the oVirt provided ruby SDK to work directly with version 4.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Rationale</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">The trend in configuration management, operations, and devops has been</span><br style="font-size:12.8px"><span style="font-size:12.8px">to maintain as much of the development process as possible in terms of</span><br style="font-size:12.8px"><span style="font-size:12.8px">the virtual machines and hosts that they run on. With software like</span><br style="font-size:12.8px"><span style="font-size:12.8px">Terraform the tasks of creating the underlying infrastructure such as</span><br style="font-size:12.8px"><span style="font-size:12.8px">network rules, etc have had great success moving into 'Infrastructure</span><br style="font-size:12.8px"><span style="font-size:12.8px">as code'. The same company behind Terraform got their reputation from</span><br style="font-size:12.8px"><span style="font-size:12.8px">Vagrant which aims to utilize the same process for virtual machines</span><br style="font-size:12.8px"><span style="font-size:12.8px">themselves. The core software allows for standard commands such as</span><br style="font-size:12.8px"><span style="font-size:12.8px">'up', 'provision', 'destroy' to be used across a provider framework. A</span><br style="font-size:12.8px"><span style="font-size:12.8px">provider for oVirt makes the process for managing VMs easier and able</span><br style="font-size:12.8px"><span style="font-size:12.8px">to be controlled through code and source control.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Initial Goals</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">The initial goal is to get the base steps of 'up', 'down' (halt), and</span><br style="font-size:12.8px"><span style="font-size:12.8px">'destroy' to succeed using the oVirt provided ruby SDK for v4.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Stretch/followup goals would be to ensure testability and alternate</span><br style="font-size:12.8px"><span style="font-size:12.8px">commands such as 'provision' and allow configuration management suites</span><br style="font-size:12.8px"><span style="font-size:12.8px">like puppet to work via 'userdata' (cloud-init).</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Current Status</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">The version 3 of this software has been heavily utilized. The original</span><br style="font-size:12.8px"><span style="font-size:12.8px">fork known as 'vagrant-ovirt' has been abandoned with no plans to</span><br style="font-size:12.8px"><span style="font-size:12.8px">communicate or move forward. My upstream fork has had great success</span><br style="font-size:12.8px"><span style="font-size:12.8px">with nearly 4x the downloads from </span><a href="http://rubygems.org/" rel="noreferrer" target="_blank" style="font-size:12.8px">rubygems.org</a><span style="font-size:12.8px"> . Until my github fork</span><br style="font-size:12.8px"><span style="font-size:12.8px">has more 'stars' I cannot take over it completely so the gem was</span><br style="font-size:12.8px"><span style="font-size:12.8px">renamed 'vagrant-ovirt3'. This is also true for </span><a href="http://rubygems.org/" rel="noreferrer" target="_blank" style="font-size:12.8px">rubygems.org</a><span style="font-size:12.8px"> since</span><br style="font-size:12.8px"><span style="font-size:12.8px">gems are not namespaced, therefore could not be published without a</span><br style="font-size:12.8px"><span style="font-size:12.8px">unique name. The v4 provider is still pending my initial POC commit</span><br style="font-size:12.8px"><span style="font-size:12.8px">but there are no current barriers except initial oVirt hosting. The</span><br style="font-size:12.8px"><span style="font-size:12.8px">hosting of oVirt v3 for testing is a laptop on a UPS at my home, and</span><br style="font-size:12.8px"><span style="font-size:12.8px">v4 is also a different pc attached to a UPS.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">External Dependencies</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">RHEVM/oVirt REST API - This provider must interact with the API itself</span><br style="font-size:12.8px"><span style="font-size:12.8px">to manage virtual machines.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Initial Committers</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Marcus Young ( 3vilpenguin at gmail dot com )</span><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Brian Proffitt<div>Principal Community Analyst</div><div>Open Source and Standards</div><div>@TheTechScribe</div><div>574.383.9BKP</div></div></div>
</div></div>