Clean-Up of options

[brenner-tobias]

Make the "path" option available to be used for additional_hosts (see Cloudflared Documentation).

[elcajon]

I am rather against providing this as a configuration option.
Many services do not work under a different path than root, so the questions and problems would always end up with us first.
In addition, there is already the possibility to add paths via the custom config.yml or the remote managed tunnel.

(I already thought about removing more advanced options to make the add-on more beginner friendly and to move more advanced users towards config.yml and remote managed tunnel functionalities.)

[brenner-tobias]

Very valid point, thanks for raising this. I agree that the add-on keeps getting more complicated and I also forgot about the two possibilities to either use custom config.yml or even easier a remote tunnel. I will suggest this to anyone who wants to include more advanced configurations from now on.

While we are at it: Any suggestions for config options that we should remove and only address in the documentation with the information to please use the custom config option? From my perspective, we can discuss to remove whole warp section (which from my end is so advanced, that everyone who wants to use it can also simply just use the custom config).

What do you think @elcajon?

[elcajon]

To be honest, I already migrated my tunnel to remote managed quite some time ago and since then I only use the corresponding token option.
I suspect that Cloudflare will continue to expand in this direction. The way is also easier than creating your own config.yaml and supports the exact same functionality.

So when I look at the list of options:

schema:
  external_hostname: str?
  tunnel_name: str?
  additional_hosts:
    - hostname: str
      service: str
      disableChunkedEncoding: bool?
  catch_all_service: str?
  nginx_proxy_manager: bool?
  quick_tunnel: bool?
  log_level: list(trace|debug|info|notice|warning|error|fatal)?
  reset_cloudflared_files: bool?
  data_folder: list(config|share|ssl)?
  custom_config: bool?
  warp_enable: bool?
  warp_routes:
    - str?
  warp_reset: bool?
  tunnel_token: str?

• I agree on warp_* settings. Let's remove them altogether. This can easily be set up with remote managed.
• reset_cloudflared_files: I never understood why this is needed, simply uninstalling and reinstalling has the same effect, right?
• custom_config & data_folder: The two options make sense only when used together. The question would be how many use this option. Possibilities just like remote managed but more difficult to set up if you don't look up the options in the CF documentation.
• quick_tunnel: Nice feature but also useless if the domain is changed at every restart.
• catch_all_service: Could be established remote managed as well. I guess the integrated NPM option would be enough to offer.

Maybe we should link a short survey regarding the used add-on options with the next release upgrade and see what kind of response we get?

[brenner-tobias]

I agree with your points and suggest the following approach:

1. Create a poll, who is using warp_*, custom_config and catch_all_service
2. Create a new update removing the following and include the poll in the release notes
   2.a. reset-cloudflared_files
   2.b. quick_tunnel
3. Remove all that are not used widely (I expect that we can remove everything, maybe leave custom_config but that's it)

Any thoughts?

[elcajon]

Sounds good to me. 👍🏻

[skynet01]

Sounds good, but we should include a basic guide on how to achieve the same thing that we just removed through Cloudflare ui. Even if it's as basic as "Go here, click on this, copy your key etc.. now enable warp, have fun configuring it".

Otherwise, there will be angry people when their stuff stops working .. especially because they didn't read the update notes.. ..as some people like me have auto-update enabled. Maybe we can just leave it in and not update the features and only remove it once it conflicts with something?
..just my 2 cents ;)