Re: [VOTE] Release Apache Brooklyn 1.1.0 [rc1]
Hello all, I've performed the following on macOS (M1) , Sonoma 14.2.1 (23C71). - Download links work. - Binaries work. - Checksums and PGP signatures are valid. * --> !!! Not sure if this is related but when trying to run the cli on macOS, I got the warnings attached. I remember a discussion last year about registering a contributor to this project as a registered macOS developer, but not sure if anything came of that. * - Expanded source archive matches contents of RC tag. - Expanded source archive builds and passes tests. - LICENSE is present and correct. - NOTICE is present and correct, including copyright date. - All files have license headers where appropriate. - All dependencies have compatible licenses. - No compiled archives bundled in the source archive. - I follow this project’s commits list. - Apache Brooklyn started successfully with no exceptions in the logs. - All pages displayed correctly and responsive(on Brave, Firefox and Chrome). - The catalog is populated with default blueprints. - The `br` cli works for adding a location to the catalog and location appears in the catalog page and location page. - Used the Graphical Composer to create a simple app and deploy it in the location added with the cli. - Deleted the app using the `stop` effector. Unless the macOS complaint about this product's developer not being verified is critical, it's a *LGTM, ready to +1. * Cheers, Iuliana Cosmina On Mon, 5 Feb 2024 at 22:28, Geoff Macartney wrote: > I've done (Mac Monterey) > >- Download links work >- Binaries works (just tested the tar tbh) >- LICENSE is present and correct. >- NOTICE is present and correct, including copyright date. >- All files have license headers where appropriate. >- All dependencies have compatible licenses (As far as I know) >- No compiled archives bundled in source archive. >- Deployed and deleted simple server template app. > > LGTM, ready to +1. Don't think the failure with nginx needs to block the > release. In future maybe a simpler example might be worthwhile. > > Geoff > > > > > On Mon, 5 Feb 2024 at 15:42, Thomas Bouron > wrote: > > > Hi all. > > > > Here are the tests I've successfully conducted on my MacBook running > Sonoma > > 14.3 running Java 1.8.0.292 > > > >- Download links work > >- Binaries works (unpacked and tested both tar and zip) > >- LICENSE is present and correct. > >- NOTICE is present and correct, including copyright date. > >- All files have license headers where appropriate. > >- All dependencies have compatible licenses (As far as I know) > >- No compiled archives bundled in source archive. > > > > I have also deployed, used and tear down template 1 (1-server-template) > and > > 4 (4-resilient-bash-web-cluster-template) on AWS, region `eu-west-1`. > > Template 4 failed to deployed because nginx couldn't compile (C compiler > > missing) but this is an issue with the blueprint itself, not Brooklyn. > > > > Given the circumstances, I'll +1 this RC unless people feel strongly > about > > fixing the blueprint. > > > > Best. > > > > On Fri, 2 Feb 2024 at 10:51, Duncan Grant wrote: > > > > > This is to call for a vote for the release of Apache Brooklyn 1.1.0. > > > > > > This release comprises of a source code distribution, and a > corresponding > > > binary distribution, 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-1.1.0-rc1 > > > > > > The artifact SHA-256 checksums are as follows: > > > > > > 7e9f516888cd449b4336b490a1a61f2ad38e043f780e89287aa66c4f8372638e > > > *apache-brooklyn-1.1.0-rc1-1.noarch.rpm > > > 0444355d282e997d45b78c1db2917e6868c7406cd4a4f32e5687dc61c6911665 > > > *apache-brooklyn-1.1.0-rc1-bin.tar.gz > > > 68a8bafbc08da9e1098fe9b62862347fdeb3f5eb126b7ff324ca8ac7e19c2d19 > > > *apache-brooklyn-1.1.0-rc1-bin.zip > > > 9e3ec65c85823d577e8ba2e52245f4f8a79e21fdab9fe2e491c0292315b8feb8 > > > *apache-brooklyn-1.1.0-rc1-classic.tar.gz > > > 1f26e6344dd87e0fc4044fbdcf4a9dfeb82bab0ada0ebebed6d9efade13a09d7 > > > *apache-brooklyn-1.1.0-rc1-classic.zip > > > 2b1624321e867b2b2953aa20b9a30d3c81594f2bf3d62cb977879dd21bab6289 > > > *apache-brooklyn-1.1.0-rc1-client-cli-linux.tar.gz > > > 8eee13fd6f1112df4e2e7019e1891acd1fc01fe539fb34a7c910c3bb2c057810 > > > *apache-brooklyn-1.1.0-rc1-client-cli-linux.zip &
Re: Time to do a new release?
+1 On Tue, 16 Jan 2024 at 15:12, Alex Heneveld wrote: > +1 from me too - new features have stabilized, including workflow and > kubernetes updates so this makes sense > > On Mon, 15 Jan 2024 at 20:38, Geoff Macartney > wrote: > > > Hi Juan, > > > > +1 from me. A new release is long overdue. > > > > Cheers > > Geoff > > > > > > > > On Mon, 15 Jan 2024, 12:31 Juan Cabrerizo, > wrote: > > > > > Hello, Brooklyn developers and users, > > > > > > I completely missed a comment on a closed PR [1] last December asking > for > > > cutting a new Brooklyn release that includes it. > > > > > > The fact is, Brooklyn 1.0.0 was released almost four years ago, and > since > > > then, new features have been added and vulnerable dependencies > replaced. > > > > > > It is probably a good time to release 1.1.0. I wonder if anyone is > > working > > > on something that wants to be part of it. > > > > > > It would be great to have others' opinions here. > > > > > > [1] > > > > > > https://github.com/apache/brooklyn-client/pull/86#issuecomment-1869669313 > > > > > > -- Cheers, Iuliana Cosmina
Re: move jclouds to the attic?
Hello All, Jclouds is a core component of Apache Brooklyn, which is a project that is very dear to my heart. This being said, I would like to volunteer as well to keep jclouds secure and evolving. Iuliana On Wed, Nov 16, 2022, 07:54 Juan Cabrerizo wrote: > I concur with Enrico, > First warranty the Jclouds is patched when needed. it has to be secure. > Then keep alive the community of users/dependent projects responding to > issues and requests. > > Adding new cloud providers features seems to be for me the next step, but > it depends on the evolution on the necessities and other tooling. > > That's what I had in mind when I volunteered and I think is enough for > keeping live the project. > > Juan > > On Mon, 14 Nov 2022 at 11:14, Enrico Olivelli wrote: > > > Il giorno lun 14 nov 2022 alle ore 11:59 Andrew Gaul > > ha scritto: > > > > > > I would like to understand what the three potential PMC members plan to > > > do since jclouds already has many absentee committers and PMCs. For > > > example I seen only one commit in the last 5 years and no previous help > > > testing releases. Repeating my original mail: > > > > > > > Ideally the community could step up to sustain the project, e.g., > > > > reviewing pull requests, fixing issues, responding to mailing list > > > > queries, and eventually becoming committers themselves. Does anyone > > > > have a multi-year interest in jclouds that wants to help out? > > > > > > jclouds is also a critical dependency for my project S3Proxy which > > > accounts for 25% of jclouds Maven Central downloads. I would like to > > > see Apache jclouds continue instead of creating a private fork but > > > currently I do most of the maintenance with little community support. > > > How will this change under a new PMC set? > > > > (I am also volunteering, as posted in a previous message). > > In order to keep a project alive we must at least guarantee: > > - security fixes > > - responding to user requests > > > > There are other Apache projects that are widely used but they don't > > need many new features > > and they are pretty stable, > > > > In JClouds I would expect some work to follow the new features of the > > supported providers, > > but this is not strictly needed, it depends on users. > > > > Apart from "keeping it alive" we could try to boost it a little bit by > > engaging more with the well known > > projects that use it and ask them to advertise more about how they use > > JClouds > > > > my 2 cents > > Enrico > > > > > > > > > > On Mon, Nov 14, 2022 at 05:53:18AM +0100, Jean-Baptiste Onofré wrote: > > > > Hi guys, > > > > > > > > thanks for your update ! > > > > > > > > I propose to prepare a quick plan describing: > > > > 1. PMC set proposal > > > > 2. Roadmap/ideas for jclouds future (I would like to mention Karaf > > Minho here) > > > > 3. Send the proposal on the mailing list to move forward on vote and > > > > inform the board > > > > > > > > Thoughts ? > > > > > > > > Regards > > > > JB > > > > > > > > On Sun, Nov 13, 2022 at 11:12 AM Juan Cabrerizo > > wrote: > > > > > > > > > > Hi, I'm a PMC member of Brooklyn, happy to try to help JClouds and > > joining > > > > > the committee. It's a core dependency for us. > > > > > > > > > > Regards > > > > > Juan > > > > > > > > > > On Sat, 12 Nov 2022 at 16:22, Geoff Macartney > > wrote: > > > > > > > > > > > I would also be willing to join the Jclouds PMC if that would be > > helpful. > > > > > > > > > > > > Regards > > > > > > Geoff > > > > > > > > > > > > On Thu, 10 Nov 2022 at 11:15, Jean-Baptiste Onofré < > > j...@nanthrax.net> > > > > > > wrote: > > > > > > > > > > > > > > I’m in ;) > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > Le jeu. 10 nov. 2022 à 11:56, fpapon a > > écrit : > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > After some discussions with JB, we are ok to propose our help > > to join > > > > > > > > the PMC of JCloud and contribute to keep the project alive if > > anybody > > > > > > is > > > > > > > > ok. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Francois > > > > > > > > > > > > > > > > On 09/11/2022 21:57, Geoff Macartney wrote: > > > > > > > > > Hello Andrew, and Jclouds PMC, > > > > > > > > > > > > > > > > > > I'm sorry to be so late in replying to this, I confess I > had > > missed > > > > > > it > > > > > > > > > when it was sent last month and only became aware of it > > today. > > > > > > > > > > > > > > > > > > Speaking as a member of the Apache Brooklyn PMC I must > > confess I am > > > > > > > > > sad to hear this proposal. Jclouds is one of our most > > critical > > > > > > > > > dependencies, and I would worry about the implications for > > Brooklyn > > > > > > if > > > > > > > > > Jclouds moved to the Attic. I am worried in any case about > > the > > > > > > > > > implications of the lower activity in the community, but > > that is > > > > > > > > > another issue. > > > > > > >
Re: Java Cro 2022 conclusions
Hello Geoff, Unfortunately the conference was not recorded, and I was not prepared to do my own recording. The whole event seems to be big in Croatia, but I've found the overall organization and promotion of the event was pretty... lacking. Hopefully it will get better in the future. The Brooklyn Terraform module is the one started from Cloudsoft, it is open-source so anybody can contribute. I used it because it provided me a way to make the Brooklyn types as generic as possible. The code and configuration for the demo, the presentation as well are in this repository, in case anybody is interested: https://github.com/cloudsoft/java-cro Best Regards, Iuliana Cosmina On Thu, Oct 13, 2022, 15:18 Geoff Macartney wrote: > Hi Iuliana, > > Thanks for the update, this sounds marvellous. Was your presentation > recorded? I would love to watch it. > > Just for clarity, by "the brooklyn-terraform module" I assume you mean > Cloudsoft's repo of that name [1]. Of course, since this is open and > Apache 2.0 licensed, anyone can contribute to it! > > Best regards > Geoff > > > [1] https://github.com/cloudsoft/brooklyn-terraform > > On Wed, 12 Oct 2022 at 10:52, Iuliana Cosmina > wrote: > > > > Hi team, > > > > This week I participated in a Java conference ( > > https://2022autumn.javacro.hr/eng) and I demonstrated how Apache > Brooklyn > > can be used to develop applications for the cloud locally, that get > > deployed to little or no change to a cloud provider. I used the > > brooklyn-terraform module to deploy a three tier application to a > > local Kubernetes cluster and then migrate it to EKS. > > > > Here are a few things a few things that we must/should do that I figured > > out while preparing the demo and presenting at #javacro2022: > > > > 1. When we have a frontend (or anything really) depending on a cluster > that > > exposes some sensors the frontend needs, deleting the app causes the > > dependent component to hang, because the cluster is deleted first. Not > sure > > if this is caused by the fact that the cluster is a software component, > or > > maybe we have a race condition between deleting tasks. I can reproduce > it > > easily, so this is a bug that we can and we should fix. > > 2. We need to add custom terraform types: dbs, servers, for most used > > cloud providers etc. > > 3. All terraform entities under the same parent - when deployed on > > Kubernetes - should be deployed under the same namespace - it helps with > > cleaning. Also.. maybe in the case of an application that had only > > terraform entities deployed on the same Kubernetes cluster as children, a > > successful deletion of the namespace should suffice and Apache Brooklyn > > should back off instead of trying to delete the entities itself and > failing > > to do so. We could use the power of Kubernetes when possible. > > 4. At this conference there were a lot of young people just dipping > their > > toes in cloud development and they are interested in Apache Brooklyn for > > its ability to help them get used to working on the cloud without an > actual > > cloud. Maybe a collaboration with Universities for workshops should be > > considered. Also we could use some fresh eyes on Brooklyn to get some > > feedback, use them as a testing resource and a source of ideas for things > > missing in Apache Brooklyn. > > 5. When terraform deploys over an unstable network, the application > deploy > > fails in Brooklyn. Is there anything we can do about this? Maybe a retry? > > 6. One observation from a fellow speaker is that in order to get things > > done, we need to write a lot of YAML. I don't particularly disagree, nor > > have any idea how to fix it, unless we consider trying to enrich our > > catalog with out of the box types for most recent technologies. > > > > That is pretty much it, if anything else comes to mind, I'll make another > > list and continue this email thread. > > > > Observation: You might ask why I used Apache Brooklyn to drive a > Terraform > > deployment on a Kubernetes cluster? Because it provided me the > opportunity > > to try to create a CAMP blueprint agnostic towards where it got deployed. > > > > -- > > > > Best regards, > > Iuliana Cosmina > > > > <http://rpx.kicks-ass.net> >
Java Cro 2022 conclusions
Hi team, This week I participated in a Java conference ( https://2022autumn.javacro.hr/eng) and I demonstrated how Apache Brooklyn can be used to develop applications for the cloud locally, that get deployed to little or no change to a cloud provider. I used the brooklyn-terraform module to deploy a three tier application to a local Kubernetes cluster and then migrate it to EKS. Here are a few things a few things that we must/should do that I figured out while preparing the demo and presenting at #javacro2022: 1. When we have a frontend (or anything really) depending on a cluster that exposes some sensors the frontend needs, deleting the app causes the dependent component to hang, because the cluster is deleted first. Not sure if this is caused by the fact that the cluster is a software component, or maybe we have a race condition between deleting tasks. I can reproduce it easily, so this is a bug that we can and we should fix. 2. We need to add custom terraform types: dbs, servers, for most used cloud providers etc. 3. All terraform entities under the same parent - when deployed on Kubernetes - should be deployed under the same namespace - it helps with cleaning. Also.. maybe in the case of an application that had only terraform entities deployed on the same Kubernetes cluster as children, a successful deletion of the namespace should suffice and Apache Brooklyn should back off instead of trying to delete the entities itself and failing to do so. We could use the power of Kubernetes when possible. 4. At this conference there were a lot of young people just dipping their toes in cloud development and they are interested in Apache Brooklyn for its ability to help them get used to working on the cloud without an actual cloud. Maybe a collaboration with Universities for workshops should be considered. Also we could use some fresh eyes on Brooklyn to get some feedback, use them as a testing resource and a source of ideas for things missing in Apache Brooklyn. 5. When terraform deploys over an unstable network, the application deploy fails in Brooklyn. Is there anything we can do about this? Maybe a retry? 6. One observation from a fellow speaker is that in order to get things done, we need to write a lot of YAML. I don't particularly disagree, nor have any idea how to fix it, unless we consider trying to enrich our catalog with out of the box types for most recent technologies. That is pretty much it, if anything else comes to mind, I'll make another list and continue this email thread. Observation: You might ask why I used Apache Brooklyn to drive a Terraform deployment on a Kubernetes cluster? Because it provided me the opportunity to try to create a CAMP blueprint agnostic towards where it got deployed. -- Best regards, Iuliana Cosmina <http://rpx.kicks-ass.net>
Re: Apache Brooklyn Docs build
+, Awesome effort guys. Regards, Iuliana Cosmina On Fri, 21 May 2021 at 13:25, Jean-Baptiste Onofre wrote: > +1, no objection from me as well. > > I’m smoothly reconnecting dots on Brooklyn ;) > > Regards > JB > > > Le 21 mai 2021 à 14:23, Thomas Bouron a > écrit : > > > > +1 to revert back to Jekyll, and shame on Gitbook and me to have pushed > for > > that change. > > > > Also, thank you Alex! > > > > Best. > > > > On Fri, 21 May 2021 at 11:40, Duncan Grant > > wrote: > > > >> All, > >> > >> The apache brooklyn docs have become difficult to build as they are > based > >> on gitbook, which has moved away from supporting an OSS model. [1]. > Because > >> of this the giitbook cli is no longer being maintained and, on mac at > >> least, is becoming difficult to run. On the other hand Jekyll [2] is in > >> active development and is being well supported by the community. > >> > >> So Alex has created a PR [3] to revert back to using Jekyll and update > to > >> the latest ruby and Jekyll releases. I've tested this and it is working > >> well and building locally is almost instantaneous making it really nice > to > >> update the docs. > >> > >> It doesn mean we've lost the template/formatting that we had with > gitbook > >> and it looks like it did in the past but I think that having a working > and > >> easily updatable set of docs is more important. Obviously we would > welcome > >> any commits from anyone who wishes to improve the styling. > >> > >> I'll merge Alex's PR later today if no one has any major objections. > >> > >> thanks > >> > >> Duncan > >> > >> [1] https://github.com/GitbookIO/gitbook > >> [2] https://github.com/jekyll/jekyll > >> [3] https://github.com/apache/brooklyn-docs/pull/315 > >> > >> -- > >> Duncan Grant > >> Lead Software Engineer > >> > >> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud > >> > >> GitHub: https://github.com/duncangrant/ > >> > > > > > > -- > > Thomas Bouron > > Lead Software Engineer > > > > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud > > > > GitHub: https://github.com/tbouron > > Twitter: https://twitter.com/eltibouron > > -- Cheers, Iuliana Cosmina
Brooklyn DSL improvement proposal
Hi Brooklyners,
I am new here, but while writing CAMP blueprints using Brooklyn DSL I hit
a wall.
Here’s my situation: I have a brooklyn.parameter of a custom type named
Credential, that is defined like this:
- *id*: Credential
*format*: bean-with-type
*item*:
*type*: my.type.Credential
The Credential class has two properties: user and token.
I want to be able to use the value of the ‘user’ property when configuring
my service, like this:
*items*:
- *itemType*: template *item*:*brooklyn.parameters*:- *name*:
user_credentials *type*: Credential *default*:
*user*: *"unsername"
**token*: *"password"
**services*:- *id*: credential-service *type*:
my.credential.Service *brooklyn.initializers*: - *type*:
my.initializer.AAA*brooklyn.config*: *name*:
user.name *static.value*:
*$brooklyn:config("user_credentials")["user"]*
Currently I see no way to access the value of the "user" property of my
brooklyn parameter. Also, in case the Credential type also has a "roles"
property which is a list or an array, I would very much like to be
able to write
*$brooklyn:config("user_credentials")["roles"]["0"]*
Of if the “user.credentials” is of type list, it would be
nice if I could do
*$brooklyn:config("user_credentials")["0"]["user"]*
I personally like the [x] approach where x is tried (in order):
- an argument to a `get(x)` method (works for lists and maps: index or
key)
- a bean property (if x is a string, look for method called getX() or a
field called x
- a config key, if the target is Configurable , ie getConfig(x) or
config().get(x)
Or we could go for something pretty similar to a JsonPath style (
https://github.com/json-path/JsonPath)
This would allow us to write constructs like:
*$brooklyn:config("user_credentials").user*
*$brooklyn:config("user_credentials").roles[0]*
*$brooklyn:config("user_credentials")[0].user*
I think a change like this would make Brooklyn DSL more flexible and open
the door to further improvements and also make blueprints more readable.
I propose to work on the above and welcome any thoughts from the community.
Cheers,
Iuliana
--
Cheers,
Iuliana Cosmina
Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]
+1 from me Successfully started unpacked and started apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3. All nodes were correctly created. Observation: Since this is a RC release, the files/install_brooklyn.sh had to be modified and the BROOKLYN_URL variable had to be explicitly set to "https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm”. Because the script seems to be meant to work only with final releases. Also, successfully unpacked and started apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On this instance I tried all templates in the Quick Launch and they all deployed correctly on AWS instances. I used Firefox 73.0.2 to access Apache Brooklyn. Observation: for the composed templates ( 3 and 4 use template 2 ) the blueprints composer cannot visually display the blueprint because it does not recognise the `locations: []` construct and the workaround is to edit the YAML file and replace it with `location: your_location`, than the blueprint is recognised and the visual components are depicted correctly. Iuliana Cosmina SoftwareEngineer Cloudsoft | Bringing Business to the Cloud E: iuli...@cloudsoft.io M: 07745054173 T: _iulianacosmina L: https://www.linkedin.com/in/iulianacosmina/ On 21 Feb 2020, 10:42 +, Aled Sage , wrote: > +1 from me. > > I did some exploratory testing on OS X with the tar.gz, and deployed a > few blueprints. > > -- > > For the dockerfile not working out-of-the-box with base image > `maven:3.6.3-jdk-8`, that's something we should include in the release > notes (saying what the simple workaround is). However, I don't think > this has to be a blocker - we don't use this to release an image to > docker hub (or equivalent) as part of the brooklyn release. Also, that > dockerfile is a convenience for building (if I understand correctly) > rather than impacting end-users who are running Brooklyn; the build > outside of docker still works. > > Aled > > > On 18/02/2020 23:37, Richard Downer wrote: > > This is to call for a vote for the release of Apache Brooklyn 1.0.0. > > > > This release comprises of a source code distribution, and a corresponding > > binary distribution, 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-1.0.0-rc3 > > > > The artifact SHA-256 checksums are as follows: > > > > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a > > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm > > 7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61 > > *apache-brooklyn-1.0.0-rc3-bin.tar.gz > > 9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c > > *apache-brooklyn-1.0.0-rc3-bin.zip > > e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480 > > *apache-brooklyn-1.0.0-rc3-classic.tar.gz > > e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84 > > *apache-brooklyn-1.0.0-rc3-classic.zip > > 3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494 > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz > > eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip > > 13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82 > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz > > f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24 > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip > > 8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5 > > *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz > > ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277 > > *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip > > 9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49 > > *apache-brooklyn-1.0.0-rc3-src.tar.gz > > a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3 > > *apache-brooklyn-1.0.0-rc3-src.zip > > 164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc > > *apache-brooklyn-1.0.0-rc3-vagrant.tar.gz > > ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1 > > *apache-brooklyn-1.0.0-rc3-vagrant.zip > > 9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26 > > *apache-brooklyn-1.0.0-rc3.deb > > > > The Nexus staging repository for the Maven artifacts is located at: > > > > > > https://repository.apache.org/content/repositories/orgapachebrooklyn-1055 > > > > All release artifacts are signed with the following key: > > > > https://people.apache.org
Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc2]
+1 from me Tested apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOs running Catalina 10.15.3. Successfully deployed all blueprints in the quick launch on AWS eu-west-1. Successfully started unpacked and started apache-brooklyn-1.0.0-rc3-vagrant.zip. All nodes were correctly created. Iuliana Cosmina SoftwareEngineer Cloudsoft | Bringing Business to the Cloud E: iuli...@cloudsoft.io T: _iulianacosmina L: https://www.linkedin.com/in/iulianacosmina/ On 20 Feb 2020, 12:47 +, John Campbell , wrote: > +1 from me > > Tested apache-brooklyn-1.0.0-rc3-bin.zip on macOS running Mohave 10.14.6 > > Successfully deployed sample 1 server template successfully on AWS us-east-1 > Successfully deployed sample 4 resilient bash web cluster template on AWS > us-east-1 > > > John Campbell > Software Engineer > > Cloudsoft | Bringing Business to the Cloud > > E: john.campb...@cloudsoft.io > M: 07779 576614 > T: - > L: www.linkedin.com/in/john-campbell-42105267 > > Need a hand with AWS? Get a Free Consultation. >
[Upgrade Poposal]: Karaf 4.2.8, released on the 14th of January 2020
Hello, Since we have to do a few fixes to do, can we also do a Karaf upgrade? Version 4.2.8 released on the 14th of January 2020 and according to the release notes quite a few significant bugs were fixed. ttps://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345539 Cheers, Iuliana Cosmina Engineer Cloudsoft| Bringing Business to the Cloud Twitter:_iulianacosmina GitHub:https://github.com/iuliana
[VOTE] Release Apache Brooklyn 1.0.0 [rc2]
-1 Here is a summary of my tests. ——— [X] Tested the apache-brooklyn-1.0.0-rc2-vagrant.zip & apache-brooklyn-1.0.0-rc2-vagrant.tar.gz The condition to check that Brooklyn is up is wrong. This means that when calling vagrant up, the Brooklyn node is created, but the command never ends, and the other nodes are not created. In files/install_brooklyn.sh, Brooklyn being successfully up is checked by the presence of the "BundleEvent STARTED - org.apache.brooklyn.karaf-init” statement in the Brooklyn.debug.log file. But that statement is not part of the log. [✓] apache-brooklyn-1.0.0-rc2-bin.tar.gz - installed correctly on macOs 10.15.3 - web interface is ok in Firefox 72.0.2 & Safari - 1-server-template and 2-bash-web-server-template(corrected) were deployed to AWS machines - start/stop/restart work correctly [✓] apache-brooklyn-1.0.0-rc2-bin.zip - installed correctly on macOs 10.15.3 - web interface is ok in Firefox 72.0.2 & Safari - 1-server-template and 2-bash-web-server-template(corrected) were deployed to AWS machines - start/stop/restart work correctly [✓] apache-brooklyn-1.0.0-rc2-1.noarch.rpm - installed correctly on CentOS 7.3 - web interface is ok in Firefox 72.0.2 & Safari - 1-server-template and 2-bash-web-server-template(corrected) were deployed to AWS machines - start/stop/restart work correctly [X] QuickLaunch template errors: - The 2-bash-server-template contains an error in line 13. The apt-get install command is called without the -Y argument. This means that the VM is not configured correctly since it is stuck waiting a confirmation. - Template 3-bash-web-and-riak-template cannot be deployed on an Ubuntu 18 AWS machine. The error message is E: Unable to locate package riak. - Template 4-resilient-bash-web-cluster-template cannot be deployed on an Ubuntu 18 AWS machine, because of compile error while building nginx-1.8.0. Although the issues are not critical, a new user of Brooklyn might see them as such. Especially since working templates would convince a new user that Brooklyn works as expected. Iuliana Cosmina Engineer Cloudsoft | Bringing Business to the Cloud Twitter: _iulianacosmina GitHub: https://github.com/iuliana
