# Development of an adapter for OAR scheduler
**URL:** https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325
**Category:** Interested In Contributing?
**Created:** [June 23, 2025, 11:29am UTC](https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325 "2025-06-23T11:29:17Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@PaulBreugnot](https://discourse.openondemand.org/u/PaulBreugnot)
#### Post date: [June 23, 2025, 11:29am UTC](https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325/1 "2025-06-23T11:29:17Z")
Hello OOD team,
I am currently working on the development of INRIA’s computing ressources (ABACA).
In order to support OpenOnDemand, we need to develop a new adapter for our scheduler, [OAR](https://oar.imag.fr/).
I already identified where I should place the new adapter, and I think I can handle most of the task taking inspiration from existing adapters.
However, we identified three possible solutions to integrate the adapter:
1. Develop it as a standalone project. The ruby gem can then be installed to our infrastructure as a Debian package with an `ondemand` dependency, and ensure the gem is installed where `ood_core` can find it (looks feasible). This way we can just rely on `ondemand` Debian releases.
2. Maintain our own `ondemand` fork and develop the new adapter there.
3. Develop the adapter in our fork and ask for a pull request on the official `ondemand` upstream when its production ready.
The 2nd solution is probably the worst, but do you have any recommendation for such a case? Would you be interested to integrate the new adapter to OpenOnDemand? If yes, what quality guarantee and / or CI should we support?
Cordially,
Paul Breugnot
---
### Author:  [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)
#### Post date: [June 23, 2025, 1:24pm UTC](https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325/2 "2025-06-23T13:24:48Z")
Yes the 3rd option is what we should do.
> [@PaulBreugnot](#):
>
> If yes, what quality guarantee and / or CI should we support?
That’s entirely up to you. Any bugs in this adapter will only affect you. So only you are in the ‘splash zone’ of any bug you write here. All other centers using say Slurm for example won’t be affected.
Lastly I’d just say that the timing is right for this. We’re basically in the middle of 4.1 development so submitting patches now will ensure that this can make it into 4.1.
---
### Author:  [@PaulBreugnot](https://discourse.openondemand.org/u/PaulBreugnot)
#### Post date: [June 23, 2025, 3:15pm UTC](https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325/3 "2025-06-23T15:15:22Z")
Nice! Thank you for your answer.
I don’t know if I can commit for 4.1 depending on when it is planned, but I will keep you up to date!
---
### Author:  [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)
#### Post date: [June 23, 2025, 3:29pm UTC](https://discourse.openondemand.org/t/development-of-an-adapter-for-oar-scheduler/4325/4 "2025-06-23T15:29:52Z")
Cool. In the interim, you don’t even really need to push it upstream. Here’s an example of adding an adapter through an initializer (I created this one to add it into the demo container). It’s kind of an easier version of #1 above.
Initializers let you add and redefine behavior, so that option is viable too as you’re adding files that OOD will not overwrite when you upgrade.
>