+1 here for the same reason! On Mon, Nov 21, 2016 at 12:12 PM, Barak Korren <bkor...@redhat.com> wrote:
> +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 <sbona...@redhat.com> > wrote: > >> Il 21/Nov/2016 17:55, "Brian Proffitt" <bprof...@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@ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/devel >> >> >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > *Barak Korren* > bkor...@redhat.com > RHEV-CI Team > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gsher...@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel