unrecognized key warning

[ben-bay]

This will save users (and me, frankly) lots of headache due to slight misspellings or indentation errors.

Merlin still allows extra keys; but since they are never used, it will be helpful to show a warning whenever one is found.

Have I missed any keys that merlin supports?

[koning]

We should also add env/labels to the spec.

[ben-bay]

We should also add env/labels to the spec.

That's on line 48 currently

[koning]

We should also add env/labels to the spec.

That's on line 48 currently

I meant in the spec.

[ben-bay]

We should also add env/labels to the spec.

That's on line 48 currently

I meant in the spec.

Now that I look at this section in the specification doc, I think I removed the labels section in the past, at the time we were starting to discourage use of env.labels in favor of env.variables.

[FrankD412]

@ben-bay -- I've looked over the PR, and it looks to me like the necessary keys are there. That said, it looks like you're improving the checking in the specification which is something I've wanted to add to Maestro myself. I'd like to collaborate with you to back port this functionality to Maestro as I think that's where the core of this functionality should reside. That would make it so that Maestro is responsible for its keys in the base YAMLSpecification while Merlin just has to check for any extra keys it's added simply by implementing its check on top of the base check.

[ben-bay]

@ben-bay -- I've looked over the PR, and it looks to me like the necessary keys are there. That said, it looks like you're improving the checking in the specification which is something I've wanted to add to Maestro myself. I'd like to collaborate with you to back port this functionality to Maestro as I think that's where the core of this functionality should reside. That would make it so that Maestro is responsible for its keys in the base YAMLSpecification while Merlin just has to check for any extra keys it's added simply by implementing its check on top of the base check.

@FrankD412 brilliant, happy to work with you on this. Glad you share my sentiment here-- you have no idea how much time the occasional warning would've saved me. I agree backporting seems like the natural solution.

[ben-bay]

@FrankD412 for now I'll merge this, then when our backport is complete I'll remove the maestro material on my end.