Description of problem:
Adding a host with a name that is already in use returns a bad request (code 400), while doing the same with a Data Center returns a conflict (code 409).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add a host through the REST-API.
2. Add the same host again.
Bad request (code 400) with the message: "Cannot add Host. The Host name is already in use, please choose a unique name and try again."
We should get a conflict, not a bad request.
Adding a data center with a name that is already in use returns a conflict (code 409) with the message: "Cannot create Data Center. The Data Center name is already in use."
The API translates the error messages returned by the backend into HTTP codes according to the value returned by the ErrorMessage.getErrorType() message. The error returned by the backend when the name of the host is already in use is ACTION_TYPE_FAILED_NAME_ALREADY_USED, and the corresponding ErrorType is BAD_PARAMETERS, not CONFLICT. Not sure why it isn't CONFLICT. The change is simple, but it may have a backwards compatibility effect in existing clients, so I think it is better to not change it in the 3.6 branch.
Ori, do you know why this error type isn't classified as CONFLICT?
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Response: 409 Conflict: Cannot add Host. Host with the same address already exists.
oVirt 4.0.0 has been released, closing current release.
I just installed oVirt 4.1.6 ...that latest release on a new instance of the latest release of CentOS 7.4.1708.
After a setup attempt..."Datacenter" config, ..."Host" config, and "Storage" config...I realized I made a mistake in the config of the "Storage"->POSIX compliant FS Domain ...I basically setup an NFS Share in the wrong place...and instead of having access to 500GB I only had access to 40GB...
So after several failed attempts to undo this ...I decided that a "Force Remove" of the Data Center...was probably my best solution and just rebuild the setup fresh... I quickly found out that this was a BAD idea !!! as the "Force Remove" option under "Data Centers" did almost nothing in the PostgreSQL DB...
So I'm now left to clean entries in the Database to resolve this exact issue...that's supposed to be CLOSED !!!
I did find this response, that describe where to locate the password of your PostgreSQL DB Instance :
I just assumed that the password I used at install was the same password being used to create the database.... Not so...
The setup was to figure out where in the 153 Tables do this stagnant entry for my IP Address exist...
Found that answer here :
Next tidbit... oVirt uses Contraints on Foreign Keys in the DB....so to delete the bad records...you have to delete in this order..
After this, all was good again... I must say...this 4 hour ordeal...could have been avoided by the fact that on a new install of oVirt...with NO ...Zero...VM's running or even configured...I should be allowed to edit...the "Domain" storage entry...I made a simple mistake by mounting the wrong NFS Share and adding it to the oVirt setup...and it cost me half the work day.
Thanks guys, reminds me why I used VMware in the Past
I am sorry to hear that you've had a bad experience with oVirt.
Since you already managed to fix your env, I'll just say that next time you can send a question to users. Usually you will get a quick answer to these kind of questions.