సర్వీస్ కేటలాగ్ డేటా మోడల్ మరియు golden path టెంప్లేట్‌లను డిజైన్ చేయండి

పరిచయం

నిర్మాణాత్మక కేటలాగ్ లేనప్పుడు AI బృందాలు యాదృచ్ఛిక (ad-hoc) ప్రొవిజనింగ్‌కు మొగ్గు చూపుతాయని ఇంజనీర్లు తరచుగా గమనిస్తారు—GPU ఖర్చు నియంత్రణ లేకుండా పెరుగుతుంది, మోడల్ డిప్లాయ్‌మెంట్‌లు మానిటరింగ్ ఇన్‌స్ట్రుమెంటేషన్‌ను దాటవేస్తాయి, మరియు కనెక్షన్ స్ట్రింగ్‌లు డజన్ల కొద్దీ సర్వీసులలో హార్డ్‌కోడ్ చేయబడి, వాటి మధ్య ఎటువంటి ఆటోమేటెడ్ వైరింగ్ ఉండదు. గోల్డెన్ పాత్‌లతో జత చేసిన సర్వీస్ కేటలాగ్ ఈ సమస్యను పరిష్కరిస్తుంది—ధృవీకరించబడిన సర్వీసుల క్యూరేటెడ్ రిజిస్ట్రీని మరియు ముందుగా కంపోజ్ చేసిన వర్క్‌ఫ్లోలను బృందాలకు అందిస్తుంది, తద్వారా ప్లాట్‌ఫారమ్ నిర్ణయాలను మొదటి నుంచి తిరిగి కనిపెట్టకుండా వాటిని స్వీకరించవచ్చు. ఈ పాఠం ముగిసే సమయానికి, రిజిస్ట్రేషన్ సమయంలోనే గవర్నెన్స్ పాలసీలను అమలు చేసే కేటలాగ్ డేటా మోడల్‌ను డిజైన్ చేయగలరు, ఆ సర్వీసులను ఎండ్-టు-ఎండ్ AI వర్క్‌ఫ్లోలుగా కంపోజ్ చేసే గోల్డెన్ పాత్ స్టెప్ సీక్వెన్స్‌లను నిర్వచించగలరు, మరియు ప్రొవిజనింగ్ ఆర్కెస్ట్రేటర్ ప్లాట్‌ఫారమ్ కంట్రోల్ ప్లేన్ ద్వారా ఇంటర్-సర్వీస్ కాన్ఫిగరేషన్‌ను ఎలా స్వయంచాలకంగా ప్రచారం చేస్తుందో అర్థం చేసుకోగలరు.

కీలక పదజాలం

• Service Catalog: ప్లాట్‌ఫారమ్ అందించే సర్వీసుల క్యూరేటెడ్ రిజిస్ట్రీ; ప్రతి సర్వీసుకు దాని సామర్థ్యాలు, SLAలు, డిపెండెన్సీలు మరియు ప్రొవిజనింగ్ ఇంటర్‌ఫేస్‌ను వివరించే మెటాడేటా ఉంటుంది.
• Golden Path: ఒక నిర్దిష్ట వినియోగ సందర్భం కోసం అనేక కేటలాగ్ సర్వీసులను ఎండ్-టు-ఎండ్ పైప్‌లైన్‌గా కంపోజ్ చేసే, ముందుగా ధృవీకరించబడిన, నిర్దిష్ట అభిప్రాయంతో రూపొందించిన వర్క్‌ఫ్లో టెంప్లేట్.
• Service Template: ఒక నిర్దిష్ట సర్వీస్ ఇన్‌స్టాన్స్ కోసం ఇన్‌ఫ్రాస్ట్రక్చర్-యాజ్-కోడ్ మరియు కాన్ఫిగరేషన్‌ను ఉత్పత్తి చేసే పారామీటరైజ్డ్ బ్లూప్రింట్.
• Platform Control Plane: ప్లాట్‌ఫారమ్ అంతటా సర్వీస్ లైఫ్‌సైకిల్, కాన్ఫిగరేషన్ ప్రచారం మరియు హెల్త్ మానిటరింగ్‌ను నిర్వహించే APIలు మరియు కంట్రోలర్‌ల సమితి.
• Catalog Entry: కేటలాగ్‌లోని ఒకే సర్వీస్ నిర్వచనం; ఇందులో దాని స్కీమా, వెర్షన్ హిస్టరీ, ఓనర్‌షిప్ మెటాడేటా మరియు డిపెండెన్సీ గ్రాఫ్ ఉంటాయి.

భావనలు

ప్లాట్‌ఫారమ్ కాన్ఫిగరేషన్ మేనేజ్‌మెంట్‌కు అనుసంధానం

సర్వీస్ కేటలాగ్ మరియు గోల్డెన్ పాత్ రిజిస్ట్రీ ఒంటరిగా ఉండవు—అవి సంబంధిత ల్యాబ్ లక్ష్యంలో వివరించిన ప్లాట్‌ఫారమ్ కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సర్వీసుకు నేరుగా ఫీడ్ అవుతాయి. ప్రొవిజనింగ్ ఆర్కెస్ట్రేటర్ ఒక గోల్డెన్ పాత్ స్టెప్ నుంచి సర్వీసును డిప్లాయ్ చేసినప్పుడు, ఫలితంగా వచ్చిన కాన్ఫిగరేషన్‌ను (ఎండ్‌పాయింట్‌లు, క్రెడెన్షియల్ రిఫరెన్సులు, రిసోర్స్ కేటాయింపులు) Redis కాషింగ్‌తో PostgreSQLకు రాస్తుంది. గోల్డెన్ పాత్‌లోని తదుపరి సర్వీసులు తమ ముందున్న సర్వీసుల కాన్ఫిగరేషన్‌ను ఈ స్టోర్ నుంచి చదువుతాయి, ఇది ఆటోమేటిక్ వైరింగ్‌ను సాధ్యం చేస్తుంది.

ఉదాహరణకు, గోల్డెన్ పాత్ స్టెప్ 1లో వెక్టర్ డేటాబేస్‌ను ప్రొవిజన్ చేసినప్పుడు, ఆర్కెస్ట్రేటర్ డేటాబేస్ కనెక్షన్ స్ట్రింగ్ మరియు కలెక్షన్ స్కీమాను platform/team-alpha/vector-db/qdrant/connection వంటి నేమ్‌స్పేస్డ్ కీ కింద కాన్ఫిగరేషన్ స్టోర్‌కు రాస్తుంది. స్టెప్ 2 మోడల్ సర్వింగ్ ఎండ్‌పాయింట్‌ను ప్రొవిజన్ చేసినప్పుడు, సర్వింగ్ ఫ్రేమ్‌వర్క్ స్టార్టప్ కాన్ఫిగరేషన్ ఎంబెడ్డింగ్ లుకప్‌లను ఎక్కడికి పంపాలో తెలుసుకోవడానికి అదే కీని చదువుతుంది. ఈ నమూనా హార్డ్‌కోడ్ చేసిన కనెక్షన్ స్ట్రింగ్‌లను తొలగిస్తుంది మరియు కన్స్యూమర్ కోడ్‌లో మార్పులు అవసరం లేకుండానే ప్లాట్‌ఫారమ్ క్రెడెన్షియల్‌లను రొటేట్ చేయడానికి లేదా సర్వీసులను మైగ్రేట్ చేయడానికి వీలు కల్పిస్తుంది.

కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సర్వీస్, కేటలాగ్ లైఫ్‌సైకిల్ ఈవెంట్‌లకు మ్యాప్ అయ్యే కింది ఆపరేషన్‌లతో gRPC లేదా REST APIని బహిర్గతం చేయాలి:

• PUT /config/{namespace}/{service_id}/{key} — ప్రొవిజనింగ్ సమయంలో కాన్ఫిగరేషన్ విలువను రాస్తుంది, ఆటోమేటిక్ Redis కాష్ ఇన్‌వాలిడేషన్‌తో.
• GET /config/{namespace}/{service_id}/{key} — కాన్ఫిగరేషన్ విలువను చదువుతుంది; Redis కాష్ నుంచి సర్వ్ చేయబడి, PostgreSQL ఫాల్‌బ్యాక్‌తో ఉంటుంది.
• DELETE /config/{namespace}/{service_id} — డీకమిషన్ చేసిన సర్వీసుకు సంబంధించిన అన్ని కాన్ఫిగరేషన్‌ను తొలగిస్తుంది; గోల్డెన్ పాత్ స్టెప్ రోల్‌బ్యాక్ అయినప్పుడు ట్రిగ్గర్ అవుతుంది.
• LIST /config/{namespace} — ఒక బృందం నేమ్‌స్పేస్‌లో కాన్ఫిగర్ చేసిన అన్ని సర్వీసులను జాబితా చేస్తుంది; ప్లాట్‌ఫారమ్ హెల్త్ డాష్‌బోర్డ్‌లోని సర్వీస్ ఇన్వెంటరీ వీక్షణకు శక్తినిస్తుంది.

AI-నిర్దిష్ట గోల్డెన్ పాత్‌ల కోసం డిజైన్ సూత్రాలు

AI వర్క్‌ఫ్లోల కోసం గోల్డెన్ పాత్‌లను నిర్మించడానికి, సాంప్రదాయ మైక్రోసర్వీస్ ప్లాట్‌ఫారమ్‌లలో తలెత్తని అంశాలపై దృష్టి పెట్టాలి:

1. GPU లైఫ్‌సైకిల్ మేనేజ్‌మెంట్‌ను ఎన్‌కోడ్ చేయండి — GPU వర్క్‌లోడ్‌లను ప్రొవిజన్ చేసే ప్రతి గోల్డెన్ పాత్‌లో కోటా ధృవీకరణ, నోడ్ పూల్ ఎంపిక మరియు ఆటోమేటిక్ స్కేల్-డౌన్ పాలసీల కోసం స్టెప్‌లు ఉండాలి. కేటలాగ్ ఎంట్రీలోని GPURequirement మోడల్ డిక్లరేషన్‌ను తప్పనిసరి చేస్తుంది, కానీ ప్రొవిజనింగ్ ప్రారంభించడానికి ముందు టార్గెట్ క్లస్టర్‌లో తగినంత GPU సామర్థ్యం ఉందని గోల్డెన్ పాత్ కూడా ధృవీకరించాలి. సామర్థ్యం సరిపోకపోతే, డిప్లాయ్‌మెంట్ మధ్యలో విఫలమయ్యే బదులు, పాత్ కెపాసిటీ రిక్వెస్ట్ వర్క్‌ఫ్లోకు లింక్‌తో స్పష్టమైన ఎర్రర్‌ను తిరిగి ఇవ్వాలి.

2. ఇన్‌ఫ్రాస్ట్రక్చర్‌తో పాటు మోడల్ ఆర్టిఫ్యాక్ట్‌లను వెర్షన్ చేయండి — మోడల్ సర్వింగ్ కోసం గోల్డెన్ పాత్‌లు ప్రొవిజనింగ్ పారామీటర్లలో మోడల్ ఆర్టిఫ్యాక్ట్ వెర్షన్‌ను (ఉదా., నిర్దిష్ట రన్ IDతో ఉన్న MLflow మోడల్ URI) పిన్ చేయాలి. ఇది ఇన్‌ఫ్రాస్ట్రక్చర్ మరియు మోడల్ వెర్షన్‌లు అటామిక్‌గా డిప్లాయ్ అయి, కలిసి రోల్‌బ్యాక్ చేయగలవని నిర్ధారిస్తుంది. కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సర్వీస్ యొక్క PostgreSQL బ్యాకెండ్‌లో మోడల్ వెర్షన్‌ను నిల్వ చేయడం ద్వారా, ఏ మోడల్ వెర్షన్ ఏ ఇన్‌ఫ్రాస్ట్రక్చర్‌పై ఏ సమయంలో నడిచిందనే ఆడిట్ చేయగల చరిత్ర ఏర్పడుతుంది.

3. డిఫాల్ట్‌గా అబ్జర్వబిలిటీని చేర్చండి — ప్రతి గోల్డెన్ పాత్‌లో డిప్లాయ్ చేసిన సర్వీసుల కోసం Prometheus స్క్రేప్ టార్గెట్‌లు మరియు Grafana డాష్‌బోర్డ్ నిర్వచనాలను ప్రొవిజన్ చేసే మానిటరింగ్ స్టెప్ ఉండాలి. AI వర్క్‌లోడ్‌లకు రిక్వెస్ట్ లేటెన్సీకి మించిన ప్రత్యేక మెట్రిక్స్ అవసరం—టోకెన్ థ్రూపుట్, బ్యాచ్ క్యూ డెప్త్, GPU వినియోగ శాతం మరియు ఇన్ఫరెన్స్ డ్రిఫ్ట్ స్కోర్లు. మానిటరింగ్ స్టెప్ కేటలాగ్‌లోని MONITORING సర్వీస్ టైప్‌ను ఉపయోగించి, Grafana ఆపరేటర్ స్వయంచాలకంగా రీకన్సైల్ చేసే ముందుగా నిర్మించిన డాష్‌బోర్డ్ JSONను ఇంజెక్ట్ చేయాలి.

4. ఎక్స్‌పెరిమెంట్-నుంచి-ప్రొడక్షన్ ప్రమోషన్‌కు మద్దతు ఇవ్వండి — డేటా సైంటిస్టులు తరచుగా ఎక్స్‌పెరిమెంట్ ట్రాకింగ్ పరిసరాలలో మోడల్‌లను అభివృద్ధి చేస్తారు, మరియు ధృవీకరించబడిన ఎక్స్‌పెరిమెంట్‌ను ప్రొడక్షన్ సర్వింగ్ డిప్లాయ్‌మెంట్‌గా ప్రమోట్ చేయడానికి స్పష్టమైన మార్గం వారికి అవసరం. బాగా డిజైన్ చేసిన గోల్డెన్ పాత్ ఒక promote యాక్షన్‌ను అందిస్తుంది; అది ఫీచర్ స్టోర్ నుంచి ఎక్స్‌పెరిమెంట్ మెటాడేటాను చదివి, ప్లాట్‌ఫారమ్ యొక్క ప్రామాణిక కంటైనర్ ఇమేజ్ బిల్డర్‌ను ఉపయోగించి మోడల్‌ను ప్యాకేజ్ చేసి, అన్ని ప్రొడక్షన్ సర్వీసులకు ఉపయోగించే అదే ArgoCD పైప్‌లైన్ ద్వారా డిప్లాయ్ చేస్తుంది. ఇది చాలా ML ప్రాజెక్టులు నిలిచిపోవడానికి కారణమయ్యే ఎక్స్‌పెరిమెంటేషన్ మరియు ప్రొడక్షన్ మధ్య అంతరాన్ని తొలగిస్తుంది.

ఈ సూత్రాలు గోల్డెన్ పాత్‌లు కేవలం Helm చార్ట్‌ల చుట్టూ ఉన్న సౌలభ్య ర్యాపర్‌లు మాత్రమే కాకుండా, AI వర్క్‌లోడ్‌లను స్కేల్‌లో విశ్వసనీయంగా నడిపించడంపై ప్లాట్‌ఫారమ్ బృందం సేకరించిన కార్యాచరణ జ్ఞానాన్ని ఎన్‌కోడ్ చేస్తాయని నిర్ధారిస్తాయి. ప్రతి పాత్‌ను సెమాంటిక్ వెర్షనింగ్ ఉపయోగించి వెర్షన్ చేయాలి, ArgoCD పరిశీలించే Git రిపాజిటరీలో నిల్వ చేయాలి, మరియు డెవలపర్ పోర్టల్ కేటలాగ్‌లో ప్రచురించడానికి ముందు ప్లాట్‌ఫారమ్ యొక్క స్వంత CI పైప్‌లైన్ ద్వారా పరీక్షించాలి.

కోడ్ వాక్‌త్రూ

ServiceCatalogEntry, GoldenPathDefinition మరియు Platform Control Plane కోసం కీలక పదజాల నిర్వచనాల ఆధారంగా, కింది అమలు ఈ నిర్మాణాలను Pydantic మోడల్‌లుగా ఎన్‌కోడ్ చేస్తుంది; ఏదైనా సర్వీసును డిప్లాయ్ చేయడానికి ముందు ప్రొవిజనింగ్ ఆర్కెస్ట్రేటర్ వీటిని ధృవీకరిస్తుంది.

Code snippetpython
1from pydantic import BaseModel, Field, field_validator
2from enum import Enum
3from typing import Optional
4from datetime import datetime
5
6class ServiceType(str, Enum):
7    MODEL_SERVING = "model-serving"
8    TRAINING_JOB = "training-job"
9    VECTOR_DB = "vector-db"
10    FEATURE_STORE = "feature-store"
11    MONITORING = "monitoring"
12
13class GPURequirement(BaseModel):
14    gpu_type: str
15    min_count: int = Field(ge=0, default=0)
16    max_count: int = Field(ge=0, default=8)
17    memory_gb: int = Field(ge=0, default=40)
18
19class ServiceDependency(BaseModel):
20    service_id: str
21    version_constraint: str
22    optional: bool = False
23
24class ServiceCatalogEntry(BaseModel):
25    service_id: str = Field(min_length=3, max_length=64)
26    name: str
27    service_type: ServiceType
28    version: str = Field(pattern=r"^\d+\.\d+\.\d+$")
29    owner_team: str
30    description: str = Field(min_length=20)
31    gpu_requirements: Optional[GPURequirement] = None
32    dependencies: list[ServiceDependency] = Field(default_factory=list)
33    helm_chart_ref: Optional[str] = None
34    created_at: datetime = Field(default_factory=datetime.utcnow)
35    deprecated: bool = False
36
37    @field_validator("gpu_requirements")
38    @classmethod
39    def gpu_required_for_compute_services(cls, v, info):
40        stype = info.data.get("service_type")
41        gpu_types = {ServiceType.MODEL_SERVING, ServiceType.TRAINING_JOB}
42        if stype in gpu_types and v is None:
43            raise ValueError(f"gpu_requirements mandatory for {stype}")
44        return v

ServiceType ప్లాట్‌ఫారమ్ నియంత్రించే AI వర్క్‌లోడ్ వర్గాలను జాబితా చేస్తుంది; Kubernetes లేబుల్ సంప్రదాయాలకు అనుగుణంగా ఉండే kebab-case విలువలను ఉపయోగిస్తుంది. GPURequirement సబ్-మోడల్ ప్రతి ఎంట్రీపై స్పష్టమైన హార్డ్‌వేర్ డిక్లరేషన్‌లను తప్పనిసరి చేస్తుంది. ServiceCatalogEntryపై ఉన్న field_validator GPU అవసరాలను వదిలివేసిన ఏదైనా model-serving లేదా training-job ఎంట్రీని తిరస్కరిస్తుంది; డిప్లాయ్ సమయంలో కాకుండా స్కీమా ధృవీకరణ సమయంలోనే ఖర్చు గవర్నెన్స్‌ను అమలు చేస్తుంది—ప్రణాళిక లేని GPU కేటాయింపులు బడ్జెట్ మించిపోవడానికి కారణమయ్యే ప్లాట్‌ఫారమ్‌లకు ఇది కీలకమైన పాలసీ.

ఆర్కెస్ట్రేటర్ ప్రతి గోల్డెన్ పాత్ స్టెప్‌ను ప్రొవిజన్ చేసినప్పుడు, ఫలితంగా వచ్చిన కనెక్షన్ వివరాలను కాన్ఫిగరేషన్ స్టోర్‌కు రాస్తుంది, తద్వారా డౌన్‌స్ట్రీమ్ స్టెప్‌లు వాటిని స్వయంచాలకంగా కనుగొనగలవు మరియు హార్డ్‌కోడ్ చేసిన స్ట్రింగ్‌లు తొలగిపోతాయి. కింది హెల్పర్‌లు భావనలు విభాగంలో వివరించిన PUT మరియు GET ఆపరేషన్‌లను అమలు చేస్తాయి:

Code snippetpython
1import httpx
2
3def write_service_config(
4    namespace: str,
5    service_id: str,
6    key: str,
7    value: str,
8    config_api_base: str = "http://platform-config:8080",
9) -> None:
10    """Write a provisioned service's config for downstream golden path steps."""
11    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
12    response = httpx.put(url, json={"value": value}, timeout=10.0)
13    response.raise_for_status()
14
15def read_service_config(
16    namespace: str,
17    service_id: str,
18    key: str,
19    config_api_base: str = "http://platform-config:8080",
20) -> str:
21    """Read a predecessor step's config during golden path provisioning."""
22    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
23    response = httpx.get(url, timeout=10.0)
24    response.raise_for_status()
25    return response.json()["value"]

వెక్టర్ డేటాబేస్ స్టెప్ పూర్తయిన తర్వాత, ఆర్కెస్ట్రేటర్ write_service_config("team-alpha", "vector-db/qdrant", "connection", connection_string)ను కాల్ చేస్తుంది. ఆపై మోడల్-సర్వింగ్ స్టెప్ ఎండ్‌పాయింట్‌ను కనుగొనడానికి read_service_config("team-alpha", "vector-db/qdrant", "connection")ను కాల్ చేస్తుంది—ఇది భావనలు విభాగంలో వివరించిన నేమ్‌స్పేస్డ్ కీ నమూనాకు సరిపోలుతుంది మరియు కన్స్యూమర్ కోడ్ మార్పులు లేకుండానే ఆటోమేటిక్ క్రెడెన్షియల్ రొటేషన్‌ను సాధ్యం చేస్తుంది.

service_type=ServiceType.MODEL_SERVING మరియు gpu_requirements=Noneతో ఒక ServiceCatalogEntryని ఇన్‌స్టాన్షియేట్ చేసి ధృవీకరించండి—వాలిడేటర్ ValueErrorను రైజ్ చేయాలి; ఇది ఏ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను తాకడానికి ముందే, కేటలాగ్ రిజిస్ట్రేషన్ సమయంలోనే గవర్నెన్స్ పాలసీ అమలవుతుందని నిర్ధారిస్తుంది.

విభాగ అనువర్తనం

చేయవలసినవి మరియు చేయకూడనివి

కేటలాగ్ మోడల్, గోల్డెన్ పాత్ కాన్ఫిగరేషన్ ప్రచారం మరియు పైన ఉన్న విభాగ-నిర్దిష్ట అనువర్తనం ద్వారా నడిచిన తర్వాత, కింది సూచనలు గవర్నెన్స్ మరియు వైరింగ్ నమూనాలను మీ స్వంత కేటలాగ్ ఎంట్రీలు మరియు గోల్డెన్ పాత్‌లను డిజైన్ చేసేటప్పుడు నేరుగా వర్తింపజేయగల నియమాలుగా సంక్షిప్తం చేస్తాయి.

చేయవలసినవి

1. ప్రతి model-serving మరియు training-job కేటలాగ్ ఎంట్రీపై gpu_requirementsను డిక్లేర్ చేయండి — gpu_requirements None అయినప్పుడు ServiceCatalogEntryపై ఉన్న field_validator ఈ సర్వీస్ టైప్‌లను తిరస్కరిస్తుంది; ఏ ఇన్‌ఫ్రాస్ట్రక్చర్ ప్రొవిజన్ కావడానికి ముందే స్కీమా ధృవీకరణ సమయంలో ఖర్చు గవర్నెన్స్‌ను అమలు చేసి, ప్రణాళిక లేని GPU బడ్జెట్ అతిక్రమణలను నివారిస్తుంది.
2. స్థిరమైన నేమ్‌స్పేస్డ్ కీ నమూనాతో (ఉదా., "team-alpha" / "vector-db/qdrant" / "connection") write_service_config / read_service_configను ఉపయోగించండి — ఇది సర్వీసుల అంతటా కనెక్షన్ స్ట్రింగ్‌లను హార్డ్‌కోడ్ చేసే బదులు, ప్రతి గోల్డెన్ పాత్ స్టెప్ ముందున్న స్టెప్‌ల అవుట్‌పుట్‌లను ప్లాట్‌ఫారమ్ కంట్రోల్ ప్లేన్ నుంచి స్వయంచాలకంగా కనుగొనేలా చేస్తుంది.
3. semverకు పరిమితం చేసిన version ఫీల్డ్ (^\d+\.\d+\.\d+$) మరియు deprecated ఫ్లాగ్‌తో కేటలాగ్ ఎంట్రీలను మోడల్ చేయండి — ఎంట్రీలను వెర్షన్ చేసి, డిప్రికేషన్-అవగాహనతో ఉంచడం ద్వారా ఆర్కెస్ట్రేటర్ ServiceDependency.version_constraint తనిఖీలను అమలు చేయగలదు, మరియు ఇప్పటికే ఉన్న గోల్డెన్ పాత్ స్టెప్ సీక్వెన్స్‌లను విచ్ఛిన్నం చేయకుండా బృందాలకు మైగ్రేషన్ మార్గాన్ని అందిస్తుంది.

చేయకూడనివి

1. gpu_requirementsను వదిలివేసి, ఆర్కెస్ట్రేటర్ డిఫాల్ట్‌లను అందిస్తుందని అనుకోవద్దు — ServiceType.MODEL_SERVING మరియు ServiceType.TRAINING_JOB కోసం GPURequirement తప్పనిసరి సబ్-మోడల్; దాన్ని దాటవేస్తే రిజిస్ట్రేషన్ సమయంలో ValueError రైజ్ అవుతుంది, మరియు ప్లాట్‌ఫారమ్ డిఫాల్ట్‌లపై నిశ్శబ్దంగా ఆధారపడటం అనేది కేటలాగ్ తొలగించడానికి రూపొందించిన యాదృచ్ఛిక ప్రొవిజనింగ్ నమూనా ఖచ్చితంగా అదే.
2. గోల్డెన్ పాత్ స్టెప్ కోడ్‌లో కనెక్షన్ స్ట్రింగ్‌లను హార్డ్‌కోడ్ చేయవద్దు — write_service_config / read_service_configను దాటవేయడం ఆటోమేటిక్ క్రెడెన్షియల్-ప్రచార ఒప్పందాన్ని విచ్ఛిన్నం చేస్తుంది; అంటే ఎండ్‌పాయింట్ మార్పులకు (క్రెడెన్షియల్ రొటేషన్‌లతో సహా) ఒకే కాన్ఫిగ్-స్టోర్ రైట్ బదులు, వినియోగించే ప్రతి సర్వీసులో మాన్యువల్ అప్‌డేట్‌లు అవసరమవుతాయి.
3. ServiceType enum వెలుపల ఉన్న యాదృచ్ఛిక service_type స్ట్రింగ్ కింద కొత్త AI వర్క్‌లోడ్‌ను రిజిస్టర్ చేయవద్దు — enum యొక్క kebab-case విలువలు (model-serving, vector-db, మొదలైనవి) Kubernetes లేబుల్ సంప్రదాయాలకు అనుగుణంగా ఉంటాయి, మరియు గవర్నెన్స్ వాలిడేటర్ మరియు GPU-అవసరాల తనిఖీ బ్రాంచ్ అయ్యే కీలు ఇవే; గుర్తించబడని టైప్ field_validatorను మరియు ఆర్కెస్ట్రేటర్ రిసోర్స్-కోటా లాజిక్‌ను రెండింటినీ దాటవేస్తుంది.