-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vSphere: Ignore VM templates #768
base: master
Are you sure you want to change the base?
Conversation
Skip agent output for VM templates. This removes VM templates from discovery and avoids their piggyback data.
All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA or my organization already has a signed CLA. |
Hi @rhartmann, But with your PR those services would disappear and templates would become completely invisible. |
To add to that: If it would be configurable, it would be acceptable. But as a hard drop of those services, it is not. |
Make ignoring templates optional (command-line argument). This adds backwards compatibilty: templates do not disappear unless opted-in.
dd5ce48
to
075c213
Compare
I added an option similar to the option for placeholder VMs. I am aware of the possibilities to get rid of (or change the state of) services based on naming conventions, but sadly I cannot apply a naming convention in my use case. Btw, is it possible to use service labels instead? I mean, if the services were labelled as VMs or templates, the entire option to ignore templates would be unnecessary. |
@rhartmann For the services labels you would need to create a rule that applies to VM names (here templates). As you don't have a naming concept, you have the same problem as with the ignored_services (or any other rule) As long as this is the case, service labels would just introduce another secondary rule step, that in fact can be handled already with a direct rule that doesn't need to rely on another rule. |
Would it be possible to add discovered service labels to services belonging / caused by VM templates? |
I suppose, to add service labels instead, the agent and both parse functions (one of which is a legacy check, so is it even worthwile?) would need changes. I don't intend to do those. |
That's fair, I can understand that. Also, it's not clear to me, how the plugin "VMware ESX: Location and State of VMs and Host Systems" should deal with this, adding service labels alone would not do anything. Code wise, there seems to be nothing wrong with it other than a missing migration (to add the new mandatory option), but we could easily add that; no action on your side needed. |
Skip vSphere agent output for VM templates, as proposed in Idea 448538 and discussed in this forum post.
What is the expected behavior?
Do not discover VM templates. No need to monitor something that cannot be powered on.
What is the observed behavior?
Each VM template gets discovered as a separate service that is always WARN because VM template are always powered off.