On Wed, Jan 13, 2016 at 8:28 PM, Uvindra Dias Jayasinha <[email protected]> wrote:
> @Lakmali, +1, we can do it this way. > > > @All, just a suggestion for next time, it would be great if we could > leverage the API Import/Export feature to move existing APIs over to the > new product version, since its available in the product. Users dont need to > manually copy them over then. WDYT? > I don't think its right to leverage that since its intention is to move the API from one location to another (Dev to QA). Even if it did, it can only take care of API related information. Not other information such as App Data, Token Data, etc. And the Import/Export feature would have to change from release to release. > > On 13 January 2016 at 09:48, Uvindra Dias Jayasinha <[email protected]> > wrote: > >> Ya this is fine but it has a real impact on complicating the migration. >> This issue has been there with migrating previous releases as well. We need >> to put more thought into reducing migration complexity when we add new >> features, more complications means more issues to deal with and lots of >> time consumed. >> >> On 13 January 2016 at 07:47, Nuwan Dias <[email protected]> wrote: >> >>> >>> >>> On Wed, Jan 13, 2016 at 6:07 PM, Uvindra Dias Jayasinha < >>> [email protected]> wrote: >>> >>>> Ok if we allow these to be extended then we should not be adding our >>>> logic from the product here, but seems that we have made improvements >>>> within the extensible part. >>>> >>> >>> They are being modified for extending the extension support :). Ex: We >>> have the ability to change the message type of an error response. So we >>> allow users to modify a property on the sequence to do that. In the next >>> release we figure out that we can also change the status code using the >>> same mechanism. So we add another property on the same sequence so users >>> can change the status code as well using extensions. Therefore there are >>> valid cases for modifying these sequences during feature releases. >>> >>>> >>>> We should add our changes to a default sequence that is used unless it >>>> has been overridden by a custom sequence that has been defined for this >>>> purpose by the user. That way we can upgrade the default sequences and >>>> users who haven't overridden it get to use it. >>>> >>>> But seems that the way thing are now we can achieve the same affect by >>>> asking users to copy the sequences over if they have made any >>>> customizations. Either way if they have done customizations they need to >>>> copy them. So we can simply ask them to do that and not try to migrate >>>> automatically. >>>> >>>> >>>> :) Agree with Lakmali, who replied on the other thread, user should >>>> only copy the sequences if they have customized them. No need to do >>>> anything with the migration client >>>> >>>> On 13 January 2016 at 07:26, Nuwan Dias <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha < >>>>> [email protected]> wrote: >>>>> >>>>>> I think the only way is to complicate the migration instructions, >>>>>> >>>>>> If user has customized any sequences they need to copy them over >>>>>> manually to latest pack and we will use those.(Discalimer to user: You >>>>>> maybe missing out on the latest changes shipped with the default >>>>>> sequences >>>>>> in the latest pack) >>>>>> >>>>>> Migration client doesn't need to do anything then, its not in a >>>>>> position to make a proper decision anyway. >>>>>> >>>>>> But its pretty clear this is a hole in our extensibility. We dont >>>>>> provide official extension points to make changes in the areas that these >>>>>> specific sequences address, forcing uses to change the default sequences >>>>>> that are shipped which makes upgrading a pain. We should address this in >>>>>> a >>>>>> future release >>>>>> >>>>> >>>>> The sole purpose of these sequences are for extensibility. Ex: To >>>>> change the message type of a auth failure error. So its understandable >>>>> that >>>>> people edit them. >>>>> >>>>>> >>>>>> On 13 January 2016 at 05:23, Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> In our migration guide, currently what we instruct is to copy & >>>>>>>> replace repository/deployment/server/synapse-config/default directory >>>>>>>> and >>>>>>>> repository/tenants from previous APIM version to new APIM version. >>>>>>>> Here we >>>>>>>> mention to skip replacing _TokenAPI_.xml, _RevokeAPI_.xml and >>>>>>>> _AuthorizeAPI_.xml files by which latest files of those will be >>>>>>>> remained. >>>>>>>> >>>>>>>> But with this approach, it will replace other system sequences with >>>>>>>> old ones (ex: _auth_failure_handler_.xml, _cors_request_handler_.xml, >>>>>>>> main.xml, fault.xml, etc). So some of the fixes went to those will be >>>>>>>> missed out. We have two ways to include those changes to the new >>>>>>>> version. >>>>>>>> >>>>>>>> 1. Include the missing changes through migration client. >>>>>>>> 2. Get the latest sequences from the new version pack and replace >>>>>>>> corresponded sequences of each tenant through migration client. >>>>>>>> >>>>>>>> Some of the changes done to these sequences are minor changes like >>>>>>>> adding a drop mediator after send, changing a regex value, removing a >>>>>>>> property etc. Since some of the users may have already done own >>>>>>>> customizations to these sequences, trying to add changes to existing >>>>>>>> ones >>>>>>>> may lead to complications. >>>>>>>> So I think it would be better to ask the users to add their changes >>>>>>>> (if there are any) to default sequences in the >>>>>>>> pack(repository/resources/apim-synapse-config) prior running the >>>>>>>> migration >>>>>>>> client and then through the client we can replace existing ones. WDYT? >>>>>>>> >>>>>>> >>>>>>> This part is tricky. Since we do not know the amount nor nature of >>>>>>> customisations they may have done, can we guarantee the migration client >>>>>>> will do its job properly since it doesn't know the content/state of the >>>>>>> file before it starts to execute on it? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Lakmali >>>>>>>> >>>>>>>> -- >>>>>>>> Lakmali Baminiwatta >>>>>>>> Senior Software Engineer >>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> mobile: +94 71 2335936 >>>>>>>> blog : lakmali.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Technical Lead - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > > -- > Regards, > Uvindra > > Mobile: 777733962 > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
