OK, I've finally figured out why I was getting confused and what NMS-4562's Description of "You have to delete the service from the node page" means. It actually means you ALSO have to delete the service from the node page.
If you try to delete a provisioned node from the node page, you see the message that the node has to be deleted from the provisioning group. Thus from a standpoint of UI consistency, you would expect that the services also should be deleted from the provisioning group as well and, if you try to delete the service from the node page when the service is still in the Provisioning Group, the deletion request appears to be rejected/ignored. So you wind up have to delete a provisioned service twice, from the provisioning group first (don't forget to synchronize), and then from the node page. From a UI standpoint, requiring a double deletion from two significantly different parts of the user interface is extremely confusing.
I guess the problem is that it's easy for the UI to check whether a node was provisioned by looking at the foreignsource/foreignid columns, but there's no such indicator in ifservices to see if a service was explictly part of the node description in the provisioning list or if it was discovered (i.e. as a result of scanning a provisioned interface with no services list). Such a column should probably be added and maintained by the provisioning daemon during provisioning group synchronization.
Probably what should happen to be consistent with node UI behaviour is that
- on the Node's service page, the Delete link should only available if the service was not provisioned explictly.
- on the Node's service page, a message should be displayed when a service was explictly provisioned that it needs to be removed from the provisioning group's node definition,
I'm not sure if the process for queuing a deletion should also accept an additional parameter to indicate that the request was generated by the provisioning daemon, or if it could just check the new provisioned flag in the ifservices table.
However, I hope that the above explains why I think that even if there is a detector for that type of service, the service should be deleted if the detector fails to detect the service (i.e. a service that may have been present during initial provisioning may since have been disabled in the monitored system). Otherwise de-provisioning a service for which a detector exists (but no actual running service) would still force the user to delete a service twice in two different places. Hopefully the second paragraph in this comment makes it clear why this is not a good thing.
If there is no detector for that type of service then the service should be deleted when unprovisioned