Hi Community

 

Often, I get asked by our business sponsors: "Why do we need an ISAM Appliance Liberty Runtime Restart when changing a logo in the templates files" ?  Well they don't report it like that as you could guess; rather it is more in these terms: "Does this Logo change will require a Sunday night change ?" Their concern is more that they wished updates to simple look and feel material could be applied in a bit more streamlined and expeditive method. No matter if we explain them "we could have this done for the next maintenance window (Sunday night)", they are more looking for "Could you get this done tonight ?" and I truly understand that, and I consider it to be a legitimate request.

 

I pondered about this in the past but then our usage of the ISAM Liberty Runtime was more limited to "just" SAML/OAuth where let's admit it, once you nailed to look and feel of those error pages, you are pretty much done. But now with more sophisticated use cases (such as relying on Infomap authentication mechanism) templates content contains lots more than just simplistic "error" page branding, that only gets to be seen rarely (hopefully) by end-users.

 

So, we have lots of content in the Liberty Runtime that does not require a "Runtime restart": mapping rules,  Infomap JS, OAuth API/client definition, …. and there are some that you can't get around a "Runtime Restart" such as Server Connections and Key Stores updates, and I could understand why.

But it always struck me that templates content required a hard "Runtime Restart". In comparison, in ISAM WebSEAL, static content changes are picked immediately and don't require any "restart".

Configuration changes that triggers "Runtime Reload" are more easily manageable as they happen very quickly, and sometime will cause only a 2-5 seconds pauses of activities, you can still push them during your "off-hours" business periods. On the other hand, "Runtime Restart" map to a full Liberty server restart taking 30sec and often more making them harder to be scheduled during "off-hours" when it is supporting various authentication services for mission critical applications (24/7). Yes, behind a load-balancer, and with proper and rich orchestration capabilities, maybe it is possible to lower the perceivable impact into end-users, but it is still a challenge in term of change management because a server restart it still a "server restart" where most of the time, it will indeed restart, but it could also "not restart". This is just to say that it is riskier.

 

Is it just an issue overlooked during Appliance RESTAPI design (meaning a simple "Runtime Reload" would have been sufficient), or does it more relates to more serious restrictions inside the Liberty server dealing with static content ?

 

Your thoughts are welcomed.

------------------------------
Sylvain Gilbert
------------------------------

Hi Sylvain,

From 9.0.2 template pages have not required a full restart and have only needed a runtime reload. If you have encountered some scenarios where a hard restart is required, it would be useful if you could open a support case, or detail the recreation steps and ISAM versions so that we can investigate further.

I just ran a quick test where I changed the template file to point to a different, already imported image and the change immediately took effect after a reload. I also tested changing the content of the image in template files, and again the change took immediate effect after a reload.

Hope this helps.

------------------------------
Jasmine
------------------------------

Hi Jasmine

Just did some quick simple tests (9.0.7.0 and V10):

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Restart", and only then image became unavailable.

With a bit of skepticism (always good to have some available in your toolbox) on previous results, I opted to a slight change:

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Reload" instead, and only then image became unavailable, which is the expected result, even better because it is less drastic than a "Runtime Restart".

So, in conclusion, we have been forcing a "Runtime Restart" for the past year where a "Runtime Reload" would have done the job, and even then I am questioning why we would need to do that now.

It is true that template static content Commit may be the only one that I am aware of in the whole Liberty Runtime component that does not trigger notifications (beyond the usual "Successfully deployed all pending changes"): most or all other Liberty Runtime Commits will trigger either (Runtime Required) of the other (Reload Required) notification. 

So we can call this a false positive ! Great, no Case to open, no open source code to fix. Just our own code to fix.  

Thanks

 

------------------------------
Sylvain Gilbert
------------------------------

Original Message:
Sent: Mon August 03, 2020 08:24 PM
From: Jasmine Smith
Subject: Hard Runtime Restart on templates content deploy

Hi Sylvain,

From 9.0.2 template pages have not required a full restart and have only needed a runtime reload. If you have encountered some scenarios where a hard restart is required, it would be useful if you could open a support case, or detail the recreation steps and ISAM versions so that we can investigate further.

I just ran a quick test where I changed the template file to point to a different, already imported image and the change immediately took effect after a reload. I also tested changing the content of the image in template files, and again the change took immediate effect after a reload.

Hope this helps.

------------------------------
Jasmine
------------------------------

Hi Sylvain,

I'm glad to hear a reload is working! However, I think that a fix is still required in the Verify Access code. At a minimum the "Reload required" flag should be correctly set to true, and the correct notification about an automatic reload or a reload being required should show up after the pending changes commit.

I've been able to reproduce this locally, and we'll be fixing this in the next version of Verify Access. If you'd like the fix to be backported, feel free to open a support case so that we can make a fixpack for you.

------------------------------
Jasmine
------------------------------

