Assertion failure in VCL_DelBackend()

[Dridi Boukelmoune]

> VCL_DelBackend is declared in $include_dir/cache/cache_backend.h, so
> it's available to a VMOD, and there's no indication that it's "not
> supposed to" be used. I've suspected that there are things in
> $include_dir that aren't really meant to be public, but if we're
> serious about that, and if Varnish is liable to crash if a VMOD does
> use them, then perhaps we should separate out the non-public
> interfaces. Or at least document them as non-public -- we have that in
> the *_int.h includes in vapi, for example.

If it were up to me I'd simply remove everything that doesn't start
with VRT_, except of course symbols from libvarnish* and related data
structures :)

> But it would be a real letdown if VCL_DelBackend is made unavailable
> with no replacement for removing backends. I don't see any other
> current interface that can do it.

VRT_delete_backend ?

> As I mentioned, VCL_DelBackend does work for the dynamic backends that
> the VMOD creates (with VRT_new_backend), and I haven't investigated
> why they're different from the static backends. I can live with a VMOD
> that can only remove its own backends, but the call seemed to me to be
> general enough for static backends as well, so I thought why not.

I don't even know how you would delete the backend without breaking
the type system. If you reference it from a VMOD you should get a
const struct director and the actual struct backend should be hidden
behind the priv pointer. You should get enough hints that you're not
supposed to delete them at this point :p

>>> Bug report? (Are we still using trac for that, or are we into the
>>> Brave New World now?)
>>
>> I think not.
>
> You think ... there should be no bug report? Or that we're not using
> trac any more? Or that we're not using github for bug tracking ... ?

Sorry, I meant there should not be a bug report.

> ... about that use case: It's for "microservices", which are
> lightweight backend apps running in docker containers that are managed
> by mesos/marathon, and are rapidly created, removed and migrated. So
> rapidly that we couldn't get it to work any more by changing the
> backend config in VCL and running vcl.load/vcl.use. We've been forced
> to add haproxies as an intervening layer, which are backends for
> Varnish, and they in turn get the changing backend configs. I'd like
> to use dynamic backends in 4.1 to be able to get rid of the extra
> layer, and for that, we need to be able to remove backends at runtime.

Sounds good, I have been doing that with DNS :)

If you have some sort of API to get the backends, you can go with
dynamic-only backends. You still need at least one static backend to
please libvcc, but I had a patch to remove this limitation in the
past. I could re-submit if it makes more sense this time. The reason
it was rejected initially was because it would defer the backend
sanity check to vcl_init{} but since then it has become possible to
fail vcl_init{} so maybe it could be reconsidered.

Cheers,
Dridi