Hi Imesh. Done: https://wso2.org/jira/browse/PAAS-238
Please, try to send update to [email protected]. Thanks, Marco ________________________________ Da: Imesh Gunaratne [[email protected]] Inviato: martedì 15 settembre 2015 18.23 A: Monaco Marco Cc: Anuruddha Liyanarachchi; WSO2 Developers' List Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, On Tue, Sep 15, 2015 at 7:13 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: This is the log of nginx-extension: 2015-09-15 13:35:17,905 [-] [pool-1-thread-2] ERROR Nginx Could not start nginx instance 2015-09-15 13:35:17,906 [-] [pool-1-thread-2] ERROR LoadBalancerExtension Could not start load balancer org.apache.stratos.load.balancer.extension.api.exception.LoadBalancerExtensionException: java.lang.RuntimeException: Command execution failed: nginx: [emerg] duplicate upstream "wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it/>" in /etc/nginx/nginx.conf:27 This looks like a bug in the nginx extension. It would be great if you can report this in JIRA with the details to reproduce. We will fix this ASAP. Thanks On Tue, Sep 15, 2015 at 7:13 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Imesh, Your suggestion worked as a charme, now seems working fine, but we'are still facing problems with LB. If PPAAS try to spawn several instances of same cartridge the nginx fails configuration. This is the scenario: esb manager (min 1 instance, max 1 instance) + esb worker (min 2 instance, max 5 instances). When PPAAS deploy the 2nd worker cartridge, nginx extension modify configuration and nginx stop working beacuse of several upstream that goes in conflict. This is the log of nginx-extension: 2015-09-15 13:35:17,905 [-] [pool-1-thread-2] ERROR Nginx Could not start nginx instance 2015-09-15 13:35:17,906 [-] [pool-1-thread-2] ERROR LoadBalancerExtension Could not start load balancer org.apache.stratos.load.balancer.extension.api.exception.LoadBalancerExtensionException: java.lang.RuntimeException: Command execution failed: nginx: [emerg] duplicate upstream "wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>" in /etc/nginx/nginx.conf:27 at org.apache.stratos.nginx.extension.Nginx.start(Nginx.java:91) at org.apache.stratos.load.balancer.extension.api.LoadBalancerExtension.configureAndStart(LoadBalancerExtension.java:247) at org.apache.stratos.load.balancer.extension.api.LoadBalancerExtension.access$100(LoadBalancerExtension.java:46) at org.apache.stratos.load.balancer.extension.api.LoadBalancerExtension$1.onEvent(LoadBalancerExtension.java:184) at org.apache.stratos.messaging.listener.EventListener.update(EventListener.java:42) at java.util.Observable.notifyObservers(Observable.java:159) at org.apache.stratos.messaging.event.EventObservable.notifyEventListeners(EventObservable.java:51) at org.apache.stratos.messaging.message.processor.topology.CompleteTopologyMessageProcessor.process(CompleteTopologyMessageProcessor.java:69) at org.apache.stratos.messaging.message.processor.MessageProcessorChain.process(MessageProcessorChain.java:61) at org.apache.stratos.messaging.message.receiver.topology.TopologyEventMessageDelegator.run(TopologyEventMessageDelegator.java:73) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: Command execution failed: nginx: [emerg] duplicate upstream "wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>" in /etc/nginx/nginx.conf:27 at org.apache.stratos.common.util.CommandUtils.executeCommand(CommandUtils.java:62) at org.apache.stratos.nginx.extension.Nginx.start(Nginx.java:87) ... 12 more 2015-09-15 13:35:17,918 [-] [pool-1-thread-2] INFO Nginx Stopping nginx... 2015-09-15 13:35:17,929 [-] [pool-1-thread-2] ERROR Nginx Could not stop nginx this is the log of nginx: 2015/09/15 13:35:17 [emerg] 6034#0: duplicate upstream "wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>" in /etc/nginx/nginx.conf:27 2015/09/15 13:35:17 [emerg] 6037#0: duplicate upstream "wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>" in /etc/nginx/nginx.conf:27 This is the nginx.conf after extension modifications: events { worker_connections 1024; } http { server_names_hash_bucket_size 128; upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.60:8243<http://192.168.0.60:8243>; } server { listen 8243 ssl; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass https://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; } upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.62:8243<http://192.168.0.62:8243>; server 192.168.0.61:8243<http://192.168.0.61:8243>; } server { listen 8243 ssl; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass https://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; } } http { server_names_hash_bucket_size 128; upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.60:9443<http://192.168.0.60:9443>; } server { listen 9443 ssl; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass https://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; } } http { server_names_hash_bucket_size 128; upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.60:9763<http://192.168.0.60:9763>; } server { listen 9763; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass http://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } } http { server_names_hash_bucket_size 128; upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.60:8280<http://192.168.0.60:8280>; } server { listen 8280; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass http://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } upstream wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> { server 192.168.0.62:8280<http://192.168.0.62:8280>; server 192.168.0.61:8280<http://192.168.0.61:8280>; } server { listen 8280; server_name wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it>; location / { proxy_pass http://wso2esb-481-application.esb.iotsp.it; } location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } } As you can see there are several definitions of wso2esb-481-application.esb.iotsp.it<http://wso2esb-481-application.esb.iotsp.it> that make it impossible to run. What's wrong? Thank you, Marco ________________________________ Da: Imesh Gunaratne [[email protected]<mailto:[email protected]>] Inviato: martedì 15 settembre 2015 11.10 A: Monaco Marco Cc: Anuruddha Liyanarachchi; WSO2 Developers' List Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, Please find my answers inline: On Tue, Sep 15, 2015 at 4:11 AM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Plus another question: is possible to use Stratos to automatically assign floating ips to spawned openstack vm? Yes this is possible. Please refer following wiki page, if you find any problem please send configuration files, logs (stratos, cartridge agent) and other information to have a look. https://cwiki.apache.org/confluence/display/STRATOS/4.1.x+Multiple+Network+Interfaces Now I have just few questions: 1) in PPaas 4.0.0 for each cartridge it was automatically spawned and configured an LB. Now not, plus I should need to pass LB_IP on cartridge definition, so I suppose it requires a manually loadel LB (WSO2 ELB was great). Am I right? Yes your understanding is correct. Now we do not automatically spin load balancers, rather they need to be started separately. We now have support for Nginx, Haproxy, LVS, EC2 load balancer & GCE load balancer. What we mean by support is that the load balancer configuration can be auto-generated according to the topology. Clarification: does balancer configuration automatically update when new instances are spawned from autoscaler? Yes, that's the responsibility of the load balancer extension. For each load balancer above we have a separate extension. 2) I saw that configurator only supports WSO2 AM, IS and ESB. For other WSO2 Products (I need MB, IS, DES (or CEP + BAM) and EMS) can I use old PPAS 4.0.0 cartridges and puppet definitions? At the moment we have Configurator Template Modules for API-M 1.9.0, IS 5.0.0, ESB 4.8.1, AS 5.2.1, DAS 3.0.0, CEP 4.0.0, & DSS 3.2.2 [1], [2]. MB is in the road map and it will be available in a month or two, BAM won't be there because of DAS. Clarification: Are there some documentation on how to create configurator templates? We can try to manage to develop some templates and make them available to community. Currently I do not think we have documented this but its not that complex: 1. Take the product distribution and copy of the set of configuration files that need to be templated to a folder. 2. Refer Jinja2 for template syntax: http://jinja.pocoo.org/docs/dev/ and add place holders. 3. Add a module.ini file to the root fo the above folder. 4. Now this template module can be used with the Configurator. It's great to hear that you are willing to contribute to this. Appreciate it! No, we can't use Private PaaS 4.0.0 cartridges and their puppet definitions with 4.1.0. We have completely re-architected the cartridge and the cartridge agent design. Clarification: what about new cartridges? What if we use old stratos cartirdge agent on some type of services? I'm referring to some cartridges that we developed for 4.0.0 version. They won't be usable with 4.1.0? No it may not work properly because there is a protocol for the cartridge agent to communicate with Stratos and it has been changed from 4.0.0 to 4.1.0. On Tue, Sep 15, 2015 at 4:11 AM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Imesh, Now it's very late in Italy, I'll try your suggestion tomorrow. Thank you. I need just few clarification (inline to your previuos email). Plus another question: is possible to use Stratos to automatically assign floating ips to spawned openstack vm? We have configured only 1 private network on neutron witha router connected to the external openstack network. A floating pool has been preallocated on the wso2 tenant, but when Stratos starts instances only private ip is assigned. We configured cloud-controller.xml with both autoAssignIp true and flase, but it do not change behaviour. Thanks, Marco Inviato dal mio dispositivo Samsung -------- Messaggio originale -------- Da: Imesh Gunaratne <[email protected]<mailto:[email protected]>> Data: 14/09/2015 21:07 (GMT+01:00) A: Monaco Marco <[email protected]<mailto:[email protected]>> Cc: Anuruddha Liyanarachchi <[email protected]<mailto:[email protected]>>, WSO2 Developers' List <[email protected]<mailto:[email protected]>> Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, It's really nice to hear that you were able to deploy ESB 4.8.1 on Private PaaS 4.1.0 latest code base. Thanks for sharing your experience with us. Please see my comments inline: On Mon, Sep 14, 2015 at 11:56 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: 1) on /etc/puppet/manifests/nodes/base.pp I had to add $mb_url = "tcp://[mb_ip]:[mb_port]" since PCA complained about the missing MB information We have made Puppet Master configurations optional with Private PaaS 4.1.0. We can now define these parameters in the network partitions and have Puppet Master with zero configurations. You can find a sample here: https://github.com/wso2/product-private-paas/blob/master/samples/network-partitions/openstack/network-partition-openstack.json 2) on plugin plugins/wso2esb-481-startup-handler.py on line 75 i received error on MB_IP since PCA looks in values array with MB_IP keys and it don't find any MB_IP property. Since I didn't want to recreate the full cartridge, groups and application I just hardcoded MB_IP to "tcp://[mb_ip]:[mb_port]", but I suppose that I just need to create the cartridge with MB_IP property. This was not documented and present on sample cartridge. I think this has happened because of 1). Please try to define MB_IP in the relevant network partition. Now I have just few questions: 1) in PPaas 4.0.0 for each cartridge it was automatically spawned and configured an LB. Now not, plus I should need to pass LB_IP on cartridge definition, so I suppose it requires a manually loadel LB (WSO2 ELB was great). Am I right? Yes your understanding is correct. Now we do not automatically spin load balancers, rather they need to be started separately. We now have support for Nginx, Haproxy, LVS, EC2 load balancer & GCE load balancer. What we mean by support is that the load balancer configuration can be auto-generated according to the topology. Clarification: does balancer configuration automatically update when new instances are spawned from autoscaler? 2) I saw that configurator only supports WSO2 AM, IS and ESB. For other WSO2 Products (I need MB, IS, DES (or CEP + BAM) and EMS) can I use old PPAS 4.0.0 cartridges and puppet definitions? At the moment we have Configurator Template Modules for API-M 1.9.0, IS 5.0.0, ESB 4.8.1, AS 5.2.1, DAS 3.0.0, CEP 4.0.0, & DSS 3.2.2 [1], [2]. MB is in the road map and it will be available in a month or two, BAM won't be there because of DAS. Clarification: Are there some documentation on how to create configurator templates? We can try to manage to develop some templates and make them available to communtiy. No, we can't use Private PaaS 4.0.0 cartridges and their puppet definitions with 4.1.0. We have completely re-architected the cartridge and the cartridge agent design. Clarification: what about new cartridges? What if we use old stratos cartirdge agent on some type of services? I'm referring to some cartridges that we developed for 4.0.0 version. They won't be usable with 4.1.0? [1] https://github.com/wso2/product-private-paas/tree/master/cartridges/templates-modules [2] https://github.com/wso2/product-private-paas/tree/ppaas-4.2.0/cartridges/templates-modules Thanks On Mon, Sep 14, 2015 at 11:56 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Imesh, I just successfully deployed ESB 4.81 cartridge (manager + workers) on openstack right now, but I had to make some changes on cartridge configuration: 1) on /etc/puppet/manifests/nodes/base.pp I had to add $mb_url = "tcp://[mb_ip]:[mb_port]" since PCA complained about the missing MB information 2) on plugin plugins/wso2esb-481-startup-handler.py on line 75 i received error on MB_IP since PCA looks in values array with MB_IP keys and it don't find any MB_IP property. Since I didn't want to recreate the full cartridge, groups and application I just hardcoded MB_IP to "tcp://[mb_ip]:[mb_port]", but I suppose that I just need to create the cartridge with MB_IP property. This was not documented and present on sample cartridge. Now I have just few questions: 1) in PPaas 4.0.0 for each cartridge it was automatically spawned and configured an LB. Now not, plus I should need to pass LB_IP on cartridge definition, so I suppose it requires a manually loadel LB (WSO2 ELB was great). Am I right? 2) I saw that configurator only supports WSO2 AM, IS and ESB. For other WSO2 Products (I need MB, IS, DES (or CEP + BAM) and EMS) can I use old PPAS 4.0.0 cartridges and puppet definitions? Thank you very much, Marco ________________________________ Da: Imesh Gunaratne [[email protected]<mailto:[email protected]>] Inviato: venerdì 11 settembre 2015 14.43 A: Monaco Marco Cc: Anuruddha Liyanarachchi; WSO2 Developers' List Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, On Fri, Sep 11, 2015 at 12:49 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Imesh, thanks for suggestion, I solved deleting the entire VM of stratos and creating everything new from scratch. Anyway even if I can spawn new instances I'm still facing problems here: i forgot to modify ./repository/conf/cartridge-config.properties and now in lauch-params file I have the wrong puppet master ip. I fixed the file after the first try and also restarted stratos but when I try to deploy instances I still see that launch-params has wrong configurations. I'm sorry this is a bug. You could overcome this for the moment by deleting the application and creating it again. The problem is that the puppet master properties are added to the payload once an application is created. I noticed the same with iaas configuration: if I want to change some iaas properties in cloud-controller.xml file after the first lauch of Stratos, such modification does not take place. The only way is to delete all files, H2 db and mysql db and configure everything from scratch. Yes this is similar to the above issue, if you redeploy the cartridge this problem can be solved. Here the problem is that we have a IaaS configuration cache in cloud controller. It first take the configuration from the cloud-controller.xml and then apply values specified in the cartridge definition (to be overwritten) on top of that. This cache is not updated once we update the cloud-controller.xml file. Just to clarify, except for the above issues were you able to deploy an application in OpenStack successfully with Private PaaS 4.1.0? If not please let us know, we can arrange a google hangout and have a look. Thanks On Fri, Sep 11, 2015 at 12:49 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Imesh, thanks for suggestion, I solved deleting the entire VM of stratos and creating everything new from scratch. Anyway even if I can spawn new instances I'm still facing problems here: i forgot to modify ./repository/conf/cartridge-config.properties and now in lauch-params file I have the wrong puppet master ip. I fixed the file after the first try and also restarted stratos but when I try to deploy instances I still see that launch-params has wrong configurations. I noticed the same with iaas configuration: if I want to change some iaas properties in cloud-controller.xml file after the first lauch of Stratos, such modification does not take place. The only way is to delete all files, H2 db and mysql db and configure everything from scratch. Hope you guys have a method to change such configuration without require a fresh reinstall of the product... Thank you as usual, Marco ________________________________ Da: Imesh Gunaratne [[email protected]<mailto:[email protected]>] Inviato: mercoledì 9 settembre 2015 18.58 A: Monaco Marco Cc: Anuruddha Liyanarachchi; WSO2 Developers' List Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, What's Private PaaS distribution you are using? Can you please try with 4.1.0-Alpha: https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-ALPHA/ Thanks On Wed, Sep 9, 2015 at 11:22 AM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi Anuruddha, many thanks. I did it also with gui pasting JSON, and did it with UI, too. When I do with GUI it justs hangs for a while and came back to previous page... nothing is logged, also with DEBUG loglevel. Still stucked at this point. Marco Inviato dal mio dispositivo Samsung -------- Messaggio originale -------- Da: Anuruddha Liyanarachchi <[email protected]<mailto:[email protected]>> Data: 09/09/2015 07:47 (GMT+01:00) A: Monaco Marco <[email protected]<mailto:[email protected]>> Cc: WSO2 Developers' List <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 Hi Marco, This error occur when the cartridge definition doesn't contain iaasProvider section. I guess the path to your cartridge json is incorrect in the curl command. I deployed the same cartridge json, that you are using and I did not face any issue. Can you switch to JSON view from the UI and paste the cartridge definition and try to add it [1]. [1] https://drive.google.com/file/d/0B0v957zZwVWrQjVWX2x6YzI3Mkk/view?usp=sharing <https://drive.google.com/file/d/0B0v957zZwVWrQjVWX2x6YzI3Mkk/view?usp=sharing> On Wed, Sep 9, 2015 at 12:39 AM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Anuruddha, thank you for the suggestion. I made a git pull from repo without deleting DBs (just replacing files) and it started to spawn new instances, but it complained about public ip addresses and stopping. i made a fresh installation deleting all SQL dbs, but now we are stucked on another error. I successfully set up again Network Partition, Autoscale Policies, Deployment Policies, but when I came to cartridge Stratos started to missbehave. If I try to set up a cartridge on GUI it just stucks and then came back to Add Cartridge page. I tryied to use api (https://127.0.0.1:9443/api/cartridges) sending this json: { "type": "wso2esb-481-manager", "category": "framework", "provider": "wso2", "host": "esb.alma.it<http://esb.alma.it>", "displayName": "WSO2 ESB 4.8.1 Manager", "description": "WSO2 ESB 4.8.1 Manager Cartridge", "version": "4.8.1", "multiTenant": false, "loadBalancingIPType": "private", "portMapping": [ { "name": "mgt-http", "protocol": "http", "port": 9763, "proxyPort": 0 }, { "name": "mgt-https", "protocol": "https", "port": 9443, "proxyPort": 0 }, { "name": "pt-http", "protocol": "http", "port": 8280, "proxyPort": 0 }, { "name": "pt-https", "protocol": "https", "port": 8243, "proxyPort": 0 } ], "iaasProvider": [ { "type": "openstack", "imageId": "RegionOne/c2951a15-47b7-4f9c-a6e0-d3b7a50bc9aa", "networkInterfaces": [ { "networkUuid": "bd02ca5c-4a57-45c3-8478-db0624829bdb" } ], "property": [ { "name": "instanceType", "value": "RegionOne/3" }, { "name": "securityGroups", "value": "default" }, { "name": "autoAssignIp", "value": "true" }, { "name": "keyPair", "value": "alma-keypair" } ] } ], "property": [ { "name": "payload_parameter.CONFIG_PARAM_CLUSTERING", "value": "true" }, { "name": "payload_parameter.LB_IP", "value": "<LOAD_BALANCER_IP>" } ] } and getting this response: {"status":"error","message":"IaaS providers not found in cartridge: null"} in stratos logs I can see the same errors: [2015-09-08 19:00:26,600] ERROR {org.apache.stratos.rest.endpoint.handlers.CustomExceptionMapper} - IaaS providers not found in cartridge: null org.apache.stratos.rest.endpoint.exception.RestAPIException: IaaS providers not found in cartridge: null at org.apache.stratos.rest.endpoint.api.StratosApiV41Utils.addCartridge(StratosApiV41Utils.java:126) at org.apache.stratos.rest.endpoint.api.StratosApiV41.addCartridge(StratosApiV41.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:194) at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:100) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:93) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:223) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:203) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:159) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) and i'm not able to add any cartridge, including simple php. I triple checked all IaaS settings in cloud-controller.xml and in cartridge definitions and they are correct. Any throught? Tanks.... Marco ________________________________ Da: Anuruddha Liyanarachchi [[email protected]<mailto:[email protected]>] Inviato: martedì 8 settembre 2015 15.46 A: Monaco Marco; WSO2 Developers' List Cc: [email protected]<mailto:[email protected]> Oggetto: Re: Strange Error in WSO2 Private Paas 4.1.2 [Removing stratos dev and adding wso2dev ] Hi Marco, We have fixed this in the master branch with commit [1]. Please take a pull from master branch or download the alpha release pack from [2]. [1]https://github.com/wso2/product-private-paas/commit/54a77e9d85538a20ace00c57ec9e8aed410fb773 [2]https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-ALPHA/ On Tue, Sep 8, 2015 at 7:06 PM, Monaco Marco <[email protected]<mailto:[email protected]>> wrote: Hi, We have successfully installed WSO2 PPaaS 4.1.2 on our Openstack IaaS Environment. After following this procedure (https://docs.wso2.com/display/PP410/Deploy+Private+PaaS+in+OpenStack) we are able to open the Private PaaS console and configure Network Partitions, Autoscale Policies, Deployment, Cartridge, ecc.. We have problems trying to deploy applications. We tested both PHP and WSO2ESB applications, also using Mock IaaS, but we receive always the same error: ERROR {org.apache.stratos.autoscaler.rule.AutoscalerRuleEvaluator} - Unable to Analyse Expression log.debug("[scaling] Number of required instances based on stats: " + numberOfRequiredInstances + " " + "[active instances count] " + activeInstancesCount + " [network-partition] " + clusterInstanceContext.getNetworkPartitionId() + " [cluster] " + clusterId); int nonTerminatedMembers = clusterInstanceContext.getNonTerminatedMemberCount(); if(scaleUp){ int clusterMaxMembers = clusterInstanceContext.getMaxInstanceCount(); if (nonTerminatedMembers < clusterMaxMembers) { int additionalInstances = 0; if(clusterMaxMembers < numberOfRequiredInstances){ additionalInstances = clusterMaxMembers - nonTerminatedMembers; log.info<http://log.info>("[scale-up] Required member count based on stat based scaling is higher than max, hence" + " notifying to parent for possible group scaling or app bursting. [cluster] " + clusterId + " [instance id]" + clusterInstanceContext.getId() + " [max] " + clusterMaxMembers + " [number of required instances] " + numberOfRequiredInstances + " [additional instances to be created] " + additionalInstances); delegator.delegateScalingOverMaxNotification(clusterId, clusterInstanceContext.getNetworkPartitionId(), clusterInstanceContext.getId()); } else { additionalInstances = numberOfRequiredInstances - nonTerminatedMembers; } clusterInstanceContext.resetScaleDownRequestsCount(); log.debug("[scale-up] " + " [has scaling dependents] " + clusterInstanceContext.hasScalingDependants() + " [cluster] " + clusterId ); if(clusterInstanceContext.hasScalingDependants()) { log.debug("[scale-up] Notifying dependencies [cluster] " + clusterId); delegator.delegateScalingDependencyNotification(clusterId, clusterInstanceContext.getNetworkPartitionId(), clusterInstanceContext.getId(), numberOfRequiredInstances, clusterInstanceContext.getMinInstanceCount()); } else { boolean partitionsAvailable = true; int count = 0; String autoscalingReason = (numberOfRequiredInstances == numberOfInstancesReuquiredBasedOnRif)?"Scaling up due to RIF, [Predicted Value] "+rifPredictedValue+" [Threshold] "+rifThreshold:(numberOfRequiredInstances== numberOfInstancesReuquiredBasedOnMemoryConsumption)?"Scaling up due to MC, [Predicted Value] "+mcPredictedValue+" [Threshold] "+mcThreshold:"Scaling up due to LA, [Predicted Value] "+laPredictedValue+" [Threshold] "+laThreshold; autoscalingReason += " [Number of required instances] "+numberOfRequiredInstances+" [Cluster Max Members] "+clusterMaxMembers+" [Additional instances to be created] " + additionalInstances; while(count != additionalInstances && partitionsAvailable){ ClusterLevelPartitionContext partitionContext = (ClusterLevelPartitionContext) partitionAlgorithm.getNextScaleUpPartitionContext(clusterInstanceContext.getPartitionCtxtsAsAnArray()); if(partitionContext != null){ log.info<http://log.info>("[scale-up] Partition available, hence trying to spawn an instance to scale up! " + " [application id] " + applicationId + " [cluster] " + clusterId + " [instance id] " + clusterInstanceContext.getId() + " [network-partition] " + clusterInstanceContext.getNetworkPartitionId() + " [partition] " + partitionContext.getPartitionId() + " scaleup due to RIF: " + (rifReset && (rifPredictedValue > rifThreshold)) + " [rifPredictedValue] " + rifPredictedValue + " [rifThreshold] " + rifThreshold + " scaleup due to MC: " + (mcReset && (mcPredictedValue > mcThreshold)) + " [mcPredictedValue] " + mcPredictedValue + " [mcThreshold] " + mcThreshold + " scaleup due to LA: " + (laReset && (laPredictedValue > laThreshold)) + " [laPredictedValue] " + laPredictedValue + " [laThreshold] " + laThreshold); log.debug("[scale-up] " + " [partition] " + partitionContext.getPartitionId() + " [cluster] " + clusterId ); long scalingTime = System.currentTimeMillis(); delegator.delegateSpawn(partitionContext, clusterId, clusterInstanceContext.getId(), isPrimary,autoscalingReason,scalingTime); count++; } else { log.warn("[scale-up] No more partition available even though " + "cartridge-max is not reached!, [cluster] " + clusterId + " Please update deployment-policy with new partitions or with higher " + "partition-max"); partitionsAvailable = false; } } } } else { log.info<http://log.info>("[scale-up] Trying to scale up over max, hence not scaling up cluster itself and notifying to parent for possible group scaling or app bursting. [cluster] " + clusterId + " [instance id]" + clusterInstanceContext.getId() + " [max] " + clusterMaxMembers); delegator.delegateScalingOverMaxNotification(clusterId, clusterInstanceContext.getNetworkPartitionId(), clusterInstanceContext.getId()); } } else if(scaleDown){ if(nonTerminatedMembers > clusterInstanceContext.getMinInstanceCount){ log.debug("[scale-down] Decided to Scale down [cluster] " + clusterId); if(clusterInstanceContext.getScaleDownRequestsCount() > 2 ){ log.debug("[scale-down] Reached scale down requests threshold [cluster] " + clusterId + " Count " + clusterInstanceContext.getScaleDownRequestsCount()); if(clusterInstanceContext.hasScalingDependants()) { log.debug("[scale-up] Notifying dependencies [cluster] " + clusterId); delegator.delegateScalingDependencyNotification(clusterId, clusterInstanceContext.getNetworkPartitionId(), clusterInstanceContext.getId(), numberOfRequiredInstances, clusterInstanceContext.getMinInstanceCount()); } else{ MemberStatsContext selectedMemberStatsContext = null; double lowestOverallLoad = 0.0; boolean foundAValue = false; ClusterLevelPartitionContext partitionContext = (ClusterLevelPartitionContext) partitionAlgorithm.getNextScaleDownPartitionContext(clusterInstanceContext.getPartitionCtxtsAsAnArray()); if(partitionContext != null){ log.info<http://log.info>("[scale-down] Partition available to scale down " + " [application id] " + applicationId + " [cluster] " + clusterId + " [instance id] " + clusterInstanceContext.getId() + " [network-partition] " + clusterInstanceContext.getNetworkPartitionId() + " [partition] " + partitionContext.getPartitionId() + " scaledown due to RIF: " + (rifReset && (rifPredictedValue < rifThreshold)) + " [rifPredictedValue] " + rifPredictedValue + " [rifThreshold] " + rifThreshold + " scaledown due to MC: " + (mcReset && (mcPredictedValue < mcThreshold)) + " [mcPredictedValue] " + mcPredictedValue + " [mcThreshold] " + mcThreshold + " scaledown due to LA: " + (laReset && (laPredictedValue < laThreshold)) + " [laPredictedValue] " + laPredictedValue + " [laThreshold] " + laThreshold ); // In partition context member stat context, all the primary members need to be // avoided being selected as the member to terminated -- Imesh Gunaratne Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057<tel:%2B94%2077%20374%202057> W: http://imesh.gunaratne.org Lean . Enterprise . Middleware -- Imesh Gunaratne Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
