OST ansible inventory rework
Hi all, As part of the discussion around [1], we talked about changing the way we create and use the ansible inventory. I am now in the middle of doing something about this. It turned our far more complex and possibly less elegant than expected/hoped/intended. I'd like to get a high-level review for my WIP [2]. It's not tested and not ready for review. But if people think this is going in the correct direction, I'll continue. Otherwise, I'll give up - and then we have to decide how to continue otherwise. Parts of this can most likely be done more nicely, other parts should probably be completely replaced/removed/redone. We should probably also make some hard decisions, which I am frankly not sure we can make without having more concrete ideas about what other backends we want and how they would look like. So for now I ignored all this and simply did a POC. So, WDYT? Thanks and best regards, [1] https://gerrit.ovirt.org/c/ovirt-system-tests/+/114653 [2] https://github.com/didib/ovirt-system-tests/commits/add-inventory -- Didi
Hi all,
As part of the discussion around [1], we talked about changing the way we create and use the ansible inventory.
I am now in the middle of doing something about this. It turned our far more complex and possibly less elegant than expected/hoped/intended.
I'd like to get a high-level review for my WIP [2]. It's not tested and not ready for review. But if people think this is going in the correct direction, I'll continue. Otherwise, I'll give up - and then we have to decide how to continue otherwise. Parts of this can most likely be done more nicely, other parts should probably be completely replaced/removed/redone. While the 'Inventory' class is very nice, propagating that into other parts of codebase indeed turned out to be quite a pickle... I was thinking about it and did an attempt of a different approach - simply converting the inventory
Hi, On 5/25/21 4:07 PM, Yedidyah Bar David wrote: provided by the backend to be a directory [3]. It also meets the design goals - the backend is unaware of the HE VM and we can extend the inventory dynamically by simply dropping additional 'he.yml' file there when we're ready. Preliminary tests shown that there's no breakage so we should be able to avoid the "global inventory fix" and stay with what we have right now. WDYT?
We should probably also make some hard decisions, which I am frankly not sure we can make without having more concrete ideas about what other backends we want and how they would look like. So for now I ignored all this and simply did a POC. I definitely want to keep OST code backend-(or in fact lago-)independent cause lago is not maintained and its raison d'être is inexistent... I doubt however we'll find the time to actually move/implement a different backend to run OST. I'd definitely like to see oVirt tested by oVirt some day (as that should be doable), but I guess that's up to the community.
Regards, Marcin
So, WDYT?
Thanks and best regards,
[1] https://gerrit.ovirt.org/c/ovirt-system-tests/+/114653
[2] https://github.com/didib/ovirt-system-tests/commits/add-inventory
[3] https://gerrit.ovirt.org/#/c/ovirt-system-tests/+/114948/
participants (2)
-
Marcin Sobczyk -
Yedidyah Bar David