The bug https://bugzilla.redhat.com/show_bug.cgi?id=1383369 was reintroduced by https://review.openstack.org/#/c/486742/ . The expected value is [auth]tempest_users=swiftoperator . Please revert the change or add a proper logic to decide when this option needed, the main purpose of the deployer-input file is to provide the non discoverable information for tempest. Version: python-tripleoclient-7.2.1-0.20170807222309.a731597.el7ost
I'm not familiar with the code that interacts with Tempest. Arx, could you comment on the upstream patch? There is no bug attached to it, it seems like it was meant to be more of a clean-up rather than fix a problem? As it is causing one now with the automation, perhaps reverting it as suggested would make sense for now, and work instead on a solution that covers this use case as well for 13. What do you think?
So, in python-tripleoclient, it was hardcoded the swiftoperator role, and this role is only created when the swift is installed with tripleo-heat-templates. In an environment without swift, this role isn't created, and so the tempest deployer input file had this configuration wrongly set. Right now, there's no logic in the tempest-deployer-input.conf based on what you're installing, so, if you really require this configuration, you should manually add it in your tempest.conf. I also don't know if is possible right do some logic in python-tripleoclient because it doesn't know which kind of deployment you're doing, but I can be wrong.
The whole point behind the tempest-deployer-input.conf it gives me the right (at least working) valuers for the things which are not discover able over the API. If I really had to solve this on my own, there is no point for having the tempest-deployer-input.conf .
Hi Attila. I chatted a bit more with Arx and from what I understand the problem is that these preset swift values do not work for every case and cause some of the upstream CI scenarios to fail (because Tempest would see the role and try to use it even when it doesn't exist). It looks like upstream is keeping a list of which jobs need which roles in a YAML file and feeding it via quickstart, so the jobs that need it can have the swiftoperator etc roles set: https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/validate-tempest/templates/configure-tempest.sh.j2#L165 . Maybe that could be an option for downstream as well?
(In reply to Julie Pichon from comment #4) > It looks like upstream is keeping a list of which jobs need which roles in a > YAML file and feeding it via quickstart, so the jobs that need it can have > the swiftoperator etc roles set: > https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/ > validate-tempest/templates/configure-tempest.sh.j2#L165 . Maybe that could > be an option for downstream as well? And that's why Attila was talking about removing the need for tempest-deployer-input.conf: if all the options that should be provided by it (coming from the real tripleo configuration) need to be explicitly passed to tempest, why would we need it? That said, I disagree that removing it is the proper way. Unfortunately so far no one worked on solving the real issue: that tripleoclient should write down a tempest-deployer-input.conf file based on the *real* configuration deployed by TripleO.
It looks like upstream is moving towards removing the file all together, as it is misleading and not useful in its current state - https://review.openstack.org/#/c/503835/ .
Review removed for now, there is an hint on how to fix this: using the same code that is used by `openstack overcloud config download` to retrieve the configuration deployed and use that to populate that file (and long term, a mistral workflow to do that).
*** Bug 1382048 has been marked as a duplicate of this bug. ***