Re: Default VM Image
I'm in favor of adding Ubuntu 16.04 and CentOS 7 with score setting higher than previous versions. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 20 January 2017 at 00:17, Duncan Godwin <duncan.god...@cloudsoftcorp.com> wrote: > Hi All, > > Should we change the default image to CentOS 7 over Ubuntu 14.04? > > Apache Brooklyn, by default currently favours Ubuntu 14.04 and 12.04 LTS > images when no preference is selected. This is because of the code in > BrooklynImageChooser here: > > https://github.com/apache/brooklyn-server/blob/ > f4281af2e40a9d12264c566a4b65fa6549238be5/locations/jclouds/ > src/main/java/org/apache/brooklyn/location/jclouds/ > BrooklynImageChooser.java#L138-L149 > > Most of the blueprints in brooklyn-library seem to favour CentOS 7 and I > think most of the Apache Brooklyn users are using and testing CentOS 7. It > therefore seems to me to make sense to alter BrooklynImageChooser score to > favour CentOS 7 based images. What does everyone think? > > Many thanks > > Duncan >
Re: [VOTE] Release Apache Brooklyn 0.9.0 [rc4]
+1 I tested the rpm package install and uninstall and deployed simple webserver blueprint. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 8 April 2016 at 18:42, Andrea Turli <andrea.tu...@cloudsoftcorp.com> wrote: > +1 > > I have: > >- Verified the sha256 for each of the artifacts, verified that each > .tar.gz could be unpacked and built the src using the script attached. >- Installed + launched Brooklyn from src just built >- Created a new fake cloud Location with the location wizard just to > the reload the brooklyn properties, and verify that the cloud location is > still there (issue fixed) >- Deployed an empty server to localhost ( > > using the following environment: > > $ mvn -version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Maven home: /usr/local/Cellar/maven/3.3.9/libexec > Java version: 1.8.0_31, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.11.3", arch: "x86_64", family: "mac" > > $ go version > go version go1.6 darwin/amd64 > > > Also, I think the YAML composer problem is also gone, as the YAML pasted > doesn't disappear anymore as the composer is immediately loaded and > available, tested with: > > Google Chrome Version 49.0.2623.87 (64-bit) > > Best, > Andrea > > On 8 April 2016 at 16:04, Richard Downer <rich...@apache.org> wrote: > >> This is to call for a vote for the release of Apache Brooklyn 0.9.0 [rc4]. >> >> This release comprises of a source code distribution, and a corresponding >> binary distribution, RPM packages, Vagrant environment package, and Maven >> artifacts. >> >> The source and binary distributions, including signatures, digests, etc. >> can be found at: >> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-0.9.0-rc4 >> >> The artifact SHA-256 checksums are as follows: >> b9d8bdb3a0c8930df3043b2b590142970639ec911f31dd78723f4d3a78925675 >> *apache-brooklyn-0.9.0-rc4-1.noarch.rpm >> b798c353219dbec36b48db6fe5e792bf3bdd19cfa008a7bcb5c091b1d72f4b4f >> *apache-brooklyn-0.9.0-rc4-bin.tar.gz >> 47e8dae9d4c88eefe165fe810590b22f164dd6d6338b81a515627371965f885a >> *apache-brooklyn-0.9.0-rc4-bin.zip >> 760e8a371f7b7b51383f0e79acc9359426c6de43f06ee97fed2fb1f16429503b >> *apache-brooklyn-0.9.0-rc4-client-cli-linux.tar.gz >> 66e18fc0f35c50ad1741a668d290c06e3c1327008e6d7bc92137da752d746da8 >> *apache-brooklyn-0.9.0-rc4-client-cli-linux.zip >> 49dc1a46955d783c6e3e80385ee19d0de98a3739c718407e10e3405835d22af7 >> *apache-brooklyn-0.9.0-rc4-client-cli-macosx.tar.gz >> ce7320951cbacfb5ff65e4617da47caa0301a6a482b9083130b6a3db63695068 >> *apache-brooklyn-0.9.0-rc4-client-cli-macosx.zip >> 5a324042985f440901a3b21c7598d100f6823100019bde70d71dc34503df7408 >> *apache-brooklyn-0.9.0-rc4-client-cli-windows.tar.gz >> 825c383ccd6147c86496d0f00cf854f8f94867547952f16ac7d67a10de8f12c6 >> *apache-brooklyn-0.9.0-rc4-client-cli-windows.zip >> 619fefbaf6cdbd08edbe83a7795bfa7cdc039859dbb42ee090dba6236231da76 >> *apache-brooklyn-0.9.0-rc4-src.tar.gz >> 5c337b9d03efd18033a58d15d95a6ed12c7aeb59af0478956e9527bed5eac00b >> *apache-brooklyn-0.9.0-rc4-src.zip >> 0df4ee55102351748e732e393522fe6c0950da8a49b9df9fcb3fb75cb1c3c5a1 >> *apache-brooklyn-0.9.0-rc4-vagrant.tar.gz >> e458c2cc11c721d61495182ad6cd846e3a7cead1f064562c638cd335d82f7576 >> *apache-brooklyn-0.9.0-rc4-vagrant.zip >> >> The Nexus staging repositories for the Maven artifacts are located at: >> https://repository.apache.org/content/repositories/orgapachebrooklyn-1020 >> https://repository.apache.org/content/repositories/orgapachebrooklyn-1021 >> >> All release artifacts are signed with the following key: >> https://people.apache.org/keys/committer/richard.asc >> >> KEYS file available here: >> https://dist.apache.org/repos/dist/release/brooklyn/KEYS >> >> The artifacts were built from these Git commit IDs: >> brooklyn: acc8ff1930d243d2a5fae1ad2f1a1ef17ca4a19c >> brooklyn-client: bc8593a933fcb76327ae4a511643e39d25a87ba2 >> brooklyn-dist: c18130c9e36222e6a27f7cf8ce0e0db5309da4de >> brooklyn-docs: 12430d193e1891b87a677d6b45a3b17861c83518 >> brooklyn-library: 2565e6eb2868468ec2528df74fe85efdb887b6d2 >> brooklyn-server: d520fde682dfb597487943ec62ffb752d0f6ef17 >> brooklyn-ui: 165482f4a1abfdcd244db92e2c9f770d81ff6b52 >> All of the above have been tagged as "rel/apache-brooklyn-0.9.0-rc4". >> >> Please download the artifacts, test, and vote on releasing this package as >> Apache Brooklyn 0.9.0. >> >> The vote will be open for at least 72 hours. >> [ ] +1 Release this package as Apache Brooklyn 0.9.0 (please describe the >> tests you have performed) >> [ ] +0 no opinion >> [ ] -1 Do not release this package (please describe why not) >> >> Thanks >> Richard. >> > >
Re: [CANCEL][VOTE] Release Apache Brooklyn 0.9.0 [rc3]
Thank you very much Aled. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 8 April 2016 at 00:18, Aled Sage <aled.s...@gmail.com> wrote: > Thanks Aleksandr, > > Sorry I missed that. I've added brooklyn-dist PR #32 to 0.9.0 branch, > ready for the next release candidate. > > Aled > > > > On 07/04/2016 22:04, Aleksandr Vasilev wrote: > >> Aled, >> >> I'd like to have this PR included as well, as it removes the error during >> the RPM install: >> https://github.com/apache/brooklyn-dist/pull/32 >> >> Thanks! >> >> Best Regards, >> >> Aleksandr Vasilev >> DevOps Engineer | Cloudsoft Corporation >> >> On 7 April 2016 at 23:42, Aled Sage <aled.s...@gmail.com> wrote: >> >> Hi all, >>> >>> Based on the bug Svet found, and his -1, I'm cancelling the 0.9.0 rc3 >>> vote. >>> >>> I've cherry-picked the following commits into the 0.9.0 branches: >>> >>> * https://github.com/apache/brooklyn-ui/pull/25, which fixes the >>> problem Svet hit. >>> * https://github.com/apache/brooklyn-server/pull/105, which fixes the >>> "Template 2: Bash Web Server" for folk who don't have python >>> pre-installed, and who are running as non-root user (with >>> password-less sudo). >>> >>> I suggest we live with >>> https://issues.apache.org/jira/browse/BROOKLYN-250, >>> given that we don't have a fix for that yet (the "new location" wizard >>> does >>> not correctly set the display name - instead it uses the location id). >>> >>> Unless anyone has anything else that needs to be included, or thinks that >>> BROOKLYN-250 should be fixed and is low-risk/fast to do so, then I think >>> we're ready for another release candidate. >>> >>> Aled >>> >>> >>> >
Re: [VOTE] Release Apache Brooklyn 0.9.0 [rc3]
I addressed the issue with the RPM install:
https://github.com/apache/brooklyn-dist/pull/32
(Thanks Svet for pointing it out)
Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation
On 7 April 2016 at 15:16, Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
wrote:
> I created a PR for this: https://github.com/apache/brooklyn-ui/pull/25
>
> On Thu, 7 Apr 2016 at 12:55 Thomas Bouron <thomas.bou...@cloudsoftcorp.com
> >
> wrote:
>
> > Found the issue:
> >
> https://github.com/apache/brooklyn-ui/blob/c31ec2c962b925c907d513a62dd095acacb9cea0/src/main/webapp/assets/js/libs/jquery.easy-autocomplete.js#L352-L360
> >
> > The jquery.easy-autocomplete.js library creates a new `contains` method
> > within the `Array.prototype`. While this usually work for objects, it
> > doesn't for arrays as this `contains` methods becomes a key of every
> array
> > defined afterward. Meaning:
> >
> > Array.prototype.contains = function() {};
> > // somewhere deep in other javascript code...var a = [1,2,3,4,5];for (x
> in a) {
> > // Now contains is a part of EVERY array and
> > // will show up here as a key of 'a'}
> >
> > A quick workaround would be to add:
> >
> > delete Array.prototype.contains;
> >
> > when the location wizard view is destroyed. I tested it and it worked.
> > Unfortunately, it means that any views using the library onward will need
> > to do the same. So for the future, we need to swap it for another one.
> >
> > Are you happy to go with the workaround?
> >
> > Best.
> >
> > On Thu, 7 Apr 2016 at 12:38 John McCabe <j...@johnmccabe.net> wrote:
> >
> >> @andrea you need to bump your go to 1.6 and retry.
> >>
> >> I have:
> >> - spun up the vagrant box (had to inject the rc3 download url as its not
> >> on
> >> the mirrors) without observing any issues
> >> - checked port forwarding looks ok - binds to http://localhost:8081 on
> >> the
> >> host
> >> - checked byon location catalog loads without issue
> >> - checked display name for inherited locations looks ok
> >> - deployed tomcat app to byon location
> >> - confirm issue observed by @neykov, and also refresh as suggested by
> >> @tbouron
> >> - raised BROOKLYN-250, noticed that when adding locations to the catalog
> >> (yaml or wizard), the displayName isn't being used in dropdowns or on
> the
> >> catalog page (it uses name if present and falls back to id)
> >>
> >> On Thu, 7 Apr 2016 at 11:48 Andrea Turli <
> andrea.tu...@cloudsoftcorp.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > Borrowing some ideas from Apache jclouds community [1] I'd like to
> >> propose
> >> > to use the same workflow:
> >> >
> >> > Validating an Apache Brooklyn release involves verifying the
> following:
> >> >
> >> > - Verify that the checksums are valid.
> >> > - Verify that the PGP signatures are valid.
> >> > - Check that the expanded source archive matches contents of RC tag.
> >> > - Verify that the expanded source archive builds and passes tests.
> >> > - Check that LICENSE and NOTICE files are present and correct.
> >> > - Make sure all files have license headers where appropriate.
> >> > - Check that all dependencies have compatible licenses.
> >> > - Verify that no compiled archives bundled in source archive.
> >> >
> >> > Some steps require a manual verification, and others are fully
> >> automated.
> >> > The following scripts can be used:
> >> >
> >> > - Verify RAT, build, tests, checksums and signatures in one script
> >> >
> >> > Download the verification script:
> >> >
> >> > Unix: see the attachment
> >> > If we accept the script we can then upload it to
> >> > https://dist.apache.org/repos/dist/dev/brooklyn/verify_jclouds_rc.sh
> >> >
> >> > Run it and watch for failures:
> >> >
> >> > Unix:
> >> > chmod +x verify_brooklyn_rc.sh
> >> > ./verify_brooklyn_rc.sh 0.9.0-rc3
> >> >
> >> > Notice if you're running this on a Mac, you'll need brew and to do a
> >> brew
> >> > install gpg first.
> >> >
> >> > By the way running the script I've got
> >> >
> >> > [INFO]
> >> > [INFO]
> >> >
>
Re: [VOTE] Release Apache Brooklyn 0.9.0 [rc1]
+1 Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 31 March 2016 at 16:16, Richard Downer <rich...@apache.org> wrote: > This is to call for a vote for the release of Apache Brooklyn 0.9.0 [rc1]. > > This release comprises of a source code distribution, and a corresponding > binary distribution, RPM packages, Vagrant environment package, and > Maven artifacts. > > The source and binary distributions, including signatures, digests, etc. > can > be found at: > https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-0.9.0-rc1 > > The artifact SHA-256 checksums are as follows: > c03938c4c7a060e8e50f435170e5033277f09c84a54d4abcf0d949c807de9363 > *apache-brooklyn-0.9.0-rc1-1.noarch.rpm > 777663bbc4cf2d4228ea5dfdfd3e17b5aeaefc3a72ef51d6560fdffe27fc0f46 > *apache-brooklyn-0.9.0-rc1-bin.tar.gz > 4dcaa31e68fed04217aa2b976675cd9b92db0d8f24735c033081ecd3128985d0 > *apache-brooklyn-0.9.0-rc1-bin.zip > ef697bfe7d1f4b83964a008a2f92ee92282a1f6160904d3e7b51e571b0002422 > *apache-brooklyn-0.9.0-rc1-src.tar.gz > 149eef62981f154c1bff7a0f41ddbbbc6f0b40c21997391f9a273db156a405ce > *apache-brooklyn-0.9.0-rc1-src.zip > 1b39a3c2da645a05026882c106d321e8f34fd19d8d3864baab88952538315d30 > *apache-brooklyn-0.9.0-rc1-vagrant.tar.gz > cae31212f1293e557c4039138f95769d2c58de7478cbc3b5bf8a9d5c03dfd7a2 > *apache-brooklyn-0.9.0-rc1-vagrant.zip > > The Nexus staging repositories for the Maven artifacts are located at: > https://repository.apache.org/content/repositories/orgapachebrooklyn-1014 > https://repository.apache.org/content/repositories/orgapachebrooklyn-1015 > > All release artifacts are signed with the following key: > https://people.apache.org/keys/committer/richard.asc > > KEYS file available here: > https://dist.apache.org/repos/dist/release/brooklyn/KEYS > > The artifacts were built from these Git commit IDs: > brooklyn: acc8ff1930d243d2a5fae1ad2f1a1ef17ca4a19c > brooklyn-client: 64573c8e1b8630f59b23356520282c91cc46a8a1 > brooklyn-dist: 0b8b81df458fa4323939582d9f0dda10b2f6eaee > brooklyn-docs: 12430d193e1891b87a677d6b45a3b17861c83518 > brooklyn-library: 76c0c720edfcd9ad4f7bd70352ece6f08fb5aaad > brooklyn-server: 1ccdef868ae798add88f51e269df87c01bd8544f > brooklyn-ui: 307382128951bb237bc351ac22136745e5d50475 > All of the above have been tagged as "apache-brooklyn-0.9.0-rc1". > > > Please vote on releasing this package as Apache Brooklyn 0.9.0. > > The vote will be open for at least 72 hours. > [ ] +1 Release this package as Apache Brooklyn 0.9.0 > [ ] +0 no opinion > [ ] -1 Do not release this package because ... > > > Thanks, > Richard. >
Re: brooklyn br cli + go lang required for build
Hi Alex, I'm interested in the implementation details of "-Dno-go-client" option as I'd like to implement the same thing for RPM packaging as per your advice. I searched through Brooklyn uber project but only found readme articles and links to golang website. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 10 March 2016 at 05:10, Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote: > > > This is to announce that the Brooklyn Client Command Line Interface tool > has been > > added to the Apache Brooklyn "brooklyn-client" repository [1]. > > This is excellent! Great work Robert, Geoff, and David. > > I've already switched to using the CLI for many things, from deploying to > looking up details. The fun will really start when we're embedding this in > scripts and using `jq` on the output. > > You may have seen lots of commits across projects just now: the CLI is > now built and bundled as part of the dist. This means you need Go 1.6 > installed. Or you can use `-Dno-go-client` if building in the uber. (See > the README at [1].) > > Now we just need to release 0.9.0. > > Best > Alex > > [1] https://github.com/apache/brooklyn > > > On 09/03/2016 12:35, Geoff Macartney wrote: > >> This is to announce that the Brooklyn Client Command Line Interface tool >> has been added to the Apache Brooklyn "brooklyn-client" repository [1]. >> >> This is a lightweight, standalone command line client for Apache >> Brooklyn, written in Go. The intention is to provide the same control over >> Brooklyn that until now has only been possible via the graphical UI, but at >> the command line. So not only can Brooklyn now be used without requiring a >> web browser, but it also allows power users and devops teams to automate >> Brooklyn with shell scripts. >> >> The tool name is "br". Just to give a couple of quick examples, you >> could deploy a blueprint with >> >> $ br deploy webapp.yaml >> >> You can then check the progress of the installation by querying the >> application you just deployed: >> >> $ br application WebCluster >> Id: lmOcZbsT >> Name:WebCluster >> Status: RUNNING >> ServiceUp: true >> ... etc. >> >> (or just "br app"). >> >> The tool also lets you examine the status of individual entities in the >> application, check sensor values and policy configuration, examine the >> activity history, and even invoke effectors. >> >> The documentation for Brooklyn will be updated with guides for the CLI, >> and you can already read the current snapshot documentation [2]. >> >> It is worth noting that the tool is still under development, and, while >> it has broad coverage of Brooklyn functionality at present, there are still >> things to do. >> >> If you are interested in seeing a demo of the CLI in action, you might >> want to look at a blog post I wrote recently [3]. This is actually on a >> different topic (Brooklyn Salt integration) but does show the CLI in action. >> >> Thanks to Cloudsoft for contributing this to Apache Brooklyn. >> >> Regards >> Geoff Macartney >> >> [1] https://github.com/apache/brooklyn-client >> [2] https://brooklyn.apache.org/v/0.9.0-SNAPSHOT/ops/cli/index.html >> [3] >> http://www.cloudsoftcorp.com/blog/2016/03/salt-support-in-apache-brooklyn/ >> >> >> Gnu PGP key - http://is.gd/uI >> >> >> >> >
Re: [VOTE] Accept contribution of Brooklyn CLI
+1 On Thursday, February 18, 2016, Morgan Wright <mor...@cloudsoftcorp.com> wrote: > +1 > On Thu, Feb 18, 2016 at 8:00 AM Morgan Wright <mor...@cloudsoftcorp.com > <javascript:;>> > wrote: > > > > > On Thu, Feb 18, 2016 at 7:52 AM Duncan Godwin < > > duncan.god...@cloudsoftcorp.com <javascript:;>> wrote: > > > >> +1 > >> > >> On 18 February 2016 at 15:51, David Lloyd <da...@lloyds.org.uk > <javascript:;>> wrote: > >> > >> > +1 > >> > > >> > /Dave. > >> > > >> > On 18/02/2016 15:25, Richard Downer wrote: > >> > > >> >> All, > >> >> > >> >> https://github.com/apache/brooklyn-client/pull/1 adds the Brooklyn > >> >> CLI. This allows a user to control and script Brooklyn from the > >> >> command line. It opens up many possibilities, including making the > web > >> >> UI optional (reducing the security footprint in production > >> >> deployments), allowing admins to script Brooklyn using shell scripts, > >> >> and simplifies our getting started tutorials. It's a very compelling > >> >> addition to the Brooklyn project. > >> >> > >> >> The CLI was developed in a non-Apache location starting last year, > >> >> with the bulk of development happening from November onwards. It has > >> >> > >> >>> 150 commits from 4 authors and is over 6,000 SLOC. Given the size of > >> >>> > >> >> the contribution, it is prudent to follow Apache's IP clearance > >> >> process before merging the PR. > >> >> > >> >> This vote is to discover if the Brooklyn PMC and community are in > >> >> favour of accepting this contribution. If the vote passes, the PMC > and > >> >> the authors of the code will work together to complete Apache's IP > >> >> Clearance process and merge the code for the CLI. > >> >> > >> >> This vote will be open for at least 72 hours (i.e. 15:30 UTC on > Sunday > >> >> 21st February 2016) > >> >> > >> >> [ ] +1, accept contribution of the Brooklyn CLI into the project > >> >> [ ] 0, no opinion > >> >> [ ] -1, reject contribution because... > >> >> > >> >> Thanks, > >> >> Richard. > >> >> > >> > > >> > > >> > > > -- Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation
Re: Brooklyn Daemon Solution
Alex, In this case, I agree that wrapping java command in a service script may be the best choice. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 20:50, Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote: > > Aleksandr, > > Is there anyone who needs this level of security? In my experience a > service calling a shell script is common, and in the cases where someone > needs something stronger they can build it. They possibly have custom > requirements there in any case. Bear in mind a daemon is going to > introduce a lot of complexity (many different OS's) so it would need to > offer major benefits to users or it's just not worth it, in my view. > > OTOH hopefully this is being considered as part of putting together RPM's > and DEB's and Docker images, as part of the Brooklyn build. In which case > the sooner we have that the better, because people do want those. Even > installing as a service I think is optional. > > FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users > to implement. In practice I mainly see service scripts calling the > catalina start shell script which uses java -- not jsvc. > > Best > Alex > > [1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html > > > > On 29/01/2016 15:58, Aleksandr Vasilev wrote: > >> Regarding the security implications when using a script vs a binary, >>> >> could you explain? >> It's not the difference between binary vs script, it's the different >> approach at launching the process. In my daemon I make sure child process >> is detached from the parent and can't get hold of any terminal sessions, >> so >> an attacker can't get any additional privileges. >> >> with file descriptor redirection, beyond stderr, stdout what are you >>> considering >>> >> here? >> Nothing more unless any other file descriptors are opened by Brooklyn. The >> daemon makes sure to close them all. >> >> are you intending this to be used outside of init? we'd have the config >>> >> set externally to the daemon >> Not at all, just suggesting it can be used in any type of service script >> >> we don't have to wrap a script surely? the init script doesn't have to >>> >> call the brooklyn script. >> Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm >> not sure this solution detaches the child process properly. >> >> >> Best Regards, >> Aleksandr Vasilev >> DevOps Engineer | Cloudsoft Corporation >> >> >> On 29 January 2016 at 18:45, John McCabe <j...@johnmccabe.net> wrote: >> >> Hi Aleksandr, >>> >>> 1. Proper detaching from the parent process, making daemon more secure >>>> 2. Proper detaching from any TTYs, making daemon even more secure >>>> >>> Regarding the security implications when using a script vs a binary, >>> could >>> you explain? >>> >>> 3. Proper redirection of all file descriptors, helps with debugging and >>>> logging >>>> >>> with file descriptor redirection, beyond stderr, stdout what are you >>> considering here? >>> >>> 5. More flexible solution: ability to run Brooklyn with any arguments, >>>> service script will have "brooklyn launch" part hardcoded and will >>>> >>> require >>> >>>> to edit the code each time you need to run it with the new args. >>>> >>> are you intending this to be used outside of init? we'd have the config >>> set >>> externally to the daemon >>> >>> Overall I see the native daemon solution as more traditional and >>>> >>> compliant >>> >>>> to Linux standards than just wrapping bash script in yet another script. >>>> >>> we don't have to wrap a script surely? the init script doesn't have to >>> call >>> the brooklyn script. >>> >>> All the best, >>> John >>> >>> On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < >>> aleksandr.vasi...@cloudsoftcorp.com> wrote: >>> >>> Hi Alex, >>>> >>>> The advantages of having a native daemon in my opinion are: >>>> 1. Proper detaching from the parent process, making daemon more secure >>>> 2. Proper detaching from any TTYs, making daemon even more secure >>>> 3. Proper redirection of all file descriptors, helps with debugging and >>>> logging >>>> 4. More portable solution, as the daemo
