[ovirt-devel] engine-setup: ***L:ERROR Internal error: No module named dwh

[Jakub Niedermertl]

Hi all,

does anyone else experience following error of `engine-setup`?

$ ~/target/bin/engine-setup
***L:ERROR Internal error: No module named dwh

I have a suspicion it might be related to commit '221c7ed packaging: setup: 
Remove constants duplication'.

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

Re: [ovirt-devel] [vdsm] branch ovirt-4.0.5 created

[Francesco Romani]

- Original Message -
> From: "Dan Kenigsberg" 
> To: "Francesco Romani" 
> Cc: "Nir Soffer" , devel@ovirt.org
> Sent: Monday, October 10, 2016 5:11:26 PM
> Subject: Re: [vdsm] branch ovirt-4.0.5 created
> 
> On Mon, Oct 10, 2016 at 10:30:49AM -0400, Francesco Romani wrote:
> > Hi everyone,
> > 
> > this time I choose to create the ovirt-4.0.5 branch.
> > I already merged some patches for 4.0.6.
> > 
> > Unfortunately I branched a bit too early (from last tag :))
> > 
> > So patches
> > https://gerrit.ovirt.org/#/c/65303/1
> > https://gerrit.ovirt.org/#/c/65304/1
> > https://gerrit.ovirt.org/#/c/65305/1
> > 
> > Should be trivially mergeable - the only thing changed from ovirt-4.0
> > counterpart
> > is the change-id. Please have a quick look just to doublecheck.
> 
> Change-Id should be the same for a master patch and all of its backport.
> It seems that it was NOT changed, at least for
> https://gerrit.ovirt.org/#/q/I5cea6ec71c913d74d95317ff7318259d64b40969
> which is a GOOD thing.

Yes, sorry, indeed it is (and indeed it should not change).
 
> I think we want to enable CI on the new 4.0.5 branch, right? Otherwise
> we'd need to fake the CI+1 flag until 4.0.5 is shipped.

We should, but it is not urgently needed - just regular priority.
For the aforementioned first three patches especially I'm just overly
cautious.

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

Re: [ovirt-devel] Outreachy internship

[Francesco Romani]

- Original Message -
> From: "Саша Ершова" 
> To: devel@ovirt.org
> Sent: Wednesday, October 5, 2016 7:40:21 PM
> Subject: [ovirt-devel] Outreachy internship
> 
> Dear all,
> My name is Alexandra Ershova, and I'm a student in Natural Language
> Processing in Higher School of Economics, Moscow, Russia. I'd like to take
> part in the current round of Outreachy internships. My main programming
> language is Python (I have experience with both 2 and 3). Writing system
> tests seems like an interesting project to me, and I would like to do it.
> Could you please give me an application task, so that I could make my first
> contribution?

hello Alexandra, thanks for your interet in oVirt!

In addition to what Yaniv already outlined, did you manage to run the Vdsm 
testsuite?

A good first step could be indeed to make sure the lago environment is up and 
running and
it can run the ovirt system tests.

Feel free to file issues ond/or ask for help also on the devel@ovirt.org 
mailing list.
Once you are played a bit with lago, it is a good idea to introduce yourself 
here;
you can find a broader audience and even more mentors for lago itself (the lago 
developers
hang around on thet ML).

I recommend to work on a CentOS 7.2 or Fedora 24 system, either real or 
virtualized.

Should you have any question, feel free to post a message on devel@ovirt.org, 
or ping me
on irc (fromani on the #vdsm channel on freenode).

Please note the following assumes you have one oVirt installation (of any 
kind), and basic knowledge
of the architecture.

The application task for the idea you expressed interest in is:

1. write a system test to make sure one host has the 'ovirtmgmt' network 
available (defined, and running).
   another way to check this is to make sure the host has one active nic which 
is part of the aforementioned
   network. You can check this from the oVirt Engine webadmin UI: select the 
"host" panel, check
   the "network interfaces" subtab in the lower portion of the screen.

Please note the above is a VERY terse introduction. You will likely need 
clarifications.
You are more than welcome to ask for clarifications via mail (here), and/or 
join the #vdsm
IRC channel on the freenode network.

-- 
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] Project Proposal - Vagrant provider

[Oved Ourfali]

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

Thanks!
Oved


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

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

[ovirt-devel] [vdsm] branch ovirt-4.0.5 created

[Francesco Romani]

Hi everyone,

this time I choose to create the ovirt-4.0.5 branch.
I already merged some patches for 4.0.6.

Unfortunately I branched a bit too early (from last tag :))

So patches
https://gerrit.ovirt.org/#/c/65303/1
https://gerrit.ovirt.org/#/c/65304/1
https://gerrit.ovirt.org/#/c/65305/1

Should be trivially mergeable - the only thing changed from ovirt-4.0 
counterpart
is the change-id. Please have a quick look just to doublecheck.

patches
https://gerrit.ovirt.org/#/c/65306/1
https://gerrit.ovirt.org/#/c/65307/1

are ready anytime once the three above are mentioned.
They are very simple and safe.

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

[ovirt-devel] oVirt 4.0.5 RC2 merge / branch / tag / bugzilla reminder

[Sandro Bonazzola]

All stable branch maintainers, please make sure to

   - merge all relevant open bugs until Wednesday morning 10:00 AM TLV time.


For each package that need to be built (i.e oVirt product) please make sure
every bug in MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building
and should include the same version you used for the tag you just used for
this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.5.1, tr: 4.0.5.1)
A list of bugs that require attention is here:

   -
   
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.5%20target_release%3A---%20status%3Amodified%2Cpost


-- 
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] oVirt 4.0.5 RC2 build planned

[Sandro Bonazzola]

Fyi oVirt developers,

An oVirt build is planned for this Wednesday 10:00 AM TLV time (9:00 AM
CEST).
Taking into consideration the time it takes for Jenkins to run a full CI
everything need to be backported by Tuesday 11PM.
Please make sure to mark as verified and CR +2 so it will be ready for
merging Wednesday morning.

A list of pending blockers is available here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.5%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost

-- 
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] Project Proposal - Vagrant provider

[Marc Young]

Project Proposal - Vagrant Provider

A vagrant provider for oVirt v4

Abstract

This will be a provider plugin for the Vagrant suite that allows
command-line ease of virtual machine provisioning and lifecycle
management.

Proposal

This Vagrant provider plugin will interface with the oVirt REST API
(version 4 and higher) using the oVirt provided ruby SDK
'ovirt-engine-sdk-ruby'. This allows users to abstract the user
interface and experience into a set of command line abilities to
create, provision, destroy and manage the complete lifecycle of
virtual machines. It also allows the use of external configuration
management and configuration files themselves to be committed into
code.

Background

I have previously forked and maintained the 'vagrant-ovirt' gem as
'vagrant-ovirt3' due to Gems requiring unique names. The original
author has officially abandoned the project. For the last few years
all code to maintain this project has been maintained by myself and a
few ad-hoc github contributors. This provider interfaced directly with
oVirt v3 using fog and rbovirt. The new project would be a fresh start
using the oVirt provided ruby SDK to work directly with version 4.

Rationale

The trend in configuration management, operations, and devops has been
to maintain as much of the development process as possible in terms of
the virtual machines and hosts that they run on. With software like
Terraform the tasks of creating the underlying infrastructure such as
network rules, etc have had great success moving into 'Infrastructure
as code'. The same company behind Terraform got their reputation from
Vagrant which aims to utilize the same process for virtual machines
themselves. The core software allows for standard commands such as
'up', 'provision', 'destroy' to be used across a provider framework. A
provider for oVirt makes the process for managing VMs easier and able
to be controlled through code and source control.

Initial Goals

The initial goal is to get the base steps of 'up', 'down' (halt), and
'destroy' to succeed using the oVirt provided ruby SDK for v4.
Stretch/followup goals would be to ensure testability and alternate
commands such as 'provision' and allow configuration management suites
like puppet to work via 'userdata' (cloud-init).

Current Status

The version 3 of this software has been heavily utilized. The original
fork known as 'vagrant-ovirt' has been abandoned with no plans to
communicate or move forward. My upstream fork has had great success
with nearly 4x the downloads from rubygems.org . Until my github fork
has more 'stars' I cannot take over it completely so the gem was
renamed 'vagrant-ovirt3'. This is also true for rubygems.org since
gems are not namespaced, therefore could not be published without a
unique name. The v4 provider is still pending my initial POC commit
but there are no current barriers except initial oVirt hosting. The
hosting of oVirt v3 for testing is a laptop on a UPS at my home, and
v4 is also a different pc attached to a UPS.

External Dependencies

RHEVM/oVirt REST API - This provider must interact with the API itself
to manage virtual machines.

Initial Committers

Marcus Young ( 3vilpenguin at gmail dot com )
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

On 10/07/2016 09:44 PM, Yaniv Kaul wrote:
> I'm trying on FC24, using
> python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to add
> a DC, and failing - against master. The client is unhappy:
> File
> "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
> line 98, in add_dc4
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line
> 4347, in add
> response = self._connection.send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 276, in send
> return self.__send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 298, in __send
> self._sso_token = self._get_access_token()
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 460, in _get_access_token
> sso_response = self._get_sso_response(self._sso_url, post_data)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 498, in _get_sso_response
> return json.loads(body_buf.getvalue().decode('utf-8'))
>   File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads
> return _default_decoder.decode(s)
>   File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
> 

That is what happens when you try to connect version 3 of the server
with version 4 of the SDK: OAuth authentication fails with this
unexpected error. Are you sure you are using version 4 of the engine?
Can you try a simpler request? For example, try this example:


https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/test_connection.py

That will generate an "example.log" file. Can you share it? Take into
account that the log will contain your password, so make sure to remove
it or share it privately.

> 
> Surprisingly, I now can't find that RPM of this SDK in
> resources.ovirt.org  now.
> 
> I've tried
> with 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm
> 
>  
> 
> - same result.
> 
> Did not see anything obvious on server or engine logs.
> The code:
> def add_dc4(api):
> nt.assert_true(api != None)
> dcs_service = api.system_service().data_centers_service()
> nt.assert_true(
> dc = dcs_service.add(
> sdk4.types.DataCenter(
> name=DC_NAME4,
> description='APIv4 DC',
> local=False,
>
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> ),
> )
> )
> 
> 
> And the api object is from:
> return sdk4.Connection(
> url=url,
> username=constants.ENGINE_USER,
> password=str(self.metadata['ovirt-engine-password']),
> insecure=True,
> debug=True,
> )
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Ondra Machacek]

On 10/07/2016 09:44 PM, Yaniv Kaul wrote:

I'm trying on FC24, using
python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to add
a DC, and failing - against master. The client is unhappy:
File
"/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
line 98, in add_dc4
version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line
4347, in add
response = self._connection.send(request)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
276, in send
return self.__send(request)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
298, in __send
self._sso_token = self._get_access_token()
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
460, in _get_access_token
sso_response = self._get_sso_response(self._sso_url, post_data)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
498, in _get_sso_response
return json.loads(body_buf.getvalue().decode('utf-8'))
  File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
  File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded



This error means something wrong during authentication.
The JSON SSO response returned something unexpected.

Anyway I've tried with current master and everything is fine for me.

Can you please send debug log of the SDK?

import loggging
logging.basicConfig(level=logging.DEBUG, filename='/tmp/debug.log')

return sdk4.Connection(
  url=url,
  username=constants.ENGINE_USER,
  password=str(self.metadata['ovirt-engine-password']),
  insecure=True,
  log=logging.getLogger(),
  debug=True,
)



Surprisingly, I now can't find that RPM of this SDK in
resources.ovirt.org  now.

I've tried
with 
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm


- same result.

Did not see anything obvious on server or engine logs.
The code:
def add_dc4(api):
nt.assert_true(api != None)
dcs_service = api.system_service().data_centers_service()
nt.assert_true(
dc = dcs_service.add(
sdk4.types.DataCenter(
name=DC_NAME4,
description='APIv4 DC',
local=False,

version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
),
)
)


And the api object is from:
return sdk4.Connection(
url=url,
username=constants.ENGINE_USER,
password=str(self.metadata['ovirt-engine-password']),
insecure=True,
debug=True,
)



___
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