Open EricDavisX opened 3 years ago
Nicolas C notes that we can probably improve our error handling on the 'force' option to ignore when the policy SO is not existing. Not sure how to prioritize this, but likely lower, honestly.
The work-around info: ...can probably delete the agent directly from .fleet-agents index, though *note: this will not invalidate the API key for the agents
@kpollich @nchaulet is this one still a problem?
@kpollich @nchaulet is this one still a problem?
Yes, this issue is still present.
@criamico - Is this the same issue as https://github.com/elastic/kibana/issues/155925? And does your PR for that issue address this?
Seems like this comment explains how to do this today https://github.com/elastic/kibana/issues/155925#issuecomment-1919250162, e.g.
POST kbn:/api/fleet/agents/<agent_id>/unenroll
{
"force": true,
"revoke": true
}
Perhaps we should add this to our troubleshooting docs to make sure users can recover from this situation?
Filed a request to add this workaround to troubleshooting docs: https://github.com/elastic/ingest-docs/issues/897
Kibana version: 8.0 based self-managed stack, on our 'kibana' endpoint / ingest test system.
Describe the bug: I suppose some maintenance was done on the server and we deleted the saved-objects metadata for the Agents somehow (it is a routinely updated server and sometimes roughly used / maintained). So, it isn't high urgency, perhaps, but in this case, I think it brings the need for the 'force' usage to be even a little more forceful. I am guessing at the logic, but could we change the function to ignore when the SO isn't found and still push through on the removal?
... or is that critical triage info the user would / may want to know so they can follow up on root cause and talk to support team, etc. I'm not fully sure.
Steps to reproduce:
Expected behavior: Agent is removed as desired.
We currently have this situation on our test server, I can point you to it over slack if you need.
*Screenshots (if relevant): *