Re: [ovirt-devel] [ovirt-users] Cockpit oVirt support

[Marek Libra]

Regarding libvirt, there's fallback to Libvirt provider (part of
cockpit-machines) for VMs which are not managed by oVirt.
For the oVirt ones, oVirt API handles all the actions.

It's not yet implemented, but I'm considering to fallback to Libvirt for
selected actions in case the oVirt API can't be reached. Like for shut down
[1].

Anyway, there's still open question with the Libvirt connection since it's
secured on an oVirt host.

[1] https://github.com/cockpit-project/cockpit/issues/7670

On Wed, Oct 18, 2017 at 3:18 PM, Ryan Barry <rba...@redhat.com> wrote:

> This looks great, guys. Congrats!
>
> Does this also work with plain libvirt?
>
> On Wed, Oct 18, 2017 at 3:24 AM, Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>> Hi all,
>> I’m happy to announce that we finally finished initial contribution of
>> oVirt specific support into the Cockpit management platform
>> See below for more details
>>
>> There are only limited amount of operations you can do at the moment, but
>> it may already be interesting for troubleshooting and simple admin actions
>> where you don’t want to launch the full blown webadmin UI
>>
>> Worth noting that if you were ever intimidated by the complexity of the
>> GWT UI of oVirt portals and it held you back from contributing, please take
>> another look!
>>
>> Thanks,
>> michal
>>
>> Begin forwarded message:
>>
>> *From: *Marek Libra <mli...@redhat.com>
>> *Subject: **Re: Cockpit 153 released*
>> *Date: *17 October 2017 at 16:02:59 GMT+2
>> *To: *Development discussion for the Cockpit Project <
>> cockpit-de...@lists.fedorahosted.org>
>> *Reply-To: *Development discussion for the Cockpit Project <
>> cockpit-de...@lists.fedorahosted.org>
>>
>> Walk-through video for the new "oVirt Machines" page can be found here:
>> https://youtu.be/5i-kshT6c5A
>>
>> On Tue, Oct 17, 2017 at 12:08 PM, Martin Pitt <mp...@redhat.com> wrote:
>>
>>> http://cockpit-project.org/blog/cockpit-153.html
>>>
>>> Cockpit is the modern Linux admin interface. We release regularly. Here
>>> are the release notes from version 153.
>>>
>>>
>>> Add oVirt package
>>> -
>>>
>>> This version introduces the "oVirt Machines" page on Fedora for
>>> controlling
>>> oVirt virtual machine clusters.  This code was moved into Cockpit as it
>>> shares
>>> a lot of code with the existing "Machines" page, which manages virtual
>>> machines
>>> through libvirt.
>>>
>>> This feature is packaged in cockpit-ovirt and when installed it will
>>> replace
>>> the "Machines" page.
>>>
>>> Thanks to Marek Libra for working on this!
>>>
>>> Screenshot:
>>>
>>> http://cockpit-project.org/images/ovirt-overview.png
>>>
>>> Change: https://github.com/cockpit-project/cockpit/pull/7139
>>>
>>>
>>> Packaging cleanup
>>> -
>>>
>>> This release fixes a lot of small packaging issues that were spotted by
>>> rpmlint/lintian.
>>>
>>> Get it
>>> --
>>>
>>> You can get Cockpit here:
>>>
>>> http://cockpit-project.org/running.html
>>>
>>> Cockpit 153 is available in Fedora 27:
>>>
>>> https://bodhi.fedoraproject.org/updates/cockpit-153-1.fc27
>>>
>>> Or download the tarball here:
>>>
>>> https://github.com/cockpit-project/cockpit/releases/tag/153
>>>
>>>
>>> Take care,
>>>
>>> Martin Pitt
>>>
>>> ___
>>> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
>>> To unsubscribe send an email to cockpit-devel-le...@lists.fedo
>>> rahosted.org
>>>
>>>
>>
>>
>> --
>> Marek Libra
>>
>> senior software engineer
>> Red Hat Czech
>>
>> <https://www.redhat.com/>
>> ___
>> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
>> To unsubscribe send an email to cockpit-devel-le...@lists.fedo
>> rahosted.org
>>
>>
>>
>> ___
>> Users mailing list
>> us...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
> --
>
> RYAN BARRY
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHEV HYPERVISOR
>
> Red Hat NA <https://www.redhat.com/>
>
> rba...@redhat.comM: +1-651-815-9306 IM: rbarry
> <https://red.ht/sig>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

Marek Libra

senior software engineer

Red Hat Czech

<https://www.redhat.com>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Unable to add host in oVirt 4.2 (clean install)

[Marek Libra]

Since Andrej ran in similar issue today, I'm posting for others:

When installing oVirt 4.2 first alpha release from scratch on fresh Centos
7 minimal, adding host failed. Unfortunately, I don't have log messages
anymore, but I remember last errors were misleadingly related to ovn (no
matter the ovn was not configured on the engine).

The issue was resolved by manual installation of python-netaddr package on
the host. Subsequently, adding the host in webadmin passed.

What package should require the python-netaddr? ovirt-provider-ovn-driver?

I hope it helps,
Marek
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Announcing VM Portal 0.1.4

[Marek Libra]

Hello All,

Let me announce availability of the VM Portal v0.1.4 for preliminary
testing.
We are looking forward to your feedback which we will try to incorporate
into oncoming stable 1.0.0 version.

The VM Portal aims to be a drop-in replacement of the existing Basic User
Portal.
Revised list of Extended User Portal features will be implemented to
ideally replace it as well.

The VM Portal is installed by default since oVirt 4.1.

*The simplest way to try latest version is via Docker by [1].*
Once oVirt credentials are entered and initialization is finished, you can
access it on [2].

If you prefer to stay as closest to the production setup as possible, the
latest rpms are available on project's yum repo [3].
Then you can access the portal from [4].

Prerequisites: The VM Portal requires ovirt-engine 4.0+, so far mostly
tested on 4.1.

Please note, the docker image is so far meant to just simplify user testing
and is not ready for production setup.
Unless decided otherwise in the future, stable releases are still planed to
be deployed via rpms.

For issue reporting or enhancement ideas, please use project's github issue
tracker [5].

Thank you for your feedback,
Marek


