+1 here for the same reason!
On Mon, Nov 21, 2016 at 12:12 PM, Barak Korren <bkorren(a)redhat.com> wrote:
I think oVirt had been missing from the list of Vagrant providers for too
On 21 November 2016 at 19:09, Sandro Bonazzola <sbonazzo(a)redhat.com>
> Il 21/Nov/2016 17:55, "Brian Proffitt" <bproffit(a)redhat.com> ha
> > 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
> > ±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
> My vote is +0. I have no strong opinion on this and I'm not using vagrant
> so I would be happy to leave other to decide.
> Using the + because I am happy to see the contribution ☺
> > 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'
> > '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
> > 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
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> Devel mailing list
Devel mailing list
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer