How to determine power on/off of discovered host from API?

What if a discovered host is powered off after it was discovered and
registered in Foreman.

One way seems to be to:

PUT api/v2/discovered_hosts/:id/refresh_facts

and if a 500 error is returned, then we know it's powered off.

Any other "ping status" API call?

Thanks,

Joseph

Hey,

> PUT api/v2/discovered_hosts/:id/refresh_facts

yeah this or GET /features works as well.

> Any other "ping status" API call?

Nope, all other ports except 8443 and 8448 (http) are firewalled.

Proper shutdown should delete discovered host (file RFE for this
please), good idea. But hard power off we can't detect easily of course.

··· -- Later, Lukas #lzap Zapletal

Looks like yet another feature that will be available when we move to
facets…
This info should be available from the facet that is responsible for
hardware/virtual resource (the one that responds to /hosts/:id/power today)

··· On Tuesday, June 7, 2016 at 3:28:26 PM UTC+3, Lukas Zapletal wrote: > > Hey, > > > PUT api/v2/discovered_hosts/:id/refresh_facts > > yeah this or GET /features works as well. > > > Any other "ping status" API call? > > Nope, all other ports except 8443 and 8448 (http) are firewalled. > > Proper shutdown should delete discovered host (file RFE for this > please), good idea. But hard power off we can't detect easily of course. > -- > Later, > Lukas #lzap Zapletal >

> Hey,
>
> > PUT api/v2/discovered_hosts/:id/refresh_facts
>
> yeah this or GET /features works as well.
>
> We're seeing that PUT api/v2/discovered_hosts/:id/refresh_facts is causing
a new discovered_host. Have you seen this before?

Also, I don't see GET /features in the routes file for foreman_discovery.
This is a route for the smart_proxy, right? Am I missing something?

··· On Tue, Jun 7, 2016 at 3:28 PM, Lukas Zapletal wrote:

Any other “ping status” API call?

Nope, all other ports except 8443 and 8448 (http) are firewalled.

Proper shutdown should delete discovered host (file RFE for this
please), good idea. But hard power off we can’t detect easily of course.

Later,
Lukas #lzap Zapletal


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Shimon, sounds good. Thanks for the reply. I'll use the workaround solution
(of just checking for an error) until this is ready.

··· On Wed, Jun 8, 2016 at 12:54 PM, wrote:

Looks like yet another feature that will be available when we move to
facets…
This info should be available from the facet that is responsible for
hardware/virtual resource (the one that responds to /hosts/:id/power today)

On Tuesday, June 7, 2016 at 3:28:26 PM UTC+3, Lukas Zapletal wrote:

Hey,

PUT api/v2/discovered_hosts/:id/refresh_facts

yeah this or GET /features works as well.

Any other “ping status” API call?

Nope, all other ports except 8443 and 8448 (http) are firewalled.

Proper shutdown should delete discovered host (file RFE for this
please), good idea. But hard power off we can’t detect easily of course.

Later,
Lukas #lzap Zapletal


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

> > We're seeing that PUT api/v2/discovered_hosts/:id/refresh_facts is causing
> a new discovered_host. Have you seen this before?

Hmm, that looks like a bug. Is it possible that IP address or MAC
address of the host changed?

> Also, I don't see GET /features in the routes file for foreman_discovery.
> This is a route for the smart_proxy, right? Am I missing something?

This is a call you do against the discovered node itself.

> > Any other "ping status" API call?
> >
> > Nope, all other ports except 8443 and 8448 (http) are firewalled.

I think there's a misunderstanding. I was under impression you want to
determine if the node is running or not. That's the way how you do this
(directly), we currently do not have any API call that checks that.

You can always use refresh_facts in order to check that, it will give
you an error when the node is not running, but there's no separate API
call as a "health-check".

··· -- Later, Lukas #lzap Zapletal