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