C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: +94772207259



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Ruwan Abeykoon
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: +94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Vidura Nanayakkara
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : +94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Lakshman Udayakantha
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: +94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Niranjan Karunanandham
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: +94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Ramith Jayasinghe
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: +94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: +94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Ramith Jayasinghe
what I was thinking is if there is a anyway we can record the fact that this patch is a log/preqa may be by adding (custom?) meta data. 
then at least a warning saying 'there is a pre-qa/log patch available during the server start up.


On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: +94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Niranjan Karunanandham
In reply to this post by Jayanga Dissanayake
Hi Jayanga,


On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Well we do not have to call it "patch", it can be called "update" or some other name :)
 

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Yes, I agree that this will be an empty folder. The reason for my suggestion is that unlike the other components in the lib folder, this temp jar will be of the same version as that in the plugins (since this is a temp jar, IMO we do not need to change the version). Also allowing the jars in the lib folder to overwrite the plugins folder IMO is wrong because lib is the place for the customer to add his components and it should not overwrite the server components, i.e., in the plugins. IMO having this in a separate location would be clean, since then we give that particular directory higher precedence than the plugins folder and this folder should be used for temp purpose only.
 

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Niranjan Karunanandham
In reply to this post by Ramith Jayasinghe

On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <[hidden email]> wrote:
what I was thinking is if there is a anyway we can record the fact that this patch is a log/preqa may be by adding (custom?) meta data. 
then at least a warning saying 'there is a pre-qa/log patch available during the server start up.
I agree with Ramith. In 4.4.x, we mention when patches are applied in the patch.log. IMO it would be better if we can record something similar to this when temp updates are applied to the system. This will help us in the support front by checking the logs if there are any temp jars applied.

 


On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Lakshman Udayakantha
In reply to this post by Niranjan Karunanandham

Yes, I agree that this will be an empty folder. The reason for my suggestion is that unlike the other components in the lib folder, this temp jar will be of the same version as that in the plugins (since this is a temp jar, IMO we do not need to change the version). Also allowing the jars in the lib folder to overwrite the plugins folder IMO is wrong because lib is the place for the customer to add his components and it should not overwrite the server components, i.e., in the plugins. IMO having this in a separate location would be clean, since then we give that particular directory higher precedence than the plugins folder and this folder should be used for temp purpose only.
+1 for this. Since the word is patch abondoned from c5, how about creating a folder called information-collector or log-collector?

Thanks,
Lakshman
 

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Niranjan Karunanandham
In reply to this post by Niranjan Karunanandham
In-addition, in C5 by default, it scans the lib folder and updates the corresponding runtime's bundles.info. But in a production environment, our suggestion is to switch this off so that we can reduce the server startup time. In C5, there is a configuration to switch this off, and there is a separate script file to write selective components in the lib folder to each runtime's bundle.info separately before starting up the server.

Regards,
Nira

On Mon, May 22, 2017 at 2:54 PM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,


On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Well we do not have to call it "patch", it can be called "update" or some other name :)
 

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Yes, I agree that this will be an empty folder. The reason for my suggestion is that unlike the other components in the lib folder, this temp jar will be of the same version as that in the plugins (since this is a temp jar, IMO we do not need to change the version). Also allowing the jars in the lib folder to overwrite the plugins folder IMO is wrong because lib is the place for the customer to add his components and it should not overwrite the server components, i.e., in the plugins. IMO having this in a separate location would be clean, since then we give that particular directory higher precedence than the plugins folder and this folder should be used for temp purpose only.
 

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Jayanga Dissanayake
In reply to this post by Niranjan Karunanandham
Hi Ramith/Nira

On Mon, May 22, 2017 at 2:56 PM, Niranjan Karunanandham <[hidden email]> wrote:

On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <[hidden email]> wrote:
what I was thinking is if there is a anyway we can record the fact that this patch is a log/preqa may be by adding (custom?) meta data. 
then at least a warning saying 'there is a pre-qa/log patch available during the server start up.
I agree with Ramith. In 4.4.x, we mention when patches are applied in the patch.log. IMO it would be better if we can record something similar to this when temp updates are applied to the system. This will help us in the support front by checking the logs if there are any temp jars applied.

​Thanks for the suggestion. Currently, we log a sample message like below when we are updateing the bundles.info file.
 "Successfully updated the OSGi bundle information of Carbon Runtime: default"​

But this happens only once, at the very first time you are starting with the new jar. Consequent restarts would not log the given message as there is no update. In C4 we had patch log, in the C5 we havent thought of such file yet. I would be better to have the custom user bundles and log/pre-qa bundle information in the logs. We will check the possibility of adding this to the logs with minimal effect to the server startup time. 


On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Nisala Nanayakkara
Hi Jayanga,

+1 for maintaining separate directory for log, pre-QA patches/updates with a proper name. I assume that the pre-QA patches/updates are still valid in C5. So names such as "information-collector" or "log-collector" will not be an option. Because this directory will not only contains log patches/updates. Moreover maintaining separate directory will provide us more convenient way to filter the changes into wso2 packed jars and generate a log file with this changes. Since applying log, pre-QA patch/update is only one time task, We can provide command-line option to get updates/patches from this separate directory as Ruwan mentioned. So it will not affect use-cases such as adding DB drivers, configuring additional transports (e.g: JMS) and etc.


Thanks,
Nisala

On Mon, May 22, 2017 at 5:20 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith/Nira

On Mon, May 22, 2017 at 2:56 PM, Niranjan Karunanandham <[hidden email]> wrote:

On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <[hidden email]> wrote:
what I was thinking is if there is a anyway we can record the fact that this patch is a log/preqa may be by adding (custom?) meta data. 
then at least a warning saying 'there is a pre-qa/log patch available during the server start up.
I agree with Ramith. In 4.4.x, we mention when patches are applied in the patch.log. IMO it would be better if we can record something similar to this when temp updates are applied to the system. This will help us in the support front by checking the logs if there are any temp jars applied.

​Thanks for the suggestion. Currently, we log a sample message like below when we are updateing the bundles.info file.
 "Successfully updated the OSGi bundle information of Carbon Runtime: default"​

But this happens only once, at the very first time you are starting with the new jar. Consequent restarts would not log the given message as there is no update. In C4 we had patch log, in the C5 we havent thought of such file yet. I would be better to have the custom user bundles and log/pre-qa bundle information in the logs. We will check the possibility of adding this to the logs with minimal effect to the server startup time. 


On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nisala Niroshana Nanayakkara,
Software Engineer
Mobile | +94 717600022
WSO2 Inc | http://wso2.com/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

Niranjan Karunanandham
Hi all,

On Mon, May 22, 2017 at 10:47 PM, Nisala Nanayakkara <[hidden email]> wrote:
Hi Jayanga,

+1 for maintaining separate directory for log, pre-QA patches/updates with a proper name. I assume that the pre-QA patches/updates are still valid in C5. So names such as "information-collector" or "log-collector" will not be an option. Because this directory will not only contains log patches/updates. Moreover maintaining separate directory will provide us more convenient way to filter the changes into wso2 packed jars and generate a log file with this changes. Since applying log, pre-QA patch/update is only one time task, We can provide command-line option to get updates/patches from this separate directory as Ruwan mentioned. So it will not affect use-cases such as adding DB drivers, configuring additional transports (e.g: JMS) and etc.


IMO we do not need to have a command line option for this. Currently for C5, we have a listener for the lib folder and apply it to the current runtime's bundle.info. In production, the recommendation is to comment this listener and to apply the jars in lib to the runtime's bundles.info using osgi-lib.sh [1]. Similarly for the temp fix / log patch, IMO we can have a separate folder with a listener which by default is commented off so that it does not scan the folder during server startup. Since this is a testing purpose, we do not need a separate command line tool. Only when required for testing purpose, we can enable the listener. It would be better so that we have a proper precedence as below:

"new folder" > plugins > lib
where ">" means higher precedence
 


Thanks,
Nisala

On Mon, May 22, 2017 at 5:20 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith/Nira

On Mon, May 22, 2017 at 2:56 PM, Niranjan Karunanandham <[hidden email]> wrote:

On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <[hidden email]> wrote:
what I was thinking is if there is a anyway we can record the fact that this patch is a log/preqa may be by adding (custom?) meta data. 
then at least a warning saying 'there is a pre-qa/log patch available during the server start up.
I agree with Ramith. In 4.4.x, we mention when patches are applied in the patch.log. IMO it would be better if we can record something similar to this when temp updates are applied to the system. This will help us in the support front by checking the logs if there are any temp jars applied.

​Thanks for the suggestion. Currently, we log a sample message like below when we are updateing the bundles.info file.
 "Successfully updated the OSGi bundle information of Carbon Runtime: default"​

But this happens only once, at the very first time you are starting with the new jar. Consequent restarts would not log the given message as there is no update. In C4 we had patch log, in the C5 we havent thought of such file yet. I would be better to have the custom user bundles and log/pre-qa bundle information in the logs. We will check the possibility of adding this to the logs with minimal effect to the server startup time. 


On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ramith,

Inside the server, there is no way to distinguish whether it is a log/pre-qa, it will just be a bundle with same symbolic name and the version
We might specify log/pre-qa in the zip file we provide to the client.

Can you please explain more on the validations that you would expect, so that I could look more into the possibilities whether those are feasible with the currently proposed methodology.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <[hidden email]> wrote:
is there a way we can flag a patch to be something 'temporary' (such as a log/pre-qa)? if so may be we can do some validation surrounding that?

On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Niranjan,

Having another directory for patches would add an empty directory to the current pack structure. And having the name "patch" is not correct according to the C5 way, as we are proving fixes as updates.

Another point is, having many places to put bundles will complicate our story, Hence, I would prefer to have one place where users put bundles into. If that bundle is having a symbolic name and version equivalent to a one in the plugins directory, it will act as a "patch" or else it will be treated as a separate bundle.

Thanks,
Jayanga.

Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham <[hidden email]> wrote:
Hi Jayanga,

IMO we should also take into consideration of apply fixes other than just log patches. In C5 onwards, the current approach is to use WUM to deliver all updates. But there can be scenarios where we would need to provide an immediate solution or say a Pre-QA fix. IMO we would need to address this here. 

IMO applying the temp fix in lib folder is not correct. IMO the Lib folder is used for addition components that are required by the server, i.e., components which are not provided by wso2. IMO it would be better to have a separate folder for this. In carbon 4.4.X, we had a separate folder called patches.

Regards,
Nira

On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Vidura,

Adding a separate command line would easily lead to more human errors. With C5, we are trying to minimize the configurations, command line parameters, etc. to make the users' life easier and to reduce the human errors much as possible. Log patch is just a one case I highlighted. There are other use cases like;
  • Adding DB drivers
  • Configuring additional transports e.g: JMS
  • Putting custom mediators (in C4), etc.
Above requirements are based on the C4 experience and there will definitely be some similar set of requirements in the C5 as well. Hence, if we introduce a separate command line, the user will have to start the server with that parameter each time they modify the lib directory, even they do a version upgrade of a given library.
Hence I would prefer to make the library update decision programmatically rather a user input.   

@Lackman:
With C5, we will abandon the word "patch". Everything including features, fixes, etc. will be provided via updates. Hence there is no point having a separate directory call "patches". A "log patch" is just another jar file having the same bundle symbolic name and version as its original bundle in the plugins directory. Once it is removed from the lib directory, the server will use the original bundle in the plugins directory.

Thanks,
Jayanga.



Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha <[hidden email]> wrote:
Hi,

I also think running a separate tool or add startup parameter to say there is a change to the existing bundles and deploy them also is a better approach, since this is a special scenario as Vidura mentioned also. 

For the reverting to a backup point, IMO it is an unnecessary step because if we have a good set of integration and unit tests to cover the wum update, then there is the least importance of reverting to a backup point. Another thing is, since subsequent updates are going on previous updates, all the changes will come with new updates. In that case, How are we going to apply subsequent updates on previous updates? 

Anyway, I feel that we should go with a separate patch folder if we are going to apply temporary patch rather than lib folder. It is more convenient because the patch is not an additional library. What is the reason are we stopping doing this?

Thanks,
Lakshman.

On Wed, May 17, 2017 at 6:25 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Jayanga and Ruwan,

Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <[hidden email]> wrote:
Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib to check whether there are any changes to the files. Yes, we could save some 'time' in the server startup if we provide a separate tool. But there is a possibility that someone would miss running that script and expect the new changes. Anyway, I'll check on the possibilities of minimizing startup time taken.

Regarding the checkpointing thing, the suggested approach keep the original bundles.info file as a backup and always update it with the bundles given in the [product_home]/lib. And we haven planned on keeping the historical changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[hidden email]> wrote:
+ 1 on the idea of the four steps mentioned.
Can we look into a way this can be triggered selectively with some command-line option or an offline command? Reason to keep this logic from slowing down the startup in production run.

In addition to that, in future, we could able to enhance the same logic to allow similar behavior like "windows System Restore Point" or "OSX time machine" to revert to known point of WUM, by version controlling the bundle-info and the respective jars/configs.

Cheers,
Ruwan

On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <[hidden email]> wrote:
Hi All,

Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.

1. It first read the bundles.info file of the current runtime
2. Then take the list of bundles coming from "plugins" directory.
3. Adds the bundles in the [product_home]/lib directory to the previous list
4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority)
5. Update the bundles.info file

The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it.

Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed).

The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users.

There is a possibility to let the clients add the log patch into the  [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored.

To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows.

1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file)
2. Read the bundles.info.original file
3. Add the bundles in the [product_home]/lib directory
4. Update the  bundles.info file
And
The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib

Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file

WDYT?


Thanks,
Jayanga Dissanayake
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [hidden email]
mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259





--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nisala Niroshana Nanayakkara,
Software Engineer
Mobile | +94 717600022
WSO2 Inc | http://wso2.com/

[1] - https://github.com/wso2/carbon-kernel/blob/master/docs/KernelFeatures/DroppingOSGiBundlesintoaCarbonServer.md

Regards,
Nira

--

Niranjan Karunanandham
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture