acs-engine 0.6.0 generate fails on DNSPrefix and ServicePrincipalProfile validation

[shahiddev]

Is this a request for help?:
No

Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE

What version of acs-engine?:
0.6.0

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes

What happened:
Error trying to generate template from latest kubernetes-hybrid.json template with populated values for all fields.

> acs-engine.exe generate ./kubernetes-hybrid.json
INFO[0000] Error returned by LoadContainerService: the service principal client ID must be specified with Orchestrator Kubernetes. Attempting to load container service using LoadContainerServiceForAgentPoolOnlyCluster
FATA[0000] error parsing the api model: Namespace Properties.DNSPrefix is not caught, Key: 'Properties.DNSPrefix' Error:Field validation for 'DNSPrefix' failed on the 'required' tag
Key: 'Properties.ServicePrincipalProfile.ClientID' Error:Field validation for 'ClientID' failed on the 'required' tag
Key: 'Properties.CertificateProfile' Error:Field validation for 'CertificateProfile' failed on the 'required' tag

What you expected to happen:
Template generated

How to reproduce it (as minimally and precisely as possible):
acs-engine version 0.6.0 (downloaded as binary from https://github.com/Azure/acs-engine/releases/download/v0.6.0/acs-engine-v0.6.0-windows-amd64.zip)
example template with redacted values

{
  "apiVersion": "vlabs",
  "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes"
    },
    "masterProfile": {
      "count": 1,
      "dnsPrefix": "mydnsname",
      "vmSize": "Standard_D2_v2"
    },
    "agentPoolProfiles": [
      {
        "name": "linuxpool1",
        "count": 2,
        "vmSize": "Standard_D2_v2",
        "availabilityProfile": "AvailabilitySet"
      },
      {
        "name": "windowspool2",
        "count": 2,
        "vmSize": "Standard_D2_v2",
        "availabilityProfile": "AvailabilitySet",
        "osType": "Windows"
      }
    ],
    "windowsProfile": {
      "adminUsername": "azureuser",
      "adminPassword": "supersecretpasswordhere"
    },
    "linuxProfile": {
      "adminUsername": "azureuser",
      "ssh": {
        "publicKeys": [
          {
            "keyData": "<SSH public key data here>"
          }
        ]
      }
    },
    "servicePrincipalProfile": {
      "clientId ": "<service principal app id>",
      "secret": "<service principal password>"
    }
  }
}

Anything else we need to know:

[itowlson]

Possibly related: I've noticed that if you omit the service principal when you do an acs-engine generate it reports the DNSPrefix error, even though the masterProfile.dnsPrefix is set. This happens on current master. (The missing SP error was also reported, which enabled me to fix the problem, but the presence of the spurious DNSPrefix error confused me.)

[itowlson]

...in fact it seems to do this for almost any validation error: if I mistype the orchestratorProfile.orchestratorType as Kuberneteez then I get the DNSPrefix error and an equally spurious CertificateProfile error:

INFO[0000] Error returned by LoadContainerService: OrchestratorType has unknown orchestrator: Kuberneteez. Attempting to load container service using LoadContainerServiceForAgentPoolOnlyCluster
FATA[0000] error parsing the api model: Namespace Properties.DNSPrefix is not caught, Key: 'Properties.DNSPrefix' Error:Field validation for 'DNSPrefix' failed on the 'required' tag
Key: 'Properties.CertificateProfile' Error:Field validation for 'CertificateProfile' failed on the 'required' tag

Perhaps this is an artefact of the attempt to use LoadContainerServiceForAgentPoolOnlyCluster, but it's jolly confusing.

[itowlson]

Hmm, the fallback to LoadContainerServiceForAgentPoolOnlyCluster is also problematic for non-vlabs versions because it gives you a spurious "unrecognised APIVersion" error, even though your apiVersion was fine and acs-engine just decided to try it against a different code path.

[jackfrancis]

@itowlson I've confirmed that this error shows up during unrelated failures. Feel free to thow together a PR if you identify where we've erred in our validation logic!

[chribsen]

I can also confirm that this error pops up on unrelated failures. I experienced this error when calling acs-engine generate with a JSON file that had keyData set to:

{
   "keyData": ""
}