如何从OpenStack Shade迁移至OpenStackSDK？迁移方案与工作量咨询

Hey there! I’ve tackled this exact migration a couple of times for internal automation tools, so I can give you a clear breakdown of the process and expected effort.

Migration Steps & Best Practices #

Let’s start with a structured approach to make the transition smooth:

1. Get Familiar with OpenStack SDK Basics #

Shade was actually a higher-level wrapper built on top of the OpenStack SDK, so many core concepts (like authentication, resource handling) will feel familiar. The key difference is that the SDK is more aligned with OpenStack’s native API structure—you’ll work directly with service-specific clients (e.g., compute, network, identity) instead of Shade’s unified OpenStackCloud object. Spend an hour or two exploring the SDK’s core modules to get comfortable with its pattern.

2. Replace Dependencies #

First, update your project’s requirements:

• Remove shade from your requirements.txt (or pyproject.toml)
• Add openstacksdk (stick to a stable, recent version—check the official release notes for compatibility with your target OpenStack cloud version)

3. Iterative Code Migration #

Break this down by functionality to avoid overwhelming yourself:

• Connection Initialization: Replace shade.openstack_cloud() with openstack.connect(). Most auth parameters (like auth_url, username, password, project_name) are the same, but the SDK makes auth method configuration more explicit (e.g., using auth_type for password vs. application credential auth).
  Example:

  # Shade
  cloud = shade.openstack_cloud(cloud='my-cloud')
  # SDK
  conn = openstack.connect(cloud='my-cloud')
  

• Resource Operations: Map Shade’s convenience methods to SDK’s service-specific methods. For example:
  • Shade’s create_server() → SDK’s conn.compute.create_server()
  • Shade’s list_networks() → SDK’s conn.network.networks()
    Note: The SDK may require more explicit parameters (Shade often used sensible defaults), so you’ll need to adjust arguments to match the SDK’s method signatures.
• Error Handling: Shade used a generic OpenStackCloudException, but the SDK provides granular exceptions (e.g., ResourceNotFound, Conflict, BadRequest). Update your try/except blocks to catch these specific exceptions where appropriate—this will make error handling more precise.
• Filtering & Querying: Shade’s filters parameter in list methods maps to keyword arguments in the SDK’s list methods. For example:

  # Shade
  servers = cloud.list_servers(filters={'status': 'ACTIVE'})
  # SDK
  servers = conn.compute.servers(status='ACTIVE')
  

4. Test Rigorously #

• Start with unit tests: Mock SDK calls to verify that your business logic still behaves as expected after the migration.
• Run integration tests in a non-production OpenStack environment: Validate end-to-end workflows (e.g., server provisioning, network setup) to catch any API compatibility issues.
• Migrate one feature at a time: Don’t rewrite everything at once—get one module working, test it thoroughly, then move to the next.

Estimated Workload #

The effort depends heavily on the size and complexity of your tool:

• Small Tools (<1k lines of core OpenStack interaction code, basic resource operations): 1–2 weeks. Most of the work will be replacing method calls, adjusting parameters, and updating tests.
• Medium Tools (1k–5k lines, multiple OpenStack services: compute, network, storage, identity): 3–6 weeks. You’ll need to handle more granular exception mapping, adapt custom Shade wrappers to the SDK’s structure, and validate cross-service workflows.
• Large Tools (>5k lines, complex business logic, custom Shade abstractions): 6–12+ weeks. Expect to refactor some parts of your code to align with the SDK’s service-centric model, and invest time in regression testing to avoid breaking existing functionality.

Key Notes to Avoid Headaches #

• Keep your business logic separate from OpenStack calls as much as possible—this makes migrations like this easier in the future.
• Check if your target OpenStack cloud uses any custom API extensions: The SDK supports most standard extensions, but you may need to adjust calls for vendor-specific features.
• If you’re using older Shade versions, some methods may have no direct 1:1 mapping—refer to the SDK’s migration notes (included in their docs) for edge cases.

内容的提问来源于stack exchange，提问作者GhostCat