search

vmware / nsx-t-datacenter-ci-pipelines

CI pipelines for VMware NSX-T Datacenter
Other
71 stars 43 forks source link

Sample config missing param definitions #51

Closed aegershman closed 5 years ago

aegershman commented 5 years ago

After filling out the sample config from sample_parameters/PAS_and_PKS/nsx_pipeline_config.yml and fly'ing up the pipeline, the pipeline complained of missing params for the following:

nsxt_ansible_branch
nsx_t_pipeline_branch
ova_file_name
ovftool_file_name

It would be very helpful to have default values included in the sample config and described with a comment, as I'm not sure what the values like the branches should be (master?)

EDIT: I see. These params are defined in the docker_image/run.sh but they're not in the sample_config, which makes it confusing when using the "existing Concourse" workflow

Dyanngg commented 5 years ago

@aegershman Thanks for pointing this out. Doc has been updated on that regard.

aegershman commented 5 years ago

@Dyanngg Would you accept a PR which adds these keys to the nsx_pipeline_config? (or have someone vmware-side add it themselves?)

Even if they're commented out in the sample_params file, it makes it easier to understand all the values that are required.

Dyanngg commented 5 years ago

@aegershman For this pipeline, we recommend using the docker image provided to fly up concourse, which takes care of these params by default. If using the docker image and specifying conflicting param in the config file, the pipeline will run into erroneous state. Thus we prefer leave how to manually configure these in the documentation.

aegershman commented 5 years ago

@Dyanngg Right though the wiki has a section on how to use the pipeline with an existing Concourse rather than using the docker image

We were having unpleasant problems using the Docker method to run this locally because the docker_image/run.sh tried to ./generate-keys using the docker-compose from concourse-docker master and it was barfing with errors, though it looks like this was fixed two days ago-- and honestly the only reason we ran it with the Docker method was because it seems it was the only supported way for the pipeline to consume the *.ova and *.bundle is how it's served up over nginx via docker

I guess what I'm saying is, it'll likely make things easier for both consumers and repo maintainers if the required parameters are defined in the code itself rather than the wiki. It'll help reduce drift.

Will stop pushing on this specific issue but in general hope vmware considers moving the usage doc out of the wiki and into the code/params itself