OpenStackClient

osc 是用 Rust 编写的 OpenStack 命令行界面。它依赖于相应的 openstack_sdk crate（库）并使用 OpenAPI 规范生成。这意味着与完全由人类编写的 python-openstackclient 相比，该工具的维护工作量要小得多。由于是自动生成的，因此与 python cli 存在某些差异，但同时也强制执行 UX 一致性。

注意：作为一个新的工具，它试图解决与原始 python-openstackclient 的一些问题。这意味着它无法提供无缝迁移到另一个工具。

特性

• 命令实现代码由 (codegenerator)https://opendev.org/openstack/codegenerator 生成，这意味着不需要维护该代码。
• osc api 作为 API 包装器，允许用户执行任何直接 API 调用，指定服务类型、URL、方法和有效负载。例如，当某些资源当前未本地实现时，可以使用此功能。
• osc auth 具有子命令，用于明确处理身份验证（显示当前身份验证信息、续订身份验证、MFA/SSO 支持）
• 每个资源在命令中都有一个服务类型，以解决用户组与卷组等混淆
• 每个多词资源名称由破折号分隔（例如：floating-ip、access-rule）

输出

• osc ... -o json 作为明确的机器可读格式输出。它允许查看 API 发送的原始资源 JSON 表示，而不进行任何客户端处理。注意：结果是原始 JSON 响应，但找到在预期资源键下方的原始 JSON 资源信息。此模式可以用于查看 osc 不期望的字段，并允许使用类似 jq 的工具进行进一步简单的机器处理。
• osc ... -o wide 用于列表操作以返回所有已知字段。默认情况下，列表操作将只返回已知通用资源字段的子集，以防止多行表格。此模式（与不指定 -o 参数）被视为面向人类的输出。字段名称通常不会被重命名，而是按API返回的名称命名。

微版本

最初，python-openstackclient 除非传递了指定微版本的额外参数，否则使用最低微版本。后来，在切换到使用 OpenStackSDK 的命令期间，开始使用尽可能高的微版本（除非用户明确请求微版本，使用 --XXX-api-version Y.Z）。这两种方法的一个共同点是通过让用户控制版本来保证稳定性。这两种方法的缺点是它们带有某些观点，这些观点不一定符合用户的期望，并且使得对将要发生什么的预期变得复杂。对于最终用户来说，在出现、消失和以不同类型重新出现某些参数时，阅读命令的帮助页面非常复杂且容易出错。在这种情况下，实现（和使用）命令也是既复杂又容易出错的。

osc 试图取两种方法的最佳之处，并为微版本提供专门的命令（例如，create20，create294）。最新的微版本命令始终有一个通用别名（如上面的 create），以便用户明确使用最新的微版本，但这并不能保证它可以与请求的参数一起调用。这种方法使用户能够非常明确地表达要求，并保证预期的参数。当需要更新的微版本时，用户应明确进行“迁移”步骤，以将调用适配到一组新的参数。通过这种方式，微版本（或功能）的弃用也变得简单得多，并且通过标记整个命令为弃用或完全删除来处理。

Shell 自动完成

osc 支持为各种 shell 生成完成文件。这可以通过执行以下操作启用：

echo 'source <(osc completion bash)' >>~/.bashrc