Hi, As I previously mentioned, isn't this more like a behavior of "refactor-X" against "X" where X can be rename/edit etc. And the re factoring feature will be a ideal new feature that will enhance the user experience.
On Mon, Mar 3, 2014 at 10:14 AM, Eranda Sooriyabandara <[email protected]>wrote: > Hi Janaka, > > > On Mon, Mar 3, 2014 at 9:59 AM, Janaka Ranabahu <[email protected]> wrote: > >> >> >> >> On Sun, Mar 2, 2014 at 11:26 PM, Eranda Sooriyabandara >> <[email protected]>wrote: >> >>> Hi Janaka, >>> >>> >>> On Mon, Feb 24, 2014 at 7:19 PM, Janaka Ranabahu <[email protected]>wrote: >>> >>>> Hi Subash, >>>> >>>> >>>> On Fri, Feb 21, 2014 at 5:43 PM, Subash Chaturanga <[email protected]>wrote: >>>> >>>>> HI Janaka, >>>>> In a Prod or non Prod env ithere can be a use case that at a given >>>>> point of time, governance master needs to refactor the LC config (some >>>>> config change as Ajith mentioned) and reflect the changes on all >>>>> associated >>>>> 100s of services. So I believe this feature is a useful one (may be in a >>>>> new form like "refactor"). >>>>> >>>> But the current behavior of G-Reg is not to update the existing >>>> artifacts. Is that a design decision? >>>> >>> >>> WDYM by not allow to update? >>> >> If you modify a check item name in a state, none of the existing >> resources in that state does not reflect that change. >> > > As you know that we keep the LC state details as resource properties. So > any update on LC related to that state won't be reflected. In order to fix > this we need to come up with a different way of keeping states of LC of a > resource which will be a major improvement. But for now we should advise > the user not to update LC config state if they are in use, instead we can > tell them that you only can change the future states only. > > thanks > Eranda > > > > >> >> Thanks, >> Janaka >> >>> >>> thanks >>> Eranda >>> >>> >>> >>>> >>>> Thanks, >>>> Janaka >>>> >>>>> >>>>> Vendors like WSRR have the capability to maintain versions of the same >>>>> LC, which is a good feature to have for GReg as well, where it will allows >>>>> users to create versions of LC for those major/minor changes and it will >>>>> avoid those inconsistencies. >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Feb 22, 2014 at 3:51 AM, Janaka Ranabahu <[email protected]>wrote: >>>>> >>>>>> Hi Ajith, >>>>>> >>>>>> Please see my concerns inline. >>>>>> >>>>>> >>>>>> On Fri, Feb 21, 2014 at 4:33 PM, Ajith Vitharana <[email protected]>wrote: >>>>>> >>>>>>> Hi Janaka, >>>>>>> >>>>>>> First *"**ServiceLifeCycle is already in use and your changes may >>>>>>> affect existing usage" * is sufficient warning. Because we can't >>>>>>> add lengthy descriptions in small UI box. >>>>>>> Practically, do we change the *LC state id* having large number of >>>>>>> artifacts in a production system ?. >>>>>>> >>>>>> What happens if some user do so? This may not happen in a production >>>>>> instance. But in a developer environment this is something very likely to >>>>>> happen. >>>>>> >>>>>>> >>>>>>> Renaming the existing *LC state id* is only one use case. >>>>>>> >>>>>> yes it is only one possibility. It is the first one I tried and it >>>>>> created couple of inconsistent behaviors. Also we can not limit users to >>>>>> not to change the state id. It is one possibility that we have allowed. >>>>>> >>>>>> Following are are the valid points of allowing to update the existing >>>>>>> LC configuration. >>>>>>> >>>>>>> 1. Add new state to existing configurations. >>>>>>> >>>>>> 2. Add/update executors, validators, transition UI ..etc. >>>>>>> >>>>>> These 2 are not likely scenarios for a already defined LC. If there >>>>>> is a requirement for a new state, that indicates that the organization >>>>>> process has changed. Then what we need is a new version of the LC and not >>>>>> to modify the current one. >>>>>> >>>>>>> 3. Add/Update the parameters. >>>>>>> 4 Add/update the check Items ..etc >>>>>>> >>>>>> This will not work for the existing resources. I tried this and it >>>>>> was not reflected immediately. So that is why I raised the concern that >>>>>> by >>>>>> allowing this, there can be resources in the same state but with >>>>>> different >>>>>> check items. >>>>>> >>>>>> So IMO we should not allow to modify a LC if it is already in use. By >>>>>> not allowing, we can enforce the users to have a naming conversion for >>>>>> the >>>>>> LC, which is version aware and there is very limited opportunity for >>>>>> inconsistent behavior. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks, >>>>>> Janaka >>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> Ajith. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 22, 2014 at 2:16 AM, Janaka Ranabahu <[email protected]>wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have noticed that we allow users to modify a lifecycle that is >>>>>>>> already assigned to resources. Did we do a complete analysis of the >>>>>>>> situations that could come by allowing this behavior? >>>>>>>> >>>>>>>> I have noticed the following inconsistent behavior due to this. >>>>>>>> >>>>>>>> When saving the lifecycle configuration, it only gives a warning >>>>>>>> saying* "ServiceLifeCycle is already in use and your changes may >>>>>>>> affect existing usage. Are you sure you want to save these Lifecycle >>>>>>>> changes?"* There is no descriptive explanation about what is the >>>>>>>> impact of the change. It happens to be that, if you rename a state, >>>>>>>> and if >>>>>>>> there were resources on that state, the lifecycle portlet disappear >>>>>>>> from >>>>>>>> the UI. There is no way to remove, add or do any action on the >>>>>>>> lifecycle >>>>>>>> for that resource and that resource is completely unusable(from LC >>>>>>>> point of >>>>>>>> view) from that point onward. >>>>>>>> >>>>>>>> Also we do not update the existing resources with the change. If we >>>>>>>> add a new check item or change a check item of an existing state, that >>>>>>>> change is not reflected for the resources that are already associated >>>>>>>> with >>>>>>>> the lifecycle. Because of that, G-Reg began to have resources with the >>>>>>>> same >>>>>>>> lifecycle, but with different behaviors. >>>>>>>> >>>>>>>> Therefore, I'm wondering what is the purpose of modifying a >>>>>>>> lifecycle which is already in use. IMO, this had introduced a >>>>>>>> inconsistent >>>>>>>> behavior and had not solve anything. The real problem comes when there >>>>>>>> is a >>>>>>>> high number of resources that is associated with the lifecycle. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Janaka >>>>>>>> >>>>>>>> -- >>>>>>>> *Janaka Ranabahu* >>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com >>>>>>>> >>>>>>>> >>>>>>>> * E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >>>>>>>> <%2B94%20718370861>* >>>>>>>> >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ajith Vitharana. >>>>>>> WSO2 Inc. - http://wso2.org >>>>>>> Email : [email protected] >>>>>>> Mobile : +94772217350 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Janaka Ranabahu* >>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com >>>>>> >>>>>> >>>>>> * E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >>>>>> <%2B94%20718370861>* >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks >>>>> /subash >>>>> >>>>> *Subash Chaturanga* >>>>> Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com >>>>> >>>>> email: [email protected] >>>>> blog: http://subashsdm.blogspot.com/ >>>>> twitter: @subash89 >>>>> phone: +9477 2225922 >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> *Janaka Ranabahu* >>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com >>>> >>>> >>>> * E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >>>> <%2B94%20718370861>* >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> >>> *Eranda Sooriyabandara*Senior Software Engineer; >>> Integration Technologies Team; >>> WSO2 Inc.; http://wso2.com >>> Lean . Enterprise . Middleware >>> >>> E-mail: eranda AT wso2.com >>> Mobile: +94 716 472 816 >>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>> Blog: http://emsooriyabandara.blogspot.com/ >>> >>> >>> >>> >>> >> >> >> -- >> *Janaka Ranabahu* >> Senior Software Engineer; WSO2 Inc.; http://wso2.com >> >> >> * E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >> <%2B94%20718370861>* >> >> Lean . Enterprise . Middleware >> > > > > -- > > *Eranda Sooriyabandara*Senior Software Engineer; > Integration Technologies Team; > WSO2 Inc.; http://wso2.com > Lean . Enterprise . Middleware > > E-mail: eranda AT wso2.com > Mobile: +94 716 472 816 > Linked-In: http://www.linkedin.com/in/erandasooriyabandara > Blog: http://emsooriyabandara.blogspot.com/ > > > > > -- Thanks /subash *Subash Chaturanga* Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com email: [email protected] blog: http://subashsdm.blogspot.com/ twitter: @subash89 phone: +9477 2225922 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
