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

Tue Nov 22 08:23:23 UTC 2016

+1

On Mon, Nov 21, 2016 at 7:23 PM, Ryan Barry <rbarry at redhat.com> wrote:

> +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 at redhat.com> 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 at redhat.com>
>> > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> > Cc: board at ovirt.org, "devel" <devel at ovirt.org>
>> > 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 at redhat.com >
>> wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> > Il 21/Nov/2016 17:55, "Brian Proffitt" < bproffit at 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 at ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > --
>> > Barak Korren
>> > bkorren at redhat.com
>> > RHEV-CI Team
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161122/debdf116/attachment.html>