On Fri, Apr 27, 2018 at 9:49 AM, Ade Lee <a...@redhat.com> wrote: > Hi, > > Recently I starting looking at how we implement password changes in an > existing deployment, and found that there were issues. This made me > wonder whether we needed a test job to confirm that password changes > (and other config changes) are in fact executed properly. > > As far as I understand it, the way to do password changes is to - > 1) Create a yaml file containing the parameters to be changed and > their new values > 2) call openstack overcloud deploy and append -e new_params.yaml > > Note that the above steps can really describe the testing of setting > any config changes (not just passwords). > > Of course, if we do change passwords, we'll want to validate that the > config files have changed, the keystone/dbusers have been modified, the > mistral plan has been updated, services are still running etc. > > After talking with many folks, it seems there is no clear consensus > where code to do the above tasks should live. Should it be in tripleo- > upgrades, or in tripleo-validations or in a separate repo? > > Is there anyone already doing something similar? > > If we end up creating a role to do this, ideally it should be > deployment tool agnostic - usable by both infrared or quickstart or > others. > > Whats the best way to do this? >
So in my mind, this falls under a testing framework validation where we want to perform a set of $deployment_actions and ensure that $specific_things have been completed. For the most part we don't have anything like that in the upstream tripleo project for actions that aren't covered by tempest tests. Even tempest tests are only ensuring that we configured the services so they work but not a state transition from A to B. Honestly I don't think tripleo-upgrades or tripleo-validations is the appropriate place for this type of check. tripleo-validations might make sense if we expected an end user to do this after performing a specific action but I don't think there's enough of these types of actions for that to be warrented. It's more likely that we would want to come up with a deployment test suite that could be run offline where a scenario like 'change all the passwords' would be executed and verified that it functioned as expected (all the passwords were changed). Something like this might work in a periodic upstream job but it's more like a full validation suite that would most likely need to be run offline. Thanks, -Alex > Thanks, > Ade > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev