Create functional class for DNS ChangeRequest

[mziccard]

If this has been already discussed I am sorry for bringing it up again.

A DNS change request is now mapped using a single non-functional class ChangeRequest. I see a benefit in having a functional class for change requests as well. It would be cool to be able to write:

ChangeRequest change = dns.applyChangeRequest(ChangeRequestInfo.builder...);
while (!change. isDone()) {
  Thread.sleep (1000L);
}
// change request is DONE

In the same way we do for bigquery's jobs and as I plan to do with compute's operations. What do you think?

[aozarov]

We could (I do not object), however I think in this case it would be much less useful (at least for now) as:

• The proposed ChangeRequest will not have any other additional methods other than isDone.
• isDone is much less useful as, there are no obvious actions to take when true (as opposed to BigQuery that you may want to query after a successful upload job).
• I could not find any time commitment/expectation for how long such operation may take.

[aozarov]

I managed to find this for propagation time expectation: "You can use this command determine when your authoritative name server picks up your change, which should happen within 120 seconds"

[mziccard]

We could add also reload but I agree that's almost the same as isDone in terms of usage.

You might be interested in the change to be completed to start redirecting traffic or start using records that the change request just created.

[mderka]

I think this goes against our decision to make change request a zone-independent struct. Since changes always happen inside zones, you would need dns.applyChangeRequest(zone, ChangeRequestInfo.builder...); in which case you can right away query done on the zone object. Otherwise, we would need to equip ChangeRequest with zone reference.

[mziccard]

Adding zone to ChangeRequest doesn't seem absurd to me. If you want to keep it independent from the user perspective the zone reference could be added as a private field in the functional object, without the user even knowing.

[mderka]

As per my discussion with @aozarov, a suitable way of handling this would be treating ChangeRequestInfo as zone-independent struct and functional object having zone. We do see value in this, but we also agreed that there are more urgent things to handle. I am assigning this to myself and categorizing as "yes, do it if you have time at the end."

[mderka]

Before closing this, add isDone() and reload().

[aozarov]

Also, I find the ChangeRequest.applyTo method strange for various reasons:

1. As user can't create ChangeRequest it means that it was returned by a get or list mehods and hence
   suggests that it was already applied, no?

2. If we think there is a reason for re-applying it maybe it should be called reapply?

3. If the intent was to apply it on a different zone (hence the name applyTo?) then we should pass a zone as an argument.

/cc @mziccard @mderka

[mderka]

1. Correct.
2. No, the intention was (3).
3. Correct. Changing the signature.