5:55 p.m.
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
6:09 p.m.
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
6:12 p.m.
+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
6:14 p.m.
+1
I was looking for a declarative way to create VMs. This will make it
even more compatible with what I have.
--
Martin Sivak
SLA / oVirt
On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt <bproffit(a)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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:15 p.m.
+1
On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt <bproffit(a)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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:22 p.m.
+1 here for the same reason!
On Mon, Nov 21, 2016 at 12:12 PM, Barak Korren <bkorren(a)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 <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
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
6:26 p.m.
Big +1 on my end.
Thanks for the contribution!
Oved
On Nov 21, 2016 6:55 PM, "Brian Proffitt" <bproffit(a)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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:05 p.m.
+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>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: board(a)ovirt.org, "devel" <devel(a)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(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
7:23 p.m.
+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> 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>
> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> Cc: board(a)ovirt.org, "devel" <devel(a)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(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
9:23 a.m.
+1
On Mon, Nov 21, 2016 at 7:23 PM, Ryan Barry <rbarry(a)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(a)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(a)redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > Cc: board(a)ovirt.org, "devel" <devel(a)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(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
9:26 a.m.
+1
On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt <bproffit(a)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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:29 a.m.
--Apple-Mail=_E998834F-EC07-4C06-98E2-0848DE245FEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
+1
On Nov 22, 2016, at 9:26 AM, Roman Mohr <rmohr(a)redhat.com>
wrote:
=20
+1
=20
On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt <bproffit(a)redhat.com =
<mailto:bproffit@redhat.com>> wrote:
All:
=20
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.=20
=20
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.=20
=20
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:
=20
+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).
=20
=C2=B10
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.
=20
-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.
=20
Thank you!
Brian Proffitt
=20
=20
---
=20
Project Proposal - Vagrant Provider
=20
A vagrant provider for oVirt v4
=20
Abstract
=20
This will be a provider plugin for the Vagrant suite that allows
command-line ease of virtual machine provisioning and lifecycle
management.
=20
Proposal
=20
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.
=20
Background
=20
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.
=20
Rationale
=20
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.
=20
Initial Goals
=20
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).
=20
Current Status
=20
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 <http://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 =
<http://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.
=20
External Dependencies
=20
RHEVM/oVirt REST API - This provider must interact with the API itself
to manage virtual machines.
=20
Initial Committers
=20
Marcus Young ( 3vilpenguin at gmail dot com )
=20
--=20
Brian Proffitt
Principal Community Analyst
Open Source and Standards
@TheTechScribe
574.383.9BKP
=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_E998834F-EC07-4C06-98E2-0848DE245FEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">+1<div class=3D""><br
class=3D""><div><blockquote type=3D"cite"=
class=3D""><div class=3D"">On Nov 22, 2016, at 9:26 AM,
Roman Mohr =
<<a href=3D"mailto:rmohr@redhat.com" =
class=3D"">rmohr(a)redhat.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div
dir=3D"ltr" =
class=3D"">+1</div><div class=3D"gmail_extra"><br
class=3D""><div =
class=3D"gmail_quote">On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt =
<span dir=3D"ltr" class=3D""><<a
href=3D"mailto:bproffit@redhat.com" =
target=3D"_blank"
class=3D"">bproffit(a)redhat.com</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D""><div class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">All:</span></div><div
class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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. </span></div><div class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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. </span></div><div class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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:</span></div><div
class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div>+1<div =
class=3D"">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).<br class=3D""><br
class=3D"">=C2=B10</div><=
div class=3D"">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.<br class=3D""><br
class=3D"">-1</div><div =
class=3D"">No, I veto this action. All vetos must include an explanation =
of why the veto is appropriate. A veto with no explanation is =
void.</div><div class=3D""><br
class=3D""></div><div class=3D"">Thank =
you!</div><div class=3D"">Brian Proffitt</div><div
class=3D""><br =
class=3D""></div><div class=3D""><br
class=3D""></div><div =
class=3D"">---</div><div class=3D""><br
class=3D""></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Project Proposal =
- Vagrant Provider</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">A vagrant provider for oVirt v4</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Abstract</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">This will be a =
provider plugin for the Vagrant suite that allows</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">command-line ease of virtual machine provisioning and =
lifecycle</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px"
class=3D"">management.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Proposal</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">This Vagrant =
provider plugin will interface with the oVirt REST API</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">(version 4 and higher) using the oVirt provided ruby =
SDK</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px"
class=3D"">'ovirt-engine-sdk-ruby'. This =
allows users to abstract the user</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">interface and =
experience into a set of command line abilities to</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">create, provision, destroy and manage the complete lifecycle =
of</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">virtual machines. It also
allows =
the use of external configuration</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">management and =
configuration files themselves to be committed into</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">code.</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Background</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">I have previously forked and maintained the
'vagrant-ovirt' =
gem as</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'vagrant-ovirt3' due
to Gems =
requiring unique names. The original</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">author has =
officially abandoned the project. For the last few years</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">all code to maintain this project has been maintained by =
myself and a</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">few ad-hoc github
contributors. =
This provider interfaced directly with</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">oVirt v3 using fog and rbovirt. The new project would be a =
fresh start</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">using the oVirt provided ruby
SDK =
to work directly with version 4.</span><br style=3D"font-size:12.8px"
=
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">Rationale</span><br
=
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">The trend in =
configuration management, operations, and devops has been</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">to maintain as much of the development process as possible in =
terms of</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">the virtual machines and
hosts =
that they run on. With software like</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Terraform the =
tasks of creating the underlying infrastructure such as</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">network rules, etc have had great success moving into =
'Infrastructure</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">as code'. The same
company behind =
Terraform got their reputation from</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Vagrant which =
aims to utilize the same process for virtual machines</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">themselves. The core software allows for standard commands =
such as</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'up',
'provision', 'destroy' to be =
used across a provider framework. A</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">provider for =
oVirt makes the process for managing VMs easier and able</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">to be controlled through code and source
control.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Initial =
Goals</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">The initial goal is to get the base steps of 'up',
'down' =
(halt), and</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'destroy' to succeed
using the =
oVirt provided ruby SDK for v4.</span><br style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Stretch/followup =
goals would be to ensure testability and alternate</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">commands such as 'provision' and allow configuration =
management suites</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">like puppet to work via
'userdata' =
(cloud-init).</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Current Status</span><br
style=3D"font-size:12.8px" =
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">The version 3 of this
software has =
been heavily utilized. The original</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">fork known as =
'vagrant-ovirt' has been abandoned with no plans to</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">communicate or move forward. My upstream fork has had great =
success</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">with nearly 4x the downloads
=
from </span><a href=3D"http://rubygems.org/"
rel=3D"noreferrer" =
style=3D"font-size:12.8px" target=3D"_blank" =
class=3D"">rubygems.org</a><span
style=3D"font-size:12.8px" =
class=3D""> . Until my github fork</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">has more 'stars' I cannot take over it completely so the
gem =
was</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">renamed
'vagrant-ovirt3'. This is =
also true for </span><a href=3D"http://rubygems.org/" =
rel=3D"noreferrer" style=3D"font-size:12.8px"
target=3D"_blank" =
class=3D"">rubygems.org</a><span
style=3D"font-size:12.8px" =
class=3D""> since</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">gems are not =
namespaced, therefore could not be published without a</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">unique name. The v4 provider is still pending my initial POC =
commit</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">but there are no current
barriers =
except initial oVirt hosting. The</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">hosting of oVirt =
v3 for testing is a laptop on a UPS at my home, and</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">v4 is also a different pc attached to a UPS.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">External =
Dependencies</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">RHEVM/oVirt REST API - This provider must interact with the =
API itself</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">to manage virtual =
machines.</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Initial Committers</span><br
style=3D"font-size:12.8px" =
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">Marcus Young ( 3vilpenguin at
=
gmail dot com )</span><span class=3D"HOEnZb"><font
color=3D"#888888" =
class=3D""><br clear=3D"all" class=3D""><div
class=3D""><br =
class=3D""></div>-- <br class=3D""><div =
class=3D"m_5255044269514700025gmail_signature"><div dir=3D"ltr"
=
class=3D"">Brian Proffitt<div class=3D"">Principal Community
=
Analyst</div><div class=3D"">Open Source and
Standards</div><div =
class=3D"">@TheTechScribe</div><div =
class=3D"">574.383.9BKP</div></div></div>
</font></span></div></div>
<br class=3D"">______________________________<wbr =
class=3D"">_________________<br class=3D"">
Devel mailing list<br class=3D"">
<a href=3D"mailto:Devel@ovirt.org"
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">http://lists.ovirt.org/<wbr =
class=3D"">mailman/listinfo/devel</a><br
class=3D""></blockquote></div><br=
class=3D""></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br
class=3D""></div></body></html>=
--Apple-Mail=_E998834F-EC07-4C06-98E2-0848DE245FEA--
10:11 a.m.
--Apple-Mail=_E3D846C5-89EC-4969-9C63-CA3887F93A07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
+1
On 21 Nov 2016, at 17:55, Brian Proffitt <bproffit(a)redhat.com>
wrote:
=20
All:
=20
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.=20
=20
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.=20
=20
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:
=20
+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).
=20
=C2=B10
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.
=20
-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.
=20
Thank you!
Brian Proffitt
=20
=20
---
=20
Project Proposal - Vagrant Provider
=20
A vagrant provider for oVirt v4
=20
Abstract
=20
This will be a provider plugin for the Vagrant suite that allows
command-line ease of virtual machine provisioning and lifecycle
management.
=20
Proposal
=20
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.
=20
Background
=20
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.
=20
Rationale
=20
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.
=20
Initial Goals
=20
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).
=20
Current Status
=20
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 <http://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 =
<http://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.
=20
External Dependencies
=20
RHEVM/oVirt REST API - This provider must interact with the API itself
to manage virtual machines.
=20
Initial Committers
=20
Marcus Young ( 3vilpenguin at gmail dot com )
=20
--=20
Brian Proffitt
Principal Community Analyst
Open Source and Standards
@TheTechScribe
574.383.9BKP
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
--Apple-Mail=_E3D846C5-89EC-4969-9C63-CA3887F93A07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">+1<div class=3D""><br
class=3D""><div><blockquote type=3D"cite"=
class=3D""><div class=3D"">On 21 Nov 2016, at 17:55, Brian
Proffitt =
<<a href=3D"mailto:bproffit@redhat.com" =
class=3D"">bproffit(a)redhat.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div
dir=3D"ltr" =
class=3D""><div class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">All:</span></div><div
class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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. </span></div><div class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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. </span></div><div class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">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:</span></div><div
class=3D""><span =
style=3D"font-size:12.8px" class=3D""><br
class=3D""></span></div>+1<div =
class=3D"">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).<br class=3D""><br
class=3D"">=C2=B10</div><=
div class=3D"">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.<br class=3D""><br
class=3D"">-1</div><div =
class=3D"">No, I veto this action. All vetos must include an explanation =
of why the veto is appropriate. A veto with no explanation is =
void.</div><div class=3D""><br
class=3D""></div><div class=3D"">Thank =
you!</div><div class=3D"">Brian Proffitt</div><div
class=3D""><br =
class=3D""></div><div class=3D""><br
class=3D""></div><div =
class=3D"">---</div><div class=3D""><br
class=3D""></div><div =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Project Proposal =
- Vagrant Provider</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">A vagrant provider for oVirt v4</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Abstract</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">This will be a =
provider plugin for the Vagrant suite that allows</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">command-line ease of virtual machine provisioning and =
lifecycle</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px"
class=3D"">management.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Proposal</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">This Vagrant =
provider plugin will interface with the oVirt REST API</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">(version 4 and higher) using the oVirt provided ruby =
SDK</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px"
class=3D"">'ovirt-engine-sdk-ruby'. This =
allows users to abstract the user</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">interface and =
experience into a set of command line abilities to</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">create, provision, destroy and manage the complete lifecycle =
of</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">virtual machines. It also
allows =
the use of external configuration</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">management and =
configuration files themselves to be committed into</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">code.</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Background</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">I have previously forked and maintained the
'vagrant-ovirt' =
gem as</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'vagrant-ovirt3' due
to Gems =
requiring unique names. The original</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">author has =
officially abandoned the project. For the last few years</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">all code to maintain this project has been maintained by =
myself and a</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">few ad-hoc github
contributors. =
This provider interfaced directly with</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">oVirt v3 using fog and rbovirt. The new project would be a =
fresh start</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">using the oVirt provided ruby
SDK =
to work directly with version 4.</span><br style=3D"font-size:12.8px"
=
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">Rationale</span><br
=
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">The trend in =
configuration management, operations, and devops has been</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">to maintain as much of the development process as possible in =
terms of</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">the virtual machines and
hosts =
that they run on. With software like</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Terraform the =
tasks of creating the underlying infrastructure such as</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">network rules, etc have had great success moving into =
'Infrastructure</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">as code'. The same
company behind =
Terraform got their reputation from</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Vagrant which =
aims to utilize the same process for virtual machines</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">themselves. The core software allows for standard commands =
such as</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'up',
'provision', 'destroy' to be =
used across a provider framework. A</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">provider for =
oVirt makes the process for managing VMs easier and able</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">to be controlled through code and source
control.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Initial =
Goals</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">The initial goal is to get the base steps of 'up',
'down' =
(halt), and</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">'destroy' to succeed
using the =
oVirt provided ruby SDK for v4.</span><br style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">Stretch/followup =
goals would be to ensure testability and alternate</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">commands such as 'provision' and allow configuration =
management suites</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">like puppet to work via
'userdata' =
(cloud-init).</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Current Status</span><br
style=3D"font-size:12.8px" =
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">The version 3 of this
software has =
been heavily utilized. The original</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">fork known as =
'vagrant-ovirt' has been abandoned with no plans to</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">communicate or move forward. My upstream fork has had great =
success</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">with nearly 4x the downloads
=
from </span><a href=3D"http://rubygems.org/"
rel=3D"noreferrer" =
target=3D"_blank" style=3D"font-size:12.8px" =
class=3D"">rubygems.org</a><span
style=3D"font-size:12.8px" =
class=3D""> . Until my github fork</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">has more 'stars' I cannot take over it completely so the
gem =
was</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">renamed
'vagrant-ovirt3'. This is =
also true for </span><a href=3D"http://rubygems.org/" =
rel=3D"noreferrer" target=3D"_blank"
style=3D"font-size:12.8px" =
class=3D"">rubygems.org</a><span
style=3D"font-size:12.8px" =
class=3D""> since</span><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">gems are not =
namespaced, therefore could not be published without a</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">unique name. The v4 provider is still pending my initial POC =
commit</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">but there are no current
barriers =
except initial oVirt hosting. The</span><br style=3D"font-size:12.8px"
=
class=3D""><span style=3D"font-size:12.8px"
class=3D"">hosting of oVirt =
v3 for testing is a laptop on a UPS at my home, and</span><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">v4 is also a different pc attached to a UPS.</span><br =
style=3D"font-size:12.8px" class=3D""><br
style=3D"font-size:12.8px" =
class=3D""><span style=3D"font-size:12.8px"
class=3D"">External =
Dependencies</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">RHEVM/oVirt REST API - This provider must interact with the =
API itself</span><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">to manage virtual =
machines.</span><br style=3D"font-size:12.8px"
class=3D""><br =
style=3D"font-size:12.8px" class=3D""><span
style=3D"font-size:12.8px" =
class=3D"">Initial Committers</span><br
style=3D"font-size:12.8px" =
class=3D""><br style=3D"font-size:12.8px"
class=3D""><span =
style=3D"font-size:12.8px" class=3D"">Marcus Young ( 3vilpenguin at
=
gmail dot com )</span><br clear=3D"all" class=3D""><div
class=3D""><br =
class=3D""></div>-- <br class=3D""><div
class=3D"gmail_signature"><div =
dir=3D"ltr" class=3D"">Brian Proffitt<div
class=3D"">Principal Community =
Analyst</div><div class=3D"">Open Source and
Standards</div><div =
class=3D"">@TheTechScribe</div><div =
class=3D"">574.383.9BKP</div></div></div>
</div></div>
_______________________________________________<br class=3D"">Board =
mailing list<br class=3D""><a href=3D"mailto:Board@ovirt.org"
=
class=3D"">Board(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/board<br =
class=3D""></div></blockquote></div><br
class=3D""></div></body></html>=
--Apple-Mail=_E3D846C5-89EC-4969-9C63-CA3887F93A07--
11:26 a.m.
+1
----- Original Message -----
From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
To: "Brian Proffitt" <bproffit(a)redhat.com>
Cc: board(a)ovirt.org, "devel" <devel(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Francesco Romani
Red Hat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
11:48 a.m.
+1
----- Original Message -----
From: "Francesco Romani" <fromani(a)redhat.com>
To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
Cc: board(a)ovirt.org, "devel" <devel(a)ovirt.org>
Sent: Tuesday, November 22, 2016 11:26:39 AM
Subject: Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project
+1
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> To: "Brian Proffitt" <bproffit(a)redhat.com>
> Cc: board(a)ovirt.org, "devel" <devel(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
--
Francesco Romani
Red Hat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2716
days inactive
2717
days old
14 comments
15 participants
participants (15)
-
Barak Korren -
Brian Proffitt -
Francesco Romani -
Greg Sheremeta -
Jakub Niedermertl -
Martin Perina -
Martin Sivak -
Michal Skrivanek -
Oved Ourfali -
Piotr Kliczewski -
Roman Mohr -
Ryan Barry -
Sandro Bonazzola -
Vinzenz Feenstra -
Vojtech Szocs