Hi Senaka,
> There is a use-case. For example, even in the case of a service, you can > push it to the ES at anytime after it has been created. There is no concept > of a service needs to be in Production or Testing for it to be available on > the Store. But, for a service to be published on the store, you need it to > be reviewed and also it needs to have an endpoint. So, the service has a > Store-lifecycle. But, it has a separate development lifecycle. Similarly it > can have other lifecycles for other concepts. > I got it. I had a confusion where I thought there will be separate stores for dev, testing and production and there will be separate services in dev, testing and prod which done by the current service lifecycle. Are we going to change them? If the plan is for no separate stores for dev, qa and production and one service maintain for across all lifecycle, it does make sense to have a separate lifecycle. Please correct me if I am wrong. thanks Eranda > > Thanks, > Senaka > > > On Friday, December 12, 2014, Eranda Sooriyabandara <era...@wso2.com> > wrote: > >> Hi Senaka, >> >> >>> Lets take your example. Say we have both ES-LC and Dev-LC. Ideally, >>> there will be two independent lifecycles. There needs to be some >>> implementation or configuration that will tie these two lifecycles >>> together. For example, like there are some checklist rules that need to be >>> statisfied for being able to Promote from X to Y, you might also need to >>> satisfy some other conditions in different lifecycles in order retain your >>> existing state or promote from current to next and vice versa. >>> >> >>> So, the user can define/extend how the lifecycles depends on each other, >>> but from the framework level you can have two or more completely >>> independent lifecycles. >>> >> >> Is there any usecase where there can be two independent lifecycles per >> resource? AFAIU, can't be. My logic is in our environment if we have two >> lifecycle bind together then the scope of combining lifecycle is bound to a >> state. >> >> For example >> When when we promote Dev to Test will the state of ES lifecycle should >> remain the same? (may be it's in Published state) >> >> If it bound to a state why can't we specify one lifecycle as a part of >> other lifecycle. We can define it as below >> >> <stateLC name="ESLifecycle"> >> <stateLC name="RainLifecycle"> >> >> Please correct me if I am on wrong way. >> >> thanks >> Eranda >> >> >>> >>> Thanks, >>> Senaka. >>> >>> On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara <era...@wso2.com> >>> wrote: >>> >>>> @Sagara, Senaka, Shazni, >>>> >>>> Here I am bit worried about the lifecycle state combinations we are >>>> getting. >>>> Let's take the example of Service. In service lifecycle we have >>>> Development, Test, Production and then we have a ES lifecycle which >>>> contains Created, Published, Retired. Think we associate both lifecycle to >>>> a service where we need to promote the service to the service store while >>>> keep it in the development. We can do it by changing the ES lifecycle to >>>> published. Then we promoting the service lifecycle to QA and still we see >>>> ES lifecycle is in published state which is bit confusing. Please correct >>>> me if I am wrong. >>>> >>>> If you look closely to the use case provided by Sagara, Service >>>> lifecycle is the main lifecycle and the ES lifecycle is a state specific >>>> lifecycle where when we promoting Dev to Test we should not transfer the >>>> state of ES lifecycle. So I hope we should have a main lifecycle and we >>>> should be able to define state specific lifecycles where we can select >>>> existing lifecycles. >>>> WDYT? >>>> >>>> thanks >>>> Eranda >>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >>> Solutions Architect; WSO2 Inc.; http://wso2.com >>> >>> >>> >>> *Member; Apache Software Foundation; http://apache.org >>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>> >>> >>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >>> http://linkedin.com/in/senakafernando >>> <http://linkedin.com/in/senakafernando>*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: (812) 964-9032 >> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >> Blog: http://emsooriyabandara.blogspot.com/ >> >> >> >> >> > > -- > > > *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* > Solutions Architect; WSO2 Inc.; http://wso2.com > > > > *Member; Apache Software Foundation; http://apache.org > <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 > 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; > > > *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: > http://linkedin.com/in/senakafernando > <http://linkedin.com/in/senakafernando>*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: (812) 964-9032 Linked-In: http://www.linkedin.com/in/erandasooriyabandara Blog: http://emsooriyabandara.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
