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

feat: have landscape-config --silent only send a registration messa… #258

Merged
merged 3 commits into from
Aug 14, 2024

Conversation

wck0
Copy link
Contributor

@wck0 wck0 commented Aug 5, 2024

…ge when required and add a new --force-registration flag

…ge when required and add a new `--force-registration` flag
@wck0
Copy link
Contributor Author

wck0 commented Aug 5, 2024

Currently, landscape-config --silent will always try to send a registration message. With this change, when the --silent flag is paired with the --register-if-needed flag we only send the registration message if we can deduce that no registration message has been sent yet (i.e. the secure id is null).

Manual testing instructions:

  1. Working on this branch, build the snap: make snap
  2. Install the snap in some container.
  3. Configure Landscape Client and have it send a registration message to create a new pending computer.
  4. Run landscape-client.config --silent --register-if-needed and observe no additional pending computer is created.
  5. Accept the pending computer and allow some message exchange to occur.
  6. Run landscape-config --silent --register-if-needed and observe no additional pending computer is created.
  7. Run landscape-config --silent and observe this time a pending computer is created.
  8. Repeat ad nauseam making changes to the configuration along the way.
  9. Try to break something.

@srunde3 srunde3 self-assigned this Aug 5, 2024
@srunde3
Copy link
Contributor

srunde3 commented Aug 5, 2024

Why do we want --force-registration to not create a new pending computer? Wouldn't we want it to create a new secure_id for the client and therefore a new pending computer?

Copy link
Contributor

@srunde3 srunde3 left a comment

Choose a reason for hiding this comment

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

Manual testing went fine according to your instructions; left one question about if your documented behavior is what we "want" from this change

@@ -2756,6 +2804,13 @@ def test_success_means_exit_code_0(self):
result = determine_exit_code("success")
self.assertEqual(0, result)

def test_registration_skipped_means_exit_code_0(self):
"""
When passed "success" the determine_exit_code function returns 0.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: looks like a carryover from a copy-paste; should be "registration-skipped"

Copy link
Contributor

Choose a reason for hiding this comment

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

Should be "registration-skipped"?

if config.is_registered:

registration_status = is_registered(config)
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: could we just replace usages of registration_status with already_registered?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I picked this nit.

set_secure_id(config, "registering")
secure_id = get_secure_id(config)
if (not secure_id) or config.force_registration:
set_secure_id(config, "registering")
Copy link
Contributor

Choose a reason for hiding this comment

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

I realize this is somewhat of a carryover from the existing implementation, but is it necessary to set the secure_id in the configuration file and in the registration handler? Could we get rid of it here since you set it in the registration handler now?

@silverdrake11
Copy link
Contributor

How is this different from this pull request #243

@silverdrake11
Copy link
Contributor

One other question. Will this break existing scripts that rely on landscape-config sending a new registration as the default behavior? I can see that the charm will be affected by this. For example, if the user runs the re-register run action, then that is implement simply by a landscape-config --silent

@wck0
Copy link
Contributor Author

wck0 commented Aug 5, 2024

Why do we want --force-registration to not create a new pending computer? Wouldn't we want it to create a new secure_id for the client and therefore a new pending computer?

We don't. I made a copy-pasta error in my testing instructions. Editing them to better reflect the intentions.

@wck0
Copy link
Contributor Author

wck0 commented Aug 5, 2024

How is this different from this pull request #243

The --skip-registration flag can be passed independent of the --silent flag.

@wck0
Copy link
Contributor Author

wck0 commented Aug 5, 2024

One other question. Will this break existing scripts that rely on landscape-config sending a new registration as the default behavior? I can see that the charm will be affected by this. For example, if the user runs the re-register run action, then that is implement simply by a landscape-config --silent

Yes, it sounds like this change will break that behavior. It can be adjusted in the charm by calling landscape-config --silent --force-registration if the charm action should always result in a new registration request.

@silverdrake11
Copy link
Contributor

In that case I would prefer we have a flag --send-only-if-unsent (maybe we can think of a better name) than modify the default behavior of landscape client. We have alot of customers relying on old default behavior and changing the api in a way that could result in breaking changes seems like it can cause trouble

@wck0
Copy link
Contributor Author

wck0 commented Aug 6, 2024

OK, good point. I'll fix this up and let Carlos know.

@wck0
Copy link
Contributor Author

wck0 commented Aug 6, 2024

Leaning towards --register-if-needed but open to suggestions.

@wck0 wck0 marked this pull request as draft August 6, 2024 18:44
@wck0
Copy link
Contributor Author

wck0 commented Aug 6, 2024

Updated, restoring the behavior of --silent and with a new flag --register-if-needed.
Other refactoring, too.

@wck0 wck0 marked this pull request as ready for review August 6, 2024 23:13
Copy link
Contributor

@srunde3 srunde3 left a comment

Choose a reason for hiding this comment

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

Code looks good, but I'm getting unexpected registration messages after running --silent --register-if-needed. I'll continue this tomorrow to see if the issue exists between chair and keyboard or if changes are needed here.

@@ -2756,6 +2804,13 @@ def test_success_means_exit_code_0(self):
result = determine_exit_code("success")
self.assertEqual(0, result)

def test_registration_skipped_means_exit_code_0(self):
"""
When passed "success" the determine_exit_code function returns 0.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be "registration-skipped"?

default=default_answer,
)

if should_register or config.silent:
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this check is causing the client to reset the secure_id even if we pass --register-if-needed and the client is already registered; the restart_client function sets the secure_id to 'registering", and then we end up with another pending computer.

@wck0
Copy link
Contributor Author

wck0 commented Aug 13, 2024

Updated. For manual testing now:

  1. start with a fresh snap install
  2. register with your Landscape Server
  3. accept the pending computer
  4. wait for message exchange to occur. This ensures that the secure_id is set on the client to match the accepted computer
  5. inspect the broker.bpickle file and note the value of secure_id
  6. run landscape-config --silent --register-if-needed
  7. observe no new pending computer is created.
  8. inspect the broker.bpickle file and note that the value of secure_id has not changed
  9. try to break something

if config.silent:
should_register = False

if config.force_registration:
Copy link
Contributor

@srunde3 srunde3 Aug 13, 2024

Choose a reason for hiding this comment

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

nit: you could rearrange this block to make it slightly simpler, if you so desire:

    if config.force_registration:
        should_register = True
    elif config.register_if_needed:
        should_register = not already_registered
    elif config.silent:
        should_register = True
    else:
        ...

Copy link
Contributor

@srunde3 srunde3 left a comment

Choose a reason for hiding this comment

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

LGTM! 🚢 left one pedantic inline nit for your viewing pleasure. Manual testing went well.

@wck0 wck0 merged commit 279baf5 into canonical:main Aug 14, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants