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.

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.

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

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.

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

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.