Finalizer set

[bmoyles]

cc/ @kvick
cc/ @mtripoli

Based on Tuesday's talk, I propose FinalizerSet to contain multiple finalizers and hold the finalize() method. A finalizer set itself doesn't need to be a plugin point--it's merely a container that exposes a finalize() method. The pluggable bits are the finalizers themselves.
An environment will consist of the same components (cloud, blockdev, vol, provision) with finalizers replaced by a finalizer set.
A finalizer set is a named, ordered sequence of finalizers.
When finalizer.finalize() is called, finalizers in the FinalizerSet are executed in order.

Consider a finalizer set containing the following finalizers:
register_ebs_ami
register_s3_ami
tag_artifacts
distribute_images

We'd need to find the right place to add the snapshot... Given that the context contains enough metadata by the time we reach the finalizer stage, I think @kvick is spot on with having the exit for the volume manager handle the snapshot, and we finalize once we exit that context (but only finalize if we succeeded provisioning, natch)

Then, finalize() would simply iterate the registered and configured finalizers. A failure to finalize may or may not signal a failure in the overall operation. (Consider an asgard_poke finalizer that simulates the old nacPoke behavior--it's not doomsday if that fails, it's a nice-to-have--Asgard will find the AMI, just not necessarily immediately)

We may even be able to run some finalizers concurrently--ebs and s3 registration, for example, should be able to run in parallel. tag_artifacts, on the other hand, really only makes sense after registration, and distribution only makes sense after tags have been applied (especially as distribute_Images likely has to distribute tags as well)

[mtripoli]

Sounds good.

Regarding resource tagging, I'm working up another issue to make the tag names and values configurable.

[kvick]

I was thinking more along the lines of function chaining which IMO is simpler, expressive and naturally manages ordering (but not async)

It might break down in the it-can-sometimes-fail-and-thats-ok situation, so it to is not without flaws.

Would the YAML config go something like this?

ec2_yum_linux:
cloud: ec2
provisioner: yum
volume: linux
blockdevice: linux
finalizer_set: [ register_ebs_ami, tag_artifacts, distribute_images]

Which upon further reflection may be expressive enough to make my earlier thought moot.