Re: [ovirt-devel] Project Proposal - Vagrant provider
We should probably deliver some feedback to the Marc before we vote on this officially. BKP On Mon, Oct 10, 2016 at 10:44 AM, Oved Ourfaliwrote: > Thanks for the proposal. > We're excited to add Vagrant into oVirt's portfolio of SDKs and > modules/providers! > Starting with the v4 ruby SDK makes sense to me. > CC-in some relevant guys to share their thoughts. > > Thanks! > Oved > > > On Sun, Oct 9, 2016 at 6:03 PM, Marc Young <3vilpeng...@gmail.com> wrote: > >> 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 ) >> ___ >> 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 > -- 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
Re: [ovirt-devel] Project Proposal - Vagrant provider
Thanks for the proposal. We're excited to add Vagrant into oVirt's portfolio of SDKs and modules/providers! Starting with the v4 ruby SDK makes sense to me. CC-in some relevant guys to share their thoughts. Thanks! Oved On Sun, Oct 9, 2016 at 6:03 PM, Marc Young <3vilpeng...@gmail.com> wrote: > 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 ) > ___ > 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
[ovirt-devel] Project Proposal - Vagrant provider
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 ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel