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
Refactor Item
#3439
Comments
Yesterday and today I invested a large chunk of my day into the documentation of the Cobbler data structures into UML so that the reorganization can be easier done on paper before implementation. The linked draft PR showed that moving the structures around is not as easy as it appeared before. |
My investigation continued today. I will upload the DrawIO diagram as soon as I have a complete first draft available. Atm the document is still under active development. |
The plan I think for this is the following:
|
Okay since GitHub doesn't support diagrams directly in GitHub comments, I have to upload it to a GitHub Gist and post the screenshot here. |
Current state: Desired To-Be state: Gist with drawio diagram: https://gist.github.com/SchoolGuy/4f7da2f292e2ba0fd27bf5bbf5ce5d33
|
The outcome of #3416 (comment) shows that we can remove the tree about configuration management. This will make our main refactoring much easier. |
Is your feature request related to a problem?
As a developer
I want to implement the models that my users use correctly
so that I can provide the necessary features.
Provide a detailed description of the proposed feature
Currently, all Items in Cobbler are assumed to be inheriting from a tree of parent objects. In reality, not all of our models have logical parents that require this. Since the parent logic is a costly operation we should try to make the functionality of it available to items that don't require inheritance.
If we do this in the right way this would also slim down our data structures. Not all items require to have
kernel_options
orautoinstall_meta
dictionaries. As all of these data structures need to be set during serialization and deserialization and this takes CPU cycles that I don't want to spend. Smaller data structures also should mean that there are less errors since there is less room to make those errors.Alternatives you've considered
None
Additional information
This is a braindump by me. Which should act as a tracker for the corresponding PR.
The text was updated successfully, but these errors were encountered: