Re: [ovirt-devel] Vdsm api package

[Sandro Bonazzola]

Il 29/Mar/2016 20:12, "Nir Soffer"  ha scritto:
>
> On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola 
wrote:
> >
> > Il 29/Mar/2016 20:02, "Nir Soffer"  ha scritto:
> >>
> >> Hi all,
> >>
> >> In the Vdsm call, we discussed a way to expose vdsm errors to its
clients
> >> (e.g, engine, hosted engine agent/setup).
> >>
> >> The idea is to have a vdsmapi package, holding:
> >> - errors.py - all public errors
> >> - events.py - all events sent by vdsm
> >> - client.py - library for communicating with vdsm
> >> - schema.py - the client will use this to autogenerate online help and
> >> validate messages
> >> - schema.yaml - we probably need several files (gluster, events, etc.)
> >>
> >> This will allow other projects talking with vdsm to do:
> >>
> >> from vdsmapi import client, errors
> >> ...
> >> try:
> >> client.list(vmId="xxxyyy")
> >> except errors.NoSuchVM:
> >> ...
> >>
> >> (this is a fake example, the real api may be different)
> >>
> >> Engine can build-require vdsmapi, and generate java module with the
> >> public errors from
> >> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
> >> and updating
> >> it every time vdsm adds new public error.
> >>
> >> Vdsm will use this package when building response to clients.
> >>
> >> Edi was concerned about sharing the errors module, so maybe we need a
> >> package:
> >>
> >> vdsmapi/
> >> errors/
> >> network.py
> >> virt.py
> >> storage.py
> >> gluster.py
> >>
> >> We can still expose all the errors via errors/__init__.py, so clients
> >> do not have to care about
> >> the area of the application the error come from.
> >>
> >> Thoughts?
> >
> > For which version is this proposal targeted? 4.1?
>
> This is not targeted to any version yet, but I would be happy if we can
do this
> for next release.

I don't see it fitting 4.0 scope but I agree it would be nice to have in
4.1.

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

Re: [ovirt-devel] new internal stable modules + proposal

[Martin Polednik]

On 29/03/16 20:36 +0300, Nir Soffer wrote:

On Tue, Mar 29, 2016 at 7:44 PM, Martin Polednik  wrote:

On 29/03/16 11:12 -0400, Francesco Romani wrote:


Hi,

in the last Vdsm developer call we agreed to promote a few modules in the
common repository.
The common repository provides the additional guarantees over regular
modules in lib/vdsm/

- stable API
- (thus) safe to use across verticals

the planned moves are:

lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py
lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py
lib/vdsm/virt/api.py -> lib/vdsm/common/api.py

Question is if those modules should go under common/ or under another
subdirectory, maybe infra?



Hi.

I agree that some modules should be kept (and advertised) as stable.

The name 'common' is more suited for such package as 'infra' is very ovirt
specific and could hurt readability and navigation of the project. It does
make sense to structure the project as follows:

lib/vdsm/common
lib/vdsm/virt/common
lib/vdsm/storage/common
lib/vdsm/network/common


This creates a dependency between the packages. The goal is to have
packages that do
not depend on each other except the common package, which is library
code used by
other parts.


True, forgot about that. We fortunately still have possibility of further
sharding 'common' if that need arises.


Taking extra care taken to avoid 'common junkyard' situation and
making sure that the scope of common corresponds to it's package.

List of modules that I consider public (mostly author/main contributor
of these lately):

lib/vdsm/cpuarch.py
lib/vdsm/cpuinfo.py
lib/vdsm/hostdev.py
lib/vdsm/machinetype.py
lib/vdsm/numa.py
lib/vdsm/osinfo.py
lib/vdsm/udevadm.py


+1


Lastly, i have a proposal about better handling of those modules.

First, the mere fact a module is placed under lib/vdsm/common provides the
extra guarantees I mentioned.
But should we added more annotations?

for example something like

__API__ = {}

near the top of the module

if this attribute exist, then the module is safe to use across verticals,
has stable API and so forth
(this is _in addition_ to the common/ package, not as replacement).

