Bug 1039966

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.