ray.serve.schema.ApplicationDetails#

pydantic model ray.serve.schema.ApplicationDetails[source]#

Detailed info about a Serve application.

field deployed_app_config: ServeApplicationSchema | None = None#

The exact copy of the application config that was submitted to the cluster. This will include all of, and only, the options that were explicitly specified in the submitted config. Default values for unspecified options will not be displayed, and deployments that are part of the application but unlisted in the config will also not be displayed. Note that default values for unspecified options are applied to the cluster under the hood, and deployments that were unlisted will still be deployed. This config simply avoids cluttering with unspecified fields for readability.

field deployment_topology: DeploymentTopology | None = None#

The deployment topology showing how deployments in this application call each other.

field deployments: Dict[str, DeploymentDetails] [Required]#

Details about the deployments in this application.

field docs_path: str | None [Required]#

The path at which the docs for this application is served, for instance the docs_url for FastAPI-integrated applications.

field external_scaler_enabled: bool [Required]#

Whether external scaling is enabled for this application.

field last_deployed_time_s: float [Required]#

The time at which the application was deployed.

field message: str [Required]#

A message that gives more insight into the application status.

field name: str [Required]#

Application name.

field route_prefix: str | None [Required]#

This is the route_prefix of the ingress deployment in the application. Requests to paths under this HTTP path prefix will be routed to this application. This value may be null if the application is deploying and app information has not yet fully propagated in the backend; or if the user explicitly set the prefix to None, so the application isn’t exposed over HTTP. Routing is done based on longest-prefix match, so if you have deployment A with a prefix of “/a” and deployment B with a prefix of “/a/b”, requests to “/a”, “/a/”, and “/a/c” go to A and requests to “/a/b”, “/a/b/”, and “/a/b/c” go to B. Routes must not end with a “/” unless they’re the root (just “/”), which acts as a catch-all.

field source: APIType [Required]#

The type of API that the application originates from. This is a Developer API that is subject to change.

field status: ApplicationStatus [Required]#

The current status of the application.

validator application_details_route_prefix_format  »  route_prefix[source]#