Like:

__API__ = {
 "introduced-in": "4.14.0",
 "deprecated-from": "4.18.0",
 "removed-at": "4.20.0",
 "contact": "from...@redhat.com"
}

We could refine further this concept if we like it. The idea is to be
lightweight as possible while
carrying all the information we need.



I agree about keeping global metadata in that way, except ideally
using docstrings for better readability (e.g. interactive help()). To
better reflect the needs for granular deprecation and based on our
private discussion on this subject, I'd like to see at least
@deprecated(target_removal_version) decorator. On top of that, we need
properly documented public API and deprecation process.


Using standard way such as __author__ is better than docstrings, see for example
the output of help(module)


Partially agreed. Having proper docstrings wouldn't hurt either. I
frequently use repl w/ vdsm now that it is in lib, this would help
myself - am I the only one?

I would still like to see some kind of proper deprecation in private
APIs. It might as well serve as a testing ground for deprecation in
public API.


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

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

Re: [ovirt-devel] Vdsm api package

[Nir Soffer]

On Tue, Mar 29, 2016 at 9:08 PM, Adam Litke  wrote:
> On 29/03/16 21:01 +0300, Nir Soffer wrote:
>>
>> Hi all,
>>
>> In the Vdsm call, we discussed a way to expose vdsm errors to its clients
>> (e.g, engine, hosted engine agent/setup).
>>
>> The idea is to have a vdsmapi package, holding:
>> - errors.py - all public errors
>> - events.py - all events sent by vdsm
>> - client.py - library for communicating with vdsm
>> - schema.py - the client will use this to autogenerate online help and
>> validate messages
>> - schema.yaml - we probably need several files (gluster, events, etc.)
>>
>> This will allow other projects talking with vdsm to do:
>>
>>from vdsmapi import client, errors
>>...
>>try:
>>client.list(vmId="xxxyyy")
>>except errors.NoSuchVM:
>>...
>>
>> (this is a fake example, the real api may be different)
>>
>> Engine can build-require vdsmapi, and generate java module with the
>> public errors from
>> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
>> and updating
>> it every time vdsm adds new public error.
>>
>> Vdsm will use this package when building response to clients.
>>
>> Edi was concerned about sharing the errors module, so maybe we need a
>> package:
>>
>> vdsmapi/
>>errors/
>>network.py
>>virt.py
>>storage.py
>>gluster.py
>>
>> We can still expose all the errors via errors/__init__.py, so clients
>> do not have to care about
>> the area of the application the error come from.
>>
>> Thoughts?
>
>
> Seems like a fantastic idea.  Would engine builds of the master branch
> always fetch the errors module from vdsm's master branch or would
> there be some synchronization points?

I guess the synchronization points would be the version of the package you
are targeting. Engine master will requires vdsmapi-4.0-gitxxxyyy, and
engine 4.0 will
use vdsmapi-4.0 etc.

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

Re: [ovirt-devel] Vdsm api package

[Nir Soffer]

On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola  wrote:
>
> Il 29/Mar/2016 20:02, "Nir Soffer"  ha scritto:
>>
>> Hi all,
>>
>> In the Vdsm call, we discussed a way to expose vdsm errors to its clients
>> (e.g, engine, hosted engine agent/setup).
>>
>> The idea is to have a vdsmapi package, holding:
>> - errors.py - all public errors
>> - events.py - all events sent by vdsm
>> - client.py - library for communicating with vdsm
>> - schema.py - the client will use this to autogenerate online help and
>> validate messages
>> - schema.yaml - we probably need several files (gluster, events, etc.)
>>
>> This will allow other projects talking with vdsm to do:
>>
>> from vdsmapi import client, errors
>> ...
>> try:
>> client.list(vmId="xxxyyy")
>> except errors.NoSuchVM:
>> ...
>>
>> (this is a fake example, the real api may be different)
>>
>> Engine can build-require vdsmapi, and generate java module with the
>> public errors from
>> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
>> and updating
>> it every time vdsm adds new public error.
>>
>> Vdsm will use this package when building response to clients.
>>
>> Edi was concerned about sharing the errors module, so maybe we need a
>> package:
>>
>> vdsmapi/
>> errors/
>> network.py
>> virt.py
>> storage.py
>> gluster.py
>>
>> We can still expose all the errors via errors/__init__.py, so clients
>> do not have to care about
>> the area of the application the error come from.
>>
>> Thoughts?
>
> For which version is this proposal targeted? 4.1?

This is not targeted to any version yet, but I would be happy if we can do this
for next release.

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

Re: [ovirt-devel] Vdsm api package

[Sandro Bonazzola]

Il 29/Mar/2016 20:02, "Nir Soffer"  ha scritto:
>
> Hi all,
>
> In the Vdsm call, we discussed a way to expose vdsm errors to its clients
> (e.g, engine, hosted engine agent/setup).
>
> The idea is to have a vdsmapi package, holding:
> - errors.py - all public errors
> - events.py - all events sent by vdsm
> - client.py - library for communicating with vdsm
> - schema.py - the client will use this to autogenerate online help and
> validate messages
> - schema.yaml - we probably need several files (gluster, events, etc.)
>
> This will allow other projects talking with vdsm to do:
>
> from vdsmapi import client, errors
> ...
> try:
> client.list(vmId="xxxyyy")
> except errors.NoSuchVM:
> ...
>
> (this is a fake example, the real api may be different)
>
> Engine can build-require vdsmapi, and generate java module with the
> public errors from
> vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
> and updating
> it every time vdsm adds new public error.
>
> Vdsm will use this package when building response to clients.
>
> Edi was concerned about sharing the errors module, so maybe we need a
package:
>
> vdsmapi/
> errors/
> network.py
> virt.py
> storage.py
> gluster.py
>
> We can still expose all the errors via errors/__init__.py, so clients
> do not have to care about
> the area of the application the error come from.
>
> Thoughts?

For which version is this proposal targeted? 4.1?


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

Re: [ovirt-devel] Vdsm api package

[Adam Litke]

On 29/03/16 21:01 +0300, Nir Soffer wrote:

Hi all,

In the Vdsm call, we discussed a way to expose vdsm errors to its clients
(e.g, engine, hosted engine agent/setup).

The idea is to have a vdsmapi package, holding:
- errors.py - all public errors
- events.py - all events sent by vdsm
- client.py - library for communicating with vdsm
- schema.py - the client will use this to autogenerate online help and
validate messages
- schema.yaml - we probably need several files (gluster, events, etc.)

This will allow other projects talking with vdsm to do:

   from vdsmapi import client, errors
   ...
   try:
   client.list(vmId="xxxyyy")
   except errors.NoSuchVM:
   ...

(this is a fake example, the real api may be different)

Engine can build-require vdsmapi, and generate java module with the
public errors from
vdsmapi/errors.py module, instead of keeping this hardcoded in engine,
and updating
it every time vdsm adds new public error.

Vdsm will use this package when building response to clients.

Edi was concerned about sharing the errors module, so maybe we need a package:

vdsmapi/
   errors/
   network.py
   virt.py
   storage.py
   gluster.py

We can still expose all the errors via errors/__init__.py, so clients
do not have to care about
the area of the application the error come from.

Thoughts?


Seems like a fantastic idea.  Would engine builds of the master branch
always fetch the errors module from vdsm's master branch or would
there be some synchronization points?

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

Re: [ovirt-devel] new internal stable modules + proposal

[Nir Soffer]

On Tue, Mar 29, 2016 at 7:44 PM, Martin Polednik  wrote:
> On 29/03/16 11:12 -0400, Francesco Romani wrote:
>>
>> Hi,
>>
>> in the last Vdsm developer call we agreed to promote a few modules in the
>> common repository.
>> The common repository provides the additional guarantees over regular
>> modules in lib/vdsm/
>>
>> - stable API
>> - (thus) safe to use across verticals
>>
>> the planned moves are:
>>
>> lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py
>> lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py
>> lib/vdsm/virt/api.py -> lib/vdsm/common/api.py
>>
>> Question is if those modules should go under common/ or under another
>> subdirectory, maybe infra?
>
>
> Hi.
>
> I agree that some modules should be kept (and advertised) as stable.
>
> The name 'common' is more suited for such package as 'infra' is very ovirt
> specific and could hurt readability and navigation of the project. It does
> make sense to structure the project as follows:
>
> lib/vdsm/common
> lib/vdsm/virt/common
> lib/vdsm/storage/common
> lib/vdsm/network/common

This creates a dependency between the packages. The goal is to have
packages that do
not depend on each other except the common package, which is library
code used by
other parts.

> Taking extra care taken to avoid 'common junkyard' situation and
> making sure that the scope of common corresponds to it's package.
>
> List of modules that I consider public (mostly author/main contributor
> of these lately):
>
> lib/vdsm/cpuarch.py
> lib/vdsm/cpuinfo.py
> lib/vdsm/hostdev.py
> lib/vdsm/machinetype.py
> lib/vdsm/numa.py
> lib/vdsm/osinfo.py
> lib/vdsm/udevadm.py

+1

>> Lastly, i have a proposal about better handling of those modules.
>>
>> First, the mere fact a module is placed under lib/vdsm/common provides the
>> extra guarantees I mentioned.
>> But should we added more annotations?
>>
>> for example something like
>>
>> __API__ = {}
>>
>> near the top of the module
>>
>> if this attribute exist, then the module is safe to use across verticals,
>> has stable API and so forth
>> (this is _in addition_ to the common/ package, not as replacement).
>>
>> Like:
>>
>> __API__ = {
>>  "introduced-in": "4.14.0",
>>  "deprecated-from": "4.18.0",
>>  "removed-at": "4.20.0",
>>  "contact": "from...@redhat.com"
>> }
>>
>> We could refine further this concept if we like it. The idea is to be
>> lightweight as possible while
>> carrying all the information we need.
>
>
> I agree about keeping global metadata in that way, except ideally
> using docstrings for better readability (e.g. interactive help()). To
> better reflect the needs for granular deprecation and based on our
> private discussion on this subject, I'd like to see at least
> @deprecated(target_removal_version) decorator. On top of that, we need
> properly documented public API and deprecation process.

Using standard way such as __author__ is better than docstrings, see for example
the output of help(module)

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

Re: [ovirt-devel] new internal stable modules + proposal

[Martin Polednik]

On 29/03/16 11:12 -0400, Francesco Romani wrote:

Hi,

in the last Vdsm developer call we agreed to promote a few modules in the 
common repository.
The common repository provides the additional guarantees over regular modules 
in lib/vdsm/

- stable API
- (thus) safe to use across verticals

the planned moves are:

lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py
lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py
lib/vdsm/virt/api.py -> lib/vdsm/common/api.py

Question is if those modules should go under common/ or under another 
subdirectory, maybe infra?


Hi.

I agree that some modules should be kept (and advertised) as stable.

The name 'common' is more suited for such package as 'infra' is very ovirt
specific and could hurt readability and navigation of the project. It does
make sense to structure the project as follows:

lib/vdsm/common
lib/vdsm/virt/common
lib/vdsm/storage/common
lib/vdsm/network/common

Taking extra care taken to avoid 'common junkyard' situation and
making sure that the scope of common corresponds to it's package.

List of modules that I consider public (mostly author/main contributor
of these lately):

lib/vdsm/cpuarch.py
lib/vdsm/cpuinfo.py
lib/vdsm/hostdev.py
lib/vdsm/machinetype.py
lib/vdsm/numa.py
lib/vdsm/osinfo.py
lib/vdsm/udevadm.py


Lastly, i have a proposal about better handling of those modules.

First, the mere fact a module is placed under lib/vdsm/common provides the 
extra guarantees I mentioned.
But should we added more annotations?

for example something like

__API__ = {}

near the top of the module

if this attribute exist, then the module is safe to use across verticals, has 
stable API and so forth
(this is _in addition_ to the common/ package, not as replacement).

