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