Project

General

Profile

Actions

Architecture #8759

closed

Document how to build a standard agent to allow easier usage by external build systems or for new platforms

Added by Florian Heigl over 8 years ago. Updated over 1 year ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Documentation
Effort required:
Name check:
Fix check:
Regression:
No

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)
It would allow for the following things:
  • 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

Actions #1

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)

Actions #2

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 !
Actions #3

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 :-)

Actions #4

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.

Actions #5

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?

Actions #6

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.

Actions #7

Updated by Alexis Mousset over 1 year ago

  • Status changed from New to Rejected
  • Regression set to No

No more agent thin and better Makefiles, closing.

Actions

Also available in: Atom PDF