Like:

__API__ = {
 "introduced-in": "4.14.0",
 "deprecated-from": "4.18.0",
 "removed-at": "4.20.0",
 "contact": "from...@redhat.com"
}

We could refine further this concept if we like it. The idea is to be 
lightweight as possible while
carrying all the information we need.


I agree about keeping global metadata in that way, except ideally
using docstrings for better readability (e.g. interactive help()). To
better reflect the needs for granular deprecation and based on our
private discussion on this subject, I'd like to see at least
@deprecated(target_removal_version) decorator. On top of that, we need
properly documented public API and deprecation process.


Comments welcome as usual

bests,

--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
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] new internal stable modules + proposal

[Francesco Romani]

- Original Message -
> From: "Nir Soffer" 
> To: "Francesco Romani" 
> Cc: "devel" 
> Sent: Tuesday, March 29, 2016 6:00:56 PM
> Subject: Re: [ovirt-devel] [vdsm] new internal stable modules + proposal
> 
> On Tue, Mar 29, 2016 at 6:12 PM, Francesco Romani  wrote:
> > Hi,
> >
> > in the last Vdsm developer call we agreed to promote a few modules in the
> > common repository.
> > The common repository provides the additional guarantees over regular
> > modules in lib/vdsm/
> >
> > - stable API
> > - (thus) safe to use across verticals
> >
> > the planned moves are:
> >
> > lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py
> 
> +1
> 
> I think we want to move also the executor, used by virt and jsonrpc.
> We plan to move all storage jobs
> to the executor.
> 
> > lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py
> 
> Is it used outside of virt?

Yes, sorry, I meant executor.py. Periodic.py will stay in virt for a little 
more.
 
> > lib/vdsm/virt/api.py -> lib/vdsm/common/api.py
> 
> +1
> 
> >
> > Question is if those modules should go under common/ or under another
> > subdirectory, maybe infra?
> 
> I would not add infra package, common *is* infra.

OK, to explain further we have already

lib/vdsm/common/network

BTW I'm fine using lib/vdsm/common/ directly.

The move will be done this friday unless anyone objects.

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] new internal stable modules + proposal

[Nir Soffer]

On Tue, Mar 29, 2016 at 6:12 PM, Francesco Romani  wrote:
> Hi,
>
> in the last Vdsm developer call we agreed to promote a few modules in the 
> common repository.
> The common repository provides the additional guarantees over regular modules 
> in lib/vdsm/
>
> - stable API
> - (thus) safe to use across verticals
>
> the planned moves are:
>
> lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py

+1

I think we want to move also the executor, used by virt and jsonrpc.
We plan to move all storage jobs
to the executor.

> lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py

Is it used outside of virt?

> lib/vdsm/virt/api.py -> lib/vdsm/common/api.py

+1

>
> Question is if those modules should go under common/ or under another 
> subdirectory, maybe infra?

I would not add infra package, common *is* infra.

>
> Lastly, i have a proposal about better handling of those modules.
>
> First, the mere fact a module is placed under lib/vdsm/common provides the 
> extra guarantees I mentioned.
> But should we added more annotations?
>
> for example something like
>
> __API__ = {}
>
> near the top of the module
>
> if this attribute exist, then the module is safe to use across verticals, has 
> stable API and so forth
> (this is _in addition_ to the common/ package, not as replacement).
>
> Like:
>
> __API__ = {
>   "introduced-in": "4.14.0",
>   "deprecated-from": "4.18.0",
>   "removed-at": "4.20.0",
>   "contact": "from...@redhat.com"
> }

Since this is internal api, I don't think we need this info. The
guarantee you have when you
use such module is that it will never break your code. If someone one
is changing such module,
it must change and test the code using it.

Maybe the "standard" __author__ ?

Not sure it will help much, using git shortlog path/to/module is
probably more useful when you
look for someone to review a patch for some module.

>
> We could refine further this concept if we like it. The idea is to be 
> lightweight as possible while
> carrying all the information we need.

Adding nothing is the most lightweight way :-)

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

[ovirt-devel] [vdsm] new internal stable modules + proposal

[Francesco Romani]

Hi,

in the last Vdsm developer call we agreed to promote a few modules in the 
common repository.
The common repository provides the additional guarantees over regular modules 
in lib/vdsm/

- stable API
- (thus) safe to use across verticals

the planned moves are:

lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py
lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py
lib/vdsm/virt/api.py -> lib/vdsm/common/api.py

Question is if those modules should go under common/ or under another 
subdirectory, maybe infra?

Lastly, i have a proposal about better handling of those modules.

First, the mere fact a module is placed under lib/vdsm/common provides the 
extra guarantees I mentioned.
But should we added more annotations?

for example something like

__API__ = {}

near the top of the module

if this attribute exist, then the module is safe to use across verticals, has 
stable API and so forth
(this is _in addition_ to the common/ package, not as replacement).

Like:

__API__ = {
  "introduced-in": "4.14.0",
  "deprecated-from": "4.18.0",
  "removed-at": "4.20.0",
  "contact": "from...@redhat.com"
}

We could refine further this concept if we like it. The idea is to be 
lightweight as possible while
carrying all the information we need.

Comments welcome as usual

bests,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Hello and a question about QEMU log

[Phillip Bailey]

Hi,

The libvirt team would be better equipped to address that question, as that
functionality is actually a part of that project. Their contact information
can be found here: https://libvirt.org/contact.html.

-Phillip Bailey

On Sun, Mar 27, 2016 at 10:04 PM, zhukaijie  wrote:

> Hello,
> Each running VM has it's command line logged in
> /var/log/libvirt/qemu/${vmname}. And now I'd like to disable this log
> function, that is to say, not to record the QEMU command line of VM. Could
> you please tell me will can I configure it?
> Best wishes.
> ___
> 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] Failing to run ovirt-system-tests using lago due to missing rpms

[Eyal Edri]

Hi,

Anyone encountered these errors when running 3.6 basic suite on RHEL 7.2?


* STDERR
Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync)
   Requires: ovirt-iso-uploader >= 3.6.0
Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync)
   Requires: slf4j >= 1.7.0
   Available: slf4j-1.5.8-8.el6.noarch (base)
   slf4j = 1.5.8-8.el6
Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync)
   Requires: ovirt-host-deploy-java >= 1.4.0
Error: Package: ovirt-engine-vmconsole-proxy-helper-3.6.4.1-1.el6.noarch
(localsync)
   Requires: ovirt-vmconsole-proxy
Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync)
   Requires: ovirt-image-uploader >= 3.6.0
Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync)
   Requires: ebay-cors-filter
Error: Package: ovirt-engine-setup-base-3.6.4.1-1.el6.noarch (localsync)
   Requires: otopi >= 1.4.0
Error: Package: ovirt-engine-setup-plugin-ovirt-engine-3.6.4.1-1.el6.noarch
(localsync)
   Requires: ovirt-engine-extension-aaa-jdbc
Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync)
   Requires: ovirt-engine-wildfly >= 8.2.1
Error: Package:
ovirt-engine-setup-plugin-ovirt-engine-common-3.6.4.1-1.el6.noarch
(localsync)
   Requires: ovirt-setup-lib
Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync)
   Requires: vdsm-jsonrpc-java >= 1.1.8
Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync)
   Requires: ovirt-engine-extension-aaa-jdbc

  # [Thread-3] Deploy VM lago_basic_suite_3_6_engine: ERROR (in 0:01:59)
Error while running thread
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/lago/utils.py", line 46, in
_ret_via_queue
queue.put({'return': func()})
  File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 472,
in _deploy_host
host.name(),
RuntimeError:
/home/eedri/lago/ovirt-system-tests/basic_suite_3.6/deploy-scripts/setup_engine.sh
failed with status 1 on lago_basic_suite_3_6_engine
@ Deploy oVirt environment: ERROR (in 0:01:59)
Error occured, aborting
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 248, in
do_run
self.cli_plugins[args.ovirtverb].do_run(args)
  File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in
do_run
self._do_run(**vars(args))
  File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in
wrapper
return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in
wrapper
return func(*args, prefix=prefix, **kwargs)
  File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 174, in
do_deploy
prefix.deploy()
  File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 598, in
wrapper
func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 52,
in wrapper
return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 480,
in deploy
self._deploy_host, self.virt_env.get_vms().values()
  File "/usr/lib/python2.7/site-packages/lago/utils.py", line 88, in
invoke_in_parallel
vt.join_all()
  File "/usr/lib/python2.7/site-packages/lago/utils.py", line 46, in
_ret_via_queue
queue.put({'return': func()})
  File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 472,
in _deploy_host
host.name(),
RuntimeError:
/home/eedri/lago/ovirt-system-tests/basic_suite_3.6/deploy-scripts/setup_engine.sh
failed with status 1 on lago_basic_suite_3_6_engine

-- 
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] Engine 3.6.5 has been branched out

[Francesco Romani]

- Original Message -
> From: "Tal Nisan" 
> To: "devel" 
> Sent: Tuesday, March 29, 2016 2:03:48 PM
> Subject: [ovirt-devel] Engine 3.6.5 has been branched out
> 
> A new branch ovirt-engine-3.6.5 has been branched out from the
> ovirt-engine-3.6 branch please note that:
> 
> - 3.6.5 patches will now have to be backported to the new branch as well as
> the 3.6 branch
> - 3.6.6 patches should only be merged to the 3.6 branch only
> 
> All 3.6.6 patches that were backported to the 3.6 and were pending the
> branching out can now be merged, please rebase and verify again.

Hi,

As for Vdsm, we *do not* have a 3.6.5 branch at the moment.
Releases > 3.6.4 are been tagged from the ovirt-3.6 branch, no double backport
is needed.

Will update if we choose to make such branch.

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Vdsm build requires now python 3 on EL7

[Sandro Bonazzola]

On Tue, Mar 29, 2016 at 3:47 PM, Vinzenz Feenstra 
wrote:

>
> On Mar 29, 2016, at 3:42 PM, Martin Perina  wrote:
>
>
>
> On Tue, Mar 29, 2016 at 3:35 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  wrote:
>>
>>> Hi all,
>>>
>>> Since commit f247a0cff310 (el7: require newly available
>>> python34-nose), building vdsm
>>> requires Python 3 on EL7.
>>>
>>> Unfortunately, it seems that ovirt-release-master that should add all
>>> the dependencies
>>> needed for vdsm does is not configured properly, so building vdsm will
>>> fail.
>>>
>>
>> Pithon 3 is not available in CentOS 7 and as far as I can tell it's not
>> available in EPEL as well.
>> Please drop Python3 on EL7.
>>
>
> ​Well, there is Python 3.4 on EPEL:
>
> https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/python34.html
>
>
> The appropriate way for us to do this, should be via software collections:
> https://www.softwarecollections.org/en/scls/rhscl/rh-python34/
>
> If it is available there then we can use it, otherwise we shouldn’t
> otherwise we’d have problems with RHEL7 users, EPEL  is not always a viable
> alternative.
>

Ok, so python34 is there:
http://koji.fedoraproject.org/koji/packageinfo?packageID=20542

I didn't see it because I was searching in the wrong place:
http://koji.fedoraproject.org/koji/packageinfo?packageID=9781

So, for me, ok to add python3 support on el7.
Can you please push a patch to ovirt-release including needed packages in
the epel repo?
Please note that if you want python3 support in virt sig you'll have to
provide it in virt sig repo as well



>
> ​
>
>
>>
>>
>>
>>
>>
>>
>>>
>>> I heard that installing epel7 repo fixes this issue.
>>>
>>> Cheers,
>>> Nir
>>>
>>> [1]
>>> https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a915
>>>
>>
>>
>>
>> --
>> 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
>
>
>


-- 
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] [VDSM] Vdsm build requires now python 3 on EL7

[Dan Kenigsberg]

