Make server_configuration optionnal.

[maximenoel8]

What does this PR change?

• Remove variables not impacting the deployment.
  - build hosts:
  - auto connection to master is not possible for build host during salt states => remove server_configuration and auto_connect_to_master variables
  - avahi_reflector is only setup in minion salt states.
  • ssh minion:
    • auto connection to master is not possible for ssh minion during salt states => remove auto_connect_to_master variable
• Make server_configuration optional for proxy, client and build_host, this value is only used if respectively auto_configure or auto_register is set to true.

[ktsamis]

I don't see a problem with this

[srbarrios]

The build host, build docker images.
Looking at salt states, you are right, we don't seem to have avahi_reflector used anywhere else aside minion, but... maybe we should do the opposite of the proposed change and support avahi_reflector in build_host, to do so, I think it's enough to change its parent from host to minion.

@Bischoff could you bring some light before approving this PR please?

[srbarrios]

Waiting @Bischoff feedback about avahi_reflector support in a Build Host

[srbarrios]

From the point of view of auto_connect_to_master feature, I think it make sense to have the possibility to auto connect a build host, at the end is just another salt minion that we onboard with a special Add-On system type.

Instead of removing it because is unused at that moment, I would consider to change its parent from host to minion. So that would make possible for a build_host to auto-connect to master.

If you agree on that, we can create a card to track it and don't forget.

[maximenoel8]

It's just that it has never been used for a long while ( maybe ever ). I was thinking adding the auto connect to build host, but if it's not needed now, I don't see a need for later.
I will ping Pablo to have a look at this PR.

[Bischoff]

I used to use avahi quite a lot. These days a lot less, because of our private DNS entries, but it's a privilege. I know at least 2 developers who rely on avahi.

We don't need auto connect on the build host (*), but we do need the avahi reflector.

(*) at least not me, but maybe some developer or supporter does. Oscar mentioned that in demoes our supporters use that auto connect thing intensively.

[meaksh]

I would agree with Óscar on moving the build_host from host to minion and then keeping the auto-connect with master feature.

As developer, I use avahi on my deployments all the times, OTOH I never use this reflector config, which seems not be actually working at the moment for build_host (as only does stuff on minion SLS files)

[maximenoel8]

The build host, build docker images. Looking at salt states, you are right, we don't seem to have avahi_reflector used anywhere else aside minion, but... maybe we should do the opposite of the proposed change and support avahi_reflector in build_host, to do so, I think it's enough to change its parent from host to minion.

@Bischoff could you bring some light before approving this PR please?

Do we have a use case ? Sumaform is already complex, by digging I found those unused variables. It has been like that for a while.

[Bischoff]

The build host, build docker images. Looking at salt states, you are right, we don't seem to have avahi_reflector used anywhere else aside minion, but... maybe we should do the opposite of the proposed change and support avahi_reflector in build_host, to do so, I think it's enough to change its parent from host to minion.
@Bischoff could you bring some light before approving this PR please?

Do we have a use case ? Sumaform is already complex, by digging I found those unused variables. It has been like that for a while.

If you deploy a build host on your workstation where you use avahi, you will need the reflector. I would call this a use case.

We don't see it in our official test suites because they all rely on a DNS server.

I think Oscar is correct here. Either don't apply, or refactor to be able to use it on a build host.

[Bischoff]

same concerns as Oscar