Skip to content
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 IPA IPA Trust Topology Controller #119

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

justin-stephenson
Copy link
Contributor

@justin-stephenson justin-stephenson commented Aug 1, 2024

Add "IPATrustIPA" KnownTopology

For topology groups some changes are:

  • Remove "IPATrust"
  • Add "IPATrustAD" -- includes IPATrustAD and IPATrustSamba
  • Add "AnyIPATrust" -- includes IPATrustAD, IPATrustSamba, IPATrustIPA

Linked PRs:
SSSD/sssd-ci-containers#106
SSSD/sssd#7517

@danlavu
Copy link

danlavu commented Aug 6, 2024

@justin-stephenson, It looks great, but I do think we should rename the topologies to just IPATrust, ADTrust and then SambaTrust.

@justin-stephenson
Copy link
Contributor Author

@justin-stephenson, It looks great, but I do think we should rename the topologies to just IPATrust, ADTrust and then SambaTrust.

That makes sense for the individual KnownTopology objects.

What about Topology groups? My thinking was to have the following:

  • IPATrustAD -- includes IPATrustAD and IPATrustSamba
  • AnyIPATrust -- includes IPATrustAD, IPATrustSamba, IPATrustIPA

This handles the case of any trust tests which may only run against IPA - AD trusts (AD and SambaAD specific), but in general we should try to write tests which are green for all trust types (using this AnyIPATrust KnownTopology group). On the contrary maybe we don't need IPATrustAD topology group, and those tests can just set ADTrust known topology and don't need to run against Samba AD.

What do you think?

@danlavu
Copy link

danlavu commented Aug 7, 2024

How about about,

TrustAnyAD
TrustAnyProvider

TrustAD could be generic, but it'd be confusing with ADTrust and just being the inverse.

@justin-stephenson justin-stephenson force-pushed the ipa_ipa_trust_topology_controller branch from 50d1412 to 24b3db4 Compare August 7, 2024 19:11
@justin-stephenson
Copy link
Contributor Author

How about about,

TrustAnyAD TrustAnyProvider

TrustAD could be generic, but it'd be confusing with ADTrust and just being the inverse.

Okay do we agree on the following? If yes i'll make this change to the PR.

KnownTopology:

  • IPATrust
  • ADTrust
  • SambaTrust

KnownTopologyGroup:

  • TrustAnyAD - ADTrust, SambaTrust
  • TrustAnyProvider - IPATrust, ADTrust, SambaTrust

@justin-stephenson justin-stephenson force-pushed the ipa_ipa_trust_topology_controller branch from 24b3db4 to f57543c Compare August 8, 2024 13:52
Copy link
Member

@pbrezina pbrezina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, it looks good, in general. See comments inside.

About COPR packages, we can leave it as is for now to simplify local testing. But it certainly should not be merged. If we would like to merge it, then proper downgrade of the packages must be done, otherwise we'd run tests against wip ipa.

