Re: [ovirt-devel] PHX planned maintenance 29.01.2018 @19:00 GMT

2018-01-29 Thread Evgheni Dereveanchin
Maintenance is complete with minimal downtime. CI is resumed and all
services should be reachable.
If any jobs failed to get queued for you - feel free to re-trigger. For
other issues please log a Jira ticket.

Regards,
Evgheni

On Mon, Jan 29, 2018 at 2:13 PM, Evgheni Dereveanchin 
wrote:

> Hi everyone,
>
> Planned works are going to be performed in the PHX data center today. They
> are related to core networking hardware upgrades and may cause short
> connectivity loss to services hosted by the oVirt project, including:
>
> * Jenkins CI
> * Package repositories
> * project website
> * mailing lists
>
> The maintenance window starts at 19:00 GMT and has a duration of one hour.
>
> I will pause CI job execution before the maintenance window so builds will
> be queued and executed after network upgrades are implemented to decrease
> the possibility of false positives. I will follow up with any further
> updates.
>
> --
> Regards,
> Evgheni Dereveanchin
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] PHX planned maintenance 29.01.2018 @19:00 GMT

2018-01-29 Thread Evgheni Dereveanchin
Hi everyone,

Planned works are going to be performed in the PHX data center today. They
are related to core networking hardware upgrades and may cause short
connectivity loss to services hosted by the oVirt project, including:

* Jenkins CI
* Package repositories
* project website
* mailing lists

The maintenance window starts at 19:00 GMT and has a duration of one hour.

I will pause CI job execution before the maintenance window so builds will
be queued and executed after network upgrades are implemented to decrease
the possibility of false positives. I will follow up with any further
updates.

-- 
Regards,
Evgheni Dereveanchin
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Error while setting up disk in ovirt-engine.

2018-01-29 Thread Yaniv Kaul
On Jan 29, 2018 12:21 PM, "Avinash Dasoundhi"  wrote:

Hello Everyone

I have set up ovirt-engine for testing purpose and, I am using
ovirt-vdsmfake[1] to provision host and vms on that ovirt-engine. But I am
facing an error while creating a disk.


Depending on your use case, you might want to check ovirt-system-tests
instead.
Y.


I have provision 10 hosts, all are up with their own local storage. And
when I am trying to add a disk to the disk section, error popups like "*Error
while executing action Add Disk to VM: General Exception*". I saw the logs,
thought of some permission error, checked that but still this error is
coming.

Can somebody provide some details on it?

I am attaching the engine.log with this mail.

Thank You


-- 

AVINASH DASOUNDHI

ASSOCIATE SOFTWARE ENGINEER IN ENG PERF R, RHCSA

Red Hat BLR 

IRC - tenstormavi

adaso...@redhat.comM: +91-8653245552


___
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] [CQ]: 86865, 8 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause

2018-01-29 Thread Yedidyah Bar David
On Mon, Jan 29, 2018 at 1:47 PM, oVirt Jenkins  wrote:
> A system test invoked by the "ovirt-master" change queue including change
> 86865,8 (otopi) failed. However, this change seems not to be the root cause 
> for
> this failure. Change 86679,4 (otopi) that this change depends on or is based
> on, was detected as the cause of the testing failures.
>
> This change had been removed from the testing queue. Artifacts built from this
> change will not be released until either change 86679,4 (otopi) is fixed and
> this change is updated to refer to or rebased on the fixed version, or this
> change is modified to no longer depend on it.
>
> For further details about the change see:
> https://gerrit.ovirt.org/#/c/86865/8
>
> For further details about the change that seems to be the root cause behind 
> the
> testing failures see:
> https://gerrit.ovirt.org/#/c/86679/4

That's indeed the reason for the failure.

This patch adds to otopi a check for before=/after= parameters for
event methods.

It causes CI to fail due to bad ones in engine-setup, should be fixed by:

https://gerrit.ovirt.org/86858

>
> For failed test results see:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5149/
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



-- 
Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


[ovirt-devel] What does SDM.merge's param "base_generation" in subchain_info means?

2018-01-29 Thread pengyixiang
hello, everyone!
 When we call "SDM.merge", we need a param "base_generation" in [1], and I 
know [2] will be called and "base_generation" is translated to "requested_gen", 
that means "GEN" in disk metadata?
If so, how did this "GEN" worked and seted? I see many *.meta is "GEN=0", and 
some is "GEN=1" in [3]. 




Hope to get your reply, Thank you!




[1]  {'subchain_info': {'img_id': '91837525-850d-4e74-9a7e-c89b793d0e5b', 
'sd_id': '93b8a2c9-f527-4eb3-acfb-af76ab24fbbe', 'top_id': 
'4e51d4e5-9630-45a6-9829-012460e7d67a', 'base_id': 
'fdf47584-21aa-45b2-9925-157ff54f5e7e', 'base_generation': 0}, 'job_id': 
'766a3050-476c-48ae-9470-3bec7867a6cd'}


[2]  
https://github.com/oVirt/vdsm/blob/07d05287ac1496ad49915e026d34e29ca4da635b/lib/vdsm/storage/volume.py#L602


[3] 
DOMAIN=93b8a2c9-f527-4eb3-acfb-af76ab24fbbe CTIME=1516090454 FORMAT=COW 
DISKTYPE=2 LEGALITY=LEGAL SIZE=167772160 VOLTYPE=INTERNAL DESCRIPTION= 
IMAGE=f882e7cc-f57e-48ff-9b87-bba35331e983 
PUUID=9050f956-6836-4fce-8d27-69df13c4f85c MTIME=0 POOL_UUID= TYPE=SPARSE GEN=1 
EOF___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Error while setting up disk in ovirt-engine.

2018-01-29 Thread Greg Sheremeta
vdsmfake can be picky :) are you running the docker container? Can you
attach the vdsmfake logs?

When using vdsmfake, I usually add an NFS storage, and just set the path to
"tmp:/tmp", name it something, and click OK. When I've tried to do more
than that, I've seen similar errors. In other words, when using vdsmfake, I
"tread lightly" because it just doesn't support everything.

I don't believe we have an official vdsmfake maintainer -- perhaps Roy by
default, so cc'ing him.

Greg

On Mon, Jan 29, 2018 at 4:27 AM, Avinash Dasoundhi 
wrote:

> Hello Everyone
>
> I have set up ovirt-engine for testing purpose and, I am using
> ovirt-vdsmfake[1] to provision host and vms on that ovirt-engine. But I am
> facing an error while creating a disk.
>
> I have provision 10 hosts, all are up with their own local storage. And
> when I am trying to add a disk to the disk section, error popups like "*Error
> while executing action Add Disk to VM: General Exception*". I saw the
> logs, thought of some permission error, checked that but still this error
> is coming.
>
> Can somebody provide some details on it?
>
> I am attaching the engine.log with this mail.
>
> Thank You
>
>
> --
>
> AVINASH DASOUNDHI
>
> ASSOCIATE SOFTWARE ENGINEER IN ENG PERF R, RHCSA
>
> Red Hat BLR 
>
> IRC - tenstormavi
>
> adaso...@redhat.comM: +91-8653245552
> 
>
> ___
> 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] what does the vm.merge do in vdsm?

2018-01-29 Thread Dan Kenigsberg
On Thu, Jan 25, 2018 at 5:42 PM, Pen  wrote:
> hi
>   what means in vdsm api merge's param "drive.volumeID" in [1]?If I want
> delete "snapshot1" in snapshot chain [3],
> "drive.volumeID" means "snapshot2" or  "active_img"? I have seen about
> document in [2], then I have a question,
> If we want delete "snapshot1" in [4], and "snapshot1" is "snapshot2"'s
> srcVolume and "snapshot3"'s srcVolume at the
> same time, what should I do? merge twice?
>
>
>
>
> [1]
>
> @api.method
> def merge(self, drive, baseVolUUID, topVolUUID, bandwidth=0, jobUUID=None):
> return self.vm.merge(
> drive, baseVolUUID, topVolUUID, bandwidth, jobUUID)
>
>
> [2]
> https://www.ovirt.org/develop/release-management/features/storage/live-merge/
>
> [3]
> backing_img --- snapshot1 --- snapshot2 --- active_img
>
> [4]
> backing_img --- snapshot1 --- snapshot2 --- active_img
>  |
>  |
>  - snapshot3


Hi Pen,

It seems that you email has stalled for a couple of days on qq.com. I
believed that I've replied to the query you've sent from another
mailbox, under the subject line
   [ovirt-devel] How did vm.merge do when we delete a snapshot that
pointed by several other's snapshot's srcVol (as several other
snapshot's backing)

bottom line: you cannot create a topology like [4] in vdsm storage.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] what does the vm.merge do in vdsm?

2018-01-29 Thread Pen
hi
  what means in vdsm api merge's param "drive.volumeID" in [1]??If I want 
delete "snapshot1" in snapshot chain [3], 
"drive.volumeID" means "snapshot2" or  "active_img"? I have seen about document 
in [2], then I have a question, 
If we want delete "snapshot1" in [4], and "snapshot1" is "snapshot2"'s 
srcVolume and "snapshot3"'s srcVolume at the 
same time, what should I do? merge twice?




[1] 
@api.method
def merge(self, drive, baseVolUUID, topVolUUID, bandwidth=0, jobUUID=None):
return self.vm.merge(
drive, baseVolUUID, topVolUUID, bandwidth, jobUUID)


[2] 
https://www.ovirt.org/develop/release-management/features/storage/live-merge/

[3] 
backing_img --- snapshot1 --- snapshot2 --- active_img

[4]
backing_img --- snapshot1 --- snapshot2 --- active_img
 |
 |
 - snapshot3___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Martin Perina
On Mon, Jan 29, 2018 at 11:14 AM, Sandro Bonazzola 
wrote:

>
>
> 2018-01-29 11:01 GMT+01:00 Tal Nisan :
>
>> For alignment purposes between the projects we should consider branch
>> ovirt-engine as well.
>> At this point in time I'm for it, would like to hear any acks/nacks so we
>> can decide how we proceeed
>>
>>
> Nothing against branching, ack on my side
>

​+1 from me

Eli, could you please start preparing patch which will bump master to 4.3
(db, dc/cluster level ...)?​



>
>
>>
>> On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg 
>> wrote:
>>
>>> On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani 
>>> wrote:
>>> > Hi all,
>>> >
>>> >
>>> > It is time again to reconsider branching out the 4.2 stable branch.
>>> >
>>> > So far we decided to *not* branch out, and we are taking tags for ovirt
>>> > 4.2 releases from master branch.
>>> >
>>> > This means we are merging safe and/or stabilization patches only in
>>> master.
>>> >
>>> >
>>> > I think it is time to reconsider this decision and branch out for 4.2,
>>> > because of two reasons:
>>> >
>>> > 1. it sends a clearer signal that 4.2 is going in stabilization mode
>>> >
>>> > 2. we have requests from virt team, which wants to start working on the
>>> > next cycle features.
>>> >
>>> >
>>> > If we decide to branch out, I'd start the new branch on monday,
>>> February
>>> > 5 (1 week from now).
>>> >
>>> >
>>> > The discussion is open, please share your acks/nacks for branching out,
>>> > and for the branching date.
>>> >
>>> >
>>> > I for myself I'm inclined to branch out, so if noone chimes in (!!)
>>> I'll
>>> > execute the above plan.
>>>
>>> For network we don't see a lot of pending 4.2 work - except for the
>>> requirement to support el7.5. On the other hand, we too have already a
>>> patch for 4.3. Thus I'm fine with branching next week.
>>>
>>> When you do branch, please make sure to follow Barak Korren's request on
>>> the
>>> [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2
>>> thread.
>>> ___
>>> 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
>>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Tomas Jelinek
On Mon, Jan 29, 2018 at 11:01 AM, Tal Nisan  wrote:

> For alignment purposes between the projects we should consider branch
> ovirt-engine as well.
> At this point in time I'm for it, would like to hear any acks/nacks so we
> can decide how we proceeed
>

+1 from me


>
>
> On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg  wrote:
>
>> On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani 
>> wrote:
>> > Hi all,
>> >
>> >
>> > It is time again to reconsider branching out the 4.2 stable branch.
>> >
>> > So far we decided to *not* branch out, and we are taking tags for ovirt
>> > 4.2 releases from master branch.
>> >
>> > This means we are merging safe and/or stabilization patches only in
>> master.
>> >
>> >
>> > I think it is time to reconsider this decision and branch out for 4.2,
>> > because of two reasons:
>> >
>> > 1. it sends a clearer signal that 4.2 is going in stabilization mode
>> >
>> > 2. we have requests from virt team, which wants to start working on the
>> > next cycle features.
>> >
>> >
>> > If we decide to branch out, I'd start the new branch on monday, February
>> > 5 (1 week from now).
>> >
>> >
>> > The discussion is open, please share your acks/nacks for branching out,
>> > and for the branching date.
>> >
>> >
>> > I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll
>> > execute the above plan.
>>
>> For network we don't see a lot of pending 4.2 work - except for the
>> requirement to support el7.5. On the other hand, we too have already a
>> patch for 4.3. Thus I'm fine with branching next week.
>>
>> When you do branch, please make sure to follow Barak Korren's request on
>> the
>> [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2
>> thread.
>> ___
>> 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] [RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Barak Korren
Please add the 4.2 jobs in YAML _before_ you branch.
There is no harm in that, and it will ensure you get CI working as soon as
you branch.

Other then that ACK from me.

On 29 January 2018 at 12:14, Sandro Bonazzola  wrote:

>
>
> 2018-01-29 11:01 GMT+01:00 Tal Nisan :
>
>> For alignment purposes between the projects we should consider branch
>> ovirt-engine as well.
>> At this point in time I'm for it, would like to hear any acks/nacks so we
>> can decide how we proceeed
>>
>>
> Nothing against branching, ack on my side
>
>
>
>>
>> On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg 
>> wrote:
>>
>>> On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani 
>>> wrote:
>>> > Hi all,
>>> >
>>> >
>>> > It is time again to reconsider branching out the 4.2 stable branch.
>>> >
>>> > So far we decided to *not* branch out, and we are taking tags for ovirt
>>> > 4.2 releases from master branch.
>>> >
>>> > This means we are merging safe and/or stabilization patches only in
>>> master.
>>> >
>>> >
>>> > I think it is time to reconsider this decision and branch out for 4.2,
>>> > because of two reasons:
>>> >
>>> > 1. it sends a clearer signal that 4.2 is going in stabilization mode
>>> >
>>> > 2. we have requests from virt team, which wants to start working on the
>>> > next cycle features.
>>> >
>>> >
>>> > If we decide to branch out, I'd start the new branch on monday,
>>> February
>>> > 5 (1 week from now).
>>> >
>>> >
>>> > The discussion is open, please share your acks/nacks for branching out,
>>> > and for the branching date.
>>> >
>>> >
>>> > I for myself I'm inclined to branch out, so if noone chimes in (!!)
>>> I'll
>>> > execute the above plan.
>>>
>>> For network we don't see a lot of pending 4.2 work - except for the
>>> requirement to support el7.5. On the other hand, we too have already a
>>> patch for 4.3. Thus I'm fine with branching next week.
>>>
>>> When you do branch, please make sure to follow Barak Korren's request on
>>> the
>>> [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2
>>> thread.
>>> ___
>>> 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
>>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Sandro Bonazzola
2018-01-29 11:01 GMT+01:00 Tal Nisan :

> For alignment purposes between the projects we should consider branch
> ovirt-engine as well.
> At this point in time I'm for it, would like to hear any acks/nacks so we
> can decide how we proceeed
>
>
Nothing against branching, ack on my side



>
> On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg  wrote:
>
>> On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani 
>> wrote:
>> > Hi all,
>> >
>> >
>> > It is time again to reconsider branching out the 4.2 stable branch.
>> >
>> > So far we decided to *not* branch out, and we are taking tags for ovirt
>> > 4.2 releases from master branch.
>> >
>> > This means we are merging safe and/or stabilization patches only in
>> master.
>> >
>> >
>> > I think it is time to reconsider this decision and branch out for 4.2,
>> > because of two reasons:
>> >
>> > 1. it sends a clearer signal that 4.2 is going in stabilization mode
>> >
>> > 2. we have requests from virt team, which wants to start working on the
>> > next cycle features.
>> >
>> >
>> > If we decide to branch out, I'd start the new branch on monday, February
>> > 5 (1 week from now).
>> >
>> >
>> > The discussion is open, please share your acks/nacks for branching out,
>> > and for the branching date.
>> >
>> >
>> > I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll
>> > execute the above plan.
>>
>> For network we don't see a lot of pending 4.2 work - except for the
>> requirement to support el7.5. On the other hand, we too have already a
>> patch for 4.3. Thus I'm fine with branching next week.
>>
>> When you do branch, please make sure to follow Barak Korren's request on
>> the
>> [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2
>> thread.
>> ___
>> 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
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm][RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Dan Kenigsberg
On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani  wrote:
> Hi all,
>
>
> It is time again to reconsider branching out the 4.2 stable branch.
>
> So far we decided to *not* branch out, and we are taking tags for ovirt
> 4.2 releases from master branch.
>
> This means we are merging safe and/or stabilization patches only in master.
>
>
> I think it is time to reconsider this decision and branch out for 4.2,
> because of two reasons:
>
> 1. it sends a clearer signal that 4.2 is going in stabilization mode
>
> 2. we have requests from virt team, which wants to start working on the
> next cycle features.
>
>
> If we decide to branch out, I'd start the new branch on monday, February
> 5 (1 week from now).
>
>
> The discussion is open, please share your acks/nacks for branching out,
> and for the branching date.
>
>
> I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll
> execute the above plan.

For network we don't see a lot of pending 4.2 work - except for the
requirement to support el7.5. On the other hand, we too have already a
patch for 4.3. Thus I'm fine with branching next week.

When you do branch, please make sure to follow Barak Korren's request on the
[ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2
thread.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] [vdsm][RFC] reconsidering branching out ovirt-4.2

2018-01-29 Thread Eyal Edri
On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani 
wrote:

> Hi all,
>
>
> It is time again to reconsider branching out the 4.2 stable branch.
>
> So far we decided to *not* branch out, and we are taking tags for ovirt
> 4.2 releases from master branch.
>
> This means we are merging safe and/or stabilization patches only in master.
>
>
> I think it is time to reconsider this decision and branch out for 4.2,
> because of two reasons:
>
> 1. it sends a clearer signal that 4.2 is going in stabilization mode
>
> 2. we have requests from virt team, which wants to start working on the
> next cycle features.
>
>
> If we decide to branch out, I'd start the new branch on monday, February
> 5 (1 week from now).
>
>
> The discussion is open, please share your acks/nacks for branching out,
> and for the branching date.
>
>
> I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll
> execute the above plan.
>


+1 from me, but FYI if not all projects or at least the important ones like
ovirt-engine will do the same or add mapping from master to 4.2, like
explained in the 4.2 thread on devel list,
Then CI won't really work for 4.2, as it will probably need always newer
engine version or other pkgs that only exists in master flow.


>
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R
> Red Hat
> IRC: fromani github: @fromanirh
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

Eyal edri


MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
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