Repository navigation
Allow creating and modifying allocations through the API #47
Description
Activity
@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.
Reacted by Quan Pham@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.
@QuanMPhm are there any updates here? do you think this will get completed this sprint?
if it's fine for me to extend the allocation API with the current representation we have now.
@QuanMPhm Yes, go ahead with this.
Reacted by Quan Pham@QuanMPhm are there any updates here? do you think this will get completed this sprint?
@morantara I will try :)
@QuanMPhm any updates here?
@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.
@QuanMPhm any luck getting this reviewed?
@morantara Pushed a few sprints
@QuanMPhm its that time again :) should this be moved to a future sprint?
@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?
This issue has been migrated to: CCI-MOC/MOC-issues#271
Currently,
/api/allocationsonly 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/allocationsis the correct, or if there are already existing standards that we can implement, similar to how we implemented SCIM for user memberships.