Re: [ovirt-devel] oVirt 4.2.0 GA Go / No go

[Oved Ourfali]

+1 on my end.

On Tue, Dec 19, 2017 at 4:21 PM, Sandro Bonazzola 
wrote:

> Hi,
> we released 4.2.0 RC3 yesterday and currently we don't have approved or
> proposed blockers.
> So maintainers, please give your Go / No go for releasing GA tomorrow,
> December 20th.
>
> Thanks,
>
> --
>
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 GA status

[Oved Ourfali]

>From the latest comment it doesn't seem like a blocker to me.
Martin S. - your thoughts?

On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola 
wrote:

> We have a proposed blocker for the release:
> 1527155  Infra vdsm
> Bindings-API igoih...@redhat.com NEW jsonrpc reconnect logic does not
> work and gets stuck 
> urgent unspecified ovirt-4.2.0 04:30:30
>
> Please review and either approve the blcoker or postpone to 4.2.1.
> Thanks,
>
>
> --
>
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Adding new features to ovirt.org

[Oved Ourfali]

On Thu, Nov 16, 2017 at 2:53 PM, Barak Korren  wrote:

> On 16 November 2017 at 10:30, Martin Sivak  wrote:
> >> I wonder where did this category division come from, some of these,
> >> like "VDSM" or "Infra" or "SLA" may not be easy for users to
> >> understand.
> >> We need to be careful about using internal development terms in user
> >> facing documentation.
> >
> > And yet we require the user to select a team using the same terms when
> > filing a new bug..
> >
> > I agree with you, but I think the mandatory field in bugzilla is
> > another candidate for consideration.
>
> I've no disagreement with this statement, then again, I don't know
> much about the complex reasons behind the selection of fields used in
> bugzilla.
>
>
>
Nothing complex, to be honest.
The bugzilla "oVirt team" fields come to reflect the different teams owning
a bug.
Those are valuable for the teams, but some also make sense for users
(virt/storage/infra/network/dwh/node), while others might be a bit more
confusing (ux/integration/SLA).
Not sure what VDSM is with regards to the feature pages? maybe for old
features? I assume we can merge it into one of the others.
And we can send some explanation upstream (or better add one to the
website) if that helps.


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

Re: [ovirt-devel] Invitation to API 'Live Documentation' presentation - Oct 2

[Oved Ourfali]

Yes.

On Sep 27, 2017 19:52, "Greg Sheremeta"  wrote:

Hi Ori,

Sounds nice :) Your invite came through for me at "Mon Oct 2, 2017 4pm –
5pm (EDT)" -- but double checking, this is 4pm Israel time, right?

Best wishes,
Greg


On Wed, Sep 27, 2017 at 9:42 AM, Ori Liel  wrote:

> This coming Monday, Oct 2, I will present a new feature in the API which
> has to do with documentation of API operations (it's more exciting than it
> sounds).
>
> This presentation is important for everyone submitting patches to the
> ovirt-engine-api-model, because these patches will be required to use the
> documentation infrastructure in the proper manner.
>
> I invite you all to be there, at:
>
>   https://bluejeans.com/u/oliel/3879/
>
> Ori
>
> ___
> 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] [ OST Failure Report ] [ oVirt master ] [ 2017-08-30 ] [add_hosts]

[Oved Ourfali]

Barak - can you prioritize fixing this one?
It blocks us from adding additional functionality into the
ovirt-ansible-roles repo.

On Thu, Aug 31, 2017 at 11:54 AM, Martin Perina  wrote:

> So with ovirt-ansible-roles-1.1.0 (which is the last offically relased
> version) everything runs fine and host is added properly (tested several
> times on CentOS 7.3)
>
> But we need to fix executing builds from github otherwise we cannot
> continue working with ovirt-ansible-roles in github:
>
> 1. If you add comment 'ci build please' to github PR, then build will be
> executed and the result will be a repo with RPM to be used in OST (but this
> build will not be passed to queue to be added to tested repo)
>
> 2. When PR is merged, then either automatically or by some other
> comment/action (available to maintainers only) build will be executed and
> if build is OK, it can be queued to be added to tested repo
>
> Without above we just cannot continue working on ovirt-ansible-roles on
> github.
>
> Thanks
>
> Martin
>
>
>
> On Thu, Aug 31, 2017 at 8:55 AM, Barak Korren  wrote:
>
>> On 30 August 2017 at 22:20, Martin Perina  wrote:
>> >
>> >>
>> >> So we're back in square one.
>> >> Another possible culprit may be ansible: Vdsm is stopped two seconds
>> >> after it logs to the host.
>> >>
>> >> Aug 30 11:26:24 lago-basic-suite-master-host-0 systemd: Starting
>> >> Session 10 of user root.
>> >> Aug 30 11:26:25 lago-basic-suite-master-host-0 python: ansible-setup
>> >> Invoked with filter=* gather_subset=['all']
>> >> fact_path=/etc/ansible/facts.d gather_timeout=10
>> >> Aug 30 11:26:25 lago-basic-suite-master-host-0 python: ansible-command
>> >> Invoked with warn=True executable=None _uses_shell=False
>> >> _raw_params=bash -c "rpm -qi vdsm | grep -oE
>> >> 'Version\\s+:\\s+[0-9\\.]+' | awk '{print $3}'" removes=None
>> >> creates=None chdir=None
>> >> Aug 30 11:26:26 lago-basic-suite-master-host-0 python: ansible-systemd
>> >> Invoked with no_block=False name=libvirt-guests enabled=True
>> >> daemon_reload=False state=started user=False masked=None
>> >> Aug 30 11:26:26 lago-basic-suite-master-host-0 systemd: Reloading.
>> >> Aug 30 11:26:26 lago-basic-suite-master-host-0 systemd: Cannot add
>> >> dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.
>> >> Aug 30 11:26:26 lago-basic-suite-master-host-0 systemd: Stopped MOM
>> >> instance configured for VDSM purposes.
>> >> Aug 30 11:26:26 lago-basic-suite-master-host-0 systemd: Stopping
>> >> Virtual Desktop Server Manager...
>> >>
>> >>
>> >> could it be that it triggers a systemd-reload that makes systemd croak
>> >> on the vdsm-mom cycle?
>> >
>> >
>> > We are not restarting VDSM within ovirt-host-deploy Ansible role, the
>> VDSM
>> > restart is performed in host-deploy part same as in previous versions.
>> >
>> > Within ovirt-host-deploy-firewalld we only enable and restart firewalld
>> > service.
>> >
>>
>> comparing a successful add-host flow [1] to a failed one [2] we notice
>> that in the failed add host ansible logs in twice (session 10 and
>> session 11). Could it be somehow related? Notice that Session 11 uses
>> the OLD way (awk+grep based) to find vdsm's version.
>>
>> Aug 30 05:55:53 lago-basic-suite-master-host-0 systemd-logind: New
>> session 10 of user root.
>> Aug 30 05:55:53 lago-basic-suite-master-host-0 systemd: Starting
>> Session 10 of user root.
>> Aug 30 05:55:53 lago-basic-suite-master-host-0 python: ansible-setup
>> Invoked with filter=* gather_subset=['all']
>> fact_path=/etc/ansible/facts.d gather_timeout=10
>> Aug 30 05:55:54 lago-basic-suite-master-host-0 python: ansible-command
>> Invoked with warn=True executable=None _uses_shell=False
>> _raw_params=bash -c "rpm -qi vdsm | grep -oE
>> 'Version\\s+:\\s+[0-9\\.]+' | awk '{print $3}'" removes=None
>> creates=None chdir=None
>> Aug 30 05:55:54 lago-basic-suite-master-host-0 python: ansible-systemd
>> Invoked with no_block=False name=libvirt-guests enabled=True
>> daemon_reload=False state=started user=False masked=None
>> Aug 30 05:55:54 lago-basic-suite-master-host-0 systemd: Reloading.
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 systemd: Cannot add
>> dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 systemd: Stopped MOM
>> instance configured for VDSM purposes.
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 systemd: Stopping
>> Virtual Desktop Server Manager...
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 systemd: Starting
>> Suspend Active Libvirt Guests...
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 systemd: Started
>> Suspend Active Libvirt Guests.
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 journal: libvirt
>> version: 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem
>> , 2017-05-25-20:52:28, c1bm.rdu2.centos.org)
>> Aug 30 05:55:55 lago-basic-suite-master-host-0 journal: hostname:
>> 

Re: [ovirt-devel] Webadmin Hosts

[Oved Ourfali]

Hi,

Not sure I follow. You want to add a new dialog to the hosts main tab?
CC-ing Greg from the UI team to keep him in the loop.

Oved

On Sun, Jul 23, 2017 at 10:35 AM, 紫星雨  wrote:

> Hello!
>  There are serveral sub-function buttons under "hosts", such as 'New'
> and 'Edit' button.
>  When click on the button will trigger event monitoring  pop-up a new
> interface , I want to know how to implement as fallow the UI(New Host).
>
>
>
>
> ___
> 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] [ OST Failure Report ] [ Failed Build ] [ oVirt engine master ]

[Oved Ourfali]

If that's the case, we should make sure in the future that patches are self
contained, even if the plan is to push them together.

On Wed, Jul 19, 2017 at 1:39 PM, Daniel Belenky <dbele...@redhat.com> wrote:

> The root cause of those failures is that [1] and [2] can't be built
> without [3].
>
> [1] https://gerrit.ovirt.org/#/c/78847/5
> <https://gerrit.ovirt.org/#/c/78847/5>[2] https://gerrit.ovirt.org/#/c/
> 78848/5 <https://gerrit.ovirt.org/#/c/78848/5>
> [3] https://gerrit.ovirt.org/#/c/78849/10
> <https://gerrit.ovirt.org/#/c/78849/10>
>
> On Wed, Jul 19, 2017 at 1:15 PM, Eyal Edri <ee...@redhat.com> wrote:
>
>>
>>
>> On Wed, Jul 19, 2017 at 12:45 PM, Oved Ourfali <oourf...@redhat.com>
>> wrote:
>>
>>> I also see that subsequent patches, such as [1] pass those tests:
>>> 
>>> 
>>> Patch Set 4: Continuous-Integration+1
>>> Build Successful
>>> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch
>>> -el7-x86_64/26661/ : SUCCESS
>>> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch
>>> -fc25-x86_64/10705/ : SUCCESS
>>>
>>
>> check-patch doesn't run the same commands as 'check-merged' or
>> 'build-artifacts'.
>> I've deleted the workspaces for those jobs on 2 slaves it failed on, if
>> it was due to old maven cache left there it should work now,
>> but we need to understand why it happened and maybe improve the code in
>> check-merged/build-artifacts of in the cleanup code.
>>
>>
>>
>>> 
>>> 
>>> [1] https://gerrit.ovirt.org/#/c/79493/
>>>
>>>
>>> On Wed, Jul 19, 2017 at 12:27 PM, Oved Ourfali <oourf...@redhat.com>
>>> wrote:
>>>
>>>> Can we access the environment?
>>>>
>>>> On Wed, Jul 19, 2017 at 12:21 PM, Daniel Belenky <dbele...@redhat.com>
>>>> wrote:
>>>>
>>>>> It's also removing /home/jenkins/.m2
>>>>>
>>>>> On Wed, 19 Jul 2017 at 12:16 Tomas Jelinek <tjeli...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Jul 19, 2017 at 11:02 AM, Daniel Belenky <dbele...@redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> I've added a build step that removes .m2 cache and the error still
>>>>>>> appears.
>>>>>>>
>>>>>>
>>>>>> are you sure you have removed the right m2 folder? I see this in the
>>>>>> logs:
>>>>>>
>>>>>> rm -rf /root/.m2/repository/org/ovirt
>>>>>>
>>>>>> and than building it in
>>>>>> /home/jenkins/
>>>>>>
>>>>>> ... along shot but seems suspicious.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 19, 2017 at 11:46 AM, Eyal Edri <ee...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Daniel,
>>>>>>>> IIRC we have local maven cache on the slaves, please try to clean
>>>>>>>> it first and re-run.
>>>>>>>> If its not working, then I suggest engine maintainers will look
>>>>>>>> into the command that is run inside 'check-merged.sh' and see if there 
>>>>>>>> is a
>>>>>>>> leftover
>>>>>>>> profile in Makefile or maven that still requires userportal.
>>>>>>>>
>>>>>>>> On Wed, Jul 19, 2017 at 11:43 AM, Oved Ourfali <oourf...@redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> I discussed that offline with Eyal.
>>>>>>>>> Perhaps some of the data there is cached.
>>>>>>>>> He said he is on it.
>>>>>>>>>
>>>>>>>>> On Wed, Jul 19, 2017 at 11:22 AM, Daniel Belenky <
>>>>>>>>> dbele...@redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi, I've tried to re-trigger build-artifacts and it failed.
>>>>>>>>>> What do you mean by 'brand ne

Re: [ovirt-devel] [ OST Failure Report ] [ Failed Build ] [ oVirt engine master ]

[Oved Ourfali]

I also see that subsequent patches, such as [1] pass those tests:

Patch Set 4: Continuous-Integration+1
Build Successful
http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-el7-x86_64/26661/
: SUCCESS
http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc25-x86_64/10705/
: SUCCESS

[1] https://gerrit.ovirt.org/#/c/79493/


On Wed, Jul 19, 2017 at 12:27 PM, Oved Ourfali <oourf...@redhat.com> wrote:

> Can we access the environment?
>
> On Wed, Jul 19, 2017 at 12:21 PM, Daniel Belenky <dbele...@redhat.com>
> wrote:
>
>> It's also removing /home/jenkins/.m2
>>
>> On Wed, 19 Jul 2017 at 12:16 Tomas Jelinek <tjeli...@redhat.com> wrote:
>>
>>> On Wed, Jul 19, 2017 at 11:02 AM, Daniel Belenky <dbele...@redhat.com>
>>> wrote:
>>>
>>>> I've added a build step that removes .m2 cache and the error still
>>>> appears.
>>>>
>>>
>>> are you sure you have removed the right m2 folder? I see this in the
>>> logs:
>>>
>>> rm -rf /root/.m2/repository/org/ovirt
>>>
>>> and than building it in
>>> /home/jenkins/
>>>
>>> ... along shot but seems suspicious.
>>>
>>>
>>>
>>>>
>>>> On Wed, Jul 19, 2017 at 11:46 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>>
>>>>> Daniel,
>>>>> IIRC we have local maven cache on the slaves, please try to clean it
>>>>> first and re-run.
>>>>> If its not working, then I suggest engine maintainers will look into
>>>>> the command that is run inside 'check-merged.sh' and see if there is a
>>>>> leftover
>>>>> profile in Makefile or maven that still requires userportal.
>>>>>
>>>>> On Wed, Jul 19, 2017 at 11:43 AM, Oved Ourfali <oourf...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I discussed that offline with Eyal.
>>>>>> Perhaps some of the data there is cached.
>>>>>> He said he is on it.
>>>>>>
>>>>>> On Wed, Jul 19, 2017 at 11:22 AM, Daniel Belenky <dbele...@redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi, I've tried to re-trigger build-artifacts and it failed.
>>>>>>> What do you mean by 'brand new environment'? It's the
>>>>>>> build-artifacts and check-merged of this patch, not OST.
>>>>>>> Link:
>>>>>>> check-merged: http://jenkins.ovirt.org/job/o
>>>>>>> virt-engine_master_check-merged-el7-x86_64/5408/
>>>>>>> build-artifacts: http://jenkins.ovirt.org/job/o
>>>>>>> virt-engine_master_check-merged-el7-x86_64/5408/
>>>>>>>
>>>>>>> On Wed, Jul 19, 2017 at 10:56 AM, Oved Ourfali <oourf...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can you re-test?
>>>>>>>> We have pushed a fix this morning.
>>>>>>>> Although not specifically for that.
>>>>>>>> Also, is that a brand new environment?
>>>>>>>> We removed the user portal, so it shouldn't look for the pom file.
>>>>>>>>
>>>>>>>> On Jul 19, 2017 09:46, "Daniel Belenky" <dbele...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> This patch has [1] failed building, and every patch that was
>>>>>>>>> rebased on top of it failed too because of it.
>>>>>>>>>
>>>>>>>>> Error snippet:
>>>>>>>>>
>>>>>>>>> [ERROR] The build could not read 1 project -> [Help 1]
>>>>>>>>> [ERROR]
>>>>>>>>> [ERROR]   The project 
>>>>>>>>> org.ovirt.engine.ui:webadmin-modules:4.2.0-SNAPSHOT
>>>>>>>>> (/home/jenkins/workspace/ovirt-engine_master_build-artifacts
>>>>>>>>> -el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml) has 1
>>>>>>>>&

Re: [ovirt-devel] [ OST Failure Report ] [ Failed Build ] [ oVirt engine master ]

[Oved Ourfali]

Can we access the environment?

On Wed, Jul 19, 2017 at 12:21 PM, Daniel Belenky <dbele...@redhat.com>
wrote:

> It's also removing /home/jenkins/.m2
>
> On Wed, 19 Jul 2017 at 12:16 Tomas Jelinek <tjeli...@redhat.com> wrote:
>
>> On Wed, Jul 19, 2017 at 11:02 AM, Daniel Belenky <dbele...@redhat.com>
>> wrote:
>>
>>> I've added a build step that removes .m2 cache and the error still
>>> appears.
>>>
>>
>> are you sure you have removed the right m2 folder? I see this in the logs:
>>
>> rm -rf /root/.m2/repository/org/ovirt
>>
>> and than building it in
>> /home/jenkins/
>>
>> ... along shot but seems suspicious.
>>
>>
>>
>>>
>>> On Wed, Jul 19, 2017 at 11:46 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>
>>>> Daniel,
>>>> IIRC we have local maven cache on the slaves, please try to clean it
>>>> first and re-run.
>>>> If its not working, then I suggest engine maintainers will look into
>>>> the command that is run inside 'check-merged.sh' and see if there is a
>>>> leftover
>>>> profile in Makefile or maven that still requires userportal.
>>>>
>>>> On Wed, Jul 19, 2017 at 11:43 AM, Oved Ourfali <oourf...@redhat.com>
>>>> wrote:
>>>>
>>>>> I discussed that offline with Eyal.
>>>>> Perhaps some of the data there is cached.
>>>>> He said he is on it.
>>>>>
>>>>> On Wed, Jul 19, 2017 at 11:22 AM, Daniel Belenky <dbele...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi, I've tried to re-trigger build-artifacts and it failed.
>>>>>> What do you mean by 'brand new environment'? It's the build-artifacts
>>>>>> and check-merged of this patch, not OST.
>>>>>> Link:
>>>>>> check-merged: http://jenkins.ovirt.org/job/ovirt-engine_master_check-
>>>>>> merged-el7-x86_64/5408/
>>>>>> build-artifacts: http://jenkins.ovirt.org/job/
>>>>>> ovirt-engine_master_check-merged-el7-x86_64/5408/
>>>>>>
>>>>>> On Wed, Jul 19, 2017 at 10:56 AM, Oved Ourfali <oourf...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Can you re-test?
>>>>>>> We have pushed a fix this morning.
>>>>>>> Although not specifically for that.
>>>>>>> Also, is that a brand new environment?
>>>>>>> We removed the user portal, so it shouldn't look for the pom file.
>>>>>>>
>>>>>>> On Jul 19, 2017 09:46, "Daniel Belenky" <dbele...@redhat.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This patch has [1] failed building, and every patch that was
>>>>>>>> rebased on top of it failed too because of it.
>>>>>>>>
>>>>>>>> Error snippet:
>>>>>>>>
>>>>>>>> [ERROR] The build could not read 1 project -> [Help 1]
>>>>>>>> [ERROR]
>>>>>>>> [ERROR]   The project 
>>>>>>>> org.ovirt.engine.ui:webadmin-modules:4.2.0-SNAPSHOT
>>>>>>>> (/home/jenkins/workspace/ovirt-engine_master_build-
>>>>>>>> artifacts-el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml)
>>>>>>>> has 1 error
>>>>>>>> [ERROR] Child module /home/jenkins/workspace/ovirt-
>>>>>>>> engine_master_build-artifacts-el7-x86_64/ovirt-engine/
>>>>>>>> frontend/webadmin/modules/userportal-gwtp of
>>>>>>>> /home/jenkins/workspace/ovirt-engine_master_build-artifacts-
>>>>>>>> el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml does not
>>>>>>>> exist
>>>>>>>> [ERROR]
>>>>>>>> [ERROR] To see the full stack trace of the errors, re-run Maven
>>>>>>>> with the -e switch.
>>>>>>>> [ERROR] Re-run Maven using the -X switch to enable full debug
>>>>>>>> logging.
>>>>>>>> [ERROR]
>>>>>>>> [ERROR] For more information about the errors and possible
>>>>>>>> solutions, please read the following articles:
>>>>>>>> [ERROR] 

Re: [ovirt-devel] [ OST Failure Report ] [ Failed Build ] [ oVirt engine master ]

[Oved Ourfali]

I discussed that offline with Eyal.
Perhaps some of the data there is cached.
He said he is on it.

On Wed, Jul 19, 2017 at 11:22 AM, Daniel Belenky <dbele...@redhat.com>
wrote:

> Hi, I've tried to re-trigger build-artifacts and it failed.
> What do you mean by 'brand new environment'? It's the build-artifacts and
> check-merged of this patch, not OST.
> Link:
> check-merged: http://jenkins.ovirt.org/job/ovirt-engine_master_check-
> merged-el7-x86_64/5408/
> build-artifacts: http://jenkins.ovirt.org/job/ovirt-engine_master_check-
> merged-el7-x86_64/5408/
>
> On Wed, Jul 19, 2017 at 10:56 AM, Oved Ourfali <oourf...@redhat.com>
> wrote:
>
>> Can you re-test?
>> We have pushed a fix this morning.
>> Although not specifically for that.
>> Also, is that a brand new environment?
>> We removed the user portal, so it shouldn't look for the pom file.
>>
>> On Jul 19, 2017 09:46, "Daniel Belenky" <dbele...@redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> This patch has [1] failed building, and every patch that was rebased on
>>> top of it failed too because of it.
>>>
>>> Error snippet:
>>>
>>> [ERROR] The build could not read 1 project -> [Help 1]
>>> [ERROR]
>>> [ERROR]   The project org.ovirt.engine.ui:webadmin-modules:4.2.0-SNAPSHOT
>>> (/home/jenkins/workspace/ovirt-engine_master_build-artifacts
>>> -el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml) has 1 error
>>> [ERROR] Child module /home/jenkins/workspace/ovirt-
>>> engine_master_build-artifacts-el7-x86_64/ovirt-engine/fronte
>>> nd/webadmin/modules/userportal-gwtp of /home/jenkins/workspace/ovirt-
>>> engine_master_build-artifacts-el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml
>>> does not exist
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>>> -e switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions,
>>> please read the following articles:
>>> [ERROR] [Help 1] http://cwiki.apache.org/conflu
>>> ence/display/MAVEN/ProjectBuildingException
>>> make: *** [clean] Error 1
>>>
>>> [1] https://gerrit.ovirt.org/#/c/78847/5
>>>
>>> Thanks,
>>> --
>>>
>>> DANIEL BELENKY
>>>
>>> Associate sw engineer
>>>
>>> RHEV DEVOPS
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>> Red Hat Israel <https://www.redhat.com/>
>>>
>>> dbele...@redhat.comIRC: #rhev-integ, #rhev-dev
>>> <https://red.ht/sig>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>
>
> --
>
> DANIEL BELENKY
>
> Associate sw engineer
>
> RHEV DEVOPS
>
> EMEA VIRTUALIZATION R
>
> Red Hat Israel <https://www.redhat.com/>
>
> dbele...@redhat.comIRC: #rhev-integ, #rhev-dev
> <https://red.ht/sig>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ Failed Build ] [ oVirt engine master ]

[Oved Ourfali]

Can you re-test?
We have pushed a fix this morning.
Although not specifically for that.
Also, is that a brand new environment?
We removed the user portal, so it shouldn't look for the pom file.

On Jul 19, 2017 09:46, "Daniel Belenky"  wrote:

> Hi all,
>
> This patch has [1] failed building, and every patch that was rebased on
> top of it failed too because of it.
>
> Error snippet:
>
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project org.ovirt.engine.ui:webadmin-modules:4.2.0-SNAPSHOT
> (/home/jenkins/workspace/ovirt-engine_master_build-
> artifacts-el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml) has
> 1 error
> [ERROR] Child module /home/jenkins/workspace/ovirt-
> engine_master_build-artifacts-el7-x86_64/ovirt-engine/
> frontend/webadmin/modules/userportal-gwtp of
> /home/jenkins/workspace/ovirt-engine_master_build-artifacts-
> el7-x86_64/ovirt-engine/frontend/webadmin/modules/pom.xml does not exist
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> ProjectBuildingException
> make: *** [clean] Error 1
>
> [1] https://gerrit.ovirt.org/#/c/78847/5
>
> Thanks,
> --
>
> DANIEL BELENKY
>
> Associate sw engineer
>
> RHEV DEVOPS
>
> EMEA VIRTUALIZATION R
>
> Red Hat Israel 
>
> dbele...@redhat.comIRC: #rhev-integ, #rhev-dev
> 
>
> ___
> 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] Failed to build artifacts for oVirt master

[Oved Ourfali]

CC-ing Greg anyway,

On Tue, Jul 18, 2017 at 12:18 PM, Tomas Jelinek <tjeli...@redhat.com> wrote:

>
>
> On Tue, Jul 18, 2017 at 11:10 AM, Oved Ourfali <oourf...@redhat.com>
> wrote:
>
>> CC-ing the author of those patches.
>>
>> On Tue, Jul 18, 2017 at 12:09 PM, Daniel Belenky <dbele...@redhat.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> The following patches are failing to build artifacts:
>>>
>>>1. https://gerrit.ovirt.org/#/c/79540/1
>>>2. https://gerrit.ovirt.org/#/c/79433/3
>>>
>>>
> Ah, right. The actually correct way of fixing it is to merge this:
> https://gerrit.ovirt.org/#/q/status:open+project:ovirt-
> engine+branch:master+topic:delete_userportal
> but it seems it is not going to happen today...
>
> Going to provide a quick fix.
>
>
>> Though, it seems that the root for the failure is patch [2] as patch [1]
>>> was merged after patch [2], and patch [2] failed to build artifacts.
>>>
>>> Error snippet from Console Output:
>>>
>>> ...
>>> ...
>>> [INFO] UserPortal  FAILURE 
>>> [1:34.567s]
>>> ...
>>> ...
>>> [ERROR] Failed to execute goal 
>>> org.codehaus.mojo:gwt-maven-plugin:2.8.0:compile (gwtcompile) on project 
>>> userportal: Command [[
>>> [ERROR] /bin/sh -c 
>>> '/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/bin/java' 
>>> '-javaagent:/root/.m2/repository/org/aspectj/aspectjweaver/1.8.10/aspectjweaver-1.8.10.jar'
>>>  
>>> '-Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory'
>>>  '-Dgwt.jjs.maxThreads=4' 
>>> '-Djava.io.tmpdir=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>>>  
>>> '-Djava.util.prefs.systemRoot=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>>>  
>>> '-Djava.util.prefs.userRoot=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>>>  
>>> '-Djava.util.logging.config.class=org.ovirt.engine.ui.gwtaop.JavaLoggingConfig'
>>>  '-Xms1G' '-Xmx4G' 
>>> '-Dgwt.dontPrune=org\.ovirt\.engine\.core\.(common|compat)\..*' 
>>> 'com.google.gwt.dev.Compiler' '-logLevel' 'INFO' '-war' 
>>> '/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/generated-gwt'
>>>  '-localWorkers' '1' '-failOnError' '-XfragmentCount' '-1' '-sourceLevel' 
>>> 'auto' '-style' 'OBF' '-gen' 
>>> '/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/gen'
>>>  'org.ovirt.engine.ui.userportal.UserPortal'
>>> [ERROR] ]] failed with status 1
>>> [ERROR] -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
>>> switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions, 
>>> please read the following articles:
>>> [ERROR] [Help 1] 
>>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>>> [ERROR]
>>> [ERROR] After correcting the problems, you can resume the build with the 
>>> command
>>> [ERROR]   mvn  -rf :userportal
>>>
>>> --
>>>
>>> DANIEL BELENKY
>>>
>>> Associate sw engineer
>>>
>>> RHEV DEVOPS
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>> Red Hat Israel <https://www.redhat.com/>
>>>
>>> dbele...@redhat.comIRC: #rhev-integ, #rhev-dev
>>> <https://red.ht/sig>
>>>
>>> ___
>>> 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] Failed to build artifacts for oVirt master

[Oved Ourfali]

CC-ing the author of those patches.

On Tue, Jul 18, 2017 at 12:09 PM, Daniel Belenky 
wrote:

> Hi all,
>
> The following patches are failing to build artifacts:
>
>1. https://gerrit.ovirt.org/#/c/79540/1
>2. https://gerrit.ovirt.org/#/c/79433/3
>
> Though, it seems that the root for the failure is patch [2] as patch [1]
> was merged after patch [2], and patch [2] failed to build artifacts.
>
> Error snippet from Console Output:
>
> ...
> ...
> [INFO] UserPortal  FAILURE [1:34.567s]
> ...
> ...
> [ERROR] Failed to execute goal 
> org.codehaus.mojo:gwt-maven-plugin:2.8.0:compile (gwtcompile) on project 
> userportal: Command [[
> [ERROR] /bin/sh -c 
> '/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/bin/java' 
> '-javaagent:/root/.m2/repository/org/aspectj/aspectjweaver/1.8.10/aspectjweaver-1.8.10.jar'
>  
> '-Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory'
>  '-Dgwt.jjs.maxThreads=4' 
> '-Djava.io.tmpdir=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>  
> '-Djava.util.prefs.systemRoot=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>  
> '-Djava.util.prefs.userRoot=/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/tmp'
>  
> '-Djava.util.logging.config.class=org.ovirt.engine.ui.gwtaop.JavaLoggingConfig'
>  '-Xms1G' '-Xmx4G' 
> '-Dgwt.dontPrune=org\.ovirt\.engine\.core\.(common|compat)\..*' 
> 'com.google.gwt.dev.Compiler' '-logLevel' 'INFO' '-war' 
> '/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/target/generated-gwt'
>  '-localWorkers' '1' '-failOnError' '-XfragmentCount' '-1' '-sourceLevel' 
> 'auto' '-style' 'OBF' '-gen' 
> '/home/jenkins/workspace/ovirt-engine_master_build-artifacts-el7-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.2.0/frontend/webadmin/modules/userportal-gwtp/gen'
>  'org.ovirt.engine.ui.userportal.UserPortal'
> [ERROR] ]] failed with status 1
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :userportal
>
> --
>
> DANIEL BELENKY
>
> Associate sw engineer
>
> RHEV DEVOPS
>
> EMEA VIRTUALIZATION R
>
> Red Hat Israel 
>
> dbele...@redhat.comIRC: #rhev-integ, #rhev-dev
> 
>
> ___
> 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] Chaning the statistics monitoring interval to 30s

[Oved Ourfali]

On Thu, Jul 6, 2017 at 12:19 PM, Roy Golan <rgo...@redhat.com> wrote:

>
>
> On Thu, Jul 6, 2017 at 12:18 PM Roy Golan <rgo...@redhat.com> wrote:
>
>> Action items:
>> - Demonstrate the effect of the reduction of stats collection on the
>> system - WIP
>> - Code changes:
>>   - config item change: NumberVmRefreshesBeforeSave from 5 to 10
>>   - make the 'poll' vms job to fire at NumberVmRefreshesBeforeSave / 2
>> (or just make the code to support explicit time interval)
>>   - VDSM should get a config set with the sampling inteval - to support
>> back-compat
>>
>> - Chages to DWH sampling and ManageIQ?
>

I think manageIQ can cope with either 60 seconds or 20 seconds intervals
(after a change we've made when we moved to 20 seconds).
Put an action item indeed to check that with us if we'll decide to do so.


>
>>
>>
>> On Thu, Jul 6, 2017 at 11:00 AM Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>> On Thu, Jul 6, 2017 at 10:04 AM, Oved Ourfali <oourf...@redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 9:38 AM, Arik Hadas <aha...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 5, 2017 at 9:36 PM, Shirly Radco <sra...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> SHIRLY RADCO
>>>>>>
>>>>>> BI SOFTWARE ENGINEER,
>>>>>>
>>>>>> Red Hat Israel <https://www.redhat.com/>
>>>>>>
>>>>>> sra...@redhat.com
>>>>>>  <https://red.ht/sig>
>>>>>>  <https://redhat.com/summit>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 5, 2017 at 6:35 PM, Arik Hadas <aha...@redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 5, 2017 at 5:57 PM, Roy Golan <rgo...@redhat.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I would like to get feedback on $subject and see if I'm missing
>>>>>>>> something. The impact of this is simply less resource consumption and 
>>>>>>>> by
>>>>>>>> that we can support even greater number of hosts [1] and vms in the 
>>>>>>>> system.
>>>>>>>>
>>>>>>>
>>>>>>>> If you think more relaxed statistics collection will affect a core
>>>>>>>> flow let me know - as far as I see I didn't spot anything critical.
>>>>>>>>
>>>>>>>
>>>>>>>> The overhead of a cycle per host something like that: 2 roundtrips
>>>>>>>> per host in a cycle, (vm + host stats) and tons of memory allocation 
>>>>>>>> for
>>>>>>>> char[] -> json-> maps of maps -> VM/Vds statistics -> Maps -> 
>>>>>>>> serialiazing
>>>>>>>> to DB.
>>>>>>>>
>>>>>>>> To minimize the effect of this change we can leave a call to 'list'
>>>>>>>> verb to at least detect vms existence in the same rate as today.
>>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Pros
>>>>>>>> - Engine has rore resources to support more hosts/vms/other
>>>>>>>> activities of the engine
>>>>>>>> - Vdsm will have more resources as well (need to tweak vdsm to
>>>>>>>> collect in the same
>>>>>>>> frequency)
>>>>>>>> - less DB writes and reads, approx half of what the system will do
>>>>>>>> in the in its lifefpan (cause this is what is mainly does all the time)
>>>>>>>>
>>>>>>>> Cons
>>>>>>>> - DWH/Dashboard will have less entries, I'm not sure what is
>>>>>>>> graphical affect given our hourly resolution (cmiiw here)
>>>>>>>>
>>>>>>>
>>>>>>> What's the frequency of the queries done by DWH/Dashboard? Do they
>&g

Re: [ovirt-devel] Chaning the statistics monitoring interval to 30s

[Oved Ourfali]

On Thu, Jul 6, 2017 at 9:38 AM, Arik Hadas  wrote:

>
>
> On Wed, Jul 5, 2017 at 9:36 PM, Shirly Radco  wrote:
>
>>
>>
>> --
>>
>> SHIRLY RADCO
>>
>> BI SOFTWARE ENGINEER,
>>
>> Red Hat Israel 
>>
>> sra...@redhat.com
>>  
>>  
>>
>>
>> On Wed, Jul 5, 2017 at 6:35 PM, Arik Hadas  wrote:
>>
>>>
>>>
>>> On Wed, Jul 5, 2017 at 5:57 PM, Roy Golan  wrote:
>>>
 Hi all,

 I would like to get feedback on $subject and see if I'm missing
 something. The impact of this is simply less resource consumption and by
 that we can support even greater number of hosts [1] and vms in the system.

>>>
 If you think more relaxed statistics collection will affect a core flow
 let me know - as far as I see I didn't spot anything critical.

>>>
 The overhead of a cycle per host something like that: 2 roundtrips per
 host in a cycle, (vm + host stats) and tons of memory allocation for char[]
 -> json-> maps of maps -> VM/Vds statistics -> Maps -> serialiazing to DB.

 To minimize the effect of this change we can leave a call to 'list'
 verb to at least detect vms existence in the same rate as today.

>>>
>>> +1
>>>
>>>

 Pros
 - Engine has rore resources to support more hosts/vms/other activities
 of the engine
 - Vdsm will have more resources as well (need to tweak vdsm to collect
 in the same
 frequency)
 - less DB writes and reads, approx half of what the system will do in
 the in its lifefpan (cause this is what is mainly does all the time)

 Cons
 - DWH/Dashboard will have less entries, I'm not sure what is graphical
 affect given our hourly resolution (cmiiw here)

>>>
>>> What's the frequency of the queries done by DWH/Dashboard? Do they count
>>> on the _update_date column of the queried data?
>>>
>>
>> Current frequency is 20 seconds.
>> The configurations are queried based on the _update_date, but  statistics
>> are queried every interval.
>>
>> The affect will be less accuracy in the hourly calculations.
>>
>
> Ack. So if the proposed change is done, it would probably make sense to
> increase the inverval of those queries to be higher than 30 sec, or at
> least taking into consideration the _update_date of vm_statistics as well.
>
>

Note that it will cause issues with cloudforms to change those queries to
30 seconds, so I guess we'll still query it every 20 seconds (although the
data won't change in some of those queries).



>>
>>> I'm asking because if they query the database every minute and say "the
>>> time now is 10:30 and the queried data is ..." then there should not be
>>> less entries.
>>>
>>>


 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876

>>>

 ___
 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] Making event types backwards compatible?

[Oved Ourfali]

On May 30, 2017 11:28, "Juan Hernández"  wrote:

On 05/30/2017 09:38 AM, Tomas Jelinek wrote:
>
>
> On Tue, May 30, 2017 at 9:16 AM, Juan Hernández  > wrote:
>
> On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> >
> >
> > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek <
mskri...@redhat.com 
> > >> wrote:
> >
> > > On 29 May 2017, at 11:44, Juan Hernández 
> >> wrote:
> > >
> > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > >>
> > >>> On 29 May 2017, at 10:39, Juan Hernández <
jhern...@redhat.com 
> > >>
wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>> It has been recently requested that the API provides event
> types:
> > >>>
> > >>> [RFE] Expose event types to API
> > >>> https://bugzilla.redhat.com/1453170
> 
> >  >
> > >>>
> > >>> Currently the API provides the event code and description,
for
> > example:
> > >>>
> > >>> 
> > >>>   19
> > >>>   Host myhost failed to recover. > >>>   ...
> > >>> 
> > >>>
> > >>> There is no documentation of what is the meaning of codes,
> > except the
> > >>> source code of the engine itself. This forces some
> applications
> > to add
> > >>> their own code to name mapping. For example, the 'ovirt'
Ruby
> > gem used
> > >>> by older versions of ManageIQ to interact with oVirt
contains
> > the following:
> > >>>
> > >>>
> >
>  https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/
event.rb#L25-L485
> 
> >
>   >
> > >>>
> > >>> We could avoid this by adding to the API a new event
> attribute that
> > >>> indicates the type:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> Ideally this should be defined as an enum, so that it will
be
> > >>> represented as an enum in the SDKs. Alternatively it could
> just
> > be an
> > >>> string, and we could reuse the 'name' attribute:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> However, the key point to making this useful would be to
keep
> > the types
> > >>> (or names) backwards compatible, so that users of the API
can
> > rely on
> > >>> their values and meanings.
> > >>>
> > >>> So this is my question to you: can we commit to keep the
> names and
> > >>> meanings of the backend event types backwards compatible?
> > >>
> > >> Do we even have to make it bw compatible?
> > >> I guess it depends on the actual usage of those names…
> > >> The ovirt ruby gem itself doesn’t do much with it
> > >
> > > We need to make keep it backwards compatible or else tell
> users "don't
> > > rely on these values, as they may change without notice".
> > >
> > > The 'ovirt' gem doesn't do anything special, it just creates
> its own
> > > code to name mapping. But the users of the 'ovirt' gem (the
> ManageIQ
> > > oVirt provider) do rely on the name. For example:
> > >
> > >
> > >
> https://github.com/ManageIQ/manageiq-providers-ovirt/blob/
master/app/models/manageiq/providers/redhat/infra_
manager/event_parser.rb#L80-L92
> 
> >
>   >
> >
> >
> > hmmm, while we are on topic, this pretty much looks like that
manageiq
> > 

Re: [ovirt-devel] upgrade of CL and DC vs running VMs

[Oved Ourfali]

On Thu, May 25, 2017 at 12:16 PM, Michal Skrivanek 
wrote:

> Hi all,
> I believe that introduction of bug 1413150 (Add warning to change CL to
> the match the installed engine version) may have an unfortunate consequence
> of people actually moving forward with the CL and DC without realizing the
> constraints on running existing VMs. The periodic nagging is likely going
> to make people run into the following issue even more frequently
>
>
Shall we note on cluster upgrade operation that the user should be aware of
the implications?
Do we know in advance those constraints and whether that are relevant in
the environment, and if it is then not issue the warning?


> We have a cluster level override per VM which takes care of compatibility
> on CL update by setting the VM’s override to the original CL - that is
> visible in VM properties, but that’s pretty much it, it’s not very
> prominent at the moment and it can’t be searched on (bug 1454389). When the
> update cluster change is made there is a dialog informing you, and there’s
> also the pending config change for those running VMs…until you shut the VM
> down, from that time on it only has the CL override set.
>
> But the real problem is with DC which AFAIK does not have an override
> capability, and currently does not have any checks for running VMs. With
> the above mechanism you can easily get a VM with CL override (say. 3.6) and
> mindlessly updated DC to 4.1…and once you stop such VM you won’t be able to
> start it anymore as there is a proper check for unsupported 3.6 CL VM in a
> newer DC (as implemented by bug 1436577 - Solve DC/Cluster upgrade of VMs
> with now-unsupported custom compatibility level)
>

I don't recall. Do we have a warning on data center level as well? Or only
cluster level?


>
> We either need to warn/block on DC upgrade, or implement some kind of a DC
> override (I guess this is a storage question?)
>

(Similar to my question above), do we have a way to identify those
constraints and whether they are relevant in the environment? And if so,
block upgrading of the DC level?


>
> Thoughts/ideas?
>
> Thanks,
> michal
> ___
> 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] [ OST Failure Report ] [ oVirt master][09-05-2017][ 002_bootstrap.add_hosts ]

[Oved Ourfali]

CC-ing Edi.


On Tue, May 9, 2017 at 3:46 PM, Yedidyah Bar David  wrote:

> On Tue, May 9, 2017 at 3:44 PM, Piotr Kliczewski
>  wrote:
> > It seems to be broken by this patch [1]
> >
> >
> > [1] https://gerrit.ovirt.org/#/c/76603
>
> Indeed. Please revert for now [1], then investigate.
>
> [1] https://gerrit.ovirt.org/76626
>
> >
> > On Tue, May 9, 2017 at 2:40 PM, Anton Marchukov 
> wrote:
> >> Hello.
> >>
> >> Today around 11 am the add host for master started to consistently fail.
> >>
> >> We found the following in /var/log/messages (as I understand it might
> get
> >> there through journald as the host deploy log claims that vdsmd unit
> startup
> >> failed):
> >>
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: Traceback (most
> >> recent call last):
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/bin/vdsm-tool", line 219, in main
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: return
> >> tool_command[cmd]["command"](*args)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/tool/network.py", line 48, in
> >> upgrade_networks
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> netupgrade.upgrade()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
> 55, in
> >> upgrade
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> _create_unified_configuration(rconfig, NetInfo(netinfo(vdsmnets)))
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
> 133, in
> >> _create_unified_configuration
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> RunningConfig.store()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
> line
> >> 204, in store
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> _store_net_config()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
> line
> >> 281, in _store_net_config
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> utils.rmTree(real_old_safeconf_dir)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 125, in rmTree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> shutil.rmtree(directoryToRemove)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib64/python2.7/shutil.py", line 232, in rmtree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> onerror(os.path.islink, path, sys.exc_info())
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib64/python2.7/shutil.py", line 230, in rmtree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: raise
> >> OSError("Cannot call rmtree on a symbolic link")
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: OSError: Cannot
> >> call rmtree on a symbolic link
> >> May  9 07:01:25 lago-basic-suite-master-host1 systemd:
> vdsm-network.service:
> >> control process exited, code=exited status=1
> >>
> >>
> >> The full logs of the run you can find in Jenkins artifacts:
> >>
> >> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_
> master/6589/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
> >>
> >>
> >> Any vdsm patches merged that might cause this?
> >>
> >> --
> >>
> >> Anton Marchukov
> >> Senior Software Engineer - RHEV CI - Red Hat
> >>
> >>
> >> ___
> >> 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
>
>
>
> --
> Didi
> ___
> 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] New design for the Gerrit UI

[Oved Ourfali]

Looks very nice!

On May 3, 2017 7:20 PM, "Evgheni Dereveanchin"  wrote:

> Hi everyone,
>
> The Infra team is working on customizing the look of Gerrit to make it fit
> better with other oVirt services. I want to share the result of this
> effort. Hopefully we can gather some feedback before applying the design to
> oVirt's instance of Gerrit.
>
> Please visit the Staging instance to check it out:
>
>   https://gerrit-staging.phx.ovirt.org/
>
> The new design is inspired by oVirt's main website. There is a known
> glitch that the "Loading Gerrit Code Review" message is overlapped by the
> logo when the UI is loading. If you spot any other issues or have ideas for
> improvement feel free to respond to this thread or share your feedback in
> the following JIRA ticket:
>
>   https://ovirt-jira.atlassian.net/browse/OVIRT-912
>
> --
> Regards,
> Evgheni Dereveanchin
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST failure NoClassDefFoundError

[Oved Ourfali]

I guess you need to upgrade vdsm-jsonrpc-java.
Did you try that?

On Tue, Apr 25, 2017 at 12:57 AM, Roy Golan  wrote:

> I get this on basic suite from a built RPM[1]:
>
> Caused by: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>   at 
> org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message.withCorrelationId(Message.java:75)
>  [vdsm-jsonrpc-java-client.jar:]
>   at 
> org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClient.sendMessage(SSLStompClient.java:85)
>  [vdsm-jsonrpc-java-client.jar:]
>   at 
> org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:83) 
> [vdsm-jsonrpc-java-client.jar:]
>
>
> My patch under test certainly didn't touch this area [2]
>
> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/290/
> artifact/exported-artifacts/test_logs/basic-suite-master/
> post-002_bootstrap.py/lago-basic-suite-master-engine/_
> var_log/ovirt-engine/engine.log
>
> [2] https://gerrit.ovirt.org/#/c/75262/
>
> Did anyone see that?
>
>
>
> ___
> 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] ovirt-engine dependencies and packaging plans for 4.2

[Oved Ourfali]

On Apr 7, 2017 15:47, "Sandro Bonazzola"  wrote:

In https://bugzilla.redhat.com/show_bug.cgi?id=1439518
I'm suggesting a packaging change for ovirt-engine allowing to reduce the
space needed to install a minimal ovirt-engine.

Martin says:
We should get rid of PostgreSQL RPM dependency when we move to SCL version
of PG9.5/9.6, which is planned fo 4.2
Do we have a bz to track it? How engine-setup can upgrade from a non-scl to
a scl postgres setup? Who's going to handle it?


No bz yet.
This is work planned for 4.2 indeed, but will require work both on infra
and integration.


Following up from https://bugzilla.redhat.com/show_bug.cgi?id=1439518#c1
Do we have plans to split userportal/backend to their own containers at
some point?


-- 

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

Re: [ovirt-devel] oVirt in the new programming-journal

[Oved Ourfali]

Great to see that!
Kodus!

On Mon, Apr 3, 2017 at 4:19 PM, Arik Hadas  wrote:

> Hi everyone,
>
> I would like to share a paper that has just been published in the new
> programming-journal (that is called "The Art, Science, and Engineering of
> Programming") named "Language Oriented Modularity: From Theory to Practice"
> [1].
>
> The evaluation of the proposed approach for language-oriented modularity
> is done in part with oVirt (specifically, with the engine) and also
> the difficulty/inability to reuse a DSAL that was designed for one
> application in a different application is demonstrated with oVirt and
> muCommander [2].
>
> I hope you will find it interesting :)
>
> [1] http://programming-journal.org/2017/1/10/
> [2] https://github.com/mucommander
>
> Regards.
> Arik
>
> ___
> 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] Firewalld migration.

[Oved Ourfali]

On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgold...@redhat.com> wrote:

> Hey Oved,
>
> I don't think completely moving away from iptables is foreseeable at this
> point, but I could be of course wrong. Either way, upgrading still needs to
> be thought of.
>
>
I see.


> By stating that the current infrastructure is complex, I was referring to
> the entire chain of storing rules in the database, fetching them using a
> dedicated deployment class consisting of include/exclude logic, sending
> them over, unpacking, deploying...
>
> This procedure involves a lot of code that could be made redundant if the
> required logic is present in the host, which to me seems favorable. It of
> course entails other potential difficulties, primarily in the form of
> custom services.
>
> I don't think otopi's firewalld plugin is any more complex than the
> potential code that will have to be written in vdsm-tool, however it
> currently expects the data generated by aforementioned chain. The hybrid
> approach briefly touches on simplifying Engine's involvement while
> retaining use of otopi's plugin.
>
>
Okay. I think that writing a new plugin for firewalld is indeed a good
option, whether you "refactor" the engine side or not.


>
>
> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourf...@redhat.com> wrote:
>
>> top-posting:
>> You need to also consider how upgrade will be handled, right?
>> Or iptables will still remain supported?
>>
>> Also, see some comments inline.
>>
>> Regards,
>> Oved
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgold...@redhat.com>
>> wrote:
>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required
>>> rules (based on cluster/firewall configuration) to the deployment
>>> configuration, en route to being deployed on the host via otopi and its
>>> iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>>
>>
>> Can you elaborate?
>> I'm not an otopi expert, but I think that otopi plugins shouldn't be more
>> complex than what you describe in section #2, and the plugins were meant in
>> order to handle such cases.
>>
>> - Many of the required services are provided by firewalld. Rewriting them
>>> is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>>
>> So here you replace the otopi plugin with relevant vdsm-tool code, and
>> the question is why is that better?
>>
>>
>>> Pros:
>>>
>>>  - Engine side involvement is greatly diminished.
>>>  - Simple(r).
>>>
>>> Cons:
>>>
>>>  - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in
>>> the form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created
>>> services remains an open question. I think we'd like to avoid implementing
>>> logic that ask whether some service is provided (and then write it if it
>>> isn't...), and so choosing between the dynamic and static approaches is
>>> also needed. Using the static approach, guaranteeing *all* services are
>>> provided will be required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and
>>> we'll still have to use similar mechanism as described in #1 (service
>>> string -> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Oved Ourfali]

top-posting:
You need to also consider how upgrade will be handled, right?
Or iptables will still remain supported?

Also, see some comments inline.

Regards,
Oved

On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg  wrote:

>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
>

Can you elaborate?
I'm not an otopi expert, but I think that otopi plugins shouldn't be more
complex than what you describe in section #2, and the plugins were meant in
order to handle such cases.

- Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
>
So here you replace the otopi plugin with relevant vdsm-tool code, and the
question is why is that better?


> Pros:
>
>  - Engine side involvement is greatly diminished.
>  - Simple(r).
>
> Cons:
>
>  - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Introducing engine micro-benchmarks

[Oved Ourfali]

On Mar 23, 2017 12:16 PM, "Juan Hernández"  wrote:

On 03/23/2017 11:05 AM, Roy Golan wrote:
> Lately we came across an interesting case where multi-host+mult-networks
> resulted editing a host to conclude in minutes. One assumption that was
> raised which we wanted to eliminate was that the decryption we perform
> on a fence agent password might be taking too long.
>
> So these days it's an easy task thanks to JMH[1], supplied by the jdk
> itself. I kickstarted [2] and added a 'DecryptionBenchmark', see the
> output as an example[3]
>
> Although The JMH project recommends to create a separate project I find
> it would be less trivial to people to contribute benchmarks let alone
> just playing around with current code they want to test.
>
> - So, (when it will be merged) you add your benchmark under
>  backend/manager/modules/benchmarks/MyBenchmark.java
>
> - run it from intellij using the jmh plugin exactly like a unit-test
> OR
> - mvn test -P benchmarks -pl org.ovirt.engine:benchmarks
> OR
> - java -jar benchmarks.jar
>
> I hope this would serve all of us well, please review and add your
> benchmarks.
>
> PS - this will not run in the CI atm.
>
> [1] http://openjdk.java.net/projects/code-tools/jmh/
> [2] https://gerrit.ovirt.org/74537 microbenchmarks: Introduce
> microbenchmarks using JMH
> [3] DecryptionBenchmark output (short version):
>
> # Run complete. Total time: 00:09:06
>
> Benchmark Mode  SamplesScore  Score
error  Units
> b.DecryptionBenchmark.decryption thrpt   50  101.258
1.270  ops/s
> b.DecryptionBenchmark.encryption thrpt   50  238.587
4.667  ops/s
> b.DecryptionBenchmark.decryption  avgt   500.010
0.000   s/op
> b.DecryptionBenchmark.encryption  avgt   500.004
0.000   s/op
> b.DecryptionBenchmark.decryptionsample 55440.010
0.000   s/op
> b.DecryptionBenchmark.encryptionsample130670.004
0.000   s/op
> b.DecryptionBenchmark.decryptionss   500.014
0.001  s
> b.DecryptionBenchmark.encryptionss   500.009
0.001  s
>
> Process finished with exit code 0
>

Very interesting Roy, thanks.


Indeed!


What was the root cause of the host edit taking minutes?


No.
Juan - your original thought that the encrypt / decrypt are there due to
way too many queries was right. In the env there were around 1800 calls to
get all the hosts due to network checks that ran there.

We just wanted to check whether the encryption and decryption has any
impact in addition, and Roy looked into it and saw it doesn't impact much.


___
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] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]

[Oved Ourfali]

As Piotr mentioned, the job is using 1.3.8 however 1.3.9 was released.

On Sun, Mar 19, 2017 at 10:27 AM, Barak Korren  wrote:

>
>
> בתאריך 17 במרץ 2017 02:32 PM,‏ "Piotr Kliczewski" <
> piotr.kliczew...@gmail.com> כתב:
>
>
> The change was merged 2 weeks ago. How can we make sure not to waste
> people time next time to analyze the issue?
>
>
> "Merged" is hardly "released".
>
> As long as a fix does not make it to a release, users can still come
> across the issue, and so can OST. I can't think of a quick way to avoid
> that, but I'm open to suggestions
>
> WRT getting more frequent oVirt releases, I'm hardly in a position to give
> input about that.
>
>
>
>
> ___
> 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] Error in ovirt-engine installation

[Oved Ourfali]

CC-ing Vojtech and Greg.
Guys, can you please take a look?

On Mar 16, 2017 21:05, "shubham dubey"  wrote:

> Hello,
> I am trying to install ovirt-engine from almost 2 or 3 weeks in my fedora
> 25.
> But everytime I run this $ make install-dev PREFIX="$HOME/ovirt-engine"
>
> I got following error http://pastebin.com/cEfDJYix. I have tried to debug
> the problem lots of time but doesn't get succeeded. With little googling
> I might think that error is memory related but I have checked the memory
> usage and that looks normal.
> So,can anyone help to solve the problem?
>
> Thanks,
> Shubham
>
>
> ___
> 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] System tests for 4.1 currently failing to run VMs!

[Oved Ourfali]

If we make it mandatory then it should happen automatically in Jenkins.
If we rely on engineers to run it then it means they won't always do that.



On Thu, Dec 22, 2016 at 9:48 AM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 21 Dec 2016, at 20:52, Eyal Edri <ee...@redhat.com> wrote:
>
> Not as easy at it sounds,   the current flow of ost is much more
> complicated than just build artifacts. I'm not saving we won't do it,  but
> it won't be ready tomorrow and we designed lago exactly for being
> independent of any ci system so anyone can run it on their laptop.
>
>
> +1
> we just need to improve a little bit to make it possible for everyone.
> Almost there.
>
>  So maybe using Jenkins might be simpler but people shouldn't skip
> verification just because such a job doesn't exist yet.
>
> On Dec 21, 2016 9:02 PM, "Oved Ourfali" <oourf...@redhat.com> wrote:
>
>> Why not run it via Jenkins for patches?
>> Like, if you add a comment saying "run: ost" it will run it?
>>
>
> please don’t add more. Even the Rerun-hooks thing is hard to remember.
> Even after years I always keep asking is it "Re-run hooks” or “Rerun-Hooks”
> or “rerun hooks”, does case matter…..bleh
> Either add the button or maybe add it as a link in the automated comments
> (that would actually work good enough)
>
> Thanks,
> michal
>
> It do it automatically based on another thing?
>>
>> On Dec 21, 2016 17:42, "Eyal Edri" <ee...@redhat.com> wrote:
>> >
>> >
>> >
>> > On Wed, Dec 21, 2016 at 5:36 PM, Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>> >>
>> >>
>> >>> On 21 Dec 2016, at 16:25, Yaniv Kaul <yk...@redhat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Dec 21, 2016 at 5:19 PM, Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>> >>>>
>> >>>>
>> >>>>> On 21 Dec 2016, at 14:56, Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On 21 Dec 2016, at 12:19, Eyal Edri <ee...@redhat.com> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Dec 21, 2016 at 12:56 PM, Vinzenz Feenstra <
>> vfeen...@redhat.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Dec 21, 2016, at 11:17 AM, Barak Korren <bkor...@redhat.com>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> The test for running VMs had been failing since yesterday.
>> >>>>>>>>
>> >>>>>>>> The patch merged before the failures started was:
>> >>>>>>>> https://gerrit.ovirt.org/#/c/68826/
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> The error we`re seeing is a time-out (after two minutes) while
>> running
>> >>>>>>>> this API call:
>> >>>>>>>>
>> >>>>>>>> api.vms.get(VM0_NAME).status.state == ‘up'
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> This is a REST API call, the patch above is Frontend. So this is
>> unrelated.
>> >>>>>>>
>> >>>>>>> However on Host 0 I can see this:
>> >>>>>>>
>> >>>>>>> 2016-12-20 16:54:43,544 ERROR (vm/d299ab29) [virt.vm]
>> (vmId='d299ab29-284a-435c-a50f-183a6e54def2') The vm start process
>> failed (vm:615) Traceback (most recent call last): File
>> "/usr/share/vdsm/virt/vm.py", line 551, in _startUnderlyingVm self._run()
>> File "/usr/share/vdsm/virt/vm.py", line 1991, in _run
>> self._connection.createXML(domxml, flags), File
>> "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123,
>> in wrapper ret = f(*args, **kwargs) File 
>> "/usr/lib/python2.7/site-packages/vdsm/utils.py",
>> line 941, in wrapper return func(inst, *args, **kwargs) File
>> "/usr/lib64/python2.7/site-packages/libvirt.py", line 3782, in createXML
>> if ret is None:raise libvirtError('virDomainCreateXML() failed',
>> c

Re: [ovirt-devel] System tests for 4.1 currently failing to run VMs!

[Oved Ourfali]

Why not run it via Jenkins for patches?
Like, if you add a comment saying "run: ost" it will run it?
It do it automatically based on another thing?

On Dec 21, 2016 17:42, "Eyal Edri"  wrote:
>
>
>
> On Wed, Dec 21, 2016 at 5:36 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:
>>
>>
>>> On 21 Dec 2016, at 16:25, Yaniv Kaul  wrote:
>>>
>>>
>>>
>>> On Wed, Dec 21, 2016 at 5:19 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:


> On 21 Dec 2016, at 14:56, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:
>
>
>> On 21 Dec 2016, at 12:19, Eyal Edri  wrote:
>>
>>
>>
>> On Wed, Dec 21, 2016 at 12:56 PM, Vinzenz Feenstra <
vfeen...@redhat.com> wrote:
>>>
>>>
 On Dec 21, 2016, at 11:17 AM, Barak Korren 
wrote:

 The test for running VMs had been failing since yesterday.

 The patch merged before the failures started was:
 https://gerrit.ovirt.org/#/c/68826/
>>>
>>>
>>>
>>>

 The error we`re seeing is a time-out (after two minutes) while
running
 this API call:

 api.vms.get(VM0_NAME).status.state == ‘up'
>>>
>>>
>>> This is a REST API call, the patch above is Frontend. So this is
unrelated.
>>>
>>> However on Host 0 I can see this:
>>>
>>> 2016-12-20 16:54:43,544 ERROR (vm/d299ab29) [virt.vm]
(vmId='d299ab29-284a-435c-a50f-183a6e54def2') The vm start process failed
(vm:615) Traceback (most recent call last): File
"/usr/share/vdsm/virt/vm.py", line 551, in _startUnderlyingVm self._run()
File "/usr/share/vdsm/virt/vm.py", line 1991, in _run
self._connection.createXML(domxml, flags), File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in
wrapper ret = f(*args, **kwargs) File
"/usr/lib/python2.7/site-packages/vdsm/utils.py", line 941, in wrapper
return func(inst, *args, **kwargs) File
"/usr/lib64/python2.7/site-packages/libvirt.py", line 3782, in createXML if
ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor:
2016-12-20T21:54:43.044971Z qemu-kvm: warning: CPU(s) not present in any
NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 2016-12-20T21:54:43.045164Z
qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA
config 2016-12-20T21:54:43.101886Z qemu-kvm: -device
usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to
attach usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1"
(high speed)
>
>
> it is likely related to the recent USB patches
> investigating


 hm, there are multiple problems (features/bugs depending on prefferred
point of view:)
 but there is an easy “fix” taking care of this particular problem, so
we can start with that and figure out the proper approach later
 arik will push that and merge it soon, likely today
>>>
>>>
>>> Thanks - if there is a quicker way to resolve this by reverting, I
think it's a better option.
>>
>>
>> I really need to talk you out of this approach:-)
>> It does sound tempting and logical, but with our development model of
large patch series combined with late detection it really is quite risky.
Here it wouldn’t help much…and figuring out the right revert patch is more
complicated then fixing it.
>
>
> Can we start asking developers run OST before they merge so it will be
early detection and not late detection?
> We have video sessions on how to use OST, so it shouldn't be any issues
in running it on a patch.
>
>>
>> I believe the best is to identify it early and notify the maintainer who
merged that patch ASAP, as that person is in the best position to asses if
revert is safe or if there is a simple follow up patch he can push right
away
>>
>> We can surely improve on reporting, so Barak, how/why did you point to
that particular patch in your email? It should start failing on
16c2ec236184b3152f1df8e874b43115f78d0989 (CommitDate: Fri Dec 16 01:56:07
2016 -0500)
>> Even though it may be that it was hidden because
of c46f653a7846c3c2a76507b8dcf5bc0391ec5709 (CommitDate: Mon Dec 19
15:16:40 2016 -0500)
>>
>> (fix is ready, waiting on CI now)
>>
>> Thanks,
>> michal
>>
>>> Y.
>>>


>>> 2016-12-20 16:54:43,550 INFO (vm/d299ab29) [virt.vm]
(vmId='d299ab29-284a-435c-a50f-183a6e54def2') Changed state to Down:
internal error: process exited while connecting to monitor:
2016-12-20T21:54:43.044971Z qemu-kvm: warning: CPU(s) not present in any
NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 2016-12-20T21:54:43.045164Z
qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA
config 2016-12-20T21:54:43.101886Z qemu-kvm: -device
usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to
attach usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1"
(high speed) (code=1) 

Re: [ovirt-devel] [VDSM] Correct implementation of virt-sysprep job

[Oved Ourfali]

On Dec 7, 2016 20:24, "Michal Skrivanek" <mskri...@redhat.com> wrote:
>
>
>
> On 07 Dec 2016, at 09:17, Oved Ourfali <oourf...@redhat.com> wrote:
>
>>
>>
>> On Tue, Dec 6, 2016 at 11:12 PM, Adam Litke <ali...@redhat.com> wrote:
>>>
>>> On 06/12/16 22:06 +0200, Arik Hadas wrote:
>>>>
>>>> Adam,
>>>
>>>
>>> :)  You seem upset.  Sorry if I touched on a nerve...
>>>
>>>> Just out of curiosity: when you write "v2v has promised" - what
exactly do you
>>>> mean? the tool? Richard Jones (the maintainer of virt-v2v)? Shahar and
I that
>>>> implemented the integration with virt-v2v? I'm not aware of such a
promise by
>>>> any of these options :)
>>>
>>>
>>> Some history...
>>>
>>> Earlier this year Nir, Francesco (added), Shahar, and I began
>>> discussing the similarities between what storage needed to do with
>>> external commands and what was designed specifically for v2v.  I am
>>> not sure if you were involved in the project at that time.  The plan
>>> was to create common infrastructure that could be extended to fit the
>>> unique needs of the verticals.  The v2v code was going to be moved
>>> over to the new infrastructure (see [1]) and the only thing that
>>> stopped the initial patch was lack of a VMWare testing environment for
>>> verification.
>>>
>>> At that time storage refocused on developing verbs that used the new
>>> infrastructure and have been maintaining its suitability for general
>>> use.  Conversion of v2v -> Host Jobs is obviously a lower priority
>>> item and much more difficult now due to the early missed opportunity.
>>>
>>>> Anyway, let's say that you were given such a promise by someone and
thus
>>>> consider that mechanism to be deprecated - it doesn't really matter.
>>>
>>>
>>> I may be biased but I think my opinion does matter.
>>>
>>>> The current implementation doesn't well fit to this flow (it requires
>>>> per-volume job, it creates leases that are not needed for template's
disks,
>>>> ...) and with the "next-gen API" with proper support for virt flows
not even
>>>> being discussed with us (and iiuc also not with the infra team) yet, I
don't
>>>> understand what do you suggest except for some strong, though
irrelevant,
>>>> statements.
>>>
>>>
>>> If you are willing to engage in a good-faith technical discussion I am
>>> sure I can help you to understand.  These operations to storage demand
>>> some form of locking protection.  If volume leases aren't appropriate
then
>>> perhaps we should use the VM Leases / xleases that Nir is finishing
>>> off for 4.1 now.
>>>
>>>> I suggest loud and clear to reuse (not to add dependencies, not to
enhance, ..)
>>>> an existing mechanism for a very similar flow of virt-v2v that works
well and
>>>> simple.
>>>
>>>
>>> I clearly remember discussions involving infra (hello Oved), virt
>>> (hola Michal), and storage where we decided that new APIs performing
>>> async operations involving external commands should use the HostJobs
>>> infrastructure instead of adding more information to Host Stats.
>>> These were the "famous" entity polling meetings.
>>>
>>> Of course plans can change but I have never been looped into any such
>>> discussions.
>>>
>>
>> Well, I think that when someone builds a good infrastructure he first
needs to talk to all consumers and make sure it fits.
>> In this case it seems like most work was done to fit the storage
use-case, and now you check whether it can fit others as well
>>
>> IMO it makes much more sense to use events where possible (and you've
promised to use those as well, but I don't see you doing that...). v2v
should use events for sure, and they have promised to do that in the past,
instead of using the v2v jobs. The reason events weren't used originally
with the v2v feature, was that it was too risky and the events
infrastructure was added too late in the game.
>
>
> Revisiting and refactoring code which is already in use is always a bit
of luxury we can rarely prioritize. So indeed v2v is not using events. The
generalization work has been done to some extent, but there is no incentive
to rewrite it completely.
> On the other hand we are now trying to add events to migration progress
reporting and hand over since that area is being touched due to 

Re: [ovirt-devel] [VDSM] Correct implementation of virt-sysprep job

[Oved Ourfali]

On Dec 7, 2016 20:16, "Nir Soffer" <nsof...@redhat.com> wrote:
>
> On Wed, Dec 7, 2016 at 8:10 PM, Oved Ourfali <oourf...@redhat.com> wrote:
> > On Dec 7, 2016 16:00, "Nir Soffer" <nsof...@redhat.com> wrote:
> >>
> >> On Wed, Dec 7, 2016 at 10:17 AM, Oved Ourfali <oourf...@redhat.com>
wrote:
> >> >
> >> >
> >> > On Tue, Dec 6, 2016 at 11:12 PM, Adam Litke <ali...@redhat.com>
wrote:
> >> >>
> >> >> On 06/12/16 22:06 +0200, Arik Hadas wrote:
> >> >>>
> >> >>> Adam,
> >> >>
> >> >>
> >> >> :)  You seem upset.  Sorry if I touched on a nerve...
> >> >>
> >> >>> Just out of curiosity: when you write "v2v has promised" - what
> >> >>> exactly
> >> >>> do you
> >> >>> mean? the tool? Richard Jones (the maintainer of virt-v2v)? Shahar
and
> >> >>> I
> >> >>> that
> >> >>> implemented the integration with virt-v2v? I'm not aware of such a
> >> >>> promise by
> >> >>> any of these options :)
> >> >>
> >> >>
> >> >> Some history...
> >> >>
> >> >> Earlier this year Nir, Francesco (added), Shahar, and I began
> >> >> discussing the similarities between what storage needed to do with
> >> >> external commands and what was designed specifically for v2v.  I am
> >> >> not sure if you were involved in the project at that time.  The plan
> >> >> was to create common infrastructure that could be extended to fit
the
> >> >> unique needs of the verticals.  The v2v code was going to be moved
> >> >> over to the new infrastructure (see [1]) and the only thing that
> >> >> stopped the initial patch was lack of a VMWare testing environment
for
> >> >> verification.
> >> >>
> >> >> At that time storage refocused on developing verbs that used the new
> >> >> infrastructure and have been maintaining its suitability for general
> >> >> use.  Conversion of v2v -> Host Jobs is obviously a lower priority
> >> >> item and much more difficult now due to the early missed
opportunity.
> >> >>
> >> >>> Anyway, let's say that you were given such a promise by someone and
> >> >>> thus
> >> >>> consider that mechanism to be deprecated - it doesn't really
matter.
> >> >>
> >> >>
> >> >> I may be biased but I think my opinion does matter.
> >> >>
> >> >>> The current implementation doesn't well fit to this flow (it
requires
> >> >>> per-volume job, it creates leases that are not needed for
template's
> >> >>> disks,
> >> >>> ...) and with the "next-gen API" with proper support for virt flows
> >> >>> not
> >> >>> even
> >> >>> being discussed with us (and iiuc also not with the infra team)
yet, I
> >> >>> don't
> >> >>> understand what do you suggest except for some strong, though
> >> >>> irrelevant,
> >> >>> statements.
> >> >>
> >> >>
> >> >> If you are willing to engage in a good-faith technical discussion I
am
> >> >> sure I can help you to understand.  These operations to storage
demand
> >> >> some form of locking protection.  If volume leases aren't
appropriate
> >> >> then
> >> >> perhaps we should use the VM Leases / xleases that Nir is finishing
> >> >> off for 4.1 now.
> >> >>
> >> >>> I suggest loud and clear to reuse (not to add dependencies, not to
> >> >>> enhance, ..)
> >> >>> an existing mechanism for a very similar flow of virt-v2v that
works
> >> >>> well
> >> >>> and
> >> >>> simple.
> >> >>
> >> >>
> >> >> I clearly remember discussions involving infra (hello Oved), virt
> >> >> (hola Michal), and storage where we decided that new APIs performing
> >> >> async operations involving external commands should use the HostJobs
> >> >> infrastructure instead of adding more information to Host Stats.
> >> >> These were the "famous" entity polling meetings.
> >&

Re: [ovirt-devel] The engine build job you probably didn't know exists

[Oved Ourfali]

Cool job indeed!

On Dec 7, 2016 16:40, "Eyal Edri"  wrote:

> FYI,
>
> After hearing that this might be useful to many developers, I wanted to
> bring to your attention the ovirt-engine master build job from patch [1]
> which allows you to build new rpms from an open ovirt-engine patch on
> Gerrit.
>
> Its was created as temp job for a team who needed it a few months ago, but
> seems it might useful for other teams as well, so we decided to publish it
> even though its not standardized yet as part of our standard CI system.
>
> I hope you can find it useful for your teams.
>
>
> [1] http://jenkins.ovirt.org/job/ovirt-engine_master_build-
> artifacts-el7-x86_64_build_from_patch/
>
> --
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Correct implementation of virt-sysprep job

[Oved Ourfali]

On Dec 7, 2016 16:00, "Nir Soffer" <nsof...@redhat.com> wrote:
>
> On Wed, Dec 7, 2016 at 10:17 AM, Oved Ourfali <oourf...@redhat.com> wrote:
> >
> >
> > On Tue, Dec 6, 2016 at 11:12 PM, Adam Litke <ali...@redhat.com> wrote:
> >>
> >> On 06/12/16 22:06 +0200, Arik Hadas wrote:
> >>>
> >>> Adam,
> >>
> >>
> >> :)  You seem upset.  Sorry if I touched on a nerve...
> >>
> >>> Just out of curiosity: when you write "v2v has promised" - what
exactly
> >>> do you
> >>> mean? the tool? Richard Jones (the maintainer of virt-v2v)? Shahar
and I
> >>> that
> >>> implemented the integration with virt-v2v? I'm not aware of such a
> >>> promise by
> >>> any of these options :)
> >>
> >>
> >> Some history...
> >>
> >> Earlier this year Nir, Francesco (added), Shahar, and I began
> >> discussing the similarities between what storage needed to do with
> >> external commands and what was designed specifically for v2v.  I am
> >> not sure if you were involved in the project at that time.  The plan
> >> was to create common infrastructure that could be extended to fit the
> >> unique needs of the verticals.  The v2v code was going to be moved
> >> over to the new infrastructure (see [1]) and the only thing that
> >> stopped the initial patch was lack of a VMWare testing environment for
> >> verification.
> >>
> >> At that time storage refocused on developing verbs that used the new
> >> infrastructure and have been maintaining its suitability for general
> >> use.  Conversion of v2v -> Host Jobs is obviously a lower priority
> >> item and much more difficult now due to the early missed opportunity.
> >>
> >>> Anyway, let's say that you were given such a promise by someone and
thus
> >>> consider that mechanism to be deprecated - it doesn't really matter.
> >>
> >>
> >> I may be biased but I think my opinion does matter.
> >>
> >>> The current implementation doesn't well fit to this flow (it requires
> >>> per-volume job, it creates leases that are not needed for template's
> >>> disks,
> >>> ...) and with the "next-gen API" with proper support for virt flows
not
> >>> even
> >>> being discussed with us (and iiuc also not with the infra team) yet, I
> >>> don't
> >>> understand what do you suggest except for some strong, though
irrelevant,
> >>> statements.
> >>
> >>
> >> If you are willing to engage in a good-faith technical discussion I am
> >> sure I can help you to understand.  These operations to storage demand
> >> some form of locking protection.  If volume leases aren't appropriate
then
> >> perhaps we should use the VM Leases / xleases that Nir is finishing
> >> off for 4.1 now.
> >>
> >>> I suggest loud and clear to reuse (not to add dependencies, not to
> >>> enhance, ..)
> >>> an existing mechanism for a very similar flow of virt-v2v that works
well
> >>> and
> >>> simple.
> >>
> >>
> >> I clearly remember discussions involving infra (hello Oved), virt
> >> (hola Michal), and storage where we decided that new APIs performing
> >> async operations involving external commands should use the HostJobs
> >> infrastructure instead of adding more information to Host Stats.
> >> These were the "famous" entity polling meetings.
>
> We discussed these issues behind close doors, not in the public mailing
list,
> so it is not surprising that people do not know about the agreements we
had.
>

The core team was there. So it is surprising.

> >>
> >> Of course plans can change but I have never been looped into any such
> >> discussions.
> >>
> >
> > Well, I think that when someone builds a good infrastructure he first
needs
> > to talk to all consumers and make sure it fits.
> > In this case it seems like most work was done to fit the storage
use-case,
> > and now you check whether it can fit others as well
>
> The jobs framework is generic and can be used for any subsystem,
> there is nothing related to storage about it. But modifying disks *is*
> a storage operation, even if someone from the virt team worked on it.
>
> V2v is also storage operation - if we compare it with copying disks:
>
> - we create a new volume that nobody is using yet
>

Re: [ovirt-devel] [VDSM] Correct implementation of virt-sysprep job

[Oved Ourfali]

On Tue, Dec 6, 2016 at 11:12 PM, Adam Litke  wrote:

> On 06/12/16 22:06 +0200, Arik Hadas wrote:
>
>> Adam,
>>
>
> :)  You seem upset.  Sorry if I touched on a nerve...
>
> Just out of curiosity: when you write "v2v has promised" - what exactly do
>> you
>> mean? the tool? Richard Jones (the maintainer of virt-v2v)? Shahar and I
>> that
>> implemented the integration with virt-v2v? I'm not aware of such a
>> promise by
>> any of these options :)
>>
>
> Some history...
>
> Earlier this year Nir, Francesco (added), Shahar, and I began
> discussing the similarities between what storage needed to do with
> external commands and what was designed specifically for v2v.  I am
> not sure if you were involved in the project at that time.  The plan
> was to create common infrastructure that could be extended to fit the
> unique needs of the verticals.  The v2v code was going to be moved
> over to the new infrastructure (see [1]) and the only thing that
> stopped the initial patch was lack of a VMWare testing environment for
> verification.
>
> At that time storage refocused on developing verbs that used the new
> infrastructure and have been maintaining its suitability for general
> use.  Conversion of v2v -> Host Jobs is obviously a lower priority
> item and much more difficult now due to the early missed opportunity.
>
> Anyway, let's say that you were given such a promise by someone and thus
>> consider that mechanism to be deprecated - it doesn't really matter.
>>
>
> I may be biased but I think my opinion does matter.
>
> The current implementation doesn't well fit to this flow (it requires
>> per-volume job, it creates leases that are not needed for template's
>> disks,
>> ...) and with the "next-gen API" with proper support for virt flows not
>> even
>> being discussed with us (and iiuc also not with the infra team) yet, I
>> don't
>> understand what do you suggest except for some strong, though irrelevant,
>> statements.
>>
>
> If you are willing to engage in a good-faith technical discussion I am
> sure I can help you to understand.  These operations to storage demand
> some form of locking protection.  If volume leases aren't appropriate then
> perhaps we should use the VM Leases / xleases that Nir is finishing
> off for 4.1 now.
>
> I suggest loud and clear to reuse (not to add dependencies, not to
>> enhance, ..)
>> an existing mechanism for a very similar flow of virt-v2v that works well
>> and
>> simple.
>>
>
> I clearly remember discussions involving infra (hello Oved), virt
> (hola Michal), and storage where we decided that new APIs performing
> async operations involving external commands should use the HostJobs
> infrastructure instead of adding more information to Host Stats.
> These were the "famous" entity polling meetings.
>
> Of course plans can change but I have never been looped into any such
> discussions.
>
>
Well, I think that when someone builds a good infrastructure he first needs
to talk to all consumers and make sure it fits.
In this case it seems like most work was done to fit the storage use-case,
and now you check whether it can fit others as well

IMO it makes much more sense to use events where possible (and you've
promised to use those as well, but I don't see you doing that...). v2v
should use events for sure, and they have promised to do that in the past,
instead of using the v2v jobs. The reason events weren't used originally
with the v2v feature, was that it was too risky and the events
infrastructure was added too late in the game.



> Do you "promise" to implement your "next gen API" for 4.1 as an
>> alternative?
>>
>
> I guess we need the design first.
>
>
> On Tue, Dec 6, 2016 at 5:04 PM, Adam Litke  wrote:
>>
>>On 05/12/16 11:17 +0200, Arik Hadas wrote:
>>
>>
>>
>>On Mon, Dec 5, 2016 at 10:05 AM, Nir Soffer 
>> wrote:
>>
>>   On Sun, Dec 4, 2016 at 8:50 PM, Shmuel Melamud <
>> smela...@redhat.com>
>>wrote:
>>   >
>>   > Hi!
>>   >
>>   > I'm currently working on integration of virt-sysprep into
>> oVirt.
>>   >
>>   > Usually, if user creates a template from a regular VM, and
>> then
>>creates
>>   new VMs from this template, these new VMs inherit all
>> configuration
>>of the
>>   original VM, including SSH keys, UDEV rules, MAC addresses,
>> system
>>ID,
>>   hostname etc. It is unfortunate, because you cannot have two
>> network
>>   devices with the same MAC address in the same network, for
>> example.
>>   >
>>   > To avoid this, user must clean all machine-specific
>> configuration
>>from
>>   the original VM before creating a template from it. You can do
>> this
>>   manually, but there is virt-sysprep utility that does this
>>automatically.
>>   >
>>   > Ideally, virt-sysprep should be seamlessly 

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] Where's MOM (on latest master)

[Oved Ourfali]

I don't think it is related to version X or Y. It is a race, so might be
related to other factors.

On Nov 18, 2016 12:59 PM, "Martin Sivak" <msi...@redhat.com> wrote:

> > Are we / can we use systemd socket activation there?
>
> That actually requires systemd specific code iirc (to take over the
> standing by socket). I am actually wondering why the xml-rpc in 4.0.4
> was fine and json-rpc in 4.0.6 is too slow.
>
> Martin
>
> On Fri, Nov 18, 2016 at 11:53 AM, Anton Marchukov <amarc...@redhat.com>
> wrote:
> > Hello All.
> >
> > Are we / can we use systemd socket activation there?
> >
> > Anton.
> >
> > On Fri, Nov 18, 2016 at 11:21 AM, Martin Sivak <msi...@redhat.com>
> wrote:
> >>
> >> What about making vdsm ready to answer connections when it returns to
> >> systemd instead? I hate workarounds and this always worked fine.
> >>
> >> Martin
> >>
> >> On Fri, Nov 18, 2016 at 11:13 AM, Oved Ourfali <oourf...@redhat.com>
> >> wrote:
> >> > Seems like a race regardless of the protocol.
> >> > Should you add a retry?
> >> >
> >> >
> >> > On Nov 18, 2016 11:52 AM, "Martin Sivak" <msi...@redhat.com> wrote:
> >> >>
> >> >> Yes, because VDSM is supposed to be up (there is systemd dependency).
> >> >> This always worked fine with xml-rpc.
> >> >>
> >> >> Martin
> >> >>
> >> >> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer <nsof...@redhat.com>
> >> >> wrote:
> >> >> > On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak <msi...@redhat.com>
> >> >> > wrote:
> >> >> >> This happens because MOM can't connect to VDSM and so it quits.
> >> >> >
> >> >> > So mom try once to connect and if the connection fails it quits?
> >> >> >
> >> >> >> We
> >> >> >> discussed it on the mailinglist
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> https://lists.fedoraproject.org/archives/list/vdsm-devel@
> lists.fedorahosted.org/thread/MZ7UJUWO5KFRDJJDNXX7VIYU5PWSXF62/
> >> >> >> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html
> >> >> >>
> >> >> >> This issue never happened with XML-RPC.
> >> >> >>
> >> >> >> Shira reported it as
> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1393012
> >> >> >>
> >> >> >> Martin
> >> >> >>
> >> >> >> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul <yk...@redhat.com>
> >> >> >> wrote:
> >> >> >>> I've recently seen, including now on Master, the following
> >> >> >>> warnings:
> >> >> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started
> >> >> >>> MOM
> >> >> >>> instance configured for VDSM purposes.
> >> >> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]:
> Starting
> >> >> >>> MOM
> >> >> >>> instance configured for VDSM purposes...
> >> >> >>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available, Policy could not be set.
> >> >> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available.
> >> >> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available, KSM stats will be missing.
> >> >> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available.
> >> >> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available, KSM stats will be missing.
> >> >> >>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm
> MOM
> >> >> >>> WARN MOM
> >> >> >>> not available.

Re: [ovirt-devel] Where's MOM (on latest master)

[Oved Ourfali]

Discuss it with the infra guys and I'm sure you'll get the reasons, and
will figure out a solution together.

On Nov 18, 2016 12:21 PM, "Martin Sivak" <msi...@redhat.com> wrote:

> What about making vdsm ready to answer connections when it returns to
> systemd instead? I hate workarounds and this always worked fine.
>
> Martin
>
> On Fri, Nov 18, 2016 at 11:13 AM, Oved Ourfali <oourf...@redhat.com>
> wrote:
> > Seems like a race regardless of the protocol.
> > Should you add a retry?
> >
> >
> > On Nov 18, 2016 11:52 AM, "Martin Sivak" <msi...@redhat.com> wrote:
> >>
> >> Yes, because VDSM is supposed to be up (there is systemd dependency).
> >> This always worked fine with xml-rpc.
> >>
> >> Martin
> >>
> >> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer <nsof...@redhat.com>
> wrote:
> >> > On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak <msi...@redhat.com>
> >> > wrote:
> >> >> This happens because MOM can't connect to VDSM and so it quits.
> >> >
> >> > So mom try once to connect and if the connection fails it quits?
> >> >
> >> >> We
> >> >> discussed it on the mailinglist
> >> >>
> >> >>
> >> >> https://lists.fedoraproject.org/archives/list/vdsm-devel@
> lists.fedorahosted.org/thread/MZ7UJUWO5KFRDJJDNXX7VIYU5PWSXF62/
> >> >> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html
> >> >>
> >> >> This issue never happened with XML-RPC.
> >> >>
> >> >> Shira reported it as
> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1393012
> >> >>
> >> >> Martin
> >> >>
> >> >> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul <yk...@redhat.com>
> wrote:
> >> >>> I've recently seen, including now on Master, the following warnings:
> >> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started
> MOM
> >> >>> instance configured for VDSM purposes.
> >> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Starting
> MOM
> >> >>> instance configured for VDSM purposes...
> >> >>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, Policy could not be set.
> >> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available, KSM stats will be missing.
> >> >>> Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> >> >>> WARN MOM
> >> >>> not available.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Any ideas what this is and why?
> >> >>>
> >> >>> ___
> >> >>> 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] Where's MOM (on latest master)

[Oved Ourfali]

Seems like a race regardless of the protocol.
Should you add a retry?

On Nov 18, 2016 11:52 AM, "Martin Sivak"  wrote:

> Yes, because VDSM is supposed to be up (there is systemd dependency).
> This always worked fine with xml-rpc.
>
> Martin
>
> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer  wrote:
> > On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak 
> wrote:
> >> This happens because MOM can't connect to VDSM and so it quits.
> >
> > So mom try once to connect and if the connection fails it quits?
> >
> >> We
> >> discussed it on the mailinglist
> >>
> >> https://lists.fedoraproject.org/archives/list/vdsm-devel@
> lists.fedorahosted.org/thread/MZ7UJUWO5KFRDJJDNXX7VIYU5PWSXF62/
> >> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html
> >>
> >> This issue never happened with XML-RPC.
> >>
> >> Shira reported it as https://bugzilla.redhat.com/
> show_bug.cgi?id=1393012
> >>
> >> Martin
> >>
> >> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul  wrote:
> >>> I've recently seen, including now on Master, the following warnings:
> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started MOM
> >>> instance configured for VDSM purposes.
> >>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Starting MOM
> >>> instance configured for VDSM purposes...
> >>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, Policy could not be set.
> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available, KSM stats will be missing.
> >>> Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM
> WARN MOM
> >>> not available.
> >>>
> >>>
> >>>
> >>> Any ideas what this is and why?
> >>>
> >>> ___
> >>> 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] Project Proposal - Vagrant provider

[Oved Ourfali]

Thanks for the proposal.
We're excited to add Vagrant into oVirt's portfolio of SDKs and
modules/providers!
Starting with the v4 ruby SDK makes sense to me.
CC-in some relevant guys to share their thoughts.

Thanks!
Oved


On Sun, Oct 9, 2016 at 6:03 PM, Marc Young <3vilpeng...@gmail.com> wrote:

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

Re: [ovirt-devel] Master ovirt-engine build broken

[Oved Ourfali]

On Wed, May 4, 2016 at 3:24 PM, Vojtech Szocs <vsz...@redhat.com> wrote:

>
>
> - Original Message -
> > From: "Vojtech Szocs" <vsz...@redhat.com>
> > To: "Oved Ourfali" <oourf...@redhat.com>, "David Caro" <
> dcaro...@redhat.com>
> > Cc: "devel" <devel@ovirt.org>
> > Sent: Wednesday, May 4, 2016 2:19:09 PM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> >
> >
> >
> > - Original Message -
> > > From: "Oved Ourfali" <oourf...@redhat.com>
> > > To: "Vojtech Szocs" <vsz...@redhat.com>
> > > Cc: "Marek Libra" <mli...@redhat.com>, "devel" <devel@ovirt.org>
> > > Sent: Wednesday, May 4, 2016 2:07:19 PM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > > Okay.
> > > Makes sense.
> > > Thanks Vojtech - please also revert this one.
> >
> > Trying to revert master patch https://gerrit.ovirt.org/#/c/56720/
> > gives me "500 Internal server error" -- am I missing something?
> >
> > Perhaps oVirt gerrit maintainers can advise here? (adding David)
>
> Sorry for the noise, I did it manually with git revert:
>
>   https://gerrit.ovirt.org/#/c/57031/
>
> Can someone please ack?
>

done.


>
> >
> > >
> > > Oved
> > >
> > > On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs <vsz...@redhat.com>
> wrote:
> > >
> > > > (top-posting)
> > > >
> > > > Hi,
> > > >
> > > > root cause is wrong number of message parameters (placeholders)
> > > > in translated properties files, compared to message definitions
> > > > in Java code.
> > > >
> > > > For example, UIMessages#cpuInfoLabel method has 4 parameters,
> > > > but the corresponding message in `UIMessages_de_DE.properties`
> > > > only contains 3 placeholders.
> > > >
> > > > 4.0 String Freeze is May 25 so it's still OK to modify message
> > > > definitions in Java code.
> > > >
> > > > I suggest to simply revert the offending patch:
> > > >
> > > >   translations update from zanata ovirt-3.6
> > > >   https://gerrit.ovirt.org/#/c/56720/
> > > >
> > > > and create new one which doesn't introduce conflicts.
> > > >
> > > > We have unit tests to detect these kinds of errors, this is
> > > > to ensure the build fails early on (before GWT compilation).
> > > >
> > > > I'm not sure why `check-patch` job for above mentioned patch
> > > > didn't report the problem, since UIMessagesTest should fail,
> > > > as Roman wrote below.
> > > >
> > > > Regards,
> > > > Vojtech
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Marek Libra" <mli...@redhat.com>
> > > > > To: "devel" <devel@ovirt.org>
> > > > > Sent: Wednesday, May 4, 2016 12:31:18 PM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > There are issues on other keys as well.
> > > > > I'm rebuilding for all locales locally now.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: "Marek Libra" <mli...@redhat.com>
> > > > > To: "devel" <devel@ovirt.org>
> > > > > Sent: Wednesday, May 4, 2016 11:29:55 AM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > The fix is here: https://gerrit.ovirt.org/#/c/57007/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: "Roman Mohr" <rm...@redhat.com>
> > > > > To: "Oved Ourfali" <oourf...@redhat.com>
> > > > > Cc: "devel" <devel@ovirt.org>
> > > > > Sent: Wednesday, May 4, 2016 10:27:51 AM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > >
> > > > >
> > > > > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali <
> oourf...@redhat.com >
> > > > wrote:
> > > > >
> > > > >
> > >

Re: [ovirt-devel] Master ovirt-engine build broken

[Oved Ourfali]

Okay.
Makes sense.
Thanks Vojtech - please also revert this one.

Oved

On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs <vsz...@redhat.com> wrote:

> (top-posting)
>
> Hi,
>
> root cause is wrong number of message parameters (placeholders)
> in translated properties files, compared to message definitions
> in Java code.
>
> For example, UIMessages#cpuInfoLabel method has 4 parameters,
> but the corresponding message in `UIMessages_de_DE.properties`
> only contains 3 placeholders.
>
> 4.0 String Freeze is May 25 so it's still OK to modify message
> definitions in Java code.
>
> I suggest to simply revert the offending patch:
>
>   translations update from zanata ovirt-3.6
>   https://gerrit.ovirt.org/#/c/56720/
>
> and create new one which doesn't introduce conflicts.
>
> We have unit tests to detect these kinds of errors, this is
> to ensure the build fails early on (before GWT compilation).
>
> I'm not sure why `check-patch` job for above mentioned patch
> didn't report the problem, since UIMessagesTest should fail,
> as Roman wrote below.
>
> Regards,
> Vojtech
>
>
> - Original Message -
> > From: "Marek Libra" <mli...@redhat.com>
> > To: "devel" <devel@ovirt.org>
> > Sent: Wednesday, May 4, 2016 12:31:18 PM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> >
> > There are issues on other keys as well.
> > I'm rebuilding for all locales locally now.
> >
> >
> >
> >
> >
> > From: "Marek Libra" <mli...@redhat.com>
> > To: "devel" <devel@ovirt.org>
> > Sent: Wednesday, May 4, 2016 11:29:55 AM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> >
> > The fix is here: https://gerrit.ovirt.org/#/c/57007/
> >
> >
> >
> >
> > From: "Roman Mohr" <rm...@redhat.com>
> > To: "Oved Ourfali" <oourf...@redhat.com>
> > Cc: "devel" <devel@ovirt.org>
> > Sent: Wednesday, May 4, 2016 10:27:51 AM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> >
> >
> >
> > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com >
> wrote:
> >
> >
> >
> > Roman - did you build the langs in order to find the issue?
> >
> > I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not
> all
> > of my builds showed that error.
> >
> > Looking at
> >
> >
> https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration
> >
> > two patches passed and two failed after a topic rebase.
> >
> >
> >
> > Eyal - can we monitor a list of files that i changed will result in also
> > building all the languages?
> >
> >
> >
> >
> >
> >
> > On Wed, May 4, 2016 at 11:22 AM, Eyal Edri < ee...@redhat.com > wrote:
> >
> >
> >
> > right, and we can't enable lang permutation since it takes a very long
> time
> > to run.
> >
> > On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek < tjeli...@redhat.com >
> wrote:
> >
> >
> >
> >
> > - Original Message -
> > > From: "Oved Ourfali" < oourf...@redhat.com >
> > > To: "Tomas Jelinek" < tjeli...@redhat.com >
> > > Cc: "Roman Mohr" < rm...@redhat.com >, "devel" < devel@ovirt.org >,
> "Scott
> > > Dickerson" < sdick...@redhat.com >
> > > Sent: Wednesday, May 4, 2016 9:55:40 AM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > > I wonder, how come the CI didn't catch that?
> >
> > because this happens only when you compile with language permutations
> >
> > >
> > > On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek < tjeli...@redhat.com >
> > > wrote:
> > >
> > > > hmmm,
> > > > regression introduced yesterday by
> https://gerrit.ovirt.org/#/c/56720/
> > > > fix on the way
> > > >
> > > > - Original Message -
> > > > > From: "Roman Mohr" < rm...@redhat.com >
> > > > > To: "devel" < devel@ovirt.org >
> > > > > Sent: Wednesday, May 4, 2016 9:34:53 AM
> > > > > Subject: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > Hi,
> > > > >
> > > > > I see failing tests regarding to missing translations

Re: [ovirt-devel] Master ovirt-engine build broken

[Oved Ourfali]

Roman - did you build the langs in order to find the issue?
Eyal - can we monitor a list of files that i changed will result in also
building all the languages?


On Wed, May 4, 2016 at 11:22 AM, Eyal Edri <ee...@redhat.com> wrote:

> right, and we can't enable lang permutation since it takes a very long
> time to run.
>
> On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek <tjeli...@redhat.com>
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Oved Ourfali" <oourf...@redhat.com>
>> > To: "Tomas Jelinek" <tjeli...@redhat.com>
>> > Cc: "Roman Mohr" <rm...@redhat.com>, "devel" <devel@ovirt.org>, "Scott
>> Dickerson" <sdick...@redhat.com>
>> > Sent: Wednesday, May 4, 2016 9:55:40 AM
>> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
>> >
>> > I wonder, how come the CI didn't catch that?
>>
>> because this happens only when you compile with language permutations
>>
>> >
>> > On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek <tjeli...@redhat.com>
>> wrote:
>> >
>> > > hmmm,
>> > > regression introduced yesterday by
>> https://gerrit.ovirt.org/#/c/56720/
>> > > fix on the way
>> > >
>> > > - Original Message -
>> > > > From: "Roman Mohr" <rm...@redhat.com>
>> > > > To: "devel" <devel@ovirt.org>
>> > > > Sent: Wednesday, May 4, 2016 9:34:53 AM
>> > > > Subject: [ovirt-devel] Master ovirt-engine build broken
>> > > >
>> > > > Hi,
>> > > >
>> > > > I see failing tests regarding to missing translations (e.g. [1]).
>> > > >
>> > > > [...]
>> > > >
>> > > > Failed tests:   doTest(org.ovirt.engine.ui.uicompat.UIMessagesTest):
>> > > > cpuInfoLabel does not match the number of parameters in
>> > > > UIMessages_zh_CN.properties(..)
>> > > >
>> > > > [...]
>> > > >
>> > > > Best Regards,
>> > > >
>> > > > Roman
>> > > >
>> > > > [1]
>> > > >
>> > >
>> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc23-x86_64/407/console
>> > > >
>> > > > ___
>> > > > 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
>>
>>
>>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV 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] Master ovirt-engine build broken

[Oved Ourfali]

I wonder, how come the CI didn't catch that?

On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek  wrote:

> hmmm,
> regression introduced yesterday by https://gerrit.ovirt.org/#/c/56720/
> fix on the way
>
> - Original Message -
> > From: "Roman Mohr" 
> > To: "devel" 
> > Sent: Wednesday, May 4, 2016 9:34:53 AM
> > Subject: [ovirt-devel] Master ovirt-engine build broken
> >
> > Hi,
> >
> > I see failing tests regarding to missing translations (e.g. [1]).
> >
> > [...]
> >
> > Failed tests:   doTest(org.ovirt.engine.ui.uicompat.UIMessagesTest):
> > cpuInfoLabel does not match the number of parameters in
> > UIMessages_zh_CN.properties(..)
> >
> > [...]
> >
> > Best Regards,
> >
> > Roman
> >
> > [1]
> >
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc23-x86_64/407/console
> >
> > ___
> > 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] Permission issues when trying to migrate vm through the api (ovirt system tests)

[Oved Ourfali]

On Mon, Apr 18, 2016 at 2:51 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 18 Apr 2016, at 12:47, Yaniv Kaul  wrote:
>
>
>
> On Mon, Apr 18, 2016 at 1:32 PM, David Caro  wrote:
>
>>
>> Hi everyone!
>>
>>
>> I'm having some issues when trying to run the ovirt system tests from
>> ovirt
>> master branch, and I need some help from you guys.
>>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1328011
>
>
> great, lago caught a regression!
>

In the past it caught many regressions also in 3.6 :-)


> patch will be posted soon
>
> Y.
>
>
>>
>> The issue is that when trying to migrate a vm through the api, I get the
>> error:
>>
>>   RequestError:
>>   status: 400
>>   reason: Bad Request
>>   detail: User is not authorized to perform this action.
>>
>>
>> That does not happen when doing the same through the ui, the vm is
>> migrated
>> correctly.
>>
>> The engine logs don't add much more details:
>>
>> 2016-04-18 06:04:15,393 INFO
>> [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-15)
>> [29237280] No permission found for user
>> '001a-001a-001a-001a-02dd' or one of the groups he is member
>> of, when running action 'MigrateVmToServer', Required permissions are:
>> Action type: 'USER' Action group: 'CREATE_VM' Object type: 'Cluster'
>> Object ID: 'null'.
>> 2016-04-18 06:04:15,393 WARN
>> [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-15)
>> [29237280] Validation of action 'MigrateVmToServer' failed for user
>> admin@internal-authz. Reasons:
>> VAR__ACTION__MIGRATE,VAR__TYPE__VM,USER_NOT_AUTHORIZED_TO_PERFORM_ACTION
>> 2016-04-18 06:04:15,413 ERROR
>> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
>> task-15) [] Operation Failed: [User is not authorized to perform this
>> action.]
>>
>>
>> Something that looks odd to me too, is that in the roles, when you edit
>> the
>> 'SuperUser' role (the one the admin user belongs to) there there's one
>> permission missing, the 'VM->Provisioning Operations->Create Instance',
>> and
>> can't be added (it's greyed out), not sure if it's related though, I can
>> pass
>> you a screenshot if you want.
>>
>>
>> I can give you access to an environment where that happens and more
>> details/logs/etc if you want to look deeper into it.
>>
>>
>> Thanks!
>>
>>
>> --
>> David Caro
>>
>> Red Hat S.L.
>> Continuous Integration Engineer - EMEA ENG Virtualization R
>>
>> Tel.: +420 532 294 605
>> Email: dc...@redhat.com
>> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
>> Web: www.redhat.com
>> RHT Global #: 82-62605
>>
>
> ___
> 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] Workaround for Gerrit 'Internal Server Error' after deleting draft

[Oved Ourfali]

Did you also report that bug for the Gerrit guys to fix?
On Mar 28, 2016 17:04, "Tomer Saban"  wrote:

> Hi,
>
> I came across a bug in Gerrit when trying to delete a draft. It seems that
> it ruins
> the patchset(Gerrit doens't set the new last revision properly).
> So, in order to fix this issue we need to reset the last revision.
>
> In order, to do that you need to find the last revision after deleting the
> draft(Let's assume it's 23).
> Once, you have that you need to number of the patch in gerrit. For
> example, the number in:
> https://gerrit.ovirt.org/#/c/51636/ is 51636.
>
> Last, You need to run the following line from the shell:
> ssh gerrit.ovirt.org gerrit review --rebase 51636,23
>
> FYI,
> Tomer
>
> ___
> 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] Allow access to Cockpit by default after adding a host? Or make it configurable in Engine?

[Oved Ourfali]

I'd open it by default, if the user asks to configure the firewall.
We ask that on host bootstrapping, so one can choose not to let us
configure the firewall if he controls his own firewall configuration.
On Mar 4, 2016 14:02, "Fabian Deutsch"  wrote:

> Btw. This question is now asked for Node, but it also affects other
> hosts which are running Cockpit.
>
> - faian
>
> On Fri, Mar 4, 2016 at 1:01 PM, Fabian Deutsch 
> wrote:
> > Hey,
> >
> > Node Next will ship Cockpit by default.
> >
> > When the host is getting installed, Cockpit can be reached by default
> > over it's port 9090/tcp.
> >
> > But after the host was added to Engine, Engine/vdsm is setting up it's
> > own iptables rules which then prevent further access to Cockpit.
> >
> > How do we want users to control the access to Cockpit? So where shall
> > users be able to open or close the Cockpit firewall port.
> >
> > Initially I thought that we can open up the cockpit port by default,
> > but this might be a security issue.
> > (Brute force attacks to crack user passwords through the web interface).
> >
> > - fabian
>
>
>
> --
> Fabian Deutsch 
> RHEV Hypervisor
> Red Hat
> ___
> 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] Changing the name of VDSM in oVirt 4.0.

[Oved Ourfali]

I must agree with Martin here.
In addition, I think the benefit here is low, and the efforts it will
require and the risks are high. Upgrade issues? Compatibility ones? Effect
on engine features such as host upgrade manager, different provisioning
products that might rely on that such as puppet recipes, ansible modules,
or others...
(can't say all mentioned stuff are relevant, and I guess there might be
more implications than I've described).

IMHO, we should spend our time improving our project rather than spend a
lot of developers, testers and integration people on these kind of tasks.

In addition, bootstrapping of hosts doesn't require manual installation of
VDSM, and as of 3.6 neither does upgrade, so most users shouldn't know and
care what VDSM is.

Regards,
Oved

On Jan 26, 2016 7:00 PM, "Martin Sivak"  wrote:
>
> Hi,
>
> name change might be considered, but I do not think it will make a big
> difference. People do not see vdsm too often (installed by host
> deploy, managed by engine..).
>
>
> But trying to make sure that (all?) component versions in a project
> are the same is not a good idea if you ask me. You are not going to
> rebuild everything when a hot fix is needed, but granted, you might
> use minor numbers so the versions will at least start with the same
> numbers. Or will we force a version bump and rebuild to unchanged
> component, when others were updated for a given release? (we have
> components like that - ovirt-scheduler-proxy for example)
>
> Engine does not depend on an exact vdsm version, we have gradual
> feature degradation built in in form of capabilities, machine type and
> cluster levels so it should be totally up to the user what version of
> vdsm is used. The same we do not control libvirt or kernel. Some of
> the components (at least on my side) are completely usable without
> oVirt and when oVirt is released it just gets the latest stable bits
> available.
>
> Why don't we treat oVirt as a package distribution it is? The long
> term plan still is to break the monoliths (like vdsm or engine) and
> the possibly new teams (or community) might have different needs.. we
> might even want to promote reuse of some of the components (like [2])
> in oVirt unrelated way and I would really love to see that kind of
> adoption. We are trying to keep so much control that we are an open
> project, but not a community one (where the community can influence
> future plans, release schedules, workflows or processes).
>
> Neither Fedora, nor RHEL (Debian, ..) try to control the version of
> components. They depend purely on package dependencies and separate
> component development from distribution compose processes (something
> we lack..). Even OpenStack abandoned the unified versioning last year
> (at least partially) [1]. We decided to use similar age based
> versioning like described in [1] when I was still part of the Anaconda
> team and it worked perfectly fine.
>
> I really wish we would loosen the project coupling (and processes)
> instead of tightening it. Sadly everything we have done lately is
> going in the tightening direction...
>
>
>
> TL;DR: Please let us use whatever versions of packages we want,
> release as often as we want and just take the latest bits to compose
> the oVirt distribution. Most of the components we have handle that
> just fine.
>
> [1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and
> please pay particular attention to the last section and especially the
> last two paragraphs in it)
> [2] There was a thread about vdsm RPMs being too granular:
> http://lists.ovirt.org/pipermail/devel/2016-January/012185.html
>
> --
> Martin Sivak
> oVirt / SLA
> ___
> 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] Vdsm sync 5/1 summary after short delay

[Oved Ourfali]

Thanks for the summary!
See one comment inline.

On Sun, Jan 10, 2016 at 2:49 PM, Yaniv Bronheim  wrote:

>
> (fromani, nsoffer, ybronhei, alitke)
>
>  - Removing xmlrpc for good - who should accept it? where do we stand with
> full jsonrpc client ? (we didn't get to any conclusions and said that we'll
> reraise this topic next week with pioter)
>
>
With regards to that, in order to move to 3.6 cluster level, you MUST have
all hosts in jsonrpc protocol. So, we just need to make sure no piece of
code uses that explicitly, and if so move that to jsonrpc as well.


>  - Moving from nose to pytest - generally good approach to achieve. It
> requires some changes in current testlib.py code. must be an item for next
> major version (nir already managed to run most of the tests with it, and
> stated few gaps)
>
>  - Exception patches - still on progress, please review (
> https://gerrit.ovirt.org/48868)
>
>  - python3 effort to cover all asyncProc usage, and allowing utils import
> without having python3-cpopen - https://gerrit.ovirt.org/51421
> https://gerrit.ovirt.org/49441 . still under review
>
> We didn't take notes during that talk, so if I forgot to mention something
> I apologize. Feel free to reply and raise it
>
> Greetings,
>
> --
> *Yaniv Bronhaim.*
>
> ___
> 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] VDSM dependency broken on 3.6 branch

[Oved Ourfali]

CC-ing Dan.
However, note that this is a dependency of a hook, and hooks aren't
mandatory for installation of VDSM.

Regards,
Oved
On Dec 18, 2015 18:23, "Sandro Bonazzola"  wrote:

> *06:49:19* package: vdsm-hook-ovs-4.17.13-31.git8bb3de9.el7.centos.noarch 
> from check-custom-el7*06:49:19*   unresolved deps: *06:49:19*  
> openvswitch >= 0:2*06:49:19* package: 
> vdsm-hook-ovs-4.17.13-33.git6fb5413.el7.centos.noarch from 
> check-custom-el7*06:49:19*   unresolved deps: *06:49:19*  openvswitch >= 
> 0:2
>
>
> --
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Controlling UI table column visibility and position

[Oved Ourfali]

That's awesome!
Looking forward to playing around with it!

Thanks,
Oved
On Nov 25, 2015 6:42 PM, "Vojtech Szocs"  wrote:

> Dear developers and users,
>
> it's now possible to tweak table column visibility and position
> through header context menu in WebAdmin's main & sub tabs [1,2].
>
>   [1] https://gerrit.ovirt.org/#/c/43401/
>   [2] https://gerrit.ovirt.org/#/c/47542/
>
> This allows you to turn "unwanted" columns off and re-arrange
> those which are visible to match your personal preference.
>
> Screenshot of customizing VM main tab:
>
>   https://imgur.com/5dfh8QA
>
> There's also RFE [3] to persist (remember) such column settings
> in the browser, similar to persisting other client-side options.
>
>   [3] https://bugzilla.redhat.com/1285456
>
> Regards,
> Vojtech
> ___
> 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] oVirt 3.6.1 branch has been created

[Oved Ourfali]

On Wed, Nov 18, 2015 at 6:23 PM, Sandro Bonazzola <sbona...@redhat.com>
wrote:

>
>
> On Wed, Nov 18, 2015 at 4:27 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>>
>>
>> On Wed, Nov 18, 2015 at 5:23 PM, Moti Asayag <masa...@redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Nov 18, 2015 at 1:33 PM, Oved Ourfali <oourf...@redhat.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I think it was premature.
>>>>
>>>> I still see a lot of bugs to be fixed in 3.6.1.
>>>> See query:
>>>>
>>>> https://bugzilla.redhat.com/report.cgi?x_axis_field=bug_status_axis_field=status_whiteboard_axis_field=target_milestone_redirect=1_format=report-table_desc_type=allwordssubstr_desc=_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords===_id=_id_type=anyexact_milestone=ovirt-3.6.1=substring==substring==substringNow_top=AND=1=status_whiteboard=anywordssubstr=docs%2Cnode=flagtypes.name=anywordssubstr==noop=noop==table=wrap
>>>>
>>>> And if looking only at blockers and exceptions I see 25 bugs still on
>>>> new/assigned/post.
>>>>
>>>>
>>>> https://bugzilla.redhat.com/report.cgi?x_axis_field=bug_status_axis_field=status_whiteboard_axis_field=target_milestone_redirect=1_format=report-table_desc_type=allwordssubstr_desc=_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords===_id=_id_type=anyexact_milestone=ovirt-3.6.1=substring==substring==substringNow_top=AND=1=status_whiteboard=anywordssubstr=docs%2Cnode=flagtypes.name=anywordssubstr=blocker%2Cexception=noop=noop==noop=noop==table=wrap
>>>>
>>>> Why not to do the branching later, when we get it more stable or push
>>>> bugs out of it?
>>>>
>>>
>>> +1, are there any stabilization criteria to determine when a code base
>>> is considered stabilized enough for branching ?
>>>
>>>
>>
>> Guys the overhead of cherry picking isn't small. Why CI issues promoted
>> that?
>>
>
> CI issues just asked to rename from 3.6.1.x to 3.6.1.
> Branch creation has nothing to do with CI requests.
> Guys, if hitting cherry-pick button on gerrit web ui costs to much feel
> free to revert https://gerrit.ovirt.org/48709 and delete
> ovirt-engine-3.6.1 branch.
>

Well, does it always work well for you?
I didn't hear one good reason to do the branching now.

So yes. I suggest you revert it (or give good reasons not to).


> Let me know when you'll be ready to branch.
>
>
>>
>>
>>
>>>
>>>> Thanks,
>>>> Oved
>>>>
>>>>
>>>>
>>>> On Wed, Nov 18, 2015 at 12:33 PM, Sandro Bonazzola <sbona...@redhat.com
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>> just an heads up we branched for 3.6.1 stabilization this morning.
>>>>> If you have patches targeted to 3.6.1 you now need to cherry-pick them
>>>>> to 3.6.1 branch too.
>>>>> A build is scheduled for today at 2 PM TLV time.
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Moti
>>>
>>> ___
>>> 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
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 3.6.1 branch has been created

[Oved Ourfali]

Hi

I think it was premature.

I still see a lot of bugs to be fixed in 3.6.1.
See query:
https://bugzilla.redhat.com/report.cgi?x_axis_field=bug_status_axis_field=status_whiteboard_axis_field=target_milestone_redirect=1_format=report-table_desc_type=allwordssubstr_desc=_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords===_id=_id_type=anyexact_milestone=ovirt-3.6.1=substring==substring==substringNow_top=AND=1=status_whiteboard=anywordssubstr=docs%2Cnode=flagtypes.name=anywordssubstr==noop=noop==table=wrap

And if looking only at blockers and exceptions I see 25 bugs still on
new/assigned/post.

https://bugzilla.redhat.com/report.cgi?x_axis_field=bug_status_axis_field=status_whiteboard_axis_field=target_milestone_redirect=1_format=report-table_desc_type=allwordssubstr_desc=_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords===_id=_id_type=anyexact_milestone=ovirt-3.6.1=substring==substring==substringNow_top=AND=1=status_whiteboard=anywordssubstr=docs%2Cnode=flagtypes.name=anywordssubstr=blocker%2Cexception=noop=noop==noop=noop==table=wrap

Why not to do the branching later, when we get it more stable or push bugs
out of it?

Thanks,
Oved



On Wed, Nov 18, 2015 at 12:33 PM, Sandro Bonazzola 
wrote:

> Hi,
> just an heads up we branched for 3.6.1 stabilization this morning.
> If you have patches targeted to 3.6.1 you now need to cherry-pick them to
> 3.6.1 branch too.
> A build is scheduled for today at 2 PM TLV time.
>
> --
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Martin Perina - new engine backend maintainer

[Oved Ourfali]

Hi All,

Martin Perina has been working on the oVirt project for over 2.5 years.
He focused on various features, including AAA extensions, Kdump detection,
fencing, wildfly support, and various backend functionality.

He is also a very sharp reviewer, that caught many issues over these years.
He has become a key contributor in the last year, leading many major
efforts on the infrastructure group, and collaborating also with other
groups.

After consulting with the maintainers group, I announce that he is now an
engine backend maintainer.
Martin - we hope to see more and more good work from you in the upcoming
years.

David - can you set this in gerrit?

Thanks!
Oved
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Login issue on master

[Oved Ourfali]

Please share complete engine.log and server.log.

- Original Message -
 From: Vered Volansky ve...@redhat.com
 To: devel@ovirt.org
 Sent: Wednesday, August 12, 2015 8:48:00 AM
 Subject: Re: [ovirt-devel] Login issue on master
 
 engine:
 2015-08-12 08:12:41,129 INFO [org.ovirt.engine.core.bll.aaa.LoginBaseCommand]
 (default task-28) [] Can't login user 'admin' with authentication profile
 'internal' because the authentication failed.
 2015-08-12 08:12:41,146 ERROR
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
 (default task-28) [] Correlation ID: null, Call Stack: null, Custom Event
 ID: -1, Message: User admin cannot login, please verify the username and
 password.
 2015-08-12 08:12:41,154 ERROR
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
 (default task-28) [] Correlation ID: null, Call Stack: null, Custom Event
 ID: -1, Message: User admin@internal failed to log in.
 2015-08-12 08:12:41,154 WARN
 [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] (default task-28) []
 CanDoAction of action 'LoginAdminUser' failed for user admin@internal.
 Reasons: USER_FAILED_TO_AUTHENTICATE_WRONG_USERNAME_OR_PASSWORD
 
 
 
 
 On Wed, Aug 12, 2015 at 8:41 AM, Vered Volansky  ve...@redhat.com  wrote:
 
 
 
 Can't login to engine after rebase and schema-dev execution.
 Can't investigate more at the moment, just a heads up.
 
 
 ___
 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] Screen casting and video editing on fc21 with Blender

[Oved Ourfali]

Including editing? 

On Jul 23, 2015 7:39 AM, Max Kovgan mkov...@redhat.com wrote:Hi, Eli. I have yet seen any thing related to video playback or recording VLC cannot do.
This includes desktop screen casting.

On Jul 22, 2015 11:39 PM, Christopher Pereira kripper@imatronix.cl wrote:Hi,

For Windows, if licenses are not a problem, you also have Camtasia [1], which uses an optimized codec that only stores images and GUI events in the same way RemoteDesktop does.
As a result, recordings is lossless and take much less space. For example, AFAIU, if you scroll a static image on the screen, its stored only once and only its position changes are recorded frame by frame. There are also other benefits like the fact that the mouse pointer position can be edited separately after recording.
You may probably get similar results if you record everything lossless (which takes a lot of space and resources while recording). For best quality, the key is to avoid re-compression (you should only encode the final video).

Camtasia also includes a complete editor.

Besides, Camtasias AVI files can be edited with Sony Vegas or Premiere and finally be rendered with standard codecs which can be shared or uploaded to youtube, vimeo, etc. (otherwise, you would need to provide the Camtasia codec for playback).

I wonder if there are stable OS alternatives using a similar approach.

Best regards,
Christopher.

[1] https://www.techsmith.com/camtasia.html

On 22-07-2015 16:49, Eli Mesika wrote:

Hi guys

As you already know, some of us need to do some video/screen cast for their 3.6 new features
I spent my day today in recording and editing a video for one of my new 3.6 features and I want to share my experience to save you time (and hair..)

Well, I started with recordmydesktop (yum) to capture the video files , this worked smooth and enables you also to have a cup of coffee until the file is written to the disk.
Then, after having few videos, I wanted to edit them and make a whole smooth video, cutting some stuff out ...
I had started with installing pitivi (yum), from its feature list it seems promising but after dozens of crashes on almost every mouse move, I really gave up...

Oved, sent me this post [1]:
So, I installed Blender and tried to work with it but it seems to refuse adding my video files to the project time-line ...
Digging around [2], I found that the Blender package on fc21 does not work well and in order to get it working you have to download Blender latest version (2.75a) manually from [3],
extract it to a directory and run blender 

Blender has many usages, but you can adjust it to do video editing, just follow [4] [5] and [6] tutorials (less than 15 min for all)
(all are important, especially the first one that includes proper configuration)

One major issue is to configure well the frames per second rate (fps) (can be shown on the file properties) of your videos if you dont want to get a gap between your video and the sound track

I was able after that to edit my videos and export (render) video as MP4 and audio as MP3 (embedded in the video file) (other formats may have codec issues...)

Overall, I worked with Blender few hours, splitting videos, removing video strips , grabbing and dragging without a single error or crash

Although that Blender learning curve seems to be longer than other applications, I recommend to use this application for video editing and screen casting

If you have any question or need any assistance/advice , I will be happy to help.


[1] http://opensource.com/life/15/1/current-state-linux-video-editing
[2] http://www.spinics.net/linux/fedora/fedora-users/msg459024.html
[3] https://www.blender.org/
[4] https://www.youtube.com/watch?v=xSGIPmQdV6Mhtml5=1
[5] https://www.youtube.com/watch?v=20VqQLpvctY
[6] https://www.youtube.com/watch?v=zxFGm_LQeZQ


Thanks
Eli Mesika

___
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] engine-setup broken in master?

[Oved Ourfali]

Hi

I've just checked-out latest master, built the engine, targeting a new 
directory, new DB schema, and it worked well.

Can you re-test it?

Thanks,
Oved

- Original Message -
 From: Omer Frenkel ofren...@redhat.com
 To: devel@ovirt.org
 Sent: Thursday, June 25, 2015 10:37:55 AM
 Subject: [ovirt-devel] engine-setup broken in master?
 
 Hi,
 on latest master, engine-setup fails for me with:
 [ ERROR ] Failed to execute stage 'Setup validation': Failed checking Engine
 database: [u'']
 
 from the setup log:
 
 2015-06-25 10:27:51 DEBUG
 otopi.plugins.ovirt_**FILTERED**_setup.ovirt_**FILTERED**.upgrade.dbvalidations
 plugin.execute:940 execute-output:
 ['/home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/dbu
 tils/validatedb.sh', '--user=**FILTERED**', '--host=localhost',
 '--port=5432', '--database=**FILTERED**',
 '--log=/home/ofrenkel/ovirt-**FILTERED**/var/log/ovirt-**FILTERED**/setup/ovirt-**FILTERED**-setup-201506
 25102702-nwwazb.log'] stderr:
 ERROR:  function fn_db_validate_fks(boolean, boolean) does not exist
 LINE 3: from fn_db_validate_fks(false, 0 != 0)
  ^
 HINT:  No function matches the given name and argument types. You might need
 to add explicit type casts.
 
 2015-06-25 10:27:51 DEBUG otopi.context context._executeMethod:155 method
 exception
 Traceback (most recent call last):
   File /usr/lib/python2.7/site-packages/otopi/context.py, line 145, in
   _executeMethod
 method['method']()
   File
   
 /home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/upgrade/dbvalidations.py,
   line 128, in _validation
 violations, issues_found = self._checkDb()
   File
   
 /home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/upgrade/dbvalidations.py,
   line 91, in _checkDb
 output=stdout,
 RuntimeError: Failed checking Engine database:
 [u'']
 
 2015-06-25 10:27:51 ERROR otopi.context context._executeMethod:164 Failed to
 execute stage 'Setup validation': Failed checking Engine database:
 [u'']
 
 
 
 looks like lately this function (fn_db_validate_fks) was moved, might be
 related?
 ( https://gerrit.ovirt.org/#/c/42655/ )
 
 i even tried to completely remove my ~/ovirt-engine/ folder and create from
 scratch
 
 anyone else experienced this?
 
 Thanks,
 Omer.
 ___
 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] engine-setup broken in master?

[Oved Ourfali]

- Original Message -
 From: Omer Frenkel ofren...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, June 25, 2015 11:06:09 AM
 Subject: Re: [ovirt-devel] engine-setup broken in master?
 
 
 
 - Original Message -
  From: Oved Ourfali ov...@redhat.com
  To: Omer Frenkel ofren...@redhat.com
  Cc: devel@ovirt.org
  Sent: Thursday, June 25, 2015 11:03:46 AM
  Subject: Re: [ovirt-devel] engine-setup broken in master?
  
  Hi
  
  I've just checked-out latest master, built the engine, targeting a new
  directory, new DB schema, and it worked well.
  
  Can you re-test it?
  
  Thanks,
  Oved
  
 
 i dont want new db schema, you should test upgrade.
 i tested several times, on 2 different setup folders, same existing db of
 course.
 

Okay.
You haven't specified that, so I tested with a clean environment.
Eli will be around in ~2 hours (he is on half day PTO), and I'll ask him to dig 
into it.

Thanks,
Oved

  - Original Message -
   From: Omer Frenkel ofren...@redhat.com
   To: devel@ovirt.org
   Sent: Thursday, June 25, 2015 10:37:55 AM
   Subject: [ovirt-devel] engine-setup broken in master?
   
   Hi,
   on latest master, engine-setup fails for me with:
   [ ERROR ] Failed to execute stage 'Setup validation': Failed checking
   Engine
   database: [u'']
   
   from the setup log:
   
   2015-06-25 10:27:51 DEBUG
   otopi.plugins.ovirt_**FILTERED**_setup.ovirt_**FILTERED**.upgrade.dbvalidations
   plugin.execute:940 execute-output:
   ['/home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/dbu
   tils/validatedb.sh', '--user=**FILTERED**', '--host=localhost',
   '--port=5432', '--database=**FILTERED**',
   '--log=/home/ofrenkel/ovirt-**FILTERED**/var/log/ovirt-**FILTERED**/setup/ovirt-**FILTERED**-setup-201506
   25102702-nwwazb.log'] stderr:
   ERROR:  function fn_db_validate_fks(boolean, boolean) does not exist
   LINE 3: from fn_db_validate_fks(false, 0 != 0)
^
   HINT:  No function matches the given name and argument types. You might
   need
   to add explicit type casts.
   
   2015-06-25 10:27:51 DEBUG otopi.context context._executeMethod:155 method
   exception
   Traceback (most recent call last):
 File /usr/lib/python2.7/site-packages/otopi/context.py, line 145, in
 _executeMethod
   method['method']()
 File
 
   /home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/upgrade/dbvalidations.py,
 line 128, in _validation
   violations, issues_found = self._checkDb()
 File
 
   /home/ofrenkel/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/upgrade/dbvalidations.py,
 line 91, in _checkDb
   output=stdout,
   RuntimeError: Failed checking Engine database:
   [u'']
   
   2015-06-25 10:27:51 ERROR otopi.context context._executeMethod:164 Failed
   to
   execute stage 'Setup validation': Failed checking Engine database:
   [u'']
   
   
   
   looks like lately this function (fn_db_validate_fks) was moved, might be
   related?
   ( https://gerrit.ovirt.org/#/c/42655/ )
   
   i even tried to completely remove my ~/ovirt-engine/ folder and create
   from
   scratch
   
   anyone else experienced this?
   
   Thanks,
   Omer.
   ___
   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] cannot install host: VdsDeployBase, Error during deploy dialog: java.lang.NullPointerException

[Oved Ourfali]

A similar issue was already reported in this mailing list.
You should just upgrade the ovirt-host-deploy to ovirt-host-deploy-1.4.0-0.0.

Oved

- Original Message -
 From: Martin Mucha mmu...@redhat.com
 To: devel@ovirt.org
 Sent: Wednesday, June 24, 2015 9:34:50 AM
 Subject: [ovirt-devel] cannot install host: VdsDeployBase, Error during 
 deploy dialog: java.lang.NullPointerException
 
 Hi,
 
 I have difficulties to install host. I do believe it fails due to this:
 
 2015-06-24 08:29:26,729 ERROR
 [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [612066b7]
 Error during deploy dialog: java.lang.NullPointerException
 at
 
 org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236)
 [otopi.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:579)
 [bll.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:577)
 [bll.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._nextCustomizationEntry(VdsDeployBase.java:202)
 [bll.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._threadMain(VdsDeployBase.java:301)
 [bll.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase.access$200(VdsDeployBase.java:45)
 [bll.jar:]
 at
 
 org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase$7.run(VdsDeployBase.java:392)
 [bll.jar:]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
 
 anyone met this? Know how to overcome this? Any hints welcomed.
 (alredy tried to remove library from m2 repo to force re-download)
 
 M.
 ___
 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] [IMPORTANT] Re: Move to Jboss Wildfly - planned for Monday, June 22nd

[Oved Ourfali]

top-posting:

Running more in-depth tests, we found out that there is an issue with matrix 
parameters in the REST-API (see [1] for more details).

We are now trying to understand the cause for these issue, and also check 
whether there is a workaround or not.
If we won't resolve it soon we'll have to postpone the move to Wildfly until 
this gets resolved.

I'll keep you all posted.

Regards,
Oved

[1] For example, asking for only 2 VMs can be done via using the following 
resource URL
   http://engine:port/ovirt-engine/api/vms;max=2

- Original Message -
 From: Oved Ourfali ov...@redhat.com
 To: Roy Golan rgo...@redhat.com
 Cc: devel devel@ovirt.org
 Sent: Sunday, June 21, 2015 4:24:38 PM
 Subject: Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday, June 
 22nd
 
 
 
 - Original Message -
  From: Roy Golan rgo...@redhat.com
  To: Oved Ourfali ov...@redhat.com
  Cc: devel devel@ovirt.org
  Sent: Sunday, June 21, 2015 4:05:13 PM
  Subject: Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday, June
  22nd
  
  On 06/21/2015 03:21 PM, Oved Ourfali wrote:
  
   - Original Message -
   From: Roy Golan rgo...@redhat.com
   To: Oved Ourfali ov...@redhat.com, devel devel@ovirt.org
   Sent: Sunday, June 21, 2015 3:19:28 PM
   Subject: Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday,
   June 22nd
  
   On 06/18/2015 09:13 AM, Oved Ourfali wrote:
   Hi all!
  
   On Monday, June 22nd, 11:00 CET, we plan to drop JBoss 7.1 support in
   oVirt
   3.6 and move to Jboss WildFly 8.2
   (we're still doing final verifications, but it looks promising).
  
   This will allow us to support Fedora 22 properly, and in future
   versions
   to
   leverage some new and cool features.
  
   In addition, Jboss WildFly 8.2 works with OpenJDK 1.8 so you can easily
   use
   it for
   development on newer distributions where OpenJDK 1.7 is not available
   (Fedora 21 and 22, for example).
   May need a separate thread for that, but we will be able to code using
   JDK 8. its about time. jdk 8 was out April 2014.
  
   We will still work with JDK7 for downstream.
  
  this should go on a separate thread :)
  
   When the patch [1] is merged, you will need WildFly 8.2 to be able to
   develop
   oVirt engine 3.6. Please use following guideline and update your
   development
   environment:
  
   I. Using WildFly 8.2 for oVirt 3.6 development
  
  1. Enable ovirt-master-snapshot-static repository on your
  development
  machine
   [ovirt-master-snapshot-static]
   name=Latest oVirt master additional nightly snapshot
   
   baseurl=http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/@DIST@$releasever/
   enabled=1
   skip_if_unavailable=1
   gpgcheck=0
  
 Please replace @DIST@ with fc for Fedora or el for
 Centos/RHEL
  
  2. Install WildFly packages:
   yum install ovirt-engine-wildfly ovirt-engine-wildfly-overlay
  
  3. Rebase your patches and build oVirt engine (assuming
  ~/ovirt-engine
  as
 destination)
   make install-dev
  
  5. Setup WildFly overlay (assuming ~/ovirt-engine as destination)
   echo
   
   ENGINE_JAVA_MODULEPATH=\/usr/share/ovirt-engine-wildfly-overlay/modules:\${ENGINE_JAVA_MODULEPATH}\
   \

   ~/ovirt-engine/etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf
  
  6. Execute setup
   cd ~/ovirt-engine
   ./bin/engine-setup
  
  7. Start engine service
   cd ~/ovirt-engine
   ./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py
   start
  
  
   II. Using JBoss 7.1.1 for 3.5 environment
   why would anyone want to do that?
  
   Bugs!
  
  only for out (last?) z stream which will be 3.5.4. other then that, its
  really the end.
  
 
 We might also have 3.5.5.
 
  Using JBoss 7.1.1 on 3.5 is still possible, by doing the following:
  
   1. Install JBoss 7.1.1 RPM from ovirt-master-snapshot-static repo
   using
yum install ovirt-engine-jboss-as
  
   2. Build oVirt engine 3.5 with your backported feature (assuming
  ~/ovirt-engine as destination)
make install-dev
   
   3. Execute setup
cd ~/ovirt-engine
./bin/engine-setup--jboss-home=/usr/share/ovirt-engine-jboss-as
  
   4. Start engine service
cd ~/ovirt-engine
./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py
start
 
   Once merged, we will send an E-mail to make sure you're all aware, and
   that
   you can do the steps described above.
  
   We're here for any issue you might have (specifically Martin who is
   responsible for this effort, and myself).
   Don't hesitate to contact us for any issue, either by mail or irc
   (mperina
   or oved).
  
   Regards,
   Oved
  
   [1] https://gerrit.ovirt.org/40152

Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday, June 22nd

[Oved Ourfali]

- Original Message -
 From: Roy Golan rgo...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: devel devel@ovirt.org
 Sent: Sunday, June 21, 2015 4:05:13 PM
 Subject: Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday, June 
 22nd
 
 On 06/21/2015 03:21 PM, Oved Ourfali wrote:
 
  - Original Message -
  From: Roy Golan rgo...@redhat.com
  To: Oved Ourfali ov...@redhat.com, devel devel@ovirt.org
  Sent: Sunday, June 21, 2015 3:19:28 PM
  Subject: Re: [ovirt-devel] Move to Jboss Wildfly - planned for Monday,
  June 22nd
 
  On 06/18/2015 09:13 AM, Oved Ourfali wrote:
  Hi all!
 
  On Monday, June 22nd, 11:00 CET, we plan to drop JBoss 7.1 support in
  oVirt
  3.6 and move to Jboss WildFly 8.2
  (we're still doing final verifications, but it looks promising).
 
  This will allow us to support Fedora 22 properly, and in future versions
  to
  leverage some new and cool features.
 
  In addition, Jboss WildFly 8.2 works with OpenJDK 1.8 so you can easily
  use
  it for
  development on newer distributions where OpenJDK 1.7 is not available
  (Fedora 21 and 22, for example).
  May need a separate thread for that, but we will be able to code using
  JDK 8. its about time. jdk 8 was out April 2014.
 
  We will still work with JDK7 for downstream.
 
 this should go on a separate thread :)
 
  When the patch [1] is merged, you will need WildFly 8.2 to be able to
  develop
  oVirt engine 3.6. Please use following guideline and update your
  development
  environment:
 
  I. Using WildFly 8.2 for oVirt 3.6 development
 
 1. Enable ovirt-master-snapshot-static repository on your development
 machine
  [ovirt-master-snapshot-static]
  name=Latest oVirt master additional nightly snapshot
  
  baseurl=http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/@DIST@$releasever/
  enabled=1
  skip_if_unavailable=1
  gpgcheck=0
 
Please replace @DIST@ with fc for Fedora or el for
Centos/RHEL
 
 2. Install WildFly packages:
  yum install ovirt-engine-wildfly ovirt-engine-wildfly-overlay
 
 3. Rebase your patches and build oVirt engine (assuming
 ~/ovirt-engine
 as
destination)
  make install-dev
 
 5. Setup WildFly overlay (assuming ~/ovirt-engine as destination)
  echo
  
  ENGINE_JAVA_MODULEPATH=\/usr/share/ovirt-engine-wildfly-overlay/modules:\${ENGINE_JAVA_MODULEPATH}\
  \
   
  ~/ovirt-engine/etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf
 
 6. Execute setup
  cd ~/ovirt-engine
  ./bin/engine-setup
 
 7. Start engine service
  cd ~/ovirt-engine
  ./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py start
 
 
  II. Using JBoss 7.1.1 for 3.5 environment
  why would anyone want to do that?
 
  Bugs!
 
 only for out (last?) z stream which will be 3.5.4. other then that, its
 really the end.
 

We might also have 3.5.5.

 Using JBoss 7.1.1 on 3.5 is still possible, by doing the following:
 
  1. Install JBoss 7.1.1 RPM from ovirt-master-snapshot-static repo
  using
   yum install ovirt-engine-jboss-as
 
  2. Build oVirt engine 3.5 with your backported feature (assuming
 ~/ovirt-engine as destination)
   make install-dev
  
  3. Execute setup
   cd ~/ovirt-engine
   ./bin/engine-setup--jboss-home=/usr/share/ovirt-engine-jboss-as
 
  4. Start engine service
   cd ~/ovirt-engine
   ./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py start

  Once merged, we will send an E-mail to make sure you're all aware, and
  that
  you can do the steps described above.
 
  We're here for any issue you might have (specifically Martin who is
  responsible for this effort, and myself).
  Don't hesitate to contact us for any issue, either by mail or irc
  (mperina
  or oved).
 
  Regards,
  Oved
 
  [1] https://gerrit.ovirt.org/40152
  ___
  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

[ovirt-devel] Move to Jboss Wildfly - planned for Monday, June 22nd

[Oved Ourfali]

Hi all!

On Monday, June 22nd, 11:00 CET, we plan to drop JBoss 7.1 support in oVirt 3.6 
and move to Jboss WildFly 8.2
(we're still doing final verifications, but it looks promising).

This will allow us to support Fedora 22 properly, and in future versions to 
leverage some new and cool features.

In addition, Jboss WildFly 8.2 works with OpenJDK 1.8 so you can easily use it 
for
development on newer distributions where OpenJDK 1.7 is not available (Fedora 
21 and 22, for example).

When the patch [1] is merged, you will need WildFly 8.2 to be able to develop
oVirt engine 3.6. Please use following guideline and update your development
environment:

I. Using WildFly 8.2 for oVirt 3.6 development

 1. Enable ovirt-master-snapshot-static repository on your development machine
  [ovirt-master-snapshot-static]
  name=Latest oVirt master additional nightly snapshot
  
baseurl=http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/@DIST@$releasever/
  enabled=1
  skip_if_unavailable=1
  gpgcheck=0

Please replace @DIST@ with fc for Fedora or el for Centos/RHEL

 2. Install WildFly packages:
  yum install ovirt-engine-wildfly ovirt-engine-wildfly-overlay

 3. Rebase your patches and build oVirt engine (assuming ~/ovirt-engine as
destination)
  make install-dev

 5. Setup WildFly overlay (assuming ~/ovirt-engine as destination)
  echo 
ENGINE_JAVA_MODULEPATH=\/usr/share/ovirt-engine-wildfly-overlay/modules:\${ENGINE_JAVA_MODULEPATH}\
 \
   
~/ovirt-engine/etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf

 6. Execute setup
  cd ~/ovirt-engine
  ./bin/engine-setup

 7. Start engine service
  cd ~/ovirt-engine
  ./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py start


II. Using JBoss 7.1.1 for 3.5 environment

 Using JBoss 7.1.1 on 3.5 is still possible, by doing the following: 

  1. Install JBoss 7.1.1 RPM from ovirt-master-snapshot-static repo using
   yum install ovirt-engine-jboss-as

  2. Build oVirt engine 3.5 with your backported feature (assuming
 ~/ovirt-engine as destination)
   make install-dev
  
  3. Execute setup
   cd ~/ovirt-engine
   ./bin/engine-setup--jboss-home=/usr/share/ovirt-engine-jboss-as

  4. Start engine service
   cd ~/ovirt-engine
   ./share/ovirt-engine/services/ovirt-engine/ovirt-engine.py start

Once merged, we will send an E-mail to make sure you're all aware, and that you 
can do the steps described above.

We're here for any issue you might have (specifically Martin who is responsible 
for this effort, and myself).
Don't hesitate to contact us for any issue, either by mail or irc (mperina or 
oved).

Regards,
Oved

[1] https://gerrit.ovirt.org/40152
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] master broken

[Oved Ourfali]

The patch was reverted and now we do further investigation.

Sorry for the inconvenience,
Oved


- Original Message -
 From: Martin Betak mbe...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: devel@ovirt.org
 Sent: Tuesday, June 16, 2015 3:00:06 PM
 Subject: Re: [ovirt-devel] master broken
 
 Hi all,
 
 I am encountering another error when adding host:
 
 2015-06-16 13:57:41,058 ERROR
 [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
 (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Command
 'org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand' failed: null
 2015-06-16 13:57:41,059 ERROR
 [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
 (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Exception:
 java.lang.NullPointerException
   at
   
 org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotEntityInMemory(DefaultCompensationContext.java:140)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotNewEntity(DefaultCompensationContext.java:101)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.AddVdsStaticToDb(AddVdsCommand.java:284)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.access$000(AddVdsCommand.java:67)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:112)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:109)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:210)
   [utils.jar:]
   at
   
 org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.executeCommand(AddVdsCommand.java:109)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1198)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1949)
   [bll.jar:]
   at
   
 org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174)
   [utils.jar:]
   at
   
 org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116)
   [utils.jar:]
   at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1366)
   [bll.jar:]
   at 
 org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:361)
   [bll.jar:]
   at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) 
 [bll.jar:]
   at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441)
   [bll.jar:]
   at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:397) 
 [bll.jar:]
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [rt.jar:1.7.0_75]
   at
   
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [rt.jar:1.7.0_75]
   at
   
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [rt.jar:1.7.0_75]
   at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75]
   at
   
 org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
   [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
   at
   
 org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
 org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
 org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:114)
   [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
   at
   
 org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:125)
   [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
   at
   
 org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135)
   [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
   at
   
 org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
   [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
   at
   
 org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
 org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final

Re: [ovirt-devel] master broken

[Oved Ourfali]

Seems like there is part of the add host flow that calls update before the 
entity is actually saved.
Logically, that's wrong, but we've posted a fix for that to cover this flow, 
just to make sure there are no other regressions.
In addition, we'll fix this logic anyway.

Patch will be merged soon (pending another verification).

Thanks!
Oved

- Original Message -
 From: Oved Ourfali ov...@redhat.com
 To: Piotr Kliczewski piotr.kliczew...@gmail.com
 Cc: devel@ovirt.org
 Sent: Tuesday, June 16, 2015 11:14:56 AM
 Subject: Re: [ovirt-devel] master broken
 
 We're looking into it.
 
 Oved
 
 - Original Message -
  From: Piotr Kliczewski piotr.kliczew...@gmail.com
  To: devel@ovirt.org
  Sent: Tuesday, June 16, 2015 11:07:16 AM
  Subject: [ovirt-devel]  master broken
  
  Guys,
  
  I attempted to add a host using latest master code and got following
  exception:
  
  2015-06-16 10:01:28,854 WARN
  [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
  (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action
  'AddVds' failed for user admin@internal. Reasons:
  VAR__ACTION__ADD,VAR__TYPE__HOST,$server
  192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store
  fingerprint to db for host 192.168.1.7:
  javax.persistence.PersistenceException:
  org.hibernate.id.IdentifierGenerationException: ids for this class
  must be manually assigned before calling save():
  org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER
  2015-06-16 10:01:41,724 ERROR
  [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor]
  (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a
  new transaction: javax.persistence.PersistenceException:
  org.hibernate.id.IdentifierGenerationException: ids for this class
  must be manually assigned before calling save():
  org.ovirt.engine.core.common.businessentities.VdsStatic
  at
  org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
  at
  org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
  at
  org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
  at
  org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876)
  [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
  at
  org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548)
  [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
  at
  org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60)
  [dal.jar:]
  at
  org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java)
  
  Thanks,
  Piotr
  ___
  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] master broken

[Oved Ourfali]

We're looking into it.

Oved

- Original Message -
 From: Piotr Kliczewski piotr.kliczew...@gmail.com
 To: devel@ovirt.org
 Sent: Tuesday, June 16, 2015 11:07:16 AM
 Subject: [ovirt-devel]  master broken
 
 Guys,
 
 I attempted to add a host using latest master code and got following
 exception:
 
 2015-06-16 10:01:28,854 WARN
 [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
 (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action
 'AddVds' failed for user admin@internal. Reasons:
 VAR__ACTION__ADD,VAR__TYPE__HOST,$server
 192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store
 fingerprint to db for host 192.168.1.7:
 javax.persistence.PersistenceException:
 org.hibernate.id.IdentifierGenerationException: ids for this class
 must be manually assigned before calling save():
 org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER
 2015-06-16 10:01:41,724 ERROR
 [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor]
 (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a
 new transaction: javax.persistence.PersistenceException:
 org.hibernate.id.IdentifierGenerationException: ids for this class
 must be manually assigned before calling save():
 org.ovirt.engine.core.common.businessentities.VdsStatic
 at
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
 [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
 at
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
 [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
 at
 org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
 [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
 at
 org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876)
 [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
 at
 org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548)
 [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
 at
 org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60)
 [dal.jar:]
 at
 org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java)
 
 Thanks,
 Piotr
 ___
 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] master broken

[Oved Ourfali]

Fix merged.

- Original Message -
 From: Oved Ourfali ov...@redhat.com
 To: Piotr Kliczewski piotr.kliczew...@gmail.com
 Cc: devel@ovirt.org
 Sent: Tuesday, June 16, 2015 11:50:52 AM
 Subject: Re: [ovirt-devel] master broken
 
 Seems like there is part of the add host flow that calls update before the
 entity is actually saved.
 Logically, that's wrong, but we've posted a fix for that to cover this flow,
 just to make sure there are no other regressions.
 In addition, we'll fix this logic anyway.
 
 Patch will be merged soon (pending another verification).
 
 Thanks!
 Oved
 
 - Original Message -
  From: Oved Ourfali ov...@redhat.com
  To: Piotr Kliczewski piotr.kliczew...@gmail.com
  Cc: devel@ovirt.org
  Sent: Tuesday, June 16, 2015 11:14:56 AM
  Subject: Re: [ovirt-devel] master broken
  
  We're looking into it.
  
  Oved
  
  - Original Message -
   From: Piotr Kliczewski piotr.kliczew...@gmail.com
   To: devel@ovirt.org
   Sent: Tuesday, June 16, 2015 11:07:16 AM
   Subject: [ovirt-devel]  master broken
   
   Guys,
   
   I attempted to add a host using latest master code and got following
   exception:
   
   2015-06-16 10:01:28,854 WARN
   [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
   (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action
   'AddVds' failed for user admin@internal. Reasons:
   VAR__ACTION__ADD,VAR__TYPE__HOST,$server
   192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store
   fingerprint to db for host 192.168.1.7:
   javax.persistence.PersistenceException:
   org.hibernate.id.IdentifierGenerationException: ids for this class
   must be manually assigned before calling save():
   org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER
   2015-06-16 10:01:41,724 ERROR
   [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor]
   (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a
   new transaction: javax.persistence.PersistenceException:
   org.hibernate.id.IdentifierGenerationException: ids for this class
   must be manually assigned before calling save():
   org.ovirt.engine.core.common.businessentities.VdsStatic
   at
   org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
   [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at
   org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
   [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at
   org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
   [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at
   org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876)
   [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
   at
   org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548)
   [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
   at
   org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60)
   [dal.jar:]
   at
   org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java)
   
   Thanks,
   Piotr
   ___
   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] latest master

[Oved Ourfali]

Eli is looking into that with the SLA team.
Seems like an upgrade script was deleted.
As far as I know it will be merged soon.

Thanks,
Oved

- Original Message -
 From: Alexander Wels aw...@redhat.com
 To: devel@ovirt.org
 Sent: Monday, June 15, 2015 4:44:09 PM
 Subject: [ovirt-devel] latest master
 
 Hi,
 
 I just rebased and re-ran the engine setup to make sure I have the latest
 schema. I am getting the following exception when starting the engine:
 
 Caused by: org.postgresql.util.PSQLException: The column name
 ksm_merge_across_nodes was not found in this ResultSet.
 at
 org.postgresql.jdbc2.AbstractJdbc2ResultSet.findColumn(AbstractJdbc2ResultSet.java:2542)
 at
 org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBoolean(AbstractJdbc2ResultSet.java:2390)
 at
 org.jboss.jca.adapters.jdbc.WrappedResultSet.getBoolean(WrappedResultSet.java:615)
 at
 org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:319)
 [dal.jar:]
 at
 org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:267)
 [dal.jar:]
 at
 org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
 [spring-jdbc.jar:3.1.1.RELEASE]
 ... 68 more
 
 It appears the code is looking for a column that wasn't added to the schema?
 
 ksm_merge_across_nodes
 
 Can someone merge the column into master so I am not stuck? thanks.
 ___
 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] Libvirt secrets management - take 2

[Oved Ourfali]

On Jun 12, 2015 14:21, Nir Soffer nsof...@redhat.com wrote:

 Hi all, 

 Recently support for Ceph network disk landed in master. It its possible 
 now to start a vm using Ceph network disk or hot-plug/unplug such disk 
 using Cephx authentication. 

 However, to make it work, you must add the relevant Ceph secret to 
 libvirt manually, in the same way it is done in OpenStack deployment. 
 Our goal is to manage secrets automatically and use ephemeral (safer) 
 secrets. 

 The next patches in the Ceph topic [1], implement secret management in 
 the same way we manage storage domains or server connections: 

 The concept is - all hosts can use all secrets, so you can migrate a vm 
 using Ceph disk to any host in the cluster. 

 1. When host becomes up, we register the secrets associated with all the 
    current active domains with libvirt 

 2. When activating a domain, we register the secrets associated with the 
    new domain with libvirt 

 3. When deactivating a domain, we unregister the secrets associated with 
    the domain from libvirt 

 4. When moving host to maintenance, we clear all secrets 

 5. When vdsm shutdown or starts, clear all secrets to ensure that we don't 
 keep 
    stale or unneeded secrets on a host 

 This system seems to work, but Federico pointed few issues and suggested 
 a new (simpler?) approach. 

 In future libvirt version, libvirt will support the concept of transient 
 secrets so you can start a transient vm using secret without registering 
 the secret with libvirt before starting the vm. The secret will be 
 specified in the vm XML (for starting a vm) or disk XML (for hot-plug). 
 This will make our secret management system and APIs useless. 

When is this planned to be added to libvirt? iiuc, once added, you will no 
longer need to register the secrets with libvirt, right? 


 Managing state on multiple hosts is hard; we will probably have to deal 
 with nasty edge cases (e.g. lost messages, network errors), which may 
 lead to host with missing secret, which cannot run some vms. We probably 
 do this right for storage domains (after 8 years?), and we should not 
 assume that we are smarter and secret management will work in the first 
 try. 

 The new approach is to *not* manage state or multiple hosts. Instead, 
 send the required secrets only to the host that starting a vm or 
 hot-plugging a disk that need a libvirt secret: 

 1. When starting a vm, add the required secrets to the vm description. 
    On the host, vdsm will register these secrets with libvirt before 
    starting the vm. 

 2. When migrating a vm, add the required secrets to the vm description. 
    On the host, vdsm will send these secrets to the destination host, 
    and on the destination host, vdsm will register the secrets with libvirt 
    before starting the vm. 


Will these secrets be part of the domain xml? 
If so, no need for special treatment in case of VM migration. 

 3. When hot-plugging a disk, send the secret if needed in the disk 
    description.  On the host, vdsm will register the secrets with libvirt. 

 4. When vdsm shutdown or starts, clear all secrets to ensure that we don't 
 keep 
    stale or unneeded secrets on a host 

 5. We never unregister secrets, since they are ephemeral anyway. 

 6. Alternatively, we can implement secrets reference counting so when a vm 
    stops or disk is hot-unplugged we decrease the reference count on the 
    secrets associated with this vm/disk, and if no other vms need the 
    secret, we can unregister the secret from libvirt. 

Doesn't seem necessary to me. 


 The new approach is simpler, if we avoid the fancy secret reference 
 counting. I believe we can get it merged in couple of weeks with help 
 from the virt team.

 Please share your thoughts on these alternative solutions. 


Keep in mind also hosted engine. Sounds to me like the new approach will be a 
better fit for it, as he won't need to deal with storage domain secrets, but 
just pass it in the VM description... Although I'm not a hosted engine expert, 
so not sure it makes a difference, but it sounds simpler in that aspect as 
well. 


 Thanks, 
 Nir 

 [1] 
 https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:ceph
  
 ___ 
 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] [UI] New/Edit host dialog is broken

[Oved Ourfali]

On Jun 9, 2015 21:00, Alexander Wels aw...@redhat.com wrote:

 On Monday, June 08, 2015 07:38:05 AM Einav Cohen wrote: 
  Thanks, Eli; @Alexander - can you please investigate this? 
  
   
  Regards, 
  Einav 
  

 Yes, found the problem, fixed here [1]. 


Looks good to me. Thanks for the quick fix. 
Who can merge that on a short loop? 


 [1] https://gerrit.ovirt.org/#/c/42104/ 

  - Original Message - 
  
   From: Eli Mesika emes...@redhat.com 
   To: engine-de...@ovirt.org devel@ovirt.org 
   Cc: Einav Cohen eco...@redhat.com, Oved Ourfali 
   oourf...@redhat.com, Alexander Wels aw...@redhat.com Sent: Monday, 
   June 8, 2015 7:17:46 AM 
   Subject: [UI] New/Edit host dialog is broken 
   
   Hi guys 
   
   I have found that new/edit host dialog is not working as expected 
   
   1) Create a new DC 'mydc' 
   2) Create a new cluster 'myCluster' 
   3) Create a new Host on 'myCluster' 
   
   Result: Host is created in Dc 'Default' and cluster 'Default' 
   
   1) Edit the host you have created 
   2) Change the cluster to 'myCluster' 
   3) press OK 
   
   Result: Host is still in Dc 'Default' and cluster 'Default' 
   
   
   Thanks 
   Eli Mesika 

 ___ 
 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] gerrit+ci improvement proposal

[Oved Ourfali]

- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: Eli Mesika emes...@redhat.com
 Cc: Oved Ourfali ov...@redhat.com, devel@ovirt.org, in...@ovirt.org
 Sent: Sunday, June 7, 2015 9:52:15 AM
 Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
 
 
 
 - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Oved Ourfali ov...@redhat.com
  Cc: Eyal Edri ee...@redhat.com, in...@ovirt.org, devel@ovirt.org
  Sent: Thursday, June 4, 2015 3:49:05 PM
  Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
  
  
  
  - Original Message -
   From: Oved Ourfali ov...@redhat.com
   To: Eyal Edri ee...@redhat.com
   Cc: devel@ovirt.org, in...@ovirt.org
   Sent: Thursday, June 4, 2015 10:03:02 AM
   Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
   
   
   
   - Original Message -
From: Eyal Edri ee...@redhat.com
To: Sandro Bonazzola sbona...@redhat.com
Cc: in...@ovirt.org, devel@ovirt.org
Sent: Thursday, June 4, 2015 9:46:40 AM
Subject: Re: [ovirt-devel] gerrit+ci improvement proposal



- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: Eyal Edri ee...@redhat.com, Max Kovgan mkov...@redhat.com
 Cc: devel@ovirt.org, in...@ovirt.org
 Sent: Thursday, June 4, 2015 9:11:10 AM
 Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
 
 Il 03/06/2015 21:46, Eyal Edri ha scritto:
  
  
  - Original Message -
  From: Max Kovgan mkov...@redhat.com
  To: devel@ovirt.org
  Cc: in...@ovirt.org
  Sent: Wednesday, June 3, 2015 8:22:54 PM
  Subject: [ovirt-devel] gerrit+ci improvement proposal
 
  Hi everyone!
  We really want to have reliable and snappy CI: to allow short
  cycles
  and
  encourage developers to write tests.
 
  # Problem
 
  Many patches are neither ready for review nor for CI upon
  submission,
  which
  is OK.
  But running all the jobs on those patches with limited resources
  results
  in:
  overloaded resources, slow response time, unhappy developers.
 
  # Proposed Solution
 
  To run less jobs we know we don’t need to, thus making more
  resources
  for
  the
  jobs we need to run.
  We have been experimenting to make our CI stabler and quicker to
  respond
  by
  using gerrit flags. This has improved in both directions very well
  internally.
  Now it seems a good time to let all the oVirt projects to use
  this.
  This solution indirectly promotes reviews and quick tests - “to
  fail
  early”,
  yet full blown static code analysis and long tests to run “when
  ready”.
 
  # How it works
 
  2 new gerrit independent flags are added to gerrit.
 
  ## CI flag
 
  Will express patch CI status. Values:
   * +1 CI passed
   *  0 CI did not run yet
   * -1 CI failed
  Permissions for setting: project maintainers (for special cases)
  should
  be
  able to set/override (except Jenkins).
 
  ## Workflow flag
 
  Will express patch “workflow” state. Values:
   *  0 Work In Progress
   * +1 Ready For Review
   * +2 Ready For Merge
  Permissions for setting: Owner can set +1, Project Maintainers can
  set
  +2
 
  ## Review + CI Integration:
 
  Merging [“Submit” button to appear] will require: Review+1, CI+1,
  Workflow+2
  Patch lifecycle now is:
  ---
  patch state   |owner |reviewer |maintainer |CI tests |pass
  ---
  added/updated |- |-|-  |quick|CI+1
  review|Workflow+1|Review+1 |-  |heavy   |CI+1
  merge ready   |- |-|Workflow+2 |gating   |CI+1
  merge |- |-|merge  |merge|CI+1
 
  Changes from current workflow:
  Owner only adds reviewers, now owner needs to set Workflow+1 for
  the
  patch
  to be reviewed, and heavily auto-tested.
  Maintainer now needs to set Workflow+2 and wait for Submit
  button
  to
  appear after CI has completed running gating tests.
 
 
  Next step will be to automate merge the change after Workflow+2
  has
  been
  set
  by the Maintainer and gating tests passed.
 
 
  ## Why now?
 
  It is elimination of waste. The sooner - the better.
  The solution has been used for a while and it works.
  Resolving the problem without gerrit involved will lead to adding
  unreliable
  code into jobs, and will still be prone to problems:
Just recently, 3d ago we’ve tried detecting what to run from
jenkins
relying only on gerrit comments so that upon Verified+1

Re: [ovirt-devel] gerrit+ci improvement proposal

[Oved Ourfali]

On Jun 7, 2015 10:00 AM, Eyal Edri ee...@redhat.com wrote:



 - Original Message - 
  From: Oved Ourfali ov...@redhat.com 
  To: Eyal Edri ee...@redhat.com 
  Cc: in...@ovirt.org, devel@ovirt.org 
  Sent: Sunday, June 7, 2015 9:55:56 AM 
  Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 
  
  
  
  - Original Message - 
   From: Eyal Edri ee...@redhat.com 
   To: Eli Mesika emes...@redhat.com 
   Cc: Oved Ourfali ov...@redhat.com, devel@ovirt.org, in...@ovirt.org 
   Sent: Sunday, June 7, 2015 9:52:15 AM 
   Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 
   
   
   
   - Original Message - 
From: Eli Mesika emes...@redhat.com 
To: Oved Ourfali ov...@redhat.com 
Cc: Eyal Edri ee...@redhat.com, in...@ovirt.org, devel@ovirt.org 
Sent: Thursday, June 4, 2015 3:49:05 PM 
Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 



- Original Message - 
 From: Oved Ourfali ov...@redhat.com 
 To: Eyal Edri ee...@redhat.com 
 Cc: devel@ovirt.org, in...@ovirt.org 
 Sent: Thursday, June 4, 2015 10:03:02 AM 
 Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 
 
 
 
 - Original Message - 
  From: Eyal Edri ee...@redhat.com 
  To: Sandro Bonazzola sbona...@redhat.com 
  Cc: in...@ovirt.org, devel@ovirt.org 
  Sent: Thursday, June 4, 2015 9:46:40 AM 
  Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 
  
  
  
  - Original Message - 
   From: Sandro Bonazzola sbona...@redhat.com 
   To: Eyal Edri ee...@redhat.com, Max Kovgan 
   mkov...@redhat.com 
   Cc: devel@ovirt.org, in...@ovirt.org 
   Sent: Thursday, June 4, 2015 9:11:10 AM 
   Subject: Re: [ovirt-devel] gerrit+ci improvement proposal 
   
   Il 03/06/2015 21:46, Eyal Edri ha scritto: 


- Original Message - 
From: Max Kovgan mkov...@redhat.com 
To: devel@ovirt.org 
Cc: in...@ovirt.org 
Sent: Wednesday, June 3, 2015 8:22:54 PM 
Subject: [ovirt-devel] gerrit+ci improvement proposal 

Hi everyone! 
We really want to have reliable and snappy CI: to allow short 
cycles 
and 
encourage developers to write tests. 

# Problem 

Many patches are neither ready for review nor for CI upon 
submission, 
which 
is OK. 
But running all the jobs on those patches with limited 
resources 
results 
in: 
overloaded resources, slow response time, unhappy developers. 

# Proposed Solution 

To run less jobs we know we don’t need to, thus making more 
resources 
for 
the 
jobs we need to run. 
We have been experimenting to make our CI stabler and quicker 
to 
respond 
by 
using gerrit flags. This has improved in both directions very 
well 
internally. 
Now it seems a good time to let all the oVirt projects to use 
this. 
This solution indirectly promotes reviews and quick tests - 
“to 
fail 
early”, 
yet full blown static code analysis and long tests to run 
“when 
ready”. 

# How it works 

2 new gerrit independent flags are added to gerrit. 

## CI flag 

Will express patch CI status. Values: 
     * +1 CI passed 
     *  0 CI did not run yet 
     * -1 CI failed 
Permissions for setting: project maintainers (for special 
cases) 
should 
be 
able to set/override (except Jenkins). 

## Workflow flag 

Will express patch “workflow” state. Values: 
     *  0 Work In Progress 
     * +1 Ready For Review 
     * +2 Ready For Merge 
Permissions for setting: Owner can set +1, Project Maintainers 
can 
set 
+2 

## Review + CI Integration: 

Merging [“Submit” button to appear] will require: Review+1, 
CI+1, 
Workflow+2 
Patch lifecycle now is: 
---
 
patch state   |owner |reviewer |maintainer |CI tests |pass 
---
 
added/updated |- |-    |-  |quick    |CI+1 
review    |Workflow+1|Review+1 |-  |heavy |CI+1 
merge ready   |- |-    |Workflow+2 |gating   |CI+1 
merge |- |-    |merge  |merge    |CI+1 

Changes from current workflow: 
Owner only adds reviewers, now owner needs to set Workflow+1 
for 
the 
patch

Re: [ovirt-devel] gerrit+ci improvement proposal

[Oved Ourfali]

- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com
 Cc: in...@ovirt.org, devel@ovirt.org
 Sent: Thursday, June 4, 2015 9:46:40 AM
 Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
 
 
 
 - Original Message -
  From: Sandro Bonazzola sbona...@redhat.com
  To: Eyal Edri ee...@redhat.com, Max Kovgan mkov...@redhat.com
  Cc: devel@ovirt.org, in...@ovirt.org
  Sent: Thursday, June 4, 2015 9:11:10 AM
  Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
  
  Il 03/06/2015 21:46, Eyal Edri ha scritto:
   
   
   - Original Message -
   From: Max Kovgan mkov...@redhat.com
   To: devel@ovirt.org
   Cc: in...@ovirt.org
   Sent: Wednesday, June 3, 2015 8:22:54 PM
   Subject: [ovirt-devel] gerrit+ci improvement proposal
  
   Hi everyone!
   We really want to have reliable and snappy CI: to allow short cycles and
   encourage developers to write tests.
  
   # Problem
  
   Many patches are neither ready for review nor for CI upon submission,
   which
   is OK.
   But running all the jobs on those patches with limited resources results
   in:
   overloaded resources, slow response time, unhappy developers.
  
   # Proposed Solution
  
   To run less jobs we know we don’t need to, thus making more resources
   for
   the
   jobs we need to run.
   We have been experimenting to make our CI stabler and quicker to respond
   by
   using gerrit flags. This has improved in both directions very well
   internally.
   Now it seems a good time to let all the oVirt projects to use this.
   This solution indirectly promotes reviews and quick tests - “to fail
   early”,
   yet full blown static code analysis and long tests to run “when ready”.
  
   # How it works
  
   2 new gerrit independent flags are added to gerrit.
  
   ## CI flag
  
   Will express patch CI status. Values:
* +1 CI passed
*  0 CI did not run yet
* -1 CI failed
   Permissions for setting: project maintainers (for special cases) should
   be
   able to set/override (except Jenkins).
  
   ## Workflow flag
  
   Will express patch “workflow” state. Values:
*  0 Work In Progress
* +1 Ready For Review
* +2 Ready For Merge
   Permissions for setting: Owner can set +1, Project Maintainers can set
   +2
  
   ## Review + CI Integration:
  
   Merging [“Submit” button to appear] will require: Review+1, CI+1,
   Workflow+2
   Patch lifecycle now is:
   ---
   patch state   |owner |reviewer |maintainer |CI tests |pass
   ---
   added/updated |- |-|-  |quick|CI+1
   review|Workflow+1|Review+1 |-  |heavy |CI+1
   merge ready   |- |-|Workflow+2 |gating   |CI+1
   merge |- |-|merge  |merge|CI+1
  
   Changes from current workflow:
   Owner only adds reviewers, now owner needs to set Workflow+1 for the
   patch
   to be reviewed, and heavily auto-tested.
   Maintainer now needs to set Workflow+2 and wait for Submit button to
   appear after CI has completed running gating tests.
  
  
   Next step will be to automate merge the change after Workflow+2 has been
   set
   by the Maintainer and gating tests passed.
  
  
   ## Why now?
  
   It is elimination of waste. The sooner - the better.
   The solution has been used for a while and it works.
   Resolving the problem without gerrit involved will lead to adding
   unreliable
   code into jobs, and will still be prone to problems:
 Just recently, 3d ago we’ve tried detecting what to run from jenkins
 relying only on gerrit comments so that upon Verified+1, we’d run the
 job.
 We could not use “Review+1”, because it makes no sense at all, so we
 left
 the job to set Verified+1.
 Meaning - re-trigger itself immediately more than 1 times.
 
 Jenkins and its visitors very unhappy, and we had to stop those jobs,
 clean
 up the queue, and spam developers.
  
   ## OK OK OK. Now what?
  
   Now we want your comments and opinions before pushing this further:
   Please participate in this thread, so we can start trying it out.
   Ask, Suggest better ideas, all this is welcome.
  
  
   Best Regards!
  
  
   N.B.
   Of course, this is not written in stone, in case we find a better
   approach
   on
   solving those issues, we will change to it.
   And we will keep improving so don't be afraid that it will be enforced:
   if
   this does not work out we will discard it.
  
   P.S.
   Kudos to dcaro, most of the work was done by him, and most of this text
   too.
  
   
   +1 from me, releasing CI from running non critical and un-essential jobs
   will not only reduce load from ci,
   and shorted response time for developers, it will allow us to add much
   more
   powerful tests such as functional  system
   tests that actually add hosts and run VMs, improving 

Re: [ovirt-devel] hibernate's internal PersistentBag sent to FE

[Oved Ourfali]

- Original Message -
 From: Tomas Jelinek tjeli...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: Liran Zelkha lzel...@redhat.com, devel@ovirt.org
 Sent: Tuesday, June 2, 2015 9:59:17 AM
 Subject: Re: [ovirt-devel] hibernate's internal PersistentBag sent to FE
 
 
 
 - Original Message -
  From: Oved Ourfali ov...@redhat.com
  To: aw...@redhat.com
  Cc: Liran Zelkha lzel...@redhat.com, devel@ovirt.org
  Sent: Tuesday, June 2, 2015 8:35:56 AM
  Subject: Re: [ovirt-devel] hibernate's internal PersistentBag sent to FE
  
  top-posting:
  Due to the fact that we'll see that all over the place, I really think that
  it would be best to support that at the frontend level, and not the backend
  level.
 
 well, from philosophical perspective I think that sending
 org.hibernate.collection.**internal**.PersistentBag from backend to FE and
 than faking it's implementation on FE
 is a way to hell. It will bring lots of problems. For example the FE will be
 directly dependent on the internal structure of an internal hibernate class
 and if we update hibernate, FE can fail miserably.
 Also the FE patch (https://gerrit.ovirt.org/#/c/41682/1) seems to be more
 tricky than expected - it seems to be working but Omer had issues with it
 and in some cases (when the delegating also retainAll()) it caused my JRE to
 fail on SIGSEGV.
 It can be fixed on FE but it is a hack with all risks this kinds of hacks
 brings.
 
  Doing it in the backend level will cause a lot of overhead.
 
 Is it really lots of overhead? Comparing to all other layers the data has to
 pass anyway? When abandoning GWT FE and start to use REST we will anyway
 remove the GenericApiGWTServiceImpl which contains this cleaning
 (https://gerrit.ovirt.org/#/c/41810/).

I'm okay with doing this cleaning. Just not to propagate the fix to the 
business entities themselves (that's what I meant by saying in the backend 
level).


 
  I'll leave the technical details to the UX experts here to see what's the
  right approach to do it in the frontend side.
  
  Thanks,
  Oved
  
  - Original Message -
   From: Alexander Wels aw...@redhat.com
   To: Martin Perina mper...@redhat.com
   Cc: Liran Zelkha lzel...@redhat.com, devel@ovirt.org
   Sent: Tuesday, June 2, 2015 4:16:31 AM
   Subject: Re: [ovirt-devel] hibernate's internal PersistentBag sent to FE
   
   On Monday, June 01, 2015 10:51:28 AM Martin Perina wrote:
- Original Message -

 From: Alexander Wels aw...@redhat.com
 To: Tomas Jelinek tjeli...@redhat.com
 Cc: Liran Zelkha lzel...@redhat.com, devel@ovirt.org
 Sent: Monday, June 1, 2015 4:19:47 PM
 Subject: Re: [ovirt-devel] hibernate's internal PersistentBag sent to
 FE
 
 On Monday, June 01, 2015 09:33:07 AM Tomas Jelinek wrote:
  - Original Message -
  
   From: Alexander Wels aw...@redhat.com
   To: devel@ovirt.org
   Cc: Tomas Jelinek tjeli...@redhat.com, Liran Zelkha
   lzel...@redhat.com Sent: Monday, June 1, 2015 3:16:34 PM
   Subject: Re: [ovirt-devel] hibernate's internal PersistentBag
   sent
   to
   FE
   
   On Monday, June 01, 2015 09:08:50 AM Tomas Jelinek wrote:
Hey all,

since the org.ovirt.engine.core.common.job.Job/Step... has been
moved
to
use
the JPA we have a problem on frontend. The problem is that the
@OneToMany
annotations results in a List which is of type PersistentBag.
When
we
send
this to Frontend it fails during deserialization. It actually
fails
quite
bad because the FE already has an ui-override of it which is
not
correct
resulting in a ton of NPEs in development mode.

So, there are 2 nasty fixes I have made where none of them
should
be
merged
but demonstrate the possibilities: 1: extend the FE to be able
to
work
with
the PersistentBag (https://gerrit.ovirt.org/#/c/41682/) not
really
good
solution since the PersistenBag is an internal Hibernate class
which
is
really not meant to be passed around

2: fix on the backend to not send the PersistentBag but an
ArrayList.
This
is only a PoC fixed on a command we face the problem
(https://gerrit.ovirt.org/#/c/41797/) Obviously this is not
going
to
work
for other commands accessing the same Job nor for other
entities.

So, the first option is generic but very very bad. The second
option
should
be used but not sure how to do this in a cheep way (e.g.
without
using
reflection to deep traverse everything sent back to frontend
checking
if
it
does not have a PersistentBag in it.
   
   Tomas

Re: [ovirt-devel] API for executing commands on node?

[Oved Ourfali]

We don't have any API that allows that.
However, if you want you can use the shell in a box UI plugin
(see 
http://derezvir.blogspot.co.il/2013/01/ovirt-webadmin-shellinabox-ui-plugin.html).
But it requires manually installing something on the host as well.

It will allow you to connect to the host through the UI and run operations on 
it.

Regards,
Oved


- Original Message -
 From: Christopher Pereira krip...@imatronix.cl
 To: devel@ovirt.org
 Sent: Wednesday, June 3, 2015 8:52:09 AM
 Subject: [ovirt-devel] API for executing commands on node?
 
 Hi,
 
 What is the best practice to run custom console commands on a given
 oVirt host?
 Do we have some API for this?
 I need to pass arguments to this remote commands/scripts.
 
 ___
 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] Java 1.8

[Oved Ourfali]

On May 5, 2015 9:22 AM, Sandro Bonazzola sbona...@redhat.com wrote:

 Il 05/05/2015 08:15, Yedidyah Bar David ha scritto: 
  - Original Message - 
  From: knarra kna...@redhat.com 
  To: devel@ovirt.org 
  Cc: Stanislav Graf sg...@redhat.com 
  Sent: Tuesday, May 5, 2015 8:50:38 AM 
  Subject: [ovirt-devel] ovirt-engine replies with 503 Service Temporarily 
  Unavailable on fresh install 
  
  
  Hi, 
  
  From last Tuesday (Apr-28), I'm experiencing 
  ovirt-engine replies with 503 Service Temporarily Unavailable on fresh 
  install https://bugzilla.redhat.com/show_bug.cgi?id=1217023 I tried to 
  completely reinstall before filing BZ and the issue was reproducible. I 
  also 
  updated today my install with latest, still the same. 
  
  Am I alone who is hit by this BZ? Anything I could try? Should I reinstall 
  again tomorrow? 
  
  The mentioned bug does not seem very relevant. 
  
  After checking with Kasturi, it seems that he is trying to run it with 
  java-1.8.0-openjdk on RHEL6.6. 
  
  For now, unless you care about this, just remove and install 1.7. 
  
  Until the situation with 1.8 stabilizes, we might want to do something, not 
  sure exactly what - perhaps change the script java-home to not accept 1.8 
  for now (and people that want to test that will have to override by having 
  there 
  a trivial java-home.local pointing at their 1.8 home), or make engine-setup 
  notice and prompt, whatever. 
  

 Adding Oved: are we going to use 1.7 or 1.8 on EL6/EL7 ? 
 On Fedora we only have 1.8 so there we can't enforce 1.7. 
 Maybe we can use a config file enforcing the java home on EL6/7 as we do with 
 JBoss. 


The plan is to work with 1.7, although 1.8 should work as well. 

Oved

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

Re: [ovirt-devel] oVirt Glance repository

[Oved Ourfali]

Hi

I've created the glance repository, and I'll be happy to upload images once 
these are ready.
I currently don't have the capacity to create and verify different images, but 
if someone can chime in I'll be more than happy to assist and guide.
In addition, I've verified each image with cloud-init (and surprisingly some 
images that aren't on the list below didn't work well with cloud-init), so one 
should do this verification before suggesting an image to add.

Regards,
Oved


- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: devel@ovirt.org
 Sent: Wednesday, April 1, 2015 12:37:20 PM
 Subject: [ovirt-devel] oVirt Glance repository
 
 Hi,
 not sure about who's maintaining the oVirt Glance repository, but I see
 
 Fedora 19 32-Bit (6975f6e)Disk797 MB
 CirrOS 0.3.1 (73786f4)Disk12 MB
 CentOS 6.5 64-Bit (7df3c30)   Disk1 GB
 Fedora 19 64-Bit (865bfac)Disk858 MB
 Neutron Appliance (CentOS 7.0) - IceHouse-2014.1.1-3 (960d964)Disk
 682 MB
 Fedora 20 Project Atomic Image (a62ba67)  Disk847 MB
 CentOS 6.5 64-Bit Docker (b485e50)Disk1 GB
 
 I really think it should be refreshed with more recent distributions to be
 useful.
 
 --
 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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status (building RC2 today!)

[Oved Ourfali]

On Mar 18, 2015 9:57 AM, Sandro Bonazzola sbona...@redhat.com wrote:

 Hi, 
 we still have 5 open blockers for 3.5.2[1]: 

 Bug ID Whiteboard Status Summary 
 1161012 infra POST task cleaning utility  should erase commands that have 
 running tasks 

Simone, latest comment by you implies that it is working now with the latest 
patches. All appear in the bugzilla as merged. Should it move to modified? 

 1187244 network POST [RHEL  7.0 + 7.1] Host configure with DHCP is losing 
 connectivity after some time - dhclient is not running 
 1177220 storage ASSIGNED [BLOCKED] Failed to Delete First snapshot with live 
 merge 
 1196327 virt ASSIGNED [performance] bad getVMList output creates unnecessary 
 calls from Engine 
 1202360 virt POST [performance] bad getVMList output creates unnecessary 
 calls from Engine 

 And 2 dependency on libvirt not yet fixed: 
 Bug ID Status Summary 
 1199182 POST 2nd active commit after snapshot triggers qemu failure 
 1199036 POST Libvirtd was restarted when do active blockcommit while there is 
 a blockpull job running 

 ACTION: Assignee to provide ETA for the blocker bug. 

 Despite the blockers bug count, we're going to build RC2 today 2015-03-18 at 
 12:00 UTC for allowing the verification of fixed bugs and testing on 
 CentOS 7.1. 
 If you're going to test this release candidate on CentOS please be sure to 
 have the CR[2] repository enabled and system fully updated to CentOS 7.1. 

 We still have 7 bugs in MODIFIED and 31 on QA[3]: 

 MODIFIED ON_QA Total 
 infra 2 10 12 
 integration 0 2 2 
 network 0 2 2 
 node 0 1 1 
 sla 2 1 3 
 storage 3 11 14 
 virt 0 4 4 
 Total 7 31 38 

 ACTION: Testers: you're welcome to verify bugs currently ON_QA. 

 All remaining bugs not marked as blockers have been moved to 3.5.3. 
 A release management entry has been added for tracking the schedule of 
 3.5.3[4] 
 A bug tracker [5] has been created for 3.5.3. 
 We have 32 bugs currently targeted to 3.5.3[6]: 

 Whiteboard NEW ASSIGNED POST Total 
 docs 2 0 0 2 
 external 1 0 0 1 
 gluster 4 0 1 5 
 infra 2 2 0 4 
 node 2 0 1 3 
 ppc 0 0 1 1 
 sla 4 0 0 4 
 storage 8 0 0 8 
 ux 1 0 1 2 
 virt 1 0 1 2 
 Total 25 2 5 32 


 ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 ensuring 
 they're correctly targeted. 
 ACTION: Maintainers: to fill release notes for 3.5.2, the page has been 
 created and updated here [7] 
 ACTION: Testers: please add yourself to the test page [8] 

 7 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch 
 according to Change-Id 

 commit 6b5a8169093357656d3e638c7018ee516d1f44bd 
 Author: Maor Lipchuk mlipc...@redhat.com 
 Date:   Thu Feb 19 14:40:23 2015 +0200 
     core: Add validation when Storage Domain is blocked. 
     Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f 

 commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325 
 Author: Maor Lipchuk mlipc...@redhat.com 
 Date:   Sun Mar 1 17:17:16 2015 +0200 
     restapi: reconfigure values on import data Storage Domain. 
     Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b 

 commit 4283f755e6b77995247ecb9ddd904139bc8c322c 
 Author: Maor Lipchuk mlipc...@redhat.com 
 Date:   Tue Mar 10 12:05:05 2015 +0200 
     restapi: Quering FCP unregistered Storage Domains 
     Change-Id: Iafe2f2afcd0e6e68ad2054c857388acc30a7 

 commit a3d8b687620817b38a64a3917f4440274831bca3 
 Author: Maor Lipchuk mlipc...@redhat.com 
 Date:   Wed Feb 25 17:00:47 2015 +0200 
     core: Add fk constraint on vm_interface_statistics 
     Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8 

 commit c8caaceb6b1678c702961d298b3d6c48183d9390 
 Author: emesika emes...@redhat.com 
 Date:   Mon Mar 9 18:01:58 2015 +0200 
     core: do not use distinct if sort expr have func 
     Change-Id: I7c036b2b9ee94266b6e3df54f2c50167e454ed6a 

 commit 4332194e55ad40eee423e8611eceb95fd59dac7e 
 Author: Vered Volansky vvola...@redhat.com 
 Date:   Thu Mar 12 17:38:35 2015 +0200 
     webadmin: Fix punctuation in threshold warnings 
     Change-Id: If30f094e52f42b78537e215a2699cf74c248bd83 

 commit 773f2a108ce18e0029f864c8748d7068b71f8ff3 
 Author: Maor Lipchuk mlipc...@redhat.com 
 Date:   Sat Feb 28 11:37:26 2015 +0200 
     core: Add managed devices to OVF 
     Change-Id: Ie0e912c9b2950f1461ae95f4704f18b818b83a3b 

 ACTION: Authors please verify they're not meant to be targeted to 3.5.2. 


 [1] https://bugzilla.redhat.com/1186161 
 [2] http://mirror.centos.org/centos/7/cr/x86_64/ 
 [3] http://goo.gl/UEVTCf 
 [4] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.3 
 [5] https://bugzilla.redhat.com/1198142 
 [6] 
 https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20target_release%3A3.5.3
  
 [7] http://www.ovirt.org/OVirt_3.5.2_Release_Notes 
 [8] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing 

 -- 
 Sandro Bonazzola 
 Better technology. Faster innovation. Powered by community collaboration. 
 See how it works at redhat.com 
 ___ 
 

Re: [ovirt-devel] [ovirt-users] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status

[Oved Ourfali]

- Original Message -
 From: Oved Ourfali ov...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com
 Cc: devel@ovirt.org, us...@ovirt.org
 Sent: Wednesday, March 11, 2015 2:55:29 PM
 Subject: Re: [ovirt-users] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status
 
 
 
 - Original Message -
  From: Sandro Bonazzola sbona...@redhat.com
  To: Amit Aviram aavi...@redhat.com, Adam Litke ali...@redhat.com,
  Yedidyah Bar David d...@redhat.com,
  Ido Barkan ibar...@redhat.com, Martin Perina mper...@redhat.com,
  Tal Nisan tni...@redhat.com, Maor
  Lipchuk mlipc...@redhat.com, Eyal Edri ee...@redhat.com,
  us...@ovirt.org, devel@ovirt.org
  Sent: Wednesday, March 11, 2015 2:33:50 PM
  Subject: [ovirt-users] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status
  
  Hi,
  We still have 8 open blockers for 3.5.2[1]:
  
  Bug ID  Whiteboard  Status  Summary
  1195119 infra   POST[backend] [NPE] Adding 
  permission to an object fails
  if
  DEBUG level is set
 
 Will be in by the end of tomorrow noon.
 

Item is on MODIFIED now.

  1190466 integration NEW HEAP_MAX default value as 1G 
  must be changed
  1187244 network NEW [RHEL  7.0 + 7.1] Host 
  configure with DHCP is losing
  connectivity after some time - dhclient is not running
  1176581 storage ASSIGNEDStorage Tab - import Domain - 
  help button is
  missing
  1176582 storage ASSIGNEDTemplates tab - export 
  template - help leads to
  exporting VM
  1176583 storage ASSIGNEDStorage tab- ISO Domain - 
  Data Center - Attach
  - help button is missing
  1177220 storage ASSIGNED[BLOCKED] Failed to Delete 
  First NFS snapshot
  with
  live merge
  1197292 storage POST[3.5-7.1] Failed to retrieve 
  iscsi lun from hardware
  iscsi after register to RHEV-M
  
  
  ACTION: Assignee to provide ETA for the blocker bug.
  
  We also had 5 blockers fixed since 3.5.2 RC1[2] so a new RC and GA has been
  rescheduled as release criteria for RC1 are not met.
  2015-03-18  2nd Release candidate
  2015-04-02  General availability
  
  
  We still have 7 bugs in MODIFIED and 48 on QA[8]:
  
  Whiteboard  MODIFIEDON_QA   Total
  infra   2   19  21
  integration 0   4   4
  network 0   2   2
  node0   1   1
  sla 2   2   4
  storage 3   13  16
  virt0   7   7
  Total   7   48  55
  
  
  ACTION: Maintainers/Assignee: please move bugs to ON_QA if they're included
  in 3.5.2 RC1
  ACTION: Testers: you're welcome to verify bugs currently ON_QA.
  
  
  All remaining bugs not marked as blockers have been moved to 3.5.3.
  A release management entry has been added for tracking the schedule of
  3.5.3[3]
  A bug tracker [4] has been created for 3.5.3.
  We have 33 bugs currently targeted to 3.5.3[5]:
  
  Whiteboard  NEW ASSIGNEDPOSTTotal
  doc 1   0   0   1
  docs1   0   0   1
  external1   0   0   1
  gluster 4   0   1   5
  infra   2   2   0   4
  network 0   1   0   1
  node3   0   1   4
  ppc 0   0   1   1
  sla 4   0   0   4
  storage 8   0   0   8
  ux  0   0   1   1
  virt1   0   1   2
  Total   25  3   5   33
  
  
  ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3
  ensuring
  they're correctly targeted.
  ACTION: Maintainers: to fill release notes for 3.5.2, the page has been
  created and updated here [6]
  ACTION: Testers: please add yourself to the test page [7]
  
  4 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch
  according to Change-Id
  
  commit 6b5a8169093357656d3e638c7018ee516d1f44bd
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Thu Feb 19 14:40:23 2015 +0200
  core: Add validation when Storage Domain is blocked.
  Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f
  
  commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Sun Mar 1 17:17:16 2015 +0200
  restapi: reconfigure values on import data Storage Domain.
  Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b
  
  commit a3d8b687620817b38a64a3917f4440274831bca3
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Wed Feb 25 17:00:47 2015 +0200
  core: Add fk constraint on vm_interface_statistics
  Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8
  
  commit

Re: [ovirt-devel] [ovirt-users] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status

[Oved Ourfali]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: Amit Aviram aavi...@redhat.com, Adam Litke ali...@redhat.com, 
 Yedidyah Bar David d...@redhat.com,
 Ido Barkan ibar...@redhat.com, Martin Perina mper...@redhat.com, Tal 
 Nisan tni...@redhat.com, Maor
 Lipchuk mlipc...@redhat.com, Eyal Edri ee...@redhat.com, 
 us...@ovirt.org, devel@ovirt.org
 Sent: Wednesday, March 11, 2015 2:33:50 PM
 Subject: [ovirt-users] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status
 
 Hi,
 We still have 8 open blockers for 3.5.2[1]:
 
 Bug IDWhiteboard  Status  Summary
 1195119   infra   POST[backend] [NPE] Adding 
 permission to an object fails if
 DEBUG level is set

Will be in by the end of tomorrow noon.

 1190466   integration NEW HEAP_MAX default value as 1G 
 must be changed
 1187244   network NEW [RHEL  7.0 + 7.1] Host 
 configure with DHCP is losing
 connectivity after some time - dhclient is not running
 1176581   storage ASSIGNEDStorage Tab - import Domain - 
 help button is
 missing
 1176582   storage ASSIGNEDTemplates tab - export 
 template - help leads to
 exporting VM
 1176583   storage ASSIGNEDStorage tab- ISO Domain - 
 Data Center - Attach
 - help button is missing
 1177220   storage ASSIGNED[BLOCKED] Failed to Delete 
 First NFS snapshot with
 live merge
 1197292   storage POST[3.5-7.1] Failed to retrieve 
 iscsi lun from hardware
 iscsi after register to RHEV-M
 
 
 ACTION: Assignee to provide ETA for the blocker bug.
 
 We also had 5 blockers fixed since 3.5.2 RC1[2] so a new RC and GA has been
 rescheduled as release criteria for RC1 are not met.
 2015-03-182nd Release candidate
 2015-04-02General availability
 
 
 We still have 7 bugs in MODIFIED and 48 on QA[8]:
 
 WhiteboardMODIFIEDON_QA   Total
 infra 2   19  21
 integration   0   4   4
 network   0   2   2
 node  0   1   1
 sla   2   2   4
 storage   3   13  16
 virt  0   7   7
 Total 7   48  55
 
 
 ACTION: Maintainers/Assignee: please move bugs to ON_QA if they're included
 in 3.5.2 RC1
 ACTION: Testers: you're welcome to verify bugs currently ON_QA.
 
 
 All remaining bugs not marked as blockers have been moved to 3.5.3.
 A release management entry has been added for tracking the schedule of
 3.5.3[3]
 A bug tracker [4] has been created for 3.5.3.
 We have 33 bugs currently targeted to 3.5.3[5]:
 
 WhiteboardNEW ASSIGNEDPOSTTotal
 doc   1   0   0   1
 docs  1   0   0   1
 external  1   0   0   1
 gluster   4   0   1   5
 infra 2   2   0   4
 network   0   1   0   1
 node  3   0   1   4
 ppc   0   0   1   1
 sla   4   0   0   4
 storage   8   0   0   8
 ux0   0   1   1
 virt  1   0   1   2
 Total 25  3   5   33
 
 
 ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 ensuring
 they're correctly targeted.
 ACTION: Maintainers: to fill release notes for 3.5.2, the page has been
 created and updated here [6]
 ACTION: Testers: please add yourself to the test page [7]
 
 4 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch
 according to Change-Id
 
 commit 6b5a8169093357656d3e638c7018ee516d1f44bd
 Author: Maor Lipchuk mlipc...@redhat.com
 Date:   Thu Feb 19 14:40:23 2015 +0200
 core: Add validation when Storage Domain is blocked.
 Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f
 
 commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325
 Author: Maor Lipchuk mlipc...@redhat.com
 Date:   Sun Mar 1 17:17:16 2015 +0200
 restapi: reconfigure values on import data Storage Domain.
 Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b
 
 commit a3d8b687620817b38a64a3917f4440274831bca3
 Author: Maor Lipchuk mlipc...@redhat.com
 Date:   Wed Feb 25 17:00:47 2015 +0200
 core: Add fk constraint on vm_interface_statistics
 Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8
 
 commit 773f2a108ce18e0029f864c8748d7068b71f8ff3
 Author: Maor Lipchuk mlipc...@redhat.com
 Date:   Sat Feb 28 11:37:26 2015 +0200
 core: Add managed devices to OVF
 Change-Id: Ie0e912c9b2950f1461ae95f4704f18b818b83a3b
 
 ACTION: Maor Lipchuk please verify they're not meant to be targeted to 3.5.2.
 
 
 [1] https://bugzilla.redhat.com/1186161
 [2]
 

[ovirt-devel] Proposing Sahina Bose as oVirt core maintainer

[Oved Ourfali]

Hi all!

I would like to propose Sahina Bose as an engine-core maintainer, with regards 
to Gluster related code.
Sahina joined the oVirt project two years ago, and has since contributed over 
150 patches, and has been instrumental in reviews of all Gluster patches.

Will appreciate your response!

Thanks,
Oved
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [QE][ACTION NEEDED] oVirt 3.5.2 RC status - postponing

[Oved Ourfali]

On Feb 24, 2015 4:54 PM, Sandro Bonazzola sbona...@redhat.com wrote:

 Hi, 
 We still have one open blocker for 3.5.2[1]: 

 Bug ID Whiteboard Status Summary 
 1161012 infra POST task cleaning utility  should erase commands that have 
 running tasks 


Yair and Simone, what's blocking this one from getting merged? 

 We need to postpone the RC until this will be fixed. 
 The patch is already under review and verification so it shouldn't take too 
 much. 


 There are still 48 bugs [2] targeted to 3.5.2. 
 Excluding node and documentation bugs we still have 42 bugs [3] targeted to 
 3.5.2. 

 Whiteboard NEW ASSIGNED POST Total 
 doc 1 0 0 1 
 docs 1 0 0 1 
 gluster 4 0 1 5 
 infra 4 2 8 14 
 integration 0 0 1 1 
 network 1 1 0 2 
 node 4 0 1 5 
 ppc 0 0 1 1 
 sla 4 0 0 4 
 storage 11 0 0 11 
 ux 1 0 0 1 
 virt 1 0 1 2 
 Total 32 3 13 48 


 Maintainers / Assignee: 
 - Please add the bugs to the tracker if you think that 3.5.2 should not be 
 released without them fixed. 
 - Please update the target to 3.5.3 or later for bugs that won't be in 3.5.2: 
   it will ease gathering the blocking bugs for next releases. 
 - Please fill release notes, the page has been created and updated here [4] 

 Community: 
 - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the 
 test page [5] 

 [1] http://bugzilla.redhat.com/1186161 
 [2] http://goo.gl/crVJPH 
 [3] http://goo.gl/2qTZZU 
 [4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes 
 [5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing 

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

Re: [ovirt-devel] Fwd: Gerrit update

[Oved Ourfali]

Didn't get to that yet.

Thanks for the quick response!
Oved

- Original Message -
 From: David Caro dcaro...@redhat.com
 To: devel@ovirt.org
 Sent: Monday, February 23, 2015 8:33:57 AM
 Subject: [ovirt-devel] Fwd: Gerrit update
 
 
 I sent it only to infra :/
 
 - Forwarded message from David Caro dcaro...@redhat.com -
 
  From: David Caro dcaro...@redhat.com
  To: Infra in...@ovirt.org
  Date: Mon, 23 Feb 2015 07:30:27 +0100
  Subject: Gerrit update
  User-Agent: Mutt/1.5.22.1 (2013-10-16)
  
  
  Hi everyone!
  
  As of right now, gerrit is being updated to 2.10 [1] I will notice when
  it's
  ready, in the meantime you (or jenkins) will not be able to use it.
  
  
  
  Cheers!
  
  
  --
  David Caro
  
  Red Hat S.L.
  Continuous Integration Engineer - EMEA ENG Virtualization RD
  
  Tel.: +420 532 294 605
  Email: dc...@redhat.com
  Web: www.redhat.com
  RHT Global #: 82-62605
 
 
 
  ___
  Infra mailing list
  in...@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/infra
 
 
 - End forwarded message -
 
 --
 David Caro
 
 Red Hat S.L.
 Continuous Integration Engineer - EMEA ENG Virtualization RD
 
 Tel.: +420 532 294 605
 Email: dc...@redhat.com
 Web: www.redhat.com
 RHT Global #: 82-62605
 
 ___
 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] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6

[Oved Ourfali]

On Feb 11, 2015 10:49 PM, Michael Burman mbur...@redhat.com wrote:

 Hello Yaniv and all! 

 So i did this: 
 I tried to install clean rhel7.1 host with the right libvirt 
 version(libvirt-1.2.8-16.el7.x86_64,vdsm-4.17.0-394.gitb237397.el7.x86_64) 
 and failed to join this host under 3.6 cluster. 
 Host red-vds2.qa.lab.tlv.redhat.com is compatible with versions 
 (3.0,3.1,3.2,3.3,3.4,3.5) and cannot join Cluster mb3.6 which is set to 
 version 3.6. 
 After failing i checked the /usr/share/vdsm/dsaversion.py and saw that: 
 version_info = { 
     'version_name': version_name, 
     'software_version': software_version, 
     'software_revision': software_revision, 
     'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'], 
     'supportedProtocols': ['2.2', '2.3'], 
     'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'], 

 So i added the 3.6 for cluster levels and engine support lines, restarted 
 vdsm and finally managed to join my rhel7.1 host to 3.6 Cluster. 

 All of this means that rhel7.1 hosts with vdsm 4.17.0 and libvirt version 
 -libvirt-1.2.8-16.el7.x86_64 are still not supported by default for 3.6 
 clusters and dsaversion.py file must be edited manually in order to join to 
 cluster 3.6. 
 I guess this must be changed. 


+1 on that one. 

 Best regards, 
 Michael B 


 - Original Message - 
 From: Michael Burman mbur...@redhat.com 
 To: ybronhei ybron...@redhat.com 
 Cc: devel@ovirt.org, in...@ovirt.org 
 Sent: Monday, February 9, 2015 10:50:28 AM 
 Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) 
 to Cluster 3.6 

 Thank you all! 

 Ok, so how can i get this right libvirt version for rhel7? not7.1 and without 
 any dependencies issues?? 
 I want to join rhel7 host, with the right libvirt version to 3.6 cluster..is 
 it possible? 

 Michael B 


 - Original Message - 
 From: ybronhei ybron...@redhat.com 
 To: Oved Ourfali oourf...@redhat.com, Sandro Bonazzola 
 sbona...@redhat.com, Dan Kenigsberg dan...@redhat.com 
 Cc: in...@ovirt.org, devel@ovirt.org, Michael Burman mbur...@redhat.com 
 Sent: Monday, February 9, 2015 10:03:56 AM 
 Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) 
 to Cluster 3.6 

 On 02/09/2015 08:35 AM, Oved Ourfali wrote: 
  
  On Feb 9, 2015 9:31 AM, Sandro Bonazzola sbona...@redhat.com wrote: 
  
  Il 08/02/2015 16:15, Michael Burman ha scritto: 
  Hi everyone! 
  
  Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6 
  Cluster?? 
  I know that the libvirt version is not supported, but isn't should be? 
  even if it's rhel7..? 
  
  I changed the /usr/share/vdsm/dsaversion.py file to: 
  'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'], 
    'supportedProtocols': ['2.2', '2.3'], 
    'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'], 
  
  But caps.py is still: 
  if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'): 
    return _dropVersion('3.6', 
    'VIR_MIGRATE_AUTO_CONVERGE not found in 
 libvirt,' 
    ' support for clusterLevel = 3.6 is 
 disabled.' 
    ' For Fedora 20 users, please consider 
 upgrading' 
    ' libvirt from the virt-preview 
 repository') 
  
    if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'): 
    return _dropVersion('3.6', 
    'VIR_MIGRATE_COMPRESSED not found in 
 libvirt,' 
    ' support for clusterLevel = 3.6 is 
 disabled.' 
    ' For Fedora 20 users, please consider 
 upgrading' 
    ' libvirt from the virt-preview 
 repository') 
  
  libvirt is still disabled for 3.6 clusters... 
  
  
  I already tried to rebuild from fedora(with Sandro appreciated help), but 
  had a lot of issues dependencies. 
  
  I'm running on- 
  ovirt-engine-3.6.0-0.0.master.20150206122208.gitd429375.el6.noarch 
  vdsm-4.17.0-390.gita3163f3.el7.x86_64 
  libvirt-1.1.1-29.el7_0.7.x86_64 
  
  I would like to know if and when it will be possible to join rhel7 
  host(vdsm-4.17.0) to Cluster 3.6? 
  
  Moving to devel list, not really an infra issue. 
  
  
  Yaniv, you had a patch for that, but it was abandoned. Why? 
 because we don't need it- i explained there 
 the cluster check is only after the supportedVDSMVersion does not catch. 
 we failed to add the host to the cluster because the libvirt version . 
 as it is now, with the right versions, you should be able to add vdsm 
 4.17 to lastest engine regardless the cluster level 
  
  
  Best regards, 
  
  Michael B 
  
  
  
  
  
  -- 
  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] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6

[Oved Ourfali]

On Feb 9, 2015 9:31 AM, Sandro Bonazzola sbona...@redhat.com wrote:

 Il 08/02/2015 16:15, Michael Burman ha scritto: 
  Hi everyone! 
  
  Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6 
  Cluster?? 
  I know that the libvirt version is not supported, but isn't should be? even 
  if it's rhel7..? 
  
  I changed the /usr/share/vdsm/dsaversion.py file to: 
  'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'], 
  'supportedProtocols': ['2.2', '2.3'], 
  'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'], 
  
  But caps.py is still: 
  if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'): 
  return _dropVersion('3.6', 
  'VIR_MIGRATE_AUTO_CONVERGE not found in 
 libvirt,' 
  ' support for clusterLevel = 3.6 is disabled.' 
  ' For Fedora 20 users, please consider 
 upgrading' 
  ' libvirt from the virt-preview repository') 
  
  if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'): 
  return _dropVersion('3.6', 
  'VIR_MIGRATE_COMPRESSED not found in libvirt,' 
  ' support for clusterLevel = 3.6 is disabled.' 
  ' For Fedora 20 users, please consider 
 upgrading' 
  ' libvirt from the virt-preview repository') 
  
  libvirt is still disabled for 3.6 clusters... 
  
  
  I already tried to rebuild from fedora(with Sandro appreciated help), but 
  had a lot of issues dependencies. 
  
  I'm running on- 
  ovirt-engine-3.6.0-0.0.master.20150206122208.gitd429375.el6.noarch 
  vdsm-4.17.0-390.gita3163f3.el7.x86_64 
  libvirt-1.1.1-29.el7_0.7.x86_64 
  
  I would like to know if and when it will be possible to join rhel7 
  host(vdsm-4.17.0) to Cluster 3.6? 

 Moving to devel list, not really an infra issue. 


Yaniv, you had a patch for that, but it was abandoned. Why? 

  
  Best regards, 
  
  Michael B 
  
  
  


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

Re: [ovirt-devel] Adding support for 3.6 in engine database

[Oved Ourfali]

- Original Message -
 From: Dan Kenigsberg dan...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: engine-de...@ovirt.org devel@ovirt.org
 Sent: Wednesday, January 14, 2015 5:03:12 PM
 Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
 
 On Wed, Jan 14, 2015 at 08:19:00AM -0500, Oved Ourfali wrote:
  
  
  - Original Message -
   From: Dan Kenigsberg dan...@redhat.com
   To: Oved Ourfali ov...@redhat.com, fsimo...@redhat.com
   Cc: engine-de...@ovirt.org devel@ovirt.org
   Sent: Wednesday, January 14, 2015 3:15:02 PM
   Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
   
   On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote:


- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Lior Vernia lver...@redhat.com, Oved Ourfali
 oourf...@redhat.com
 Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg
 dan...@redhat.com, Yaniv Bronheim
 ybron...@redhat.com
 Sent: Thursday, January 8, 2015 3:41:31 PM
 Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
 
 
 
 - Original Message -
  From: Lior Vernia lver...@redhat.com
  To: Eli Mesika emes...@redhat.com
  Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg
  dan...@redhat.com, Yaniv Bronheim
  ybron...@redhat.com
  Sent: Thursday, January 8, 2015 3:08:24 PM
  Subject: Re: [ovirt-devel] Adding support for 3.6 in engine
  database
  
  Tried to work with it, and noticed that:
  1. The engine doesn't list 4.17 as a supported vdsm version.
  2. 4.17 vdsm doesn't report 3.6 as a supported engine version.
  
  This basically means that no host could be operational in a 3.6
  cluster,
  as to my understanding 4.17 is exactly the version supporting 3.6
  functionality.
  
  May I send a fix for (1), or is there any argument against? And who
  could take care of (2)?
 
 I had understood deom Oved that this is 4.16 see patch
 http://gerrit.ovirt.org/#/c/36511/
 Oved ???
 

I don't know when we should add 4.17. I remember there is some policy
for
that.
Dan?
   
   Yes, there is.
   
   Vdsm would like to declare its support of clusterLevel 3.6 only when it
   actually does. This is not yet the case, as we are not yet in 3.6
   feature freeze (heck, we're not yet in feature definition).
   
   To test cluster level 3.6 on the master branch, someone has to lie.
   
   It may be Vdsm (by claiming that it supports 3.6 while it does
   not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it
   does not).
   
   I prefer the latter, as the Engine-side hack is eaiser to undo on a
   distributed system. If today's Vdsm claims that it already support 3.6,
   future Engines would add it to their cluster, only to find that random
   APIs fails. If the hack is Engine-side, it would be gone when 3.6
   reaches feature freeze.
   
  
  We don't have a mechanism to allow specific version of VDSM to a specific
  cluster level.
  For this we only rely on the reported supported cluster levels.
 
 I know. I'm asking Engine to add it.

The logic in the engine is complex and confusing enough, without adding any 
other configuration to it, so I prefer to leave it as is.
I don't see why we can't add the cluster levels to the supported VDSM cluster 
levels, as we didn't release any official VDSM version yet, so what's the issue 
with that?
The fact that engine master has 3.6 cluster level doesn't mean it is supported 
either. It will be once 3.6 is released.

 ___
 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] Adding support for 3.6 in engine database

[Oved Ourfali]

- Original Message -
 From: Dan Kenigsberg dan...@redhat.com
 To: Oved Ourfali ov...@redhat.com, fsimo...@redhat.com
 Cc: engine-de...@ovirt.org devel@ovirt.org
 Sent: Wednesday, January 14, 2015 3:15:02 PM
 Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
 
 On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote:
  
  
  - Original Message -
   From: Eli Mesika emes...@redhat.com
   To: Lior Vernia lver...@redhat.com, Oved Ourfali
   oourf...@redhat.com
   Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg
   dan...@redhat.com, Yaniv Bronheim
   ybron...@redhat.com
   Sent: Thursday, January 8, 2015 3:41:31 PM
   Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
   
   
   
   - Original Message -
From: Lior Vernia lver...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg
dan...@redhat.com, Yaniv Bronheim
ybron...@redhat.com
Sent: Thursday, January 8, 2015 3:08:24 PM
Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database

Tried to work with it, and noticed that:
1. The engine doesn't list 4.17 as a supported vdsm version.
2. 4.17 vdsm doesn't report 3.6 as a supported engine version.

This basically means that no host could be operational in a 3.6
cluster,
as to my understanding 4.17 is exactly the version supporting 3.6
functionality.

May I send a fix for (1), or is there any argument against? And who
could take care of (2)?
   
   I had understood deom Oved that this is 4.16 see patch
   http://gerrit.ovirt.org/#/c/36511/
   Oved ???
   
  
  I don't know when we should add 4.17. I remember there is some policy for
  that.
  Dan?
 
 Yes, there is.
 
 Vdsm would like to declare its support of clusterLevel 3.6 only when it
 actually does. This is not yet the case, as we are not yet in 3.6
 feature freeze (heck, we're not yet in feature definition).
 
 To test cluster level 3.6 on the master branch, someone has to lie.
 
 It may be Vdsm (by claiming that it supports 3.6 while it does
 not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it
 does not).
 
 I prefer the latter, as the Engine-side hack is eaiser to undo on a
 distributed system. If today's Vdsm claims that it already support 3.6,
 future Engines would add it to their cluster, only to find that random
 APIs fails. If the hack is Engine-side, it would be gone when 3.6
 reaches feature freeze.
 

We don't have a mechanism to allow specific version of VDSM to a specific 
cluster level.
For this we only rely on the reported supported cluster levels.

 Dan.
 ___
 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] [ovirt-users] [Feature review] Select network to be used for glusterfs

[Oved Ourfali]

Hi Sahina,

Some comments:

1. As far as I understand, you might not have an IP available immediately after 
setupNetworks runs (getCapabilities should run, but it isn't run automatically, 
afair).
2. Perhaps you should pass not the IP but the name of the network? IPs might 
change.
3. Adding to 2, perhaps using DNS names is a more valid approach?
4. You're using the terminology role, but it might be confusing, as we have 
roles with regards to permissions. Consider changing storage usage and not 
storage role in the feature page.

Thanks,
Oved

- Original Message -
 From: Sahina Bose sab...@redhat.com
 To: devel@ovirt.org, users us...@ovirt.org
 Sent: Monday, January 12, 2015 2:00:16 PM
 Subject: [ovirt-users] [Feature review] Select network to be used for 
 glusterfs
 
 Hi all,
 
 Please review the feature page for this proposed solution and provide
 your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
 
 thanks
 sahina
 
 
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Adding support for 3.6 in engine database

[Oved Ourfali]

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Lior Vernia lver...@redhat.com, Oved Ourfali oourf...@redhat.com
 Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg 
 dan...@redhat.com, Yaniv Bronheim
 ybron...@redhat.com
 Sent: Thursday, January 8, 2015 3:41:31 PM
 Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
 
 
 
 - Original Message -
  From: Lior Vernia lver...@redhat.com
  To: Eli Mesika emes...@redhat.com
  Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg
  dan...@redhat.com, Yaniv Bronheim
  ybron...@redhat.com
  Sent: Thursday, January 8, 2015 3:08:24 PM
  Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
  
  Tried to work with it, and noticed that:
  1. The engine doesn't list 4.17 as a supported vdsm version.
  2. 4.17 vdsm doesn't report 3.6 as a supported engine version.
  
  This basically means that no host could be operational in a 3.6 cluster,
  as to my understanding 4.17 is exactly the version supporting 3.6
  functionality.
  
  May I send a fix for (1), or is there any argument against? And who
  could take care of (2)?
 
 I had understood deom Oved that this is 4.16 see patch
 http://gerrit.ovirt.org/#/c/36511/
 Oved ???
 

I don't know when we should add 4.17. I remember there is some policy for 
that.
Dan?

 
  
  Yours, Lior.
  
  On 07/01/15 14:53, Eli Mesika wrote:
   Hi
   
   Please note that 3.6 version support was added to master, default
   DC/Cluster are created now with 3.6 and all config changes we applied.
   For more information : http://gerrit.ovirt.org/#/c/36518/
   
   Thanks
   Eli Mesika
   
   ___
   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] Creating a new gerrit flag

[Oved Ourfali]

What happens when rebasing?
We can't afford waiting for tests to run on each rebase... as we might end up 
rebasing forever.

- Original Message -
 From: David Caro dcaro...@redhat.com
 To: devel@ovirt.org, in...@ovirt.org
 Sent: Tuesday, December 9, 2014 11:43:04 AM
 Subject: [ovirt-devel] Creating a new gerrit flag
 
 Hi!
 
 e have been having an issue with gerrit patches being merged before
 jenkins ran any tests on them, to avoid it from happening again I
 propose creating a new gerrit flag (Tests) with the following
 specifics:
 
 
 +1 - Tests passed/overrided
  0 - Tests pending
 -1 - Tests broken
 
 where +1 is required to submit, +1 is set by jenkins when
 passing the tests and -1 is set by jenkins in case it breaks any
 tests. The +1 flag can be set also by maintainers to allow overriding
 the process.
 
 That way all the tests will be blocked until someone (hopefully
 jenkins) adds the +1 flag, but if the maintainer wants to override the
 value, she just has to set that flag herself.
 
 
 What do you think?
 
 
 --
 David Caro
 
 Red Hat S.L.
 Continuous Integration Engineer - EMEA ENG Virtualization RD
 
 Tel.: +420 532 294 605
 Email: dc...@redhat.com
 Web: www.redhat.com
 RHT Global #: 82-62605
 
 ___
 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] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: Yaniv Dary yd...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: in...@ovirt.org, devel@ovirt.org
 Sent: Tuesday, December 9, 2014 12:11:31 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 
 
 - Original Message -
  From: Yaniv Dary yd...@redhat.com
  To: Oved Ourfali ov...@redhat.com
  Cc: devel@ovirt.org, in...@ovirt.org
  Sent: Tuesday, December 9, 2014 12:10:36 PM
  Subject: Re: [ovirt-devel] Creating a new gerrit flag
  
  
  
  - Original Message -
   From: Oved Ourfali ov...@redhat.com
   To: David Caro dcaro...@redhat.com
   Cc: in...@ovirt.org, devel@ovirt.org
   Sent: Tuesday, December 9, 2014 11:52:11 AM
   Subject: Re: [ovirt-devel] Creating a new gerrit flag
   
   What happens when rebasing?
   We can't afford waiting for tests to run on each rebase... as we might
   end
   up
   rebasing forever.
  
  why can't you rerun tests after rebase to run tests if the patch is
  critical
  and pending?
 
 I meant manually.
 

You can run. The issue is that while running them, someone else can merge 
something, and then you'll need to rebase again... and again... and again...

  
   
   - Original Message -
From: David Caro dcaro...@redhat.com
To: devel@ovirt.org, in...@ovirt.org
Sent: Tuesday, December 9, 2014 11:43:04 AM
Subject: [ovirt-devel] Creating a new gerrit flag

Hi!

e have been having an issue with gerrit patches being merged before
jenkins ran any tests on them, to avoid it from happening again I
propose creating a new gerrit flag (Tests) with the following
specifics:


+1 - Tests passed/overrided
 0 - Tests pending
-1 - Tests broken

where +1 is required to submit, +1 is set by jenkins when
passing the tests and -1 is set by jenkins in case it breaks any
tests. The +1 flag can be set also by maintainers to allow overriding
the process.

That way all the tests will be blocked until someone (hopefully
jenkins) adds the +1 flag, but if the maintainer wants to override the
value, she just has to set that flag herself.


What do you think?


--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization RD

Tel.: +420 532 294 605
Email: dc...@redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

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

Re: [ovirt-devel] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: David Caro dcaro...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: in...@ovirt.org, devel@ovirt.org
 Sent: Tuesday, December 9, 2014 12:12:19 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 On 12/09, Oved Ourfali wrote:
  What happens when rebasing?
  We can't afford waiting for tests to run on each rebase... as we might end
  up rebasing forever.
 
 For now we will have to, all the code that is going to be merged must
 be tested as it is going to be merged, that means running the tests in
 the last rebase too.
 
 In the future there are plans on using a gating system like zuul, so
 zuul will be the one monitoring the tests and merging when passes, so
 you will just add the flag, and that will trigger the gate, that runs
 the tests and merged the patch.
 
 It's unlikely that you'll have to wait forever, but there's nothing
 avoiding you doing that (right now even).
 
 I'd like to put emphasis again on differentiating between tests that
 are fast, that should run on each patch and tests that are slow, that
 should run on each merge. That will improve the feedback times.
 

So let's apply that in the future.
For now the amount of merges done is enormous, and it will be impossible to get 
things merged on a reasonable time.
Again, I'm not against testing, but it should be done the right way...

  
  - Original Message -
   From: David Caro dcaro...@redhat.com
   To: devel@ovirt.org, in...@ovirt.org
   Sent: Tuesday, December 9, 2014 11:43:04 AM
   Subject: [ovirt-devel] Creating a new gerrit flag
   
   Hi!
   
   e have been having an issue with gerrit patches being merged before
   jenkins ran any tests on them, to avoid it from happening again I
   propose creating a new gerrit flag (Tests) with the following
   specifics:
   
   
   +1 - Tests passed/overrided
0 - Tests pending
   -1 - Tests broken
   
   where +1 is required to submit, +1 is set by jenkins when
   passing the tests and -1 is set by jenkins in case it breaks any
   tests. The +1 flag can be set also by maintainers to allow overriding
   the process.
   
   That way all the tests will be blocked until someone (hopefully
   jenkins) adds the +1 flag, but if the maintainer wants to override the
   value, she just has to set that flag herself.
   
   
   What do you think?
   
   
   --
   David Caro
   
   Red Hat S.L.
   Continuous Integration Engineer - EMEA ENG Virtualization RD
   
   Tel.: +420 532 294 605
   Email: dc...@redhat.com
   Web: www.redhat.com
   RHT Global #: 82-62605
   
   ___
   Devel mailing list
   Devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/devel
 
 --
 David Caro
 
 Red Hat S.L.
 Continuous Integration Engineer - EMEA ENG Virtualization RD
 
 Tel.: +420 532 294 605
 Email: dc...@redhat.com
 Web: www.redhat.com
 RHT Global #: 82-62605
 
 ___
 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] Creating a new gerrit flag

[Oved Ourfali]

top posting:
How about the following flow:
1. You push a patch to gerrit.
2. You need +1 on Testing in order to merge it.
3. You have +1/-1 on the Tests if finished successfully/failed
4. You find out you need to rebase.
5. The rebase copies the result of the Tests of the previous patch-set... if it 
was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was 
-1 then you need to wait for the CI to finish, and it might set it to +1.

Does that make sense?

- Original Message -
 From: Oved Ourfali ov...@redhat.com
 To: David Caro dcaro...@redhat.com
 Cc: devel@ovirt.org, in...@ovirt.org
 Sent: Tuesday, December 9, 2014 1:13:57 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 
 
 - Original Message -
  From: David Caro dcaro...@redhat.com
  To: Oved Ourfali ov...@redhat.com
  Cc: in...@ovirt.org, devel@ovirt.org
  Sent: Tuesday, December 9, 2014 12:12:19 PM
  Subject: Re: [ovirt-devel] Creating a new gerrit flag
  
  On 12/09, Oved Ourfali wrote:
   What happens when rebasing?
   We can't afford waiting for tests to run on each rebase... as we might
   end
   up rebasing forever.
  
  For now we will have to, all the code that is going to be merged must
  be tested as it is going to be merged, that means running the tests in
  the last rebase too.
  
  In the future there are plans on using a gating system like zuul, so
  zuul will be the one monitoring the tests and merging when passes, so
  you will just add the flag, and that will trigger the gate, that runs
  the tests and merged the patch.
  
  It's unlikely that you'll have to wait forever, but there's nothing
  avoiding you doing that (right now even).
  
  I'd like to put emphasis again on differentiating between tests that
  are fast, that should run on each patch and tests that are slow, that
  should run on each merge. That will improve the feedback times.
  
 
 So let's apply that in the future.
 For now the amount of merges done is enormous, and it will be impossible to
 get things merged on a reasonable time.
 Again, I'm not against testing, but it should be done the right way...
 
   
   - Original Message -
From: David Caro dcaro...@redhat.com
To: devel@ovirt.org, in...@ovirt.org
Sent: Tuesday, December 9, 2014 11:43:04 AM
Subject: [ovirt-devel] Creating a new gerrit flag

Hi!

e have been having an issue with gerrit patches being merged before
jenkins ran any tests on them, to avoid it from happening again I
propose creating a new gerrit flag (Tests) with the following
specifics:


+1 - Tests passed/overrided
 0 - Tests pending
-1 - Tests broken

where +1 is required to submit, +1 is set by jenkins when
passing the tests and -1 is set by jenkins in case it breaks any
tests. The +1 flag can be set also by maintainers to allow overriding
the process.

That way all the tests will be blocked until someone (hopefully
jenkins) adds the +1 flag, but if the maintainer wants to override the
value, she just has to set that flag herself.


What do you think?


--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization RD

Tel.: +420 532 294 605
Email: dc...@redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
  
  --
  David Caro
  
  Red Hat S.L.
  Continuous Integration Engineer - EMEA ENG Virtualization RD
  
  Tel.: +420 532 294 605
  Email: dc...@redhat.com
  Web: www.redhat.com
  RHT Global #: 82-62605
  
  ___
  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] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: Yaniv Dary yd...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: devel@ovirt.org, in...@ovirt.org
 Sent: Tuesday, December 9, 2014 2:29:38 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 
 
 - Original Message -
  From: Oved Ourfali ov...@redhat.com
  To: David Caro dcaro...@redhat.com
  Cc: in...@ovirt.org, devel@ovirt.org
  Sent: Tuesday, December 9, 2014 2:27:14 PM
  Subject: Re: [ovirt-devel] Creating a new gerrit flag
  
  top posting:
  How about the following flow:
  1. You push a patch to gerrit.
  2. You need +1 on Testing in order to merge it.
  3. You have +1/-1 on the Tests if finished successfully/failed
  4. You find out you need to rebase.
  5. The rebase copies the result of the Tests of the previous patch-set...
  if
  it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If
  it was -1 then you need to wait for the CI to finish, and it might set it
  to
  +1.
  
  Does that make sense?
 
 Yes, but only if you used rebase button and automatic rebase worked.
 In case of merge conflict you will need to wait after rebase for tests.
 

In such cases I think the reviewer should compare and decide, rather than wait 
for tests to finish.

  
  - Original Message -
   From: Oved Ourfali ov...@redhat.com
   To: David Caro dcaro...@redhat.com
   Cc: devel@ovirt.org, in...@ovirt.org
   Sent: Tuesday, December 9, 2014 1:13:57 PM
   Subject: Re: [ovirt-devel] Creating a new gerrit flag
   
   
   
   - Original Message -
From: David Caro dcaro...@redhat.com
To: Oved Ourfali ov...@redhat.com
Cc: in...@ovirt.org, devel@ovirt.org
Sent: Tuesday, December 9, 2014 12:12:19 PM
Subject: Re: [ovirt-devel] Creating a new gerrit flag

On 12/09, Oved Ourfali wrote:
 What happens when rebasing?
 We can't afford waiting for tests to run on each rebase... as we
 might
 end
 up rebasing forever.

For now we will have to, all the code that is going to be merged must
be tested as it is going to be merged, that means running the tests in
the last rebase too.

In the future there are plans on using a gating system like zuul, so
zuul will be the one monitoring the tests and merging when passes, so
you will just add the flag, and that will trigger the gate, that runs
the tests and merged the patch.

It's unlikely that you'll have to wait forever, but there's nothing
avoiding you doing that (right now even).

I'd like to put emphasis again on differentiating between tests that
are fast, that should run on each patch and tests that are slow, that
should run on each merge. That will improve the feedback times.

   
   So let's apply that in the future.
   For now the amount of merges done is enormous, and it will be impossible
   to
   get things merged on a reasonable time.
   Again, I'm not against testing, but it should be done the right way...
   
 
 - Original Message -
  From: David Caro dcaro...@redhat.com
  To: devel@ovirt.org, in...@ovirt.org
  Sent: Tuesday, December 9, 2014 11:43:04 AM
  Subject: [ovirt-devel] Creating a new gerrit flag
  
  Hi!
  
  e have been having an issue with gerrit patches being merged before
  jenkins ran any tests on them, to avoid it from happening again I
  propose creating a new gerrit flag (Tests) with the following
  specifics:
  
  
  +1 - Tests passed/overrided
   0 - Tests pending
  -1 - Tests broken
  
  where +1 is required to submit, +1 is set by jenkins when
  passing the tests and -1 is set by jenkins in case it breaks any
  tests. The +1 flag can be set also by maintainers to allow
  overriding
  the process.
  
  That way all the tests will be blocked until someone (hopefully
  jenkins) adds the +1 flag, but if the maintainer wants to override
  the
  value, she just has to set that flag herself.
  
  
  What do you think?
  
  
  --
  David Caro
  
  Red Hat S.L.
  Continuous Integration Engineer - EMEA ENG Virtualization RD
  
  Tel.: +420 532 294 605
  Email: dc...@redhat.com
  Web: www.redhat.com
  RHT Global #: 82-62605
  
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization RD

Tel.: +420 532 294 605
Email: dc...@redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

___
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

Re: [ovirt-devel] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: David Caro dcaro...@redhat.com
 To: Yaniv Dary yd...@redhat.com
 Cc: Oved Ourfali ov...@redhat.com, devel@ovirt.org, in...@ovirt.org
 Sent: Tuesday, December 9, 2014 2:40:43 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 On 12/09, Yaniv Dary wrote:
  
  
  - Original Message -
   From: Oved Ourfali ov...@redhat.com
   To: David Caro dcaro...@redhat.com
   Cc: in...@ovirt.org, devel@ovirt.org
   Sent: Tuesday, December 9, 2014 2:27:14 PM
   Subject: Re: [ovirt-devel] Creating a new gerrit flag
   
   top posting:
   How about the following flow:
   1. You push a patch to gerrit.
   2. You need +1 on Testing in order to merge it.
   3. You have +1/-1 on the Tests if finished successfully/failed
   4. You find out you need to rebase.
   5. The rebase copies the result of the Tests of the previous patch-set...
   if
   it was +1, it remains +1 and you can merge (assuming you have +2 on CR).
   If
   it was -1 then you need to wait for the CI to finish, and it might set it
   to
   +1.
   
   Does that make sense?
  
  Yes, but only if you used rebase button and automatic rebase worked.
  In case of merge conflict you will need to wait after rebase for tests.
 
 Well, that's more or less what's happening today, we did set up the
 flag propagation on trivial rebase time ago. I'll have to check how to
 make jenkins ignore those trivial rebases only if they have a +1.
 
 So are you sure that having no merge conflict means that the rebase
 patch works as before? (I imagine for example that you could have two
 features that together might not work well, even if they do not touch
 the same code)
 
 

You minimize the probability that something will get wrong. It isn't 100%.
Using Zuul is the right way to go, but until you have that I think what I 
proposed will make it both easy to use and maintain, and both safe up to 95% or 
so.

 
  
   
   - Original Message -
From: Oved Ourfali ov...@redhat.com
To: David Caro dcaro...@redhat.com
Cc: devel@ovirt.org, in...@ovirt.org
Sent: Tuesday, December 9, 2014 1:13:57 PM
Subject: Re: [ovirt-devel] Creating a new gerrit flag



- Original Message -
 From: David Caro dcaro...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: in...@ovirt.org, devel@ovirt.org
 Sent: Tuesday, December 9, 2014 12:12:19 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 On 12/09, Oved Ourfali wrote:
  What happens when rebasing?
  We can't afford waiting for tests to run on each rebase... as we
  might
  end
  up rebasing forever.
 
 For now we will have to, all the code that is going to be merged must
 be tested as it is going to be merged, that means running the tests
 in
 the last rebase too.
 
 In the future there are plans on using a gating system like zuul, so
 zuul will be the one monitoring the tests and merging when passes, so
 you will just add the flag, and that will trigger the gate, that runs
 the tests and merged the patch.
 
 It's unlikely that you'll have to wait forever, but there's nothing
 avoiding you doing that (right now even).
 
 I'd like to put emphasis again on differentiating between tests that
 are fast, that should run on each patch and tests that are slow, that
 should run on each merge. That will improve the feedback times.
 

So let's apply that in the future.
For now the amount of merges done is enormous, and it will be
impossible to
get things merged on a reasonable time.
Again, I'm not against testing, but it should be done the right way...

  
  - Original Message -
   From: David Caro dcaro...@redhat.com
   To: devel@ovirt.org, in...@ovirt.org
   Sent: Tuesday, December 9, 2014 11:43:04 AM
   Subject: [ovirt-devel] Creating a new gerrit flag
   
   Hi!
   
   e have been having an issue with gerrit patches being merged
   before
   jenkins ran any tests on them, to avoid it from happening again I
   propose creating a new gerrit flag (Tests) with the following
   specifics:
   
   
   +1 - Tests passed/overrided
0 - Tests pending
   -1 - Tests broken
   
   where +1 is required to submit, +1 is set by jenkins when
   passing the tests and -1 is set by jenkins in case it breaks any
   tests. The +1 flag can be set also by maintainers to allow
   overriding
   the process.
   
   That way all the tests will be blocked until someone (hopefully
   jenkins) adds the +1 flag, but if the maintainer wants to
   override
   the
   value, she just has to set that flag herself.
   
   
   What do you think?
   
   
   --
   David Caro
   
   Red Hat S.L.
   Continuous Integration Engineer - EMEA ENG Virtualization RD
   
   Tel

Re: [ovirt-devel] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: Sven Kieske s.kie...@mittwald.de
 To: devel@ovirt.org
 Sent: Tuesday, December 9, 2014 3:21:43 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 
 
 On 09/12/14 13:47, Oved Ourfali wrote:
  safe up to 95% or so.
 
 You just made up that number.
 I don't really understand why you would want
 to downgrade your code quality by circumventing tests.
 
 Maybe someone can elaborate on this a bit?
 

It doesn't downgrade the code quality.
It is just a way to ensure developers can both merge changes, and do it as 
safely as possible without relying on post-submit tools.
The number is indeed invented... as I don't have real statistics, but it comes 
to say that it would be safe most of the time.
After the patch is merged, if CI will fail, it is the responsibility of the 
developer to check that out and fix that.

 --
 Mit freundlichen Grüßen / Regards
 
 Sven Kieske
 
 Systemadministrator
 Mittwald CM Service GmbH  Co. KG
 Königsberger Straße 6
 32339 Espelkamp
 T: +49-5772-293-100
 F: +49-5772-293-333
 https://www.mittwald.de
 Geschäftsführer: Robert Meyer
 St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
 Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
 ___
 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] Creating a new gerrit flag

[Oved Ourfali]

- Original Message -
 From: David Caro dcaro...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org
 Sent: Tuesday, December 9, 2014 3:40:30 PM
 Subject: Re: [ovirt-devel] Creating a new gerrit flag
 
 On 12/09, Oved Ourfali wrote:
  
  
  - Original Message -
   From: Sven Kieske s.kie...@mittwald.de
   To: devel@ovirt.org
   Sent: Tuesday, December 9, 2014 3:21:43 PM
   Subject: Re: [ovirt-devel] Creating a new gerrit flag
   
   
   
   On 09/12/14 13:47, Oved Ourfali wrote:
safe up to 95% or so.
   
   You just made up that number.
   I don't really understand why you would want
   to downgrade your code quality by circumventing tests.
   
   Maybe someone can elaborate on this a bit?
   
  
  It doesn't downgrade the code quality.
  It is just a way to ensure developers can both merge changes, and do it as
  safely as possible without relying on post-submit tools.
  The number is indeed invented... as I don't have real statistics, but it
  comes to say that it would be safe most of the time.
  After the patch is merged, if CI will fail, it is the responsibility of the
  developer to check that out and fix that.
 
 This thread was started to avoid getting to that point, as getting a
 failed patch inside the code means breaking all the other tests that
 run on top of it and that blocks all the development, not only that
 specific patch.
 

The issue that started the discussion was an issue in which there was a Tests 
-1 flag, and it was ignored.
My suggestion will enforce that it won't be ignored.
In more rare cases, in which the rebase is the source of the tests issue, then 
you'll find about it later.


  
   --
   Mit freundlichen Grüßen / Regards
   
   Sven Kieske
   
   Systemadministrator
   Mittwald CM Service GmbH  Co. KG
   Königsberger Straße 6
   32339 Espelkamp
   T: +49-5772-293-100
   F: +49-5772-293-333
   https://www.mittwald.de
   Geschäftsführer: Robert Meyer
   St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
   Oeynhausen
   Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
   Oeynhausen
   ___
   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
 
 --
 David Caro
 
 Red Hat S.L.
 Continuous Integration Engineer - EMEA ENG Virtualization RD
 
 Tel.: +420 532 294 605
 Email: dc...@redhat.com
 Web: www.redhat.com
 RHT Global #: 82-62605
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] (no subject)

[Oved Ourfali]

You can only import from it... You can't export.  It is a read only repo.  On 
Oct 21, 2014 10:27 PM, czg sai sai...@gmail.com wrote:
ovirt 3.5beta

export disk to ovirt-image-repository. How to delete images from
ovirt-image-repository ?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go

[Oved Ourfali]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: devel@ovirt.org, us...@ovirt.org
 Sent: Monday, September 22, 2014 9:38:13 AM
 Subject: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go
 
 Hi,
 We are supposed to start composing oVirt 3.5.0 GA (or RC3, depending on this
 morning Go / No go Meeting decisions)
 I think we can use this email for discussing / voting 3.5.0 GA release.
 Looking at bugzilla status, I vote no go. I also think we should move the
 build to Wed allowing maintainers to fix pending blockers.
 
 Maintainers:
 - Please be sure that 3.5 snapshot satisfy release criteria[9]
 - Please be sure that no pending patches are going to block the release
 - If any patch must block the GA release please raise the issue as soon as
 possible.
 - If any packages need a rebase please raise the issue as soon as possible.
 - Be aware that packages that doesn't need a rebase must be re-built with
 final release versioning from the RC2 tag.
 
 The bug tracker [1] shows the following proposed blockers to be reviewed:
 
 Bug IDWhiteboard  Status  Summary
 1143042   infra   POSTRepeated error Failed to 
 create VM external-test when
 starting new VM
 1143860   infra   POSTMarshaling issue in fencing 
 policy using jsonrpc

I expect both infra issues to be merged by the end of the day.

 1142256   integration NEW remote engine-reports-setup 
 does not write conf file
 to allow accessing reports from engine
 1144079   integration ASSIGNEDlocal engine-reports-setup does 
 not write conf
 file to allow accessing reports from engine
 
 The following bugs are keyworded as Regression and not marked as blockers[10]
 
 Bug IDWhiteboard  Status  Summary
 1142709   integration NEW Trying to deploy hosted-engine via 
 iSCSI device fails
 1138144   storage NEW Failed to autorecover storage domain 
 after unblocking
 connection with host
 1118349   storage NEW [vdsm] Creating DataCenter 3.5 using 
 master domain V1
 fails with InquireNotSupportedError
 1138314   virtNEW Fail to start vm with payload.
 
 
 Feature freeze is now effective, and branch has been created.
 All new patches must be backported to 3.5 branch too.
 Features completed are marked in green on Features Status Table [2]
 
 There are still 77 bugs [3] targeted to 3.5.0.
 Excluding node and documentation bugs we still have 53 bugs [4] targeted to
 3.5.0.
 
 More in detail [5]:
 
 WhiteboardNEW ASSIGNEDPOSTTotal
 docs  13  1   0   14
 gluster   8   2   2   12
 i18n  0   0   1   1
 infra 1   0   3   4
 integration   1   2   1   4
 node  7   4   0   11
 ppc   2   0   4   6
 sla   12  0   7   19
 virt  3   0   3   6
 Total 47  9   21  77
 
 
 Maintainers / Assignee:
 - Please ensure that completed features are marked in green on Features
 Status Table [2]
 - If you find a blocker bug please remember to add it to the tracker [1]
 - Please fill release notes, the page has been created here [6]
 - Please review results from Third Test Day on the etherpad [7] and on the
 mailing lists
 - Please update the target to 3.5.1 or later for bugs that won't be in 3.5.0:
   it will ease gathering the blocking bugs for next releases.
 
 Community:
 - You're welcome to join us testing last release candidate or nightly builds
 and getting involved in oVirt Quality Assurance[8]
 
 [1] http://bugzilla.redhat.com/1073943
 [2] http://goo.gl/4SuYdE
 [3] http://red.ht/1pVEk7H
 [4] http://red.ht/1zT2mSq
 [5] http://red.ht/1q7SqNL
 [6] http://www.ovirt.org/OVirt_3.5_Release_Notes
 [7] http://etherpad.ovirt.org/p/3.5-testday-3
 [8] http://www.ovirt.org/OVirt_Quality_Assurance
 [9]
 http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria_.28WIP.29
 [10] http://goo.gl/uavikG
 
 Thanks,
 
 
 --
 Sandro Bonazzola
 Better technology. Faster innovation. Powered by community collaboration.
 See how it works at redhat.com
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go

[Oved Ourfali]

- Original Message -
 From: Yaniv Dary yd...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: us...@ovirt.org, devel@ovirt.org
 Sent: Monday, September 22, 2014 11:07:37 AM
 Subject: Re: [ovirt-users] [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0 
 status - Go / No Go
 
 
 
 - Original Message -
  From: Oved Ourfali ov...@redhat.com
  To: Sandro Bonazzola sbona...@redhat.com
  Cc: us...@ovirt.org, devel@ovirt.org
  Sent: Monday, September 22, 2014 11:03:07 AM
  Subject: Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0
  status - Go / No Go
  
  
  
  - Original Message -
   From: Sandro Bonazzola sbona...@redhat.com
   To: devel@ovirt.org, us...@ovirt.org
   Sent: Monday, September 22, 2014 9:38:13 AM
   Subject: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No
   Go
   
   Hi,
   We are supposed to start composing oVirt 3.5.0 GA (or RC3, depending on
   this
   morning Go / No go Meeting decisions)
   I think we can use this email for discussing / voting 3.5.0 GA release.
   Looking at bugzilla status, I vote no go. I also think we should move the
   build to Wed allowing maintainers to fix pending blockers.
   
   Maintainers:
   - Please be sure that 3.5 snapshot satisfy release criteria[9]
   - Please be sure that no pending patches are going to block the release
   - If any patch must block the GA release please raise the issue as soon
   as
   possible.
   - If any packages need a rebase please raise the issue as soon as
   possible.
   - Be aware that packages that doesn't need a rebase must be re-built with
   final release versioning from the RC2 tag.
   
   The bug tracker [1] shows the following proposed blockers to be reviewed:
   
   Bug IDWhiteboard  Status  Summary
   1143042   infra   POSTRepeated error Failed to 
   create VM external-test
   when
   starting new VM
   1143860   infra   POSTMarshaling issue in fencing 
   policy using jsonrpc
  
  I expect both infra issues to be merged by the end of the day.
  

Both bugs are now on MODIFIED.

   1142256   integration NEW remote engine-reports-setup 
   does not write conf
   file
   to allow accessing reports from engine
 
 This is only for 3.5.1.
 
   1144079   integration ASSIGNEDlocal engine-reports-setup does 
   not write
   conf
   file to allow accessing reports from engine
 
 This is pending verification from didi.
 
 
   
   The following bugs are keyworded as Regression and not marked as
   blockers[10]
   
   Bug IDWhiteboard  Status  Summary
   1142709   integration NEW Trying to deploy hosted-engine via 
   iSCSI device
   fails
   1138144   storage NEW Failed to autorecover storage domain 
   after
   unblocking
   connection with host
   1118349   storage NEW [vdsm] Creating DataCenter 3.5 using 
   master domain
   V1
   fails with InquireNotSupportedError
   1138314   virtNEW Fail to start vm with payload.
   
   
   Feature freeze is now effective, and branch has been created.
   All new patches must be backported to 3.5 branch too.
   Features completed are marked in green on Features Status Table [2]
   
   There are still 77 bugs [3] targeted to 3.5.0.
   Excluding node and documentation bugs we still have 53 bugs [4] targeted
   to
   3.5.0.
   
   More in detail [5]:
   
   WhiteboardNEW ASSIGNEDPOSTTotal
   docs  13  1   0   14
   gluster   8   2   2   12
   i18n  0   0   1   1
   infra 1   0   3   4
   integration   1   2   1   4
   node  7   4   0   11
   ppc   2   0   4   6
   sla   12  0   7   19
   virt  3   0   3   6
   Total 47  9   21  77
   
   
   Maintainers / Assignee:
   - Please ensure that completed features are marked in green on Features
   Status Table [2]
   - If you find a blocker bug please remember to add it to the tracker [1]
   - Please fill release notes, the page has been created here [6]
   - Please review results from Third Test Day on the etherpad [7] and on
   the
   mailing lists
   - Please update the target to 3.5.1 or later for bugs that won't be in
   3.5.0:
 it will ease gathering the blocking bugs for next releases.
   
   Community:
   - You're welcome to join us testing last release candidate or nightly
   builds
   and getting involved in oVirt Quality Assurance[8]
   
   [1] http://bugzilla.redhat.com/1073943
   [2] http://goo.gl/4SuYdE
   [3] http://red.ht/1pVEk7H
   [4] http://red.ht/1zT2mSq
   [5] http://red.ht/1q7SqNL
   [6] http://www.ovirt.org/OVirt_3.5_Release_Notes
   [7] http://etherpad.ovirt.org/p/3.5-testday-3
   [8] http

Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0 status

[Oved Ourfali]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: devel@ovirt.org, us...@ovirt.org
 Sent: Wednesday, September 17, 2014 2:46:10 PM
 Subject: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0 status
 
 Hi,
 We are going to start composing oVirt 3.5.0 GA (or RC3, depending on Test Day
 results and oVirt Sync Meeting decisions) on Monday 2014-09-22.
 
 Maintainers:
 - Please be sure that 3.5 snapshot satisfy release criteria[9]
 - Please be sure that no pending patches are going to block the release
 - If any patch must block the GA release please raise the issue as soon as
 possible.
 - If any packages need a rebase please raise the issue as soon as possible.
 - Be aware that packages that doesn't need a rebase must be re-built with
 final release versioning from the RC2 tag.
 
 The bug tracker [1] shows the following proposed blockers to be reviewed:
 
 Bug IDWhiteboard  Status  Summary
 1142256   integration POSTengine-setup does not write conf file 
 to allow
 accessing reports
 
 And the following dependencies still open:
 Bug 1041569 - [NFR] libvirt: Returning the watermark for all the images
 opened for writing
 Bug 1102881 - virDomainBlockCommit fails with live snapshots on oVirt block
 storage
 
 The following bugs are keyworded as Regression and not marked as blockers[10]
 
 Bug IDWhiteboard  Status  Summary
 1135909   infra   POST[Event log] Wrong warning about 
 available swap memory of
 host [1023MB], when actually host has [1024MB]  memory size

We're still discussing whether to address that on engine/VDSM side. 
Doesn't seem urgent, though, so I wouldn't consider that as a blocker.
We didn't see any change with regards to that, so I'm surprised it is a 
Regression at all...

 1118349   storage NEW [vdsm] Creating DataCenter 3.5 using 
 master domain V1
 fails with InquireNotSupportedError
 1110444   ux  POSTbookmark selection does not work on 
 first try
 1138314   virtNEW Fail to start vm with payload.
 
 Feature freeze is now effective, and branch has been created.
 All new patches must be backported to 3.5 branch too.
 Features completed are marked in green on Features Status Table [2]
 
 There are still 83 bugs [3] targeted to 3.5.0.
 Excluding node and documentation bugs we still have 58 bugs [4] targeted to
 3.5.0.
 
 More in detail [5]:
 
 WhiteboardNEW ASSIGNEDPOSTTotal
 docs  14  1   0   15
 gluster   9   4   2   15
 i18n  0   0   1   1
 integration   1   1   1   3
 node  6   4   0   10
 ppc   2   0   4   6
 sla   5   0   8   13
 storage   0   0   3   3
 virt  12  0   5   17
 Total 49  10  24  83
 
 
 Maintainers / Assignee:
 - Please ensure that completed features are marked in green on Features
 Status Table [2]
 - If you find a blocker bug please remember to add it to the tracker [1]
 - Please fill release notes, the page has been created here [6]
 - Please review results from Third Test Day [7]
 - Please update the target to 3.5.1 or later for bugs that won't be in 3.5.0:
   it will ease gathering the blocking bugs for next releases.
 
 Community:
 - You're welcome to join us testing next release candidate and getting
 involved in oVirt Quality Assurance[8]
 
 
 [1] http://bugzilla.redhat.com/1073943
 [2] http://goo.gl/4SuYdE
 [3] http://red.ht/1pVEk7H
 [4] http://red.ht/1zT2mSq
 [5] http://red.ht/1q7SqNL
 [6] http://www.ovirt.org/OVirt_3.5_Release_Notes
 [7] http://etherpad.ovirt.org/p/3.5-testday-3
 [8] http://www.ovirt.org/OVirt_Quality_Assurance
 [9]
 http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria_.28WIP.29
 [10] http://goo.gl/uavikG
 
 Thanks,
 --
 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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status

[Oved Ourfali]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: Oved Ourfali ov...@redhat.com
 Cc: us...@ovirt.org, devel@ovirt.org
 Sent: Wednesday, September 17, 2014 4:10:33 PM
 Subject: Re: [ovirt-users] [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.0
 status
 
 Il 17/09/2014 15:09, Oved Ourfali ha scritto:
  Bug ID Whiteboard  Status  Summary
   1135909  infra   POST[Event log] Wrong warning about 
   available swap
   memory of
   host [1023MB], when actually host has [1024MB]  memory size
  We're still discussing whether to address that on engine/VDSM side.
  Doesn't seem urgent, though, so I wouldn't consider that as a blocker.
  We didn't see any change with regards to that, so I'm surprised it is a
  Regression at all...
  
 
 If it's not a regression, please remove the keyword :-)
 

Well... the reporter claims it is... we haven't tested it yet due to other more 
urgent issues.

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