process: set publisher methods' max retry to 600s

[plamut]

Fixes#494.

PR checklist:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

[google-cla]

☹️ Sorry, but only Googlers may change the label cla: yes.

[tseaver]

This change, while expedient, is a bit ugly: the deadlines are emitted from this template, based on this method configuration in the googleapis repository.

If there is a general usecase for setting the deadlines to a higher multiple of the proto-repository-specified timeout, then we should have an issue open against gapic-generator-python to support it (and maybe we need additional configuration available in the service JSON config).

[plamut]

Yeah, the thing is that currently the same value is used for retry deadline and the default timeout, thus indeed a generator change would be required to support it.

I can check at the next Python libs weekly if this is something other libraries could use as well, or whether it's just something specific to Pub/Sub clients - @kamalaboulhosn do you maybe know from the top of your head?

[plamut]

Update: As discussed offline, we will go with this patchy version until it is decided where (and if) in the generator should this be changed.

[kamalaboulhosn]

Yeah, this does look a little hacky. I guess this is something that comes from the service config. @hongalex is this a config we can change in a single place that can be distributed to the repos so we don't to do these ad-hoc changes?

[plamut]

The problem here is that the gapic code generator currently uses the same setting for both the timeout and the retry deadline (method.timeout setting from here).

FWIW, it was agreed on the Python libs weekly yesterday that it needs to be investigated whether this is a quirk in the generator, or a lack of feature that would have to be implemented. Until then, the OwlBot replacement rule should be fine in order to not block this P1 change for too long.