3:11 a.m.
+1
On 21 Nov 2016, at 17:55, Brian Proffitt <bproffit(a)redhat.com>
wrote:
All:
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.
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.
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:
+1
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).
±0
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.
-1
No, I veto this action. All vetos must include an explanation of why the veto is
appropriate. A veto with no explanation is void.
Thank you!
Brian Proffitt
---
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 <http://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
<http://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 )
--
Brian Proffitt
Principal Community Analyst
Open Source and Standards
@TheTechScribe
574.383.9BKP
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board