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