You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When changing the infrastructure later down the road (i.e. adding another endpoint) the kickstart should be triggered again to deploy these changes. Came across this trying to setup a second master.
endpoints:
- name: NodeName
- name: secondnode.domain.net (and vice versa on the second node)
zones:
- name: ZoneName
endpoints:
- NodeName
- secondnode.domain.net
I see two possible trigger points at the moment using set_fact: TASK [icinga.icinga.icinga2 : feature api Endpoint objects type=Endpoint, args={{ idx }}]
is changed
or TASK [icinga.icinga.icinga2 : assemble config files src={{ item.path }}, dest={{ item.path |regex_replace('^'+icinga2_fragments_path, '/etc/icinga2') }}, delimiter= , owner={{ icinga2_user }}, group={{ icinga2_group }}, mode=420] ***
item path zones.conf is changed. Could be reused for api-users.conf because the director needs to be made aware of this change, right?
Additionally I have a question: Is it intended that the director is not deploying these changes (pending, has to be triggered manually) or simply out of scope of this collection?
The text was updated successfully, but these errors were encountered:
Hi, thanks for the issue. I see that changes on the zones should trigger a kickstart. As the roles are separated I need to check if we can fix this.
To your question, yes these pending changes should then deployed manually. After the kickstart the scope of the collections ends. But if you are interested you can check out the collection from telekom_mms. They wrote a bunch of ansible modules to control the director over it's api.
When changing the infrastructure later down the road (i.e. adding another endpoint) the kickstart should be triggered again to deploy these changes. Came across this trying to setup a second master.
i.e. changing from
to
I see two possible trigger points at the moment using set_fact:
TASK [icinga.icinga.icinga2 : feature api Endpoint objects type=Endpoint, args={{ idx }}]
is changed
or
TASK [icinga.icinga.icinga2 : assemble config files src={{ item.path }}, dest={{ item.path |regex_replace('^'+icinga2_fragments_path, '/etc/icinga2') }}, delimiter= , owner={{ icinga2_user }}, group={{ icinga2_group }}, mode=420] ***
item path zones.conf is changed. Could be reused for api-users.conf because the director needs to be made aware of this change, right?
Additionally I have a question: Is it intended that the director is not deploying these changes (pending, has to be triggered manually) or simply out of scope of this collection?
The text was updated successfully, but these errors were encountered: