[Piuparts-devel] concerning master-slave packaging

[Dave Steele]

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
appropriately.

>> 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.