|Summary:||[RFE] Allow changing the address of hosts|
|Product:||[Retired] oVirt||Reporter:||Sven Kieske <s.kieske>|
|Component:||ovirt-engine-core||Assignee:||Yaniv Bronhaim <ybronhei>|
|Status:||CLOSED WONTFIX||QA Contact:||bugs <bugs>|
|Version:||3.3||CC:||alonbl, bazulay, gklein, iheim, nsednev, rbalakri, s.kieske, yeylon|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-03-29 09:06:30 UTC||Type:||Bug|
|oVirt Team:||Infra||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Sven Kieske 2014-01-31 13:29:02 UTC
Description of problem: Currently, you can not change the address which engine uses to connect to a host in webadmin or via API, instead you have to change the db by hand Version-Release number of selected component (if applicable): tested in 3.3.2 should still be the same in 3.4 alpha1 How reproducible: always Steps to Reproduce: 1.select a host in webadmin 2. click edit 3. find the "address" field greyed out Actual results: you can't change the address Expected results: you are able to change the address of the hostname Additional info: currently, this just works by logging in as the postgres user and use the following command: psql engine -c "update vds_static set host_name = '$NEWNAME' where host_name = '$OLDNAME';" This would be a cool feature, e.g. if you switch from fqdn addresses to ip based addresses or vice versa.
Comment 1 Itamar Heim 2014-02-01 15:17:48 UTC
Sven - can you try: 1. move hos to maint. 2. edit the name 3. click re-install
Comment 2 Sven Kieske 2014-02-03 11:45:48 UTC
Itamar, I tried as you suggested, but I think you misunderstood my intent. I do not want to edit the "name" but the "address" field, which ovirt uses to connect to the host. So I did: 1. shutdown all running vms on that host. 2. put it into maintenance. 3. Clicked edit Actual Result: The "address" field is greyed out, you can not edit it. Expected result: be able to edit this field. It is already possible to achieve this by hacking at the db (like I discribed above).
Comment 3 Itamar Heim 2014-02-03 11:50:17 UTC
barak - thoughts on why we block editing the hostname (other than it will have to be re-installed?)
Comment 4 Sven Kieske 2014-02-03 12:06:00 UTC
Itamar, you still don't seem to understand. oVirt does _not_ block editing the "name" field but it blocks the "address" field, which is used to connect to the host via ssh. This field might get filled by a hostname which is resolvable via DNS or with an IPv4 address. It may be related to the hosts certificates, which I didn't check. All I can is report that you can achieve a changed address by hacking the db so I think this should also be possible without hacking it. Thank you.
Comment 5 Itamar Heim 2014-02-03 12:09:12 UTC
sven - address == hostname and yes, the issue is about the need to re-install once changing it, so the certificate will be re-generated. I assume changing the address would cause the node to become non-responsive if you activate it without re-installing?
Comment 6 Sven Kieske 2014-02-03 12:16:00 UTC
Well my workflow was like the following: 1. move host to maintenance 2. stop ovirt engine, do a backup of the db 3. as postgres user: psql engine -c "update vds_static set host_name = '$NEWNAME' where host_name = '$OLDNAME';" 4. restart engine 5. activate host again 6. everything is up and running, so no reinstallation of the host was done I'll check the certificates by hand, this is weird, according to your description the host should not be recognized because the certificate doesn't fit the address?
Comment 7 Sven Kieske 2014-02-03 12:38:55 UTC
Additional Info: The certificates still hold the old Hostname in the "CN" Field So I guess for my RFE to work we would need a helper script in the background which creates new certs for the new hostname and rolls them out, revoking the old ones? But why is my host still operational in the first place?
Comment 8 Alon Bar-Lev 2014-02-03 12:44:52 UTC
(In reply to Sven Kieske from comment #7) > But why is my host still operational in the first place? this is a serious bug, I can confirm that this is the case, just tried it.
Comment 9 Alon Bar-Lev 2014-02-03 12:53:53 UTC
(In reply to Alon Bar-Lev from comment #8) > (In reply to Sven Kieske from comment #7) > > But why is my host still operational in the first place? > > this is a serious bug, I can confirm that this is the case, just tried it. bug#1060717 opened.
Comment 10 Barak 2014-02-04 18:05:34 UTC
(In reply to Alon Bar-Lev from comment #8) > (In reply to Sven Kieske from comment #7) > > But why is my host still operational in the first place? > > this is a serious bug, I can confirm that this is the case, just tried it. This happens because we only validate that the certificate is signed by a trusted CA (which is the engine), we do not perform a full client certificate authentication (= validate the request/response actually came from the subject of the cerificate). I don't remember the reason for that ... long time go. Anyway In this case Bug 1060717 contradicts this Bug. The right way is to validate the certificate using the hostname. Bug 1060717 only covers the engine side of validation .... this should also happen on the vdsm side.
Comment 11 Barak 2014-02-04 18:10:28 UTC
Itamar, In light of the above contradistinction how do you suggest to proceed ? Solving Bug 1060717 (by validating the subject ...) will force redeploy of the host after such a change, while this bug addresses that ability to change the address. So I suggest to enable editing the address when the host is in maintenance, and notify the user somehow it must redeploy after such a change.
Comment 12 Itamar Heim 2014-02-04 21:45:26 UTC
(In reply to Barak from comment #11) > Itamar, > > In light of the above contradistinction how do you suggest to proceed ? > Solving Bug 1060717 (by validating the subject ...) will force redeploy of > the host after such a change, while this bug addresses that ability to > change the address. > > So I suggest to enable editing the address when the host is in maintenance, > and notify the user somehow it must redeploy after such a change. yes.
Comment 13 Oved Ourfali 2014-05-26 11:24:19 UTC
*** Bug 1098762 has been marked as a duplicate of this bug. ***
Comment 14 Itamar Heim 2015-03-29 09:06:30 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.