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/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
