Description of problem: The locked template is getting overridden by default and without setting force option to True. Interestingly the Locked Template gets unlocked automatically to allow the modification of itself or maybe the new template is getting created. Version-Release number of selected component (if applicable): Satellite 6.3.0 snap 5.0 How reproducible: Always Steps to Reproduce: 1. Create and import a template from a source # hammer import-templates --repo localdirectory --filter jack (I did try with filter and I m not sure how it works without filter) 2. Lock the template # hammer template update --id 542 --locked 1 3. Update the template in source but not name. 4. Using hammer try to reimport a template. hammer import-templates --repo localdirectory --filter jack Actual results: 1. The template gets updated even though the template is locked 2. The template is unlocked or newly created Expected results: 1. The template should not be updated by default or without force option when it is locked. 2. The template should not be unlocked or newly created on reimport. Additional info:
The the update of templates is influenced by 2 settings: force and lock, both are false by default. 'lock' determines whether the imported templates will be locked and prevented from being changed, 'force' determines whether to disregard the template lock and update the template anyway. Note that the template lock is just another template attribute and it can be changed by the options that are used for import. With that said, steps from comment #1 do not update locked templates. They first unlock the templates (based on default 'lock: false' setting) and then update them. If you use the '--lock true' in step 4., then newly created templates will be locked and no existing templates will be updated if they are already locked. If existing templates are unlocked, they will be updated and locked afterwards. If you use the '--lock true --force true', newly created templates will be locked and all existing will be updated and locked. Is this behaviour acceptable? Are there any specific changes that you would like to see? Do you think that adding a default option 'do not modify' for lock setting could result in a more expected default behaviour?
Hi ondrej, What I understand from Lock and Force terms is: Lock :- For New - Lock the template as soon as the new template is imported For Existing Locked and Same name - Don't do anything as its locked untill force is used, keep the template locked For Existing Unlocked and Same name - Do update the template regardless of force, and lock the template Force :- For New: NA For Existing Locked and Same name - Do update the template, keep locked For Existing Unlocked and Same name - NA But, In this bug, My template was locked, and on reimporting the template without force option the template was updated. Also the template was unlocked. These both behaviors was not accepted in case of locked = True and Force = False.
To sum up the previous discussion: The behaviour is reproducible as per steps in comment #1. However, it is not bug because the default value for 'lock' option is 'false', which unlocks the template so it can be updated. For various workflows see comment #2. The fact that this bug was raised shows a possible usability problem. Therefore I would like to turn this into a feature request that would make a locking on import more user friendly, but it may not be ready in 6.4 time frame. Cloning upstream.
Created redmine issue http://projects.theforeman.org/issues/24089 from this bug
Upstream bug assigned to oprazak
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24089 has been resolved.
@ondrejk, I have a query on how does this RFE implemented? Specifically, I wanted to understand, how does reimporting the "locked template" with some changes in the source template unlocks the template in satellite, updates the changes, and locks back. In short, I need a correct/sweet path to achieve expected result. But for me, the expected behavior is working as mentioned in the bug description now.
For updating locked templates, there is 'force import' option. This RFE extends the lock option for import with additional choices so that the lock attribute on existing templates does not have to be modified.
@oprazak: It would help if you can help understnading these options in detail to verify this RFE - Options are : 'lock', 'keep_lock_new', 'keep', 'unlock', 'true', 'false', '0', '1'
There are 4 possible options: lock, keep_lock_new, keep, unlock. 0, 1, true and false were kept for backwards compatibility and behave in the same way they used to. lock is the same as 1 or true - locks all templates unlock is the same as 0 or false - unlocks all templates keep_lock_new does not modify the lock for existing templates and locks newly created templates keep does not modify the lock for existing templates and keeps the newly created templates unlocked
rified! @Steps for orginal reason of bug: ------------------------ 1. Create and import a template from a source # hammer import-templates --repo localdirectory --filter jack 2. Lock the template # hammer template update --id 542 --locked 1 3. Update the template in source but not name. 4. Using hammer try to reimport a template. hammer import-templates --repo localdirectory --filter jack Behavior: ---------------------- 1. The template is not updated by default or without force option when it is locked. The RFE is raised for point 2 in expected behavior in Desription of this bug: Steps for RFE: ------------------ Combinations for options mentioned in comment 16 those are : lock, unlock, keep, keep_lock_new 1. Lock: - Import new, imports new template as locked PASS - Reimport unlocked, reimports template and locks the existing PASS - Reimport locked, reimports template and keep locked the existing PASS 2. Unlock - Import new, imports new template as unlocked PASS - Reimport unlocked, reimports template and keeps unlocked the existing PASS - Reimport locked, reimports template and locks the existing PASS 3. keep_lock_new: - does not modify the lock(unlocked kept unlocked, locked kept locked) for existing templates and locks newly created templates 4. keep - does not modify the lock(unlocked kept unlocked, locked kept locked) for existing templates and keeps the newly created templates unlocked
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.8 release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:4366