Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
by Sandro Bonazzola
Brian, Board, I think we have enough +1.
On Tue, Nov 22, 2016 at 10:02 AM, Jakub Niedermertl <jniederm(a)redhat.com>
wrote:
> +1
>
> ----- Original Message -----
> > From: "Roman Mohr" <rmohr(a)redhat.com>
> > To: "Brian Proffitt" <bproffit(a)redhat.com>
> > Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, board(a)ovirt.org, "devel" <
> devel(a)ovirt.org>
> > Sent: Tuesday, November 22, 2016 9:30:23 AM
> > Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> >
> > +1
> >
> > On Mon, Nov 21, 2016 at 6:07 PM, Brian Proffitt < bproffit(a)redhat.com >
> > wrote:
> >
> >
> >
> > All:
> >
> > The moVirt Project was initially accepted as an oVirt incubator project
> in
> > February 2015. It has been a successful subproject for quite some time
> and
> > it is well due for being accepted as a full oVirt project. I believe it
> is
> > appropriate to post a Call for Vote on the Devel and Board lists.
> >
> > http://www.ovirt.org/develop/projects/project-movirt/
> >
> > A “healthy” project, as determined by the oVirt Board, can be found at
> > http://www.ovirt.org/develop/projects/adding-a-new-project/
> >
> > Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes
> > should be received to formalize this project as an full oVirt project.
> > 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
> > 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
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
7 years, 5 months
[Call for Vote] Proposal for new Incubator Project
by Brian Proffitt
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
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
by Piotr Kliczewski
+1
On Tue, Nov 22, 2016 at 9:18 AM, Vinzenz Feenstra <vfeenstr(a)redhat.com> wrote:
>
> On Nov 22, 2016, at 9:12 AM, Tomas Jelinek <tjelinek(a)redhat.com> wrote:
>
>
>
> ----- Original Message -----
>
> From: "Nir Soffer" <nsoffer(a)redhat.com>
> To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> Cc: "devel" <devel(a)ovirt.org>, "board" <board(a)ovirt.org>
> Sent: Monday, November 21, 2016 10:00:05 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>
> On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek <mskrivan(a)redhat.com>
> wrote:
>
>
>
> On 21 Nov 2016, at 19:48, Vojtech Szocs <vszocs(a)redhat.com> wrote:
>
>
>
> ----- Original Message -----
>
> From: "Eyal Edri" <eedri(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "Barak Korren" <bkorren(a)redhat.com>, "devel" <devel(a)ovirt.org>,
> "board" <board(a)ovirt.org>, "Michal Skrivanek"
> <mskrivan(a)redhat.com>
> Sent: Monday, November 21, 2016 7:23:44 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>
> On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs <vszocs(a)redhat.com>
> wrote:
>
>
>
> ----- Original Message -----
>
> From: "Barak Korren" <bkorren(a)redhat.com>
> To: "Brian Proffitt" <bproffit(a)redhat.com>
> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, board(a)ovirt.org, "devel"
> <
>
> devel(a)ovirt.org>
>
> Sent: Monday, November 21, 2016 7:01:08 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt
> Project
>
> -1
>
>
> I wonder if 8x +1 beats one -1 :)
>
>
> 9X :-)
>
>
> adding my obviously biased +1, so not sure if it counts...
>
>
> +1 for including the project as is.
>
> If someone wants to run the project test or build it, the right way
> to vote is by sending patches and making it happen.
>
> I think we should get out of our gerrit silo and move all ovirt
> projects to github. This will give ovirt much better visibility.
>
> Here are some projects developed on github:
> https://github.com/systemd/systemd
> https://github.com/rust-lang/rust/
> https://github.com/kubernetes/kubernetes
>
>
> I would add also https://github.com/ManageIQ/ which we as oVirt devels are
> contributing to regularly.
>
>
> https://github.com/cockpit-project/cockpit
> https://github.com/OpenShift
>
>
>
>
> Nir
>
>
> Not because of anything with the project itself - I think it is
> genuinely awesome, but because I expect a project that emerges out of
> the incubation process to "look" like an oVirt project, by which I
> mean:
> 1. Have the code in the oVirt Gerrit
>
>
> I wonder why that would be required. We experimented with other projects
> being off gerrit as well(e.g. cockpit-ovirt) and bug tracking out of
> redhat bugzilla and for certain projcts it makes sense. With more
> integration with other upstream projects I see us moving to github even
> more...
>
> 2. Have tests and builds running on oVirt's CI system.
>
>
> Can we run mobile testing on current infra?
>
>
> We are using travis for this. Our complete config file is:
> language: android
> script: "./gradlew build"
> android:
> components:
> - platforms-tools
> - tools
> - build-tools-21.1.2
> - android-21
>
> We don't have any additional tooling developed or anything like that.
> If we will start thinking about doing some custom/complicated stuff, we
> may consider moving to ovirt's CI. Currently, I don't see a reason.
>
>
> 3. Have artefacts served from oVirt's mirrors.
>
>
> What artifacts? The final APK? Why? It's not a yum repo.
>
>
> We need to serve them using google play store so it will reach the users
> easily.
> We could serve also RPM packaged APKs
> or even create our alternative "something like play store" but Im not sure
> what benefits
> it would bring us.
>
>
> 4. Have bugs tracked in oVirt's bugzilla.
>
>
> No
> That should never be imposed on any new project. If someone loves slow
> outdated tools, so be it, but for new projects I again do not see us
> promoting it in future
>
>
> +1
>
> Well, long story short, moVirt is a simple small tool developed by a very
> small team
> and occasionally contributed by community (mostly as outreachy interns or
> intern candidates).
> It needs a swift, stable, minimal and well known tooling around which does
> exactly what we need.
> The current combination of github for code and issue tracking + travis for
> simple CI
> served us fantastically. I'm quite against moving to other place just
> because it may bring
> some benefits in the future.
>
>
>
> For 1 and 4, I feel that the benefit of allowing some projects to be
> hosted
> on GitHub (attract & involve community through GitHub's public service)
> does
> out-weigh the rule of strict consistency (have everything in oVirt
> Gerrit).
>
>
> Any project in oVirt gerrit can be mirrored to GitHub, and most of them
> are
> ( see github.com/oVirt )
>
>
> We do mirror it IIRC (or it may have been cockpit-ovirt), it's just the
> other way around - the master copy is at github
>
>
>
> Although, not sure how hard would it be to modify oVirt CI system to
> allow
> building GitHub hosted projects.
>
>
> We are supporting it, Lago is an example of such project.
>
>
>
> The guidelines should be clear about whether a project must be hosted
> via
> oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla,
> etc.
>
>
> I don't think its a must, but its highly recommended IMO, and will help
> the
> project grow.
> Imagine this scenario:
>
> the project grows and uses its own CI/testing frameworks and reaches a
> point it wants to join the oVirt eco-system,
> At that point it will be much harder to integrate it if at all, assuming
> the tools he's been using were not aligned with
> the tooling other projects are using.
>
> Also - in terms of release process, its will be very hard to include it
> in
> an official oVirt release if he wishes to do so,
> as all oVirt projects are built in the current infra and shipped as a
> single repository.
>
>
> You're missing the point it's not a yum repo.
>
>
> Eyal, I agree with your points.
>
> I just wanted to point out the possibility of hosting project's
> sources on GitHub (point 1 from Barak's list). And as you wrote,
> Lago is a good example of such project.
>
> Using standard oVirt CI infra & tools (points 2 & 3 from Barak's
> list) should be mandatory for all oVirt projects, to keep things
> manageable from build/release perspective. Full agreement here.
>
> As for bug tracking (point 4 from Barak's list), I see Lago using
> GitHub's issue tracking interface, so this should be OK too..
>
> In general, I'd say that moVirt maintainers should clearly voice
> their vision on converging (or not) towards points 1,2,3,4 that
> Barak has mentioned in his email.
>
>
> I would say no. And that is fine
>
>
> For me, having source code & issues on GitHub, but using standard
> oVirt CI infra & tools, is still acceptable for an oVirt project,
> but it's just my own opinion.
>
>
> I agree we can mix and match, though in this case I'm not sure how
> realistic is to run CI for an APK
>
>
>
>
>
>
> On 21 November 2016 at 19:07, Brian Proffitt <bproffit(a)redhat.com>
>
> wrote:
>
> All:
>
> The moVirt Project was initially accepted as an oVirt incubator
>
> project in
>
> February 2015. It has been a successful subproject for quite some time
>
> and
>
> it is well due for being accepted as a full oVirt project. I believe
>
> it is
>
> appropriate to post a Call for Vote on the Devel and Board lists.
>
> http://www.ovirt.org/develop/projects/project-movirt/
>
> A “healthy” project, as determined by the oVirt Board, can be found at
> http://www.ovirt.org/develop/projects/adding-a-new-project/
>
> Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7
>
> votes
>
> should be received to formalize this project as an full oVirt project.
> 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
> 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
>
>
>
>
> --
> 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
>
>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project
by Piotr Kliczewski
+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
>
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
by Eyal Edri
On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek <mskrivan(a)redhat.com>
wrote:
>
>
> > On 21 Nov 2016, at 19:48, Vojtech Szocs <vszocs(a)redhat.com> wrote:
> >
> >
> >
> > ----- Original Message -----
> >> From: "Eyal Edri" <eedri(a)redhat.com>
> >> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> >> Cc: "Barak Korren" <bkorren(a)redhat.com>, "devel" <devel(a)ovirt.org>,
> "board" <board(a)ovirt.org>, "Michal Skrivanek"
> >> <mskrivan(a)redhat.com>
> >> Sent: Monday, November 21, 2016 7:23:44 PM
> >> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt
> Project
> >>
> >>> On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs <vszocs(a)redhat.com>
> wrote:
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Barak Korren" <bkorren(a)redhat.com>
> >>>> To: "Brian Proffitt" <bproffit(a)redhat.com>
> >>>> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, board(a)ovirt.org,
> "devel" <
> >>> devel(a)ovirt.org>
> >>>> Sent: Monday, November 21, 2016 7:01:08 PM
> >>>> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt
> Project
> >>>>
> >>>> -1
>
> I wonder if 8x +1 beats one -1 :)
>
> >>>> Not because of anything with the project itself - I think it is
> >>>> genuinely awesome, but because I expect a project that emerges out of
> >>>> the incubation process to "look" like an oVirt project, by which I
> >>>> mean:
> >>>> 1. Have the code in the oVirt Gerrit
>
> I wonder why that would be required. We experimented with other projects
> being off gerrit as well(e.g. cockpit-ovirt) and bug tracking out of redhat
> bugzilla and for certain projcts it makes sense. With more integration with
> other upstream projects I see us moving to github even more...
>
> >>>> 2. Have tests and builds running on oVirt's CI system.
>
> Can we run mobile testing on current infra?
>
We won't know until we'll try right? fact is no one asked for it until now..
>
> >>>> 3. Have artefacts served from oVirt's mirrors.
>
> What artifacts? The final APK? Why? It's not a yum repo.
>
The fact we're only hosting RPMs (not entirely right, we host images as
well) doesn't mean we can't host anything else, we're actually working on
support for building/deploying containers.
I'm sure we can find a way if the project owner wants it.
>
> >>>> 4. Have bugs tracked in oVirt's bugzilla.
>
> No
> That should never be imposed on any new project. If someone loves slow
> outdated tools, so be it, but for new projects I again do not see us
> promoting it in future
>
I agree this point is less relevant, and each project can handle his own
tracking ( but again, if he will want to be released as part of oVirt and
not independently, then I'm not sure he'll have a choice but to align )
>
> >>>
> >>> For 1 and 4, I feel that the benefit of allowing some projects to be
> hosted
> >>> on GitHub (attract & involve community through GitHub's public service)
> >>> does
> >>> out-weigh the rule of strict consistency (have everything in oVirt
> Gerrit).
> >>>
> >>>
> >> Any project in oVirt gerrit can be mirrored to GitHub, and most of them
> are
> >> ( see github.com/oVirt )
>
> We do mirror it IIRC (or it may have been cockpit-ovirt), it's just the
> other way around - the master copy is at github
>
> >>
> >>
> >>> Although, not sure how hard would it be to modify oVirt CI system to
> allow
> >>> building GitHub hosted projects.
> >>>
> >>
> >> We are supporting it, Lago is an example of such project.
> >>
> >>
> >>>
> >>> The guidelines should be clear about whether a project must be hosted
> via
> >>> oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla,
> >>> etc.
> >>>
> >>
> >> I don't think its a must, but its highly recommended IMO, and will help
> the
> >> project grow.
> >> Imagine this scenario:
> >>
> >> the project grows and uses its own CI/testing frameworks and reaches a
> >> point it wants to join the oVirt eco-system,
> >> At that point it will be much harder to integrate it if at all, assuming
> >> the tools he's been using were not aligned with
> >> the tooling other projects are using.
> >>
> >> Also - in terms of release process, its will be very hard to include it
> in
> >> an official oVirt release if he wishes to do so,
> >> as all oVirt projects are built in the current infra and shipped as a
> >> single repository.
>
> You're missing the point it's not a yum repo.
>
See my comments above on supporting other artifacts than rpms.
I think you're missing the point of the advantages such a project can get
by joining, instead of managing its infra himself ( if it has any ),
It gets a massive CI/CD infrastructure already built and working, and will
be able to do integration / testing with a real oVirt instance (using OST
for e.g).
>
> >
> > Eyal, I agree with your points.
> >
> > I just wanted to point out the possibility of hosting project's
> > sources on GitHub (point 1 from Barak's list). And as you wrote,
> > Lago is a good example of such project.
> >
> > Using standard oVirt CI infra & tools (points 2 & 3 from Barak's
> > list) should be mandatory for all oVirt projects, to keep things
> > manageable from build/release perspective. Full agreement here.
> >
> > As for bug tracking (point 4 from Barak's list), I see Lago using
> > GitHub's issue tracking interface, so this should be OK too..
> >
> > In general, I'd say that moVirt maintainers should clearly voice
> > their vision on converging (or not) towards points 1,2,3,4 that
> > Barak has mentioned in his email.
>
> I would say no. And that is fine
>
> >
> > For me, having source code & issues on GitHub, but using standard
> > oVirt CI infra & tools, is still acceptable for an oVirt project,
> > but it's just my own opinion.
>
> I agree we can mix and match, though in this case I'm not sure how
> realistic is to run CI for an APK
>
>
I'm pretty sure that if we wanted to check that option, it will be possible
even if by using emulators, but no one from the project has ever approached
us so I can't really say anything before I see requirements.
I tend not to rule out anything I haven't verified possible before.
> >
> >>
> >>
> >>>
> >>>>
> >>>> On 21 November 2016 at 19:07, Brian Proffitt <bproffit(a)redhat.com>
> >>> wrote:
> >>>>> All:
> >>>>>
> >>>>> The moVirt Project was initially accepted as an oVirt incubator
> >>> project in
> >>>>> February 2015. It has been a successful subproject for quite some
> time
> >>> and
> >>>>> it is well due for being accepted as a full oVirt project. I believe
> >>> it is
> >>>>> appropriate to post a Call for Vote on the Devel and Board lists.
> >>>>>
> >>>>> http://www.ovirt.org/develop/projects/project-movirt/
> >>>>>
> >>>>> A “healthy” project, as determined by the oVirt Board, can be found
> at
> >>>>> http://www.ovirt.org/develop/projects/adding-a-new-project/
> >>>>>
> >>>>> Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7
> >>> votes
> >>>>> should be received to formalize this project as an full oVirt
> project.
> >>>>> 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
> >>>>> 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
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Eyal Edri
> >> Associate Manager
> >> RHV DevOps
> >> EMEA ENG Virtualization R&D
> >> Red Hat Israel
> >>
> >> phone: +972-9-7692018
> >> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >>
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
by Eyal Edri
On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Barak Korren" <bkorren(a)redhat.com>
> > To: "Brian Proffitt" <bproffit(a)redhat.com>
> > Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, board(a)ovirt.org, "devel" <
> devel(a)ovirt.org>
> > Sent: Monday, November 21, 2016 7:01:08 PM
> > Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> >
> > -1
> > Not because of anything with the project itself - I think it is
> > genuinely awesome, but because I expect a project that emerges out of
> > the incubation process to "look" like an oVirt project, by which I
> > mean:
> > 1. Have the code in the oVirt Gerrit
> > 2. Have tests and builds running on oVirt's CI system.
> > 3. Have artefacts served from oVirt's mirrors.
> > 4. Have bugs tracked in oVirt's bugzilla.
>
> For 1 and 4, I feel that the benefit of allowing some projects to be hosted
> on GitHub (attract & involve community through GitHub's public service)
> does
> out-weigh the rule of strict consistency (have everything in oVirt Gerrit).
>
>
Any project in oVirt gerrit can be mirrored to GitHub, and most of them are
( see github.com/oVirt )
> Although, not sure how hard would it be to modify oVirt CI system to allow
> building GitHub hosted projects.
>
We are supporting it, Lago is an example of such project.
>
> The guidelines should be clear about whether a project must be hosted via
> oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla,
> etc.
>
I don't think its a must, but its highly recommended IMO, and will help the
project grow.
Imagine this scenario:
the project grows and uses its own CI/testing frameworks and reaches a
point it wants to join the oVirt eco-system,
At that point it will be much harder to integrate it if at all, assuming
the tools he's been using were not aligned with
the tooling other projects are using.
Also - in terms of release process, its will be very hard to include it in
an official oVirt release if he wishes to do so,
as all oVirt projects are built in the current infra and shipped as a
single repository.
>
> >
> > On 21 November 2016 at 19:07, Brian Proffitt <bproffit(a)redhat.com>
> wrote:
> > > All:
> > >
> > > The moVirt Project was initially accepted as an oVirt incubator
> project in
> > > February 2015. It has been a successful subproject for quite some time
> and
> > > it is well due for being accepted as a full oVirt project. I believe
> it is
> > > appropriate to post a Call for Vote on the Devel and Board lists.
> > >
> > > http://www.ovirt.org/develop/projects/project-movirt/
> > >
> > > A “healthy” project, as determined by the oVirt Board, can be found at
> > > http://www.ovirt.org/develop/projects/adding-a-new-project/
> > >
> > > Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7
> votes
> > > should be received to formalize this project as an full oVirt project.
> > > 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
> > > 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
> >
> >
> >
> > --
> > 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
>
>
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
by Eyal Edri
On Mon, Nov 21, 2016 at 8:01 PM, Barak Korren <bkorren(a)redhat.com> wrote:
> -1
> Not because of anything with the project itself - I think it is
> genuinely awesome, but because I expect a project that emerges out of
> the incubation process to "look" like an oVirt project, by which I
> mean:
> 1. Have the code in the oVirt Gerrit
> 2. Have tests and builds running on oVirt's CI system.
> 3. Have artefacts served from oVirt's mirrors.
> 4. Have bugs tracked in oVirt's bugzilla.
>
I have to agree on the above, moVirt can be even greater if he can use the
tools all other oVirt projects are using.
The oVirt infra team is here to help close that gap if needed, shouldn't
take too long if the maintainers are on board.
I think the project visibility will increase significantly once he's part
of the oVirt infra eco-system.
>
> On 21 November 2016 at 19:07, Brian Proffitt <bproffit(a)redhat.com> wrote:
> > All:
> >
> > The moVirt Project was initially accepted as an oVirt incubator project
> in
> > February 2015. It has been a successful subproject for quite some time
> and
> > it is well due for being accepted as a full oVirt project. I believe it
> is
> > appropriate to post a Call for Vote on the Devel and Board lists.
> >
> > http://www.ovirt.org/develop/projects/project-movirt/
> >
> > A “healthy” project, as determined by the oVirt Board, can be found at
> > http://www.ovirt.org/develop/projects/adding-a-new-project/
> >
> > Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes
> > should be received to formalize this project as an full oVirt project.
> > 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
> > 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
>
>
>
> --
> Barak Korren
> bkorren(a)redhat.com
> RHEV-CI Team
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
7 years, 5 months
Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project
by Greg Sheremeta
+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
7 years, 5 months
[Call for Vote] moVirt as a Full oVirt Project
by Brian Proffitt
All:
The moVirt Project was initially accepted as an oVirt incubator project in
February 2015. It has been a successful subproject for quite some time and
it is well due for being accepted as a full oVirt project. I believe it is
appropriate to post a Call for Vote on the Devel and Board lists.
http://www.ovirt.org/develop/projects/project-movirt/
A “healthy” project, as determined by the oVirt Board, can be found at
http://www.ovirt.org/develop/projects/adding-a-new-project/
Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes
should be received to formalize this project as an full oVirt project.
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
Principal Community Analyst
Open Source and Standards
@TheTechScribe
574.383.9BKP
7 years, 5 months