Re: [ovirt-devel] Automation CI for vdsm

2016-01-31 Thread Barak Korren 
On 31 January 2016 at 14:15, Eyal Edri  wrote:
> Adding lago-devel.
> Anyone from Lago project can help debug why it is taking so long to setup
> Lago (1:17 hours?)
>
Simple, Lago downloads some big images and does a full sync of some
large package repos...
Most of that should be a lot faster the 2nd time around, and also
there is some work being done to shrink down the images.

@Yaniv, you did the test on a machine that didn't run Lago before and
was in TLV while using the repo in PHX right?

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

Re: [ovirt-devel] Automation CI for vdsm

2016-01-31 Thread David Caro Estevez 
I have an unstable temporary repo with el6, el7, fc22 and fc23 images that 
weight ~ 300 mb and are updated to latest packages, working on get it properly 
generated and be able to replace all the current images, that should ease the 
first init, but the reposetup is still an issue, you might consider not doing 
it if you have internet connection and don't care slowing ever run a bit (what 
it takes to download fron the repos whatever you want to install).

We are also looking int being able to generate templates locally and/or upload 
them to the repos (so you install everything you need once, and then just reuse 
the locally generated image)

David Caro

El 31/1/2016 17:54, Barak Korren  escribió:

On 31 January 2016 at 14:15, Eyal Edri  wrote:
> Adding lago-devel.
> Anyone from Lago project can help debug why it is taking so long to setup
> Lago (1:17 hours?)
>
Simple, Lago downloads some big images and does a full sync of some
large package repos...
Most of that should be a lot faster the 2nd time around, and also
there is some work being done to shrink down the images.

@Yaniv, you did the test on a machine that didn't run Lago before and
was in TLV while using the repo in PHX right?

-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
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

[ovirt-devel] Bug 1267508 - [RFE] Replace python-cheetah with python-jinja2 within ovirt-engine

2016-01-31 Thread Sandro Bonazzola 
ovirt-engine has been using python-cheetah for handling the templates
used within the project.

python-cheetah didn't receive updates since 2012 and is not available
on RHEL 7.2.

Since we're dropping el6 support in 4.0 we are migrating to a template
engine available in el7: python-jinja2[1] which is
available in 7.2 and still actively developed.

A patch has been pushed and is currently under review[2].

Please be sure to havepython-jinja2 installed on your EL7 development system.

Thanks,

[1] http://jinja.pocoo.org/

[2] https://gerrit.ovirt.org/52885


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

[ovirt-devel] Hello and A Question about oVirt

2016-01-31 Thread zhukaijie 
Hello, now I have defined a custom property named 'A' in oVirt Engine. 
Administrator is responsible for entering the value (and arbitrary string ) of 
'A' before starting the VM. After an users trys to start the VM in oVirt, VDSM 
will add the value of 'A' in the qemu:arg of libvirt domain xml, so that the 
value of 'A' will be added into the QEMU Cmd as a param. However, just like the 
password of VNC or SPICE, I want to hide the value of 'A' in '*' format in both 
Libvirt domain xml and QEMU Cmd, So could you please tell me how to achieve it? 
Thank you very much and happy 2016.
___
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.

2016-01-31 Thread Eli Mesika 


- Original Message -
> From: "Michal Skrivanek" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> Sent: Thursday, January 28, 2016 4:57:33 PM
> Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
> 
> 
> 
> 
> 
> On 26 Jan 2016, at 19:13, Oved Ourfali < oourf...@redhat.com > wrote:
> 
> 
> 
> 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.
> 
> +1

+1 as well, don't think it worth the effort 

> I like vdsm.
> any variant with “agent” brings confusion with guest agent (let alone the
> fact we have three of them)
> 
> 
> 
> 
> 
> 
> 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" < msi...@redhat.com > 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
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org

Re: [ovirt-devel] Automation CI for vdsm

2016-01-31 Thread Eyal Edri 
Adding lago-devel.
Anyone from Lago project can help debug why it is taking so long to setup
Lago (1:17 hours?)

Yaniv, was this run done only on CI, or someone tried to run it locally on
a baremetal server / laptop?

e.

On Tue, Dec 22, 2015 at 2:50 PM, Yaniv Bronheim  wrote:

> OK. so for now the patch [1] skips all storage and OVSNetwork tests
> Which still doesn't help much, single run takes more than 3hrs :/ (1:17hr,
> for the setup :\ the rest for the tests)
>
> The output looks pretty good though :)
>
> [1] https://gerrit.ovirt.org/#/c/48268/
>
> On Thu, Dec 17, 2015 at 12:13 PM, Petr Horacek 
> wrote:
>
>> Hi,
>>
>> OVSNetworkTest requires vdsm-hook-ovs installed (tests are not skipped
>> if the package is not installed) and openvswitch service running (not
>> started automatically). NetworkTest are not able to run together with
>> OVSNetworkTest since we are doing ugly inheritance hacking there. My
>> apologize for network tests difficulties, it will be resolved soon. If
>> you want your life easier, temporary skip OVSNetworkTest suite and it
>> should be OK.
>>
>> Best regards,
>> Petr
>>
>> 2015-12-16 17:25 GMT+01:00 Yaniv Bronheim :
>> > exactly - just posted a patch again that sings all fails as broken .
>> > we'll get the report soon and I'll publish it as well. hope the run will
>> > take less time now
>> >
>> > On Wed, Dec 16, 2015 at 6:19 PM, Nir Soffer  wrote:
>> >>
>> >> Nice, but we cannot enable this until all the tests pass or disabled.
>> >>
>> >> There is no point in broken or flaky functional tests.
>> >>
>> >> On Wed, Dec 16, 2015 at 5:34 PM, Yaniv Bronheim 
>> >> wrote:
>> >> > So its not stable. It won't block merges and at least give us report
>> >> > after
>> >> > each merge. It takes really long time to run it (because of the tests
>> >> > themselves. Lago things takes maximum 15minutes, but the run last for
>> >> > more
>> >> > than 2hrs right now and I suspect functional/storageTests.py gets
>> stuck)
>> >> >
>> >> > Bellow you can see where we stand (before I added python-rtslib
>> >> > package).
>> >> >
>> >> > Now, I still want to merge the patch
>> https://gerrit.ovirt.org/#/c/48268/
>> >> > -
>> >> > which enables this run after merges, and I still want you to consider
>> >> > the
>> >> > addition of Automation CI flag to our gerrit so that developer will
>> be
>> >> > able
>> >> > to use it as a trigger for the check-merged.sh script run, just to
>> see
>> >> > if
>> >> > their patch fixes\brakes something realted to the functional tests
>> >> >
>> >> >
>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/1480/ -
>> >> > is
>> >> > an example of how the run looks like. I still work to improve the
>> output
>> >> >
>> >> >
>> >> > Please reply and let me know if the idea around the automation flag
>> is
>> >> > acceptable by you.. and please review the patch for comments and
>> acks.
>> >> > We can ask dcaro to add the flag until Friday, otherwise we'll need
>> to
>> >> > delay
>> >> > this effort after the holiday..
>> >> >
>> >> >
>> >> > functional.sosPluginTests.SosPluginTest
>> >> > testSosPlugin   OK
>> >> > functional.vmRecoveryTests.RecoveryTests
>> >> > test_vm_recoveryFAIL
>> >> > functional.vmQoSTests.VMQosTests
>> >> > testSmallVMBallooning   FAIL
>> >> > functional.virtTests.VirtTest
>> >> > testComplexVm   FAIL
>> >> > testHeadlessVm  OK
>> >> > testSimpleVmFAIL
>> >> > testVmDefinitionGraphics('spice')   FAIL
>> >> > testVmDefinitionGraphics('vnc') OK
>> >> > testVmDefinitionLegacyGraphics('qxl')   FAIL
>> >> > testVmDefinitionLegacyGraphics('vnc')   OK
>> >> > testVmDefinitionMultipleGraphics('spice', 'vnc')FAIL
>> >> > testVmDefinitionMultipleGraphics('vnc', 'spice')FAIL
>> >> > testVmWithCdrom('self') FAIL
>> >> > testVmWithCdrom('specParams')   FAIL
>> >> > testVmWithCdrom('vmPayload')FAIL
>> >> > testVmWithDevice('hotplugDisk') FAIL
>> >> > testVmWithDevice('hotplugNic')  FAIL
>> >> > testVmWithDevice('smartcard')   FAIL
>> >> > testVmWithDevice('virtioNic')   FAIL
>> >> > testVmWithDevice('virtioRng')   FAIL
>> >> > testVmWithSla   FAIL
>> >> > testVmWithStorage('iscsi')