@adleong @dadjeibaah

Thanks for the review. So yes, validating that manually was pretty straightforward. Here are the steps you can take:

• Fire up consul: ./consul agent -dev -advertise 127.0.0.1
• Start Namerd:

admin:
  ip: 0.0.0.0
  port: 9991
interfaces:
  - kind: io.l5d.httpController
storage:
  kind: io.l5d.consul
  compressValues: true

• Create a dtab entry via the API:

curl -X POST \
  http://127.0.0.1:4180/api/1/dtabs/graduation \
  -H 'Content-Type: application/json' \
  -H 'Host: 127.0.0.1:4180' \
  -d '[{"prefix":"/yeezy","dst":"/kanye"}]'

• Do a curl http://127.0.0.1:8500/v1/kv/namerd/dtabs/graduation and you will get something like this:

[
    {
        "LockIndex": 0,
        "Key": "namerd/dtabs/graduation",
        "Flags": 0,
        "Value": "SDRzSUFBQUFBQUFBQU5PdlRFMnRxclMxMDg5T3pLdE1CUUFBeWttbkRnQUFBQT09",
        "CreateIndex": 16,
        "ModifyIndex": 16
    }
]

This is straight from consul. After you base64 decode the value and decompress it with Gzip,
you can convince yourself that indeed Consul is stroing the gzipped representation of /yeezy=>/kanye

• Now do a curl -X GET http://127.0.0.1:4180/api/1/dtabs/graduation in order to verify
  that the KVApi can indeed decompress the value:

[
    {
        "prefix": "/yeezy",
        "dst": "/kanye"
    }
]

If there is a better way to verify that let me know.

Now its important to keep in mind that this is a rather primitive solution in a sense that when you set this compression to true, you assume that your consul instance will only contain compressed dtabs, so you cannot really go back. So if one wants to transition to this approach while keeping their old data in consul, its not possible.. Instead what we would have to do it maybe wrap the data we store in consul in some wrapper such as case class Entry(data: String, compressed: Boolean)
So then the logic (in order to be able to support values written to consul before this change) would be something like:

match parseContentAs[Entry](rsp.content) {
   case Failure(_) => rsp.content
   case Success(Entry(data, true)) => decompress(data)
   case Success(Entry(data, false)) => data
}

This is if we really want to keep it backwards compatible wrt the data already living in a Consul instance. @chrismikehogan maybe it would be useful to share a bit more details around your usecase in order to determine whether this is actually necessary because this try-this-then-that pattern has some perf implications as well.

@zaharidichev You raise some really good points. I haven't heard back from anyone who had been requesting this feature. I think we should put this aside for now (perhaps close the PR but keep the branch) until we get more clarity on the use-case. This implementation is solid but I'd rather not merge a feature that isn't actually useful to anyone. Does that make sense?

Yes, certainly makes sense. Lets avoid codebase bloating. If we get more clarity on the request, I will pick that up again.

Closing for now due to lack of clarity on requirements.