I also don't think that we have an option to provide payload params on a subscription and we probably have this somewhere in Jira as a future improvement. (this can't be supported for Multi-tenant cartridges)
Ports check should definitely be an extension (this was raised before too) and should remove the code portion which does that by default IMO. On Mon, Aug 4, 2014 at 1:48 AM, Sajith Kariyawasam <[email protected]> wrote: > > On Sun, Aug 3, 2014 at 6:51 PM, Imesh Gunaratne <[email protected]> wrote: > >> >> Great work Lasindu! Few comments inline: >> >> On Sat, Aug 2, 2014 at 9:49 PM, Lasindu Charith <[email protected]> wrote: >> >> >>> Yet I have following concerns when it comes to Nodejs specific >>> applications. >>> >>> 1. The nodejs application itself defines the ports in use. >>> >>> > But still, as per my understanding that can be controlled using > environment variables [1] , and we should ask the application developers > (tenants) to use that way. > Because, even if it specified ports as they wish, those are anyway > controlled by the IaaS specific security-groups, which is pre-defined by > the Stratos super admins > > If we are to provide ports per subscription (As Akila also have mentioned > I'm not sure how / whether its supported), we need to support > security-groups per subscription as well > > [1] > http://stackoverflow.com/questions/18864677/what-is-process-env-port-in-node-js > >> >>> 1. This may create problems in specifying the cartridge definition >>> prior to the deployment. The port to be listened has to be specified >>> correctly in the cartridge definition in order for a particular instance >>> to >>> be activated properly. >>> >>> IMO this is not a problem. Cartridge definition anyway needs to define >> the ports. >> >>> >>> 1. Since we only can specify a single cartridge definition per >>> service type, all the ports which will be used by the nodejs application >>> has to be pre-defined/pre-known and at the time of defining the cartridge >>> definition. Also instance might hang up waiting, listing to the ports >>> which >>> are currently not used. >>> >>> Not exactly. If required we can send the ports at the subscription time >> using payload parameters (if the instance can configure them accordingly). >> >>> >>> 1. Monitoring the health would also be difficult. >>> >>> What's problem we have here? We should be able to monitor the sockets I >> guess. >> >>> >>> 1. Deploying multiple applications using the same git repository >>> could be done. But will have to use a separate configuration file to >>> specify which/how to start those applications specifically. Also the >>> necessary ports have to be specified in the definition prior to the >>> deployment. >>> >>> Our current design is to use a Git repository per >> application/subscription. >> >>> >>> >>> Please let me know any specifics/suggestions which I can use to overcome >>> the above issues. >>> >>> [1] https://forge.puppetlabs.com/puppetlabs/nodejs >>> [2] https://github.com/nodejitsu/forever >>> [3] https://github.com/Unitech/pm2 >>> >>> Thanks, >>> >>> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PPMC Member, Apache Stratos >> > > > > -- > *--* > *Sajith Kariyawasam* > *Mobile: +94772269575 <%2B94772269575>* > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
