Bug 1186365

Summary:	Invalid URL format when there are no dots in the host name
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	sha
Component:	ovirt-engine-cli	Assignee:	Juan Hernández <juan.hernandez>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.4.0	CC:	ecohen, gklein, iheim, lsurette, rbalakri, Rhev-m-bugs, rhodain, yeylon
Target Milestone:	---
Target Release:	3.6.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-12 09:54:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description sha 2015-01-27 14:41:13 UTC

Description of problem:
Trying to connect to api using ovirt-shell from F21, no matter what url combination I use, it always comes back with "is invalid url format, valid format is http[s]://server:port/path, where path is usually "ovirt-engine/api" or, for older versions of the engine, just "api". "

Version-Release number of selected component (if applicable):
[root@pmpc1455:~]$ cat /etc/redhat-release 
Fedora release 21 (Twenty One)

[root@pmpc1455:~]$ rpm -qa | grep ovirt
ovirt-engine-cli-3.4.0.5-3.fc21.noarch
ovirt-engine-sdk-python-3.4.0.7-2.fc21.noarch
libgovirt-0.3.2-1.fc21.x86_64


How reproducible:
Everytime


Steps to Reproduce:
1. Try logging into shell using:
ovirt-shell -l http://ovirt-hosted-00/ovirt-engine/api -u admin@internal

2. 

3.

Actual results:

ERROR
"http://ovirt-hosted-00/ovirt-engine/api" is invalid url format, valid format is http[s]://server:port/path, where path is usually "ovirt-engine/api" or, for older versions of the engine, just "api".

and a disconnected prompt


Expected results:

Connected prompt


Additional info:

I can log in through a web browser.

Comment 1 Juan Hernández 2015-01-27 15:05:43 UTC

If you are connecting to a production engine it will be protected with SSL, so you need to specify "https://...", and in addition the CLI will check the certificate of the server, so you also need the "--ca-file" (or "-A") option indicating the location of the CA that signed the certificate of the web server. This is usually available in "http://.../ca.crt" URL, if you didn't change it manually. So, all in all, you need something like this:

  # wget http://ovirt-hosted-00/ca.crt 

  # ovirt-shell \
  -h http://ovirt-hosted-00/ovirt-engine/api \
  -u admin@internal \
  --ca-file=ca.crt

Note also that it looks like you are using "ovirt-hosted-00" as the host name, and this isn't probably a fully qualified host name. The certificate of the web server will probably contain the fully qualified host name, and the CLI checks that, so it will probably fail. In the URL passed to the ovirt-shell parameter you should put exactly the same host name used in the web server certificate.

If you don't care about SSL certificate verification you can alternatively use the "--insecure" (or "-I") option:

  # ovirt-shell \
  -h http://ovirt-hosted-00/ovirt-engine/api \
  -u admin@internal \
  --insecure

Your issue could also be caused by this 1069171, but that is already fixed in the version you are using. It could be that you have some older version of the CLI or the SDK installed. Please check:

  # pip list | grep ovirt

Finally, note that you are reporting the bug against RHEV-M CLI, but you are actually using the version of the CLI included in Fedora. Are you using RHEV-M or oVirt Engine?

Comment 2 sha 2015-01-27 15:17:25 UTC

Hi Juan,

It was the FQDN that was the issue. Might be worth clarifying the error message to: 
valid format is http[s]://server.domain:port/path or something similar?

# ovirt-shell \
  -l https://ovirt-hosted-00.domain/ovirt-engine/api \
  -u admin@internal \
  --insecure

Apologies for the waste of time :-)

Simon

Comment 3 Juan Hernández 2015-01-27 15:32:20 UTC

This is a legitimate bug then, because a name without dots is OK if it is what appears in the server certificate. When using the "--insecure" option the content of the certificates isn't relevant, so it should have worked. We will fix that.

Comment 4 Juan Hernández 2015-02-24 08:52:45 UTC

*** Bug 1195624 has been marked as a duplicate of this bug. ***