Leftovers from previous strains in the VCL

[bdelacretaz]

Description
The VCL of my "playground" Fastly service contains leftovers from previously defined strains which are not in my Helix config anymore.

To Reproduce

• Add a proxy strain to your Helix config and publish. I assume other strain types will behave similarly but my concrete case is a proxy.
• Remove the proxy strain from the Helix config and publish

In my case the VCL of my bdelacre - playground - bertrand.helix-demo.xyz contains leftovers of a F_Proxyincubatorapacheorg4774 proxy strain, a definition:

backend F_Proxyincubatorapacheorg4774 {
...
    .host = "incubator.apache.org";
    .port = "80";
...
    .probe = {
...
        .request = "HEAD / HTTP/1.1"  "Host: incubator.apache.org" "Connection: close";
      }
}

Which AFAICS is used in a single expression later:

    {
    if (req.backend == F_Proxyincubatorapacheorg4774 && req.restarts == 0) {
      if (server.identity !~ "-IAD$" && req.http.Fastly-FF !~ "-IAD") {
        set req.backend = shield_iad_va_us;
      }
      if (!req.backend.healthy) {
        # the shield datacenter is broken so dont go to it
        set req.backend = F_Proxyincubatorapacheorg4774;
      }
    }
  }

Expected behavior
Unused strains should be removed from the VCL. I haven't seen any concrete problems with this so far but such leftovers would at least be confusing when debugging things.

Version:
hlx --version 4.4.1

[trieloff]

What's being left over is the backend that has been defined for the proxy strain, so it is specific to proxies. We can (with some accuracy) detect the backends we have generated, so theoretically it is possible to remove them, but either way there are downsides:

• when we remove it & if the user is referring to the backend elsewhere, i.e. in custom VCL code or rules, this will break and the config can't be activated
• when we do not remove it & the user has more than 5 backends, i.e. through other unrelated proxy strains, there is the risk of running into the limit of backends.

[tripodsan]

I think this relates to the question of ownership of the fastly service. If we can agree, that helix has 100% ownership of the service, then the strain config should be the single source of truth that generates the VCL and configures the service.

as mentioned elsewhere, this could imply that for tricky setups, our service would act as backend of another service. the more I think of it, the more I like it. the only problem will be cache invalidation.