It's all about the answers!

Ask a question

Collectors


sridevi yv (10632) | asked Aug 17 '10, 5:18 a.m.
hi,
i have ywo questions:
1. why exactly are nested collectors required??
2. the buildforge guide document gives four ways to select servers.. the second way specified is as follows: which i did not understand.. can someone explain this to me??

"Select servers by server pool. You can organize servers into named pools and create a collector for each pool. Define a pool name as a property in the collector (a set-value property). Then create a selector for each pool name. The server resource for a project or step is selected based on its current load."

2 answers



permanent link
Brent Ulbricht (2.5k11) | answered Aug 18 '10, 12:32 p.m.
JAZZ DEVELOPER
hi,
i have ywo questions:
1. why exactly are nested collectors required??
2. the buildforge guide document gives four ways to select servers.. the second way specified is as follows: which i did not understand.. can someone explain this to me??

"Select servers by server pool. You can organize servers into named pools and create a collector for each pool. Define a pool name as a property in the collector (a set-value property). Then create a selector for each pool name. The server resource for a project or step is selected based on its current load."


Hi,

Nested collectors are not required but are an option when creating a collector property. One advantage of using a nested collector (or sometimes it's called an include collector) is that the collector properties are all in one place. Therefore, if you have to change one of the properties and that collector has been included in multiple other collectors - then you only have to make the change in one place instead of making the same change in multiple collectors.

The server pool example is trying to explain that you can use a user set value for selecting from a set of computers that are eligible to run your job. For example, if the user set property has a name of 'POOL' - you might have in the value something like 'TEST' or 'DEV'. Then in your selector you would create a selector property for the manifest property 'POOL' and have it select on a value of whichever you would like (in this example either 'TEST' or 'DEV').

So instead of having the selector set for the explicit name of the server (which is done using BF_NAME) or by dynamic values that are Built-In (like MEM_TOTAL), you can specify your own user set property in the collector that the selector can be set to key off of when choosing which server to run a job.

bju

permanent link
sridevi yv (10632) | answered Aug 19 '10, 1:07 a.m.
hi,
i have ywo questions:
1. why exactly are nested collectors required??
2. the buildforge guide document gives four ways to select servers.. the second way specified is as follows: which i did not understand.. can someone explain this to me??

"Select servers by server pool. You can organize servers into named pools and create a collector for each pool. Define a pool name as a property in the collector (a set-value property). Then create a selector for each pool name. The server resource for a project or step is selected based on its current load."


Hi,

Nested collectors are not required but are an option when creating a collector property. One advantage of using a nested collector (or sometimes it's called an include collector) is that the collector properties are all in one place. Therefore, if you have to change one of the properties and that collector has been included in multiple other collectors - then you only have to make the change in one place instead of making the same change in multiple collectors.

The server pool example is trying to explain that you can use a user set value for selecting from a set of computers that are eligible to run your job. For example, if the user set property has a name of 'POOL' - you might have in the value something like 'TEST' or 'DEV'. Then in your selector you would create a selector property for the manifest property 'POOL' and have it select on a value of whichever you would like (in this example either 'TEST' or 'DEV').

So instead of having the selector set for the explicit name of the server (which is done using BF_NAME) or by dynamic values that are Built-In (like MEM_TOTAL), you can specify your own user set property in the collector that the selector can be set to key off of when choosing which server to run a job.

bju


hi,
regarding the nested collectors, suppose i wanna change a collector property anyways i change it in one single place even if nested collectors aren used right? where are multiple places coming from??

and regarding srever pools, i really did not understand where is "server pool" being used here..its just one server whose name is specifed by using the property "pool" instead of bf_name..then wats the difference between server pool and bf_name???

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.