[Serve] Optimize DeploymentDetails.deployment_route_prefix_not_set()

[JoshKarpel]

Why are these changes needed?

We've identified this method as a hotspot when the Serve Controller is tracking a lot of apps, taking ~5% of total time at 3k apps. Serializing the whole object to check if a field is set is unnecessary in both Pydantic v1 and v2... if you're willing to use a dunder field in v1 :)

After this change, this check takes no significant time.

Related issue number

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• 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 added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• 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 :(

This behavior didn't seem to be tested anywhere already, and it looks like it's just protecting a deprecation, so I didn't add a unit test, but I checked that it does have the desired behavior manually:

DeploymentDetails(
        name="foo",
        status=DeploymentStatus.HEALTHY,
        status_trigger=DeploymentStatusTrigger.UNSPECIFIED,
        message="m",
        deployment_config=DeploymentSchema(
            name="foo",
            route_prefix="/foo",
        ),
        target_num_replicas=1,
        replicas=[],
    )

pydantic.error_wrappers.ValidationError: 1 validation error for DeploymentDetails
deployment_config
  Unexpectedly found a deployment-level route_prefix in the deployment_config for deployment "foo". The route_prefix in deployment_config within DeploymentDetails should not be set; please set it at the application level. (type=value_error)

[JoshKarpel]

This was an unrelated bug - I suspect that either no one has ever hit this block, or they just accepted the AttributeError and figured out what was wrong some other way?

[zcin]

We need to support both pydantic v1 and v2. Could you import

from ray._private.pydantic_compat import IS_PYDANTIC_2

and also add support for pydantic 2?

[JoshKarpel]

If I understand

ray/python/ray/_private/pydantic_compat.py

Lines 55 to 57 in 4ae8128

	else:
	IS_PYDANTIC_2 = True
	from pydantic.v1 import (

correctly, it looks like when Pydantic v2 is installed, you're using the pydantic.v1 import to keep using the v1 API, so this call will be valid either way (I tested this code with Pydantic v2 installed and it worked as expected). But it would cause an issue when you switch to actually using Pydantic v2 models internally 🤔

... maybe this field will be fully deprecated by then and this validator will be deleted before the migration happens? 😁

[edoakes]

yea this should be fine because it's only touching our internal models

user models can be pydantic v2

[edoakes]

yea this should be fine because it's only touching our internal models

user models can be pydantic v2

[JoshKarpel]

Thanks!