[Piuparts-devel] concerning master-slave packaging
dsteele at gmail.com
Fri Jun 15 10:37:27 UTC 2012
On Thu, Jun 14, 2012 at 4:53 AM, Holger Levsen <holger at layer-acht.org> wrote:
> What I ment was that (I think) the only sensible solution which can work out
> of the box when _just_ using "apt-get install..." is a single-host only setup.
None of our candidate solutions work out of the box, by design.
Is something like Puppet available for the virtualization scenario?
> (well, unless we implement auto discovery of slaves...)
What are you thinking about here?
>> I question whether there is substantial enough benefit there to
>> justify the cost.
> which cost?
development complexity, vs. install recipes and carrying around extra packages.
>> My second objection to master + slave is the idea that we (I, anyway)
>> don't know enough yet about how this should be set up.
> hm, we have several such setups running?!
I don't think we have thoroughly exercised a packaging solution this
way. My strategy was to install piuparts-server, update piuparts.conf,
and ignore whatever master was up to.
How are you setting up slaves?
>> Consider security. The slave runs, as root, code signed by any one of
>> 1000+ keys.
> yes, we know about this. how is this relevant here?
As a thought experiment. It may be prudent to look at the level of
trust placed in the code that piuparts runs, and package
>> Should all that cruft be separated from slave via piuparts-master, or
>> piuparts-public-display-thingie? Or is it even enough to matter? I
>> don't think we know the answer yet.
> Honestly, I dont get your question...
I question whether master/slave is the right dividing line for
splitting up the packaging. Another candidate split is
generate_daily_reports/http_docs vs everything else, separating
less-trusted code execution from outward facing interfaces. Picking a
line now may be premature optimization.
More information about the Piuparts-devel