Skip to content
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

[dev.icinga.com #13307] Depending services should get deleted by director #623

Closed
icinga-migration opened this issue Nov 24, 2016 · 4 comments
Labels
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13307

Created by mfrosch on 2016-11-24 10:12:05 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-11-24 10:24:01 +00:00 (in Redmine)


Currently services that are directly added to a host will get deleted by the database, and not the director itself.

Therefor they are not shown in audit log.

We should properly delete the services, and log the event. Maybe find a general way for related objects that should be deleted without question. (Or ask a question?)


Relations:

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-11-24 10:15:18 +00:00

  • Duplicates set to 13261

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-11-24 10:24:01 +00:00

Deleting them is the way to go. In case we do so on beforeDelete with IcingaService::load($id)->delete() they should logged correctly.

BUT: restoring them would mean clicking each of them, makes no fun. And is regardless of this currently broken as of no "id" and/or combined key handling in the history.

Another nice approach might be to store them to the activity log with the deleted host. I'd probably prefer doing so, as it is more efficient. Only disadvantage: requires more love and care for the "Restore" form. When a Service-template required for restore got removed in the meantime I still want to be able to restore the host and the other services. Related checks and helpers should be introduced.

Please note that we could implement this in a generic way, but it's IMO not worth the effort. Sure, we could do so - but we cannot base this logic on existing relatedObjects and would be required to introduce a similar (but simpler) construct. Or teach them about the kind of join and constraint they are in. This monster is going to become an ORM ;-)

Cheers,
Thomas

@Thomas-Gelf
Copy link
Contributor

Restore is now fine, we should address this.

@Thomas-Gelf Thomas-Gelf added this to the 1.6.0 milestone Sep 5, 2018
@Thomas-Gelf
Copy link
Contributor

NB: delete also takes place, what's missing is the restore button

@Thomas-Gelf Thomas-Gelf modified the milestones: 1.6.0, 1.7.0 Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants