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