Mailinglist Archive: opensuse-buildservice (247 mails)

< Previous Next >
Re: [opensuse-buildservice] Proposal for api /build/_workerstatus change
Am Donnerstag, 6. Juni 2013, 15:03:44 schrieb Stephan Kulow:
On 06.06.2013 15:01, Adrian Schröter wrote:
Am Donnerstag, 6. Juni 2013, 12:36:24 schrieb Stephan Kulow:
On 06.06.2013 08:45, Adrian Schröter wrote:
Am Mittwoch, 5. Juni 2013, 16:04:07 schrieb Stephan Kulow:
On 05.06.2013 15:53, Adrian Schröter wrote:
Well, the backend is using the word "sibling" in it's config
currently.
However, this is git master code, nothing is in stone yet. But calling
something "backend" on the "backend" does not sound too wise either...

Perhaps you should start by adding some introduction what
$BSConfig::siblings and $BSConfig::sibling are supposed to be.

Just added this to the BSConfig.pm.template. Is it understandable?


###
# Optional support to split the binary backend. This can be used on
large
servers
# to seperate projects for better scalability.
# There is still just one source server, but there can be multiple
servers
which
# run each repserver, schedulers, dispatcher, warden and publisher
#
# This repo service is the 'home' server for all home:* projects. This
and
the # $reposerver setting must be different on the binary backend
servers. # our $sibling = 'home';
#
# this defines how the projects are split. All home: projects are hosted
# on an own server in this example
# our $partition = [ 'home:' => 'home',
# '.*' => 'main',
# ];
#
# our $siblings = { 'home' => 'http://home-backend-server:5252',
# 'main' => 'http://main-backend-server:5252',
# };

Yes. So $sibling is actually a name and nothing else and $siblings
defines the actual split.

The question still is if you would call yourself a sibling if your the
only child :)

As backend is indeed a $FOO name, I give you another suggestion:
If your main elements are <daemon>, how about <daemons sibling="home"> ?

Then you just leave out the sibling attribute if there is no $sibling.

Also possible, we just need to implement the code which finds the groups
in the UI's then.

It makes IMHO sense that for example the webui shows it as

home: scheduler dispatcher publisher ....
main: scheduler ....

and so on. So, my idea was to have this grouping directly in the XML which
avoids duplicate information and has the grouping already prepared.

I know - I just changed the name of the group element.

ah. fine with me as well.

--

Adrian Schroeter
email: adrian@xxxxxxx

SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284
(AG
Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany



--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >