On 12/07/2010 12:39 PM, Ian Main wrote:
On Fri, 2010-12-03 at 12:53 +0100, lmartinc(a)redhat.com wrote:
> git: [patch aggregator] first impl. of adapter for condor backend.
>
> Hey guys,
>
> probably this is going to be very controversial patch. This patch should allow
people
> to be able to use different job-backend if they chose to. I have refactored Condor
backend
> to be easily subtituteable via Adapter pattern. The implementation is just begining,
but
> if at least some of you will like it I will continue to provide at least one other
job-backend (DelayedJobs).
> The intention isn't to replace Condor, but make it optional and not hardcoded.
>
> If there will be no reply or dicussion I will drop this patch.
>
> Thanks for your feedback.
You're right, it is controversial :)
I really hope we do not have alternative backends any time soon.
There's only a handful of people who test/use the aggregator end to end.
If some of these people decide it would be easier to not use condor,
it's just that many fewer people testing critical production code
paths.
I really cannot stress that enough. It's all about testing.. it needs
testing, lots of it, and this just enables it to be tested less.
I think the counter argument to this would be that if we support
pluggable components at multiple levels in our application we can push
deltacloud as being more flexible and more able to fit into a custom
infrastructure. This would drive more adoption which would drive more
testing of deltacloud in general.
We can still only support the one official scheduling backend, through
our docs and maintenance infrastructure, but should a customer have some
custom scheduling / job component already in place, we can also say that
things would work out of the box as is without needing to hack
deltacloud (of course making sure that they understand that support of
their custom components and interaction with them is up to them).
If there is something difficult about the installation we need to
address that (and we are addressing some aspects of it).
To play devils advocate, I could easily create something to replace the
web UI as well, but I don't, because that's a huge part of the product
and it too needs testing and I hope everyone uses/tests it. You see
what I'm saying?
The thing with this is that the deltacloud codebase is able to support
custom web ui's, we just don't support alternatives as a team. Likewise
if an alternative scheduling system were to be developed, great, but we
wouldn't be responsible for any problems that arise from using it. We're
not talking about creating the alternative ourselves, just an easy means
which to be able to use an alternative in hopes that it'll drive
adoption of the whole system in general (and most likely if an end user
wishes to develop and test and alternative they would start by setting
up and testing condor itself first).
Maybe once the whole thing is more mature this would be a good idea,
but
for now I don't think it's appropriate.
Ian
Honestly doesn't matter to me either way, just like playing devil's
advocate myself ;-)
-Mo