Replies: 1 comment 1 reply
-
Hey @kraileth Thanks for this very well thought out feedback. This is definitely something we'll be moving towards with contexts. Once we've got the predicate / only syntax with action level variance implemented (@felipesere has a cool proof of concept) then we can really leverage contexts more. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Here's a few thoughts on context in Comtrya that I hope can lead to a discussion of that topic.
Currently the only supported context seems to be substituting
user.name
when rendering template files. While this is useful it's obvious that users will miss a lot of other possible pieces of system information. Since it's the design and the simplicity that adds a lot to the beauty of Comtrya, I'd like to see if we could do a little brainstorming on what we want to eventually achieve with this as early on as possible. Retrofitting things into a project is always more of a hassle and bears a higher risk of design clashes than when considered early enough.There's three main sources for information that can be used as context:
All of those sources are nice and useful, but I always found especially the weak separation of what could be called "hard facts" and others less than ideal. For that reason I'd like to make a proposal for what the terminology could be like:
1a)
System properties
or "(sys)props": This is every kind of information about the system that Comtrya can extract by whatever means and that is beyond what could be changed by Comtrya. This would be things regarding hardware like CPU architecture, amount of RAM installed in the machine and so on. It also would be which OS the machine runs and its version (?). Yes, the latter is theoretically something that Comtrya could influence since it could run the update process. But as that would require a reboot it would count it among the things that are not directly changable by Comtrya.1b)
System states
or "(sys)states": This is every kind of info about the environment that Comtrya is free to change during runtime. This would be things like: Which hostname does the machine have? Does /tmp/testfile exist and is it a file? Is user foo present on the system? Is package bar installed?With the "atomisation" of Comtrya the project has chosen a path that should lead to providing simple building blocks for actions. I wonder if considering what kind of information is used everywhere and making it available centrally to all potential consumers (atoms or actions) could be the next logical step. As this is potentially another pretty invasive change, it might be best to at least think about it before doing it becomes impractical due to the project having developed in an entirely different direction.
IMHO it makes sense to briefly consider additional sources of information, but to start with I'd very much like to focus on 1a and 1b here. Also this is more about considerations regarding the general structure than exactly what information should be available. A pragmatic "let's add something when it's needed" makes a lot more sense than trying to provide random information in the hope that it will be useful at some point.
E.g. CPU architecture will probably be irrelevant for a long time. A means of letting Comtrya look up if a user already exists, a package is installed or /var/log/baz is a directory and providing the answer to the atom / action could however be much more helpful than letting the atoms or actions do those things on their own all the time. Especially as the number of atoms grows, so potentially do the places where somewhat similar code is being used over and over again which could be DRYed out instead.
Beta Was this translation helpful? Give feedback.
All reactions