Remote claim storage backends

[jfrederickson]

I've been playing around with Duffle at the workshop at KubeCon - one of the first things that stuck out to me is that the current claims are only stored on the local filesystem. I see there was a related issue to add a storage layer for claims, but since there doesn't appear to be an issue for this yet, it'd be nice to have some sort of remote claims storage backend. :)

[technosophos]

The API is ready for this. We just need to decide a few things:

• Do we want to support only one backend?
  • If yes, which backend?
  • If no, what should our plugin system look like?

I'm kind of leaning toward allowing arbitrary backends. We could probably use the same subsystem that driver uses and farm out storage and retrieval to a separate process. Otherwise we will end up having to compile in every driver (which is not the end of the world, but is a little burdensome).

[scothis]

I spiked backing the claim store in Kubernetes. It was fairly easy to get working, but there are a few rough spots:

• crud.ErrFileDoesNotExist is specific to the crud implementation, but has special meaning inside the ClaimStore. I renamed it to crud.ErrDoesNotExist and moved from filesystem.go to store.go.
• persisting raw bytes may not be meaningful depending on the backing store. Writing bytes to a files makes sense, but inside k8s a more semantic persistence has advantages. For example, In my implementation I shoved the bytes into a ConfigMap blindly, but mapping the claim into a CRD would allow k8s native commands like kubectl get claims to produce meaningful output. Perhaps, what I really want is to implement a ClaimStore rather that a crud.Store, but claim.Store is a struct rather than an interface.
• it wasn't immediately obvious that the List() method should return claim names and not the claim as a string. A little doc can go a long way.
• the k8s List() method retrieves the full content of the claims only to throw away everything but the name. In practice, the kubeclient will populate a cache that can be interrogated for the individual Get() calls, but other implementations may not be so amenable.
• there's no obvious way to indicate when an alternate claim store is appropriate. That's the subject of this issue...

I'm not sure if there should be a plugin infrastructure for claims like the imageType driver. Creating a separate installer tool may make more sense. That way all bundles installed with the tool have claims stored in a consistent way. Finding the right balance of the behavior that controls the bundle lifecycle vs the implementation of the bundle lifecycle will be tricky. It only makes sense to track bundles that install into Kubernetes as claims in Kubernetes, but CNAB has no way (that I'm away of) to express that the bundle targets k8s without looking at the implementation of the bundle.