dataplaneapi
dataplaneapi copied to clipboard
haproxytech
Creating Sites generates warning messages due to implicitly used named defaults section
Hi,
I'd like to bring your attention to a minor problem with Site objects.
[!NOTE] I have shared the exact same message in https://github.com/haproxytech/client-native/issues/106 but I'm not sure if issues are actively monitored.
The SiteService and SiteFarm objects don't have a From field which prevents users from specifying a named defaults section to be used when configuring Sites.
The https://github.com/haproxytech/client-native/blob/fd6b9e5b9bdfc053f109e18a5ea284a39e3dffe6/configuration/site.go#L530-L539
and https://github.com/haproxytech/client-native/blob/fd6b9e5b9bdfc053f109e18a5ea284a39e3dffe6/configuration/site.go#L541-L548
methods don't set the https://github.com/haproxytech/client-native/blob/fd6b9e5b9bdfc053f109e18a5ea284a39e3dffe6/models/frontend.go#L139 and https://github.com/haproxytech/client-native/blob/fd6b9e5b9bdfc053f109e18a5ea284a39e3dffe6/models/backend.go#L143 respectively which leads to warnings in HAProxy when applying the configuration:
[WARNING] (1) : config : parsing [/etc/haproxy/haproxy.cfg:48] : defaults section 'defaults' (declared at /etc/haproxy/haproxy.cfg:22) is explicitly referenced by another proxy and implicitly used here. To avoid any ambiguity don't mix both usage. Add a last defaults section not explicitly used or always use explicit references.
This is not ideal because if we try to update a configuration file with an unnamed defaults section, the config parser automatically renames it as unnamed_defaults_1 and updates all existing sections with from unnamed_defaults_1. When we subsequently update the configuration file via dataplaneapi we get the above warning if we don't set the From attribute for all frontend and backend sections we are trying to create, including the ones created through a Site object
Sorry I missed you issue in client-native project. This is definitely a bug, we should add a From field to Site object and reuse it when generating both Frontend and Backends in the specified site. This way you can set your desired defaults section for that site object, and avoid messages like this and automatically using the unnamed_defaults defaults section. I'll add it to our roadmap to fix.
