[ovirt-devel] OUTAGE: jenkins.ovirt.org is down

2016-11-09 Thread Eyal Edri 
We're experience problems with the jenkins server, and its currently down.
We are in the process of understanding the issue and are working to bring
it back online,

We will update when the service is back online, hopefully shouldn't take
long.

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

[ovirt-devel] Moving oVirt JavaScript application stack forward (short and long term)

2016-11-09 Thread Vojtech Szocs 
Hello,

regarding oVirt JavaScript applications (like Dashboard), we'd like
to reach a point where we'll be using latest Node.js LTS runtime and
lock down all dependency versions, resulting in reproducible builds.

Please note that both Node.js and all JS dependencies are needed only
when building oVirt JavaScript applications & corresponding packages.

The near future items are following:

1, patch ovirt-engine-{nodejs,nodejs-modules} to use Node.js v6 (LTS),
   refer to https://github.com/nodejs/LTS for more details

2, patch ovirt-engine-nodejs-modules to use Node.js runtime provided
   by ovirt-engine-nodejs - revive https://gerrit.ovirt.org/#/c/59898/

3, lock down dependency versions in ovirt-engine-nodejs-modules
   via npm-shrinkwrap - finalize https://gerrit.ovirt.org/#/c/61957/

>From this point, we can proceed with long term items:

4, consolidate dependencies across projects:

   4a, update react-patternfly:
   - https://github.com/jtomasek/react-patternfly/
   - add common PatternFly components (e.g. out of Dashboard)

   4b, update ovirt-ui-components:
   - https://github.com/matobet/ovirt-ui-components/
   - depend on react-patternfly
   - add oVirt specific components (e.g. out of Dashboard)

   4c, update ovirt-engine-nodejs-modules:
   - depend on ovirt-ui-components

   4d, update all oVirt JS projects, like Dashboard
   - depend on ovirt-ui-components

   *all* oVirt JS projects should depend on ovirt-ui-components.

   react-patternfly exists separately to support non-oVirt cases.

5, develop "showcase" webapp as part of react-patternfly repo to
   ensure it's well-aligned with PatternFly look'n'feel

   - it would be nice to host the "showcase" webapp somewhere

6, address common problems that arise from using npm-shrinkwrap

   - deterministic (predictable) dependency resolution
   - checksum verification to ensure integrity of dependencies
   - dependency de-duplication (avoid multiple versions)

   Yarn [1][2] addresses all problems mentioned above. It's still
   in early development, so I'd wait a bit and see how it matures.

   Note: ManageIQ UI is already using Yarn [3].

   [1] https://code.facebook.com/posts/1840075619545360
   [2] https://github.com/yarnpkg/yarn
   [3] https://github.com/ManageIQ/manageiq-ui-service/pull/296/files

Feel free to share your thoughts or concerns.

Regards,
Vojtech
___
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

