Help writing custom modules

[Simon Weald]

I'm currently writing my own modules to interface with my DNS provider, but I'm running into some issues regarding some execution logic. The provider currently has the following structure for their records: zone < zone domain < zone domain record.

• zone is a container which logically holds all the domains and common DNS records
• zone domain is a domain name
  
• ex: test.com
  
• zone domain record is a DNS record which relates to that domain.
• A record for www with 1.2.3.4 would create a DNS entry for www..test.com

creation of these is easy using the create playbook here: https://gist.github.com/analbeard/cb5913abfc6101b4eef88674853f3c16

However deletion is problematic. If you use the delete playbook at that link, the first task will succeed and then the rest will fail due to to the fact that the zone deletion also removes everything inside the zone (domains and records). So, my question really is how would you expect that to function? I can see some ways around this.

• I could add a force flag to the zone module which will only remove a zone which is completely empty of domains/records if it isn't set tot true, however in which case how should I handle attempted deletion of a zone with contents but without force? Fail hard? Do nothing?
• I could allow the zone deletion to occur but then have the zone domain / zone record modules just pass successfully if the zone they're supposed to be in doesn't exist?

What would be the best approach to this?

[Kai Stian Olstad]

On Friday, 23 March 2018 15.43.59 CET Simon Weald wrote:
> creation of these is easy using the create playbook here:
> https://gist.github.com/analbeard/cb5913abfc6101b4eef88674853f3c16
>
>
> However deletion is problematic. If you use the delete playbook at that
> link, the first task will succeed and then the rest will fail due to to the
> fact that the zone deletion also removes everything inside the zone
> (domains and records). So, my question really is how would you expect that
> to function? I can see some ways around this.
>
>
>

> - I could add a force flag to the zone module which will only remove a

> zone which is completely empty of domains/records if it isn't set tot true,
> however in which case how should I handle attempted deletion of a zone with
> contents but without force? Fail hard? Do nothing?

It's a good idea to make sure the user don't shoot them self in the foot.
I think you should fail with return code 1 (or some other code), then the user could use failed_when: to ignore it like this

- name: delete zone
memset_zone
api_key: 0e0afa4165b141479ed07505991a223d
state: absent
name: testzone
register: result
failed_when: result.rc < 2


> - I could allow the zone deletion to occur but then have the zone domain

> / zone record modules just pass successfully if the zone they're supposed
> to be in doesn't exist?

This is the best solution, they are absent just like the user want and should be successful.


--
Kai Stian Olstad

[Kai Stian Olstad]

On Friday, 23 March 2018 17.29.08 CET Kai Stian Olstad wrote:
> On Friday, 23 March 2018 15.43.59 CET Simon Weald wrote:
> > creation of these is easy using the create playbook here:
> > https://gist.github.com/analbeard/cb5913abfc6101b4eef88674853f3c16
> >
> >
> > However deletion is problematic. If you use the delete playbook at that
> > link, the first task will succeed and then the rest will fail due to to the
> > fact that the zone deletion also removes everything inside the zone
> > (domains and records). So, my question really is how would you expect that
> > to function? I can see some ways around this.
> >
> >
> >
> > - I could add a force flag to the zone module which will only remove a
> > zone which is completely empty of domains/records if it isn't set tot true,
> > however in which case how should I handle attempted deletion of a zone with
> > contents but without force? Fail hard? Do nothing?
>
> It's a good idea to make sure the user don't shoot them self in the foot.
> I think you should fail with return code 1 (or some other code), then the user could use failed_when: to ignore it like this
>
> - name: delete zone
> memset_zone
> api_key: 0e0afa4165b141479ed07505991a223d
> state: absent
> name: testzone
> register: result
> failed_when: result.rc < 2

I made a little error there, to ignore it must be failed_when: result.rc > 1