Motivation: The output when an error occurs shows an integer error code,
which isn't very helpful. And in the case of an error when creating a
resource, you also get a redundant log message from the controller
client.
Modifications:
* the controller client no longer logs errors
* the generated String() allows for the enum name to be displayed in the
error output
* each errorCode enum member has a hand-generated description
* the format of the error message from the CLI client was modified to
display the error description with the error message
Related to #112
Motivation: Creating duplicate resources currently results in a 500
error being displayed by the client, with no information about the true
nature of the failure.
Modifications:
* ResourceStore now converts any errors from the etcd client into
fission errors, capturing the reason for the error in the case of a
duplicate key (as ErrorNameExists)
* ErrorNameExists errors are signaled to the client with a
409 (Conflict) HTTP status
* MakeErrorFromHTTP() now reads the body of the error response to
retrieve the actual error message instead of using the HTTP status
message
* the controller client now uses MakeErrorFromHTTP() to centralize
status code -> error code mapping
* tests for all of the resources now check that duplicate resources are
reported properly
Result: The client can now provide more context when a duplicate name is
given
related to #112
Environments for functions. For now this is just the image URL for the
function run container. In the future, Environments will also have
build container image URLs, and perhaps parameters to those
containers.
Create/read/update/delete/list. Versioning will be added later. For
now, only the latest update is stored.
This implemenents create/read/update/delete/list for http triggers.
This isn't quite the final implementation: you can't look up old
versions by UUID since it only stores the latest update. I'll get to
that later.
FunctionStore uses fileStore for function code and resourceStore for
the Function's metadata. Environment- and HTTPTrigger- Store are just
thin wrappers on resourceStore.
There is probably a better way to organize this code, maybe with
reflection.
- A generic Resource interface, which is serializable and has
a key() method to get an identifying key.
- A resourceStore, which has create, read, update, delete and list.
This wraps etcd key operations and serialization/deserialization in
a convenient service. Serialization is provided to the
resourceStore as a 'serialization' interface. This can be JSON or
anything else.
- The resourceStore also has file operations -- this has read, write
and delete operations. The general idea is to store metadata in
etcd and data on the fileStore (which could also be an object store,
we don't really use any file-specific properties). Files are also
versioned -- each writeFile writes to a new UUID and that UUID is
stored in an etcd in-order list. readFile can retrieve an arbitrary
version by UUID, or just get the latest contents.
