-
Notifications
You must be signed in to change notification settings - Fork 265
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
Job Manager: automate / schedule patching #8018
Comments
Hi, For now, we exposed our RPU mechanism in XO REST API, so it's easy to trigger it with any HTTP request into a cron job or whatever. Our next move will be to integrate that in a planned job, like a backup job but for updates. However, I don't know the state of XO for patching XenServer hosts in the first place, as our focus is obviously more toward XCP-ng than XenServer, as you can imagine. First thing first is to check what we have for XS updates and see if we can expose it in the REST API. |
I also agree with @infecticide as this would be useful for large deployments. Where I last volunteered they would leave their production servers on 24/7 as they were needed, frequently at times for remote working. Updates and/or backups would be scheduled to run over night, and/or during the weekends. When everyone wouldn't be in and/or working, or at least the chances were lower. Not having to have Xen Orchestra or XCP-ng Admin open in order to invoke the updates would be great! We would then be able to schedule, it to run at an appropriate time slot when it won't interfere with other operations, as well as be more generally free to permit the updating. Though it would be good if as part of the scheduling mechanics you could select from different week days and times for when this happens. As well as select from a checkbox whether or not you want it to try again and also from a numerical scroll box how many times for it to try again, before a complete update job failure with appropriate notification(s) about the issue. |
To be sure we are talking about the same thing: is it about scheduling patching for XCP-ng or for XenServer? Now it's two very different things. |
@olivierlambert My one is to do with XCP-ng. But overall though agree with with @infecticide about it being able to schedule patching. Generally the patching mechanics for XCP-ng and XenServer through Xen Orchestra could really do with a generic mechanism which allows for them to be scheduled with the same or a similar user interface. @infecticide Do you agree with my suggested additions to the issue? |
@olivierlambert My request is for Xenserver 8 specifically. I have a ticket open, @Danp2 is working on it. Sounds like XO doesn't yet support the changes to the new XS 8 patching process. I have no issues with what @MrGrymReaper had proposed as add-ons to this. |
Thank you very much for that @infecticide! |
We have a Xenserver 8 environment and the only reasonable way to do patching currently is to use XenCenter. We have a large environment with a large number of VMs and hosts. Patching can sometimes take more than 8 hours.
Our company works with Citrix Virtual Apps and Desktops, as a result the session must be kept active so XenCenter isn't killed and leaves the patching in a broken state. It would be nice to:
A) Not rely on Xencenter
B) Have patching scheduled to begin at a certain time, like 4 or 5AM. Then the technician can login and out of XOA throughout the day to check on it and leave without worrying about the process stopping because XenCenter closed.
The Job Manager seems to be limited to host and vm power actions. Could it be extended to automate patching?
Looks like all the relevant steps are laid out here:
https://docs.xenserver.com/en-us/xenserver/8/update/apply-updates-using-xs
I would like to be able to setup a job to begin patching a pool at a certain time and date. Maybe with a pivot on one-time vs repeat on a schedule.
I had considered writing some powershell to do it instead but having the experts put it into XOA would be better than my scratch ;-)
The text was updated successfully, but these errors were encountered: