Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #11300] Not able to add external object? #123
This issue has been migrated from Redmine: https://dev.icinga.com/issues/11300
Created by spillerm on 2016-03-04 09:49:53 +00:00
I'm trying to import my hosts as external objects, but it doesn' work.
Updated by tgelf on 2016-03-04 11:25:53 +00:00
Both :D First, external objects are usually not what you want. In an ideal world, all configuration is deployed by Director. As this may often be not the case, external object come to the rescue. You should never be required to manually create them, they can be imported through the Icinga2 API (as the kickstart wizard does with commands, zones and endpoints).
Especially zones and endpoints must currently be handled that way, because if they are not there Director cannot connect. So no chance to let Director create them beforehand. I never had the desire to do so with hosts, as I cannot imagine a scenario where this could be helpful. That's why I missed the fact that the database schema does not even allow for external hosts :D I'll fix this.
Please stay tuned, a bunch of changes there will make it to the master within today (hopefully :p). Most work has been dedicated to pretty flexible new form fields for specific tasks, the last missing puzzle piece for lots of currently missing fields. With those I can finally complete group assignment (currently disabled), notifications and users (perfect through the API, unit-tested but not accessible through the web), ordering of imports (no more mulitiselect elements) and more.
Once done it should be mostly feature-complete for the first release.
NB: I attached two screenshots showing how this is gonna look like
Updated by spillerm on 2016-03-04 12:11:42 +00:00
Thanks for your reply :-)
The existing commands are imported by kickstart wizard as external objects; that worked fine.
Now I'm unsure how to get my (about 300+) hosts into director; I tried via "Import" and "CoreApi" and all I get is a stupid CURL ERROR ("CURL ERROR: Could not resolve host:", but which host? See screenshot); I don't know why this doesn't work, importing the commands was no problem... Then I tried to import via "Sql", but it creates "Objects", and these objects cannot get deployed (of course, because they already exist) ;-)
What's best practise? Import from DB and then delete in /etc? I think that's the core I don't understand. Or is there any hidden documentation I'm missing?
Updated by tgelf on 2016-03-04 15:15:53 +00:00
Ok, now I got what you are trying to do. You are basically asking for a migration path from an existing Icinga2 configuration. And you are mostly right with your assumptions. Honestly, even if that's not what you probably want to hear: you'd better start from scratch for now. And wait for my next big fat git push, as a lot of things are getting easier.
Still, as more people might have similar ideas let me write down my thoughts on this so far. Importing existing config works, but it is basically tricky as of timing issues. It should work like this:
I already did so to import hand-crafted commands, it worked out fine. But be careful, "importing" from the Core is tricky. The API doesn't expose all details, lambda functions, if/else statements and so on are not exported.
Templates also are not. I can offer you to import hosts and services through the api, it requires a very few lines of code to get this fixed. Just didn't realize that it was missing as I never needed it so far. However, I'm unsure whether this will really make you happy, the core API exposes only "flat" objects. So you would loose all templates and all inheritance.
If you can live with "flat" data and want to import just specific properties you still could go pretty far. What I would suggest is:
I'll stop it now, just wanted to give you an idea of your available options ;-) The whole import/sync component is extremely powerful but still lacks documentation. It is extensible in various ways, so most of the mentioned issues could be solved with custom modifiers or more "intelligence" in the Core import source.
But let me please first finish the final release, I'll ship more documentation for those special features afterwards. I slowly start realizing that today I was spending too much time on answering issues and not enough on coding today. Not your fault, btw - don't worry ;)
Updated by viper539 on 2016-03-07 09:07:56 +00:00
Could you explain this a bit?
Updated by tgelf on 2016-03-07 12:17:38 +00:00
I will... slightly postponed the release to get a few rough edges smoother and to ship with a "Getting started" documentation explaining this and similar pitfalls.