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

Project host FQDN #2204

Merged
merged 4 commits into from
Jan 23, 2024
Merged

Project host FQDN #2204

merged 4 commits into from
Jan 23, 2024

Conversation

dottorblaster
Copy link
Contributor

Description

Project the FQDN sent by the agent on the host read model.

How was this tested?

Existing unit tests updated

@dottorblaster dottorblaster added the enhancement New feature or request label Jan 19, 2024
@dottorblaster dottorblaster self-assigned this Jan 19, 2024
@dottorblaster dottorblaster changed the title Project host fqdn Project host FQDN Jan 19, 2024
@dottorblaster dottorblaster marked this pull request as draft January 19, 2024 10:38
@dottorblaster dottorblaster force-pushed the project-host-fqdn branch 2 times, most recently from 0d445b6 to cdc9e2e Compare January 19, 2024 13:49
@dottorblaster dottorblaster marked this pull request as ready for review January 19, 2024 13:58
Copy link
Contributor

@jamie-suse jamie-suse left a comment

Choose a reason for hiding this comment

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

LGTM 🚀

Copy link
Member

@nelsonkopliku nelsonkopliku left a comment

Choose a reason for hiding this comment

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

I am afraid we're missing some parts of the changing fqdn scenario.

During a host's restoration
in execute on line 173 we also need to match the fqdn between the aggregate's state and the incoming RegisterHost command, meaning that the exact same host has been restored and so only a HostRestored is emitted

During a host's details changes detection
in executes on lines 259 and 284 fqdn is not properly taken into account.
In the first command handling we need to match also fqdn between aggregate's state and the incoming RegisterHost so that if they're the same no event is emitted.
In the second command handling, when the previous does not match (aka different details have been detected), we need to get the fqdn from the incoming RegisterHost command and emit it in HostDetailsUpdated (and of course update aggregate's state accordingly in the relevant apply)

Happy to answer any questions.

@dottorblaster
Copy link
Contributor Author

@nelsonkopliku thanks for catching that! About changes detection: totally right, I updated the code accordingly.

About restoration: not a big fan of matching the FQDN in that clause because I don't think it's a relevant detail to base the restoration logic upon, but I don't have a strong opinion either. Change done. 👍

@nelsonkopliku
Copy link
Member

nelsonkopliku commented Jan 22, 2024

@dottorblaster the problem with restoration is that if all other details remain unchanged, BUT fully_qualified_domain_name does change, we are yes going to have a HostRestored event emitted, but not a HostDetailsUpdated resulting in a dirty state both in the aggregate and in the read models.

[EDIT] I guess some tests for the changing fqdn scenario are necessary

@dottorblaster
Copy link
Contributor Author

@nelsonkopliku added a test for a changing FQDN scenario and enriched already existing expectations to include some more fqdn infos.

Copy link
Member

@nelsonkopliku nelsonkopliku left a comment

Choose a reason for hiding this comment

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

Everything looks fine now, thanks!
We might want to have at least one photofinish scenario sending the fqdn, for completeness.

@dottorblaster dottorblaster merged commit c3c511f into main Jan 23, 2024
24 checks passed
@dottorblaster dottorblaster deleted the project-host-fqdn branch January 23, 2024 09:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request user story
Development

Successfully merging this pull request may close these issues.

3 participants