Scheduled Tasks - New Image with Task/current-Date

[paranoid64]

I use the “Scheduled Tasks”, but here it would be nice if the images would get a date from the execution time of the task. Is it possible to specify placeholders for the images so that the crontab can insert the current date? The old image should not be overwritten, because I prefer to have 3 old versions. So I go through the images at some point and then delete the images I don’t need. Hence the date. I would have thought of something like this PC_xy_{Y}{m}{d}. The image setting always remains the same. Only the name of the image changes.

[Tom Elliott]

@paranoid64 I don’t understand your request very much.

While it could be done, should it really be done?

You’re asking us to put in a feature to effectively use 2/3 times the amount of storage for each image capture task. Versioning is one method of handling things but generally only useful in small pieces. Ultimately I don’t think this is something that should be added to FOG as it is difficult to manage, and puts your disks in potential danger if you forget that you have 2/3 of the same image.

Can you add more context of how this should be the standard for everyone who uses fog?

[paranoid64]

Of course, you need to make sure that the storage space is large enough. And yes, you must manually ensure that you delete old backups. And it’s only meant to be an optional feature. But Cron Style Scheduled Tasks only makes sense to me if I also have a new image and don’t just overwrite a working one and then it’s broken. It would also be a real relief not to always have to create an image manually beforehand.

Alternatively, it would be a relief if you at least had a copy button for images and only had to enter nine image names. But all these parameters like partition, operating system, … are already taken over.

For example, I am only there every tuesday and would like to back up the machines every tuesday at 16:30. it would be nice if the capcha tasks were not simply created and the images overwritten. i would like to have a backup in case a backup goes wrong.
I only keep 3 versions and delete the old ones manually.

[Tom Elliott]

@paranoid64 I think that’s the subjectivity of the admin I’m afraid.

For you, it doesn’t make sense to schedule a task that is an image capture unless you have the 2/3 latest backups available.

To another, they never would schedule a capture task, and only ever capture when physically approved and agreed.

To yet another, they don’t care that the scheduled capture overwrites because that’s how the manual system works anyway.

Which path should I take as the programmer trying to implement things?

To the idea of “backup”. FOG was never intended to be a backup solution, nor does it pretend to be one. I’m not saying you cannot use it for such a purpose, but us programming these things without a real “useful to all” approach just makes it happy for your usecase, but horrible for the next person (who may just well ask for a feature requesting we do away with that ability altogether.)

A copy/clone method could be useful, though it’d be more toward the definition instead of the actual phsycial files being copied no?

[paranoid64]

This is just a request :-).

So I mean the alternative. You select your image and click on “Duplicate image”, for example. Then a new image is simply created but the settings of the selected image are already in it. So you only have to enter the name and select on Host the new image name to Capture Task.

And I think you make even fog worse than it is :-D. Fog is one of the best tools for this task on my site.

[Tom Elliott]

@paranoid64 I understand it’s just a request, just wanting to expectation set a little as well.

I don’t want a person thinking I’m simply putting your request out of hand vs another having been brought it with seemingly little thought.

I like the idea of the clone approach, when to add is a different question, but I feel like it could be useful to have a definition cloning feature for more than just “images”, but for hosts, groups, etc…

So implementation of such a thing and how best to go about it is the part I have to figure out.

[JJ Fullmer]

@Tom-Elliott @paranoid64
Just to offer another use case for this, if I’m understanding it right. We currently maintain a ‘prev’ version of our image as a separate image.
The idea being if something is wrong with the new ‘stable’ image we can quickly revert to using the ‘prev’ image and continue on.
If when capturing it automatically kept the previous version, we wouldn’t need to manually do that. We don’t actually capture to the prev image, we just created the image definition and manually do a copy of the image on the server before capturing a new stable version.
We typically align this with the windows YYH2 releases.

We could probably do away with our prev image step if the stable image had an automatic history. I mean sure we have snapshot backups of our fog server too if we need it, but it’s always nice to have it at the file level for a quicker restore.

I could see other users wanting that built-in backup copy. But even still I would make it an optional setting to turn on and off, not everyone will have the storage space for 2-3 versions of their image.

[Tom Elliott]

@JJ-Fullmer But should it just be a backup, or just a history that can be reverted between?

How many iterations should we allow? (So we have to track by version number/date, and that there are those different versions, and where they’re located, and dynamically update the “location” path to which ever is the most current version.)

Just thoughts out there, but complicated and too simple to screw up. It really needs a schema thought process (maybe a plugin could do this?)