Clean up deployment suffixes between pipeline build() calls

[jiaodong]

Why are these changes needed?

We generate new suffix to differentiate multiple instantiation of the same name with _1 _2 -- within same serve instance. For CLI it uses new serve instance upon every call so there's no issue, but for jupyter notebook equivalent this could be a bit annoying since our deployment name generator is at class level.

This PR makes name generation at instance level, and adds a simple cleanup / reset upon calling build() so we start with clean state for dag traversal when it's used in context manager.

Related issue number

Checks

• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[edoakes]

@jiaodong it seems to me that the DeploymentNameGenerator should only be relevant for a single DAG traversal, right? Shouldn't it just be scoped to that traversal instead of globally scoped? Then we don't need to worry about resetting at all.

[jiaodong]

That's indeed simpler. I was trying to avoid collision if user re-uses the same class multiple invocations within the same serve instance so it should generate new suffix, but i think in current @serve.deployment implementation we're also overwriting existing deployment with same class name so it's not introducing a new behavior. Let me make some changes.

[jiaodong]

Failed tests are related to tensorflow, tutorial_rllib, tutorial_tensorflow and documentation link checks, not related to this PR. Previous commit b5f9190 also had it all green.

[edoakes]

@jiaodong please update PR description.

[simon-mo]

Discussed offline. One solution could be just don't make DeploymentName generator a global singleton, rather just passed it into the transform_ray_dag as an instance.

[edoakes]

Looks great! I think we can further simplify by removing the locking logic now that it isn't a global singleton :)

[edoakes]

LGTM