2016-11-09 Thread Juan Hernández 
On 11/09/2016 11:12 AM, Yaniv Kaul wrote:
> 
> 
> On Sat, Oct 15, 2016 at 1:04 AM, Ravi Nori  > wrote:
> 
> Also can you please try following command to directly obtain token
> from SSO. Can replace engine with FQDN and IP to see if both work
> 
> curl -v -k -H "Accept: application/json"
> 
> 'https://:443/ovirt-engine/sso/oauth/token?grant_type=password=admin@internal=123=ovirt-app-api'
> 
> You should see output similar to the one below
> 
> 
> {"access_token":"K0sBa0D3rLtmNTdMJ-Q4FzOgCtGGY2cSFSCwbLkG94te9nDdmEzHSizsFaOeNMdwOziIv3l2-Uqm8bxWkMpwMA","scope":"ovirt-app-api
> ovirt-ext=token-info:authz-search
> ovirt-ext=token-info:public-authz-search
> ovirt-ext=token-info:validate","exp":-381399824,"token_type":"bearer"}
> 
> 
> Sorry it took me so long to get back to it, but here it is:
> {"access_token":"eA8w0DaapkKAQ8tfHakzA-R0l-mjD_CsTlAqBaH4iVVjXxQN33poXzt9UhPJLxMU8YOvVNX6LICcxL1EeAiAlw","scope":"ovirt-app-api
> ovirt-ext=token-info:authz-search
> ovirt-ext=token-info:public-authz-search
> ovirt-ext=token-info:validate","exp":["java.lang.Long",1479290132000],"token_type":"bearer"}
> 

That "java.lang.Long" there is an error, but not related to this
problem, as the SDK doesn't use the "exp" attribute. I guess it is a
side effect of the recent change to use "long" instead of "int", looks
like the JSON library used in the engine doesn't like longs.

> And here's the difference between the SDK and the manual curl command in
> ssl_access log:
> 192.168.201.1 - - [09/Nov/2016:04:52:19 -0500] "POST
> /ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
> 192.168.201.1 - - [09/Nov/2016:04:55:32 -0500] "GET
> /ovirt-engine/sso/oauth/token?grant_type=password=admin@internal=123=ovirt-app-api
> HTTP/1.1" 200 295
> 

That difference is by design. The SDK uses POST to avoid sending the
credentials (specially the password) as a query parameter, as that is
most probably logged and archived.

We discovered recently an issue with the Python SDK, due to a bug in the
"pycurl" library:

  Debug mode raises UnicodeDecodeError: 'utf8' codec can't decode byte
0x8d in position 7: invalid start byte
  https://bugzilla.redhat.com/1392878

It isn't exactly the same problem, but as the cause of that bug is a
pointer that is used after releasing, it can cause all kinds of strange
effects.

Please try the latest build of the SDK.

> 
> 
> Thanks
> 
> Ravi
> 
> On Fri, Oct 14, 2016 at 4:00 PM, Yaniv Kaul  > wrote:
> 
> On Oct 14, 2016 7:13 PM, "Ravi Nori"  > wrote:
> >
> > SSO configuration looks good. 
> >
> > Can you please share any additional httpd configuration in 
> /etc/httpd/conf.d. Anything to do with LocationMatch for ovirt-engine urls.
> 
> This is a standard ovirt-system-tests on Lago installation,
> nothing out of the ordinary,  but I'll check.
> Y.
> 
> >
> > On Fri, Oct 14, 2016 at 12:52 PM, Yaniv Kaul  > wrote:
> >>
> >>
> >>
> >> On Fri, Oct 14, 2016 at 3:50 PM, Ravi Nori  > wrote:
> >>>
> >>> Hi Yaniv,
> >>>
> >>> Can you check the output of
> https::///ovirt-engine/sso/status in your browser and
> see if the SSO service is active.
> >>>
> >>> If SSO is deployed, you should see an output similar to the
> one below. Also are you able to login to webadmin using the
> browser?
> >>
> >>
> >> I am able to login using the webui.
> >>  
> >>>
> >>>
> >>> {"status_description":"SSO Webapp
> Deployed","version":"0","status":"active"}
> >>
> >>
> >> Indeed:
> >> {"status_description":"SSO Webapp
> Deployed","version":"0","status":"active"}
> >>
> >> (not sure what 'version 0' means?)
> >>  
> >>>
> >>>
> >>> Please share the content of
> /etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
> >>
> >>
> >> [root@lago-basic-suite-master-engine ~]# cat
> /etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
> >> ENGINE_SSO_CLIENT_ID="ovirt-engine-core"
> >> ENGINE_SSO_CLIENT_SECRET="bsOabtD7gE2McwLe80P109UV800XLx4O"
> >> ENGINE_SSO_AUTH_URL="https://${ENGINE_FQDN}:443/ovirt-engine/sso;
> >>
> ENGINE_SSO_SERVICE_URL="https://localhost:443/ovirt-engine/sso
> "
> >> ENGINE_SSO_SERVICE_SSL_VERIFY_HOST=false
> >> ENGINE_SSO_SERVICE_SSL_VERIFY_CHAIN=true
> >> SSO_ALTERNATE_ENGINE_FQDNS=""
> >> SSO_ENGINE_URL="https://${ENGINE_FQDN}:443/ovirt-engine/;
>

Re: [ovirt-devel] [vdsm] Requiring virt-preview again on Fedora 24

2016-11-09 Thread Sandro Bonazzola 
On Wed, Nov 9, 2016 at 1:54 PM, Francesco Romani  wrote:

> Hi all,
>
> For the upcoming ovirt 4.1 release we are going to use features available
> only
> in recent libvirt (>= 2.0.0). Those features are available on CentOS/RHEL,
> but fedora 24 was left again.
>
> For this reason we are going to require the virt-preview repo again [1]
> This patch enables it on our CI: https://gerrit.ovirt.org/#/c/66308/1
>
> Comments welcome
>
> Please open a RFE for it on ovirt-release.
I guess that ovirt-system-test and repoclosure jenkins jobs will need it as
well.
It will probably be needed also by any other job building something having
vdsm as build requirement.




> +++
>
> [1] https://fedoraproject.org/wiki/Virtualization_Preview_Repository
>
> --
> 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
>



-- 
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] [vdsm] Requiring virt-preview again on Fedora 24

2016-11-09 Thread Francesco Romani 
Hi all,

For the upcoming ovirt 4.1 release we are going to use features available only
in recent libvirt (>= 2.0.0). Those features are available on CentOS/RHEL,
but fedora 24 was left again.

For this reason we are going to require the virt-preview repo again [1]
This patch enables it on our CI: https://gerrit.ovirt.org/#/c/66308/1

Comments welcome

+++

[1] https://fedoraproject.org/wiki/Virtualization_Preview_Repository

-- 
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] Can't add DC with API v4 - client issue

2016-11-09 Thread Yaniv Kaul 
On Sat, Oct 15, 2016 at 1:04 AM, Ravi Nori  wrote:

> Also can you please try following command to directly obtain token from
> SSO. Can replace engine with FQDN and IP to see if both work
>
> curl -v -k -H "Accept: application/json" 'https://:443/ovirt-
> engine/sso/oauth/token?grant_type=password=admin@
> internal=123=ovirt-app-api'
>
> You should see output similar to the one below
>
> {"access_token":"K0sBa0D3rLtmNTdMJ-Q4FzOgCtGGY2cSFSCwbLkG94te9nDd
> mEzHSizsFaOeNMdwOziIv3l2-Uqm8bxWkMpwMA","scope":"ovirt-app-api
> ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
> ovirt-ext=token-info:validate","exp":-381399824,"token_type":"bearer"}
>

Sorry it took me so long to get back to it, but here it is:
{"access_token":"eA8w0DaapkKAQ8tfHakzA-R0l-mjD_CsTlAqBaH4iVVjXxQN33poXzt9UhPJLxMU8YOvVNX6LICcxL1EeAiAlw","scope":"ovirt-app-api
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
ovirt-ext=token-info:validate","exp":["java.lang.Long",1479290132000],"token_type":"bearer"}

And here's the difference between the SDK and the manual curl command in
ssl_access log:
192.168.201.1 - - [09/Nov/2016:04:52:19 -0500] "POST
/ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
192.168.201.1 - - [09/Nov/2016:04:55:32 -0500] "GET
/ovirt-engine/sso/oauth/token?grant_type=password=admin@internal=123=ovirt-app-api
HTTP/1.1" 200 295



> Thanks
>
> Ravi
>
> On Fri, Oct 14, 2016 at 4:00 PM, Yaniv Kaul  wrote:
>
>> On Oct 14, 2016 7:13 PM, "Ravi Nori"  wrote:
>> >
>> > SSO configuration looks good.
>> >
>> > Can you please share any additional httpd configuration in
>> /etc/httpd/conf.d. Anything to do with LocationMatch for ovirt-engine urls.
>>
>> This is a standard ovirt-system-tests on Lago installation, nothing out
>> of the ordinary,  but I'll check.
>> Y.
>>
>> >
>> > On Fri, Oct 14, 2016 at 12:52 PM, Yaniv Kaul  wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Oct 14, 2016 at 3:50 PM, Ravi Nori  wrote:
>> >>>
>> >>> Hi Yaniv,
>> >>>
>> >>> Can you check the output of https::///ovirt-engine/sso/status
>> in your browser and see if the SSO service is active.
>> >>>
>> >>> If SSO is deployed, you should see an output similar to the one
>> below. Also are you able to login to webadmin using the browser?
>> >>
>> >>
>> >> I am able to login using the webui.
>> >>
>> >>>
>> >>>
>> >>> {"status_description":"SSO Webapp Deployed","version":"0","statu
>> s":"active"}
>> >>
>> >>
>> >> Indeed:
>> >> {"status_description":"SSO Webapp Deployed","version":"0","statu
>> s":"active"}
>> >>
>> >> (not sure what 'version 0' means?)
>> >>
>> >>>
>> >>>
>> >>> Please share the content of /etc/ovirt-engine/engine.conf.
>> d/11-setup-sso.conf
>> >>
>> >>
>> >> [root@lago-basic-suite-master-engine ~]# cat
>> /etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
>> >> ENGINE_SSO_CLIENT_ID="ovirt-engine-core"
>> >> ENGINE_SSO_CLIENT_SECRET="bsOabtD7gE2McwLe80P109UV800XLx4O"
>> >> ENGINE_SSO_AUTH_URL="https://${ENGINE_FQDN}:443/ovirt-engine/sso;
>> >> ENGINE_SSO_SERVICE_URL="https://localhost:443/ovirt-engine/sso;
>> >> ENGINE_SSO_SERVICE_SSL_VERIFY_HOST=false
>> >> ENGINE_SSO_SERVICE_SSL_VERIFY_CHAIN=true
>> >> SSO_ALTERNATE_ENGINE_FQDNS=""
>> >> SSO_ENGINE_URL="https://${ENGINE_FQDN}:443/ovirt-engine/;
>> >>
>> >>
>> >> Thanks,
>> >> Y.
>> >>
>> >>
>> >>>
>> >>>
>> >>> Thanks
>> >>>
>> >>> Ravi
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Oct 14, 2016 at 7:57 AM, Juan Hernández 
>> wrote:
>> 
>>  On 10/14/2016 01:45 PM, Yaniv Kaul wrote:
>>  >
>>  >
>>  > On Thu, Oct 13, 2016 at 11:13 AM, Juan Hernández <
>> jhern...@redhat.com
>>  > > wrote:
>>  >
>>  > On 10/13/2016 12:04 AM, Yaniv Kaul wrote:
>>  > > On Fri, Oct 7, 2016 at 10:44 PM, Yaniv Kaul <
>> yk...@redhat.com 
>>  > > >> 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-scen
>> arios/002_bootstrap.py",
>>  > > line 98, in add_dc4
>>  > > version=sdk4.types.Version(ma
>> jor=DC_VER_MAJ,minor=DC_VER_MIN),
>>  > >   File "/usr/lib64/python2.7/site-pac
>> kages/ovirtsdk4/services.py",
>>  > > line 4347, in add
>>  > > response = self._connection.send(request)
>>  > >   File "/usr/lib64/python2.7/site-pac
>> kages/ovirtsdk4/__init__.py",
>>  > > line 276, in send
>>  > > return self.__send(request)
>>  > >   File "/usr/lib64/python2.7/site-pac
>>

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc

2016-11-09 Thread Yaniv Kaul 
On Tue, Nov 8, 2016 at 7:12 PM, Michal Skrivanek 
wrote:

>
>
> > On 08 Nov 2016, at 17:52, Martin Sivak  wrote:
> >
> > Hi,
> >
> > mom-vdsm.service contains:
> >
> > Requires=vdsmd.service
> > After=vdsmd.service
> >
> > So when Shira restarted vdsm, mom was also restarted.
>

What is the reason to restart mom when VDSM is restarted?
Y.



> >
> > [journalctl --unit vdsmd]
> > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Stopping Virtual Desktop
> > Server Manager...
> > Nov 08 18:25:27 RHEL7.2Server vdsmd_init_common.sh[3053]: vdsm:
> > Running run_final_hooks
> > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Starting Virtual Desktop
> > Server Manager...
> >
> > [journalctl --unit mom-vdsm]
> > Nov 08 18:17:23 RHEL7.2Server systemd[1]: Starting MOM instance
> > configured for VDSM purposes...
> > Nov 08 18:25:16 RHEL7.2Server systemd[1]: Stopping MOM instance
> > configured for VDSM purposes...
> > Nov 08 18:25:29 RHEL7.2Server systemd[1]: Started MOM instance
> > configured for VDSM purposes.
> >
> >
> > But mom then immediately failed with:
> >
> > 2016-11-08 18:25:08,008 - mom.RPCServer - INFO - ping()
> > 2016-11-08 18:25:08,010 - mom.RPCServer - INFO - getStatistics()
> > 2016-11-08 18:25:17,028 - mom.RPCServer - INFO - RPC Server ending
> > 2016-11-08 18:25:24,705 - mom.GuestManager - INFO - Guest Manager ending
> > 2016-11-08 18:25:26,575 - mom.HostMonitor - INFO - Host Monitor ending
> >
> > 2016-11-08 18:25:29,869 - mom - INFO - MOM starting
> > 2016-11-08 18:25:29,905 - mom.HostMonitor - INFO - Host Monitor starting
> > 2016-11-08 18:25:29,905 - mom - INFO - hypervisor interface
> vdsmjsonrpcbulk
> > 2016-11-08 18:25:30,029 - mom.vdsmInterface - ERROR - Cannot connect
> > to VDSM! [Errno 111] Connection refused
> > 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads
> > Traceback (most recent call last):
> >  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in
> run
> >hypervisor_iface = self.get_hypervisor_interface()
> >  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217,
> > in get_hypervisor_interface
> >return module.instance(self.config)
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/
> vdsmjsonrpcbulkInterface.py",
> > line 47, in instance
> >return JsonRpcVdsmBulkInterface()
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/
> vdsmjsonrpcbulkInterface.py",
> > line 29, in __init__
> >super(JsonRpcVdsmBulkInterface, self).__init__()
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/
> vdsmjsonrpcInterface.py",
> > line 43, in __init__
> >.orRaise(RuntimeError, 'No connection to VDSM.')
> >  File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in
> orRaise
> >raise exception(*args, **kwargs)
> > RuntimeError: No connection to VDSM.
> >
> >
> > The question here is, how much time does VDSM need to allow jsonrpc to
> > connect and request a ping and list of VMs?
>
> The only correct answer is - when it's ready and responds with success
> rather than either not respond at all(as in your case) or with "recovering
> from crash or initializing" code
>
> >
> >
> > Martin
> > ___
> > vdsm-devel mailing list -- vdsm-de...@lists.fedorahosted.org
> > To unsubscribe send an email to vdsm-devel-le...@lists.fedorahosted.org
> >
> >
> ___
> 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] Connection refused when talking to jsonrpc

2016-11-09 Thread Michal Skrivanek 

> On 9 Nov 2016, at 09:57, Francesco Romani  wrote:
> 
> 
> 
> - Original Message -
>> From: "Piotr Kliczewski" 
>> To: "Martin Sivak" 
>> Cc: "Michal Skrivanek" , "Francesco Romani" 
>> , "Shira Maximov"
>> , "devel" 
>> Sent: Wednesday, November 9, 2016 9:54:02 AM
>> Subject: Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
>> 
>> On Wed, Nov 9, 2016 at 9:48 AM, Martin Sivak  wrote:
>> 
 Isn’t the most likely cause by far a simple startup delay? We do open
>>> the listener “soon” and responds with code 99, but it’s still not instant
>>> of course
>>> 
>>> That is possible of course and we handle those "errors" just fine. But
>>> connection refused never happened with xmlrpc. It might have been
>>> luck, but it always worked there :)
>>> 
>>> 
>> There is no difference how we open listening socket (it is used by both
>> protocols) and I have seen the engine attempting to connect using both
>> protocols
>> before the socket was open. What is the time difference that you see?
> 
> Not sure I reproduced correctly, but it seems a race on startup.
> I got the same error on my box, and here it happens if mom tries to connect
> to the unix socket /var/run/vdsm/mom-vdsm.sock *before* that Vdsm creates it.
> Once vdsmd succesfully starts, a restart of mom-vdsm seems to fix all the 
> issues.
> 
> I'm not sure yet if that's all of it and how to handle with systemd 
> dependencies.
> Perhaps Nir's suggestion past in the thread to notify systemd is a good first 
> step
> in the right direction.

not sure
we would need to wait for recovery to finish if you want to be really nice to 
“dumb” clients
that would take too long though

I think mom needs a fix in addition anyway

> 
> HTH,
> 
> -- 
> 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] [vdsm] Connection refused when talking to jsonrpc

2016-11-09 Thread Piotr Kliczewski 
On Wed, Nov 9, 2016 at 9:48 AM, Martin Sivak  wrote:

> > Isn’t the most likely cause by far a simple startup delay? We do open
> the listener “soon” and responds with code 99, but it’s still not instant
> of course
>
> That is possible of course and we handle those "errors" just fine. But
> connection refused never happened with xmlrpc. It might have been
> luck, but it always worked there :)
>
>
There is no difference how we open listening socket (it is used by both
protocols) and I have seen the engine attempting to connect using both
protocols
before the socket was open. What is the time difference that you see?


>
> Martin
>
> On Wed, Nov 9, 2016 at 9:11 AM, Michal Skrivanek
>  wrote:
> >
> >> On 9 Nov 2016, at 08:55, Francesco Romani  wrote:
> >>
> >> - Original Message -
> >>> From: "Piotr Kliczewski" 
> >>> To: "Martin Perina" 
> >>> Cc: "Francesco Romani" , "Shira Maximov" <
> msh...@redhat.com>, "devel" 
> >>> Sent: Tuesday, November 8, 2016 9:31:43 PM
> >>> Subject: Re: [vdsm] Connection refused when talking to jsonrpc
> >>
> >>
> > 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM
> threads
> > Traceback (most recent call last):
> >  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29,
> in
> > run
> >hypervisor_iface = self.get_hypervisor_interface()
> >  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217,
> > in get_hypervisor_interface
> >return module.instance(self.config)
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> > dsmjsonrpcbulkInterface.py",
> > line 47, in instance
> >return JsonRpcVdsmBulkInterface()
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> > dsmjsonrpcbulkInterface.py",
> > line 29, in __init__
> >super(JsonRpcVdsmBulkInterface, self).__init__()
> >  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> > dsmjsonrpcInterface.py",
> > line 43, in __init__
> >.orRaise(RuntimeError, 'No connection to VDSM.')
> >  File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28,
> in
> > orRaise
> >raise exception(*args, **kwargs)
> > RuntimeError: No connection to VDSM.
> >
> >
> > The question here is, how much time does VDSM need to allow jsonrpc
> to
> > connect and request a ping and list of VMs?
> >
> >
> >>> It depends on recovery logic in vdsm and it can take quite some time.
> >>>
> >>> Please share vdsm logs so I could take a look?
> >>
> >> +1
> >>
> >> the most likely cause is the recovery still in progress, however I was
> expecting
> >> a different error, so worth looking at the logs.
> >
> > Isn’t the most likely cause by far a simple startup delay? We do open
> the listener “soon” and responds with code 99, but it’s still not instant
> of course
> >
> >>
> >> Bests,
> >>
> >> --
> >> 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
> >>
> >>
> >
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc

2016-11-09 Thread Martin Sivak 
> Isn’t the most likely cause by far a simple startup delay? We do open the 
> listener “soon” and responds with code 99, but it’s still not instant of 
> course

That is possible of course and we handle those "errors" just fine. But
connection refused never happened with xmlrpc. It might have been
luck, but it always worked there :)


Martin

On Wed, Nov 9, 2016 at 9:11 AM, Michal Skrivanek
 wrote:
>
>> On 9 Nov 2016, at 08:55, Francesco Romani  wrote:
>>
>> - Original Message -
>>> From: "Piotr Kliczewski" 
>>> To: "Martin Perina" 
>>> Cc: "Francesco Romani" , "Shira Maximov" 
>>> , "devel" 
>>> Sent: Tuesday, November 8, 2016 9:31:43 PM
>>> Subject: Re: [vdsm] Connection refused when talking to jsonrpc
>>
>>
> 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads
> Traceback (most recent call last):
>  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in
> run
>hypervisor_iface = self.get_hypervisor_interface()
>  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217,
> in get_hypervisor_interface
>return module.instance(self.config)
>  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> dsmjsonrpcbulkInterface.py",
> line 47, in instance
>return JsonRpcVdsmBulkInterface()
>  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> dsmjsonrpcbulkInterface.py",
> line 29, in __init__
>super(JsonRpcVdsmBulkInterface, self).__init__()
>  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
> dsmjsonrpcInterface.py",
> line 43, in __init__
>.orRaise(RuntimeError, 'No connection to VDSM.')
>  File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in
> orRaise
>raise exception(*args, **kwargs)
> RuntimeError: No connection to VDSM.
>
>
> The question here is, how much time does VDSM need to allow jsonrpc to
> connect and request a ping and list of VMs?
>
>
>>> It depends on recovery logic in vdsm and it can take quite some time.
>>>
>>> Please share vdsm logs so I could take a look?
>>
>> +1
>>
>> the most likely cause is the recovery still in progress, however I was 
>> expecting
>> a different error, so worth looking at the logs.
>
> Isn’t the most likely cause by far a simple startup delay? We do open the 
> listener “soon” and responds with code 99, but it’s still not instant of 
> course
>
>>
>> Bests,
>>
>> --
>> 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
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc

2016-11-09 Thread Michal Skrivanek 

> On 9 Nov 2016, at 08:55, Francesco Romani  wrote:
> 
> - Original Message -
>> From: "Piotr Kliczewski" 
>> To: "Martin Perina" 
>> Cc: "Francesco Romani" , "Shira Maximov" 
>> , "devel" 
>> Sent: Tuesday, November 8, 2016 9:31:43 PM
>> Subject: Re: [vdsm] Connection refused when talking to jsonrpc
> 
> 
 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads
 Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in
 run
hypervisor_iface = self.get_hypervisor_interface()
  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217,
 in get_hypervisor_interface
return module.instance(self.config)
  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
 dsmjsonrpcbulkInterface.py",
 line 47, in instance
return JsonRpcVdsmBulkInterface()
  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
 dsmjsonrpcbulkInterface.py",
 line 29, in __init__
super(JsonRpcVdsmBulkInterface, self).__init__()
  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/v
 dsmjsonrpcInterface.py",
 line 43, in __init__
.orRaise(RuntimeError, 'No connection to VDSM.')
  File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in
 orRaise
raise exception(*args, **kwargs)
 RuntimeError: No connection to VDSM.
 
 
 The question here is, how much time does VDSM need to allow jsonrpc to
 connect and request a ping and list of VMs?
 
 
>> It depends on recovery logic in vdsm and it can take quite some time.
>> 
>> Please share vdsm logs so I could take a look?
> 
> +1
> 
> the most likely cause is the recovery still in progress, however I was 
> expecting
> a different error, so worth looking at the logs.

Isn’t the most likely cause by far a simple startup delay? We do open the 
listener “soon” and responds with code 99, but it’s still not instant of course

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

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