Discussion: Deprecate WeakHostSend, WeakHostRecieve and DHCPClient

[PlagueHO]

The WeakHostSend, WeakHostRecieve and DHCPClient resources all configure properties on the *-NetIPInterface. They are "single purpose" resources that result in a lot of duplicated code/function. E.g. the resources are practically identical (duplicated code, tests etc).

I'm currently implementing a more generic NetIPInterface resource that can be used to configure properties on the *-NetIPInterface as part of #355. I'm excluding the WeakHostSend, WeakHostRecieve and DHCPClient properties as they are covered by these other resources.

But it seems to me to be non-trivial duplication of function/tests. This would reduce the amount of code and tests needing to be maintained and also simplify configurations - but of course would be a BREAKING CHANGE.

For example, the following current config:

Configuration Example
{
    Import-DscResource -Module NetworkingDsc

    Node localhost
    {
        DhcpClient EnableDhcpClient
        {
            InterfaceAlias = 'Ethernet'
            AddressFamily  = 'IPv4'
            State          = 'Enabled'
        }

        WeakHostSend DisableWeakHostReceiving
        {
            InterfaceAlias = 'Ethernet'
            AddressFamily  = 'IPv4'
            State          = 'Disabled'
        }

        WeakHostSend DisableWeakHostSending
        {
            InterfaceAlias = 'Ethernet'
            AddressFamily  = 'IPv4'
            State          = 'Disabled'
        }
    }
}

Would be changed to:

Configuration Example
{
    Import-DscResource -Module NetworkingDsc

    Node localhost
    {
        NetIPInterface ConfigureNetIPInterface
        {
            InterfaceAlias = 'Ethernet'
            AddressFamily  = 'IPv4'
            DHCP          = 'Enabled'
            WeakHostSend = 'Disabled'
            WeakHostRecieve = 'Disabled'
        }
    }
}

@tysonjhayes , @johlju - what are your thoughts on this?

[johlju]

I suggest deprecate the resource, merging them into the new resource - and in a later PR (maybe when doing another breaking change) remove them.
We had a similar scenario in SqlServerDsc a while back - I waited a couple of releases, then I removed them as a breaking change.

[PlagueHO]

Cool. That what I was thinking. I'll leave this issue open for a while before doing anything on it to give community time to provide feedback.

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[PlagueHO]

Bumping to keep this open for now.

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[PlagueHO]

I will plan to implement this change over the next few weeks.