无法获取图像详细信息：请求中提供的环境版本 Autosave_(date)T(time)Z_******** 与环境不匹配
在 AzureML Batchendpoint 上，我最近遇到以下错误：
Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ.
当我使用 yml 配置设置批处理端点时：
环境：azureml:env-name:env-version
因此，AzureML 使用我指定的版本创建和构建环境 env-version，这只是一个数字（在我的例子中 = 3）。
然后由于某种奇怪的原因，AzureML 创建了一个名为 Autosave_(date)T(time)Z_******** 的额外环境版本，该版本不是构建的，而是基于前一个环境版本刚刚创建，然后它成为该环境的最新版本。
总之，AzureML 不是寻找我指定为 env-name:3 的版本，而是似乎在寻找 env-name:Autosave_(date)T(time)Z_** ****** 然后抛出上面提到的错误信息。
On AzureML Batchendpoint, I'm recently hitting the following error:
Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ.
when I setup the batch-endpoint with a yml config:
environment: azureml:env-name:env-version
So, AzureML creates and builds the environment with the version I specify env-version, which is just a number (in my case = 3).
and then for some weird reason, AzureML creates an extra environment version called Autosave_(date)T(time)Z_********, which is not built, but based on the previous one just created, and then it becomes the latest version of that environment.
In summary, AzureML instead of looking for the version that I specified as env-name:3 it seems to be looking for env-name:Autosave_(date)T(time)Z_******** and then throws the error message mentioned above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我发现问题是，在从YAML规范文件中创建环境时，我的 conda依赖项之一是
cmake，我需要允许安装另一个Python模块。 Docker映像与以前创建的环境完全相同。从YAML文件中删除
cmake依赖关系，消除了问题。因此，解决方法是使用Dockerfile安装它。从环境定义从环境定义到 this
因此，因此，出于这个原因，自动创建了
autoSave Docker映像引用对同一构建的引用，仅在发送第一个作业时才发生一次。I found the problem was that when creating an environment from a YAML specification file, one of my conda dependencies was
cmake, which I needed to allow installation of another python module. The docker image is exactly the same as a previously created environment.Removing the
cmakedependency from the YAML file, eliminated the issue. So the workaround is to install it using a Dockerfile.The error message was very misleading to start with, but got there in the end after understanding that AzureML reuses a cached image, based on the hash value, from the environment definition accordingly to this
So for that reason, the automatically created
Autosavedocker image references to that same build, which only happens once when the first job is sent.