Open Stack

On Fri, Apr 27, 2018 at 9:49 AM, Ade Lee <alee at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev