RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
The targetcli configuration is easy to lost since it only backup the latest configuration.


Version-Release number of selected component (if applicable):


How reproducible:


Consider the following scenario.
Steps to Reproduce:
1. /> set global auto_save_on_exit=true
2. service targetcli stop
>> this will execute 'targetcli clearconfig confirm=true' to cleanup the current targetcli configuration
3. run targetcli then exit, the current configuration will saved and the users will lost their previous configuration.

So we should have several enhancement.
1. when execute 'service targetcli stop' please notice the users what happens.
It should tell the user the current configuration is cleaned and if they want to restore it please run 'service targetcli start' or targetcli restoreconfig

2. please don't overwrite the /etc/target/saveconfig.json.backup, rename it to saveconfig.json.backup.2012xxxx etc and move it to /etc/target/backup.

The /etc/target/saveconfig.json is important so we should keep tracking the its changes.
  
Actual results:


Expected results:


Additional info:

It's better to automatically archive/backup existing targetcli configuration.

1. I don't know if systemd has capabilities to output messages to the user when units are started/stopped.

2. Yes it would be nice to keep maybe X last configurations (X=10 maybe), labeled by date. I'll work on that.

(In reply to comment #3)
> 1. I don't know if systemd has capabilities to output messages to the user
> when units are started/stopped.
> 
> 2. Yes it would be nice to keep maybe X last configurations (X=10 maybe),
> labeled by date. I'll work on that.

I vote for keeping multiple last configurations.

we now keep 10 previous configs.