You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@airavata.apache.org by "Marcus Christie (Jira)" <ji...@apache.org> on 2020/03/03 15:19:00 UTC
[jira] [Updated] (AIRAVATA-3126) Implement compute resource
reservation addition
[ https://issues.apache.org/jira/browse/AIRAVATA-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Christie updated AIRAVATA-3126:
--------------------------------------
Description:
# In PGA portal implementation for a compute resource we could add a reservation
# Reservation is to have a dedicate computing time in a cluster queue/partition
# As for the existing PGA implementation we could provide a reservation name and a start and end time for the particular reservation.
# In Django the implementation does not exists.
# First we should have the previous implementation done in Django portal
# Next step would be to improve it by enabling
# Adding a reservation for a particular cluster queue/partition
# Then we should also be able to add multiple reservations for a particular queue/partition. These multiples will have different reservation names and start and end dates.
h5. Data Model
- GroupComputeResourcePreference
-- reservations: list<ComputeResourceReservation>
--- queues: list<string>
--- reservationName
--- startTime
--- endTime
A GroupComputeResourcePreference can have one or more ComputeResourceReservation records. Each ComputeResourceReservation is applicable to one or more queue/partitions for the GroupComputeResourcePreference's compute host. The ComputeResourceReservation also has a name, start date and end date.
h5. TODO
- [ ] how to deal with expired reservations?
-- in the UI have a button to remove all expired reservations
- [ ] Validation: don't allow multiple reservations for the same queue/partition for the same overlapping time period
- [ ] Validation: endTime must be greater than startTime
- [ ] update TaskContext.getReservation() logic where it looks to see if there is a currrently active reservation for the host and queue
- [ ] document the automatic migration script creation logic
- [x] Repository unit test: removing a reservation
- [x] Repository unit test: updating a reservation
- [x] Repository unit test: adding a queue
- [x] Repository unit test: removing a queue
- [ ] Refactor the openjpa MappingTool migration script creation logic
- [ ] remove generate-sql-persistence.xml and maven goal that used it
- [ ] migration for GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime into a ComputeResourceReservation record
h5. Migration Plan
h6. Expand
- database migration to add new tables
- convert GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime into a ComputeResourceReservation record
- (?) trigger to turn new values in GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime into ComputeResourceReservation records
- but I don't think there is any UI or anything updating these fields now
- deploy API server with new ComputeResourceReservation model
h6. Migrate
- Deploy Django UI for managing ComputeResourceReservation records
- Helix tasks should check the ComputeResourceReservation records in addition to GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
h6. Contract
- Helix tasks should stop checking the GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
- Remove data model fields GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime and database columns
was:
# In PGA portal implementation for a compute resource we could add a reservation
# Reservation is to have a dedicate computing time in a cluster queue/partition
# As for the existing PGA implementation we could provide a reservation name and a start and end time for the particular reservation.
# In Django the implementation does not exists.
# First we should have the previous implementation done in Django portal
# Next step would be to improve it by enabling
# Adding a reservation for a particular cluster queue/partition
# Then we should also be able to add multiple reservations for a particular queue/partition. These multiples will have different reservation names and start and end dates.
h5. Data Model
- GroupComputeResourcePreference
-- reservations: list<ComputeResourceReservation>
--- queues: list<string>
--- reservationName
--- startTime
--- endTime
A GroupComputeResourcePreference can have one or more ComputeResourceReservation records. Each ComputeResourceReservation is applicable to one or more queue/partitions for the GroupComputeResourcePreference's compute host. The ComputeResourceReservation also has a name, start date and end date.
h5. TODO
- [ ] how to deal with expired reservations?
-- in the UI have a button to remove all expired reservations
- [ ] Validation: don't allow multiple reservations for the same queue/partition for the same overlapping time period
- [ ] Validation: endTime must be greater than startTime
- [ ] update TaskContext.getReservation() logic where it looks to see if there is a currrently active reservation for the host and queue
- [ ] document the automatic migration script creation logic
- [x] Repository unit test: removing a reservation
- [x] Repository unit test: updating a reservation
- [x] Repository unit test: adding a queue
- [x] Repository unit test: removing a queue
- [ ] Refactor the openjpa MappingTool migration script creation logic
- [ ] remove generate-sql-persistence.xml and maven goal that used it
h5. Migration Plan
h6. Expand
- database migration to add new tables
- convert GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime into a ComputeResourceReservation record
- (?) trigger to turn new values in GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime into ComputeResourceReservation records
- but I don't think there is any UI or anything updating these fields now
- deploy API server with new ComputeResourceReservation model
h6. Migrate
- Deploy Django UI for managing ComputeResourceReservation records
- Helix tasks should check the ComputeResourceReservation records in addition to GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
h6. Contract
- Helix tasks should stop checking the GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
- Remove data model fields GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime and database columns
> Implement compute resource reservation addition
> ------------------------------------------------
>
> Key: AIRAVATA-3126
> URL: https://issues.apache.org/jira/browse/AIRAVATA-3126
> Project: Airavata
> Issue Type: Sub-task
> Components: Django Portal, Registry API
> Affects Versions: 0.18
> Environment: https://django.staging.seagrid.org
> Reporter: Eroma
> Assignee: Marcus Christie
> Priority: Minor
>
> # In PGA portal implementation for a compute resource we could add a reservation
> # Reservation is to have a dedicate computing time in a cluster queue/partition
> # As for the existing PGA implementation we could provide a reservation name and a start and end time for the particular reservation.
> # In Django the implementation does not exists.
> # First we should have the previous implementation done in Django portal
> # Next step would be to improve it by enabling
> # Adding a reservation for a particular cluster queue/partition
> # Then we should also be able to add multiple reservations for a particular queue/partition. These multiples will have different reservation names and start and end dates.
> h5. Data Model
> - GroupComputeResourcePreference
> -- reservations: list<ComputeResourceReservation>
> --- queues: list<string>
> --- reservationName
> --- startTime
> --- endTime
> A GroupComputeResourcePreference can have one or more ComputeResourceReservation records. Each ComputeResourceReservation is applicable to one or more queue/partitions for the GroupComputeResourcePreference's compute host. The ComputeResourceReservation also has a name, start date and end date.
> h5. TODO
> - [ ] how to deal with expired reservations?
> -- in the UI have a button to remove all expired reservations
> - [ ] Validation: don't allow multiple reservations for the same queue/partition for the same overlapping time period
> - [ ] Validation: endTime must be greater than startTime
> - [ ] update TaskContext.getReservation() logic where it looks to see if there is a currrently active reservation for the host and queue
> - [ ] document the automatic migration script creation logic
> - [x] Repository unit test: removing a reservation
> - [x] Repository unit test: updating a reservation
> - [x] Repository unit test: adding a queue
> - [x] Repository unit test: removing a queue
> - [ ] Refactor the openjpa MappingTool migration script creation logic
> - [ ] remove generate-sql-persistence.xml and maven goal that used it
> - [ ] migration for GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime into a ComputeResourceReservation record
> h5. Migration Plan
> h6. Expand
> - database migration to add new tables
> - convert GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime into a ComputeResourceReservation record
> - (?) trigger to turn new values in GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime into ComputeResourceReservation records
> - but I don't think there is any UI or anything updating these fields now
> - deploy API server with new ComputeResourceReservation model
> h6. Migrate
> - Deploy Django UI for managing ComputeResourceReservation records
> - Helix tasks should check the ComputeResourceReservation records in addition to GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
> h6. Contract
> - Helix tasks should stop checking the GroupComputeResourcePreference.reservationName/reservationStartTime/reservationEndTime
> - Remove data model fields GroupComputeResourcePreference.reservation/reservationStartTime/reservationEndTime and database columns
--
This message was sent by Atlassian Jira
(v8.3.4#803005)