[1] docker run --rm -it -e ENGINE_URL=https://[OVIRT.ENGINE.FQDN]/ovirt-engine/
-p 3000:3000 mareklibra/ovirt-web-ui:latest
[2] http://localhost:3000
[3] https://people.redhat.com/mlibra/repos/ovirt-web-ui
[4] https://[OVIRT.ENGINE.FQDN]/ovirt-engine/web-ui
[5] https://github.com/oVirt/ovirt-web-ui/issues


-- 

Marek Libra

senior software engineer

Red Hat Czech

<https://www.redhat.com>


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

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Marek Libra]

With
  https://gerrit.ovirt.org/#/c/74619/

applied, following is still failing:
  make gwt-debug DEBUG_MODULE=webadmin
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.cssResourceStyle=pretty
-Dgwt.userAgent=gecko1_8"

with message:
[WARNING] The requested profile "gwt-user" could not be activated because
it does not exist.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle) on
project webadmin: Failed during checkstyle configuration: Exception was
thrown while processing
/home/mlibra/IdeaProjects/ovirt-engine/frontend/webadmin/modules/gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java:
can't parse argument number: For input string: "" -> [Help 1]


Any hint, please?
Marek



On Fri, Mar 24, 2017 at 4:14 PM, Vojtech Szocs  wrote:

>
>
> On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs  wrote:
>
>> Found the problem after debugging NlsCheck.
>>
>> First of all, it checks all kinds of Java sources, including the
>> generated ones. That's silly and one of the reasons why Checkstyle
>> execution takes a rather long time. I'll fix that.
>>
>> Next, when checking a Java source that contains string "{}" (without
>> quotes) it will log the problem, but Checkstyle message logging infra
>> things that "{}" is a placeholder to resolve, but it's not, and it fails on
>> NumberFormatException. I'll fix that too.
>>
>
> ​https://gerrit.ovirt.org/#/c/74611/​
>
>
>> Vojtech
>>
>>
>> On Fri, Mar 24, 2017 at 3:19 PM, Vojtech Szocs  wrote:
>>
>>> Hi Allon,
>>>
>>> I think I found some strange Checkstyle related problems on master.
>>>
>>> Engine build with (GWT compilation enabled) works OK.
>>>
>>> Next, trying to start GWT debugger:
>>>
>>> $ make gwt-debug DEBUG_MODULE=webadmin \
>>>   DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" \
>>>   DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
>>> -Dgwt.compiler.localWorkers=1" \
>>>   DEV_BUILD_GWT_SUPER_DEV_MODE=1
>>>
>>> maven-checkstyle-plugin:check execution fails on
>>>
>>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>>> irt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Forma
>>> tterDotnet.java
>>>   can't parse argument number: (\\d)\\: For input string: "(\\d)\\"
>>>
>>> the class isn't used, removed it, retry. Now it fails on:
>>>
>>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>>> irt/engine/ui/uioverrides/org/slf4j/Logger.java
>>>   can't parse argument number: For input string: ""
>>>
>>> I guess it's a bug in our NON-NLS check? But why doesn't the problem
>>> occur during Engine build?
>>>
>>> I'm thinking about disabling Checkstyle for gwt-extension module, as it
>>> contains custom GWT RPC serializers and GWT class overrides, and maybe the
>>> file path src/main/java/org/ovirt/engine/ui/uioverrides/here/goes/actual/pkg
>>> is confusing the Checkstyle now.
>>>
>>> Thanks,
>>> Vojtech
>>>
>>>
>>> On Wed, Mar 22, 2017 at 10:33 PM, Allon Mureinik 
>>> wrote:
>>>
 Hi all,

 As per [1], I've just merged a series of patches that upgrades the
 oVirt engine to use the latest maven-checkstyle-plugin and checkstyle
 packages.

 Please note that the newer checkstyle is a tad stricter than the old
 one we used to have (read: it contains several fixes for bugs where the old
 checkstyle was supposed to find issues but missed them).
 I also took the opportunity and added a couple of new checks that
 enforce rules we were de-facto adhering to anyway.

 If any problems come up, please let me know.


 -Your friendly neighborhood cleanup dude

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

 ___
 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] SSO/CORS for remote non-Java apps

[Marek Libra]

Default CORS allowed origins can be generated dynamically, please have a
look at https://gerrit.ovirt.org/#/c/68529/ .
With this patch, all hosts are allowed.

The CORSSupportFilter delegates all processing to the eBay's CORSFilter
which needs to be reinitialized if the list of origins is changed.
So for simplicity, it's better to keep optimization on CORSSupportFilter
and not in the backend query.

Regarding performance, there's almost no processing if CorsSupported=false.
So it's ok.
If otherwise, the cache of host list must be maintained (host add/remove).
To avoid coupling this code with backend commands, the list is re-read at
most once per minute and the CORSFilter is optionally reinitialized.

Recently the CORSSupportFilter works already fine for REST API. For
enginesso.war some more work remains..
But once this is done, external applications served from hosts shall be
able to access both API and SSO.

And host add/remove will not require engine restart.


On Mon, Dec 12, 2016 at 7:42 PM, Vojtech Szocs <vsz...@redhat.com> wrote:

> Hi,
>
> I agree with Juan that handling the list of "allowed origins" for CORS
> filter should be done carefully, since that filter applies to each and
> every REST API request.
>
> > For completeness, there's already another patch providing SSO for
> non-GWT applications, but deployed along with the ovirt-engine and packaged
> in .war, no matter if the application itself is non-Java one.
> > See https://gerrit.ovirt.org/#/c/67206/ .
>
> That ^^ new filter is for enginesso.war or a different .war?
>
> The general problem is, from an external web application perspective,
> how to:
>
> a, obtain SSO token
>
>- reusing some "externally given" token is generally a bad idea,
>  unless the external application is "under control" of enclosing
>  application that issued the token, for example => UI plugins
>
>- therefore, requesting new token per each external application
>  should be the way to go, in general
>
> b, call REST API with SSO token
>
>- using HTTP basic auth is generally a bad idea (many reasons)
>
> c, (optional, just an idea) tighter UI integration
>
>- add infra to manage "trusted" web applications, these will show
>  up on the oVirt welcome page
>
>- when accessing "trusted" web application (via the welcome page),
>  get current user's SSO token and pass it to that application
>
> As for CORS "allowed origins" list: this is currently managed through
> `CORSAllowedOrigins` Engine config value. This list is read only once
> (on 1st CORSSupportFilter access). So any change in following options:
>
>   CORSSupport # true or false
>   CORSAllowedOrigins # comma separated list of protocol://domain:port
>
> requires Engine restart, which isn't too flexible.
>
> After we acknowledge that CORS is a necessary feature of oVirt Engine
> (in relation to SSO/REST usage from external application context), we
> should introduce a better interface to manage CORS settings, *without*
> having to restart Engine on each change.
>
> Regards,
> Vojtech
>
>
> - Original Message -
> > From: "Juan Hernández" <jhern...@redhat.com>
> > To: "Marek Libra" <mli...@redhat.com>, "devel" <devel@ovirt.org>
> > Sent: Monday, December 12, 2016 9:22:03 AM
> > Subject: Re: [ovirt-devel] SSO/CORS for remote non-Java apps
> >
> > On 12/12/2016 08:03 AM, Marek Libra wrote:
> > > The proposed way is:
> > > - use CORS filter for enginesso.war (https://gerrit.ovirt.org/68062)
> > > - at host installation, add the host to CORSAllowedOrigins
> > >- on engine host: # engine-config -s 'CORSAllowedOrigins=[host IPs]'
> > >
> > > So if Cockpit's plugin accesses the oVirt REST API, CORS will work.'
> > >
> >
> > Note that adding the host with 'engine-config' isn't ideal, as it would
> > require to restart the engine whenever a host is installed. In addition
> > you would also need to find a way to update the configuration when a
> > host is removed.
> >
> > I think that it would be better to change the CORS filter so that it
> > gets the list of allowed origins running a query that returns the list
> > of hosts. That needs to be done with care, probably caching it somehow,
> > as otherwise that query would run once for each API request, killing
> > performance. I suggest something like this:
> >
> > 1. Store in the backend, in memory, the list of allowed origins.
> >
> > 2. During startup populate that with the list of hosts.
> >
> > 3. Whenever a host is added or removed (with t

Re: [ovirt-devel] [ACTION REQUIRED] ovirt-cokpit broken, please fix

[Marek Libra]

Not sure yet, but most probably with updating nodejs in ovirt-engine-nodejs
we need to update babel to 6.10.4 or higher in ovirt-engine-nodejs-modules
as well.

On Fri, Dec 16, 2016 at 11:45 AM, Sandro Bonazzola 
wrote:

> http://jenkins.ovirt.org/job/cockpit-ovirt_master_check-merged-el7-x86_64/128/artifact/exported-artifacts/logs/mocker-epel-7-x86_64.el7.check-merged.sh/check-merged.sh.log
>
>
> WARNING in bundle.js from UglifyJs
> Side effects in initialization of unused variable CONFIG 
> [./src/constants.js:2,13]
> Side effects in initialization of unused variable VM_STATUS_ICONS_PATH_PREFIX 
> [./src/constants.js:42,13]
> Side effects in initialization of unused variable VM_STATUS_ICONS 
> [./src/constants.js:43,13]
> Side effects in initialization of unused variable GLOBAL 
> [./src/globaldata.js:1,11]
> Condition always true [./~/d3/d3.js:9553,0]
> Dropping unreachable code [./~/d3/d3.js:9553,75]
> Condition always true [./~/c3/c3.js:52,0]
> Condition always true [./~/c3/c3.js:8194,0]
> Dropping unreachable code [./~/c3/c3.js:8196,5]
> Condition always false [./~/style-loader/addStyles.js:24,0]
> Dropping unreachable code [./~/style-loader/addStyles.js:25,0]
> Condition always false 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:10,0]
> Dropping unreachable code 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:12,0]
> Side effects in initialization of unused variable update 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:7,0]
> Condition always false 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:10,0]
> Dropping unreachable code 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:12,0]
> Side effects in initialization of unused variable update 
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:7,0]
>
> ERROR in Path must be a string. Received undefined
> chmod a+x dist/vdsm/vdsm
> chmod: cannot access ‘dist/vdsm/vdsm’: No such file or directory
> make[1]: *** [vdsm] Error 1
> make[1]: Leaving directory 
> `/home/jenkins/workspace/cockpit-ovirt_master_check-merged-el7-x86_64/cockpit-ovirt/vdsm'
> make: *** [check-recursive] Error 1
> Took 229 seconds
>
>
> --
> 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] SSO/CORS for remote non-Java apps

[Marek Libra]

The proposed way is:
- use CORS filter for enginesso.war (https://gerrit.ovirt.org/68062)
- at host installation, add the host to CORSAllowedOrigins
   - on engine host: # engine-config -s 'CORSAllowedOrigins=[host IPs]'

So if Cockpit's plugin accesses the oVirt REST API, CORS will work.'

On Fri, Dec 9, 2016 at 3:42 PM, Marek Libra <mli...@redhat.com> wrote:

> Hi,
>
> How can external, purely JavaScript application, running in a browser and
> served from non-engine host access the oVirt REST API?
>
> Recent SSO implementation does not provide CORS support. It can be fixed
> by https://gerrit.ovirt.org/68062 .
>
> How shall this support for external application look like?
>
> More details are in our so far discussion with Juan bellow.
>
> For completeness, there's already another patch providing SSO for non-GWT
> applications, but deployed along with the ovirt-engine and packaged in
> .war, no matter if the application itself is non-Java one.
> See https://gerrit.ovirt.org/#/c/67206/ .
>
> -- Forwarded message --
> From: Juan Hernández <jhern...@redhat.com>
> Date: Fri, Dec 9, 2016 at 2:40 PM
> Subject: Re: CORSSuport
> To: Marek Libra <mli...@redhat.com>
>
>
> On 12/09/2016 02:26 PM, Marek Libra wrote:
> > Thanks for your quick response and fast action :-)
> >
> > I'm working on integration of oVirt to Cockpit, ideally purely JS
> > application (Cockpit's plugin) will access oVirt REST API without using
> > any proxy.
> > The Cockpit is running on an oVirt host.
> >
> > IIUC, the OAuth token is *required* to access the REST API.
> >
>
> The OAuth token isn't strictly required at the moment: the API also
> supports HTTP basic authentication. The OAuth token will be required
> when support for version 3 of the API and support for basic
> authentication are removed. We intend to remove those two things in
> version 4.2 of oVirt.
>
> > If so, there are just two options for external javascript application
> > willing to access the API:
> > [1] either reuse "externaly given Bearer token'' - some oVirt web
> > application served from engine node would need to provide it to the JS
> > application running elsewhere
> > [2] or call the /ovirt-engine/sso service to get one
> >
> > Regarding [1], I havn't tried it yet, but from checking the SSO filters
> > in ovirt-engine, this might work since it's retrieving session based on
> > token. What do you think?
> >
> > Regarding [2], the patch you posted would be needed.
> >
> > Do I miss something?
> >
>
> There is option 3: use HTTP basic authentication. But that won't work
> with oVirt 4.2 or newer, so doesn't look like a reasonable thing.
>
> I think that the only reasonable option is [2]. However, we can't (or
> should not) just configure the existing CORS support to accept any
> origin (CORSAllowedOrigins=*) as that isn't secure. We will probably
> need to have a dynamic list of allowed origins: the list of hosts. That
> would need extensive changes to the CORS filter.
>
> So, for your experiments, you can just move the current filter so that
> it can be used by the SSO application. But for real use we need to think
> a bit deeper on how should CORS support work. I'd suggest that you open
> this discussion to a wider audience, within your team, or in the
> upstream mailing list.
>
> > Thanks
> >
> > On Fri, Dec 9, 2016 at 1:53 PM, Juan Hernández <jhern...@redhat.com
> > <mailto:jhern...@redhat.com>> wrote:
> >
> > On 12/09/2016 01:38 PM, Marek Libra wrote:
> > > Hi Juan,
> > >
> > > I'm trying to set up CORS on ovirt-engine following instructions in
> > > https://gerrit.ovirt.org/#/c/36367/
> > <https://gerrit.ovirt.org/#/c/36367/> .
> > > But I can't get the 'Access-Control-Allow-Origin' to be returned.
> > >
> > > -- My ovirt-engine:
> > >
> >  ovirt-engine-4.1.0-0.0.master.20161121231311.git19a0953.el7.
> centos.noarch
> > >
> > > -- On engine host:
> > > # engine-config -s CORSSupport=true
> > > # engine-config -s 'CORSAllowedOrigins=*'
> > > # systemctl restart ovirt-engine
> > >
> > >
> > > -- My JS call looks like:
> > >
> > > var url = baseUrl +
> > >
> > '/sso/oauth/token?grant_type=urn:ovirt:params:oauth:grant-t
> ype:http=ovirt-app-api';
> > > $.ajax(url, {
> > > type: 'GET',
> > > headers: {
> > > 'Accept': 'application/json',

[ovirt-devel] SSO/CORS for remote non-Java apps

[Marek Libra]

Hi,

How can external, purely JavaScript application, running in a browser and
served from non-engine host access the oVirt REST API?

Recent SSO implementation does not provide CORS support. It can be fixed by
https://gerrit.ovirt.org/68062 .

How shall this support for external application look like?

More details are in our so far discussion with Juan bellow.

For completeness, there's already another patch providing SSO for non-GWT
applications, but deployed along with the ovirt-engine and packaged in
.war, no matter if the application itself is non-Java one.
See https://gerrit.ovirt.org/#/c/67206/ .

-- Forwarded message --
From: Juan Hernández <jhern...@redhat.com>
Date: Fri, Dec 9, 2016 at 2:40 PM
Subject: Re: CORSSuport
To: Marek Libra <mli...@redhat.com>


On 12/09/2016 02:26 PM, Marek Libra wrote:
> Thanks for your quick response and fast action :-)
>
> I'm working on integration of oVirt to Cockpit, ideally purely JS
> application (Cockpit's plugin) will access oVirt REST API without using
> any proxy.
> The Cockpit is running on an oVirt host.
>
> IIUC, the OAuth token is *required* to access the REST API.
>

The OAuth token isn't strictly required at the moment: the API also
supports HTTP basic authentication. The OAuth token will be required
when support for version 3 of the API and support for basic
authentication are removed. We intend to remove those two things in
version 4.2 of oVirt.

> If so, there are just two options for external javascript application
> willing to access the API:
> [1] either reuse "externaly given Bearer token'' - some oVirt web
> application served from engine node would need to provide it to the JS
> application running elsewhere
> [2] or call the /ovirt-engine/sso service to get one
>
> Regarding [1], I havn't tried it yet, but from checking the SSO filters
> in ovirt-engine, this might work since it's retrieving session based on
> token. What do you think?
>
> Regarding [2], the patch you posted would be needed.
>
> Do I miss something?
>

There is option 3: use HTTP basic authentication. But that won't work
with oVirt 4.2 or newer, so doesn't look like a reasonable thing.

I think that the only reasonable option is [2]. However, we can't (or
should not) just configure the existing CORS support to accept any
origin (CORSAllowedOrigins=*) as that isn't secure. We will probably
need to have a dynamic list of allowed origins: the list of hosts. That
would need extensive changes to the CORS filter.

So, for your experiments, you can just move the current filter so that
it can be used by the SSO application. But for real use we need to think
a bit deeper on how should CORS support work. I'd suggest that you open
this discussion to a wider audience, within your team, or in the
upstream mailing list.

> Thanks
>
> On Fri, Dec 9, 2016 at 1:53 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
>
> On 12/09/2016 01:38 PM, Marek Libra wrote:
> > Hi Juan,
> >
> > I'm trying to set up CORS on ovirt-engine following instructions in
> > https://gerrit.ovirt.org/#/c/36367/
> <https://gerrit.ovirt.org/#/c/36367/> .
> > But I can't get the 'Access-Control-Allow-Origin' to be returned.
> >
> > -- My ovirt-engine:
> >
>  ovirt-engine-4.1.0-0.0.master.20161121231311.git19a0953.el7.
centos.noarch
> >
> > -- On engine host:
> > # engine-config -s CORSSupport=true
> > # engine-config -s 'CORSAllowedOrigins=*'
> > # systemctl restart ovirt-engine
> >
> >
> > -- My JS call looks like:
> >
> > var url = baseUrl +
> >
> '/sso/oauth/token?grant_type=urn:ovirt:params:oauth:grant-
type:http=ovirt-app-api';
> > $.ajax(url, {
> > type: 'GET',
> > headers: {
> > 'Accept': 'application/json',
> > 'Authorization': 'Basic ' + window.btoa(user + ':' + pwd),
> > 'Content-Type': 'application/xml'
> > } })
> > .then(data => {
> > logDebug(`login successful: ${JSON.stringify(data)}`);
> > Promise.resolve(data)
> > })
> > .catch(data => {
> > logDebug('Ajax failed: ' + JSON.stringify(data));
> > return Promise.reject(data);
> > });
> >
> >
> > -- From Chrome:
> > Request
> >
> URL:https://engine.local/ovirt-engine/sso/oauth/token?
grant_type=urn:ovirt:params:oauth:grant-type:http=ovirt-app-api
> <https://engine.local/ovirt-engine/sso/oauth/token?grant_
type=urn:ovirt:params:oauth:grant-type:http=ovirt-app-api>
>

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

[Marek Libra]

There are issues on other keys as well. 
I'm rebuilding for all locales locally now. 

- Original Message -

> From: "Marek Libra" <mli...@redhat.com>
> To: "devel" <devel@ovirt.org>
> Sent: Wednesday, May 4, 2016 11:29:55 AM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken

> The fix is here: https://gerrit.ovirt.org/#/c/57007/

> - Original Message -

> > From: "Roman Mohr" <rm...@redhat.com>
> 
> > To: "Oved Ourfali" <oourf...@redhat.com>
> 
> > Cc: "devel" <devel@ovirt.org>
> 
> > Sent: Wednesday, May 4, 2016 10:27:51 AM
> 
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 

> > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com >
> > wrote:
> 

> > > Roman - did you build the langs in order to find the issue?
> > 
> 

> > I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not all
> > of my builds showed that error.
> 

> > Looking at
> 

> > https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration
> 

> > two patches passed and two failed after a topic rebase.
> 

> > > Eyal - can we monitor a list of files that i changed will result in also
> > > building all the languages?
> > 
> 

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

> > > > right, and we can't enable lang permutation since it takes a very long
> > > > time
> > > > to run.
> > > 
> > 
> 

> > > > On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek < tjeli...@redhat.com >
> > > > wrote:
> > > 
> > 
> 

> > > > > - Original Message -
> > > > 
> > > 
> > 
> 
> > > > > > From: "Oved Ourfali" < oourf...@redhat.com >
> > > > 
> > > 
> > 
> 
> > > > > > To: "Tomas Jelinek" < tjeli...@redhat.com >
> > > > 
> > > 
> > 
> 
> > > > > > Cc: "Roman Mohr" < rm...@redhat.com >, "devel" < devel@ovirt.org >,
> > > > > > "Scott
> > > > > > Dickerson" < sdick...@redhat.com >
> > > > 
> > > 
> > 
> 
> > > > > > Sent: Wednesday, May 4, 2016 9:55:40 AM
> > > > 
> > > 
> > 
> 
> > > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > I wonder, how come the CI didn't catch that?
> > > > 
> > > 
> > 
> 

> > > > > because this happens only when you compile with language permutations
> > > > 
> > > 
> > 
> 

> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek <
> > > > > > tjeli...@redhat.com
> > > > > > >
> > > > > > wrote:
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > > hmmm,
> > > > 
> > > 
> > 
> 
> > > > > > > regression introduced yesterday by
> > > > > > > https://gerrit.ovirt.org/#/c/56720/
> > > > 
> > > 
> > 
> 
> > > > > > > fix on the way
> > > > 
> > > 
> > 
> 
> > > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > > - Original Message -
> > > > 
> > > 
> > 
> 
> > > > > > > > From: "Roman Mohr" < rm...@redhat.com >
> > > > 
> > > 
> > 
> 
> > > > > > > > To: "devel" < devel@ovirt.org >
> > > > 
> > > 
> > 
> 
> > > > > > > > Sent: Wednesday, May 4, 2016 9:34:53 AM
> > > > 
> > > 
> > 
> 
> > > > > > > > Subject: [ovirt-devel] Master ovirt-engine build broken
> > > > 
> > > 
> > 
> 
> > > > > > > >
> > > > 
> > > 
> > 
> 
> > > > 

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

[Marek Libra]

The fix is here: https://gerrit.ovirt.org/#/c/57007/ 

- Original Message -

> From: "Roman Mohr" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> Sent: Wednesday, May 4, 2016 10:27:51 AM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken

> On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com > wrote:

> > Roman - did you build the langs in order to find the issue?
> 

> I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not all
> of my builds showed that error.

> Looking at

> https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration

> two patches passed and two failed after a topic rebase.

> > Eyal - can we monitor a list of files that i changed will result in also
> > building all the languages?
> 

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

> > > right, and we can't enable lang permutation since it takes a very long
> > > time
> > > to run.
> > 
> 

> > > On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek < tjeli...@redhat.com >
> > > wrote:
> > 
> 

> > > > - Original Message -
> > > 
> > 
> 
> > > > > From: "Oved Ourfali" < oourf...@redhat.com >
> > > 
> > 
> 
> > > > > To: "Tomas Jelinek" < tjeli...@redhat.com >
> > > 
> > 
> 
> > > > > Cc: "Roman Mohr" < rm...@redhat.com >, "devel" < devel@ovirt.org >,
> > > > > "Scott
> > > > > Dickerson" < sdick...@redhat.com >
> > > 
> > 
> 
> > > > > Sent: Wednesday, May 4, 2016 9:55:40 AM
> > > 
> > 
> 
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > I wonder, how come the CI didn't catch that?
> > > 
> > 
> 

> > > > because this happens only when you compile with language permutations
> > > 
> > 
> 

> > > > >
> > > 
> > 
> 
> > > > > On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek < tjeli...@redhat.com
> > > > > >
> > > > > wrote:
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > > hmmm,
> > > 
> > 
> 
> > > > > > regression introduced yesterday by
> > > > > > https://gerrit.ovirt.org/#/c/56720/
> > > 
> > 
> 
> > > > > > fix on the way
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > > - Original Message -
> > > 
> > 
> 
> > > > > > > From: "Roman Mohr" < rm...@redhat.com >
> > > 
> > 
> 
> > > > > > > To: "devel" < devel@ovirt.org >
> > > 
> > 
> 
> > > > > > > Sent: Wednesday, May 4, 2016 9:34:53 AM
> > > 
> > 
> 
> > > > > > > Subject: [ovirt-devel] Master ovirt-engine build broken
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > Hi,
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > I see failing tests regarding to missing translations (e.g. [1]).
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > [...]
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > Failed tests:
> > > > > > > doTest(org.ovirt.engine.ui.uicompat.UIMessagesTest):
> > > 
> > 
> 
> > > > > > > cpuInfoLabel does not match the number of parameters in
> > > 
> > 
> 
> > > > > > > UIMessages_zh_CN.properties(..)
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > [...]
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > Best Regards,
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > Roman
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > [1]
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc23-x86_64/407/console
> > > 
> > 
> 
> > > > > > >
> > > 
> > 
> 
> > > > > > > ___
> > > 
> > 
> 
> > > > > > > Devel mailing list
> > > 
> > 
> 
> > > > > > > Devel@ovirt.org
> > > 
> > 
> 
> > > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > 
> 
> > > > > > ___
> > > 
> > 
> 
> > > > > > Devel mailing list
> > > 
> > 
> 
> > > > > > Devel@ovirt.org
> > > 
> > 
> 
> > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > > >
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > ___
> > > 
> > 
> 
> > > > Devel mailing list
> > > 
> > 
> 
> > > > Devel@ovirt.org
> > > 
> > 
> 
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > 
> 

> > > --
> > 
> 
> > > Eyal Edri
> > 
> 
> > > Associate Manager
> > 
> 
> > > RHEV DevOps
> > 
> 
> > > EMEA ENG Virtualization R
> > 
> 
> > > Red Hat Israel
> > 
> 

> > > phone: +972-9-7692018
> > 
> 
> > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > 
> 

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

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

Re: [ovirt-devel] Cockpit-oVirt plugin

[Marek Libra]

Recent cockpit-ovirt plugin RPM is available in the 
ovirt-master-snapshot-static yum repository.

Please refer 
https://github.com/mareklibra/cockpit-ovirt/blob/master/README.md#install-from-rpm
for install instructions.

Enjoy :-)
Marek

- Original Message -
> From: "Marek Libra" <mli...@redhat.com>
> To: "Fabian Deutsch" <fdeut...@redhat.com>
> Cc: "devel" <devel@ovirt.org>
> Sent: Wednesday, February 24, 2016 12:19:30 PM
> Subject: Re: [ovirt-devel] Cockpit-oVirt plugin
> 
> The rpm is not yet ready. As soon as some WIP is done, I'll focus on that.
> 
> - Original Message -
> > From: "Fabian Deutsch" <fdeut...@redhat.com>
> > To: "Marek Libra" <mli...@redhat.com>
> > Cc: "devel" <devel@ovirt.org>
> > Sent: Tuesday, February 23, 2016 4:46:51 PM
> > Subject: Re: [ovirt-devel] Cockpit-oVirt plugin
> > 
> > On Tue, Feb 23, 2016 at 1:23 PM, Marek Libra <mli...@redhat.com> wrote:
> > > I'm pleased to announce initial version of new oVirt plugin for Cockpit,
> > > which is recently a proposed feature for oVirt 4.0.
> > >
> > > The oVirt Wiki Feature can be found at [3].
> > >
> > > Sources and README file can be found on the github [1].
> > > Up-to-date issue list is at [2] (includes planed enhancements)
> > >
> > > Please refer the README file for install instructions, so far tested on
> > > Centos 7 (minimal).
> > >
> > > The plugin will be distributed as an rpm in the future and is meant as an
> > > optional add-on to oVirt.
> > >
> > > Main focus is on
> > > - troubleshooting when accessibility/functionality of webadmin is limited
> > > - easy-to-use tool for VM-centric host monitoring/administration
> > > - potential integration point with oVirt on UI level
> > > - easy to use, so for small setups the preferred choice with an option to
> > > "upgrade" to full oVirt later
> > >
> > > The plugin or its parts can be used as standalone same as embedded into
> > > other UIs, like drill-down from webadmin or ManageIQ for more details or
> > > fine-tuning.
> > >
> > > The plugin has dependency on VDSM.
> > > Please note, since there was a VDSM patch needed, recent master is
> > > required
> > > (see README in the source).
> > >
> > > Dependency on oVirt's engine is optional - when accessible then
> > > additional
> > > plugin functionality is available.
> > > Please note, the plugin is in early development phase showing basic
> > > concept.
> > 
> > Hey Marek,
> > 
> > this work looks pretty promising!
> > 
> > Do you already have rpm build which we could include in our nightly
> > oVirt Node Next builds?
> > 
> > Greetnigs
> > fabian
> > 
> ___
> 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] Cockpit-oVirt plugin

[Marek Libra]

The rpm is not yet ready. As soon as some WIP is done, I'll focus on that.

- Original Message -
> From: "Fabian Deutsch" <fdeut...@redhat.com>
> To: "Marek Libra" <mli...@redhat.com>
> Cc: "devel" <devel@ovirt.org>
> Sent: Tuesday, February 23, 2016 4:46:51 PM
> Subject: Re: [ovirt-devel] Cockpit-oVirt plugin
> 
> On Tue, Feb 23, 2016 at 1:23 PM, Marek Libra <mli...@redhat.com> wrote:
> > I'm pleased to announce initial version of new oVirt plugin for Cockpit,
> > which is recently a proposed feature for oVirt 4.0.
> >
> > The oVirt Wiki Feature can be found at [3].
> >
> > Sources and README file can be found on the github [1].
> > Up-to-date issue list is at [2] (includes planed enhancements)
> >
> > Please refer the README file for install instructions, so far tested on
> > Centos 7 (minimal).
> >
> > The plugin will be distributed as an rpm in the future and is meant as an
> > optional add-on to oVirt.
> >
> > Main focus is on
> > - troubleshooting when accessibility/functionality of webadmin is limited
> > - easy-to-use tool for VM-centric host monitoring/administration
> > - potential integration point with oVirt on UI level
> > - easy to use, so for small setups the preferred choice with an option to
> > "upgrade" to full oVirt later
> >
> > The plugin or its parts can be used as standalone same as embedded into
> > other UIs, like drill-down from webadmin or ManageIQ for more details or
> > fine-tuning.
> >
> > The plugin has dependency on VDSM.
> > Please note, since there was a VDSM patch needed, recent master is required
> > (see README in the source).
> >
> > Dependency on oVirt's engine is optional - when accessible then additional
> > plugin functionality is available.
> > Please note, the plugin is in early development phase showing basic
> > concept.
> 
> Hey Marek,
> 
> this work looks pretty promising!
> 
> Do you already have rpm build which we could include in our nightly
> oVirt Node Next builds?
> 
> Greetnigs
> fabian
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Cockpit-oVirt plugin

[Marek Libra]

I'm pleased to announce initial version of new oVirt plugin for Cockpit, which 
is recently a proposed feature for oVirt 4.0.

The oVirt Wiki Feature can be found at [3].

Sources and README file can be found on the github [1].
Up-to-date issue list is at [2] (includes planed enhancements)

Please refer the README file for install instructions, so far tested on Centos 
7 (minimal).

The plugin will be distributed as an rpm in the future and is meant as an 
optional add-on to oVirt.

Main focus is on
- troubleshooting when accessibility/functionality of webadmin is limited
- easy-to-use tool for VM-centric host monitoring/administration
- potential integration point with oVirt on UI level
- easy to use, so for small setups the preferred choice with an option to 
"upgrade" to full oVirt later

The plugin or its parts can be used as standalone same as embedded into other 
UIs, like drill-down from webadmin or ManageIQ for more details or fine-tuning.

The plugin has dependency on VDSM.
Please note, since there was a VDSM patch needed, recent master is required 
(see README in the source).

Dependency on oVirt's engine is optional - when accessible then additional 
plugin functionality is available.
Please note, the plugin is in early development phase showing basic concept.

Marek


Links:
[1] Sources: https://github.com/mareklibra/cockpit-ovirt/
[2] Issue tracker: https://github.com/mareklibra/cockpit-ovirt/issues
[3] Wiki Proposed Feature page is in review, recent unmerged version:   
  
 
https://github.com/mareklibra/ovirt-site/blob/cockpit-ovirt-plugin/source/develop/release-management/features/cockpit.html.md
 Once merged, screenshots will be available.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Coming (Very) Soon - New ovirt.org Website & Deprecated Wiki

[Marek Libra]

Is old MediaWiki still running somewhere?

Thanks,
Marek

- Original Message -
> From: "Mikey Ariel" 
> To: us...@ovirt.org, devel@ovirt.org, in...@ovirt.org
> Sent: Thursday, February 18, 2016 12:42:56 PM
> Subject: [ovirt-devel] Coming (Very) Soon - New ovirt.org Website &   
> Deprecated Wiki
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> In the past months we've been working on upgrading the oVirt project
> infrastructure, to better support the community contributions.
> 
> One of the main platforms for our user documentation, release
> management content, and community content has been the MediaWiki site
> that you all know as ovirt.org. Most of us are familiar with the wiki
> site format, with all its advantages and disadvantages.
> 
> After several years of serving the community, I'm happy to announce
> that we are very near to completing a full upgrade of the website
> infrastructure from a wiki site to a static site, source-controlled on
> GitHub and authored in Markdown.
> 
> This email is the pre-launch announcement, as we are reaching the
> final stages of the migration, and there are a few actions that might
> affect your work on website content in the meantime.
> 
> Why migrate the website
> ===
> 
> As mentioned, wiki sites provide an open and flexible content editing
> platform. Unfortunately, as the site grows the content becomes quite
> difficult to manage and curate, resulting in lots of obsolete,
> outdated, and incorrect information.
> 
> By moving to a source-controlled repository and implementing GitHub's
> contribution workflow, we strive to ease the work of maintaining an
> up-to-date content site, employ a peer-review process for changes, and
> standardize the authoring markup language to lower the contribution
> barrier.
> 
> The Middleman framework (Ruby-based static site generator) was chosen
> based on observing successful implementation of other open-source
> community websites, such as OpenStack RDO, Project Atomic, and Gluster.
> 
> What we did so far
> ==
> 
> When we started the migration, our Web design team exported all of the
> wiki content from the old website and converted it to MD files. They
> also set up the website config flow, auto-deploy, and upgraded the
> look-and-feel of the website.
> 
> We then initiated a content review effort as well as a UX review for
> the new website in a smaller forum, which caught most of the critical
> issues with the new website and helped us get the new format to a
> place where we can release the website in a near-GA/public-beta format.
> 
> Yesterday (Wednesday Feb 17) we exported the website one more time and
> currently we're running a diff on all the files that changed since the
> initial export was done, to make sure we grab all the updates and the
> latest content before we launch the new website.
> 
> What is about to happen
> ===
> 
> Today we are initiating a **wiki freeze**, which means the old
> MediaWiki site will become read-only. This is to ensure that all of
> our diff scripts reflect the most current state of the content on the
> website, and that we don't lose any content in the transition.
> 
> Barring any unexpected blockers, we will port the ovirt.org domain to
> point to the new website and open the new website for contributions on
> **Monday February 22** or earlier.
> 
> What do you need to do right now
> 
> 
> If you have any wiki pages that you're actively editing, please don't
> save them to the old MediaWiki site, and hold onto your pending
> changes until we send the happy launch email.
> 
> We will also include instructions on how to contribute/edit/add
> content to the new website, but in general the workflow will be
> aligned with the standard GitHub best practices
> (clone-edit-commit-pullrequest), so you can utilize all of the git
> commands that you already know or work directly within the GitHub web
> editor.
> 
> 
> I'd like to thank all of the people who were involved with this
> migration so far, ovirt.org is a big website with lots of content and
> it was no small task to upgrade it.
> 
> Please feel free to ping me on- or off-list if you have any questions
> about the next steps, and expect a happy launch email soon!
> 
> Cheers,
> Mikey
> 
> 
> - --
> Mikey Ariel
> Community Lead, oVirt
> www.ovirt.org
> 
> "To be is to do" (Socrates)
> "To do is to be" (Jean-Paul Sartre)
> "Do be do be do" (Frank Sinatra)
> 
> Mobile: +420-702-131-141
> IRC: mariel / thatdocslady
> Twitter: @ThatDocsLady
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJWxa5AAAoJEHYPPTOszxHow10H/jeuhzMrUrPsCBedLg7OKnNh
> jdKDujT/aCyA4LgnRHnVBEASunShmVaOJrMdU4r0PZbdkX1Mf5/SvCEFGKY14qAg
> m/5CnDhlwbp5rqo09VOGLMg20CaMtpUoE1LpKE/epGYEKSBr2JIAA+HAsYa1OEyS
> 9oHDDx+ZIbfHNlygW1KpW6dsuZRscTbfy4kk8rY83YdJGyQiQN+ulsjT/c2N8ArR
> 

Re: [ovirt-devel] missing "jinja2"??

[Marek Libra]

Hi,

try
dnf install python-jinja2

M.
- Original Message -
> From: "Martin Mucha" 
> To: "devel" 
> Sent: Thursday, February 4, 2016 8:14:22 AM
> Subject: [ovirt-devel] missing "jinja2"??
> 
> Hi,
> 
> if I try to run engine now, I'm getting following, even if jinja2 is
> (manually) installed. How to fix that?
> 
> File
> "/home/mmucha/build/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py",
> line 26, in 
> from jinja2 import Template
> ImportError: cannot import name Template
> 
> 
> thanks,
> M.
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Ovirt upgrade job failing

[Marek Libra]

Hi,

seems like backport of https://gerrit.ovirt.org/#/c/48255/
is adding 03_06_1930_change_cpu_name_ibm_power_8.sql which causes 
the master's 03_06_1930_convert_hibernation_volumes_to_disks.sql not to run 
when upgrading.

The 03_06_1930_convert_hibernation_volumes_to_disks.sql introduces the 
snapshots.memory_metadata_disk_id .

Marek 

- Original Message -
> From: "David Caro" 
> To: devel@ovirt.org
> Sent: Friday, 27 November, 2015 11:08:37 AM
> Subject: [ovirt-devel] Ovirt upgrade job failing
> 
> 
> Hi!
> 
> Since yesterday morning the upgrade job from 3.6 to master [1] has been
> failing
> on applying the schema.sh, specifically:
> 
> 
> 2015-11-26 08:12:54 DEBUG
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:941
> execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s',
> 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20151126081101-884dt8.log',
> '-c', 'apply'] stderr:
> psql:/usr/share/ovirt-engine/dbscripts/create_views.sql:108: ERROR:  column
> snapshots.memory_metadata_disk_id does not exist
> LINE 59: snapshots.memory_metadata_disk_id,
>  ^
> FATAL: Cannot execute sql command:
> --file=/usr/share/ovirt-engine/dbscripts/create_views.sql
> 
> 
> 
> I see that the line was introduced by [2], though it did not fail back then
> (so
> the issue might not be there), it might also come from 3.6 branch, but I need
> a
> bit of help tracking that down from any of the db guys
> 
> This is making all the builds of that job fail, and it might be masking other
> errors (and giving -1 to a lot of patches).
> 
> 
> Thanks!
> 
> 
> [1]
> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-3.6_el7_merged/986/
> [2] https://gerrit.ovirt.org/#/c/47262/
> 
> --
> David Caro
> 
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R
> 
> Tel.: +420 532 294 605
> Email: dc...@redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Push notifications in 4.0 backend

[Marek Libra]

- Original Message -
> From: "Martin Perina" <mper...@redhat.com>
> To: "Eli Mesika" <emes...@redhat.com>
> Cc: "Piotr Kliczewski" <pklic...@redhat.com>, "engine-de...@ovirt.org" 
> <devel@ovirt.org>, "Michal Skrivanek"
> <mskri...@redhat.com>
> Sent: Wednesday, 25 November, 2015 11:20:49 AM
> Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> 
> 
> 
> - Original Message -
> > From: "Eli Mesika" <emes...@redhat.com>
> > To: "Vojtech Szocs" <vsz...@redhat.com>
> > Cc: "Piotr Kliczewski" <pklic...@redhat.com>, "Michal Skrivanek"
> > <mskri...@redhat.com>, "engine-de...@ovirt.org"
> > <devel@ovirt.org>
> > Sent: Wednesday, November 25, 2015 10:42:35 AM
> > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > 
> > 
> > 
> > - Original Message -
> > > From: "Vojtech Szocs" <vsz...@redhat.com>
> > > To: "Martin Betak" <mbe...@redhat.com>
> > > Cc: "engine-de...@ovirt.org" <devel@ovirt.org>, "Piotr Kliczewski"
> > > <pklic...@redhat.com>, "Michal Skrivanek"
> > > <mskri...@redhat.com>
> > > Sent: Monday, November 23, 2015 6:22:45 PM
> > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Martin Betak" <mbe...@redhat.com>
> > > > To: "Vojtech Szocs" <vsz...@redhat.com>
> > > > Cc: "Einav Cohen" <eco...@redhat.com>, "engine-de...@ovirt.org"
> > > > <devel@ovirt.org>, "Roy Golan" <rgo...@redhat.com>,
> > > > "Roman Mohr" <rm...@redhat.com>, "Michal Skrivanek"
> > > > <mskri...@redhat.com>,
> > > > "Piotr Kliczewski" <pklic...@redhat.com>,
> > > > "Tomas Jelinek" <tjeli...@redhat.com>, "Alexander Wels"
> > > > <aw...@redhat.com>,
> > > > "Greg Sheremeta" <gsher...@redhat.com>,
> > > > "Scott Dickerson" <sdick...@redhat.com>, "Arik Hadas"
> > > > <aha...@redhat.com>,
> > > > "Allon Mureinik" <amure...@redhat.com>,
> > > > "Shmuel Melamud" <smela...@redhat.com>, "Jakub Niedermertl"
> > > > <jnied...@redhat.com>, "Marek Libra"
> > > > <mli...@redhat.com>, "Martin Perina" <mper...@redhat.com>, "Alona
> > > > Kaplan"
> > > > <alkap...@redhat.com>, "Martin Mucha"
> > > > <mmu...@redhat.com>
> > > > Sent: Thursday, November 19, 2015 1:53:07 PM
> > > > Subject: Re: Push notifications in 4.0 backend
> > > > 
> > > > Hi All,
> > > > 
> > > > I have created a PoC patch [1] demonstrating the idea of annotating
> > > > basic CRUD commands to publish CDI events. It is not meant as 100%
> > > > solution, but as a simplification of the common use cases when
> > > > one would inject CDI event with given qualifier and fire it after
> > > > successful completion of transaction.
> > > 
> > > The patches (mentioned below) look interesting.
> > > 
> > > At this point, it would be great if backend core maintainers
> > > voiced their opinions on the general idea of firing CDI events
> > > in response to important actions happening on Engine, such as
> > > backend commands being executed. So, what do you think guys?
> > 
> > +1
> > 
> > I am for it, I think it may reduce load from our DB
> 
> +1
> 
The load reduction can be achieved and seems like not a big deal to implement 
it.
+1

> > 
> > > 
> > > > 
> > > > The usage of this annotations is demonstrated on several basic CRUD
> > > > commands in [2] on StoragePool, VDS, VDSGroup, .etc
> > > > 
> > > > As always, comments and suggestions are very welcome!
> > > > 
> > > > Thank you and best regards,
> > > > 
> > > > Martin
> > > > 
> > > > [1] infra: https://gerrit.ovirt.org/#/c/48696/
> > > > [2] usage: https://gerrit.ovirt.org/#/c/48697/
> > > > 
> > > > 
> > > > 
> > > > ---