Discussion: BREAKING CHANGE: Host and instance parameter is not consistent throughout the module

[johlju]

Details of the scenario you try and problem that is occurring:
I'm a big fan of consistency. The host parameter and the instance parameter is not consistent throughout the module.

I suggest we try to come to an agreement to which names we are gonna use and add that to the contribution guidelines so we can be more consistent in the future.

I would also want to discuss what you think about trying to make all of these consistent. Is that unnecessary? (it would be a module size breaking change)

I compiled a list of each module. Some are missing both parameters and some are missing either parameter. For this discussion I assume they do need them. Those resource that do not need either parameter, those are removed from the total sum.

Below is a list for each module (includes changes that will merge eventually). But to summarize.

The unique host parameters (order by most to fewest):

Host parameter name	Number of resources
SQLServer	17
(missing parameter)	6
NodeName	4

Question 1: The name SQLServer is used by most resources. Is that the best name it can have? From the top of my head there is also these that could be suitable; SQLServerName, NodeName, ServerName, ComputerName, HostName

The unique instance parameters (order by most to fewest):

Instance parameter name	Number of resources
InstanceName	11
SQLInstanceName	11
SQLInstance	5
(missing parameter)	2

Question 2: The name InstanceName is used by most resources. Is that the best name it can have?

Compiled list for all resources

Resource	Host parameter name	Instance parameter name
xSQLDatabaseRecoveryModel	SQLServer	SQLInstanceName
xSQLServerAlias	(not needed)	(not needed)
xSQLServerAlwaysOnAvailabilityGroup	SQLServer	SQLInstanceName
xSQLServerAlwaysOnAvailabilityGroupReplica	SQLServer	SQLInstanceName
xSQLServerAlwaysOnService	SQLServer	SQLInstance
xSQLServerAvailabilityGroupListener	NodeName	InstanceName
xSQLServerConfiguration	SQLServer	SQLInstanceName
xSQLServerDatabase	SQLServer	SQLInstanceName
xSQLServerDatabaseOwner	SQLServer	SQLInstance
xSQLServerDatabasePermissions	SQLServer	SQLInstanceName
xSQLServerDatabaseRole	SQLServer	SQLInstanceName
xSQLServerEndpoint	SQLServer	SQLInstanceName
xSQLServerEndpointPermission	NodeName	InstanceName
xSQLServerEndpointState	NodeName	InstanceName
xSQLServerFirewall	(missing)	InstanceName
xSQLServerLogin	SQLServer	SQLInstanceName
xSQLServerMaxDop	SQLServer	SQLInstance
xSQLServerMemory	SQLServer	SQLInstance
xSQLServerNetwork	SQLServer	InstanceName
xSQLServerPermission	NodeName	InstanceName
xSQLServerReplication	(missing)	InstanceName
xSQLServerRole	SQLServer	SQLInstanceName
xSQLServerRSConfig	(missing)	InstanceName
xSQLServerRSSecureConnectionLevel	(missing)	InstanceName
xSQLServerScript	(missing)	(missing)
xSQLServerSetup	(not needed)	InstanceName
xWaitforAvailabilityGroup	(missing)	(missing)

The DSC configuration that is using the resource (as detailed as possible):
n/a

Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
n/a

Version of the DSC module you're using, or 'dev' if you're using current dev branch:
Dev

[luigilink]

xSQLAliasServer -> I think we can add SQLServer and SQLInstanceName and concatenate these parameters in resource.
For the others we have to choose the same parameter name, but which one 😄
I like SQLServer and SQLInstance or SQLServerName and SQLInstanceName.
Can we also discuss about default value ?

[johlju]

Removed deprecated resources from the list.

[johlju]

@luigilink What do you mean by concatenate the parameters in xSQLServerAlias? xSQLServerAlias does not connect to any SQL Server, it only changes the registry on the host it runs on. It do have a ServerName parameter, but it is what the remote server is that is set in the registry.

I really think we should make SQLServer (the Host) parameter non-mandatory (see issue #319). I think then we should have $env:COMPUTERNAME as default value for SQLServer (the Host) parameter.
InstanceName (the Instance) parameter should always be mandatory, so it can be used for more than one instance on the same server, so it cannot have a default value.

[johlju]

One thought with the instance parameter name SQLInstancename is that it feel strange if I would to install an Analysis Service or Reporting Service. The name InstanceName would be more natural then.

[johlju]

If we do a breaking change in issue #851 then it would be good if we also resolved this one?

[randomnote1]

It would seem reasonable that if we have that large of a breaking change that this would be a relatively small portion of that change.

My vote is for InstanceName.

[johlju]

Any votes for the name of the parameter for the host name?

For the host name parameter, I personally don't think host name parameter name SQLServer is optimal for the same reason I stated above about the SQLInstanceName parameter name.

Options (please add more options if there are any):

• SQLServer (most used by resource today)
• SQLServerName
• NodeName
• ServerName
• ComputerName (normally used by PowerShell Cmdlets)
• HostName

I'm kind of divided between ServerName, ComputerName and HostName. But I personally think ServerName is best suited. But I go with whatever the majority of the community likes.

[randomnote1]

I tend to like HostName because of connecting to Failover Cluster Instances. However, NodeName seems to line up better with the DSC configurations defining nodes. I'm with @johlju on this one, I could go with ServerName, NodeName, or HostName.

I'm wondering if the host name parameter is even needed since the node configuration already knows which host the instance is on. The only exception is when connecting to a Failover Cluster Instance, however, this could potentially be dynamically determined. I'm thinking out loud on this one, so be gentle 😜

[johlju]

I could go with NodeName. I started using that when I created resource when I started out with DSC because it was a term used by DSC. But I tend to like ServerName because I think that is how you think of it from an SQL perspective, I do like HostName also, because it's a term used with DNS.
I can go with either. Regardless which is chosen, any is better than 'SQLServer'. 😄

I think host names is needed when using AG groups, please see this issue #319.

[nabrond]

+1 for ServerName

[johlju]

@randomnote1 @nabrond + all

Everybody okay with ServerName and InstanceName? If so, I suggest we make this change as soon as PR #902 is merged.

[johlju]

To all: Maybe I should have asked, is anyone not okay with ServerName and InstanceName as the new parameter names to replace the old (see issue description)? If so please tell us why. 😄

[randomnote1]

@johlju, I'm good with the proposed change.

[nabrond]

sounds good to me @johlju

[johlju]

Working on this now. Using PR #902 as base.