-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a way to have Instance Scheduler support a cron-like syntax to build dynamic schedules in the future #536
Comments
Thanks for reaching out! Can you help me understand your use-case a little better? I want to make sure we understand the root problem before attempting to engineer a solution. A few questions that come to mind:
|
Hi @CrypticCabub , Thanks a lot for the quick response. Please see responses below in order:
Thanks again! |
no problem! For your first concern, Instance Scheduler can support multiple cloud formation templates with multiple schedules per template, though I will grant that this just moves the goalpost to CFN service quotas on the hub account. I've seen some similar requests for more schedule control on spoke accounts, but it leads to a difficult question of trying to balance the benefits of centralized control with dispersed flexibility. We could, for example, allow each spoke account to provide its own set of schedules, but then we would have to read dynamodb in every spoke account as well as in the hub account which would complicate troubleshooting and would also have a noticable impact on the solution's baseline running costs. There's also the per-instance tagging approach you mentioned which seems more doable, but that has its own complexities and challenges I would be very curious as to if deploying multiple hub stacks would be sufficient to meet the needs of your customers or not. It is, in-fact, possible to have multiple copies of Instance Scheduler scheduling the same account so long as each copy uses a different namespace and scheduling tag key (no two hubs should ever attempt to schedule the same instance). This raises the complexity of operating the solution substantially though so it's not a perfect answer. |
Hi @CrypticCabub , one more question. Before asking the customers with going with the option to deploy it on their environment. When I first deployed Instance Scheduler the CLI didn't exist so, I haven't had the chance to use it. If use the Create Period from the CLI what would that do? would that create the period on the DynamoDB configuration? If the Cloudformation template were to be update it do you know if that would "override" or for some reason remove the period created via the CLI? The reason why I'm asking is because I'm thinking if there might be a possibility for us to create a service catalog product that would simply run this CLI utility to create the specific periods the customers would need. Instead of manually update the cloudformation template. But I also don't want for it to conflict with the IaC code in the future. |
The CLI is basically a thin wrapper around crud operations on the database. with the create/update commands for schedules and periods basically being put operations with overwrite = false/true respectively. It doesn't currently have a safety check against not overwriting a schedule managed by a cloud formation template, but I will discuss the possibility of adding such a check with the team. |
Spoke with the team about it and took a closer look at the exact behavior when the CLI and CFN Schedules interact. Currently the CLI does not respect CFN-managed schedules, but I am working on adding that behavior in this week as a late addition to our next major release. No formal release date yet, but we're hoping to be able to go live in the next few months. |
That's great! Thank you so much ! 🎉 |
Cli respecting CFN manage schedules has been added in v3.0.0 |
For very similar reasons, I would much prefer for the schedule to be derived from tags on the resources, rather than centrally managed. The team managing the instance scheduler solution is not the same team managing the resources in all the aws accounts, across the entire organization. It introduces a lot of friction across the teams, and a lot of operational overhead, trying to support every teams' schedule requirements. If the schedule were simply part of the tag-interface, it would eliminate all the friction. Users could create/set their own schedules, but the solution could be hosted centrally. |
Hi @CrypticCabub just wanted to let you know we successfully created a Service Catalog product to create schedules for our BU members. The lambda function has the scheduler CLI binary which would take care of creating them Thanks for your help. |
@exolain That's awesome to hear! Would you be willing to share a little more info on how exactly your service catalog product works? You can reply here or email me directly at [email protected]. A few specific questions I have:
|
Hi Cryptic, As for the second question it is a custom resource within the Service Catalog that calls a lambda function that lives in our Shared Services Account. That Lambda function has the layer with the scheduler cli and we access the specific path to run a subprocess to create the schedules from said lambda function. Hopefully that helps. |
We have a really big organization and there are customers who have specific requirements on their schedules. We can have people from Bulgaria/India and London working on the same application and sometimes there schedule might overlap. And a specific set schedule for office hour of a specific region wouldn't be ideal for them
is possible to have an option to use a custom schedule if the time needed is not covered by the ones you are already providing? Perhaps based in a Cron-like syntax.
I understand that the way that the Instance Scheduler is designed right now this might be challenging. But wondering if it can be reviewed as a potential feature in the future.
Please do let me know if you think it might be impossible to implement on the near future.
The idea would be that the customer would provide a tag with the specific cron syntax to stop and start their instances.
Similar to something like:
InstanceSchedulerStart: "0 5 * * *"
InstanceSchedulerStop: "0 17 * * *"
Let me know if you have any questions.
The text was updated successfully, but these errors were encountered: