Re: [ovirt-devel] Error in running engine-setup

[Yedidyah Bar David]

On Tue, Jul 18, 2017 at 9:49 PM, shubham dubey  wrote:
> I am having a issue in running $HOME/ovirt-engine/bin/engine-setup.
> Earlier I was getting this error
>
> [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 13]
> Permission denied: '/var/lib/pgsql/data/postgresql.conf'
>
> then I just change the permission of /var/lib/pgsql/data/postgresql.conf and
> /var/lib/pgsql/data/ * to 777
> now I am getting this error
>
> [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 1] Operation
> not permitted: '/var/lib/pgsql/data/postgresql.conf.20170719001357'
>
>
> So, any solution for that?

I do not think it should try to configure postgresql in dev-env.
Can you please share engine-setup logs? Thanks.

>
>
> Thanks,
> Shubham
>
> ___
> 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

[ovirt-devel] Error in running engine-setup

[shubham dubey]

I am having a issue in running $HOME/ovirt-engine/bin/engine-setup.
Earlier I was getting this error

[ ERROR ] Failed to execute stage 'Misc configuration': [Errno 13]
Permission denied: '/var/lib/pgsql/data/postgresql.conf'

then I just change the permission of /var/lib/pgsql/data/postgresql.conf
and /var/lib/pgsql/data/ * to 777
now I am getting this error

[ ERROR ] Failed to execute stage 'Misc configuration': [Errno 1] Operation
not permitted: '/var/lib/pgsql/data/postgresql.conf.20170719001357'


So, any solution for that?


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

[ovirt-devel] classic user portal is deleted

[Greg Sheremeta]

Hi,

We just merged some patches [1] to delete the classic user portal GWT
application. It is replaced by VM Portal (aka ovirt-web-ui) [2]. We tested
this change well, including with OST before merging, but let me know if you
see any issues.

[1]
https://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:delete_userportal
[2] https://github.com/oVirt/ovirt-web-ui

Best wishes,
Greg

[image: Inline image 1]

-- 
Greg Sheremeta, MBA
Sr. Software Engineer
Red Hat, Inc.
gsher...@redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Question about general testing

[Eyal Edri]

On Tue, Jul 18, 2017 at 4:13 PM, Greg Sheremeta  wrote:

>
>
> On Tue, Jul 18, 2017 at 9:08 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Jul 18, 2017 8:45 AM, "Greg Sheremeta"  wrote:
>>
>>
>>
>> On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>>>
>>>
>>>
>>> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>>>
 Hi Marc,

 I have been working on a development environment for the oVirt. The
 environment is basically two VMs running beside together. One runs the
 engine, second is a host that runs the vdsm with nested virtualization.
  I am now working on the vagrant file with orchestration to make the
 environment setup easier. So if You would wait for a few more days, You
 will be able to start from my setup.

>>>
>>> Hi Petr,
>>> I would advise you to look into oVirt System Tests which are already
>>> being used for over a year in oVirt's CI/CD flow and are continously
>>> finding real regressions on a weekly basis.
>>>
>>>
>>> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>>>
>>
>> What would be super useful is for OST (or something) to stand up an
>> environment at a specific commit, aka an instant development environment.
>> Maybe with Eclipse (Che?) ready to go right at that project state. It
>> sounds like Petr is trying to create something like that.
>>
>>
>> Eyal already sent instructions on how it can easily be achieved. One
>> Jenkins job to do the build, and then you point your repo to use its
>> output.
>> Y.
>>
>
> Right, but that's an rpm centric process. You have to execute a build that
> generates rpms to feed OST, and then you can't live-edit the (for example)
> engine code and re-start / test (fast development cycle).
>

You don't even have to use the Jenkins job for it, just run it locally with
'-s URL_TO_CUSTOM_RPMS'. see [1][2]

[1] https://www.ovirt.org/blog/2017/01/ovirt-system-tests-to-the-rescue/
[2]
http://ovirt-system-tests.readthedocs.io/en/latest/docs/CI/developers_info.html


>
> Or am I missing something?
>
>
>
>>
>>
>>
>>>
>>> It is used to continously test each oVirt project in CI, and continuous
>>> deliver it to a 'tested' repo only if it passed the system tests validation.
>>> The oVirt Systems tests project is getting updated also very frequently
>>> with new tests, which you can find here [3]
>>>
>>> We already have testing suites for 'basic install with normal
>>> engine/RHEL hypervisors', 'hosted engine', 'hyper converged setup with
>>> gluster', 'next gen node based installation'.
>>> In addition, we support exporting the environment and importing it, so
>>> basically you can bring up a complex setup once, export it and use it later
>>> for demo purposes or just reproducing a bug.
>>>
>>> In general, Lago also supports other distros such as Debian, Fedora and
>>> can be installed either with RPMs or PiP.
>>>
>>>
>>> It also supports many little features you'll end up implementing
>>> yourself, spare yourself the pleasure.
>>> Y.
>>>
>>>
>>> For more info you can read here [1][2], There are also multiple videos
>>> and slidedesk available on both projects if you're interested.
>>>
>>>
>>> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
>>> [2] http://lago.readthedocs.io/en/latest/
>>> [3] https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git
>>> ;a=shortlog;h=refs%2Fheads%2Fmaster
>>>
>>>
>>>

 As for the containers. For you to have a full test setup, you would
 need to place a VM inside the container and run a nested virtualization
 inside. This is what the two projects you mentioned are doing. Therefore
 they are not that lightweight as you would like.

 I would recommend using the VM environment, which is the simplest
 solution.

 I will send a reply again once my environment is up.

 Petr






 On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
 wrote:

> Does ovirt-system-tests meet your needs? It can leave the VMs standing
> when it's done.
>
> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
> wrote:
>
>> I've been trying for weeks to come up with a better (most
>> specifically lighter) testing environment for external API requests
>> (specifically vagrant).
>>
>> Right now It basically hooks into a real running oVirt to spin up and
>> test VMs. It works but it's not portable or lightweight.
>>
>> I've been looking into the docker containers:
>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>> this is going to stay maintained? )
>>https://github.com/oVirt/ovirt-containers (this requires
>> openshift making it a giant yak to shave)
>>
>> Are there any thoughts on where to head from here? 

Re: [ovirt-devel] Question about general testing

[Roy Golan]

On Tue, Jul 18, 2017 at 4:14 PM Greg Sheremeta  wrote:

> On Tue, Jul 18, 2017 at 9:08 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Jul 18, 2017 8:45 AM, "Greg Sheremeta"  wrote:
>>
>>
>>
>> On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>>>
>>>
>>>
>>> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>>>
 Hi Marc,

 I have been working on a development environment for the oVirt. The
 environment is basically two VMs running beside together. One runs the
 engine, second is a host that runs the vdsm with nested virtualization.
  I am now working on the vagrant file with orchestration to make the
 environment setup easier. So if You would wait for a few more days, You
 will be able to start from my setup.

>>>
>>> Hi Petr,
>>> I would advise you to look into oVirt System Tests which are already
>>> being used for over a year in oVirt's CI/CD flow and are continously
>>> finding real regressions on a weekly basis.
>>>
>>>
>>> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>>>
>>
>> What would be super useful is for OST (or something) to stand up an
>> environment at a specific commit, aka an instant development environment.
>> Maybe with Eclipse (Che?) ready to go right at that project state. It
>> sounds like Petr is trying to create something like that.
>>
>>
>> Eyal already sent instructions on how it can easily be achieved. One
>> Jenkins job to do the build, and then you point your repo to use its
>> output.
>> Y.
>>
>
> Right, but that's an rpm centric process. You have to execute a build that
> generates rpms to feed OST, and then you can't live-edit the (for example)
> engine code and re-start / test (fast development cycle).
>
> Or am I missing something?
>
>
One would have to start the suite on his own baremetal, (run_suite) and in
the end, when the VM are left running like you said, tweak the source code
on the engine VM. Then with 'runtest' re run the test scenarios

 export SUITE=basic-suite-master
 lago ovirt runtest ../basic-suite-master/test-scenarios/some-test.py

Of course that you'd have to tunnel the newtork for debugging, it should
work.



>>
>>
>>>
>>> It is used to continously test each oVirt project in CI, and continuous
>>> deliver it to a 'tested' repo only if it passed the system tests validation.
>>> The oVirt Systems tests project is getting updated also very frequently
>>> with new tests, which you can find here [3]
>>>
>>> We already have testing suites for 'basic install with normal
>>> engine/RHEL hypervisors', 'hosted engine', 'hyper converged setup with
>>> gluster', 'next gen node based installation'.
>>> In addition, we support exporting the environment and importing it, so
>>> basically you can bring up a complex setup once, export it and use it later
>>> for demo purposes or just reproducing a bug.
>>>
>>> In general, Lago also supports other distros such as Debian, Fedora and
>>> can be installed either with RPMs or PiP.
>>>
>>>
>>> It also supports many little features you'll end up implementing
>>> yourself, spare yourself the pleasure.
>>> Y.
>>>
>>>
>>> For more info you can read here [1][2], There are also multiple videos
>>> and slidedesk available on both projects if you're interested.
>>>
>>>
>>> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
>>> [2] http://lago.readthedocs.io/en/latest/
>>> [3]
>>> https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=shortlog;h=refs%2Fheads%2Fmaster
>>>
>>>
>>>

 As for the containers. For you to have a full test setup, you would
 need to place a VM inside the container and run a nested virtualization
 inside. This is what the two projects you mentioned are doing. Therefore
 they are not that lightweight as you would like.

 I would recommend using the VM environment, which is the simplest
 solution.

 I will send a reply again once my environment is up.

 Petr






 On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
 wrote:

> Does ovirt-system-tests meet your needs? It can leave the VMs standing
> when it's done.
>
> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
> wrote:
>
>> I've been trying for weeks to come up with a better (most
>> specifically lighter) testing environment for external API requests
>> (specifically vagrant).
>>
>> Right now It basically hooks into a real running oVirt to spin up and
>> test VMs. It works but it's not portable or lightweight.
>>
>> I've been looking into the docker containers:
>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>> this is going to stay maintained? )
>>https://github.com/oVirt/ovirt-containers (this requires

Re: [ovirt-devel] Question about general testing

[Greg Sheremeta]

On Tue, Jul 18, 2017 at 9:08 AM, Yaniv Kaul  wrote:

>
>
> On Jul 18, 2017 8:45 AM, "Greg Sheremeta"  wrote:
>
>
>
> On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>>
>>
>>
>> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>>
>>> Hi Marc,
>>>
>>> I have been working on a development environment for the oVirt. The
>>> environment is basically two VMs running beside together. One runs the
>>> engine, second is a host that runs the vdsm with nested virtualization.
>>>  I am now working on the vagrant file with orchestration to make the
>>> environment setup easier. So if You would wait for a few more days, You
>>> will be able to start from my setup.
>>>
>>
>> Hi Petr,
>> I would advise you to look into oVirt System Tests which are already
>> being used for over a year in oVirt's CI/CD flow and are continously
>> finding real regressions on a weekly basis.
>>
>>
>> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>>
>
> What would be super useful is for OST (or something) to stand up an
> environment at a specific commit, aka an instant development environment.
> Maybe with Eclipse (Che?) ready to go right at that project state. It
> sounds like Petr is trying to create something like that.
>
>
> Eyal already sent instructions on how it can easily be achieved. One
> Jenkins job to do the build, and then you point your repo to use its
> output.
> Y.
>

Right, but that's an rpm centric process. You have to execute a build that
generates rpms to feed OST, and then you can't live-edit the (for example)
engine code and re-start / test (fast development cycle).

Or am I missing something?



>
>
>
>>
>> It is used to continously test each oVirt project in CI, and continuous
>> deliver it to a 'tested' repo only if it passed the system tests validation.
>> The oVirt Systems tests project is getting updated also very frequently
>> with new tests, which you can find here [3]
>>
>> We already have testing suites for 'basic install with normal engine/RHEL
>> hypervisors', 'hosted engine', 'hyper converged setup with gluster', 'next
>> gen node based installation'.
>> In addition, we support exporting the environment and importing it, so
>> basically you can bring up a complex setup once, export it and use it later
>> for demo purposes or just reproducing a bug.
>>
>> In general, Lago also supports other distros such as Debian, Fedora and
>> can be installed either with RPMs or PiP.
>>
>>
>> It also supports many little features you'll end up implementing
>> yourself, spare yourself the pleasure.
>> Y.
>>
>>
>> For more info you can read here [1][2], There are also multiple videos
>> and slidedesk available on both projects if you're interested.
>>
>>
>> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
>> [2] http://lago.readthedocs.io/en/latest/
>> [3] https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git
>> ;a=shortlog;h=refs%2Fheads%2Fmaster
>>
>>
>>
>>>
>>> As for the containers. For you to have a full test setup, you would need
>>> to place a VM inside the container and run a nested virtualization inside.
>>> This is what the two projects you mentioned are doing. Therefore they are
>>> not that lightweight as you would like.
>>>
>>> I would recommend using the VM environment, which is the simplest
>>> solution.
>>>
>>> I will send a reply again once my environment is up.
>>>
>>> Petr
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
>>> wrote:
>>>
 Does ovirt-system-tests meet your needs? It can leave the VMs standing
 when it's done.

 On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
 wrote:

> I've been trying for weeks to come up with a better (most specifically
> lighter) testing environment for external API requests (specifically
> vagrant).
>
> Right now It basically hooks into a real running oVirt to spin up and
> test VMs. It works but it's not portable or lightweight.
>
> I've been looking into the docker containers:
>https://github.com/oVirt/ovirt-container-engine (doesnt look like
> this is going to stay maintained? )
>https://github.com/oVirt/ovirt-containers (this requires openshift
> making it a giant yak to shave)
>
> Are there any thoughts on where to head from here? Im looking to
> purely launch oVirt of specific versions and run some tests against it
> (launching real VMs).
>
> I got the first docker one working, but it turned into a turtles
> problem because there was no host, and adding a host requires ssh to be
> running (which isnt), etc etc.
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



 

Re: [ovirt-devel] Question about general testing

[Yaniv Kaul]

On Jul 18, 2017 8:45 AM, "Greg Sheremeta"  wrote:



On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:

>
>
> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>
>
>
> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>
>> Hi Marc,
>>
>> I have been working on a development environment for the oVirt. The
>> environment is basically two VMs running beside together. One runs the
>> engine, second is a host that runs the vdsm with nested virtualization.
>>  I am now working on the vagrant file with orchestration to make the
>> environment setup easier. So if You would wait for a few more days, You
>> will be able to start from my setup.
>>
>
> Hi Petr,
> I would advise you to look into oVirt System Tests which are already being
> used for over a year in oVirt's CI/CD flow and are continously finding real
> regressions on a weekly basis.
>
>
> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>

What would be super useful is for OST (or something) to stand up an
environment at a specific commit, aka an instant development environment.
Maybe with Eclipse (Che?) ready to go right at that project state. It
sounds like Petr is trying to create something like that.


Eyal already sent instructions on how it can easily be achieved. One
Jenkins job to do the build, and then you point your repo to use its
output.
Y.



>
> It is used to continously test each oVirt project in CI, and continuous
> deliver it to a 'tested' repo only if it passed the system tests validation.
> The oVirt Systems tests project is getting updated also very frequently
> with new tests, which you can find here [3]
>
> We already have testing suites for 'basic install with normal engine/RHEL
> hypervisors', 'hosted engine', 'hyper converged setup with gluster', 'next
> gen node based installation'.
> In addition, we support exporting the environment and importing it, so
> basically you can bring up a complex setup once, export it and use it later
> for demo purposes or just reproducing a bug.
>
> In general, Lago also supports other distros such as Debian, Fedora and
> can be installed either with RPMs or PiP.
>
>
> It also supports many little features you'll end up implementing yourself,
> spare yourself the pleasure.
> Y.
>
>
> For more info you can read here [1][2], There are also multiple videos and
> slidedesk available on both projects if you're interested.
>
>
> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
> [2] http://lago.readthedocs.io/en/latest/
> [3] https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git
> ;a=shortlog;h=refs%2Fheads%2Fmaster
>
>
>
>>
>> As for the containers. For you to have a full test setup, you would need
>> to place a VM inside the container and run a nested virtualization inside.
>> This is what the two projects you mentioned are doing. Therefore they are
>> not that lightweight as you would like.
>>
>> I would recommend using the VM environment, which is the simplest
>> solution.
>>
>> I will send a reply again once my environment is up.
>>
>> Petr
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
>> wrote:
>>
>>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>>> when it's done.
>>>
>>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>>> wrote:
>>>
 I've been trying for weeks to come up with a better (most specifically
 lighter) testing environment for external API requests (specifically
 vagrant).

 Right now It basically hooks into a real running oVirt to spin up and
 test VMs. It works but it's not portable or lightweight.

 I've been looking into the docker containers:
https://github.com/oVirt/ovirt-container-engine (doesnt look like
 this is going to stay maintained? )
https://github.com/oVirt/ovirt-containers (this requires openshift
 making it a giant yak to shave)

 Are there any thoughts on where to head from here? Im looking to purely
 launch oVirt of specific versions and run some tests against it (launching
 real VMs).

 I got the first docker one working, but it turned into a turtles
 problem because there was no host, and adding a host requires ssh to be
 running (which isnt), etc etc.

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

>>>
>>>
>>>
>>> --
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@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
>>
>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>

Re: [ovirt-devel] Question about general testing

[Greg Sheremeta]

On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:

>
>
> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>
>
>
> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>
>> Hi Marc,
>>
>> I have been working on a development environment for the oVirt. The
>> environment is basically two VMs running beside together. One runs the
>> engine, second is a host that runs the vdsm with nested virtualization.
>>  I am now working on the vagrant file with orchestration to make the
>> environment setup easier. So if You would wait for a few more days, You
>> will be able to start from my setup.
>>
>
> Hi Petr,
> I would advise you to look into oVirt System Tests which are already being
> used for over a year in oVirt's CI/CD flow and are continously finding real
> regressions on a weekly basis.
>
>
> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>

What would be super useful is for OST (or something) to stand up an
environment at a specific commit, aka an instant development environment.
Maybe with Eclipse (Che?) ready to go right at that project state. It
sounds like Petr is trying to create something like that.


>
> It is used to continously test each oVirt project in CI, and continuous
> deliver it to a 'tested' repo only if it passed the system tests validation.
> The oVirt Systems tests project is getting updated also very frequently
> with new tests, which you can find here [3]
>
> We already have testing suites for 'basic install with normal engine/RHEL
> hypervisors', 'hosted engine', 'hyper converged setup with gluster', 'next
> gen node based installation'.
> In addition, we support exporting the environment and importing it, so
> basically you can bring up a complex setup once, export it and use it later
> for demo purposes or just reproducing a bug.
>
> In general, Lago also supports other distros such as Debian, Fedora and
> can be installed either with RPMs or PiP.
>
>
> It also supports many little features you'll end up implementing yourself,
> spare yourself the pleasure.
> Y.
>
>
> For more info you can read here [1][2], There are also multiple videos and
> slidedesk available on both projects if you're interested.
>
>
> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
> [2] http://lago.readthedocs.io/en/latest/
> [3] https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git
> ;a=shortlog;h=refs%2Fheads%2Fmaster
>
>
>
>>
>> As for the containers. For you to have a full test setup, you would need
>> to place a VM inside the container and run a nested virtualization inside.
>> This is what the two projects you mentioned are doing. Therefore they are
>> not that lightweight as you would like.
>>
>> I would recommend using the VM environment, which is the simplest
>> solution.
>>
>> I will send a reply again once my environment is up.
>>
>> Petr
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
>> wrote:
>>
>>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>>> when it's done.
>>>
>>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>>> wrote:
>>>
 I've been trying for weeks to come up with a better (most specifically
 lighter) testing environment for external API requests (specifically
 vagrant).

 Right now It basically hooks into a real running oVirt to spin up and
 test VMs. It works but it's not portable or lightweight.

 I've been looking into the docker containers:
https://github.com/oVirt/ovirt-container-engine (doesnt look like
 this is going to stay maintained? )
https://github.com/oVirt/ovirt-containers (this requires openshift
 making it a giant yak to shave)

 Are there any thoughts on where to head from here? Im looking to purely
 launch oVirt of specific versions and run some tests against it (launching
 real VMs).

 I got the first docker one working, but it turned into a turtles
 problem because there was no host, and adding a host requires ssh to be
 running (which isnt), etc etc.

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

>>>
>>>
>>>
>>> --
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@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
>>
>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev 

Re: [ovirt-devel] Question about general testing

[Yaniv Kaul]

On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:



On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:

> Hi Marc,
>
> I have been working on a development environment for the oVirt. The
> environment is basically two VMs running beside together. One runs the
> engine, second is a host that runs the vdsm with nested virtualization.
>  I am now working on the vagrant file with orchestration to make the
> environment setup easier. So if You would wait for a few more days, You
> will be able to start from my setup.
>

Hi Petr,
I would advise you to look into oVirt System Tests which are already being
used for over a year in oVirt's CI/CD flow and are continously finding real
regressions on a weekly basis.


I strongly agree here. Very strongly, let's not reinvent the wheel here.

It is used to continously test each oVirt project in CI, and continuous
deliver it to a 'tested' repo only if it passed the system tests validation.
The oVirt Systems tests project is getting updated also very frequently
with new tests, which you can find here [3]

We already have testing suites for 'basic install with normal engine/RHEL
hypervisors', 'hosted engine', 'hyper converged setup with gluster', 'next
gen node based installation'.
In addition, we support exporting the environment and importing it, so
basically you can bring up a complex setup once, export it and use it later
for demo purposes or just reproducing a bug.

In general, Lago also supports other distros such as Debian, Fedora and can
be installed either with RPMs or PiP.


It also supports many little features you'll end up implementing yourself,
spare yourself the pleasure.
Y.


For more info you can read here [1][2], There are also multiple videos and
slidedesk available on both projects if you're interested.


[1] http://ovirt-system-tests.readthedocs.io/en/latest/
[2] http://lago.readthedocs.io/en/latest/
[3] https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.
git;a=shortlog;h=refs%2Fheads%2Fmaster



>
> As for the containers. For you to have a full test setup, you would need
> to place a VM inside the container and run a nested virtualization inside.
> This is what the two projects you mentioned are doing. Therefore they are
> not that lightweight as you would like.
>
> I would recommend using the VM environment, which is the simplest solution.
>
> I will send a reply again once my environment is up.
>
> Petr
>
>
>
>
>
>
> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
> wrote:
>
>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>> when it's done.
>>
>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>> wrote:
>>
>>> I've been trying for weeks to come up with a better (most specifically
>>> lighter) testing environment for external API requests (specifically
>>> vagrant).
>>>
>>> Right now It basically hooks into a real running oVirt to spin up and
>>> test VMs. It works but it's not portable or lightweight.
>>>
>>> I've been looking into the docker containers:
>>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>>> this is going to stay maintained? )
>>>https://github.com/oVirt/ovirt-containers (this requires openshift
>>> making it a giant yak to shave)
>>>
>>> Are there any thoughts on where to head from here? Im looking to purely
>>> launch oVirt of specific versions and run some tests against it (launching
>>> real VMs).
>>>
>>> I got the first docker one working, but it turned into a turtles problem
>>> because there was no host, and adding a host requires ssh to be running
>>> (which isnt), etc etc.
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@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
>



-- 

Eyal edri


ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018 <+972%209-769-2018>
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] Fwd: [IMPORTANT] Implementing materialized views

[Martin Perina]

On Tue, Jul 18, 2017 at 11:17 AM, Roy Golan  wrote:

>
> I think that a convention of {table_name}_MVIEW should be clear enough to
> prevent us from trying to write insert/delete/update on it.
>

+1
​


>
> In general I like the idea and I wonder if it will help with the vms,vds
> tables under load (could be worse to keep the view refreshed in fact
> because of frequent updates)
>

Well, not sure if vms, vds​

​views are good candidates for MV as changes to dynamics/statistics are
quite often (so we would need to refresh also MV quite often), so we would
need to do some measurement about those.
​

>
> On Tue, Jul 18, 2017 at 12:11 PM Eli Mesika  wrote:
>
>> On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David 
>> wrote:
>>
>>> On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina 
>>> wrote:
>>> > Hello,
>>> >
>>> > to make things completely clear: any developer which will perform any
>>> > changes around permissions tables need to use only predefined stored
>>> > procedures for permissions handling. If for some reason direct SQL
>>> update is
>>> > performed, then materialized view will not be refreshed until some
>>> > permission stored procedure is called, which could cause strange
>>> results.
>>>
>>> Isn't it possible to prevent such accidents somehow?
>>>
>>> E.g., is it possible that:
>>> 1. We rename current table ("permissions") to some "private"
>>> name (e.g. "permissions_tab")
>>>
>> ​This is possible ​
>>
>>
>>
>>> 2. We create the materialized view having the name of the
>>> original table ("permissions")
>>>
>>
>> ​The MV replaces the views that uses the permissions table.
>> The plan is to rename the original view to something else and have the
>> created MV with the original view name
>>
>>
>>
>>> 3. We do what's needed (?) so that direct inserts/updates/deletes
>>> on the view either fail or do the right thing.
>>>
>>
>> ​See my answer in 1)
>> ​
>>
>>
>>>
>>> >
>>> > Eli has already removed all such code within patch [3], so this is
>>> just a
>>> > warning for future.
>>> >
>>> > Thanks
>>> >
>>> > Martin
>>> >
>>> >
>>> > On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika 
>>> wrote:
>>> >>
>>> >>
>>> >> Materialized Views [1] can be used to reduce query time on complex
>>> queries
>>> >> with low data update
>>> >>
>>> >> The first candidates to use this feature are all the *permission*
>>> views
>>> >>
>>> >> There is already a RFE [2] opened for that.
>>> >>
>>> >> Please make sure that each call that handles the permissions table
>>> data is
>>> >> using the corresponding SP in dbscripts/multi_level_
>>> administration.sql
>>> >> No direct access to the permissions table is allowed !
>>> >>
>>> >> In case that a direct access to the permissions table is used, you
>>> should
>>> >> replace the code in a call to the corresponding SP as you can see in
>>> [3]
>>> >>
>>> >> A direct use that will not be replaced with a call to the
>>> corresponding SP
>>> >> may cause that direct changes to the permissions table will not be
>>> reflected
>>> >> in the
>>> >> *permission* Materialized Views and the views will remain dirty until
>>> a
>>> >> change that is calling one of the SPs that handle the data of the
>>> >> permissions table is issued and cause the Materialized Views to be
>>> refreshed
>>> >>
>>> >> Please check your code for direct use of the permissions table and
>>> consult
>>> >> with me if you have any questions or issues.
>>> >>
>>> >> Thanks
>>> >>
>>> >> Eli Mesika
>>> >>
>>> >> [1] https://wiki.postgresql.org/wiki/Materialized_Views
>>> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1470991
>>> >> [3] https://gerrit.ovirt.org/#/c/79287/
>>> >>
>>> >>
>>> >> ___
>>> >> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failed to build artifacts for oVirt master

[Tomas Jelinek]

On Tue, Jul 18, 2017 at 11:19 AM, Oved Ourfali  wrote:

> CC-ing Greg anyway,
>
> On Tue, Jul 18, 2017 at 12:18 PM, Tomas Jelinek 
> wrote:
>
>>
>>
>> On Tue, Jul 18, 2017 at 11:10 AM, Oved Ourfali 
>> wrote:
>>
>>> 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


>> Ah, right. The actually correct way of fixing it is to merge this:
>> https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engin
>> e+branch:master+topic:delete_userportal
>> but it seems it is not going to happen today...
>>
>> Going to provide a quick fix.
>>
>
fix posted: https://gerrit.ovirt.org/#/c/79549/


>
>>
>>> 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] Failed to build artifacts for oVirt master

[Oved Ourfali]

CC-ing Greg anyway,

On Tue, Jul 18, 2017 at 12:18 PM, Tomas Jelinek  wrote:

>
>
> On Tue, Jul 18, 2017 at 11:10 AM, Oved Ourfali 
> wrote:
>
>> 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
>>>
>>>
> 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 
>>>
>>> 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

[Tomas Jelinek]

On Tue, Jul 18, 2017 at 11:10 AM, Oved Ourfali  wrote:

> 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
>>
>>
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 
>>
>> 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] Fwd: [IMPORTANT] Implementing materialized views

[Roy Golan]

I think that a convention of {table_name}_MVIEW should be clear enough to
prevent us from trying to write insert/delete/update on it.

In general I like the idea and I wonder if it will help with the vms,vds
tables under load (could be worse to keep the view refreshed in fact
because of frequent updates)

On Tue, Jul 18, 2017 at 12:11 PM Eli Mesika  wrote:

> On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David 
> wrote:
>
>> On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina 
>> wrote:
>> > Hello,
>> >
>> > to make things completely clear: any developer which will perform any
>> > changes around permissions tables need to use only predefined stored
>> > procedures for permissions handling. If for some reason direct SQL
>> update is
>> > performed, then materialized view will not be refreshed until some
>> > permission stored procedure is called, which could cause strange
>> results.
>>
>> Isn't it possible to prevent such accidents somehow?
>>
>> E.g., is it possible that:
>> 1. We rename current table ("permissions") to some "private"
>> name (e.g. "permissions_tab")
>>
> ​This is possible ​
>
>
>
>> 2. We create the materialized view having the name of the
>> original table ("permissions")
>>
>
> ​The MV replaces the views that uses the permissions table.
> The plan is to rename the original view to something else and have the
> created MV with the original view name
>
>
>
>> 3. We do what's needed (?) so that direct inserts/updates/deletes
>> on the view either fail or do the right thing.
>>
>
> ​See my answer in 1)
> ​
>
>
>>
>> >
>> > Eli has already removed all such code within patch [3], so this is just
>> a
>> > warning for future.
>> >
>> > Thanks
>> >
>> > Martin
>> >
>> >
>> > On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika  wrote:
>> >>
>> >>
>> >> Materialized Views [1] can be used to reduce query time on complex
>> queries
>> >> with low data update
>> >>
>> >> The first candidates to use this feature are all the *permission* views
>> >>
>> >> There is already a RFE [2] opened for that.
>> >>
>> >> Please make sure that each call that handles the permissions table
>> data is
>> >> using the corresponding SP in dbscripts/multi_level_administration.sql
>> >> No direct access to the permissions table is allowed !
>> >>
>> >> In case that a direct access to the permissions table is used, you
>> should
>> >> replace the code in a call to the corresponding SP as you can see in
>> [3]
>> >>
>> >> A direct use that will not be replaced with a call to the
>> corresponding SP
>> >> may cause that direct changes to the permissions table will not be
>> reflected
>> >> in the
>> >> *permission* Materialized Views and the views will remain dirty until a
>> >> change that is calling one of the SPs that handle the data of the
>> >> permissions table is issued and cause the Materialized Views to be
>> refreshed
>> >>
>> >> Please check your code for direct use of the permissions table and
>> consult
>> >> with me if you have any questions or issues.
>> >>
>> >> Thanks
>> >>
>> >> Eli Mesika
>> >>
>> >> [1] https://wiki.postgresql.org/wiki/Materialized_Views
>> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1470991
>> >> [3] https://gerrit.ovirt.org/#/c/79287/
>> >>
>> >>
>> >> ___
>> >> 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] Fwd: [IMPORTANT] Implementing materialized views

[Yedidyah Bar David]

On Tue, Jul 18, 2017 at 12:10 PM, Eli Mesika  wrote:
>
>
> On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David  wrote:
>>
>> On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina  wrote:
>> > Hello,
>> >
>> > to make things completely clear: any developer which will perform any
>> > changes around permissions tables need to use only predefined stored
>> > procedures for permissions handling. If for some reason direct SQL
>> > update is
>> > performed, then materialized view will not be refreshed until some
>> > permission stored procedure is called, which could cause strange
>> > results.
>>
>> Isn't it possible to prevent such accidents somehow?
>>
>> E.g., is it possible that:
>> 1. We rename current table ("permissions") to some "private"
>> name (e.g. "permissions_tab")
>
> This is possible

OK. Are we going to? Is there a downside?

We also might still have a view 'permissions' if we want to support
old code that reads from it.

>
>
>>
>> 2. We create the materialized view having the name of the
>> original table ("permissions")
>
>
> The MV replaces the views that uses the permissions table.
> The plan is to rename the original view to something else and have the
> created MV with the original view name
>
>
>>
>> 3. We do what's needed (?) so that direct inserts/updates/deletes
>> on the view either fail or do the right thing.
>
>
> See my answer in 1)
>
>>
>>
>> >
>> > Eli has already removed all such code within patch [3], so this is just
>> > a
>> > warning for future.
>> >
>> > Thanks
>> >
>> > Martin
>> >
>> >
>> > On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika  wrote:
>> >>
>> >>
>> >> Materialized Views [1] can be used to reduce query time on complex
>> >> queries
>> >> with low data update
>> >>
>> >> The first candidates to use this feature are all the *permission* views
>> >>
>> >> There is already a RFE [2] opened for that.
>> >>
>> >> Please make sure that each call that handles the permissions table data
>> >> is
>> >> using the corresponding SP in dbscripts/multi_level_administration.sql
>> >> No direct access to the permissions table is allowed !
>> >>
>> >> In case that a direct access to the permissions table is used, you
>> >> should
>> >> replace the code in a call to the corresponding SP as you can see in
>> >> [3]
>> >>
>> >> A direct use that will not be replaced with a call to the corresponding
>> >> SP
>> >> may cause that direct changes to the permissions table will not be
>> >> reflected
>> >> in the
>> >> *permission* Materialized Views and the views will remain dirty until a
>> >> change that is calling one of the SPs that handle the data of the
>> >> permissions table is issued and cause the Materialized Views to be
>> >> refreshed
>> >>
>> >> Please check your code for direct use of the permissions table and
>> >> consult
>> >> with me if you have any questions or issues.
>> >>
>> >> Thanks
>> >>
>> >> Eli Mesika
>> >>
>> >> [1] https://wiki.postgresql.org/wiki/Materialized_Views
>> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1470991
>> >> [3] https://gerrit.ovirt.org/#/c/79287/
>> >>
>> >>
>> >> ___
>> >> 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
>
>



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

Re: [ovirt-devel] Question about general testing

[Eyal Edri]

On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:

> Hi Marc,
>
> I have been working on a development environment for the oVirt. The
> environment is basically two VMs running beside together. One runs the
> engine, second is a host that runs the vdsm with nested virtualization.
>  I am now working on the vagrant file with orchestration to make the
> environment setup easier. So if You would wait for a few more days, You
> will be able to start from my setup.
>

Hi Petr,
I would advise you to look into oVirt System Tests which are already being
used for over a year in oVirt's CI/CD flow and are continously finding real
regressions on a weekly basis.
It is used to continously test each oVirt project in CI, and continuous
deliver it to a 'tested' repo only if it passed the system tests validation.
The oVirt Systems tests project is getting updated also very frequently
with new tests, which you can find here [3]

We already have testing suites for 'basic install with normal engine/RHEL
hypervisors', 'hosted engine', 'hyper converged setup with gluster', 'next
gen node based installation'.
In addition, we support exporting the environment and importing it, so
basically you can bring up a complex setup once, export it and use it later
for demo purposes or just reproducing a bug.

In general, Lago also supports other distros such as Debian, Fedora and can
be installed either with RPMs or PiP.

For more info you can read here [1][2], There are also multiple videos and
slidedesk available on both projects if you're interested.


[1] http://ovirt-system-tests.readthedocs.io/en/latest/
[2] http://lago.readthedocs.io/en/latest/
[3]
https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=shortlog;h=refs%2Fheads%2Fmaster



>
> As for the containers. For you to have a full test setup, you would need
> to place a VM inside the container and run a nested virtualization inside.
> This is what the two projects you mentioned are doing. Therefore they are
> not that lightweight as you would like.
>
> I would recommend using the VM environment, which is the simplest solution.
>
> I will send a reply again once my environment is up.
>
> Petr
>
>
>
>
>
>
> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
> wrote:
>
>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>> when it's done.
>>
>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>> wrote:
>>
>>> I've been trying for weeks to come up with a better (most specifically
>>> lighter) testing environment for external API requests (specifically
>>> vagrant).
>>>
>>> Right now It basically hooks into a real running oVirt to spin up and
>>> test VMs. It works but it's not portable or lightweight.
>>>
>>> I've been looking into the docker containers:
>>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>>> this is going to stay maintained? )
>>>https://github.com/oVirt/ovirt-containers (this requires openshift
>>> making it a giant yak to shave)
>>>
>>> Are there any thoughts on where to head from here? Im looking to purely
>>> launch oVirt of specific versions and run some tests against it (launching
>>> real VMs).
>>>
>>> I got the first docker one working, but it turned into a turtles problem
>>> because there was no host, and adding a host requires ssh to be running
>>> (which isnt), etc etc.
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@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
>



-- 

Eyal edri


ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


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

Re: [ovirt-devel] Fwd: [IMPORTANT] Implementing materialized views

[Eli Mesika]

On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David  wrote:

> On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina  wrote:
> > Hello,
> >
> > to make things completely clear: any developer which will perform any
> > changes around permissions tables need to use only predefined stored
> > procedures for permissions handling. If for some reason direct SQL
> update is
> > performed, then materialized view will not be refreshed until some
> > permission stored procedure is called, which could cause strange results.
>
> Isn't it possible to prevent such accidents somehow?
>
> E.g., is it possible that:
> 1. We rename current table ("permissions") to some "private"
> name (e.g. "permissions_tab")
>
​This is possible ​



> 2. We create the materialized view having the name of the
> original table ("permissions")
>

​The MV replaces the views that uses the permissions table.
The plan is to rename the original view to something else and have the
created MV with the original view name



> 3. We do what's needed (?) so that direct inserts/updates/deletes
> on the view either fail or do the right thing.
>

​See my answer in 1)
​


>
> >
> > Eli has already removed all such code within patch [3], so this is just a
> > warning for future.
> >
> > Thanks
> >
> > Martin
> >
> >
> > On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika  wrote:
> >>
> >>
> >> Materialized Views [1] can be used to reduce query time on complex
> queries
> >> with low data update
> >>
> >> The first candidates to use this feature are all the *permission* views
> >>
> >> There is already a RFE [2] opened for that.
> >>
> >> Please make sure that each call that handles the permissions table data
> is
> >> using the corresponding SP in dbscripts/multi_level_administration.sql
> >> No direct access to the permissions table is allowed !
> >>
> >> In case that a direct access to the permissions table is used, you
> should
> >> replace the code in a call to the corresponding SP as you can see in [3]
> >>
> >> A direct use that will not be replaced with a call to the corresponding
> SP
> >> may cause that direct changes to the permissions table will not be
> reflected
> >> in the
> >> *permission* Materialized Views and the views will remain dirty until a
> >> change that is calling one of the SPs that handle the data of the
> >> permissions table is issued and cause the Materialized Views to be
> refreshed
> >>
> >> Please check your code for direct use of the permissions table and
> consult
> >> with me if you have any questions or issues.
> >>
> >> Thanks
> >>
> >> Eli Mesika
> >>
> >> [1] https://wiki.postgresql.org/wiki/Materialized_Views
> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1470991
> >> [3] https://gerrit.ovirt.org/#/c/79287/
> >>
> >>
> >> ___
> >> 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

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

[ovirt-devel] Failed to build artifacts for oVirt master

[Daniel Belenky]

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

Re: [ovirt-devel] Question about general testing

[Roy Golan]

On Tue, Jul 18, 2017 at 11:47 AM Petr Kotas  wrote:

> Hi Marc,
>
> I have been working on a development environment for the oVirt. The
> environment is basically two VMs running beside together. One runs the
> engine, second is a host that runs the vdsm with nested virtualization.
>  I am now working on the vagrant file with orchestration to make the
> environment setup easier. So if You would wait for a few more days, You
> will be able to start from my setup.
>
> Interesting, can you share a link?


> As for the containers. For you to have a full test setup, you would need
> to place a VM inside the container and run a nested virtualization inside.
> This is what the two projects you mentioned are doing. Therefore they are
> not that lightweight as you would like.
>
> I would recommend using the VM environment, which is the simplest solution.
>
> I will send a reply again once my environment is up.
>
> Petr
>
>
>
>
>
>
> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
> wrote:
>
>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>> when it's done.
>>
>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>> wrote:
>>
>>> I've been trying for weeks to come up with a better (most specifically
>>> lighter) testing environment for external API requests (specifically
>>> vagrant).
>>>
>>>


> Right now It basically hooks into a real running oVirt to spin up and test
>>> VMs. It works but it's not portable or lightweight.
>>>
>>> I've been looking into the docker containers:
>>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>>> this is going to stay maintained? )
>>>https://github.com/oVirt/ovirt-containers (this requires openshift
>>> making it a giant yak to shave)
>>>
>>> Are there any thoughts on where to head from here? Im looking to purely
>>> launch oVirt of specific versions and run some tests against it (launching
>>> real VMs).
>>>
>>> I got the first docker one working, but it turned into a turtles problem
>>> because there was no host, and adding a host requires ssh to be running
>>> (which isnt), etc etc.
>>>
>>>


I too thing ovirt-system-tests may be a good fit. It has already suites for
master branch (coming 4.2) and 4.1 and writing a test is very easy, it uses
the python SDK which is exactly what you want.

Basically you can write your own suite, by copy-paste an already existing
suite and just modify it to your needs.

You said you wanted real VMs, but in case you want to test API calls and
interaction you can consider vdsmfake[1] which will simulate multi hosts
and multi vms all in one

[1] https://github.com/oVirt/ovirt-vdsmfake

> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Question about general testing

[Petr Kotas]

Hi Marc,

I have been working on a development environment for the oVirt. The
environment is basically two VMs running beside together. One runs the
engine, second is a host that runs the vdsm with nested virtualization.
 I am now working on the vagrant file with orchestration to make the
environment setup easier. So if You would wait for a few more days, You
will be able to start from my setup.

As for the containers. For you to have a full test setup, you would need to
place a VM inside the container and run a nested virtualization inside.
This is what the two projects you mentioned are doing. Therefore they are
not that lightweight as you would like.

I would recommend using the VM environment, which is the simplest solution.

I will send a reply again once my environment is up.

Petr






On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta  wrote:

> Does ovirt-system-tests meet your needs? It can leave the VMs standing
> when it's done.
>
> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
> wrote:
>
>> I've been trying for weeks to come up with a better (most specifically
>> lighter) testing environment for external API requests (specifically
>> vagrant).
>>
>> Right now It basically hooks into a real running oVirt to spin up and
>> test VMs. It works but it's not portable or lightweight.
>>
>> I've been looking into the docker containers:
>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>> this is going to stay maintained? )
>>https://github.com/oVirt/ovirt-containers (this requires openshift
>> making it a giant yak to shave)
>>
>> Are there any thoughts on where to head from here? Im looking to purely
>> launch oVirt of specific versions and run some tests against it (launching
>> real VMs).
>>
>> I got the first docker one working, but it turned into a turtles problem
>> because there was no host, and adding a host requires ssh to be running
>> (which isnt), etc etc.
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> gsher...@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