Re: [ovirt-devel] [vdsm] tests failures

2016-11-10 Thread Nir Soffer 
On Thu, Nov 10, 2016 at 3:39 PM, Piotr Kliczewski
 wrote:
> All,
>
> Few mins ago I saw build [1] failure due to:
>
> 13:36:42 ERROR: test_abort_during_copy('block')
> (storage_sdm_copy_data_test.TestCopyDataDIV)
> 13:36:42 
> --
> 13:36:42 Traceback (most recent call last):
> 13:36:42   File
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
> line 133, in wrapper
> 13:36:42 return f(self, *args)
> 13:36:42   File
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/storage_sdm_copy_data_test.py",
> line 279, in test_abort_during_copy
> 13:36:42 raise RuntimeError("Timeout waiting for thread")
> 13:36:42 RuntimeError: Timeout waiting for thread

Adam, can you take a look?

>
> Thanks,
> Piotr
>
> [1] 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2326/console
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [vdsm] tests failures

2016-11-10 Thread Piotr Kliczewski 
All,

Few mins ago I saw build [1] failure due to:

13:36:42 ERROR: test_abort_during_copy('block')
(storage_sdm_copy_data_test.TestCopyDataDIV)
13:36:42 --
13:36:42 Traceback (most recent call last):
13:36:42   File
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
line 133, in wrapper
13:36:42 return f(self, *args)
13:36:42   File
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/storage_sdm_copy_data_test.py",
line 279, in test_abort_during_copy
13:36:42 raise RuntimeError("Timeout waiting for thread")
13:36:42 RuntimeError: Timeout waiting for thread

Thanks,
Piotr

[1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2326/console
___
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-10 Thread Juan Hernández 
On 11/10/2016 09:33 AM, Yaniv Kaul wrote:
> 
> 
> On Wed, Nov 9, 2016 at 8:05 PM, Juan Hernández  > wrote:
> 
> 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.
> 
> 
> I thought I was:
> python-ovirt-engine-sdk4-4.1.0-0.1.a0.20161108gitaad5627.fc24.x86_64
>  

Yes, that build contains the fix, so we can discard it as the source of
your problem.

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

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

2016-11-10 Thread Yaniv Kaul 
On Wed, Nov 9, 2016 at 8:05 PM, Juan Hernández  wrote:

> 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-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"}
> >
>
> 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.
>

I thought I was:
python-ovirt-engine-sdk4-4.1.0-0.1.a0.20161108gitaad5627.fc24.x86_64


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

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

2016-11-10 Thread Gil Shinar 
Jenkins is up and running

Sorry for the inconvenience
Gil

On Thu, Nov 10, 2016 at 9:25 AM, Eyal Edri  wrote:

> 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.
>
>
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel