Description of problem: When new config options are added to Packstack, old answer files break For example, the latest Packstack build introduced a new config variable: CONFIG_PROVISION_TEMPEST_REPO_URI My answer files did not have this in them, and now I get errors: ERROR : Failed handling answer file: 'Parser cannot find option CONFIG_PROVISION_TEMPEST_REPO_URI in answer file.' This is annoying because it breaks automation even when the option being added to Packstack is completely optional In addition, it also means that a Packstack answer file must be completely specified vs. just containing only the minimum options needed (useful if you are writing one on your own vs. using output from packstack --gen-answer-file) Version-Release number of selected component (if applicable): openstack-packstack-2013.1.1-0.24.dev660.el6.noarch
More data... The snippets for these new values are: # Whether to configure tempest for testing CONFIG_PROVISION_TEMPEST=n # The uri of the tempest git repository to use CONFIG_PROVISION_TEMPEST_REPO_URI=https://github.com/redhat-openstack/tempest.git # The revision of the tempest git repository to use CONFIG_PROVISION_TEMPEST_REPO_REVISION=stable/grizzly (CONFIG_PROVISION_TEMPEST was already there) You can't add blank values to CONFIG_PROVISION_TEMPEST_REPO_URI or CONFIG_PROVISION_TEMPEST_REPO_REVISION Since there are sane defaults here, shouldn't the behavior be that if a config option is omitted or left blank that the default value is used?
Before digging into it, the feature sounds good but is it still relevant, Packstack targeting only AIO/POC? If yes then a simple approach could be: - If a parameter is not available a default value to be used. - Unknown (older) parameter ignored.
It looks as if this behavior has already been implemented. Working with packstack master, if I remove values from the answer file, things appear to move forward without a problem. In fact, it looks as if I can pass packstack a completely empty answer file consisting of: [general] ...and it will still operate.