sssd_test_framework/roles/ad.py Show resolved Hide resolved
sssd_test_framework/roles/ipa.py Show resolved Hide resolved
sssd_test_framework/roles/samba.py Show resolved Hide resolved
@@ -118,6 +119,17 @@ def test_ldap(client: Client, ldap: LDAP):
.. topology-mark:: KnownTopology.IPATrustSamba
"""

IPATrustIPA = SSSDTopologyMark(
name="ipa-trust-ipa",
topology=Topology(TopologyDomain("sssd", client=1, ipa=2)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second IPA should go into different domain.

If you put two ore more identical roles inside single domain, it should mean that the hosts are identical (i.e. ipa replica).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, along with sssd tests mhc.yaml.

client.conn.exec(["dnf", "copr", "enable", "abbra/wip-ipa-trust", "-y"])

ipa.conn.exec(["dnf", "update", "freeipa-server", "sssd-client", "-y"])
client.conn.exec(["dnf", "update", "sssd-client", "-y"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both PR CI and IDM CI installs SSSD under test, this is not necessary and will probably break in non-local run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be removed later when feature is available and does not need to be installed from COPR, let's leave this conversation open.

Comment on lines 267 to 197
# Add ipa-ipa trust COPR and update packages
self.logger.info("Adding COPR and updating packages")
ipa.conn.exec(["dnf", "copr", "enable", "abbra/wip-ipa-trust", "-y"])
client.conn.exec(["dnf", "copr", "enable", "abbra/wip-ipa-trust", "-y"])

ipa.conn.exec(["dnf", "update", "freeipa-server", "sssd-client", "-y"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be here, if needed as a temporary solution it should be moved before pytest is run. I.e. the CI workflow, or install it manually on local run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intent was to simplify the steps for QE.

This will be removed later when feature is available and does not need to be installed from COPR, let's leave this conversation open.

Comment on lines +275 to +202
# F40 sssd-kcm fails to start with 'Invalid option --genconf-section=kcm:'
ipa.conn.exec(["systemctl", "restart", "sssd-kcm"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this fixed/investigated already?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only relevant with install from COPR.

This will be removed later when feature is available and does not need to be installed from COPR, let's leave this conversation open.

@pbrezina
Copy link
Member

Please, also add feature detection.

@justin-stephenson
Copy link
Contributor Author

Hi, it looks good, in general. See comments inside.

About COPR packages, we can leave it as is for now to simplify local testing. But it certainly should not be merged. If we would like to merge it, then proper downgrade of the packages must be done, otherwise we'd run tests against wip ipa.

Thank you for the review.

I should have been more clear about the current state. We are still in mid-development phase of IPA IPA trust feature. I created these PRs to involve QE early on in the development. We have some working functionality in sssd/ipa packages from COPR therefore they can start writing some basic tests. Dan + Jakub wanted to see these PRs to start building out the parts needed for IPA IPA Trust downstream testing.

I set the blocked label on this PR (I can move it to Draft status if you prefer). I will leave your comments about COPR and updating SSSD packages from COPR open, planning to remove later when we are ready.

Copy link
Contributor

@jakub-vavra-cz jakub-vavra-cz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the trust do both ipa servers need to be changed or only the one trusting?
If so:

  • Would it be possible to switch the code around so ipa2 is trusting ipa1?
  • That way we can keep ipa1 on the production version for other tests.

As for copr/packages, the code should be in ansible playbook in sssd-ci-containers
and enabled by a switch that is by default off. We do not want anything messing around with tested artifacts.

@justin-stephenson
Copy link
Contributor Author

For the trust do both ipa servers need to be changed or only the one trusting? If so:

* Would it be possible to switch the code around so ipa2 is trusting ipa1?

* That way we can keep ipa1 on the production version for other tests.

Currently it is possible to upgrade just the 1 IPA server but with upcoming changes on FreeIPA side in the near future it will be required to upgrade both IPA masters (ipa.test and ipa2.test) to COPR for testing.

As for copr/packages, the code should be in ansible playbook in sssd-ci-containers and enabled by a switch that is by default off. We do not want anything messing around with tested artifacts.

Okay I can move this code to SSSD/sssd-ci-containers#106 but I'm not sure how to handle downgrading SSSD packages from COPR after IPA IPA trust tests are run (initially I thought this would be handled by IPA topology controller teardown).

@pbrezina
Copy link
Member

pbrezina commented Aug 16, 2024

For the trust do both ipa servers need to be changed or only the one trusting? If so:

* Would it be possible to switch the code around so ipa2 is trusting ipa1?

* That way we can keep ipa1 on the production version for other tests.

Currently it is possible to upgrade just the 1 IPA server but with upcoming changes on FreeIPA side in the near future it will be required to upgrade both IPA masters (ipa.test and ipa2.test) to COPR for testing.

As for copr/packages, the code should be in ansible playbook in sssd-ci-containers and enabled by a switch that is by default off. We do not want anything messing around with tested artifacts.

Okay I can move this code to SSSD/sssd-ci-containers#106 but I'm not sure how to handle downgrading SSSD packages from COPR after IPA IPA trust tests are run (initially I thought this would be handled by IPA topology controller teardown).

Thank you for explaining your plan. There's no need to handle this if we don't intent to merge it in this state. I think we can do two things here:

  • instruct QE to run with --mh-topology=ipa-trust-ipa, this will only run desired tests
  • or, if you want to run all tests, move the upgrade to IPAHost.pytest_setup() and ClientHost.pytest_setup(), this way it will be updated for all tests and we can also start testing for potential regressions

@justin-stephenson
Copy link
Contributor Author

Thank you for explaining your plan. There's no need to handle this if we don't intent to merge it in this state. I think we can do two things here:

* instruct QE to run with `--mh-topology=ipa-trust-ipa`, this will only run desired tests

* or, if you want to run all tests, move the upgrade to `IPAHost.pytest_setup()` and `ClientHost.pytest_setup()`, this way it will be updated for all tests and we can also start testing for potential regressions

@jakub-vavra-cz are you okay with either of these options?

@jakub-vavra-cz
Copy link
Contributor

@justin-stephenson:
I am okay with the either options.
I want to see a "DELETE ME BEFORE MERGING" comment for the copr repo so we do not forget do delete it.

We could use some detection for the ipa2ipa trust capability both on client and on the ipa server.
(https://github.com/SSSD/sssd-test-framework/blob/master/sssd_test_framework/hosts/client.py#L40,
https://github.com/SSSD/sssd-test-framework/blob/master/sssd_test_framework/hosts/ipa.py#L71)

That way we can prepare and merge tests before it is available and run them only where it makes a sense.

Add "IPATrustIPA" KnownTopology

For topology groups some changes are:

- Remove "IPATrust"
- Add "IPATrustAD" -- includes IPATrustAD and IPATrustSamba
- Add "AnyIPATrust" -- includes IPATrustAD, IPATrustSamba, IPATrustIPA
@justin-stephenson
Copy link
Contributor Author

Rebased, needed some minor changes due to pytest-mh changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants