OpenStack - support --filter so it does not error trying to delete images that belong to other environments

[genevieve]

Leftovers for openstack does not support a filter. It tries to delete all images/instances/volumes.

It is failing in CI because there are images in our openstack environment from other users and those images are "in use" by their respective vms.

Potential workarounds:

• Support filter for openstack and require users to better tag their images
• When deleting a VM, delete it's corresponding image regardless of name

Failure:

STEP: failing to create a new Leftovers when openstack can't authenticate
STEP: listing all resources when calling Types
STEP: warning the user when a filter is passed to List
STEP: listing all resources when a filter isn't passed to List
STEP: passing a filter to DeleteType
STEP: deleting by type 'Volume'
STEP: deleting by type 'Compute Instance'
STEP: deleting by type 'Image'

• Failure in Spec Teardown (AfterEach) [18.263 seconds]
Openstack
/go/src/github.com/genevieve/leftovers/acceptance/openstack_test.go:17
  Deleting OpenStack Resources Journey
  /go/src/github.com/genevieve/leftovers/acceptance/openstack_test.go:41
    deletes the appropriate OpenStack resources [AfterEach]
    /go/src/github.com/genevieve/leftovers/acceptance/openstack_test.go:42

    Expected error:
        <*multierror.Error | 0xc0003dee20>: {
            Errors: [
                {
                    s: "[Image: bosh-openstack-kvm-ubuntu-trusty-go_agent-raw/3586.118 235a2c92-2971-4760-89b6-2fbb364255b7] Expected HTTP response code [] when accessing [DELETE http://10.196.2.211:9292/v2/images/235a2c92-2971-4760-89b6-2fbb364255b7], but got 409 instead\n{\"message\": \"Image 235a2c92-2971-4760-89b6-2fbb364255b7 could not be deleted because it is in use: The image cannot be deleted because it is in use through the backend store outside of Glance.<br /><br />\\n\\n\\n\", \"code\": \"409 Conflict\", \"title\": \"Conflict\"}",
                },
                {
                    s: "[Image: beagle-ops-manager 191ec6c7-fbdd-43dc-90d4-186eb9480f77] Expected HTTP response code [] when accessing [DELETE http://10.196.2.211:9292/v2/images/191ec6c7-fbdd-43dc-90d4-186eb9480f77], but got 409 instead\n{\"message\": \"Image 191ec6c7-fbdd-43dc-90d4-186eb9480f77 could not be deleted because it is in use: The image cannot be deleted because it is in use through the backend store outside of Glance.<br /><br />\\n\\n\\n\", \"code\": \"409 Conflict\", \"title\": \"Conflict\"}",
                },
...

[genevieve]

In terraforming-openstack, we create the openstack image with a name that contains the environment: https://github.com/pivotal-cf/terraforming-openstack/blob/master/ops-manager.tf#L2

In bosh-openstack-cpi-release, we create the openstack image with the name of the stemcell and it's version but nothing else useful: https://github.com/cloudfoundry/bosh-openstack-cpi-release/blob/c8dadbfe952140ce817546b435d7c261c7edae51/src/bosh_openstack_cpi/lib/cloud/openstack/stemcell_creator.rb#L75

In order to clean up orphaned bosh stemcells on openstack, we can only check that the image is available. In order to clean up orphaned ops manager images on openstack, we can check that the image name contains the environment.

[rowanjacobs]

This issue came up for the Ops Manager team recently; one of their bot users was mistakenly given admin rights, and that user was running leftovers, presumably only for its environment. Admin rights on OpenStack give visibility to every resource on the entire cluster, so without a filter it went and deleted every single image on the cluster.

[genevieve]

@nmahoney-pivotal @zachgersh are y’all still unable to prioritize fixing this bug? If not, I would prefer to remove this functionality so we aren’t causing users this issue.

[nwmahoney]

@genevieve yeah I don't know when we would have the bandwidth to address this :/

[genevieve]

Done.