Create SF backed KeyValue Store

[jjcollinge]

In order to store static and dynamic config (including ACME certificates) in a coordinated and centralised manner, we need to add support for a SF backed KeyValue store.
The current implementations (Consul, etcd, Zookeeper and BoltDB) work by implementing libkv https://github.com/docker/libkv
We can try to create our own implementation backed by the Property Management APIs by creating trees of names for keys and use properties as associated values.
Alternatively, we use one of the existing implementations and host that inside SF.

Property Management Proposal
KVStore keys map to Service Fabric names i.e.
/traefik/loglevel --> fabric:/traefik/loglevel
KVStore values map to property values
Property name is not needed so use a constant default value.

Use Service Fabric names over property names as they are hierarchical, this allows us map to the configuration hierarchy needed by Traefik and matches the tree structure used in libkv.

We'd need to add methods to the SFGOSDK to support;

• Creating Service Fabric names (POST)
• Deleting Service Fabric names (DELETE)
• Getting individual properties with metadata (we'd use a default property name .i.e. KeyValue as the name is redundant) (GET)
• List sub names (GET)
• Set individual properties (PUT)

Should create a new SFKV (Service Fabric Key Value store) package which exposes a nice interface to work with the Property Management API and then utilise this from both the llibkv Service Fabric fork and existing SFGOSDK?

Third Party KV Proposal
Use existing integration between Traefik and 3rd party backend.
Could reuse KV for label overrides and other metadata.
Potential consistency issues.

[mburumaxwell]

Is there any hope/update for this?

[lawrencegripper]

There is no active work on this sorry, happy to accept PR's on it tho.