Architecture #8759
closed
Document how to build a standard agent to allow easier usage by external build systems or for new platforms
Description
Hi,
I think the best route forward would be to break out the thin agent as something that is maintained like a normal distro package and not a rudder component.This would mean
- A separate repo
- SPEC and Deb files
- A single version supported (if you check out 3.2.4 you can only build the 3.2.4 agent)
- upstreaming in distros since it would be a normal package without magic
- safely moving to distro openssl etc
- easier porting to newer OS releases and architectures
- easier to port to new OS
- public CI builds and tests of the agent
The full agent wouldn't need to go through this procedure since it is too specific to be upstreamed anywhere anyway
Updated by Florian Heigl over 8 years ago
A single version supported (if you check out 3.2.4 you can only build the 3.2.4 agent)
(... and the sources needed are contained in that repo)
Updated by Benoît PECCATTE over 8 years ago
Thank you for your suggestion.
upstreaming in distros since it would be a normal package without magic
We may never want this since it means we would not control our version support anymore. Ie if a distro ships an outdated version, we would have to support it even if we don't want to.
safely moving to distro openssl etc
This is already the case with the current package (it is easier in master).
easier porting to newer OS releases and architectures
easier to port to new OS
I don't see how it would make it easier.
public CI builds and tests of the agent
Yes !
Updated by Florian Heigl over 8 years ago
Please note that what's in master is not helping anyone who wants to use rudder since that'd require a stable version. :-)
But I'll do my next try based on master :-)
Updated by Benoît PECCATTE over 8 years ago
- Target version set to Ideas (not version specific)
Indeed.
We would like to have all those advantages without having to create a new repository.
Updated by Jonathan CLARKE over 8 years ago
Florian Heigl wrote:
Please note that what's in master is not helping anyone who wants to use rudder since that'd require a stable version. :-)
But I'll do my next try based on master :-)
Right... but if we just rewrite the code in stable branches, and it breaks the next minor release, there's going to be worse complaints, trust me ;)
In short, what is in master today will be stable tomorrow. We have to start somewhere.
Taking a step back: thanks for this ticket. It is a great reminder that we need a simple entry point to build a lightweight, standard, using-OS-dependencies rudder-agent package, to make it much easier for people to explore, understand and test on new platforms. Benoit, you said you don't see how having a standard package makes this easier - the answer is simple, most folk using a "different" system (FreeBSD, slackware, whatever) know what a standard RPM spec file looks like and how to port it to their OS, so if we give them a standard RPM spec file, they have something to work with.
As Benoît said, though, I don't see why this would warrant an independant git repo. If we're leaning anywhere, it would be merging all our git repos into one big monorepo (I'm not saying that's about to happen, just that we're not keen on making even more repos). Florian, do you know of a reason, or a "usual habit" that makes it more standard/understandable/easy for there to be a single package in a single repo?
Updated by Alexis Mousset over 5 years ago
- Subject changed from Please consider to separate rudder-agent-thin from the rudder-packages repo to Document how to build a standard agent to allow easier usage by external build systems or for new platforms
- Category changed from Packaging to Documentation
Currently the agent package is much more modular and can be made "thin" by just setting the right variables in the Makefile, and the rudder-agent-thin doesn't exist anymore.
Updated by Alexis Mousset about 1 year ago
- Status changed from New to Rejected
- Regression set to No
No more agent thin and better Makefiles, closing.