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 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: Bringing Apache Brooklyn RPM package to the official Fedora repositories
Hi Valentin, The reason we decided to put Brooklyn into /opt/ directory is because there is no binaries to run, it is a bunch of libraries which by the convention goes to /opt/. The only issue there might be having /opt/brooklyn/bin dir, which can be easily removed (it contains only bash scripts to start the app). Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 15 April 2016 at 01:23, Valentin Aitken < valentin.ait...@cloudsoftcorp.com> wrote: > Hi all, > > I did the first two steps for applying for Fedora's Package Review Process > <https://fedoraproject.org/wiki/Package_Review_Process> > Look [2] and [3]. I tested it and works well. > > Please review and share your thoughts about [1] and [2] because I think it > needs discussion. > > Main points: > - changing directory structure to standard /usr folder instead of using > /opt > - PR-ing some changes against against brooklyn-dist repo > - place for publishing the .spec and src.rpm to apply for Apache Brooklyn > to become Mainstream Fedora Package > > Valentin. > > [1] > https://github.com/apache/brooklyn-dist/blob/master/rpm-packaging/pom.xml > [2] https://github.com/bostko/brooklyn_fedorapkg/blob/master/brooklyn.spec > [3] > https://github.com/bostko/brooklyn_fedorapkg/releases/download/0.1/brooklyn-0.9.0-0.src.rpm > > > On 12/04/16 00:46, Valentin Aitken wrote: > >> Hi, >> >> What do you think about adding Apache Brooklyn to Fedora and from there >> to Redhat and CentOS? >> >> As an opensource project I think it will be good to bring it to more >> wider audience to the Fedora Community. >> >> However before applying, when reading Fedora's Package Review Process < >> https://fedoraproject.org/wiki/Package_Review_Process> [1], >> I recognize several build problems: >> - cannot find a location where the rpm spec file is publicly available. >> Only rpm available in [2] >> - there is no srpm publicly available >> - I think the spec file should be tested outside the rpm-maven-plugin. >> I tested cd brooklyn-dist/packaging/target/rpm/apache-brooklyn/SPECS; >> rpmbuild -ba apache-brooklyn.spec >> and it didn't work >> >> For this to happen we have to also maintain a Fedora repo like this [3] >> but I guess I am not the only one keen on getting this to Fedora >> community. >> >> Valentin. >> >> [1] https://fedoraproject.org/wiki/Package_Review_Process >> [2] >> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-0.9.0-rc2/ >> [3] http://pkgs.fedoraproject.org/cgit/rpms/httpd.git/tree/ >> [4] https://fedoraproject.org/wiki/How_to_create_an_RPM_package >> > >
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 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 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 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 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: [CANCEL][VOTE] Release Apache Brooklyn 0.9.0 [rc3]
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 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
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 >
> 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 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]
> >> >
>
> >> > [INFO] Build
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 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 Builds on OSX
Hi Andrew, For Svet and I simple brew install rpm was enough to fix the problem. But for some people the solution you mentioned was also necessary. I will update the docs soon with this method. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 14 March 2016 at 09:06, Andrew Kennedy wrote: > Hi. > > I noticed with the new RPM packaging the build of Brooklyn master failed > on my OSX laptop. To save people the Google searching, here is what I had > to do to fix things: > > % sudo port install rpm > ... > % echo "%_tmppath /tmp" >> ~/. rpmmacros > > This is from the following StackOverflow answer: > > - > http://stackoverflow.com/questions/25277878/make-rpm-maven-plugin-work-on-mac-osmavericks > > I couldn't see anything covering this on the list, but apologies if this > is already common knowledge ;) > > Cheers, > Andrew. > -- > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft >
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 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 wrote: > +1 > On Thu, Feb 18, 2016 at 8:00 AM Morgan Wright > > wrote: > > > > > On Thu, Feb 18, 2016 at 7:52 AM Duncan Godwin < > > duncan.god...@cloudsoftcorp.com > wrote: > > > >> +1 > >> > >> On 18 February 2016 at 15:51, David Lloyd > 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 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 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 solu
Re: Brooklyn Daemon Solution
> 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 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 daemon can be used in any type of > service > > scripts or even on its own, not only systemd script > > 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. > > > > Overall I see the native daemon solution as more traditional and > compliant > > to Linux standards than just wrapping bash script in yet another script. > > > > Best Regards, > > Aleksandr Vasilev > > DevOps Engineer | Cloudsoft Corporation > > > > On 29 January 2016 at 17:30, John McCabe wrote: > > > > > [bumping so aleks can see the thread] > > > > > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > > > andrew.kenn...@cloudsoftcorp.com> wrote: > > > > > > > Or what about running a Brooklyn Docker image as a systemd service! > > > > > > > > - > > http://container-solutions.com/running-docker-containers-with-systemd/ > > > > - https://github.com/ibuildthecloud/systemd-docker > > > > > > > > Andrew. > > > > > > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > > > > alex.henev...@cloudsoftcorp.com> > > > > wrote: > > > > > > > > > > > > > > Hi Aleksandr- > > > > > > > > > > What's the advantage of a native daemon over just wrapping it as a > > > linux > > > > > service script ? > > > > > > > > > > Best > > > > > Alex > > > > > > > > > > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > > > > Hello everyone! > > > > > > > > > > > > I spent last few days looking at the solution to run Brooklyn > > process &g
Re: Brooklyn Daemon Solution
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 daemon can be used in any type of service scripts or even on its own, not only systemd script 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. Overall I see the native daemon solution as more traditional and compliant to Linux standards than just wrapping bash script in yet another script. Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 17:30, John McCabe wrote: > [bumping so aleks can see the thread] > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < > andrew.kenn...@cloudsoftcorp.com> wrote: > > > Or what about running a Brooklyn Docker image as a systemd service! > > > > - http://container-solutions.com/running-docker-containers-with-systemd/ > > - https://github.com/ibuildthecloud/systemd-docker > > > > Andrew. > > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < > > alex.henev...@cloudsoftcorp.com> > > wrote: > > > > > > > > Hi Aleksandr- > > > > > > What's the advantage of a native daemon over just wrapping it as a > linux > > > service script ? > > > > > > Best > > > Alex > > > > > > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote: > > > > Hello everyone! > > > > > > > > I spent last few days looking at the solution to run Brooklyn process > > as > > > a > > > > daemon and found two options: > > > > 1. Run daemon via Apache Commons Daemon (jsvc) > > > > 2. Write a custom daemon in C > > > > > > > > Both solutions has its own pros and cons, so let's look at what I > think > > > > they are: > > > > > > > > JSVC: > > > > Pros: > > > > - Ready to use solution. Running a daemon via jsvc is very similar to > > > > running java application from the command line with similar arguments > > > > passed. > > > > - Builds as usual in Maven > > > > > > > > Cons: > > > > - Still requires you to write daemon code, which in my opinion kills > > the > > > > out-of-the-box usability > > > > - Has tons of bugs, including: not been able to find classes in > > > classpath, > > > > not been able to run by non-root users, not been able to run on > several > > > > *nix systems (Mac OS, BSD) > > > > - The codebase hasn't changed since 2013 and seems abandoned > > > > - SVN repo often isn't accessible for some reason, right now the > > > webserver > > > > returns 503 error code: > > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ > > > > > > > > Custom Daemon (written in C): > > > > Pros: > > > > - Cross-platform, runs on any *nix system supported by Brooklyn > > > > - Very little code to maintain > > > > - Independent from third-party solutions, requires only gcc to build > > > > - Easy to make LSB-compliant init scripts to control the daemon > > > > > > > > Cons: > > > > - Requires some overhead to build C code in Maven > > > > > > > > Having all these options considered, I propose writing daemon for > > Apache > > > > Brooklyn in C language and use gcc compiler to build it. It will > > require > > > > introducing some changes to Maven build process, but there are plenty > > of > > > > solutions for doing this, such as Maven NAR plugin, which is actively > > > > maintained: > > > > https://github.com/maven-nar/nar-maven-plugin > > > > > > > > Best Regards, > > > > Aleksandr Vasilev > > > > DevOps Engineer | Cloudsoft Corporation > > > > > > > > > > -- > > > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > > >
Brooklyn Daemon Solution
Hello everyone! I spent last few days looking at the solution to run Brooklyn process as a daemon and found two options: 1. Run daemon via Apache Commons Daemon (jsvc) 2. Write a custom daemon in C Both solutions has its own pros and cons, so let's look at what I think they are: JSVC: Pros: - Ready to use solution. Running a daemon via jsvc is very similar to running java application from the command line with similar arguments passed. - Builds as usual in Maven Cons: - Still requires you to write daemon code, which in my opinion kills the out-of-the-box usability - Has tons of bugs, including: not been able to find classes in classpath, not been able to run by non-root users, not been able to run on several *nix systems (Mac OS, BSD) - The codebase hasn't changed since 2013 and seems abandoned - SVN repo often isn't accessible for some reason, right now the webserver returns 503 error code: http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ Custom Daemon (written in C): Pros: - Cross-platform, runs on any *nix system supported by Brooklyn - Very little code to maintain - Independent from third-party solutions, requires only gcc to build - Easy to make LSB-compliant init scripts to control the daemon Cons: - Requires some overhead to build C code in Maven Having all these options considered, I propose writing daemon for Apache Brooklyn in C language and use gcc compiler to build it. It will require introducing some changes to Maven build process, but there are plenty of solutions for doing this, such as Maven NAR plugin, which is actively maintained: https://github.com/maven-nar/nar-maven-plugin Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation
