Skip to content
This repository has been archived by the owner on Sep 12, 2022. It is now read-only.

Blueprint for Atmosphere(2) script, "application_to_provider.py"

Jump to bottom
Chris Martin edited this page Mar 1, 2017 · 28 revisions

Use case: Adding a provider to Atmosphere(1) deployment, need to make applications available on the new provider.

This script will accomplish that. Handles population of image data and metadata. Takes an application ID and a provider ID as input.

Procedure

For each ApplicationVersion of the specified application:

  • Copy the Glance image to new provider (see Image copy process below)
  • Create a ProviderMachine and an InstanceSource for that ApplicationVersion, populating InstanceSource.identifier with the Glance image ID

Image copy process

  • Get image from existing cloud
    • Get metadata (all properties, container_format, disk_format, is_public, name, owner, members)
    • Look up usernames of owner and members, from existing cloud or from Atmosphere DB?
    • Get location
  • Put image on new cloud
    • Create new image
    • Look up user IDs of owner and members (we already know usernames)
    • Set metadata (all properties, container_format, disk_format, is_public, name, owner, members)
    • Set
  • Transfer image to new storage location
    • Option 1 using glance client:
      • (simple way that doesn't violate abstractions but xfers more data)
      • Download image from existing provider
      • Upload image to new provider
    • Option 2 using Python iRODS client:
      • (Requires Atmosphere(1) to know about how images are stored in iRODS, but will be faster)
      • Derive iRODS path from glance location
      • icp file to iRODS collection for new provider
      • Set irods:// URI location for image in glance

Conversation with Steve 2017-02-27

  • Steve interested in using iRODS copy to skip glance download/upload, for clouds with iRODS-backed glance. download/upload not only takes longer, has been less reliable with many GBs of image data over HTTPS.

  • Regarding private images and owners/members:

    • In order for private images to work on a new provider, both image ownership and membership must also transfer. Must determine new UUIDs for owner and members on new provider and set accordingly. (Atmosphere should also know this with Application membership and ApplicationVersion membership, to the extent it is used)
    • If owner has identity on desintation provider then set owner to that identity, else set owner to atmosphere administrator
    • If image maintainer does not have an identity on destination provider, script should error out unless ran with --force, in which case the atmosphere administrator will become the owner, and only members with identities on new cloud will be transferred
    • Script needs to be idempotent: if image already exists on destination provider with the same name, then only update ownership / membership.

  • Regarding replication between providers:

    • In the past there has been a master/slave relationship where the glance database has been replicated (at SQL level) from one cloud (e.g. IU Cloud) to another (e.g. TACC Cloud). This isn't feasible going forward because we'll be supporting heterogenous versions of OpenStack with different glance DB schemas. We can't replicate image UUIDs to new provider, they will be different
    • This workflow has previously been sort-of-handled by migrate_instance_task in chromogenic: downloads image from authoring provider, runs a bunch of bash to sanitize user-specific parts, uploads image to destination provider. But Steve and I agree that the workflow needed here is Atmosphere-specific and can reasonably exist as an Atmosphere script.

  • Regarding image properties (a.k.a. "metadata"):

    • Script should have an option to migrate or not migrate properties
    • If we do migrate image properties, kernel_id and ramdisk_id won't apply to new cloud, will need to correct them (more on this later)
    • Steve says tags probably out of sync between Atmosphere and OpenStack because Atmosphere sets tags on image creation but not on image update

  • Regarding Amazon AMI-based images:

    • Example: f77cb286-d5fc-4a3e-b15b-98e5a9dd2a86 on iPlant Tucson Cloud
    • Have kernel_id and ramdisk_id properties. These UUIDs point to Amazon AKI and ARI images (respectively) which are required for the main image to boot
      • Since these UUIDs would be different on new cloud, they would need to be corrected during migration process
    • They may be deceptively labeled in Glance as disk_format of qcow2
    • Team has tried unsuccessfully to "convert" these to qcow2 etc in the past
    • "First pass" of script can ignore these but ultimately we must have a strategy for migrating community AMI-based images and phasing out AMI-based base/featured images

Questions

  • Ensure that atmoadmin is always an image member?
  • Source of truth for image owner/members should be Atmosphere(2) or Glance DB for an existing provider?
  • Do we care about image members for public images?

Answered Questions

  • Does image owner (in glance) matter? Do we care if it is 'atmoadmin' in all cases?
    • Yes, community-maintained images will be owned by the maintainer, this is important if image is not public
  • Which image metadata does and doesn't matter to Atmosphere(2)?
    • Atmosphere already knows which metadata matters to it. We should (for example) be able to migrate images without
  • How are tags handled, why are tags in Atmosphere(2) sometimes different than tags stored in Glance metadata?
    • Steve says tags probably out of sync between Atmosphere and OpenStack because Atmosphere sets tags on image creation but not on image update, bug to be fixed
Clone this wiki locally