Original Message:
Sent: Tue August 04, 2020 10:45 AM
From: Sylvain Gilbert
Subject: Hard Runtime Restart on templates content deploy

Hi Jasmine

Just did some quick simple tests (9.0.7.0 and V10):

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Restart", and only then image became unavailable.

With a bit of skepticism (always good to have some available in your toolbox) on previous results, I opted to a slight change:

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Reload" instead, and only then image became unavailable, which is the expected result, even better because it is less drastic than a "Runtime Restart".

So, in conclusion, we have been forcing a "Runtime Restart" for the past year where a "Runtime Reload" would have done the job, and even then I am questioning why we would need to do that now.

It is true that template static content Commit may be the only one that I am aware of in the whole Liberty Runtime component that does not trigger notifications (beyond the usual "Successfully deployed all pending changes"): most or all other Liberty Runtime Commits will trigger either (Runtime Required) of the other (Reload Required) notification. 

So we can call this a false positive ! Great, no Case to open, no open source code to fix. Just our own code to fix.  

Thanks

 

------------------------------
Sylvain Gilbert
------------------------------


Original Message:
Sent: Mon August 03, 2020 08:24 PM
From: Jasmine Smith
Subject: Hard Runtime Restart on templates content deploy

Hi Sylvain,

From 9.0.2 template pages have not required a full restart and have only needed a runtime reload. If you have encountered some scenarios where a hard restart is required, it would be useful if you could open a support case, or detail the recreation steps and ISAM versions so that we can investigate further.

I just ran a quick test where I changed the template file to point to a different, already imported image and the change immediately took effect after a reload. I also tested changing the content of the image in template files, and again the change took immediate effect after a reload.

Hope this helps.

------------------------------
Jasmine

Glad to hear Jasmine that you take this missing notifications behavior back to the dev team. I had some mix feeling yesterday after my post about my reported observations.

Correcting this behavior will improve consistency across restapi and lmi experience. 

Thanks 

------------------------------
Sylvain Gilbert
------------------------------

Original Message:
Sent: Wed August 05, 2020 08:08 PM
From: Jasmine Smith
Subject: Hard Runtime Restart on templates content deploy

Hi Sylvain,

I'm glad to hear a reload is working! However, I think that a fix is still required in the Verify Access code. At a minimum the "Reload required" flag should be correctly set to true, and the correct notification about an automatic reload or a reload being required should show up after the pending changes commit.

I've been able to reproduce this locally, and we'll be fixing this in the next version of Verify Access. If you'd like the fix to be backported, feel free to open a support case so that we can make a fixpack for you.

------------------------------
Jasmine
------------------------------


Original Message:
Sent: Tue August 04, 2020 10:45 AM
From: Sylvain Gilbert
Subject: Hard Runtime Restart on templates content deploy

Hi Jasmine

Just did some quick simple tests (9.0.7.0 and V10):

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Restart", and only then image became unavailable.

With a bit of skepticism (always good to have some available in your toolbox) on previous results, I opted to a slight change:

1. Deleted an image (JPG) under "C\static"
2. Encountered the usual yellow Pending Commit notification which I reacted to with a "Deploy".
3. Then obtained "Successfully deployed all pending changes" with no further notification (Manual Restart Required nor Reload was reloaded), as you indicated. Good.
4. Checked the "Runtime Required" and "Reload Required" and both report "False".
5. Tried to access the deleted JPG and it was still there (accessible) from Web Browser remotely (not from the LMI however).
6. Then performed a manual "Runtime Reload" instead, and only then image became unavailable, which is the expected result, even better because it is less drastic than a "Runtime Restart".

So, in conclusion, we have been forcing a "Runtime Restart" for the past year where a "Runtime Reload" would have done the job, and even then I am questioning why we would need to do that now.

It is true that template static content Commit may be the only one that I am aware of in the whole Liberty Runtime component that does not trigger notifications (beyond the usual "Successfully deployed all pending changes"): most or all other Liberty Runtime Commits will trigger either (Runtime Required) of the other (Reload Required) notification. 

So we can call this a false positive ! Great, no Case to open, no open source code to fix. Just our own code to fix.  

Thanks

 

------------------------------
Sylvain Gilbert


Original Message:
Sent: Mon August 03, 2020 08:24 PM
From: Jasmine Smith
Subject: Hard Runtime Restart on templates content deploy

Hi Sylvain,

From 9.0.2 template pages have not required a full restart and have only needed a runtime reload. If you have encountered some scenarios where a hard restart is required, it would be useful if you could open a support case, or detail the recreation steps and ISAM versions so that we can investigate further.

I just ran a quick test where I changed the template file to point to a different, already imported image and the change immediately took effect after a reload. I also tested changing the content of the image in template files, and again the change took immediate effect after a reload.

Hope this helps.

------------------------------
Jasmine