Hide Forgot
Description of problem: When registering an ovirt node to the engine vdsm-reg-setup submits the ip address of the management interface. If the management interface has a nat address (e.g. an rfc1918 address) the internal ip address is stored in the engine. Thus, the engine cannot reach the node. To workaround this issue I propose the attached patch that allows specifying the public ip address as "vds_ip" in the configuration file. It's a quick and dirty hack that works for me so please revise it before applying. Also, maybe there are better ways to solve this problem. Version-Release number of selected component (if applicable): 3.3.0 How reproducible: always. Steps to Reproduce: 1. have an ovirt node on a natted network 2. run vdsm-reg-setup 3. ovirt node registers itself with his rfc1918 address Actual results: node is unreachable for ovirt-engine because of it's rfc1918 address. Expected results: node is reachable through it's public ip address. Additional info:
Created attachment 834731 [details] read public ip address from config file (vds_ip)
Alon, What do you think ?
(In reply to Barak from comment #3) > Alon, What do you think ? this is known issue, nat was not considered in initial design of this feature. one simple solution is to initiate the host-deploy via engine as regular host. in bug#875088 the generic node registration protocol, I designed url?cmd=get-bootscript which replaces the manager initiated communication in favor of a script that is pulled from the manager. also in the v1 registration protocol of ovirt-engine[1], if host ip is not explicitly specified as parameter which should be the default, the source ip is used[2], which is the public ip of the NAT. so this will work with the component that is going to replace vdsm-reg(bug#994451). [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=2f199ecc45ac0b8b3e1965f833e1639e7a40f1be [2] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/services/src/main/java/org/ovirt/engine/core/services/RegisterServlet.java;hb=HEAD#l192
Alon, Is this enough? I think we have discussed in the past about a different solution,
(In reply to Barak from comment #5) > Alon, > > Is this enough? > I think we have discussed in the past about a different solution, I do not follow what "this" is.
(In reply to Alon Bar-Lev from comment #6) > (In reply to Barak from comment #5) > > Alon, > > > > Is this enough? > > I think we have discussed in the past about a different solution, > > I do not follow what "this" is. vdsm-reg - refactor ? We had a discussions whether to enable it ovet NAT ? What are the right ways to approach it ? The solution suggested above changes the registration protocol/interface. Do we have any other option ?
(In reply to Barak from comment #7) > (In reply to Alon Bar-Lev from comment #6) > > (In reply to Barak from comment #5) > > > Alon, > > > > > > Is this enough? > > > I think we have discussed in the past about a different solution, > > > > I do not follow what "this" is. > > vdsm-reg - refactor ? sure, any new feature is part of the refactor. > We had a discussions whether to enable it ovet NAT ? see comment#4 this is what we do know, it what should be done to support it in generic manner. > What are the right ways to approach it ? most probably reverse the vdsm protocol so that vdsm access the engine, this way it is easier to support mass deployment and registration. It is easier to NAT single machine than handle the reverse NAT. > The solution suggested above changes the registration protocol/interface. > > Do we have any other option ? yes, the new registration servlet[1], for this trivial issue at comment#0 it should be sufficient. """ command==register Input address - Host address to register, default request origin. """ so that by default the registration client should not specify address, to be registered using whatever the engine sees. [1] http://www.ovirt.org/Features/HostDeployProtocol
So this should be CLOSED NOTABUG ?
(In reply to Barak from comment #9) > So this should be CLOSED NOTABUG ? depends on what the definition of bug is... this is a feature request as the initial design did not consider NAT to be available between engine and vdsm. if we do plan to support NAT then it should be kept open. I am unsure what re-write of vdsm-reg will be as I see progress at the ovirt-node front[1], detached from us[2], have not reviewed it yet it is hard to understand from the plain documentation how it is working, but it should work[3] with the existing protocol of engine[4], so the entire problem moved to ovirt-node side: 1. enable if the engine supports the new registration servlet (simple to query). 2. support the sequence in [5], including: a. TUI integration b. explicit URL and http/https selection. c. download CA certificate from TLS handshake and not from host-deploy d. confirm certificate hash before persisting. e. integrate with boot args. f. implement registration at boot. as the engine is ready (its new registration protocol is used by the new ovirt-node registration tool) this is not an issue at engine side any more. [1] https://bugzilla.redhat.com/show_bug.cgi?id=875088 [2] http://www.ovirt.org/Features/Node/GenericNodeRegistration [3] http://gerrit.ovirt.org/#/c/27976/ [4] http://www.ovirt.org/Features/HostDeployProtocol [5] https://bugzilla.redhat.com/show_bug.cgi?id=994451
per comment #10 ...moving to node
(In reply to Barak from comment #11) > per comment #10 ...moving to node the node registration is not valid... see discussion at bug#875088, I reopened the RFE. Until we have generic node we need to keep this at our component...
The original RFE is reopened, moving to Barak at this moment.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.