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 #11300] Not able to add external object? #123

Closed
icinga-migration opened this issue Mar 4, 2016 · 10 comments
Closed

[dev.icinga.com #11300] Not able to add external object? #123

icinga-migration opened this issue Mar 4, 2016 · 10 comments
Labels
bug
Milestone

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Mar 4, 2016

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

Assignee: tgelf
Status: Closed (closed on 2016-03-21 18:05:52 +00:00)
Target Version: 1.0.0
Last Update: 2016-03-22 22:52:05 +00:00 (in Redmine)


Hi,

I'm trying to import my hosts as external objects, but it doesn' work.
So I tried to add a single external object manually, and it doesn't work.
Am I using your tool the wrong way, or is it a bug?

Regards,
Marianne

Attachments


Relations:

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 4, 2016

Updated by tgelf on 2016-03-04 11:25:53 +00:00

  • File added director_new_form.png
  • File added director_new_form_help.png

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.

Cheers,
Thomas

NB: I attached two screenshots showing how this is gonna look like

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 4, 2016

Updated by spillerm on 2016-03-04 12:11:42 +00:00

  • File added Screen Shot 2016-03-04 at 13.04.24.JPG

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?

Happy hacking,
Marianne

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 4, 2016

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:

  • tell Director to import existing definitions as "external objects"
  • sync rules allow you to override the object type, so you could perfectly import them as "real" (and not "external") objects
  • delete those objects on your Icinga node
  • re-deploy with the Director

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:

  • re-create your templates in the Director (there is IMO no way around this)
  • import your hosts, from Core API, from IDO, both would work
  • define a sync-rule, choosing vars.*, address and name
  • if you do not want to manually re-assign template inheritance you could do so with hand-crafted sync rule property - either specifying custom strings, or using a field from your import source. Would not work for the Core API, as it gives you your own object name in the "templates" property - this would result in a config error as of an inheritance loop

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 ;)

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 5, 2016

Updated by tgelf on 2016-03-05 15:47:45 +00:00

  • Relates set to 11201
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 6, 2016

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

  • Relates set to 11318
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 6, 2016

Updated by tgelf on 2016-03-06 21:46:35 +00:00

  • Assigned to set to tgelf
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 7, 2016

Updated by viper539 on 2016-03-07 09:07:56 +00:00

tgelf wrote:

* sync rules allow you to override the object type, so you could perfectly import them as "real" (and not "external") objects

Could you explain this a bit?
I can import all the Hosts, but only as an extenal_object.

Thank you!

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 7, 2016

Updated by tgelf on 2016-03-07 12:17:38 +00:00

viper539 wrote:

tgelf wrote:
> * sync rules allow you to override the object type, so you could perfectly import them as "real" (and not "external") objects

Could you explain this a bit?
I can import all the Hosts, but only as an extenal_object.

Thank you!

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.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 21, 2016

Updated by tgelf on 2016-03-21 18:05:52 +00:00

  • Status changed from New to Closed

I'll close this one as it has been left open only for discussion.

Cheers,
Thomas

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 22, 2016

Updated by tgelf on 2016-03-22 22:52:05 +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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.