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

+1 here. It would be a great addition in order to use oVirt for testing without users writing their own API scripts. On Mon, Nov 21, 2016 at 11:05 AM, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote: > +1 > > I agree with Barak's point. Plus it would make people (who use Vagrant) > aware of oVirt. > > Vojtech > > > ----- Original Message ----- > > From: "Barak Korren" <bkorren(a)redhat.com&gt; > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > Cc: board(a)ovirt.org, "devel" <devel(a)ovirt.org&gt; > > Sent: Monday, November 21, 2016 6:12:45 PM > > Subject: Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator > Project > > > > +1 > > I think oVirt had been missing from the list of Vagrant providers for > too > > long. > > > > On 21 November 2016 at 19:09, Sandro Bonazzola < sbonazzo(a)redhat.com > > wrote: > > > > > > > > > > > > > > Il 21/Nov/2016 17:55, "Brian Proffitt" < bproffit(a)redhat.com > ha > scritto: > > > > > > 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 > > > > > > > > > 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' (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 > > > > > > _______________________________________________ > > > Devel mailing list > > > Devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > -- > > Barak Korren > > bkorren(a)redhat.com > > RHEV-CI Team > > > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel