DigitalOcean DNS entry on setting IP address

[nikochiko]

Set a DNS entry on DigitalOcean when user submits their IP address.

This may need some extending to the Form class, and allow for registering a submission handler by task/form name.

[anandology]

I don't think that should be the job of the form. The form should accept the inputs, validate and save it into the db.

The action post save, should probably be explicitly specified.

tasks:
  - name:  new-droplet
     ...
     form:
         ...
     actions:
         - action_add_dns

[nikochiko]

That makes sense. I agree on the point that actions should be explicitly specified in the YAML.

There are some questions that we'll have to answer:

• How do we handle the case when maker has supplied "actions" but no "form" for a task? My suggestion for now: raise an exception.
• Do we allow parameters for actions? My suggestion for now: no, not allowed.
• What are the default parameters that an action is called with? Maybe only site and task for now.

• How do we register actions? Maybe like this:

  from capstone.form import register_action
  
  @register_action
  def add_dns(site, task):
    form = task.form
    submitted_values = form.get_current_values(site)  # maybe site.get_form_values(form.name) instead
    ip = submitted_values["ip"]
    set_dns_entry(site.name, ip)

I think now we would have too many things to keep in our heads as a maker. We have core validators, form validators, and form types that the maker can register, and each has its own nuances (what are the default types? what arguments are needed for registering a validator? should form validators and core validators raise the same or different kind of error?). It may be time to start documenting all this, even for our own reference.

[nikochiko]

I think there might be a better alternative.

Can we make a core validator do this for us?

If we think about it as a task ("Input the IP address of your droplet"), it should be the validator's duty to see that the IP address is valid and give the user a go-ahead for next task. We would be stretching the scope of validators slightly by also setting the DNS entry, but we won't have to introduce new structures and complexity to get it done. What do you think?

[anandology]

Why is register_action coming from capstone.form?

Actions have nothing to do with forms. They take whatever is the current state, including the userdata and perform some action.

On Mon, Oct 31, 2022 at 1:06 PM Kaustubh Maske Patil < @.***> wrote:

That makes sense. I agree on the point that actions should be explicitly specified in the YAML.

There are some questions that we'll have to answer:

• How do we handle the case when maker has supplied "actions" but no "form" for a task? My suggestion for now: raise an exception.
• Do we allow parameters for actions? My suggestion for now: no, not allowed.
• What are the default parameters that an action is called with? Maybe only site and task for now.

• How do we register actions? Maybe like this:

  from capstone.form import register_action @register_actiondef add_dns(site, task): form = task.form submitted_values = form.get_current_values(site) # maybe site.get_form_values(form.name) instead ip = submitted_values["ip"] set_dns_entry(site.name, ip)

I think now we would have too many things to keep in our heads as a maker. We have core validators, form validators, and form types that the maker can register, and each has its own nuances (what are the default types? what arguments are needed for registering a validator? should form validators and core validators raise the same or different kind of error?). It may be time to start documenting all this, even for our own reference.

— Reply to this email directly, view it on GitHub https://github.com/pipalacademy/self-hosting-101/issues/7#issuecomment-1296706267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAB3ELUBYUT6DTUQXA4M3DWF5ZI3ANCNFSM6AAAAAARSQDJAU . You are receiving this because you commented.Message ID: @.***>

[anandology]

If we think about it as a task ("Input the IP address of your droplet"), it should be the validator's duty to see that the IP address is valid and give the user a go-ahead for next task. We would be stretching the scope of validators slightly by also setting the DNS entry, but we won't have to introduce new structures and complexity to get it done. What do you think?

No, we not bending any rules. Updating DNS is not part of the validation step. The actions are executed only after the validation is successful.

[nikochiko]

Hm, okay. So how would we define when actions are run?

Something like?

actions:
  - name: add_dns_droplet
    on: form.submit

or

actions:
  - add_dns_droplet:
      on: form.submit

Or is it always form.submit?

[anandology]

Actions will be run after the form submit and all the validations are successful.

[anandology]

No need to specify any on.

[nikochiko]

Sounds good.

[nikochiko]

Done. Added in https://github.com/pipalacademy/self-hosting-101/commit/3d55af132440358c65d167eca00d8c46bce130d3