Support for instance override?

[reidca]

I used a previous version of this solution and I recall there being a way to override the schedules temporarily by adding a new tag on the instance.

Looking (and searching) the documentation I can see no mention of this support in this version.

However, if look in the source code I can see that there is a field in the schedule that the custom resource creates called "OverrideStatus".

However, since this is a) not mentioned in the documentation and b) a field of the schedule rather than a tag to put on the specific instance, I do not think this is what I am looking for.

Can someone who has experience with the project kindly:

1). Tell me if there is a way of temporarily excluding an instance from a schedule or leaving it permanently enabled without removing or altering the "Schedule" key value?
2). Help me understand whether the OverrideStatus is a supported feature of the schedule or not and perhaps explain why it is not mentioned in the documentation of allowable schedule fields? https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/schedule-reference.html

Thank you

[CrypticCabub]

Hi @reidca,

There is not currently a way to temporarily override the behavior of a schedule on a per-instance basis other than changing the schedule tag to some other placeholder schedule that you setup yourself (there is no override-status tag)

The OverrideStatus flag on a specific schedule was removed from public documentation a little over a year ago due to its actual behavior being rather unintuitive and leading to a lot of confusion (the flag does NOT simply set all instances to running/stopped but rather manipulates parts of the internal scheduling logic). This flag does still exist in the code as it is useful for developmental testing purposes, but it should generally be considered a deprecated feature for any production workloads.

[reidca]

Thank you for the prompt reply. I think a comment to this effect (no such feature) on the public documentation would be helpful for those looking for such a thing (especially if you have used previous versions that did have this feature).

Are there any plans to support this feature it is certainly something our teams could make use of.

It was literally the first thing requested when we implemented the solution.

Thanks

[CrypticCabub]

What would be the exact, desired behavior of such an override?

The reason for the removal of OverrideStatus was that we believed that the actual behavior of this particular flag differred substantially enough from what we believed customers would intuitively expect that it would be safer to remove the feature than try to explain the true behavior.

to give an example. suppose I have an instance on a regular 9-5 schedule and I apply the flag overrideStatus: "running" to that schedule at 7pm (when all instances would normally be off). Instance Scheduler would immediately start all instances at the next scheduling interval and then never perform another scheduling action on those instances ever again. Even if you stopped the instances manually, they would never be restarted. The exact reason for this has to do with the interactions taking place between the "schedule status" and the scheduling logic within the solution that I wont try to explain here.

So generally for this reason it seemed preferable to reduce confusion rather than have people discover the unusual behavior when their instances failed to behave as expected.

[reidca]

When I was asking whether you would consider introducing this functionality I was not referring to the the override property of the schedule. (I only discovered that this even existed when searching for the word override in the code). I suggest instead that there are override tags that can be set on an instance that stop scheduling from taking place on that instance only.

I think this is easier for users to comprehend and it only affects their specific instance. It also means they do not need to touch the schedule tag and once the override tag is removed then the scheduling would continue as it did previously.

This would empower the user to opt-out of scheduling for a specific instance due to reasons known only to them. It would mean if the instance is currently running and the override tag is set then the instance would not be stopped. Conversely, if the instance is stopped then and the override tag is present it would not be started either.

There may be a need to have this feature enabled or disabled by an administrator for environments where the cloud team do not want users to be able to opt-out of scheduling - alternatively they could simply stop the user from setting the specific tag using IAM policies.

How does this sound as a feature? It is something that a much earlier version of this solution used to implement.

[CrypticCabub]

Thanks for the clarification! I am not aware of such a feature having existed in Instance Scheduler specifically. Out of curiosity, do you happen to know the version this was supported in?

The feature as you describe is an interesting one that I will take back to the team as one to consider.

One thing we've been thinking about lately is the way in which customers tend to deploy instance scheduler from an organizational persona perspetive. If it's not too much trouble, would you be willing to share how you are currently using Instance Scheduler from in terms of administrative personas/organization? For example, do you currently have a central administrative team deploying/managing instance scheduler's hub stack (an "administrative" persona) with spoke account resource tagging delegated to spoke account users (what I will term as "end users")? or is there some other way in which you are managing the solution

[reidca]

I went back to look at the source code we were using for the instance scheduler (this was in 2018) and it seems that we adapted the existing AWS code to have this feature rather than it being part of the original solution. Apologies, I had assumed it was part of the main system. I do believe it would be very useful however.

In answer to your question, I am in a new team in a new role currently and therefore my/our usage of this is currently simply for our team and our accounts. However, I will be strongly advocating for the wider organisation to adopt this at an AWS organizational level , letting member accounts and autonomous teams make use of the solution by tagging their own resources. This would restrict the flexibility of scheduling decisions (especially in large organizations where platform teams may be quite removed from the users) One thought might be to be able to have "centralised" schedules in a master account and allow these to be overridden (if the same name was used) or supplemented in member accounts. This would make the system very flexible. It would also allow specific time zones to be used for teams where location is different.