All changes in this area should be deferred to rewrite of the vdsm-reg and vdsm plugin.

Oh... I did not read comment#0 correctly, I thought it is just keeping the engine name for future use.

I do not understand... if engine accesses the node it is enabled at engine.

Not sure why we need more than that not via the webadmin.

(In reply to Alon Bar-Lev from comment #2)
> Oh... I did not read comment#0 correctly, I thought it is just keeping the
> engine name for future use.
> 
> I do not understand... if engine accesses the node it is enabled at engine.

But the point here is how the node detects it get unregistered via webadmin?

(In reply to Douglas Schilling Landgraf from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> > Oh... I did not read comment#0 correctly, I thought it is just keeping the
> > engine name for future use.
> > 
> > I do not understand... if engine accesses the node it is enabled at engine.
> 
> But the point here is how the node detects it get unregistered via webadmin?

we do not support unregistration functionality. if we need this it should be carefully considered by PM.

we are working in master-slave architecture, the up-to-date data is at master side. if anyone wants to know anything about the inventory he should go to the master interfaces, in this case we do have UI and api (Rest).

(In reply to Alon Bar-Lev from comment #4)
> (In reply to Douglas Schilling Landgraf from comment #3)
> > (In reply to Alon Bar-Lev from comment #2)
> > > Oh... I did not read comment#0 correctly, I thought it is just keeping the
> > > engine name for future use.
> > > 
> > > I do not understand... if engine accesses the node it is enabled at engine.
> > 
> > But the point here is how the node detects it get unregistered via webadmin?
> 
> we do not support unregistration functionality. if we need this it should be
> carefully considered by PM.
> 
> we are working in master-slave architecture, the up-to-date data is at
> master side. if anyone wants to know anything about the inventory he should
> go to the master interfaces, in this case we do have UI and api (Rest).

That's why I have created the bugzilla, we need such mechanism to ovirt node fetch  if it still registered to ovirt-engine, if it's removed there is no reason to display to users the engine data in the node. The current REST API requires authentication, if we want to change that or create a servlet to do it, it's not in ovirt-node-plugin-vdsm component at all.

(In reply to Douglas Schilling Landgraf from comment #5)
> (In reply to Alon Bar-Lev from comment #4)
> > (In reply to Douglas Schilling Landgraf from comment #3)
> > > (In reply to Alon Bar-Lev from comment #2)
> > > > Oh... I did not read comment#0 correctly, I thought it is just keeping the
> > > > engine name for future use.
> > > > 
> > > > I do not understand... if engine accesses the node it is enabled at engine.
> > > 
> > > But the point here is how the node detects it get unregistered via webadmin?
> > 
> > we do not support unregistration functionality. if we need this it should be
> > carefully considered by PM.
> > 
> > we are working in master-slave architecture, the up-to-date data is at
> > master side. if anyone wants to know anything about the inventory he should
> > go to the master interfaces, in this case we do have UI and api (Rest).
> 
> That's why I have created the bugzilla, we need such mechanism to ovirt node
> fetch  if it still registered to ovirt-engine, if it's removed there is no
> reason to display to users the engine data in the node. The current REST API
> requires authentication, if we want to change that or create a servlet to do
> it, it's not in ovirt-node-plugin-vdsm component at all.

Again, you should define "need", and why is it that important for slave to know the status of master, especially if it is for user interface only with no applicable effect other than display.

While without any effort you can show active managers that communicate with the node, as manager always poll the node you can show data that is sufficient to this cause.

(In reply to Alon Bar-Lev from comment #6)
> (In reply to Douglas Schilling Landgraf from comment #5)
> > (In reply to Alon Bar-Lev from comment #4)
> > > (In reply to Douglas Schilling Landgraf from comment #3)
> > > > (In reply to Alon Bar-Lev from comment #2)
> > > > > Oh... I did not read comment#0 correctly, I thought it is just keeping the
> > > > > engine name for future use.
> > > > > 
> > > > > I do not understand... if engine accesses the node it is enabled at engine.
> > > > 
> > > > But the point here is how the node detects it get unregistered via webadmin?
> > > 
> > > we do not support unregistration functionality. if we need this it should be
> > > carefully considered by PM.
> > > 
> > > we are working in master-slave architecture, the up-to-date data is at
> > > master side. if anyone wants to know anything about the inventory he should
> > > go to the master interfaces, in this case we do have UI and api (Rest).
> > 
> > That's why I have created the bugzilla, we need such mechanism to ovirt node
> > fetch  if it still registered to ovirt-engine, if it's removed there is no
> > reason to display to users the engine data in the node. The current REST API
> > requires authentication, if we want to change that or create a servlet to do
> > it, it's not in ovirt-node-plugin-vdsm component at all.
> 
> Again, you should define "need", and why is it that important for slave to
> know the status of master, especially if it is for user interface only with
> no applicable effect other than display.

If ovirt-node-plugin-vdsm detects that ovirt node is removed from oVirt Engine we can unlock the hostname field in the TUI for users be able to change it again and we can put all interfaces in the original stage. Please see the depends on bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1083131


> While without any effort you can show active managers that communicate with
> the node, as manager always poll the node you can show data that is
> sufficient to this cause.

Can you please give more details how ovirt-node-plugin-vdsm will detect the ovirt-engine poll?

(In reply to Douglas Schilling Landgraf from comment #7)
> (In reply to Alon Bar-Lev from comment #6)
> > Again, you should define "need", and why is it that important for slave to
> > know the status of master, especially if it is for user interface only with
> > no applicable effect other than display.
> 
> If ovirt-node-plugin-vdsm detects that ovirt node is removed from oVirt
> Engine we can unlock the hostname field in the TUI for users be able to
> change it again and we can put all interfaces in the original stage. Please
> see the depends on bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1083131

This all should be sysamdin decision.
There should be "Revert to default" option somewhere.

> > While without any effort you can show active managers that communicate with
> > the node, as manager always poll the node you can show data that is
> > sufficient to this cause.
> 
> Can you please give more details how ovirt-node-plugin-vdsm will detect the
> ovirt-engine poll?

Isn't there a vds client or vdsm tool command that shows recent manager sessions?

(In reply to Alon Bar-Lev from comment #8)
> (In reply to Douglas Schilling Landgraf from comment #7)
> > (In reply to Alon Bar-Lev from comment #6)
> > > Again, you should define "need", and why is it that important for slave to
> > > know the status of master, especially if it is for user interface only with
> > > no applicable effect other than display.
> > 
> > If ovirt-node-plugin-vdsm detects that ovirt node is removed from oVirt
> > Engine we can unlock the hostname field in the TUI for users be able to
> > change it again and we can put all interfaces in the original stage. Please
> > see the depends on bugzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1083131
> 
> This all should be sysamdin decision.
> There should be "Revert to default" option somewhere.

Ok, in that case we are assuming that user already removed the node from engine right?

> 
> > > While without any effort you can show active managers that communicate with
> > > the node, as manager always poll the node you can show data that is
> > > sufficient to this cause.
> > 
> > Can you please give more details how ovirt-node-plugin-vdsm will detect the
> > ovirt-engine poll?
> 
> Isn't there a vds client or vdsm tool command that shows recent manager
> sessions?

I tried getVdsCaps and didn't find such info. vdsm-tool doesn't seem to show this info either.

(In reply to Alon Bar-Lev from comment #8)
> (In reply to Douglas Schilling Landgraf from comment #7)
> > (In reply to Alon Bar-Lev from comment #6)
> > > Again, you should define "need", and why is it that important for slave to
> > > know the status of master, especially if it is for user interface only with
> > > no applicable effect other than display.
> > 
> > If ovirt-node-plugin-vdsm detects that ovirt node is removed from oVirt
> > Engine we can unlock the hostname field in the TUI for users be able to
> > change it again and we can put all interfaces in the original stage. Please
> > see the depends on bugzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1083131
> 
> This all should be sysamdin decision.
> There should be "Revert to default" option somewhere.

Hey,

if informations are displayed on the TUI then they should be correct, I believe that this is also what users would assume (correct informations), i.e. to decide if he can unplug a network cable or not.

Because of that we need a way to query this informations from the master to be able to reflect the correct state (reg. pending, registered, unamanged/unregeistered) in the client's UI.

The "reset to default" issue is a different issue IMO, which could be helpfull if the registration is in some failure state.

some thoughts:
An unauthorized RHEV-M API to let RHEV-H query the registration status, could lead to information leakage.

To prevent this, RHEV-H should rather listen to "pings" from RHEV-M to determin it's status.

As I wrote, the node it-self is not a special project in this sense, if we need to add host removal sequence, this should be done to nodes and regular hosts, as node is no special in this regard.

I am unsure that these efforts are justified.

The TUI should just not show (and I think it doesn't) the active manager, so there is no actual issue, even if it displays something it can be simply removed.

Over engineering just to present some item, adding pings or new apis, or handle the state in which removing hosts at manager when host is unresponsive is something that should be considered carefully when the benefit is display bit at one place which is already available at another.

My 2 cents.

I totally agree with Alon above.

I would even go further and claim not removing the data from ovirt-node is required.

The use case of using ovirt-node in large scaled environment was not by using the TUI, rather using PXE installation and having the engine's destination (as well as all other required params) as a part of the kernel params.

The intent was for that was to control it externally, and further more the common use case from engine's side is removel ... but still expecting the node to re-register constantly, so the admin can choose again whether to add it or not. this is the reason the node tries to register each boot.


If one wants to change the data through the TUI it is possible.
I assume no admin will remove a node from the TUI alone but rather will check in the manager if it's connected or even remove it first.

I don't think there is a justification for such functionality that by definition adding a redundant flow of un-deploy.

I would close as NOTABUG

(In reply to Barak from comment #13)

> The use case of using ovirt-node in large scaled environment was not by
> using the TUI, rather using PXE installation and having the engine's
> destination (as well as all other required params) as a part of the kernel
> params.
> 
> The intent was for that was to control it externally, and further more the
> common use case from engine's side is removel ... but still expecting the
> node to re-register constantly, so the admin can choose again whether to add
> it or not. this is the reason the node tries to register each boot.

Than you have to document that somewhere, as it is not today.
Nobody knows that node is just for large scale pxe boot environments.

I doubt that this is the most common use case in real world scenarios
because most installation guides mention the node in a way as if it is
the preferred way to install hosts in any scenario.

so please fix that, because as of today most users on the ML
are better off with deploying el6 or fedora based hosts with vdsm on top.

you can clearly see that by comparing bug reports and questions/complaint
numbers about stuff that works on el/fedora based hosts and even basic stuff
which breaks node based hosts.

> If one wants to change the data through the TUI it is possible.
> I assume no admin will remove a node from the TUI alone but rather will
> check in the manager if it's connected or even remove it first.
> 
> I don't think there is a justification for such functionality that by
> definition adding a redundant flow of un-deploy.
> 
> I would close as NOTABUG

(In reply to Barak from comment #13)

> I would even go further and claim not removing the data from ovirt-node is
> required.
> 
> The use case of using ovirt-node in large scaled environment was not by
> using the TUI, rather using PXE installation and having the engine's
> destination (as well as all other required params) as a part of the kernel
> params.

Yes, that is one use case - deploying it via kernel arguments.
But the TUI is also a part of Node, which is also beeing used. And thus the TUI should state correct informations.

And the information if a Node is registered or not can be relevant. Think of a sysadmin who want's to power down a server in the server room. If the TUI provided the registration state, then he could verify that he is powering down an unregistered machine.

As Sven indicates above there are users who would also like to use Node in a small scale environment.

> The intent was for that was to control it externally, and further more the
> common use case from engine's side is removel ... but still expecting the
> node to re-register constantly, so the admin can choose again whether to add
> it or not. this is the reason the node tries to register each boot.
>
> If one wants to change the data through the TUI it is possible.
> I assume no admin will remove a node from the TUI alone but rather will
> check in the manager if it's connected or even remove it first.

Let me say that this is not about adding another mechanism to un-register, but only a mechanism to "reflect the registration state on the Node".

To reflect the state of the registration it would be great if (a) Engine would somehow let Node know when it get's unregistered or (b) provide a mechanism to Node to query it's state (but this might be a leaky approach, see comment 11).

> I don't think there is a justification for such functionality that by
> definition adding a redundant flow of un-deploy.

AFAIK there is currently no way for Node to determin if it is registered/part of a cluster or not.

> I would close as NOTABUG

I had this ask coming from customers as well, wanting to unregister a host so they could make changes such as changing host name, instead of reinstalling rhev-h host.

I think this should be closed NOTABUG

Since there is no specific user request attached and this is hard to implement and there is a discussion to whether this should be implemented at all, closing this RFE. Please reopen if anyone see this as critical and we can re-discuss.