[opensuse-buildservice] Proposal for api /build/_workerstatus change
Hi, current git master code allows to have multiple binary backends with it's own set of schedulers. This has an effect in the status reporting. With only one backend the interface stays like it is currently on api.opensuse.org osc api /build/_workerstatus <workerstatus> .... <waiting arch="x86_64" jobs="381"/> ... <blocked arch="x86_64" jobs="20173"/> ... <buildavg arch="armv5el" buildavg="114238.589179981"/> .... <scheduler arch="x86_64" state="running" starttime="1370304869"> <queue high="0" med="461" low="1439" next="16401"/> </scheduler> ... <scheduler arch="warden" state="running" starttime="1370304793"/> <sibling name="backend1"> <daemon type="scheduler" arch="x86_64" state="running" starttime="1370304869"> <queue high="0" med="461" low="1439" next="16401"/> </daemon> <daemon type="warden" state="running" starttime="1370304793"/> .... </sibling> <sibling name="backend2"> ... </sibling> </workerstatus> That means that old clients may not show data anymore, but they should not crash since all lines were optional anyway (no scheduler or dispatcher may run also in the past) any opinions on that? -- Adrian Schroeter email: adrian@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 05.06.2013 15:30, Adrian Schröter wrote:
Hi,
current git master code allows to have multiple binary backends with it's own set of schedulers. This has an effect in the status reporting.
With only one backend the interface stays like it is currently on api.opensuse.org
osc api /build/_workerstatus
<workerstatus> .... <waiting arch="x86_64" jobs="381"/> ... <blocked arch="x86_64" jobs="20173"/> ... <buildavg arch="armv5el" buildavg="114238.589179981"/> .... <scheduler arch="x86_64" state="running" starttime="1370304869"> <queue high="0" med="461" low="1439" next="16401"/> </scheduler> ... <scheduler arch="warden" state="running" starttime="1370304793"/>
With multiple binary backends you get
I like to change this xml to following structure to solve the following issues * no different meanings of arch= attribute * no need in clients to find the right backend groups (called sibiling)
I only have a small problem with the word sibling in this context. It sounds confusing that you call a group of schedulers one sibling when it's actually a group of things. One sibling is an individual - why not use the name you already used in your text: <backend/> ? Greetings, Stephan -- Bit off more than my mind could chew, Shower or suicide, what do I do? -- Julie Brown, "Will I Make it Through the Eighties?" -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Mittwoch, 5. Juni 2013, 15:48:14 schrieb Stephan Kulow:
On 05.06.2013 15:30, Adrian Schröter wrote:
Hi,
current git master code allows to have multiple binary backends with it's own set of schedulers. This has an effect in the status reporting.
With only one backend the interface stays like it is currently on api.opensuse.org
osc api /build/_workerstatus
<workerstatus> ....
<waiting arch="x86_64" jobs="381"/>
...
<blocked arch="x86_64" jobs="20173"/>
...
<buildavg arch="armv5el" buildavg="114238.589179981"/>
....
<scheduler arch="x86_64" state="running" starttime="1370304869">
<queue high="0" med="461" low="1439" next="16401"/>
</scheduler>
...
<scheduler arch="warden" state="running" starttime="1370304793"/>
With multiple binary backends you get
I like to change this xml to following structure to solve the following issues * no different meanings of arch= attribute * no need in clients to find the right backend groups (called sibiling)
I only have a small problem with the word sibling in this context. It sounds confusing that you call a group of schedulers one sibling when it's actually a group of things. One sibling is an individual - why not use the name you already used in your text: <backend/> ?
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... -- Adrian Schroeter email: adrian@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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', # };
Greetings, Stephan --
Adrian Schroeter email: adrian@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Jun 06, 2013 at 12:36:24PM +0200, Stephan Kulow wrote:
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.
That's what I suggested, but Adrian wants that strange <sibling> element for grouping purposes. I don't like it because you get a different structure if there's a sibling or not. M. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Donnerstag, 6. Juni 2013, 13:53:59 schrieb Michael Schroeder:
On Thu, Jun 06, 2013 at 12:36:24PM +0200, Stephan Kulow wrote:
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.
That's what I suggested, but Adrian wants that strange <sibling> element for grouping purposes. I don't like it because you get a different structure if there's a sibling or not.
We can have a single <sibiling> group as well in that situation, just the "name" attribute is maybe then not available. -- Adrian Schroeter email: adrian@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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. -- Adrian Schroeter email: adrian@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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@suse.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Adrian Schröter -
Michael Schroeder -
Stephan Kulow