Hi, Huge +1 for not making Puppet mandatory. I felt that Stratos 4.0 has done that already.
We have already tightly coupled our templates with Puppet. And I'm not sure on how to create a central template source. What type of templating structure do you think we should use? This should be independent from any configuration management framework, IMO. My suggestion would be to have templates in simple plain text format with replacement variable keys. Then have scripts for generating Puppet modules/Cheff modules or even stand-alone setup scripts. Shall we proceed with that? Thanks. On 2 May 2014 11:14, "Lakmal Warusawithana" <[email protected]> wrote: > Yes, I agree with Vanson on this. We should not mandate puppet. Later > someone may wants to use cheft. > > +1 for maintain separate templates. > > @Vanson, if you guys testing with scripting method please send upstream > your contributions. > > thanks > > > On Fri, May 2, 2014 at 7:01 AM, Vanson Lim <[email protected]> wrote: > >> I am not sure I agree with requiring the use of puppet to configure >> everything as it's not always practical to install puppet into a cartridge >> image. There's also the issue where depending on the VM you are trying to >> convert into a cartridge might make use of a different versions of puppet. >> >> I'd like to see the cartridge agent packaged to be deploy-able as a >> standalone entity and then to value add with puppet for those use cases >> that support it. >> >> I would prefer having the templates reside in a central templates >> directory, provide an option during setup to deploy it into the puppet >> modules/template directory tree. >> >> This avoids the issue of having two versions of the template, one for >> puppet and one for non puppet deployment cases. >> >> For those who don't want to use puppet, they can minimally script up >> something which transforms the source templates. >> >> Right now, we've found a few files like the >> cartridge-agent/bin/stratos.sh and the >> cartridge-agent/conf/template/jndi.properties.template to be incompatible >> with the latest code behavior. >> >> the stratos.sh. is missing recently added APP_PATH property and works >> only if you use puppet to overwrite file that is shipped in the zip. >> >> Similarly, the jndi/properties.template file by default doesn't have >> configuration which run's with activemq, even though all the documentation >> points to it. We found in RC1 the JNDI template needs the following >> changes otherwise the cartridge agent will fail to connect with apache >> stratos. >> >> Original: >> >> connectionfactoryName=topicConnectionfactory >> connectionfactory.topicConnectionfactory=amqp://admin:admin@carbon >> /carbon?brokerlist='tcp://$mb_ip:$mb_port' >> >> java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory >> >> >> >> Actual values required for ActiveMQ: >> >> connectionfactoryName=TopicConnectionFactory >> connectionfactory.topicConnectionfactory=tcp://$mb_ip:$mb_port >> >> java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory >> >> >> -Vanson >> >> >> >> On 5/1/14, 8:49 AM, Isuru Haththotuwa wrote: >> >> On Wed, Apr 30, 2014 at 8:10 AM, Akila Ravihansa Perera<[email protected]> >> <[email protected]>wrote: >> >> >> Hi, >> >> Cartridge Agent currently uses a JndiConfigurator class to modify the >> jndi.properties file to set MB IP and MB port. It uses a >> jndi.properties.template file to generate this. But according to >> Stratos 4.0 architecture all the properties files should be generated >> from the Puppet scripts. >> >> IMO, this templating logic should be removed from the Cartridge >> Agent's end and should be done via Puppet scripts. If the community >> agrees to that I could work on a patch for this. WDYT? >> >> >> +1 >> >> >> Thanks. >> >> -- >> Akila Ravihansa Perera >> Software Engineer >> WSO2 Inc.http://wso2.com >> >> Phone: +94 77 64 154 38 >> Blog: http://ravihansa3000.blogspot.com >> >> >> >> > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > >
