Added scripts to generate manifests for tests

[axelaris]

Hi guys,
this is scripts to generate manifests for Smoke and Acceptance tests as long as main deployment manifest.

[cfdreddbot]

Hey axelaris!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you've already signed the CLA.

[cfdreddbot]

Hey axelaris!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you've already signed the CLA.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/109012232.

[emalm]

Thanks, @axelaris, it'd be great to have separate scripts to generate the acceptance-test and smoke-test deployment manifests. I think this would conflict heavily both with the changes we intend to pull in with #109 and with the flag-based arguments we discussed on #103, though, so it would probably work better for at least the #109 changes to go in first before we develop these particular scripts.

Thanks,
Eric

[axelaris]

Ok, waiting for #109 to me merged first.

[axelaris]

Hi @ematpl,
I've fixed my patch to intend #109.
Could you please check it.

[emalm]

Thanks, @axelaris! I think it would be great for these scripts to follow the argument conventions we discussed in #103 that come from https://www.pivotaltracker.com/n/projects/1003146/stories/107891444. Specifically, it would make sense for them to take the following mandatory argument flags, all mandatory:

• -c: CF manifest file
• -i: IaaS-settings stub file
• -p: property-overrides stub file

For consistency with generate-deployment-manifest, the scripts could also take an optional -v argument with a stub that specifies the version of diego-release, with the version in the manifest defaulting to 'latest' if the version isn't specified. That could be done later, though.

The scripts also don't need to take an argument for the template, as #109 introduces a generic template for the DATs at https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/diego-acceptance-tests.yml and for the smoke tests at https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/diego-smoke-tests.yml that we can refer to in the script itself.

The spiff merge sequence should also include https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/misc-templates/bosh.yml as the left-most template argument to allow only the BOSH-recognized top-level keys to filter through.

Does that makes sense? I'm happy to discuss it more, if you're still up for contributing the scripts.

Thanks again,
Eric

[axelaris]

Hi @ematpl,
I'm done.
Could you please check?

[emalm]

Thanks for the changes, @axelaris!

I'm pretty sure we want the ${manifest_generation}/misc-templates/bosh.yml template to be the first argument to the final spiff merge in each script, rather than an intermediate argument in the first spiff merge. That bosh.yml template will filter out the non-BOSH-y top-level keys such as config_from_cf that the diego.yml template includes on https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/diego-acceptance-tests.yml#L48-L51 only so it can receive the inputs from later stub arguments.

Also, it would be great for the script to tell the user about all the arguments that are missing or invalid, rather than just one of them at a time. So then if I accidentally invoke the script without the -c flag at all and with a directory instead of a regular file for the -p flag, the error message from the script tells me about both errors before printing the usage, rather than just, say, the missing -c argument. Having that more complete set of validations can really help reduce the iteration time when using the script, especially when it's invoked in the middle of a complicated, expensive testing pipeline. But that's a nice-to-have feature. :)

Thanks again,
Eric

[axelaris]

@ematpl, done, with nice-to-have features!

[emalm]

Thanks again, @axelaris! Looks good to me! Prioritized for the Diego team to evaluate this coming week.

Best,
Eric