RFE: Implement a duration capability into schedule

[QuantumPosix]

Most reservations start and end at the same time and as long as a start date and duration is provided will populate the end date accordingly. Give the option to put in a duration into the schedule which automatically calculates the end date of a reservation.

[grafuls]

YAS! 🙌

[sadsfae]

This is a solid improvement and would keep us from having to run this logic in shell.

e.g.

quads-cli --extend-schedule --cloud cloud10 --schedule-end "2019-08-08 22:00"

Replaces this:

modcloud=cloud05
for h in $(quads-cli --cloud-only $modcloud); do quads-cli --mod-schedule $(quads-cli --ls-schedule --host $h | grep $modcloud | grep "end=2019-02-09" | tail -1 | awk -F\| '{ print $1 }') --host $h --schedule-end "2019-03-06 22:00" ; done

[grafuls]

Would be nice to have something like:
quads-cli --extend-schedule --cloud cloud10 --weeks 2

[QuantumPosix]

I agree with @grafuls if we use a date that uses combination of weeks / days to extend to give more granular control as we know what time reservations end .

[sadsfae]

In addition to this RFE we should add the ability to set --extension-interval $weekvalue to the QUADS cloud document and a setting in quads.yml for default_extension_interval to set a default.

1. If --extension-interval is set it overrides default_extension_interval in quads.yml
2. allows for running quads-cli --extend-schedule --cloud cloud10 and not specifying an interval if one isn't given.

Inclusive here should also be a --ls-extension-interval argparse that lists (if any) any custom-set extension intervals.

What this would do is paired with the --extend-schedule command in the
RFE above, extend an assignment based on its defined "extension interval"

If one is not provided it would look to the QUADS configuration file
for the value:

default_extension_interval:

In this way we can simply run quads-cli --extend-schedule --cloud cloud10

Lastly, we will want a way to report extension viability but that is a separate RFE here:

#324

[kambiz-aghaiepour]

This may address what Ashish had issues with. Perhaps based on manager input, each cloud can also have a default length (DL) for extensions. Given that extensions are becoming a necessary evil (considering allocations can be predictive but unforeseen issues or bugs can also create delays necessitating extension requests). How this might work is:

scenario 1:
define a cloud with a 1 week extension default:
quads-cli --force --define-cloud cloud02 --extenstion-dl 1 [... other required options ...]

define a cloud with a 2 week extension defult:
quads-cli --force --define-cloud cloud02 --extenstion-dl 2 [... other required options ...]

and then when you do:

quads-cli --extend-schedule --cloud cloud02

it will use the DL for cloud02. A general setting can also be set in quads.yml as outlined above.

[kambiz-aghaiepour]

interval might be clearer than DL.

[QuantumPosix]

Why cant we just use --extend and add a config parameter in the cloud as a default or an modified extension setting ~ Thanks, Chris

…

On Fri, Mar 20, 2020 at 12:36 PM Kambiz Aghaiepour ***@***.***> wrote: interval might be clearer than DL. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#267 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3IDEHRCHDKNOXGTBSTMVDRIOLOZANCNFSM4HY7QWUQ> .

[sadsfae]

Why cant we just use --extend and add a config parameter in the cloud as a default or an modified extension setting ~ Thanks, Chris

I think that's what we're saying here. We're just including an optional cloud-level setting that overrides the default and also tooling to list any of these overrides via --ls-extension-interval.

#267 (comment)

Related, we'll also implement a way to check extension viability too but via checks against the method handler/lookup needed for implementing #324

[grafuls]

Would be nice to have something like:
quads-cli --extend-schedule --cloud cloud10 --weeks 2

also would be nice to have an additional option like --check for not doing the actual extension but just to verify that the already assigned hosts can be extended.