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

grains: Split os_data into smaller functions #61597

Merged
merged 7 commits into from
Sep 26, 2022

Conversation

bdrung
Copy link
Contributor

@bdrung bdrung commented Feb 7, 2022

The os_data function is huge (531 lines for one function is too long) and also deeply nested (8 levels deep). That make reading, modifying, and testing this function harder.

Split os_data into smaller functions to a readable 167 lines with only a nesting level of three.

os_data has a case-like statement to differentiate the different operating systems, but this is split into two parts.

To make the code more readable, combine all case-like statement in os_data to use one long if-elif chain.

@bdrung bdrung requested a review from a team as a code owner February 7, 2022 22:44
@bdrung bdrung requested review from krionbsd and removed request for a team February 7, 2022 22:44
@bdrung bdrung force-pushed the split_os_grain branch 2 times, most recently from bd7eea1 to 3711114 Compare February 8, 2022 10:32
@bdrung bdrung changed the title Split os_data into smaller functions grains: Split os_data into smaller functions Feb 8, 2022
@bdrung bdrung force-pushed the split_os_grain branch 3 times, most recently from 1f9d621 to 61b9d1e Compare February 9, 2022 17:49
@bdrung
Copy link
Contributor Author

bdrung commented Feb 9, 2022

Rebased and added two more commits. os_data is now much cleaner and readable.

@bdrung
Copy link
Contributor Author

bdrung commented Feb 11, 2022

Rebased and added a test case for _linux_lsb_distrib_data().

@Ch3LL Ch3LL added the P1 Priority 1 label Sep 19, 2022
@dmurphy18 dmurphy18 requested review from dmurphy18 and removed request for krionbsd September 22, 2022 18:42
Copy link
Contributor

@dmurphy18 dmurphy18 left a comment

Choose a reason for hiding this comment

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

@bdrung Need to resolve the file conflicts and wondering how this interacts with changes in PR #61626, that is, does one need to be integrated before the other ?

Also needs a changelog entry

@dmurphy18 dmurphy18 added the Sulfur v3006.0 release code name and version label Sep 22, 2022
The `os_data` function is huge (531 lines for one function is too long)
and also deeply nested (8 levels deep). That make reading, modifying,
and testing this function harder.

Split `os_data` into smaller functions to a readable 167 lines with only
a nesting level of three.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
`os_data` has a case-like statement to differentiate the different
operating systems, but this is split into two parts.

To make the code more readable, combine all case-like statement in
`os_data` to use one long if-elif chain.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
Move fetching `lsb_distrib_*` grains into separate function
`_linux_lsb_distrib_data` to make `_linux_distribution_data` shorter.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
To make the code easier to read, set `os_family` in each branch in
`os_data()`. Most branches have an hard-coded OS family and can be
dropped from `_OS_FAMILY_MAP`. The dictionary `_OS_FAMILY_MAP` is now
only used for deriving the OS family of Linux.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
In `os_data()` only the kernel branch for `SunOS` might not set the `os`
grain. To make the code easier to read, ensure that `os` is set in each
branch in `os_data()`.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
The test cases for `os_data` do not cover the case that `lsb_release` is
imported successfully. So add a test case for that.

Signed-off-by: Benjamin Drung <benjamin.drung@ionos.com>
@bdrung
Copy link
Contributor Author

bdrung commented Sep 22, 2022

@dmurphy18 #61626 is the final merge request containing all changes. Since that merge request is big, I split it into multiple smaller chunks (that stack on each other). This merge request is the first one. I rebased it on master and resolved the conflict.

dmurphy18
dmurphy18 previously approved these changes Sep 23, 2022
@dmurphy18 dmurphy18 dismissed their stale review September 23, 2022 21:28

Forgot still needs a changelog entry

Copy link
Contributor

@dmurphy18 dmurphy18 left a comment

Choose a reason for hiding this comment

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

Sorry forgot this will still need a changelog entry before can approve and merge.
Retrying failing tests - passed, but changes looks good.

@bdrung
Copy link
Contributor Author

bdrung commented Sep 23, 2022

Why does this pull request need a changelog entry? It does not change anything for the user. Only #61626 has user facing changes and changelog entries.

@dmurphy18
Copy link
Contributor

@bdrung Sorry, so used to everything needing a changelog. You are correct, if it did not impact user and was only internal things it does not add a changelog, approving this

@Ch3LL Ch3LL merged commit 27353ab into saltstack:master Sep 26, 2022
@bdrung bdrung deleted the split_os_grain branch September 26, 2022 22:39
@bdrung
Copy link
Contributor Author

bdrung commented Sep 26, 2022

Thanks. The next pull request in this series is #61589

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 Priority 1 Sulfur v3006.0 release code name and version
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants