feat: basic Caddyfile support + tests

[dunglas]

No description provided.

[dunglas]

olric_env foo

or

olric {
   env foo
}

What's the usual convention @mholt @francislavoie?

[francislavoie]

Are there other olric options to go in? If so, grouping it might make sense, but otherwise, why not just env?

Depends if we want to "leak" that olric is the underlying implementation. Does that matter to the user? We'd need to explain what "olric" is for them to know what that's intended for.

[dunglas]

I think there will be more to support the clustered mode (cc @buraksezer).

[mholt]

My impulse is to prefer env foo as a subdirective. 👍

[buraksezer]

Olric has many configuration directives. Mostly key/value but it can also contain lists and maps. I don't know how we translate it into Caddyfile format. Here is a sample for olricd (includes service discovery sections for Consul): https://github.com/buraksezer/olric/blob/master/docker/olricd-consul.yaml

If it's complicated to build or maintain, we may read the yaml file from the disk and translate into the configuration for embedded mode. olricd is already doing this job.

cache {
    default_ttl 5
    olric_config /path/to/olric.yaml
}

[dunglas]

Thanks!!

[buraksezer]

@dunglas config.Load function is ready to use. See v0.3.0-beta.6

Simply:

c, err := config.Load(cpath)
if err != nil {
// handle this error
}

[francislavoie]

(btw @buraksezer I think you have the first two issues in that changelog flipped)

[buraksezer]

@francislavoie Thanks. Fixed!

[dunglas]

Support added in 9a0d86c!

[mholt]

Beautiful. Great start for Caddyfile support.

[mholt]

My impulse is to prefer env foo as a subdirective. 👍

[dunglas]

I added a commit with an alternative that implementation that uses a global option. It makes it explicit that the cache configuration is global and cannot be modified:

{
    # optional, but the cache can be configured only here, not in a specific handler
    cache {
        olric_config /path/to/olric.yaml
    }
}

localhost

route /cache {
    cache
    header Cache-Control "s-maxage=5"
    respond "Hello!"
}

route /other-cache {
    cache
    header Cache-Control "s-maxage=60"
    respond "Hello, World!"
}

This format is (IMHO) less error-prone and more intuitive.

In JSON, the configuration of the cache must be exactly the same for every handler or a validation error is thrown.

I also followed @buraksezer's suggestion to simply allow users to configure Olric using its own YAML format, it will simplify the maintenance a lot: users will automatically have access to all Olric's features, even new ones.

WDYT @mholt @francislavoie?

[mholt]

@dunglas I think moving the cache config to a global option is definitely a good idea, looks great.

It should still need to be documented that even the singular/global cache config cannot change even though config reloads, as users will naturally expect that if they change their config and reload it that it will update the cache's config too.

[dunglas]

On my side, this PR is ready to be merged!

[mholt]

Think I'm good with this too. Solid start!

[mholt]

(PS. You may merge this whenever you're ready!)

[dunglas]

@mholt This PR is ready to be merged, but I haven't the rights to do so.

[mholt]

Oops! My bad. I just added you as a maintainer.

[dunglas]

Thanks @mholt!