1. 17 Nov, 2021 5 commits
  2. 16 Nov, 2021 9 commits
    • Nils Goroll's avatar
      Remove VRE options masks · 6503249c
      Nils Goroll authored
      varnish core code should continue to use the VRE_* options, vmods
      may now pass PCRE2_* options.
      6503249c
    • Martin Blix Grydeland's avatar
      Amend the docs on the '-I' option · aa2232eb
      Martin Blix Grydeland authored
      Make a note in the documentation of CLI Command File that it is necessary
      to include an explicit 'vcl.use' command in the script.
      aa2232eb
    • AlveElde's avatar
      Test case for handling initially cold VCLs · bc8537ed
      AlveElde authored
      bc8537ed
    • Martin Blix Grydeland's avatar
      Limit automatic active VCL selection to startup VCLs · 49d31c8d
      Martin Blix Grydeland authored
      Limit the selection of the active VCL from MGT's view point to be the last
      startup VCL given. That would be the VCL from the very last -f argument
      given to varnishd, or the autogenerated VCL from the -b argument (-f and
      -b are mutually exclusive). Because all startup VCLs are always set to
      state AUTO, and AUTO VCLs are made warm when the child is not
      running (which it is not at the time the startup VCLs are compiled), this
      ensures that it is a warm VCL that is selected as the active VCL.
      
      With this patch, VCLs loaded through the use of an initial CLI command
      script (-I option) will not cause a VCL to automatically be selected as
      the active VCL. Rather, it is expected that the initial CLI command script
      should have an explicit 'vcl.use' statement to select the active VCL. When
      an active VCL is not set, attempts to start the child will fail, which
      again will fail the varnishd daemon startup (unless -d is given) with an
      error code.
      
      The behaviour prior to this patch when using -I, -f '' (empty field), -F
      or -d was not well defined. The first VCL loaded (either by -I startup CLI
      script or a CLI 'vcl.load' command) would become the active VCL, even if
      that VCL is loaded cold. That is an illegal state and would lead to
      asserts. It is also not very useful functionality, given the typical use
      case for -I is to set up VCL labels. Those require the tips of the VCL
      tree dependency graph to be loaded first, and then the VCLs that selects
      the label. This means that the active VCL will typically be the last VCL
      loaded, which then will require the use of a 'vcl.use' statement in the -I
      script anyways. This makes it an acceptable change of default behaviour
      that should not affect users.
      49d31c8d
    • Martin Blix Grydeland's avatar
      Change mgt_new_vcl() to return the newly compiled vclprog · 56bd0ec8
      Martin Blix Grydeland authored
      mgt_new_vcl() now returns a pointer to the newly compiled VCL program, or
      NULL on failure.
      
      This also fixes a wrong return value used previously which would cause a
      "VCL compiled.\n" to be output to CLI when the child is not running even
      when the VCL compilation step failed.
      56bd0ec8
    • Martin Blix Grydeland's avatar
      Make mgt_has_vcl() return an error string · 8d0f2b83
      Martin Blix Grydeland authored
      mgt_has_vcl() now returns an error string describing why it doesn't have a
      valid VCL.
      
      This is taken from #3711 by @bsdphk
      8d0f2b83
    • Martin Blix Grydeland's avatar
      Rename active_vcl to mgt_vcl_active · df206894
      Martin Blix Grydeland authored
      It is very easy to confuse the child process' vcl_active and the
      management process' active_vcl variables.
      
      Rename mgt's active_vcl to mgt_vcl_active, following the naming scheme
      used elsewhere.
      df206894
    • Martin Blix Grydeland's avatar
      Enforce invariant on vcl_active in the child process · 5bce732b
      Martin Blix Grydeland authored
      Add a ASSERT_VCL_ACTIVE() macro that asserts that vcl_active either is
      NULL or points to a VCL that is warm.
      
      Sprinkle this macro in the various calls throughout the child process that
      are involved in VCL handling.
      
      Patch by: @alveelde
      5bce732b
    • AlveElde's avatar
      Do not select active VCL automatically in the child process · cd553720
      AlveElde authored
      Do not select the first VCL present as the active VCL in the child
      process. Instead it should always use what the mgt process tells it
      through the explicit 'vcl.use' commands it will send.
      
      Previously, the child could select a cold VCL as the active VCL if that
      happened to be the first one present to it during restarts. This could
      lead to asserts as that is not an allowed state.
      cd553720
  3. 15 Nov, 2021 6 commits
  4. 10 Nov, 2021 7 commits
  5. 09 Nov, 2021 1 commit
  6. 08 Nov, 2021 9 commits
  7. 04 Nov, 2021 1 commit
  8. 03 Nov, 2021 2 commits
    • Nils Goroll's avatar
      Fix (struct vpi_ii).p type · 9a20cdfd
      Nils Goroll authored
      It needs to be a generic pointer pointer, because it is initialized as
      a pointer to a pointer to an arbitrary struct, yet (void **) is can not
      be dereferenced.
      
      Right now, the instance info is not used, but this might change.
      9a20cdfd
    • Poul-Henning Kamp's avatar
      FlexeLinting. · 415ed78f
      Poul-Henning Kamp authored
      415ed78f