Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Nir Soffer]

On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek  wrote:
>
>
>> On 21 Nov 2016, at 19:48, Vojtech Szocs  wrote:
>>
>>
>>
>> - Original Message -
>>> From: "Eyal Edri" 
>>> To: "Vojtech Szocs" 
>>> Cc: "Barak Korren" , "devel" , "board" 
>>> , "Michal Skrivanek"
>>> 
>>> 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  wrote:



 - Original Message -
> From: "Barak Korren" 
> To: "Brian Proffitt" 
> Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" <
 devel@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 :-)

+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

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?
>
> 3. Have artefacts served from oVirt's mirrors.
>
> What artifacts? The final APK? Why? It's not a yum repo.
>
> 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
>

 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 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Michal Skrivanek]

> On 21 Nov 2016, at 21:09, Eyal Edri  wrote:
> 
> 
> 
>> On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek  
>> wrote:
>> 
>> 
>> > On 21 Nov 2016, at 19:48, Vojtech Szocs  wrote:
>> >
>> >
>> >
>> > - Original Message -
>> >> From: "Eyal Edri" 
>> >> To: "Vojtech Szocs" 
>> >> Cc: "Barak Korren" , "devel" , 
>> >> "board" , "Michal Skrivanek"
>> >> 
>> >> 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  wrote:
>> >>>
>> >>>
>> >>>
>> >>> - Original Message -
>>  From: "Barak Korren" 
>>  To: "Brian Proffitt" 
>>  Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" <
>> >>> devel@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..

True. Though...I do appreciate the offer to look into it(I hope I didn't 
misunderstand:), but honestly there are more urgent things to resolve with lago 
stability...that is way more important at the moment IMHO

>  
>> 
>>  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. 

It is surely doable, but it doesn't give us much. The availability as a github 
release is good enough for development, and the "official" package is delivered 
through google play anyway

>  
>> 
>>  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 )

I'm not sure, I do think we will want to move off for more and more parts of 
ovirt. How to keep a unified approach is to be seen indeed, we certainly don't 
want to diverse too much

>  
>> 
>> >>>
>> >>> 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-devel] Fwd: New Defects reported by Coverity Scan for ovirt-engine

[Michal Skrivanek]

Not sure who touched that, but since it's a NPE - Tal, can you doublecheck 
please?


Begin forwarded message:

> From: scan-ad...@coverity.com
> Date: 21 November 2016 at 21:13:22 GMT+1
> To: mskri...@redhat.com
> Subject: New Defects reported by Coverity Scan for ovirt-engine
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to ovirt-engine 
> found with Coverity Scan.
> 
> 2 new defect(s) introduced to ovirt-engine found with Coverity Scan.
> 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
> recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
> 
> 
> ** CID 1366189:  Null pointer dereferences  (NULL_RETURNS)
> /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/GetDeviceListVDSCommand.java:
>  112 in 
> org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map,
>  org.ovirt.engine.core.compat.Version)()
> 
> 
> 
> *** CID 1366189:  Null pointer dereferences  (NULL_RETURNS)
> /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/GetDeviceListVDSCommand.java:
>  112 in 
> org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map,
>  org.ovirt.engine.core.compat.Version)()
> 106 
> .put(xcon.get(PHYSICAL_DEVICE_FIELD).toString(),
> 107 
> DEVICE_ACTIVE_VALUE.equals(xcon.get(DEVICE_STATE_FIELD).toString()));
> 108 }
> 109 if (xcon.containsKey(PHYSICAL_DEVICE_FIELD) && 
> xcon.containsKey(DEVICE_PATH_CAPACITY_FIELD)) {
> 110 // set name and capacity
> 111 Long size = 
> IrsBrokerCommand.assignLongValue(xcon, DEVICE_PATH_CAPACITY_FIELD);
CID 1366189:  Null pointer dereferences  (NULL_RETURNS)
Unboxing null object "size".
> 112 lun.getPathsCapacity()
> 113 
> .put(xcon.get(PHYSICAL_DEVICE_FIELD).toString(),
> 114 SizeConverter.convert(size,
> 115 
> SizeConverter.SizeUnit.BYTES, SizeConverter.SizeUnit.GiB).intValue());
> 116 }
> 117 }
> 
> ** CID 1366190:  Resource leaks  (RESOURCE_LEAK)
> /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/storage/CommandsWeightsUtilsTest.java:
>  37 in 
> org.ovirt.engine.core.bll.storage.CommandsWeightsUtilsTest.adjustWeights(java.util.List,
>  java.util.List, int)()
> 
> 
> 
> *** CID 1366190:  Resource leaks  (RESOURCE_LEAK)
> /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/storage/CommandsWeightsUtilsTest.java:
>  37 in 
> org.ovirt.engine.core.bll.storage.CommandsWeightsUtilsTest.adjustWeights(java.util.List,
>  java.util.List, int)()
> 31 adjustWeights(Arrays. asList(0.33, 0.37, 0.3), 
> Arrays. asList(3, 3, 4), 10);
> 32 }
> 33 
> 34 public void adjustWeights(List weightParts, List 
> expectedWeightsSorted, int totalWeight) {
> 35 assertFalse(weightsUtils == null);
> 36 Map map = new HashMap<>();
CID 1366190:  Resource leaks  (RESOURCE_LEAK)
Failing to save or close resource created by 
 "java.util.stream.IntStream.range(0, weightParts.size())" leaks it.
> 37 IntStream.range(0, weightParts.size()).forEach(i -> 
> map.put(String.valueOf(i), weightParts.get(i)));
> 38 Map res = weightsUtils.adjust(map, 
> totalWeight);
> 39 assertEquals("adjusted weights sum should be equal to the 
> total weight",
> 40 totalWeight,
> 41 res.values().stream().mapToInt(x -> x).sum());
> 42 
> 
> 
> 
> To view the defects in Coverity Scan visit, 
> https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRY9v3SZ-2BLqhn66fucWz5NChdV2QNZzLQCPY1fjqQGlAKjFKQ4pnDnQ8dtAwvCE2G0E-3D_xDvy9aTtFVlNgNTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3av2-2FBnTXIjnZdjb0Cw-2FiZV5z3DRotm2ow-2BiwdoVplKeuk7nRFrRXzS4jJb3IZXBSxeZC0bc8KPnuElHCtQryUJ5u-2FY6QjMUnZuFDu-2BC21coRtHfPr1uF9ZCvkTQAT-2Bg5drHSbNPaszp0YnZzvaUGArGUlXQkPt48dc-2FNZaixgGomwsPPQ-3D
> 
> To manage Coverity Scan email notifications for "mskri...@redhat.com", click 
> 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Eyal Edri]

On Mon, Nov 21, 2016 at 9:52 PM, Michal Skrivanek 
wrote:

>
>
> > On 21 Nov 2016, at 19:48, Vojtech Szocs  wrote:
> >
> >
> >
> > - Original Message -
> >> From: "Eyal Edri" 
> >> To: "Vojtech Szocs" 
> >> Cc: "Barak Korren" , "devel" ,
> "board" , "Michal Skrivanek"
> >> 
> >> 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 
> wrote:
> >>>
> >>>
> >>>
> >>> - Original Message -
>  From: "Barak Korren" 
>  To: "Brian Proffitt" 
>  Cc: "Michal Skrivanek" , bo...@ovirt.org,
> "devel" <
> >>> devel@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 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" 
> To: "Vojtech Szocs" 
> Cc: "Barak Korren" , "devel" , "board" 
> , "Michal Skrivanek"
> 
> 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  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Barak Korren" 
> > > To: "Brian Proffitt" 
> > > Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" <
> > devel@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.

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.

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.

> 
> 
> >
> > >
> > > On 21 November 2016 at 19:07, Brian Proffitt 
> > 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!

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Eyal Edri]

On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs  wrote:

>
>
> - Original Message -
> > From: "Barak Korren" 
> > To: "Brian Proffitt" 
> > Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" <
> devel@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 
> 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@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHEV-CI Team
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Ryan Barry]

+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  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" 
> > To: "Sandro Bonazzola" 
> > Cc: bo...@ovirt.org, "devel" 
> > 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 < sbona...@redhat.com >
> wrote:
> >
> >
> >
> >
> >
> >
> > Il 21/Nov/2016 17:55, "Brian Proffitt" < bprof...@redhat.com > ha
> scritto:
> > >
> > > All:
> > >
> > > This project was initially proposed for review on Oct. 9. It has been
> > > reviewed for major issues and having heard no objections, it's now
> time to
> > > formally vote on accepting this as an official oVirt incubator
> subproject.
> > >
> > > The last time we voted on one of these was during an IRC weekly
> meeting, so
> > > I believe it is appropriate to post a Call for Vote on the Devel and
> Board
> > > lists.
> > >
> > > Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5
> votes
> > > should be received to formalize this project as an incubator
> subproject.
> > > Please use the following vote process:
> > >
> > > +1
> > > Yes, agree, or the action should be performed. On some issues, this
> vote
> > > must only be given after the voter has tested the action on their own
> > > system(s).
> > >
> > > ±0
> > > Abstain, no opinion, or I am happy to let the other group members
> decide
> > > this issue. An abstention may have detrimental affects if too many
> people
> > > abstain.
> > >
> > > -1
> > > No, I veto this action. All vetos must include an explanation of why
> the
> > > veto is appropriate. A veto with no explanation is void.
> > >
> > > Thank you!
> > > Brian Proffitt
> > >
> > >
> > > ---
> > >
> > > Project Proposal - Vagrant Provider
> > >
> > > A vagrant provider for oVirt v4
> > >
> >
> >
> > My vote is +0. I have no strong opinion on this and I'm not using
> vagrant so
> > I would be happy to leave other to decide.
> > Using the + because I am happy to see the contribution ☺
> >
> >
> >
> >
> >
> > > Abstract
> > >
> > > This will be a provider plugin for the Vagrant suite that allows
> > > command-line ease of virtual machine provisioning and lifecycle
> > > management.
> > >
> > > Proposal
> > >
> > > This Vagrant provider plugin will interface with the oVirt REST API
> > > (version 4 and higher) using the oVirt provided ruby SDK
> > > 'ovirt-engine-sdk-ruby'. This allows users to abstract the user
> > > interface and experience into a set of command line abilities to
> > > create, provision, destroy and manage the complete lifecycle of
> > > virtual machines. It also allows the use of external configuration
> > > management and configuration files themselves to be committed into
> > > code.
> > >
> > > Background
> > >
> > > I have previously forked and maintained the 'vagrant-ovirt' gem as
> > > 'vagrant-ovirt3' due to Gems requiring unique names. The original
> > > author has officially abandoned the project. For the last few years
> > > all code to maintain this project has been maintained by myself and a
> > > few ad-hoc github contributors. This provider interfaced directly with
> > > oVirt v3 using fog and rbovirt. The new project would be a fresh start
> > > using the oVirt provided ruby SDK to work directly with version 4.
> > >
> > > Rationale
> > >
> > > The trend in configuration management, operations, and devops has been
> > > to maintain as much of the development process as possible in terms of
> > > the virtual machines and hosts that they run on. With software like
> > > Terraform the tasks of creating the underlying infrastructure such as
> > > network rules, etc have had great success moving into 'Infrastructure
> > > as code'. The same company behind Terraform got their reputation from
> > > Vagrant which aims to utilize the same process for virtual machines
> > > themselves. The core software allows for standard commands such as
> > > 'up', 'provision', 'destroy' to be used across a provider framework. A
> > > provider for oVirt makes the process for managing VMs easier and able
> > > to be controlled through code and source control.
> > >
> > > Initial Goals
> > >
> > > The initial goal is to get the base steps of 'up', 'down' (halt), and
> > > 'destroy' to succeed using the oVirt provided ruby SDK for v4.
> > > Stretch/followup goals would be to ensure testability and alternate
> > > commands such as 'provision' and allow configuration management suites
> > > like puppet to work via 'userdata' (cloud-init).
> > >
> > > 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" 
> To: "Brian Proffitt" 
> Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" 
> 
> 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).

Although, not sure how hard would it be to modify oVirt CI system to allow
building GitHub hosted projects.

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.

> 
> On 21 November 2016 at 19:07, Brian Proffitt  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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Eyal Edri]

On Mon, Nov 21, 2016 at 8:01 PM, Barak Korren  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  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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Barak Korren]

-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.

On 21 November 2016 at 19:07, Brian Proffitt  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel



-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Paul Dyer]

+1, I use it often.

On Mon, Nov 21, 2016 at 11:35 AM, Sphoorti Joglekar <
sphoorti.jogle...@gmail.com> wrote:

> +1
> The project has made tremendous progress.
> On Nov 21, 2016 12:21, "Martin Betak"  wrote:
>
>> +1 Albeit obviously biased :-), I think given the continuously growing
>> user base and stability, it is well deserved.
>>
>> - Original Message -
>> > From: "Brian Proffitt" 
>> > To: "devel" , bo...@ovirt.org
>> > Cc: "Michal Skrivanek" 
>> > Sent: Monday, November 21, 2016 6:07:11 PM
>> > Subject: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
>> >
>> > 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@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Paul Dyer,
Mercury Consulting Group, RHCE
504-302-8750
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Vojtech Szocs]

+1

I agree with Barak's point. Plus it would make people (who use Vagrant) aware 
of oVirt.

Vojtech


- Original Message -
> From: "Barak Korren" 
> To: "Sandro Bonazzola" 
> Cc: bo...@ovirt.org, "devel" 
> 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 < sbona...@redhat.com > wrote:
> 
> 
> 
> 
> 
> 
> Il 21/Nov/2016 17:55, "Brian Proffitt" < bprof...@redhat.com > ha scritto:
> > 
> > All:
> > 
> > This project was initially proposed for review on Oct. 9. It has been
> > reviewed for major issues and having heard no objections, it's now time to
> > formally vote on accepting this as an official oVirt incubator subproject.
> > 
> > The last time we voted on one of these was during an IRC weekly meeting, so
> > I believe it is appropriate to post a Call for Vote on the Devel and Board
> > lists.
> > 
> > Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes
> > should be received to formalize this project as an incubator subproject.
> > Please use the following vote process:
> > 
> > +1
> > Yes, agree, or the action should be performed. On some issues, this vote
> > must only be given after the voter has tested the action on their own
> > system(s).
> > 
> > ±0
> > Abstain, no opinion, or I am happy to let the other group members decide
> > this issue. An abstention may have detrimental affects if too many people
> > abstain.
> > 
> > -1
> > No, I veto this action. All vetos must include an explanation of why the
> > veto is appropriate. A veto with no explanation is void.
> > 
> > Thank you!
> > Brian Proffitt
> > 
> > 
> > ---
> > 
> > Project Proposal - Vagrant Provider
> > 
> > A vagrant provider for oVirt v4
> > 
> 
> 
> My vote is +0. I have no strong opinion on this and I'm not using vagrant so
> I would be happy to leave other to decide.
> Using the + because I am happy to see the contribution ☺
> 
> 
> 
> 
> 
> > Abstract
> > 
> > This will be a provider plugin for the Vagrant suite that allows
> > command-line ease of virtual machine provisioning and lifecycle
> > management.
> > 
> > Proposal
> > 
> > This Vagrant provider plugin will interface with the oVirt REST API
> > (version 4 and higher) using the oVirt provided ruby SDK
> > 'ovirt-engine-sdk-ruby'. This allows users to abstract the user
> > interface and experience into a set of command line abilities to
> > create, provision, destroy and manage the complete lifecycle of
> > virtual machines. It also allows the use of external configuration
> > management and configuration files themselves to be committed into
> > code.
> > 
> > Background
> > 
> > I have previously forked and maintained the 'vagrant-ovirt' gem as
> > 'vagrant-ovirt3' due to Gems requiring unique names. The original
> > author has officially abandoned the project. For the last few years
> > all code to maintain this project has been maintained by myself and a
> > few ad-hoc github contributors. This provider interfaced directly with
> > oVirt v3 using fog and rbovirt. The new project would be a fresh start
> > using the oVirt provided ruby SDK to work directly with version 4.
> > 
> > Rationale
> > 
> > The trend in configuration management, operations, and devops has been
> > to maintain as much of the development process as possible in terms of
> > the virtual machines and hosts that they run on. With software like
> > Terraform the tasks of creating the underlying infrastructure such as
> > network rules, etc have had great success moving into 'Infrastructure
> > as code'. The same company behind Terraform got their reputation from
> > Vagrant which aims to utilize the same process for virtual machines
> > themselves. The core software allows for standard commands such as
> > 'up', 'provision', 'destroy' to be used across a provider framework. A
> > provider for oVirt makes the process for managing VMs easier and able
> > to be controlled through code and source control.
> > 
> > Initial Goals
> > 
> > The initial goal is to get the base steps of 'up', 'down' (halt), and
> > 'destroy' to succeed using the oVirt provided ruby SDK for v4.
> > Stretch/followup goals would be to ensure testability and alternate
> > commands such as 'provision' and allow configuration management suites
> > like puppet to work via 'userdata' (cloud-init).
> > 
> > Current Status
> > 
> > The version 3 of this software has been heavily utilized. The original
> > fork known as 'vagrant-ovirt' has been abandoned with no plans to
> > communicate or move forward. My upstream fork has had great success
> > with nearly 4x the downloads from rubygems.org . Until my github fork
> > has more 'stars' I cannot take over it completely so the gem was
> > renamed 'vagrant-ovirt3'. This is also true for 

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Sphoorti Joglekar]

+1
The project has made tremendous progress.
On Nov 21, 2016 12:21, "Martin Betak"  wrote:

> +1 Albeit obviously biased :-), I think given the continuously growing
> user base and stability, it is well deserved.
>
> - Original Message -
> > From: "Brian Proffitt" 
> > To: "devel" , bo...@ovirt.org
> > Cc: "Michal Skrivanek" 
> > Sent: Monday, November 21, 2016 6:07:11 PM
> > Subject: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> >
> > 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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Oved Ourfali]

Big +1 on my end.

Thanks for the contribution!
Oved

On Nov 21, 2016 6:55 PM, "Brian Proffitt"  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Martin Betak]

+1 Albeit obviously biased :-), I think given the continuously growing user 
base and stability, it is well deserved.

- Original Message -
> From: "Brian Proffitt" 
> To: "devel" , bo...@ovirt.org
> Cc: "Michal Skrivanek" 
> Sent: Monday, November 21, 2016 6:07:11 PM
> Subject: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> 
> 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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Barak Korren]

+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  wrote:

> Il 21/Nov/2016 17:55, "Brian Proffitt"  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 

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

[Martin Perina]

+1

On Mon, Nov 21, 2016 at 5:55 PM, Brian Proffitt  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Martin Perina]

+1


On Mon, Nov 21, 2016 at 6:07 PM, Brian Proffitt  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Martin Sivak]

+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  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Martin Sivak]

+1

--
Martin Sivak
SLA / oVirt

On Mon, Nov 21, 2016 at 6:07 PM, Brian Proffitt  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Sandro Bonazzola]

Il 21/Nov/2016 17:55, "Brian Proffitt"  ha scritto:
>
> All:
>
> This project was initially proposed for review on Oct. 9. It has been
reviewed for major issues and having heard no objections, it's now time to
formally vote on accepting this as an official oVirt incubator subproject.
>
> The last time we voted on one of these was during an IRC weekly meeting,
so I believe it is appropriate to post a Call for Vote on the Devel and
Board lists.
>
> Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes
should be received to formalize this project as an incubator subproject.
Please use the following vote process:
>
> +1
> Yes, agree, or the action should be performed. On some issues, this vote
must only be given after the voter has tested the action on their own
system(s).
>
> ±0
> Abstain, no opinion, or I am happy to let the other group members decide
this issue. An abstention may have detrimental affects if too many people
abstain.
>
> -1
> No, I veto this action. All vetos must include an explanation of why the
veto is appropriate. A veto with no explanation is void.
>
> Thank you!
> Brian Proffitt
>
>
> ---
>
> Project Proposal - Vagrant Provider
>
> A vagrant provider for oVirt v4
>

My vote is +0. I have no strong opinion on this and I'm not using vagrant
so I  would be happy to leave other to decide.
Using the + because I am happy to see the contribution ☺


> Abstract
>
> This will be a provider plugin for the Vagrant suite that allows
> command-line ease of virtual machine provisioning and lifecycle
> management.
>
> Proposal
>
> This Vagrant provider plugin will interface with the oVirt REST API
> (version 4 and higher) using the oVirt provided ruby SDK
> 'ovirt-engine-sdk-ruby'. This allows users to abstract the user
> interface and experience into a set of command line abilities to
> create, provision, destroy and manage the complete lifecycle of
> virtual machines. It also allows the use of external configuration
> management and configuration files themselves to be committed into
> code.
>
> Background
>
> I have previously forked and maintained the 'vagrant-ovirt' gem as
> 'vagrant-ovirt3' due to Gems requiring unique names. The original
> author has officially abandoned the project. For the last few years
> all code to maintain this project has been maintained by myself and a
> few ad-hoc github contributors. This provider interfaced directly with
> oVirt v3 using fog and rbovirt. The new project would be a fresh start
> using the oVirt provided ruby SDK to work directly with version 4.
>
> Rationale
>
> The trend in configuration management, operations, and devops has been
> to maintain as much of the development process as possible in terms of
> the virtual machines and hosts that they run on. With software like
> Terraform the tasks of creating the underlying infrastructure such as
> network rules, etc have had great success moving into 'Infrastructure
> as code'. The same company behind Terraform got their reputation from
> Vagrant which aims to utilize the same process for virtual machines
> themselves. The core software allows for standard commands such as
> 'up', 'provision', 'destroy' to be used across a provider framework. A
> provider for oVirt makes the process for managing VMs easier and able
> to be controlled through code and source control.
>
> Initial Goals
>
> The initial goal is to get the base steps of 'up', 'down' (halt), and
> 'destroy' to succeed using the oVirt provided ruby SDK for v4.
> Stretch/followup goals would be to ensure testability and alternate
> commands such as 'provision' and allow configuration management suites
> like puppet to work via 'userdata' (cloud-init).
>
> Current Status
>
> The version 3 of this software has been heavily utilized. The original
> fork known as 'vagrant-ovirt' has been abandoned with no plans to
> communicate or move forward. My upstream fork has had great success
> with nearly 4x the downloads from rubygems.org . Until my github fork
> has more 'stars' I cannot take over it completely so the gem was
> renamed 'vagrant-ovirt3'. This is also true for rubygems.org since
> gems are not namespaced, therefore could not be published without a
> unique name. The v4 provider is still pending my initial POC commit
> but there are no current barriers except initial oVirt hosting. The
> hosting of oVirt v3 for testing is a laptop on a UPS at my home, and
> v4 is also a different pc attached to a UPS.
>
> External Dependencies
>
> RHEVM/oVirt REST API - This provider must interact with the API itself
> to manage virtual machines.
>
> Initial Committers
>
> Marcus Young ( 3vilpenguin at gmail dot com )
>
> --
> Brian Proffitt
> Principal Community Analyst
> Open Source and Standards
> @TheTechScribe
> 574.383.9BKP
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___

[ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.0.6 RC2 build planned

[Sandro Bonazzola]

On Mon, Nov 21, 2016 at 3:37 PM, Sandro Bonazzola 
wrote:

> Fyi oVirt developers,
>
> An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CET).
>

Sorry, planned for this Wednesday, same time.



> Taking into consideration the time it takes for Jenkins to run a full CI
> everything need to be backported by Monday 11PM.
> Please make sure to mark as verified and CR +2 so it will be ready for
> merging Tuesday morning.
>
> A list of pending blockers is available here:
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=
> target_milestone%3A4.0.6%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 4.0.6 RC2 build planned

[Sandro Bonazzola]

Fyi oVirt developers,

An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CET).
Taking into consideration the time it takes for Jenkins to run a full CI
everything need to be backported by Monday 11PM.
Please make sure to mark as verified and CR +2 so it will be ready for
merging Tuesday morning.

A list of pending blockers is available here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.6%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 4.0.6 RC2 merge / branch / tag / bugzilla reminder

[Sandro Bonazzola]

All stable branch maintainers, please make sure to
merge all relevant open bugs until Wednesday morning 10:00 AM TLV time
(9:00 AM CET).

For each package that need to be built (i.e oVirt product) please make sure
every bug in MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building
and should include the same version you used for the tag you just used for
this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.6, tr: 4.0.6)
A list of bugs that require attention is here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.6%20target_release%3A---%20status%3Amodified%2Cpost

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Martin Sivak]

Well it is only partially off topic, because it is impossible to merge
a db script close to release. A file rename means new CI job and that
can take ages (especially for the engine and the multiple branches we
have). The same what Martin is describing for the engine with FF only
setup.

Gating does not necessarily have to mean blocking only, it can contain
an ordering component too.

Martin



On Mon, Nov 21, 2016 at 3:04 PM, Barak Korren  wrote:
> On 21 November 2016 at 13:51, Martin Sivak  wrote:
>> Will it also auto-rename the database scripts? Please please!
>>
> Well, automated systems are not supposed to make code changes without
> humans being aware (see other thread about "ff-only" where "rebase if
> necessary" is a counter-example).
>
> What we could do is have the gate fail when colliding scripts show up
> (we will also have to use "ff-only" then to ensure changes are
> ordered). Actually this test is simple enough for "regular" CI to do,
> so no need to wait for the gate...
>
> Anyway, this is not directly related to merge-gating, so a little off-topic 
> IMO.
>
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Barak Korren]

On 21 November 2016 at 13:51, Martin Sivak  wrote:
> Will it also auto-rename the database scripts? Please please!
>
Well, automated systems are not supposed to make code changes without
humans being aware (see other thread about "ff-only" where "rebase if
necessary" is a counter-example).

What we could do is have the gate fail when colliding scripts show up
(we will also have to use "ff-only" then to ensure changes are
ordered). Actually this test is simple enough for "regular" CI to do,
so no need to wait for the gate...

Anyway, this is not directly related to merge-gating, so a little off-topic IMO.

-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

[Barak Korren]

>
> I enjoyed the freedom of cherry-pick, but after 2 broken nightly builds
> in the span of 10 days, I give up. Let's try ff-only.
>
All right, changed.


-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Eyal Edri]

Off topic I think..,  but wasn't there a Gerrit plugin Roy wrote for it?

On Nov 21, 2016 13:51, "Martin Sivak"  wrote:

> Will it also auto-rename the database scripts? Please please!
>
> Martin
>
> On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri  wrote:
> > This isn't gating.
> > Just trigger to run more heavy lifting CI jobs,  the idea is to replace
> the
> > manual submit with automatic system like Zuul.
> >
> >
> > On Nov 21, 2016 1:32 PM, "Tal Nisan"  wrote:
> >>
> >> Why not use +1 on verified? That way the patch owner can wait till the
> >> code review process is over, mark it as verified, wait for CI and then
> >> submit.
> >> It doesn't really give much added value to the code reviewers whether
> it's
> >> marked as verified or not
> >>
> >> On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola  >
> >> wrote:
> >>>
> >>> Il 20/Nov/2016 17:25, "Nir Soffer"  ha scritto:
> >>> >
> >>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David  >
> >>> > wrote:
> >>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren 
> >>> > > wrote:
> >>> > >> Hi all,
> >>> > >>
> >>> > >> Perhaps the main purpose of CI, is to prevent braking code from
> >>> > >> getting merged into the stable/master branches. Unfortunately our
> CI
> >>> > >> is not there yet, and one of the reasons for that is that we do
> >>> > >> large
> >>> > >> amount of our CI tests only _after_ the code is merged.
> >>> > >>
> >>> > >> The reason for that is that when balancing through, but time
> >>> > >> consuming, tests (e.g. enging build with all permutations) v.s.
> >>> > >> faster
> >>> > >> but more basic ones (e.g. "findbugs" and single permutation
> build),
> >>> > >> we
> >>> > >> typically choose the faster tests to be run per-patch-set and
> leave
> >>> > >> the through testing to only be run post-merge.
> >>> > >>
> >>> > >> We'd like to change that and have the through tests also run
> before
> >>> > >> merge. Ideally we would like to just hook stuff to the "submit"
> >>> > >> button, but Gerrit doesn't allow one to do that easily. So instead
> >>> > >> we'll need to adopt some kind of flag to indicate we want to
> submit
> >>> > >> and have Jenkins
> >>> > >> "click" the submit button on our behalf if tests pass.
> >>> > >>
> >>> > >> I see two options here:
> >>> > >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.
> >>> >
> >>> > This is problematic. For example in vdsm we have 5 maintainers with
> >>> > +2, and 4 maintainers with commit right, but only 2 are commenting
> >>> > regularly.
> >>> >
> >>> > >> 2. Add an "approve" flag that maintainers can set to +1 (This is
> >>> > >>what OpenStack is doing).
> >>> >
> >>> > This seems better.
> >>> >
> >>> > But there is another requirement - maintainer should be able to
> commit
> >>> > even if jenkins fails. Sometimes the CI is broken, or there are
> flakey
> >>> > tests
> >>> > breaking the build, and some jobs are failing regularly
> (check-merged)
> >>> > and I don't want to wait for it.
> >>>
> >>> Either disable the jobs or fix them. Having jobs consitently failing
> and
> >>> just ignore them is just a waste of resources.
> >>>
> >>> >
> >>> > Today we can override the CI vote and commit, if we keep it as is I
> >>> > don't
> >>> > see any problem with this change.
> >>> >
> >>> > Nir
> >>> > ___
> >>> > Devel mailing list
> >>> > Devel@ovirt.org
> >>> > http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
> >>
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Martin Sivak]

Will it also auto-rename the database scripts? Please please!

Martin

On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri  wrote:
> This isn't gating.
> Just trigger to run more heavy lifting CI jobs,  the idea is to replace the
> manual submit with automatic system like Zuul.
>
>
> On Nov 21, 2016 1:32 PM, "Tal Nisan"  wrote:
>>
>> Why not use +1 on verified? That way the patch owner can wait till the
>> code review process is over, mark it as verified, wait for CI and then
>> submit.
>> It doesn't really give much added value to the code reviewers whether it's
>> marked as verified or not
>>
>> On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola 
>> wrote:
>>>
>>> Il 20/Nov/2016 17:25, "Nir Soffer"  ha scritto:
>>> >
>>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David 
>>> > wrote:
>>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren 
>>> > > wrote:
>>> > >> Hi all,
>>> > >>
>>> > >> Perhaps the main purpose of CI, is to prevent braking code from
>>> > >> getting merged into the stable/master branches. Unfortunately our CI
>>> > >> is not there yet, and one of the reasons for that is that we do
>>> > >> large
>>> > >> amount of our CI tests only _after_ the code is merged.
>>> > >>
>>> > >> The reason for that is that when balancing through, but time
>>> > >> consuming, tests (e.g. enging build with all permutations) v.s.
>>> > >> faster
>>> > >> but more basic ones (e.g. "findbugs" and single permutation build),
>>> > >> we
>>> > >> typically choose the faster tests to be run per-patch-set and leave
>>> > >> the through testing to only be run post-merge.
>>> > >>
>>> > >> We'd like to change that and have the through tests also run before
>>> > >> merge. Ideally we would like to just hook stuff to the "submit"
>>> > >> button, but Gerrit doesn't allow one to do that easily. So instead
>>> > >> we'll need to adopt some kind of flag to indicate we want to submit
>>> > >> and have Jenkins
>>> > >> "click" the submit button on our behalf if tests pass.
>>> > >>
>>> > >> I see two options here:
>>> > >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.
>>> >
>>> > This is problematic. For example in vdsm we have 5 maintainers with
>>> > +2, and 4 maintainers with commit right, but only 2 are commenting
>>> > regularly.
>>> >
>>> > >> 2. Add an "approve" flag that maintainers can set to +1 (This is
>>> > >>what OpenStack is doing).
>>> >
>>> > This seems better.
>>> >
>>> > But there is another requirement - maintainer should be able to commit
>>> > even if jenkins fails. Sometimes the CI is broken, or there are flakey
>>> > tests
>>> > breaking the build, and some jobs are failing regularly (check-merged)
>>> > and I don't want to wait for it.
>>>
>>> Either disable the jobs or fix them. Having jobs consitently failing and
>>> just ignore them is just a waste of resources.
>>>
>>> >
>>> > Today we can override the CI vote and commit, if we keep it as is I
>>> > don't
>>> > see any problem with this change.
>>> >
>>> > Nir
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Eyal Edri]

This isn't gating.
Just trigger to run more heavy lifting CI jobs,  the idea is to replace the
manual submit with automatic system like Zuul.

On Nov 21, 2016 1:32 PM, "Tal Nisan"  wrote:

> Why not use +1 on verified? That way the patch owner can wait till the
> code review process is over, mark it as verified, wait for CI and then
> submit.
> It doesn't really give much added value to the code reviewers whether it's
> marked as verified or not
>
> On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola 
> wrote:
>
>> Il 20/Nov/2016 17:25, "Nir Soffer"  ha scritto:
>> >
>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David 
>> wrote:
>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren 
>> wrote:
>> > >> Hi all,
>> > >>
>> > >> Perhaps the main purpose of CI, is to prevent braking code from
>> > >> getting merged into the stable/master branches. Unfortunately our CI
>> > >> is not there yet, and one of the reasons for that is that we do large
>> > >> amount of our CI tests only _after_ the code is merged.
>> > >>
>> > >> The reason for that is that when balancing through, but time
>> > >> consuming, tests (e.g. enging build with all permutations) v.s.
>> faster
>> > >> but more basic ones (e.g. "findbugs" and single permutation build),
>> we
>> > >> typically choose the faster tests to be run per-patch-set and leave
>> > >> the through testing to only be run post-merge.
>> > >>
>> > >> We'd like to change that and have the through tests also run before
>> > >> merge. Ideally we would like to just hook stuff to the "submit"
>> > >> button, but Gerrit doesn't allow one to do that easily. So instead
>> > >> we'll need to adopt some kind of flag to indicate we want to submit
>> > >> and have Jenkins
>> > >> "click" the submit button on our behalf if tests pass.
>> > >>
>> > >> I see two options here:
>> > >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.
>> >
>> > This is problematic. For example in vdsm we have 5 maintainers with
>> > +2, and 4 maintainers with commit right, but only 2 are commenting
>> > regularly.
>> >
>> > >> 2. Add an "approve" flag that maintainers can set to +1 (This is
>> > >>what OpenStack is doing).
>> >
>> > This seems better.
>> >
>> > But there is another requirement - maintainer should be able to commit
>> > even if jenkins fails. Sometimes the CI is broken, or there are flakey
>> tests
>> > breaking the build, and some jobs are failing regularly (check-merged)
>> > and I don't want to wait for it.
>>
>> Either disable the jobs or fix them. Having jobs consitently failing and
>> just ignore them is just a waste of resources.
>>
>> >
>> > Today we can override the CI vote and commit, if we keep it as is I
>> don't
>> > see any problem with this change.
>> >
>> > Nir
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Merge gating in Gerrit

[Tal Nisan]

Why not use +1 on verified? That way the patch owner can wait till the code
review process is over, mark it as verified, wait for CI and then submit.
It doesn't really give much added value to the code reviewers whether it's
marked as verified or not

On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola 
wrote:

> Il 20/Nov/2016 17:25, "Nir Soffer"  ha scritto:
> >
> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David 
> wrote:
> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren 
> wrote:
> > >> Hi all,
> > >>
> > >> Perhaps the main purpose of CI, is to prevent braking code from
> > >> getting merged into the stable/master branches. Unfortunately our CI
> > >> is not there yet, and one of the reasons for that is that we do large
> > >> amount of our CI tests only _after_ the code is merged.
> > >>
> > >> The reason for that is that when balancing through, but time
> > >> consuming, tests (e.g. enging build with all permutations) v.s. faster
> > >> but more basic ones (e.g. "findbugs" and single permutation build), we
> > >> typically choose the faster tests to be run per-patch-set and leave
> > >> the through testing to only be run post-merge.
> > >>
> > >> We'd like to change that and have the through tests also run before
> > >> merge. Ideally we would like to just hook stuff to the "submit"
> > >> button, but Gerrit doesn't allow one to do that easily. So instead
> > >> we'll need to adopt some kind of flag to indicate we want to submit
> > >> and have Jenkins
> > >> "click" the submit button on our behalf if tests pass.
> > >>
> > >> I see two options here:
> > >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.
> >
> > This is problematic. For example in vdsm we have 5 maintainers with
> > +2, and 4 maintainers with commit right, but only 2 are commenting
> > regularly.
> >
> > >> 2. Add an "approve" flag that maintainers can set to +1 (This is
> > >>what OpenStack is doing).
> >
> > This seems better.
> >
> > But there is another requirement - maintainer should be able to commit
> > even if jenkins fails. Sometimes the CI is broken, or there are flakey
> tests
> > breaking the build, and some jobs are failing regularly (check-merged)
> > and I don't want to wait for it.
>
> Either disable the jobs or fix them. Having jobs consitently failing and
> just ignore them is just a waste of resources.
>
> >
> > Today we can override the CI vote and commit, if we keep it as is I don't
> > see any problem with this change.
> >
> > Nir
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] blockcommit and gluster network disk path

[Sahina Bose]

Hi,

I'm running into problems with blockcommit and gluster network disks -
wanted to check how to pass path for network disks. How's the protocol and
host parameters specified?

For a backing volume chain as below, executing
virsh blockcommit fioo5
vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c
--base
vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/d4c23ec6-20ce-4a2f-9b32-ca91e65a114a
--top
vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c
--verbose --wait

gives "error: invalid argument: No device found for specified path".





















27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4







thanks
sahina
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel