auto deployment after sync is not working

This forum was archived to /woltlab and is now in read-only mode.

    Dear Icinga-community,

    --

    I use:

    Icinga2: 2.7.0-1

    Director: 1.3.2

    aws-module for Director: 0.0.1

    --


    I created an import and sync rule to identify new hosts in my AWS account. The sync rule has the policy "replace". The job has the policy to process any changes directly. In the background the icinga job 'icingacli director jobs run --forever' is running.


    Each time the sync rule recognized any changes to replace my configuration the changes are not automatically deployed by Icinga Director. Why Icinga Director is not automatically deployed the new imported changes?




    Thanks in advance for any help.


    Best, Ray

    The post was edited 1 time, last by ts2010 ().

    I dig deeper into the Director specification and the only way to solve this issue could be to initialize a cron job for each minute that start the following command on the Icinga2 host:


    Code
    1. icingacli director config deploy


    Would this be really the only solution or is it rather a bug in the sync functionality?

    Deploying that often also reloads Icinga 2 every time thus resulting in tcp sessions being reset. I don't think that you really want that to happen so often. I guess that is also the reason for the disabled deployment after a sync import.

    Maybe I did not express myself correctly. I created a sync rule with 'replace' and 'purge=yes' and I thought that each time the sync rule trigger to import new or deleted hosts to my template the changes will automatically deployed by Director (purge=yes). In my case Director shows me only that the config was changed but does not deploy the changes directly. I have to manually trigger the changes and I think this is not the point of the function. My second comment was only a workaround for me if there is a bug or a misunderstanding.

    I got that already. I tried to explain the point with the deployment pipeline here: First you collect all data, then import/sync them OR edit them via web interface, then you deploy them. I think the missing auto-deployment is sort of a safety hook, and the CLI command is the missing link for those who entirely want to automate the pipeline.


    Haven't it implemented myself though, just a thought comparing it with CI tools where you sometimes can't do auto-publishing before QA happened.

    Yes, I understand your point but in my case AWS create and delete hosts in a given name range dependent on the load / traffic and we don't know when. Therefore for me auto-deployment is necessary and it seems that I've misunderstood the parameter 'purge'.


    I think the cron job with the above mentioned CLI will not frequently restart the tcp sessions cause a positive sync happens in my case only one or two times per day. Even though I run the cron job every 5 minutes from my point of view the CLI first checking changes against the database and respond with 'Config matches active stage, nothing to do' without do anything. The disadvantage is, that you have take care each time you develop new structures in Icinga.

    It doesn't hurt asking to add a flag which could be set to trigger automated deployments over at Github. I'm a Director user myself, I haven't looked into it that deep yet. Everything which helps the users experience should at least be discussed with responsible developers imho.

    Hey all, I'm pretty sure if you want auto deployments you need to create a separate job of "Config" type.



    You also need a 'icingacli director jobs run --forever' running.



    https://github.com/Icinga/icin…lob/master/doc/79-Jobs.md pretty much explains it all except about creating the "Config" job. I was able to implement auto config deployments using what I've described. If you're using a systemd OS it should be easy to implement. Hope this helps.