Fix problem when adding endpoint through API

[pm426]

Adding endpoint through API would cause exception. Zone objects can be created through API without specifying 'endpoints' attribute. This change, in order to allow Endpoint objects to be added through API, makes use of Endpoint 'zone' attribute to first establish Endpoint <-> Zone relationship and then set its value to proper zone. In other words, Endpoint 'zone' attribute value is initially used to add the Endpoint to Zone with specified name (ie: Endpoint is now part of Zones 'endpoints'). Once Endpoint is added to Zone, the value of Endpoints 'zone' attribute is set to its Zone 'parent'. This way. Endpoints (and zones) can be added to master (for use on master) or through master to configure satellite(s).

Here is an example when following conditions are met:

• master: has master zone/endpoint, does not know about the satellite or client
• satellite: has satellite zone/endpoint and master zone/endpoint
• client: has satellite zone/endpoint and client zone/endpoint (no master)

• Add satellite (or client) on master:

curl -k -s -u $USER:$PASSWD --request PUT \
  --url https://master:5665/v1/objects/zones/satellite \
  --header 'accept: application/json' \
  --data '{"attrs": {"__name": "satellite", "parent": "master"}}'

curl -k -s -u $USER:$PASSWD --request PUT \
  --url https://master:5665/v1/objects/endpoints/satellite1 \
  --header 'accept: application/json' \
  --data '{"attrs": {"__name": "satellite1", "host": "satellite1", "port": "5665", "zone": "satellite"}}'

Node that Endpoint 'satellite1' zone attribute value is set to 'satellite' and not 'master'. The Endpoint itself will be added to Zone 'satellite' as its endpoint. Internally, Endpoint zone value will be set to 'master' (its zones parent) where it is meant to reside.

• Add client zone and endpoint(s) to satellite through master:

curl -k -s -u $USER:$PASSWD --request PUT \
  --url https://master:5665/v1/objects/zones/client \
  --header 'accept: application/json' \
  --data '{"attrs": {"__name": "client", "parent": "satellite", "zone": "satellite"}}'

curl -k -s -u $USER:$PASSWD --request PUT \
  --url https://master:5665/v1/objects/endpoints/client1 \
  --header 'accept: application/json' \
  --data '{"attrs": {"__name": "client1", "host": "client1", "port": "5665", "zone": "client"}}'

Again, Endpoint 'client1' zone value is set to 'client' and not 'satellite' (it will be added to Zone 'client' as its endpoint). Internally, this value will be set to 'satellite' where sync() is supposed to send it to.

• Add more clients to 'client' zone which will configure satellite 'satellite1':

curl -k -s -u $USER:$PASSWD --request PUT \
  --url https://master:5665/v1/objects/endpoints/client2 \
  --header 'accept: application/json' \
  --data '{"attrs": {"__name": "client2", "host": "client2", "port": "5665", "zone": "client"}}'

refs #3823

[dnsmichi]

Thanks a lot 👍 I do have a similar patch set in my local stash, will review this PR soon.

[dnsmichi]

I'm waiting for more changes inside the cluster, this requires more time unfortunately.

[Woytek-Polnik]

any update ?

[dnsmichi]

When I am done with #6716 I can tell you more. This has a direct influence.

[dnsmichi]

@Al2Klimov Please evaluate whether this can be added.

[Al2Klimov]

Haven't we added packages for exactly that?

[Al2Klimov]

There are three groups of Icinga users:

• Director users
• VIm users
• API users

Only the API users who manage zones/endpoints via the API too have trouble. But IMAO one shall manage them via Director/VIm and not like this.

@N-o-X Do you agree with me?

[N-o-X]

@Al2Klimov I agree with you on that best practice point. But I can still see cases in which you might not want to use the Director or the DSL (e.g own self service system). I think we should make sure that the things we allow users to do via the API, just work.

[dnsmichi]

Keep in mind that Endpoint/Zone objects a special configuration types. With the recent "zone in zone" problem we have learned that additional dependencies apply:

• Create a zone via REST API
• Should we now automatically run zones.d inclusion from the config compiler stage again?

Another thing:

• Add an Endpoint via REST API
• How are we dealing with reconnects and additional trust relationships?

Imho the first example with the cluster config sync is a no-go for allowing this feature being merged. With implementing the stages for the sync in 2.11, I thought it would be possible. With the problems encountered for zone inception, this moves this discussion to another layer.

The same problem is with re-evaluating apply rules after creating host objects at runtime in #4084. There is no clear designed way to make this transaction/rollback safe at the moment.

I'd rather propose to remove the endpoint/zone type PUT/POST method from the API and document this accordingly. This follows the same design principle as with templates where we also only allow GET requests.

[BTT-Nick]

Will this be fixed in near future? We have the same problem with creating windows hosts via API.

Should we create a config-package for each host? (approx. >200) also if we add/delete a host do we need to purge the created config-package?

[julianbrost]

Please rebase.

Do you consider the PR fine otherwise?

[Al2Klimov]

Fine? I've opted against it!

[julianbrost]

What's the point of asking for a rebase if it's not even clear if we even want to do it this way?

[Al2Klimov]

Should we create a config-package for each host? (approx. >200) also if we add/delete a host do we need to purge the created config-package?

That's how @LordHepipud is doing it on NWS, IIRC.

[Al2Klimov]

@cla-bot check

[cla-bot[bot]]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @pm426

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.