pinsetter disablement

Bryan Kearney bkearney at redhat.com
Mon Aug 8 12:38:45 UTC 2011


On 08/08/2011 08:33 AM, jesus m. rodriguez wrote:
> On 08/08/2011 08:14 AM, James Bowes wrote:
>> On Fri, Aug 05, 2011 at 05:51:05PM -0400, jesus m. rodriguez wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> My initial approach was to add a candlepin.pinsetter.enable
>>> config, then check that in CandlepinContextListener:
>>>
>>>     if (config.getBoolean(ConfigProperties.ENABLE_PINSETTER)) {
>>>       pinsetterListener = injector.getInstance(
>>>         PinsetterContextListener.class);
>>>       pinsetterListener.contextInitialized();
>>>     }
>>>
>>> This seemed so elegant. Clearly I was wrong, it breaks all
>>> the async jobs including refresh pools.
>>>
>>> Next idea was to check the config property in PinsetterKernel.
>>>
>>>     public void startup() throws PinsetterException {
>>>       try {
>>>         scheduler.start();
>>>         if (config.getBoolean(ConfigProperties.ENABLE_PINSETTER)) {
>>>           configure();
>>>       ...
>>>     }
>>>
>>> When the config is set to false, this would keep pinsetter
>>> running enough to execute async jobs, by basically ignoring
>>> all the configured tasks. So far so, good right? Wrong again,
>>> this would also disable the CancelJobJob rendering job
>>> cancellation useless.
>>>
>>> The only option I see seems very kludgey, it would be to
>>> check the config in the configure() method of PinsetterKernel.
>>> If false, schedule ONLY the CancelJobJob as the only long
>>> running task. This will allow job cancellation to work
>>> as well as async jobs, but disables all other jobs.
>>>
>>>     private void configure() {
>>>       ...
>>>       if (config.getBoolean(ConfigProperties.ENABLE_PINSETTER)) {
>>>         // schedule CancelJobJob nothing else.
>>>       }
>>>       ...
>>>
>>> Thoughts? Any other ideas?
>>
>> This seems correct to me. async jobs and the canceljobjob are very
>> special cases; in fact, if we were comfortable with ensuring that the
>> canceljob call would always happen on the pinsetter node running the job
>> to be cancelled, I'd rather just replace it with a synchronous call,
>> rather than a job scheduling.
>
> Sadly the canceljobjob, I hate that name btw, prefer KillahJob),
> in a clustered mode you might request cancellation on one host
> but the job is on another.
>


Wait.. you have to cancel a job on the same host as it is running? My 
first thouhgt was with James.. if we can get the async jobs working 
(evern if fielded by a back end server) then I am fine with that.

-- bk





More information about the candlepin mailing list