Changing parameter in saptune note without reverting note

[frepkovsky]

Hello,

I have a question about saptune v2 and what is the process for changing parameter managed by saptune without need for reverting particular saptune note.

Currently I see the only way how to do it is by:

1.) changing the parameter in saptune note configuration file
2.) reverting saptune note parameters by 'saptune note revert '
3.) re-applying saptune note parameters by 'saptune note apply '

but this will reset the parameters to a default values for a while (revert) and then set proper value (apply) and this may cause issues.

I know it can be changed out of saptune by:

1.) changing the parameter out of saptune (i.e. by sysctl =)
2.) changing the parameter in saptune note configuration file and that's it

but is it possible by saptune itself without reverting to the defaults first?

thanks

Frantisek

[angelabriel]

Hi Frantisek,

instead of using an override file for the sap note changes (which is the way to change SAP Note configurations, but means revert/apply to get the changes take effect), you can use a custom specific note in /etc/saptune/extra to define the new parameter-value pairs you need and then simply apply this custom note. The command 'saptune note create <your_note_name>' may help you by creating the custom note. And please take a look at the man page saptune_v2(8) and read the section 'VENDOR SUPPORT'. This may help you too.

regards
Angela

[frepkovsky]

Hi Angela

I know about extra notes we do use them for parameters that are not part of any original notes shipped with saptune.

If I need to change parameter defined in extra note1, I will have to create new extra note2 put the parameter with new value there and then apply note2. I would say this is just a workaround, I see disadvantage with this approach:

• With every change we bring new extra saptune note but we would like to keep clean setup in our environment and change parameters within the defined extra notes (just change version of the note).

• The same parameter is then defined in more extra notes / configuration files. Original note1 is then reporting non-compliant parameter because it was moved and changed in note2. Unless I remove it from note1 configuration 'saptune note verify' will report errors.

I see this as possible candidate for new saptune feature request. In example, if I run 'saptune note apply ' for existing note and if there is non-compliant parameter (because it was changed in the configuration or because the parameter was changed out of the saptune i.e. by other os tool) it will set it to the correct value. Or it can be some new option for remediation of non-compliant parameters detected for saptune note.

Best regards

Frantisek

[angelabriel]

Hi Frantisek,

the current behavior that saptune is not (re)applying a note, if this note is currently applied, even if there are parameter value changes in the note definition file, is by intention. It was one of the main requests of many of our customers and partners for the rework in saptune version 2. They want to have the control, when the parameter changes take effect (during reboot or by a manual 'revert'/'apply' operation during a maintenance window, but not by accident when only typing 'saptune note apply' for an already applied note)

So at the moment the only way to go is: change the note definition (your custom note or use an override file for your note), revert the already applied note and immediately apply the note again.

But please feel free to file a feature request (by your SUSE contact) for an additional saptune 'note' operation that will help to solve your situation. So we can create an additional operation like 'saptune note reapply ' or may be better use a flag like '--force' for 'saptune note apply '.

Regards
Angela

[frepkovsky]

Hi Angela,

Thanks for your quick response, it is very appreciated! We would like to have such function to re-apply note which is currently activate without reverting it. As you suggested, we will request it via our HANA solution supplier / SUSE partner.

Best regards

Frantisek

[thomas-merz]

Hi @angelabriel ,
I really would also appreciate that saptune could do every solution apply and doing a solution revert "automatically" by a new parameter. It's so bad that we have to revert old solutions and then apply a new one (had to change HANA to S4HANA-APP+DB):
Today I had to do this on 120 SAP-VMs (by script/config-management) and about 80 failed because of saptune currently in use, try later because this lockfile prevented saptune from correct working 😞

saptune/system/lock.go

Line 37 in 9cf9161

ErrorExit("saptune currently in use, try later ...", 11)

saptune/system/lock.go

Line 12 in 9cf9161

var stLockFile = "/run/.saptune.lock"

[thomas-merz]

Or should I open a new issue because lockfile wasn't released/removed properly after revert, so that all other actions would fail until reboot? We are doing revert and apply by Puppet config management, so it happens quite fast one after the other… But in real life I would also have done it like this:

sudo saptune solution revert HANA && sudo saptune solution apply S4HANA-APP+DB

[angelabriel]

@thomas-merz

1. it seems that you have at least 2 processes running on the VM calling saptune in parallel to do something. And that is exactly the situation we need to prevent by using the lock file. You need to wait until the first operation 'revert' is (successfully) done and then start the next operation 'apply'. We can not run such operations in parallel as they work on (modify) the same system files, system parameter and internal saptune files.
   May be the automation script calling 'saptune' is started multiple times on the same VM? Or the automation tries to work in parallel instead of serializing the tasks.

2. This lock file is set, when 'saptune' is started and it will be removed at the end of the work before 'saptune' is terminated. Only if something is broken on the system, so that saptune is not able to terminate in a normal way, the lock file may be left.
   But as is works without problems on some (40) of your systems it seems not to be a general problem.
   Did the 'revert' operation return with an error on the systems with the 'surviving' lock file? So is the return value of the 'revert' operation the difference between the working and the non-working systems? And is the lock file really left over after saptune was terminated normally? Or is the process stopped during it's work (kill?).
   At the moment I have no idea (beside what I mentioned in 1.) what may be the problem. If we need to follow up, please open a ticket with your SUSE support and provide the needed logs/support config information from a system, which failed. And if possible a description, what exactly the automation script is doing. So that we will have a chance to find out, what happened.
   A github issue is not the right place for a deeper and may be longer bug hunting.

3. If really a lock file is left over, you do not need to reboot the system to get rid of the lock.
   saptune lock remove
   should work too. But please use with caution.

4. Having a saptune operation, which is first doing a 'revert' and then doing an 'apply' should be possible. But that is different from what this original issue is talking about. Here the requirement is explicitly 'NO' revert of the note/solution but only apply the changed parameter values. Which is a much more complex operation than your wish.
   So feel free to file a feature request (by your SUSE contact) for an additional saptune 'note' and/or 'solution' operation which will suit your needs. Highly appreciated. A complete description what exactly should be done - the expectations - would be really helpful.

[thomas-merz]

1. Puppet starts every saptune execution sequentially - but if I understand you right: "something" triggered by saptune might be keep running in the background? But the lock-file never vanishes - even some hours later.
2. You're right - we won't be able to do a RCA on GitHub. So let's forget this until next occurence may come - should I open than an issue at SUSE Customer Center pointing to you?
3. sudo rm /run/.saptune.lock will also do and did this successfully in my case 😉
4. I'm thinking of some kind of a "-force" parameter when doing an apply for the needed revert action before - this should both be prompted ("are you sure? (y/N)") and be forceable ("-y" or something similar).

[angelabriel]

1. Puppet starts every saptune execution sequentially - but if I understand you right: "something" triggered by saptune might be keep running in the background? But the lock-file never vanishes - even some hours later.

No. saptune is not starting things in the background. When saptune has finished the called 'operation' it is terminating with a return value indicating OK (0) or NOK (!=0) and it is removing the lock file.
So the really interesting point is - why is the lock file 'surviving'. And why is it only the case on some systems but not on all. And I do not have an answer right now.

2. You're right - we won't be able to do a RCA on GitHub. So let's forget this until next occurence may come - should I open than an issue at SUSE Customer Center pointing to you?

yes, please. Or ask Ralph to do his magic 😄

3. `sudo rm /run/.saptune.lock` will also do and did this successfully in my case wink

yes of cause. Would only show 'what saptune can do' 😄

4. I'm thinking of some kind of a "-force" parameter when doing an `apply` for the needed `revert` action before - this should both be prompted ("are you sure? (y/N)") and be forceable ("-y" or something similar).

yes, possible. Do not hesitate to sent a feature request (can be informal) where we can discuss the details. We are happy to take it, but will need some time to go thru our internal processes.