On Fri, Jul 16, 2010 at 1:57 AM, Srinath Perera <srin...@wso2.com> wrote:
> Hi Isuru, > > Does that mean Server role is fixed and does not change with CApp > deployments? Yes. In the MT environment we have to fix the server role. Server role supports regular expressions and may be we'll have to set it to ".*" as the default in MT. So that the user can deploy anything. But the actual artifact will be deployed properly only if needed features are there. > which IMO is ok, because making server automatically > adjust to apps is a separate problem, and we do not necessary have to > solve it with CApp. Also when we have the topology editor, we should > give a error/warning if user try to deploy a part of CApp to a server > that does not support it. Is that possible? > Yes. That is possible. But it requires p2 level queries. So it will take some time to check the existing features. > > Also multi-tenant case, +1 for not letting users add features. I guess > since adding new features going to affect the whole server, we do not > have a choice there. > > So how does CApp deployment in Stratos will work? When I say I want to > deploy a CApp, do I get a topology editor or does Stratos pick server > for each part of the CApp based on their roles? > We don't have a topology editor yet. So the cApp should be uploaded to each and every Carbon instance. Thanks, ~Isuru > > Thanks > Srinath > > > > On Thu, Jul 15, 2010 at 11:40 AM, Afkham Azeez <az...@wso2.com> wrote: > > +1 for not allowing feature installation for tenants. When a Capp is > > deployed on a Stratos service, and that service is the target role, > > then it is supposed to have all the required features installed. Also, > > to figure out whether you are within a tenant or in the super tenant, > > you can make use of the tenant_id param, so you need not add anything > > to carbon.xml. > > > > Azeez > > > > On Wed, Jul 14, 2010 at 7:40 PM, Isuru Suriarachchi <is...@wso2.com> > wrote: > >> > >> > >> On Wed, Jul 14, 2010 at 7:29 PM, Senaka Fernando <sen...@wso2.com> > wrote: > >>> > >>> Hi Isuru, > >>> > >>> +1. But need to clarify some issues, for the record. > >>> > >>> On Wed, Jul 14, 2010 at 6:37 PM, Isuru Suriarachchi <is...@wso2.com> > >>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> As Azeez has already mentioned in another thread, we have come up with > a > >>>> serious issue in deploying cApps in a MT environment. The root cause > for > >>>> this issue is the usage of p2 features to install artifacts in the > cApp. > >>>> Even though each tenant has it's own Axis Configuration, all tenants > share > >>>> the same OSGi environment. So the installation of features can't be > made > >>>> tenant specific. > >>>> > >>>> We didn't use p2 for cApp artifact deployment in our initial > >>>> implementation of cApp. But later we introduced p2 to automatically > install > >>>> the needed Carbon components for a particular artifact deployment. > >>>> > >>>> Ex : If we install a cApp with an AAR service into a pure Carbon > >>>> instance, it should install the service management features > automatically > >>>> into the Carbon server. > >>>> > >>>> I think this is the only reason for using p2 features for artifact > >>>> installation. Please add if I've missed something here :) .. > >>>> > >>>> As a solution for this problem, I have an idea of making the feature > >>>> installation optional in the cApp. > >>> > >>> If a feature is not available on a given server, and if installation is > >>> optional, will the total deployment fail? or will it be partial? > >> > >> I think we have to deploy other artifacts in that case. We can provide a > >> warning for the failed artifact. Or else we can list the failed > artifacts > >> under the capp-info page. > >> > >>>> > >>>> Proposed solution: > >>>> > >>>> cApp doesn't contain a p2-repo and it only has a collection of folders > >>>> which includes artifacts to be deployed. > >>>> > >>>> |-- artifacts.xml > >>>> |-- endpoint1 > >>>> | |-- artifact.xml > >>>> | `-- endpoint1.xml > >>>> |-- fooService > >>>> | |-- artifact.xml > >>>> | `-- foo.aar > >>>> `-- proxy1 > >>>> |-- artifact.xml > >>>> `-- proxy1.xml > >>>> > >>>> But inside the artifact.xml of each and every artifact, we have the > list > >>>> of dependent Carbon features which should be installed in the system > to > >>>> deploy this particular artifact (this list of features is > automatically > >>>> added by eclipse tools at artifact generation). So the artifact.xml > will > >>>> look like this.. > >>>> > >>>> <artifact type="service/axis2" version="1.4.0" > >>>> name="org.wso2.samples.CachingTestService" serverRole="wsas1"> > >>>> <file>CachingTestService.aar</file> > >>>> <subArtifacts> > >>>> <artifact type="registry/resource"> > >>>> <file>reg-config.xml</file> > >>>> </artifact> > >>>> </subArtifacts> > >>> > >>> Can sub-artifacts have features too? > >> > >> Yes. It should be possible. > >> > >>>> > >>>> <requiredFeatures> > >>>> <feature name="org.wso2.carbon.service.mgt" version="3.0.0"/> > >>>> <feature name="org.wso2.carbon.service.mgt.ui" > version="3.0.0"/> > >>>> <feature name="org.wso2.carbon.aarservices" version="3.0.0"/> > >>>> </requiredFeatures> > >>>> </artifact> > >>>> > >>>> So we provide an option for the user at the deployment time to specify > >>>> whether he needs feature installations or not. If the user already > have > >>>> these features installed in his Carbon instance, he will set the > option to > >>>> "false". If it is "true", cApp deployer can programetically install > these > >>>> features in the system. And also in MT environment, this option is > always > >>>> "false". In that case, when a user deploys a cApp, only the artifacts > for > >>>> which the needed features are already there, will be deployed. > >>> > >>> How do we enforce this in a MT environment? Can we also have some > property > >>> (similar to the server role) on the carbon.xml (or some where similar) > >>> defining the same, (so that deployment will not install features on > >>> production servers but on dev and staging servers, for example) . May > be we > >>> could use the same approach for Stratos? > >> > >> Yes. carbon.xml is the place to have that property. So the MT users > can't > >> change it. > >> > >> Thanks, > >> ~Isuru > >> > >>>> > >>>> This solution will allow us to keep the advantage of using p2 features > >>>> while allowing the cApp to be deployed in a MT environment. > >>>> > >>>> Note : However, handling third party dependent libraries will still be > a > >>>> problem in the MT environment. It should be discussed as a separate > topic. > >>>> > >>>> WDYT??.. > >>> > >>> Thanks, > >>> Senaka. > >>>> > >>>> Thanks, > >>>> ~Isuru > >>>> > >>>> _______________________________________________ > >>>> Carbon-dev mailing list > >>>> Carbon-dev@wso2.org > >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>>> > >>> > >>> > >>> > >>> -- > >>> Senaka Fernando > >>> Associate Technical Lead > >>> WSO2 Inc. > >>> E-mail: senaka AT wso2.com; Mobile: +94 77 322 1818 > >>> > >>> http://www.wso2.com/ - "Lean . Enterprise . Middleware" > >>> > >>> _______________________________________________ > >>> Carbon-dev mailing list > >>> Carbon-dev@wso2.org > >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>> > >> > >> > >> _______________________________________________ > >> Carbon-dev mailing list > >> Carbon-dev@wso2.org > >> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >> > >> > > > > > > > > -- > > Afkham Azeez > > Senior Software Architect & Senior Manager; WSO2, Inc.; > > http://wso2.com, Lean . Enterprise . Middleware > > Member; Apache Software Foundation; http://www.apache.org/ > > email: az...@wso2.com cell: +94 77 3320919 > > blog: http://blog.afkham.org > > twitter: http://twitter.com/afkham_azeez > > linked-in: http://lk.linkedin.com/in/afkhamazeez > > > > _______________________________________________ > > Carbon-dev mailing list > > Carbon-dev@wso2.org > > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > > > -- > ============================ > Srinath Perera, Ph.D. > WSO2 Inc. http://wso2.com > Blog: http://srinathsview.blogspot.com/ > > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
