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 #11318] Hosts, timeperiods and services are not imported. #129

Closed
icinga-migration opened this issue Mar 6, 2016 · 5 comments
Labels
Milestone

Comments

@icinga-migration
Copy link

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

Created by kowalskimn on 2016-03-06 20:11:35 +00:00

Assignee: kowalskimn
Status: Closed (closed on 2016-03-22 02:14:16 +00:00)
Target Version: 1.0.0
Last Update: 2016-03-22 22:52:08 +00:00 (in Redmine)


When importing the configuration via the cli (icingacli director kickstart run) i only get zones, commands, and endpoints imported. There are no error messages indicating any issues with the import.

This is with postgresql backend. Is that a bug or unfinished feature?


Relations:

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-03-06 20:29:29 +00:00

  • Status changed from New to Feedback
  • Assigned to set to kowalskimn

That's the desired behaviour. Zones and Endpoints are required as they are already there when the Director connects for the first time - you cannot configure an API user without a matching endpoint object, and an endpoint must be member of a zone.

So, that's why they are imported. Commands are imported as most people use the ITL and there is no Directorified ITL right now. This basically helps you with getting started fast.

The other objects do not really make sense to me right now, but I'm not completely against doing so. Just give me a good reason ;)

Icinga 2 does not allow one to modify existing objects configured in /etc through the API in a way that would make any sense in a real-world scenario. Just try to imagine a software able to deal with any potential variant of your hand-crafted Icinga 2 config. It wouldn't work out, and that's why even the Icinga 2 API isn't able to do so.

Basically, if you want to work with Director, you should start from scratch. I can import your existing hosts, but you would see them "flat". The Icinga 2 API doesn't know anything about your templates. Apply rules? Invisible, the API ships flat resolved services. You would not be allowed to modify those hosts, so there is really not much fun to expect.

In case you have farther questions or related suggestions please do not hesitate to ask or to let me know.

Thanks,
Thomas

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-03-06 20:50:07 +00:00

NB: the MySQL schema does not even allow for external hosts, services and timeperiods right now. As of this writing it is a bug that the PostgreSQL schema allows such and that some form suggests that one could to so.

Still, this is nothing that couldn't easily be changed - just give me a good use-case for doing so.

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-03-06 20:51:11 +00:00

  • Relates set to 11300

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-03-22 02:14:16 +00:00

  • Status changed from Feedback to Closed

No feedback, closing this for now.

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-03-22 22:52:08 +00:00

  • Target Version set to 1.0.0

@icinga-migration icinga-migration added this to the 1.0.0 milestone Jan 17, 2017
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

1 participant