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 <[email protected]> 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: [email protected] > mobile: +94772207259 <077%20220%207259> > <http://wso2.com/signature> > > On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham < > [email protected]> 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 <[email protected]> >> 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: [email protected] >>> mobile: +94772207259 <+94%2077%20220%207259> >>> <http://wso2.com/signature> >>> >>> On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha < >>> [email protected]> 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 <[email protected]> >>>> 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 <[email protected] >>>>> > 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: [email protected] >>>>>> mobile: +94772207259 <+94%2077%20220%207259> >>>>>> <http://wso2.com/signature> >>>>>> >>>>>> On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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? >>>>>>>> >>>>>>>> [1] https://github.com/wso2/carbon-kernel/blob/v5.2.0-m3/lau >>>>>>>> ncher/src/main/java/org/wso2/carbon/launcher/extensions/OSGi >>>>>>>> LibBundleDeployerUtils.java >>>>>>>> >>>>>>>> Thanks, >>>>>>>> *Jayanga Dissanayake* >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc. - http://wso2.com/ >>>>>>>> lean . enterprise . middleware >>>>>>>> email: [email protected] >>>>>>>> mobile: +94772207259 <+94%2077%20220%207259> >>>>>>>> <http://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Ruwan Abeykoon* >>>>>>> *Associate Director/Architect**,* >>>>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>>>>>> *lean.enterprise.middleware.* >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> >>>>> *Vidura Nanayakkara* >>>>> Software Engineer >>>>> >>>>> Email : [email protected] >>>>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277> >>>>> Web : http://wso2.com >>>>> Blog : https://medium.com/@viduran >>>>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Lakshman Udayakantha >>>> WSO2 Inc. www.wso2.com >>>> lean.enterprise.middleware >>>> Mobile: *0717429601 <071%20742%209601>* >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: [email protected] P: +94 777542851
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