On Tue, Mar 29, 2016 at 03:35:13PM +0200, Sandro Bonazzola wrote:
> On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  wrote:
> 
> > Hi all,
> >
> > Since commit f247a0cff310 (el7: require newly available
> > python34-nose), building vdsm
> > requires Python 3 on EL7.
> >
> > Unfortunately, it seems that ovirt-release-master that should add all
> > the dependencies
> > needed for vdsm does is not configured properly, so building vdsm will
> > fail.
> >
> 
> Pithon 3 is not available in CentOS 7 and as far as I can tell it's not
> available in EPEL as well.
> Please drop Python3 on EL7.

python34-{six,nose} has been recently added to EPEL7.

I suspect that it is not pulled by the ovirt-syndicated epel repository,
and I hope that https://gerrit.ovirt.org/#/c/55415/ would fix it.

Maor, would you try it, please?

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

Re: [ovirt-devel] [VDSM] Vdsm build requires now python 3 on EL7

[Vinzenz Feenstra]

> On Mar 29, 2016, at 3:42 PM, Martin Perina  wrote:
> 
> 
> 
> On Tue, Mar 29, 2016 at 3:35 PM, Sandro Bonazzola  > wrote:
> 
> 
> On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  > wrote:
> Hi all,
> 
> Since commit f247a0cff310 (el7: require newly available
> python34-nose), building vdsm
> requires Python 3 on EL7.
> 
> Unfortunately, it seems that ovirt-release-master that should add all
> the dependencies
> needed for vdsm does is not configured properly, so building vdsm will fail.
> 
> Pithon 3 is not available in CentOS 7 and as far as I can tell it's not 
> available in EPEL as well.
> Please drop Python3 on EL7.
> 
> ​Well, there is Python 3.4 on EPEL:
> 
> https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/python34.html 
> 

The appropriate way for us to do this, should be via software collections:
https://www.softwarecollections.org/en/scls/rhscl/rh-python34/ 


If it is available there then we can use it, otherwise we shouldn’t otherwise 
we’d have problems with RHEL7 users, EPEL  is not always a viable alternative.

> ​ 
> 
> 
> 
> 
>  
> 
> I heard that installing epel7 repo fixes this issue.
> 
> Cheers,
> Nir
> 
> [1] 
> https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a915 
> 
> 
> 
> 
> -- 
> 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 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Vdsm build requires now python 3 on EL7

[Martin Perina]

On Tue, Mar 29, 2016 at 3:35 PM, Sandro Bonazzola 
wrote:

>
>
> On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  wrote:
>
>> Hi all,
>>
>> Since commit f247a0cff310 (el7: require newly available
>> python34-nose), building vdsm
>> requires Python 3 on EL7.
>>
>> Unfortunately, it seems that ovirt-release-master that should add all
>> the dependencies
>> needed for vdsm does is not configured properly, so building vdsm will
>> fail.
>>
>
> Pithon 3 is not available in CentOS 7 and as far as I can tell it's not
> available in EPEL as well.
> Please drop Python3 on EL7.
>

​Well, there is Python 3.4 on EPEL:

https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/python34.html
​


>
>
>
>
>
>
>>
>> I heard that installing epel7 repo fixes this issue.
>>
>> Cheers,
>> Nir
>>
>> [1]
>> https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a915
>>
>
>
>
> --
> 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] [VDSM] Vdsm build requires now python 3 on EL7

[Sandro Bonazzola]

On Tue, Mar 29, 2016 at 3:21 PM, Nir Soffer  wrote:

> Hi all,
>
> Since commit f247a0cff310 (el7: require newly available
> python34-nose), building vdsm
> requires Python 3 on EL7.
>
> Unfortunately, it seems that ovirt-release-master that should add all
> the dependencies
> needed for vdsm does is not configured properly, so building vdsm will
> fail.
>

Pithon 3 is not available in CentOS 7 and as far as I can tell it's not
available in EPEL as well.
Please drop Python3 on EL7.






>
> I heard that installing epel7 repo fixes this issue.
>
> Cheers,
> Nir
>
> [1]
> https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a915
>



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