On Tue, Dec 4, 2018 at 10:20 PM Dan Prince <dprince@redhat.com> wrote:
On Tue, 2018-12-04 at 12:54 -0500, Emilien Macchi wrote:
Hi folks,
Context: https://bugs.launchpad.net/tripleo/+bug/1805825
Today I randomly found this module: https://github.com/openstack/tripleo-validations/blob/d21e7fa30f9be15bb98027...
And it gave me 2 ideas, as I think we don't need this module and would consider it as technical debt at this point: - it's relying on a file, which isn't super safe and flexible IMHO.
We still use undercloud.conf though right? Why is it not safe (the data has to be stored somewhere right)?
- a lot of validations rely on Hieradata which isn't safe either, we saw it with the Containerized Undercloud.
Why is this not safe?
I commented on the LP you linked but it seems to me that a simple fix would be to set the same hiera setting we used before so that the location of the undercloud.conf is known. We still use and support hiera for the Undercloud. It would be a simple matter to set this in an undercloud service via t-h-t. If you wanted to you could even cache a copy of the used version somewhere and then consume it that way right?
I guess this is pretty much what's happening in this patch (at least partly): https://review.openstack.org/#/c/614470/ However, I agree with Emilien that it's a good idea to remove the dependency on puppet/hieradata in favor of ansibles vars.
Dan
So I propose that: - we export require parameters via the Heat templates into Ansible variables - we consume these variables from tripleo-validations (can be in the inventory or a dedicated var file for validations).
Since tripleo-validations consume the inventory with every validation run anyway, I'm slightly in favor of storing the variables there instead of an extra validations file. Florian
So that way we remove the dependency on having the undercloud.conf access from Mistral Executor and also stop depending on Puppet (hieradata) which we don't guarantee to be here in the future.
Can someone from TripleO validations team ack this email and put this work in your backlog? If you need assistance we're happy to help but I believe this is an important effort to avoid technical debt here.
Thanks, -- Emilien Macchi