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