On 12/07/2010 12:39 PM, Ian Main wrote:
On Fri, 2010-12-03 at 12:53 +0100, lmartinc@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