You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/machine-learning/how-to-migrate-from-v1.md
+25-2Lines changed: 25 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.subservice: core
8
8
ms.topic: how-to
9
9
author: s-polly
10
10
ms.author: scottpolly
11
-
ms.date: 06/01/2022
11
+
ms.date: 09/23/2022
12
12
ms.reviewer: blackmist
13
13
ms.custom: devx-track-azurecli, devplatv2
14
14
---
@@ -84,11 +84,14 @@ Do consider migrating the code for creating a workspace to v2. Typically Azure r
84
84
> [!IMPORTANT]
85
85
> If your workspace uses a private endpoint, it will automatically have the `v1_legacy_mode` flag enabled, preventing usage of v2 APIs. See [how to configure network isolation with v2](how-to-configure-network-isolation-with-v2.md) for details.
86
86
87
+
87
88
### Connection (workspace connection in v1)
88
89
89
90
Workspace connections from v1 are persisted on the workspace, and fully available with v2.
90
91
91
92
We recommend migrating the code for creating connections to v2.
93
+
For a comparison of SDK v1 and v2 code, see [Migrate workspace management from SDK v1 to SDK v2](migrate-to-v2-resource-workspace.md).
94
+
92
95
93
96
### Datastore
94
97
@@ -114,6 +117,8 @@ You can continue using your existing v1 model deployments. For new model deploym
114
117
|Azure Kubernetes Service (AKS)|ACI, AKS|Manage your own AKS cluster(s) for model deployment, giving flexibility and granular control at the cost of IT overhead.|
115
118
|Azure Arc Kubernetes|N/A|Manage your own Kubernetes cluster(s) in other clouds or on-premises, giving flexibility and granular control at the cost of IT overhead.|
116
119
120
+
For a comparison of SDK v1 and v2 code, see [Migrate deployment endpoints from SDK v1 to SDK v2](migrate-to-v2-deploy-endpoints.md).
121
+
117
122
### Jobs (experiments, runs, pipelines in v1)
118
123
119
124
In v2, "experiments", "runs", and "pipelines" are consolidated into jobs. A job has a type. Most jobs are `command` jobs that run a command, like `python main.py`. What runs in a job is agnostic to any programming language, so you can run `bash` scripts, invoke `python` interpreters, run a bunch of `curl` commands, or anything else. Another common type of job is `pipeline`, which defines child jobs that may have input/output relationships, forming a directed acyclic graph (DAG).
@@ -126,6 +131,8 @@ What you run *within* the job does not need to be migrated to v2. However, it is
126
131
127
132
We recommend migrating the code for creating jobs to v2. You can see [how to train models with the CLI (v2)](how-to-train-cli.md) and the [job YAML references](reference-yaml-job-command.md) for authoring jobs in v2 YAMLs.
128
133
134
+
For a comparison of SDK v1 and v2 code, see [Migrate script run from SDK v1 to SDK v2](migrate-to-v2-command-job.md).
135
+
129
136
### Data (datasets in v1)
130
137
131
138
Datasets are renamed to data assets. Interoperability between v1 datasets and v2 data assets is the most complex of any entity in Azure ML.
@@ -136,18 +143,34 @@ For details on data in v2, see the [data concept article](concept-data.md).
136
143
137
144
We recommend migrating the code for [creating data assets](how-to-create-data-assets.md) to v2.
138
145
146
+
For a comparison of SDK v1 and v2 code, see [Migrate data management from SDK v1 to v2](migrate-to-v2-assets-data.md).
147
+
148
+
139
149
### Model
140
150
141
151
Models created from v1 can be used in v2. In v2, explicit model types are introduced. Similar to data assets, it may be easier to re-create a v1 model as a v2 model, setting the type appropriately.
142
152
143
153
We recommend migrating the code for creating models with [SDK](how-to-train-sdk.md) or [CLI](how-to-train-cli.md) to v2.
144
154
155
+
For a comparison of SDK v1 and v2 code, see
156
+
157
+
*[Migrate model management from SDK v1 to SDK v2](migrate-to-v2-assets-model.md)
158
+
*[Migrate AutoML from SDK v1 to SDK v2](migrate-to-v2-execution-automl.md)
159
+
*[Migrate hyperparameter tuning from SDK v1 to SDK v2](migrate-to-v2-execution-hyperdrive.md)
160
+
*[Migrate parallel run step from SDK v1 to SDK v2](migrate-to-v2-execution-parallel-run-step.md)
161
+
145
162
### Environment
146
163
147
164
Environments created from v1 can be used in v2. In v2, environments have new features like creation from a local Docker context.
148
165
149
166
We recommend migrating the code for creating environments to v2.
150
167
168
+
## Managing secrets
169
+
170
+
The management of Key Vault secrets differs significantly in V2 compared to V1. The V1 set_secret and get_secret SDK methods are not available in V2. Instead, direct access using Key Vault client libraries should be used.
171
+
172
+
For details about Key Vault, see [Use authentication credential secrets in Azure Machine Learning training jobs](how-to-use-secrets-in-runs.md).
173
+
151
174
## Scenarios across the machine learning lifecycle
152
175
153
176
There are a few scenarios that are common across the machine learning lifecycle using Azure ML. We'll look at a few and give general recommendations for migrating to v2.
@@ -182,7 +205,7 @@ A MLOps workflow typically involves CI/CD through an external tool. It's recomme
182
205
183
206
The solution accelerator for MLOps with v2 is being developed at https://github.com/Azure/mlops-v2 and can be used as reference or adopted for setup and automation of the machine learning lifecycle.
184
207
185
-
####A note on GitOps with v2
208
+
### A note on GitOps with v2
186
209
187
210
A key paradigm with v2 is serializing machine learning entities as YAML files for source control with `git`, enabling better GitOps approaches than were possible with v1. For instance, you could enforce policy by which only a service principal used in CI/CD pipelines can create/update/delete some or all entities, ensuring changes go through a governed process like pull requests with required reviewers. Since the files in source control are YAML, they're easy to diff and track changes over time. You and your team may consider shifting to this paradigm as you migrate to v2.
0 commit comments