You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow creating and modifying allocations through the API #47
Currently, /api/allocations only supports reading information about allocations. We should be able to create new allocations via it too.
We need to think about whether the current representation in /api/allocations is the correct, or if there are already existing standards that we can implement, similar to how we implemented SCIM for user memberships.
@knikolla I thought it would be more appropriate to move my questions here. I wanted some context while deciding if/how to redesign the allocations API:
What are the use case for allowing creating/editing allocations through the API? It is only to be used by admins or scripts that we wrote?
With the understanding that our Coldfront allocations are essentially the source-of-truth for our users' resource quota info, we want to freely create/edit/delete allocations with arbitrary quota attributes, and have these actions lead to the appropriate changes in Openstack/Openshift?
@knikolla I thought it would be more appropriate to move my questions here. I wanted some context while deciding if/how to redesign the allocations API:
What are the use case for allowing creating/editing allocations through the API? It is only to be used by admins or scripts that we wrote?
It is both for admins and PIs.
Admins would be able to create, edit, approve, etc. allocations through the API.
PIs would be able to request allocations and change requests through the API.
This is extending the current methods of using the browser to do things to also be exposed through an API.
With the understanding that our Coldfront allocations are essentially the source-of-truth for our users' resource quota info, we want to freely create/edit/delete allocations with arbitrary quota attributes, and have these actions lead to the appropriate changes in Openstack/Openshift?
"Freely" is a loaded term. It does not change the current permission scheme and operations initiated by PIs will still need admin approval (or automated approval as described in other issues), same as when using the UI. This is exposing UI functionality through the API.
@knikolla After doing some looking around, I couldn't find a commonly used API for representing something similar to our resource allocations. The closest open-source API may have been CIMI, but it is old and doesn't seem to have wide use. Other cloud providers like Google has something similar, but I'm not sure if that's what you want.
Let me know if you have any advice on the search, or whether if it's fine for me to extend the allocation API with the current representation we have now.
@morantara pushed. @knikolla Since we want time to test out this API along with possibly scripts built on top of it, should this be prioritized next sprint?
Activity
QuanMPhm commentedon Mar 17, 2025
@knikolla I thought it would be more appropriate to move my questions here. I wanted some context while deciding if/how to redesign the allocations API:
knikolla commentedon Mar 17, 2025
It is both for admins and PIs.
This is extending the current methods of using the browser to do things to also be exposed through an API.
"Freely" is a loaded term. It does not change the current permission scheme and operations initiated by PIs will still need admin approval (or automated approval as described in other issues), same as when using the UI. This is exposing UI functionality through the API.
QuanMPhm commentedon Mar 26, 2025
@knikolla After doing some looking around, I couldn't find a commonly used API for representing something similar to our resource allocations. The closest open-source API may have been CIMI, but it is old and doesn't seem to have wide use. Other cloud providers like Google has something similar, but I'm not sure if that's what you want.
Let me know if you have any advice on the search, or whether if it's fine for me to extend the allocation API with the current representation we have now.
morantara commentedon Apr 7, 2025
@QuanMPhm are there any updates here? do you think this will get completed this sprint?
knikolla commentedon Apr 8, 2025
@QuanMPhm Yes, go ahead with this.
QuanMPhm commentedon Apr 8, 2025
@morantara I will try :)
morantara commentedon May 19, 2025
@QuanMPhm any updates here?
QuanMPhm commentedon May 20, 2025
@morantara This can be pushed out to next sprint. Thank you for reminding me. I'll need to bug a few people to review it.
morantara commentedon Aug 11, 2025
@QuanMPhm any luck getting this reviewed?
QuanMPhm commentedon Aug 12, 2025
@morantara Pushed a few sprints
morantara commentedon Nov 3, 2025
@QuanMPhm its that time again :) should this be moved to a future sprint?
QuanMPhm commentedon Nov 4, 2025
@morantara pushed. @knikolla Since we want time to test out this API along with possibly scripts built on top of it, should this be prioritized next sprint?
joachimweyl commentedon Jul 15, 2026
This issue has been migrated to: CCI-MOC/MOC-issues#271