[ovirt-devel] [Call for Vote] Proposal for new Incubator Project

Tue Nov 22 10:26:39 UTC 2016

+1

----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>
> Cc: board at ovirt.org, "devel" <devel at ovirt.org>
> Sent: Tuesday, November 22, 2016 10:11:36 AM
> Subject: Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project
> 
> +1
> 
> 
> 
> 
> On 21 Nov 2016, at 17:55, Brian Proffitt < bproffit at 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 . 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 )
> 
> --
> Brian Proffitt
> Principal Community Analyst
> Open Source and Standards
> @TheTechScribe
> 574.383.9BKP
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

-- 
Francesco Romani
Red Hat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani