-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add topology controller #38
Conversation
To avoid potentional conflict in attributes names.
This is not strictly needed, but I wanted to add unit tests so why not make it future proof when at it.
The current state is not possible to extend very easily without breaking existing setups. This change allows full flexibility when adding new functionality to the marker.
This is needed in order to allow one-time topology setup and teardown. If the tests would not be sorted by topology, we would have to run topology setup and teardown for each test, which has its use cases but in most majority of cases you want to setup environment for given topology only once and then run all tests for this topology in order to speed things up. We will provide hooks to do both - one-time setup and per-test setup.
sssd-test-framework requires this patch to unbreak it: SSSD/sssd-test-framework#73 |
@justin-stephenson @ikerexxe @danlavu This is a kind request for a thorough review. |
Will the ansible enrollment tasks (realm join) in sssd-ci-containers still be used, or they will be deprecated by this feature?
Why does the test suite need to run multiple times currently? |
This is currently unknown, it depends on the implementation on our side. I do not know without trying if it is doable to add different trust setup and completely recover to original state.
At this moment we have client enrolled to LDAP, IPA, Samba and AD domains with IPA-Samba and IPA-AD trust created. We can run all tests at once. But when we start adding more complex stuff (multiple trusts etc) we would have to:
|
e3ae693
to
7317290
Compare
Topology controller can be associated with topology using the topology marker. It provides various hooks to implement per-topology setup and teardown.
a089db0
to
32123b5
Compare
@justin-stephenson Thank you. I updated the documentation. See the diff here. |
I need more instructions and examples as I'm trying to review this. Can either you or @justin-stephenson share an implemented test example? I'm sure I'll have more questions afterward, but an example will help me a lot. |
Let's have a sync call on Friday. |
Here is a very minimal test example justin-stephenson/sssd-test-framework@8017828 but other methods you might want to override besides |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, thanks for your work on this Pavel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got nothing. I tested it makes sense and I'll be ready to create some new topologies soon. Thank you. Pavel.
Topology controller can provide various topology related hooks.
Right now, it provides per-topology setup and teardown as well
as the possibility to skip all tests for this topology.
We can use it to automatically enroll client into domains or
setup trust. Doing this in ansible has its limitations for more
complex setups (such as multiple AD domains). Now we can do it
from pytest so we don't have to run the test suite multiple times,
each time with different environment.