[jira] [Comment Edited] (BROOKLYN-625) Blueprint Composer cannot select a location
[ https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035414#comment-17035414 ] Thomas Bouron edited comment on BROOKLYN-625 at 2/12/20 2:57 PM: - Hi [~richard]. I tested on MacOs 10.15.2 with: * Chrome 80.0.3987.87 * Firefox 73.0 * Opera 66.0.3515.72 * Safari 13.0.4 (15608.4.9.1.3) and I can see the locations just fine. Note if you add a location *after loading* the blueprint composer, you will need to refresh to page to see the location show up. was (Author: tbouron): Hi [~richard]. I tested on: * Chrome 80.0.3987.87 * Firefox 73.0 * Opera 66.0.3515.72 * Safari 13.0.4 (15608.4.9.1.3) and I can see the locations just fine. Note if you add a location *after loading* the blueprint composer, you will need to refresh to page to see the location show up. > Blueprint Composer cannot select a location > --- > > Key: BROOKLYN-625 > URL: https://issues.apache.org/jira/browse/BROOKLYN-625 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: Windows 10 Professional 64-bit > Firefox 72.0.2 (64-bit) > Apache Brooklyn 1.0.0-rc2 >Reporter: Richard Downer >Priority: Major > Fix For: 1.0.0 > > > > > # Ensure at least one location is configured in the Location Manager. > # Open the Blueprint Composer. > # Click on the "New Application" entity on the canvas. > # In the sidebar, expand the Location section and click "Attach a location". > > Expected behaviour: a list of locations to choose from. > Actual behaviour: an empty list and message "Nothing available" > Workaround: the location name can be typed in manually, then the "ad hoc" > tile clicked and attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (BROOKLYN-625) Blueprint Composer cannot select a location
[ https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035414#comment-17035414 ] Thomas Bouron commented on BROOKLYN-625: Hi [~richard]. I tested on: * Chrome 80.0.3987.87 * Firefox 73.0 * Opera 66.0.3515.72 * Safari 13.0.4 (15608.4.9.1.3) and I can see the locations just fine. Note if you add a location *after loading* the blueprint composer, you will need to refresh to page to see the location show up. > Blueprint Composer cannot select a location > --- > > Key: BROOKLYN-625 > URL: https://issues.apache.org/jira/browse/BROOKLYN-625 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: Windows 10 Professional 64-bit > Firefox 72.0.2 (64-bit) > Apache Brooklyn 1.0.0-rc2 >Reporter: Richard Downer >Priority: Major > Fix For: 1.0.0 > > > > > # Ensure at least one location is configured in the Location Manager. > # Open the Blueprint Composer. > # Click on the "New Application" entity on the canvas. > # In the sidebar, expand the Location section and click "Attach a location". > > Expected behaviour: a list of locations to choose from. > Actual behaviour: an empty list and message "Nothing available" > Workaround: the location name can be typed in manually, then the "ad hoc" > tile clicked and attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (BROOKLYN-597) Remove MD5 and SHA-1 checksums
[
https://issues.apache.org/jira/browse/BROOKLYN-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-597.
Resolution: Fixed
> Remove MD5 and SHA-1 checksums
> ---
>
> Key: BROOKLYN-597
> URL: https://issues.apache.org/jira/browse/BROOKLYN-597
> Project: Brooklyn
> Issue Type: Improvement
>Affects Versions: 0.12.0
>Reporter: Geoff Macartney
>Assignee: Geoff Macartney
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Per the recently updated Apache Release Distribution Policy,
> [https://www.apache.org/dev/release-distribution], we should remove the
> generation and checking of MD5 and SHA-1 checksums from brooklyn-dist/release
> before we do another release, presumably 1.0.
> The relevant wording is
> {quote}For every artifact distributed to the public through Apache channels,
> the PMC
> * MUST supply a
> [valid|https://www.apache.org/dev/release-signing#verifying-signature]
> [OpenPGP-compatible ASCII-armored detached
> signature|https://www.apache.org/dev/release-signing#openpgp-ascii-detach-sig]
> file
> * MUST supply at least one checksum file
> * SHOULD supply a [SHA-256 and/or
> SHA-512|https://www.apache.org/dev/release-signing#sha-checksum] checksum file
> * SHOULD NOT supply a MD5 or SHA-1 checksum file (because these are
> deprecated)
> For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (BROOKLYN-620) Order blueprint deployment history by date deployed
[ https://issues.apache.org/jira/browse/BROOKLYN-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron resolved BROOKLYN-620. Resolution: Fixed > Order blueprint deployment history by date deployed > --- > > Key: BROOKLYN-620 > URL: https://issues.apache.org/jira/browse/BROOKLYN-620 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0-M1 >Reporter: Ludovic Farine >Priority: Minor > Fix For: 1.0.0 > > > Right now it's all random (or at least random when having the same name). > We should ideally see the latest deployment at the top. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (BROOKLYN-620) Order blueprint deployment history by date deployed
[ https://issues.apache.org/jira/browse/BROOKLYN-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998125#comment-16998125 ] Thomas Bouron commented on BROOKLYN-620: PR to fix this: [https://github.com/apache/brooklyn-ui/pull/150] > Order blueprint deployment history by date deployed > --- > > Key: BROOKLYN-620 > URL: https://issues.apache.org/jira/browse/BROOKLYN-620 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0-M1 >Reporter: Ludovic Farine >Priority: Minor > Fix For: 1.0.0 > > > Right now it's all random (or at least random when having the same name). > We should ideally see the latest deployment at the top. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (BROOKLYN-624) File upload to catalog via file picker does not work
[ https://issues.apache.org/jira/browse/BROOKLYN-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron resolved BROOKLYN-624. Resolution: Fixed > File upload to catalog via file picker does not work > > > Key: BROOKLYN-624 > URL: https://issues.apache.org/jira/browse/BROOKLYN-624 > Project: Brooklyn > Issue Type: Bug >Reporter: John Campbell >Priority: Minor > > Uploading a file to the catalog can be done either by dragging and dropping > or by clicking the file upload button. The file upload button allows file(s) > to be selected but does nothing when actioned. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (BROOKLYN-624) File upload to catalog via file picker does not work
[ https://issues.apache.org/jira/browse/BROOKLYN-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995726#comment-16995726 ] Thomas Bouron commented on BROOKLYN-624: Fixed in https://github.com/apache/brooklyn-ui/pull/154 > File upload to catalog via file picker does not work > > > Key: BROOKLYN-624 > URL: https://issues.apache.org/jira/browse/BROOKLYN-624 > Project: Brooklyn > Issue Type: Bug >Reporter: John Campbell >Priority: Minor > > Uploading a file to the catalog can be done either by dragging and dropping > or by clicking the file upload button. The file upload button allows file(s) > to be selected but does nothing when actioned. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (BROOKLYN-619) Blueprint Composer: Missing pagination when switching to compact list and back to another mode
[ https://issues.apache.org/jira/browse/BROOKLYN-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron resolved BROOKLYN-619. Resolution: Fixed Fixed with [https://github.com/apache/brooklyn-ui/pull/148] > Blueprint Composer: Missing pagination when switching to compact list and > back to another mode > -- > > Key: BROOKLYN-619 > URL: https://issues.apache.org/jira/browse/BROOKLYN-619 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 1.0.0-M1 >Reporter: Ludovic Farine >Priority: Minor > Fix For: 1.0.0 > > > In the blueprint composer, the entity palette is paged in all the grid and > list modes apart from "compact list"; after "compact list" as been active, > every other mode will then display all the entities without paging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (BROOKLYN-589) MariaDB install fails on AWS: ftp.hosteurope.de very slow
[
https://issues.apache.org/jira/browse/BROOKLYN-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-589.
Resolution: Fixed
> MariaDB install fails on AWS: ftp.hosteurope.de very slow
> -
>
> Key: BROOKLYN-589
> URL: https://issues.apache.org/jira/browse/BROOKLYN-589
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Aled Sage
>Priority: Major
>
> I tried to deploy MariaDB to the centos.org marketplace AMI in AWS
> (eu-central-1/ami-1e038d71).
> This uses the entity
> {{org.apache.brooklyn.entity.database.mariadb.MariaDbNode}}, via the test in
> https://github.com/brooklyncentral/brooklyn-mariadb-node/.
> However, the install ssh command didn't complete. It kept trying to {{curl}}
> the mariadb tar.gz from http://ftp.hosteurope.de, but was getting less than 1
> bytes/sec back.
> Logging into the VM and trying this manually, I saw:
> {noformat}
> curl -v -f -L -k --retry 10 --keepalive-time 30 --speed-time 30
> "http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz;
> -o mariadb-10.2.6-linux-x86_64.tar.gz
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* About to connect() to ftp.hosteurope.de port 80 (#0)
> * Trying 80.237.136.138...
> * Connected to ftp.hosteurope.de (80.237.136.138) port 80 (#0)
> > GET
> > /mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz
> > HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ftp.hosteurope.de
> > Accept: */*
> >
> 0 00 00 0 0 0 --:--:-- 0:00:30 --:--:--
> 0* Operation too slow. Less than 1 bytes/sec transferred the last 30 seconds
> 0 00 00 0 0 0 --:--:-- 0:00:30 --:--:-- 0
> * Closing connection 0
> Warning: Transient problem: timeout Will retry in 1 seconds. 10 retries left.
> * About to connect() to ftp.hosteurope.de port 80 (#1)
> * Trying 80.237.136.138...
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* Connected to ftp.hosteurope.de (80.237.136.138) port 80 (#1)
> > GET
> > /mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz
> > HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ftp.hosteurope.de
> > Accept: */*
> >
> 0 00 00 0 0 0 --:--:-- 0:00:29 --:--:-- 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (BROOKLYN-590) squid blueprint fails on CentOS 7 on Vexxhost: openssl broken?
[
https://issues.apache.org/jira/browse/BROOKLYN-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-590.
Resolution: Fixed
Assignee: Thomas Bouron
> squid blueprint fails on CentOS 7 on Vexxhost: openssl broken?
> --
>
> Key: BROOKLYN-590
> URL: https://issues.apache.org/jira/browse/BROOKLYN-590
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Aled Sage
>Assignee: Thomas Bouron
>Priority: Major
>
> I tried to deploy the blueprint test at
> https://github.com/brooklyncentral/brooklyn-squid to Vexxhost, on CentOS
> 7.2.1511.
> However, the squid service failed to start. The stderr of the ssh command in
> Brooklyn showed:
> {noformat}
> sudo service squid start
> Redirecting to /bin/systemctl start squid.service
> Job for squid.service failed because the control process exited with error
> code. See "systemctl status squid.service" and "journalctl -xe" for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BROOKLYN-589) MariaDB install fails on AWS: ftp.hosteurope.de very slow
[
https://issues.apache.org/jira/browse/BROOKLYN-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520132#comment-16520132
]
Thomas Bouron commented on BROOKLYN-589:
[~duncangrant] created a PR for this in the maria-db repo:
https://github.com/brooklyncentral/brooklyn-mariadb-node/pull/3
> MariaDB install fails on AWS: ftp.hosteurope.de very slow
> -
>
> Key: BROOKLYN-589
> URL: https://issues.apache.org/jira/browse/BROOKLYN-589
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Aled Sage
>Priority: Major
>
> I tried to deploy MariaDB to the centos.org marketplace AMI in AWS
> (eu-central-1/ami-1e038d71).
> This uses the entity
> {{org.apache.brooklyn.entity.database.mariadb.MariaDbNode}}, via the test in
> https://github.com/brooklyncentral/brooklyn-mariadb-node/.
> However, the install ssh command didn't complete. It kept trying to {{curl}}
> the mariadb tar.gz from http://ftp.hosteurope.de, but was getting less than 1
> bytes/sec back.
> Logging into the VM and trying this manually, I saw:
> {noformat}
> curl -v -f -L -k --retry 10 --keepalive-time 30 --speed-time 30
> "http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz;
> -o mariadb-10.2.6-linux-x86_64.tar.gz
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* About to connect() to ftp.hosteurope.de port 80 (#0)
> * Trying 80.237.136.138...
> * Connected to ftp.hosteurope.de (80.237.136.138) port 80 (#0)
> > GET
> > /mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz
> > HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ftp.hosteurope.de
> > Accept: */*
> >
> 0 00 00 0 0 0 --:--:-- 0:00:30 --:--:--
> 0* Operation too slow. Less than 1 bytes/sec transferred the last 30 seconds
> 0 00 00 0 0 0 --:--:-- 0:00:30 --:--:-- 0
> * Closing connection 0
> Warning: Transient problem: timeout Will retry in 1 seconds. 10 retries left.
> * About to connect() to ftp.hosteurope.de port 80 (#1)
> * Trying 80.237.136.138...
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* Connected to ftp.hosteurope.de (80.237.136.138) port 80 (#1)
> > GET
> > /mirror/archive.mariadb.org/mariadb-10.2.6/bintar-linux-x86_64/mariadb-10.2.6-linux-x86_64.tar.gz
> > HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ftp.hosteurope.de
> > Accept: */*
> >
> 0 00 00 0 0 0 --:--:-- 0:00:29 --:--:-- 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BROOKLYN-590) squid blueprint fails on CentOS 7 on Vexxhost: openssl broken?
[
https://issues.apache.org/jira/browse/BROOKLYN-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520129#comment-16520129
]
Thomas Bouron commented on BROOKLYN-590:
[~aled.sage] I created a PR for this in the Squid repo:
https://github.com/brooklyncentral/brooklyn-squid/pull/2
> squid blueprint fails on CentOS 7 on Vexxhost: openssl broken?
> --
>
> Key: BROOKLYN-590
> URL: https://issues.apache.org/jira/browse/BROOKLYN-590
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Aled Sage
>Priority: Major
>
> I tried to deploy the blueprint test at
> https://github.com/brooklyncentral/brooklyn-squid to Vexxhost, on CentOS
> 7.2.1511.
> However, the squid service failed to start. The stderr of the ssh command in
> Brooklyn showed:
> {noformat}
> sudo service squid start
> Redirecting to /bin/systemctl start squid.service
> Job for squid.service failed because the control process exited with error
> code. See "systemctl status squid.service" and "journalctl -xe" for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (BROOKLYN-586) resolve issue of jsonpath dependency on missing library
[
https://issues.apache.org/jira/browse/BROOKLYN-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-586.
Resolution: Fixed
Assignee: Geoff Macartney
PR merged
> resolve issue of jsonpath dependency on missing library
> ---
>
> Key: BROOKLYN-586
> URL: https://issues.apache.org/jira/browse/BROOKLYN-586
> Project: Brooklyn
> Issue Type: Improvement
>Reporter: Geoff Macartney
>Assignee: Geoff Macartney
>Priority: Minor
>
> See
> [https://lists.apache.org/thread.html/10a74756dbeb1243928eb87c379b01ba58357a6204149d98676fa025@%3Cdev.brooklyn.apache.org%3E]
> {quote}The Apache Brooklyn master build [1] has failed the last couple of
> times for the Go build of brooklyn-client (see end of email for the error
> text). It looks to me like our dependency github.com/NodePrime/jsonpath has
> been deleted! It definitely used to be there (lots of google hits pointing at
> that [2]), but 404 when visiting the page.
> {quote}
>
> Per [https://github.com/apache/brooklyn-client/pull/68] we can use a
> temporary fork of the repo, but we should come up with a long term fix. If
> NodePrime restore the library we can use that, or we can move to another
> library.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (BROOKLYN-588) SoftwareProcess download with curl can fail on CentOS 7.0 (TLS negotiation)
[
https://issues.apache.org/jira/browse/BROOKLYN-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-588.
Resolution: Workaround
Assignee: Aled Sage
Addressed in Brooklyn documentation
> SoftwareProcess download with curl can fail on CentOS 7.0 (TLS negotiation)
> ---
>
> Key: BROOKLYN-588
> URL: https://issues.apache.org/jira/browse/BROOKLYN-588
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Aled Sage
>Assignee: Aled Sage
>Priority: Major
>
> When a {{SoftwareProcess}} entity needs to download an install artifact, it
> often uses curl.
> When running CentOS 7.0, this can fail. For example, when attempting to
> download something from github:
> {noformat}
> /usr/bin/curl
> curl: (37) Couldn't open file
> /home/users/amp/.brooklyn/repository/EtcdNode/2.3.1/etcd-v2.3.1-linux-amd64.tar.gz
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> curl: (35) Peer reports incompatible or unsupported protocol version.
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
> curl: (22) The requested URL returned error: 404 Not Found
> Could not retrieve etcd-v2.3.1-linux-amd64.tar.gz. Tried:
> file://$HOME/.brooklyn/repository/EtcdNode/2.3.1/etcd-v2.3.1-linux-amd64.tar.gz,
>
> https://github.com/coreos/etcd/releases/download/v2.3.1/etcd-v2.3.1-linux-amd64.tar.gz,
>
> http://downloads.cloudsoftcorp.com/brooklyn/repository/EtcdNode/2.3.1/etcd-v2.3.1-linux-amd64.tar.gz
> Executed
> /tmp/brooklyn-20180521-195405819-Dfo2-installing_EtcdNodeImpl_id_oe3.sh,
> result 9
> {noformat}
> This can happen when using a 'minimal' location in AWS (e.g. when just
> specifying the {{osFamily: centos}}, and not an explicit AMI, which defaults
> to a CentOS 7.0 AMI).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (BROOKLYN-579) DNS lookups cached for too long
[
https://issues.apache.org/jira/browse/BROOKLYN-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron resolved BROOKLYN-579.
Resolution: Fixed
Assignee: Thomas Bouron
Fixed by https://github.com/apache/brooklyn-dist/pull/121
> DNS lookups cached for too long
> ---
>
> Key: BROOKLYN-579
> URL: https://issues.apache.org/jira/browse/BROOKLYN-579
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>Assignee: Thomas Bouron
>Priority: Major
>
> I've had issues where DNS values are changed but Brooklyn doesn't see those.
> I think Java caches hostnames forever by default, ignoring DNS TTL.
> (Controlling Route 53 from Brooklyn is one obvious such example!)
> We should consider overriding this.
> Oracle Cloud describe how
> (https://docs.us-phoenix-1.oraclecloud.com/Content/API/SDKDocs/javasdk.htm):
>
> {quote}The JVM uses the
> [networkaddress.cache.ttl|http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html]
> property to specify the caching policy for DNS name lookups. The value is an
> integer that represents the number of seconds to cache the successful lookup.
> The default value for many JVMs, {{-1}}, indicates that the lookup should be
> cached forever.
> Because resources in Oracle Cloud Infrastructure use DNS names that can
> change, we recommend that you change the the TTL value to 60 seconds. This
> ensures that the new IP address for the resource is returned on next DNS
> query. You can change this value globally or specifically for your
> application:
> {quote} *
> {quote}To set TTL globally for all applications using the JVM, add the
> following in the {{$JAVA_HOME/jre/lib/security/java.security}} file:
> {{networkaddress.cache.ttl=60}}{quote}
> *
> {quote}To set TTL only for your application, set the following in your
> application's initialization code:
> {{java.security.Security.setProperty("networkaddress.cache.ttl" ,
> "60");}}{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BROOKLYN-577) GSoC: Modernise Brooklyn's authentication system
[ https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394100#comment-16394100 ] Thomas Bouron commented on BROOKLYN-577: Hi [~ktsdesilva], welcome and thank you for considering this project for your GSoC. I would first encourage you present yourself and discuss your application and plan with the project community. You can sign up for the Apache Brooklyn mailing list [by following these instructions|https://brooklyn.apache.org/community/mailing-lists.html]. I would also invite you to [read this page|https://community.apache.org/gsoc.html] which outlines the process to apply. If you have anymore question, don't hesitate to ask them here or better, on the mailing list directly. > GSoC: Modernise Brooklyn's authentication system > > > Key: BROOKLYN-577 > URL: https://issues.apache.org/jira/browse/BROOKLYN-577 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Richard Downer >Priority: Major > Labels: cloud, gsoc2018, java, javascript, rest > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). Potential students, please > read https://brooklyn.apache.org/community/gsoc.html > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > Apache Brooklyn currently uses a simple authentication/authorisation system. > Runtime authentication relies on HTTP Basic Authentication. While this has > been satisfactory for some time, it has many shortcomings. HTTP Basic > Authentication caches credentials on the client side, which is a weakness. > It's not possible for a server policy to enforce session expiry timeouts. > Even trivial things such as providing a "logout" button are difficult to > reliably implement. This makes enterprise adoption of Brooklyn problematic as > it cannot comply with the security policy requirements that enterprises > typically have. > Apache Brooklyn's authorisation systems on the server side are basic. > Usernames and passwords can be put into the server configuration by an > administrator. This means that users do not have the ability to change their > own password, and enterprise security policies such as password rotation > cannot be supported. (As an alternative, Brooklyn can integrate with external > directory services, but it is often overkill to deploy a heavy directory > server alongside a Brooklyn server.) > This project would be to overhaul Apache Brooklyn's login system to a modern > system. Considerations include: > * A built-in user directory that is easy to get started with yet which > guides the administrator towards a secure system > * Credentials stored in a secure manner > * A login screen in the UI, and the appropriate API methods to log in and > issue tokens > * Revise the server side API code to validate tokens > * UI and API support for logging out, changing password, other appropriate > operations > * UI and API support for an administrator to manage users > * Security policy features such as: > ** Logged in sessions expire after a fixed time > ** User must change their password on first login > ** User passwords expire after a fixed time and must be changed > ** Lock out accounts after a number of failed logins > ** Audit log > * Retain ability to integrate with an external directory service > This project will involve the use of Java for the server-side development > (this is where most of the work will take place), and HTML+CSS+Javascript for > the client-side development (this is less important as we expect others will > be on-hand to help with the visual development). It will require study and > implementation of "best practices" for security. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369871#comment-16369871 ] Thomas Bouron commented on BROOKLYN-575: Hi [~menuka94] and welcome! I'm glad you consider this project for GSoC. *Before you start working on anything*, you need first to present you on the mailing list and submit a proposal over there. I would point you [to my previous comment|https://issues.apache.org/jira/browse/BROOKLYN-575?focusedCommentId=16362095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16362095] I made above which contains more information. > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, gsoc2018, javascript, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Background > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI and take advantage of the novelties introduced > recently on the REST API. The goal is to improve the overall user experience, > especially when: > # deploying an application > # viewing and managing deployed applications > # viewing and managing the catalog > At least, feature parity with the current UI should be achieved. The only > requirement is to use the Brooklyn colour palette. > This project for green-field development of a new web based UI will involve: > * selecting a modern Javascript web and CSS framework > * working with REST APIs > * a nice UI/UX > * writing unit tests > _Note: The server side API is written in Java but an understanding of Java > *is NOT required*._ > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362095#comment-16362095 ] Thomas Bouron commented on BROOKLYN-575: Hi [~mertkahyaoglu], welcome and thank you for considering this project for your GSoC. I would first encourage you present yourself and discuss your application and plan with the project community. You can sign up for the Apache Brooklyn mailing list [by following these instructions|https://brooklyn.apache.org/community/mailing-lists.html]. I would also invite you to [read this page|https://community.apache.org/gsoc.html] which outlines the process to apply. If you have anymore question, don't hesitate to ask them here or better, on the mailing list directly. > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, gsoc2018, javascript, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Background > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI and take advantage of the novelties introduced > recently on the REST API. The goal is to improve the overall user experience, > especially when: > # deploying an application > # viewing and managing deployed applications > # viewing and managing the catalog > At least, feature parity with the current UI should be achieved. The only > requirement is to use the Brooklyn colour palette. > This project for green-field development of a new web based UI will involve: > * selecting a modern Javascript web and CSS framework > * working with REST APIs > * a nice UI/UX > * writing unit tests > _Note: The server side API is written in Java but an understanding of Java > *is NOT required*._ > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-575: --- Labels: cloud gsoc2018 javascript rest ui (was: cloud gsoc2018 javascript js rest ui) > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, gsoc2018, javascript, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Background > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI and take advantage of the novelties introduced > recently on the REST API. The goal is to improve the overall user experience, > especially when: > # deploying an application > # viewing and managing deployed applications > # viewing and managing the catalog > At least, feature parity with the current UI should be achieved. The only > requirement is to use the Brooklyn colour palette. > This project for green-field development of a new web based UI will involve: > * selecting a modern Javascript web and CSS framework > * working with REST APIs > * a nice UI/UX > * writing unit tests > _Note: The server side API is written in Java but an understanding of Java > *is NOT required*._ > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BROOKLYN-577) GSoC: Modernise Brooklyn's authentication system
[ https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-577: --- Labels: cloud gsoc2018 java javascript rest (was: cloud java javascript rest) > GSoC: Modernise Brooklyn's authentication system > > > Key: BROOKLYN-577 > URL: https://issues.apache.org/jira/browse/BROOKLYN-577 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Richard Downer >Priority: Major > Labels: cloud, gsoc2018, java, javascript, rest > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > Apache Brooklyn currently uses a simple authentication/authorisation system. > Runtime authentication relies on HTTP Basic Authentication. While this has > been satisfactory for some time, it has many shortcomings. HTTP Basic > Authentication caches credentials on the client side, which is a weakness. > It's not possible for a server policy to enforce session expiry timeouts. > Even trivial things such as providing a "logout" button are difficult to > reliably implement. This makes enterprise adoption of Brooklyn problematic as > it cannot comply with the security policy requirements that enterprises > typically have. > Apache Brooklyn's authorisation systems on the server side are basic. > Usernames and passwords can be put into the server configuration by an > administrator. This means that users do not have the ability to change their > own password, and enterprise security policies such as password rotation > cannot be supported. (As an alternative, Brooklyn can integrate with external > directory services, but it is often overkill to deploy a heavy directory > server alongside a Brooklyn server.) > This project would be to overhaul Apache Brooklyn's login system to a modern > system. Considerations include: > * A built-in user directory that is easy to get started with yet which > guides the administrator towards a secure system > * Credentials stored in a secure manner > * A login screen in the UI, and the appropriate API methods to log in and > issue tokens > * Revise the server side API code to validate tokens > * UI and API support for logging out, changing password, other appropriate > operations > * UI and API support for an administrator to manage users > * Security policy features such as: > ** Logged in sessions expire after a fixed time > ** User must change their password on first login > ** User passwords expire after a fixed time and must be changed > ** Lock out accounts after a number of failed logins > ** Audit log > * Retain ability to integrate with an external directory service > This project will involve the use of Java for the server-side development > (this is where most of the work will take place), and HTML+CSS+Javascript for > the client-side development (this is less important as we expect others will > be on-hand to help with the visual development). It will require study and > implementation of "best practices" for security. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-575: --- Labels: cloud gsoc2018 javascript js rest ui (was: cloud javascript js rest ui) > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, gsoc2018, javascript, js, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Background > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI and take advantage of the novelties introduced > recently on the REST API. The goal is to improve the overall user experience, > especially when: > # deploying an application > # viewing and managing deployed applications > # viewing and managing the catalog > At least, feature parity with the current UI should be achieved. The only > requirement is to use the Brooklyn colour palette. > This project for green-field development of a new web based UI will involve: > * selecting a modern Javascript web and CSS framework > * working with REST APIs > * a nice UI/UX > * writing unit tests > _Note: The server side API is written in Java but an understanding of Java > *is NOT required*._ > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-575: --- Description: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Background Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. In more detail, it's a tool for describing applications and their components, deploying these applications to the cloud, and managing the ongoing health and responsiveness. Brooklyn does this using blueprints - human readable documents which describe in detail an application component, or a whole application. Blueprints are stored in a catalog, essentially a built-in database of components and applications. An application blueprint can call on component blueprints from the catalog, therefore allowing complex applications to be built from simple pieces. h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI and take advantage of the novelties introduced recently on the REST API. The goal is to improve the overall user experience, especially when: # deploying an application # viewing and managing deployed applications # viewing and managing the catalog At least, feature parity with the current UI should be achieved. The only requirement is to use the Brooklyn colour palette. This project for green-field development of a new web based UI will involve: * selecting a modern Javascript web and CSS framework * working with REST APIs * a nice UI/UX * writing unit tests _Note: The server side API is written in Java but an understanding of Java *is NOT required*._ Prospective GSOC mentor: tbou...@apache.org was: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI to match closely the novelties introduced recently on the REST API. The goal is to achieve feature parity between the old and this new UI: * Dashboard view * In-depth view * Composer view * Catalog view * REST API view This would obviously be done in JS but the frameworks (both JS and CSS) are free to choose. This would be a good opportunity to go wild and try different ideas (either technical or design) as well as unit tests if time allows it. The only requirement is to use the Brooklyn colour palette. Prospective GSOC mentor: tbou...@apache.org > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, javascript, js, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Background > Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon > EC2. In more detail, it's a tool for describing applications and their > components, deploying these applications to the cloud, and managing the > ongoing health and responsiveness. Brooklyn does this using blueprints - > human readable documents which describe in detail an application component, > or a whole application. Blueprints are stored in a catalog, essentially a > built-in database of components and applications. An application blueprint > can call on component blueprints from the catalog, therefore allowing complex > applications to be built from simple pieces. > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI and take advantage of the novelties introduced > recently on the REST API. The goal is to improve the overall user experience, > especially when: > # deploying an application > # viewing and managing deployed applications > # viewing and managing the catalog > At least, feature parity with the current UI should be achieved. The only > requirement is to use the Brooklyn colour palette. > This project for green-field development of a new web based UI will involve: > * selecting a modern Javascript web and CSS framework > * working with REST APIs > * a nice UI/UX > * writing unit tests > _Note: The server side
[jira] [Updated] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-575: --- Description: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI to match closely the novelties introduced recently on the REST API. The goal is to achieve feature parity between the old and this new UI: * Dashboard view * In-depth view * Composer view * Catalog view * REST API view This would obviously be done in JS but the frameworks (both JS and CSS) are free to choose. This would be a good opprotunity to go wild and try different ideas (either technical or design) as well as unit tests if time allows it. The only requirement is to use the Brooklyn colour palette. Prospective GSOC mentor: tbou...@apache.org was: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI to match closely the novelties introduced recently on the REST API. The goal is to achieve feature parity between the old and new UI: * Dashboard view * In-depth view * Composer view * Catalog view * REST API view This would obviously be done in JS but the frameworks (both JS and CSS) are free to choose. This would be a good occasion to go wild and try different ideas (either technical or design) if time allows it. The only requirement is to use the Brooklyn color palette. Prospective GSOC mentor: tbou...@apache.org > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, javascript, js, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI to match closely the novelties introduced recently on > the REST API. The goal is to achieve feature parity between the old and this > new UI: > * Dashboard view > * In-depth view > * Composer view > * Catalog view > * REST API view > This would obviously be done in JS but the frameworks (both JS and CSS) are > free to choose. This would be a good opprotunity to go wild and try different > ideas (either technical or design) as well as unit tests if time allows it. > The only requirement is to use the Brooklyn colour palette. > > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BROOKLYN-575) GSOC: New Brooklyn UI
[ https://issues.apache.org/jira/browse/BROOKLYN-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-575: --- Description: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI to match closely the novelties introduced recently on the REST API. The goal is to achieve feature parity between the old and this new UI: * Dashboard view * In-depth view * Composer view * Catalog view * REST API view This would obviously be done in JS but the frameworks (both JS and CSS) are free to choose. This would be a good opportunity to go wild and try different ideas (either technical or design) as well as unit tests if time allows it. The only requirement is to use the Brooklyn colour palette. Prospective GSOC mentor: tbou...@apache.org was: This is an idea for [Google Summer of Code|https://summerofcode.withgoogle.com/] (GSOC). h1. Issue The currently Brooklyn UI is getting old and lagging behind the newest changes made into the REST API. It would need an overhaul to refresh it and more importantly, use the newest technologies out there in terms of front-end dev. h1. Proposal Rewrite the Brooklyn UI to match closely the novelties introduced recently on the REST API. The goal is to achieve feature parity between the old and this new UI: * Dashboard view * In-depth view * Composer view * Catalog view * REST API view This would obviously be done in JS but the frameworks (both JS and CSS) are free to choose. This would be a good opprotunity to go wild and try different ideas (either technical or design) as well as unit tests if time allows it. The only requirement is to use the Brooklyn colour palette. Prospective GSOC mentor: tbou...@apache.org > GSOC: New Brooklyn UI > - > > Key: BROOKLYN-575 > URL: https://issues.apache.org/jira/browse/BROOKLYN-575 > Project: Brooklyn > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Thomas Bouron >Priority: Major > Labels: cloud, javascript, js, rest, ui > > This is an idea for [Google Summer of > Code|https://summerofcode.withgoogle.com/] (GSOC). > h1. Issue > The currently Brooklyn UI is getting old and lagging behind the newest > changes made into the REST API. It would need an overhaul to refresh it and > more importantly, use the newest technologies out there in terms of front-end > dev. > h1. Proposal > Rewrite the Brooklyn UI to match closely the novelties introduced recently on > the REST API. The goal is to achieve feature parity between the old and this > new UI: > * Dashboard view > * In-depth view > * Composer view > * Catalog view > * REST API view > This would obviously be done in JS but the frameworks (both JS and CSS) are > free to choose. This would be a good opportunity to go wild and try different > ideas (either technical or design) as well as unit tests if time allows it. > The only requirement is to use the Brooklyn colour palette. > > Prospective GSOC mentor: tbou...@apache.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-548) Brooklyn node ID changes on restart
[
https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245531#comment-16245531
]
Thomas Bouron commented on BROOKLYN-548:
Thanks [~svet], I get that for the planeId. But it still feels odd that the
same server with the software gets a different ID on each start. As a user, it
does not make sense to see 3 servers, including one with status "terminated"
where I always had only 2 servers.
Anyone has thoughts on this?
Now if that the expected behaviour then fine, we can close this ticket.
> Brooklyn node ID changes on restart
> ---
>
> Key: BROOKLYN-548
> URL: https://issues.apache.org/jira/browse/BROOKLYN-548
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Thomas Bouron
>
> I was testing Brooklyn HA and noticed something odd: when restarting an HA
> Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
> For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master
> (not killed, stopped), slave took over as expected. Then I restarted the
> previous master, it came back online as a slave (expected) but the node ID
> was different. I was expecting it to keep its ID rather creating a new one.
> {code}
> {
> "planeId": "qDpn2Lau",
> "ownId": "nJagUrw8",
> "masterId": "nJagUrw8",
> "nodes": {
> "BgOjYcml": {
> "nodeId": "BgOjYcml",
> "nodeUri": null,
> "status": "TERMINATED",
> "localTimestamp": 1510052259169,
> "remoteTimestamp": 151005226
> },
> "iv3XfaEu": {
> "nodeId": "iv3XfaEu",
> "nodeUri": null,
> "status": "STANDBY",
> "localTimestamp": 1510054973636,
> "remoteTimestamp": 1510054974000
> },
> "nJagUrw8": {
> "nodeId": "nJagUrw8",
> "nodeUri": null,
> "status": "MASTER",
> "localTimestamp": 1510054975025,
> "remoteTimestamp": 1510054976000
> }
> },
> "links": {}
> }
> {code}
> On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
> {{BgOjYcml}} was the ID of the node before restart.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (BROOKLYN-548) Brooklyn node ID changes on restart
[
https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-548:
---
Attachment: (was: screenshot-1.png)
> Brooklyn node ID changes on restart
> ---
>
> Key: BROOKLYN-548
> URL: https://issues.apache.org/jira/browse/BROOKLYN-548
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Thomas Bouron
>
> I was testing Brooklyn HA and noticed something odd: when restarting an HA
> Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
> For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master
> (not killed, stopped), slave took over as expected. Then I restarted the
> previous master, it came back online as a slave (expected) but the node ID
> was different. I was expecting it to keep its ID rather creating a new one.
> {code}
> {
> "planeId": "qDpn2Lau",
> "ownId": "nJagUrw8",
> "masterId": "nJagUrw8",
> "nodes": {
> "BgOjYcml": {
> "nodeId": "BgOjYcml",
> "nodeUri": null,
> "status": "TERMINATED",
> "localTimestamp": 1510052259169,
> "remoteTimestamp": 151005226
> },
> "iv3XfaEu": {
> "nodeId": "iv3XfaEu",
> "nodeUri": null,
> "status": "STANDBY",
> "localTimestamp": 1510054973636,
> "remoteTimestamp": 1510054974000
> },
> "nJagUrw8": {
> "nodeId": "nJagUrw8",
> "nodeUri": null,
> "status": "MASTER",
> "localTimestamp": 1510054975025,
> "remoteTimestamp": 1510054976000
> }
> },
> "links": {}
> }
> {code}
> On the attached screenshot, {{BgOjYcml}} is the same node as {{iv3XfaEu}}.
> {{BgOjYcml}} was the ID of the node before restart
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (BROOKLYN-548) Brooklyn node ID changes on restart
[
https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-548:
---
Description:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one.
{code}
{
"planeId": "qDpn2Lau",
"ownId": "nJagUrw8",
"masterId": "nJagUrw8",
"nodes": {
"BgOjYcml": {
"nodeId": "BgOjYcml",
"nodeUri": null,
"status": "TERMINATED",
"localTimestamp": 1510052259169,
"remoteTimestamp": 151005226
},
"iv3XfaEu": {
"nodeId": "iv3XfaEu",
"nodeUri": null,
"status": "STANDBY",
"localTimestamp": 1510054973636,
"remoteTimestamp": 1510054974000
},
"nJagUrw8": {
"nodeId": "nJagUrw8",
"nodeUri": null,
"status": "MASTER",
"localTimestamp": 1510054975025,
"remoteTimestamp": 1510054976000
}
},
"links": {}
}
{code}
On the attached screenshot, {{BgOjYcml}} is the same node as {{iv3XfaEu}}.
{{BgOjYcml}} was the ID of the node before restart
was:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one (see
screenshot)
> Brooklyn node ID changes on restart
> ---
>
> Key: BROOKLYN-548
> URL: https://issues.apache.org/jira/browse/BROOKLYN-548
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Thomas Bouron
>
> I was testing Brooklyn HA and noticed something odd: when restarting an HA
> Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
> For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master
> (not killed, stopped), slave took over as expected. Then I restarted the
> previous master, it came back online as a slave (expected) but the node ID
> was different. I was expecting it to keep its ID rather creating a new one.
> {code}
> {
> "planeId": "qDpn2Lau",
> "ownId": "nJagUrw8",
> "masterId": "nJagUrw8",
> "nodes": {
> "BgOjYcml": {
> "nodeId": "BgOjYcml",
> "nodeUri": null,
> "status": "TERMINATED",
> "localTimestamp": 1510052259169,
> "remoteTimestamp": 151005226
> },
> "iv3XfaEu": {
> "nodeId": "iv3XfaEu",
> "nodeUri": null,
> "status": "STANDBY",
> "localTimestamp": 1510054973636,
> "remoteTimestamp": 1510054974000
> },
> "nJagUrw8": {
> "nodeId": "nJagUrw8",
> "nodeUri": null,
> "status": "MASTER",
> "localTimestamp": 1510054975025,
> "remoteTimestamp": 1510054976000
> }
> },
> "links": {}
> }
> {code}
> On the attached screenshot, {{BgOjYcml}} is the same node as {{iv3XfaEu}}.
> {{BgOjYcml}} was the ID of the node before restart
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (BROOKLYN-548) Brooklyn node ID changes on restart
[
https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-548:
---
Description:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one.
{code}
{
"planeId": "qDpn2Lau",
"ownId": "nJagUrw8",
"masterId": "nJagUrw8",
"nodes": {
"BgOjYcml": {
"nodeId": "BgOjYcml",
"nodeUri": null,
"status": "TERMINATED",
"localTimestamp": 1510052259169,
"remoteTimestamp": 151005226
},
"iv3XfaEu": {
"nodeId": "iv3XfaEu",
"nodeUri": null,
"status": "STANDBY",
"localTimestamp": 1510054973636,
"remoteTimestamp": 1510054974000
},
"nJagUrw8": {
"nodeId": "nJagUrw8",
"nodeUri": null,
"status": "MASTER",
"localTimestamp": 1510054975025,
"remoteTimestamp": 1510054976000
}
},
"links": {}
}
{code}
On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
{{BgOjYcml}} was the ID of the node before restart.
was:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one.
{code}
{
"planeId": "qDpn2Lau",
"ownId": "nJagUrw8",
"masterId": "nJagUrw8",
"nodes": {
"BgOjYcml": {
"nodeId": "BgOjYcml",
"nodeUri": null,
"status": "TERMINATED",
"localTimestamp": 1510052259169,
"remoteTimestamp": 151005226
},
"iv3XfaEu": {
"nodeId": "iv3XfaEu",
"nodeUri": null,
"status": "STANDBY",
"localTimestamp": 1510054973636,
"remoteTimestamp": 1510054974000
},
"nJagUrw8": {
"nodeId": "nJagUrw8",
"nodeUri": null,
"status": "MASTER",
"localTimestamp": 1510054975025,
"remoteTimestamp": 1510054976000
}
},
"links": {}
}
{code}
On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
{{BgOjYcml}} was the ID of the node before restart.
> Brooklyn node ID changes on restart
> ---
>
> Key: BROOKLYN-548
> URL: https://issues.apache.org/jira/browse/BROOKLYN-548
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Thomas Bouron
>
> I was testing Brooklyn HA and noticed something odd: when restarting an HA
> Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
> For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master
> (not killed, stopped), slave took over as expected. Then I restarted the
> previous master, it came back online as a slave (expected) but the node ID
> was different. I was expecting it to keep its ID rather creating a new one.
> {code}
> {
> "planeId": "qDpn2Lau",
> "ownId": "nJagUrw8",
> "masterId": "nJagUrw8",
> "nodes": {
> "BgOjYcml": {
> "nodeId": "BgOjYcml",
> "nodeUri": null,
> "status": "TERMINATED",
> "localTimestamp": 1510052259169,
> "remoteTimestamp": 151005226
> },
> "iv3XfaEu": {
> "nodeId": "iv3XfaEu",
> "nodeUri": null,
> "status": "STANDBY",
> "localTimestamp": 1510054973636,
> "remoteTimestamp": 1510054974000
> },
> "nJagUrw8": {
> "nodeId": "nJagUrw8",
> "nodeUri": null,
> "status": "MASTER",
> "localTimestamp": 1510054975025,
> "remoteTimestamp": 1510054976000
> }
> },
> "links": {}
> }
> {code}
> On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
> {{BgOjYcml}} was the ID of the node before restart.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (BROOKLYN-548) Brooklyn node ID changes on restart
[
https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-548:
---
Description:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one.
{code}
{
"planeId": "qDpn2Lau",
"ownId": "nJagUrw8",
"masterId": "nJagUrw8",
"nodes": {
"BgOjYcml": {
"nodeId": "BgOjYcml",
"nodeUri": null,
"status": "TERMINATED",
"localTimestamp": 1510052259169,
"remoteTimestamp": 151005226
},
"iv3XfaEu": {
"nodeId": "iv3XfaEu",
"nodeUri": null,
"status": "STANDBY",
"localTimestamp": 1510054973636,
"remoteTimestamp": 1510054974000
},
"nJagUrw8": {
"nodeId": "nJagUrw8",
"nodeUri": null,
"status": "MASTER",
"localTimestamp": 1510054975025,
"remoteTimestamp": 1510054976000
}
},
"links": {}
}
{code}
On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
{{BgOjYcml}} was the ID of the node before restart.
was:
I was testing Brooklyn HA and noticed something odd: when restarting an HA
Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not
killed, stopped), slave took over as expected. Then I restarted the previous
master, it came back online as a slave (expected) but the node ID was
different. I was expecting it to keep its ID rather creating a new one.
{code}
{
"planeId": "qDpn2Lau",
"ownId": "nJagUrw8",
"masterId": "nJagUrw8",
"nodes": {
"BgOjYcml": {
"nodeId": "BgOjYcml",
"nodeUri": null,
"status": "TERMINATED",
"localTimestamp": 1510052259169,
"remoteTimestamp": 151005226
},
"iv3XfaEu": {
"nodeId": "iv3XfaEu",
"nodeUri": null,
"status": "STANDBY",
"localTimestamp": 1510054973636,
"remoteTimestamp": 1510054974000
},
"nJagUrw8": {
"nodeId": "nJagUrw8",
"nodeUri": null,
"status": "MASTER",
"localTimestamp": 1510054975025,
"remoteTimestamp": 1510054976000
}
},
"links": {}
}
{code}
On the attached screenshot, {{BgOjYcml}} is the same node as {{iv3XfaEu}}.
{{BgOjYcml}} was the ID of the node before restart
> Brooklyn node ID changes on restart
> ---
>
> Key: BROOKLYN-548
> URL: https://issues.apache.org/jira/browse/BROOKLYN-548
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.12.0
>Reporter: Thomas Bouron
>
> I was testing Brooklyn HA and noticed something odd: when restarting an HA
> Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`.
> For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master
> (not killed, stopped), slave took over as expected. Then I restarted the
> previous master, it came back online as a slave (expected) but the node ID
> was different. I was expecting it to keep its ID rather creating a new one.
> {code}
> {
> "planeId": "qDpn2Lau",
> "ownId": "nJagUrw8",
> "masterId": "nJagUrw8",
> "nodes": {
> "BgOjYcml": {
> "nodeId": "BgOjYcml",
> "nodeUri": null,
> "status": "TERMINATED",
> "localTimestamp": 1510052259169,
> "remoteTimestamp": 151005226
> },
> "iv3XfaEu": {
> "nodeId": "iv3XfaEu",
> "nodeUri": null,
> "status": "STANDBY",
> "localTimestamp": 1510054973636,
> "remoteTimestamp": 1510054974000
> },
> "nJagUrw8": {
> "nodeId": "nJagUrw8",
> "nodeUri": null,
> "status": "MASTER",
> "localTimestamp": 1510054975025,
> "remoteTimestamp": 1510054976000
> }
> },
> "links": {}
> }
> {code}
> On the JSON above, {{BgOjYcml}} is the same node as {{iv3XfaEu}} but
> {{BgOjYcml}} was the ID of the node before restart.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (BROOKLYN-548) Brooklyn node ID changes on restart
[ https://issues.apache.org/jira/browse/BROOKLYN-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bouron updated BROOKLYN-548: --- Attachment: screenshot-1.png > Brooklyn node ID changes on restart > --- > > Key: BROOKLYN-548 > URL: https://issues.apache.org/jira/browse/BROOKLYN-548 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Thomas Bouron > Attachments: screenshot-1.png > > > I was testing Brooklyn HA and noticed something odd: when restarting an HA > Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`. > For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master > (not killed, stopped), slave took over as expected. Then I restarted the > previous master, it came back online as a slave (expected) but the node ID > was different. I was expecting it to keep its ID rather creating a new one > (see screenshot) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (BROOKLYN-548) Brooklyn node ID changes on restart
Thomas Bouron created BROOKLYN-548: -- Summary: Brooklyn node ID changes on restart Key: BROOKLYN-548 URL: https://issues.apache.org/jira/browse/BROOKLYN-548 Project: Brooklyn Issue Type: Bug Affects Versions: 0.12.0 Reporter: Thomas Bouron I was testing Brooklyn HA and noticed something odd: when restarting an HA Brooklyn node, it changes it's node ID reported by `/v1/server/ha/states`. For instance, I have 2 Brooklyn nodes, 1 master, 1 slave. I stopped master (not killed, stopped), slave took over as expected. Then I restarted the previous master, it came back online as a slave (expected) but the node ID was different. I was expecting it to keep its ID rather creating a new one (see screenshot) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BROOKLYN-503) Shell.env should work with SaltEntity
[
https://issues.apache.org/jira/browse/BROOKLYN-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147243#comment-16147243
]
Thomas Bouron commented on BROOKLYN-503:
[~angarg12] I converted the {{SaltEntity}} to be a real {{SoftwareProcess}}. So
far all my tests are successful (which is a good sign)
I saw your blueprint in the description of this ticket and wanted to test it as
well. Unfortunately, it contains couple of placeholder URLs.
Would you mind sharing the full blueprint, or test the new version of
SaltEntity with my change?
Cheers
> Shell.env should work with SaltEntity
> -
>
> Key: BROOKLYN-503
> URL: https://issues.apache.org/jira/browse/BROOKLYN-503
> Project: Brooklyn
> Issue Type: Improvement
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04
>Reporter: Andres Garcia Garcia
> Labels: env, salted
>
> I am using Brooklyn to deploy servers configured with Salt.
> I am trying to deploy one VM with a web server and another with MySQL, and
> link them together using env variables in the salt pillars.
> Based on the sample templates, this is my yaml.
> name: Salt LAMP deployment (Brooklyn Example)
> {code}
> services:
> - id: mysql
> name: mysql
> type: org.apache.brooklyn.entity.cm.salt.SaltEntity
> formulas:
> - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
> start_states:
> - mysql
> pillars:
> - mysql
> pillarUrls:
> - ftp://xxx/wordpress-example.tar
> - id: wordpress
> name: wordpress
> type: org.apache.brooklyn.entity.cm.salt.SaltEntity
> formulas:
> - https://github.com/saltstack-formulas/php-formula/archive/master.tar.gz
> -
> https://github.com/saltstack-formulas/wordpress-formula/archive/master.tar.gz
> - https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
> - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
> start_states:
> - mysql.client
> - php.ng
> - php.ng.mysql
> - wordpress
> - apache
> - apache.config
> - apache.vhosts.standard
> pillars:
> - php
> - wordpress
> - apache
> - mysql
> pillarUrls:
> - ftp://xxx/filezilla.tar
> brooklyn.config:
> shell.env:
> MYSQL_URL: $brooklyn:entity("mysql").attributeWhenReady("host.name")
> location:
> jclouds:aws-ec2:
> identity: xxx
> credential: xxx
> region: us-west-2
> inboundPorts:
> - 22
> - 80
> - 3306
> hardwareId: t2.small
> {code}
> And then, inside the pillars, I configure them as follows
> {code}
> wordpress:
> sites:
> username: xxx
> password: xxx
> database: xxx
> dbhost: {{ salt['environ.get']('MYSQL_URL') }}
> {code}
> However, the MYSQL_URL env variable is resolved to none.
> I got word from svet in the IRC channel that SaltEntity doesn't support
> shell.env. I think it would be really helpful to make this option available
> in order to configure multinode deployments with Salt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (BROOKLYN-339) Node.js entity fails
[
https://issues.apache.org/jira/browse/BROOKLYN-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15987165#comment-15987165
]
Thomas Bouron commented on BROOKLYN-339:
[~drigodwin] [~aledsage] I would suggest to create a new constraint like
{{requiredIf}} that take a map of {{configkey: predicate}}
> Node.js entity fails
>
>
> Key: BROOKLYN-339
> URL: https://issues.apache.org/jira/browse/BROOKLYN-339
> Project: Brooklyn
> Issue Type: Bug
> Environment: Tested on Centos 6 on AWS
>Reporter: Duncan Godwin
>
> Starting the Node.js entity gives the following error during the customize
> phase:
> {code}
> Failed after 0ms: At least one of Git or archive URL must be set for
> NodeJsWebAppServiceImpl{id=v9qctusjsb}
> java.lang.IllegalStateException: At least one of Git or archive URL must be
> set for NodeJsWebAppServiceImpl{id=v9qctusjsb}
> at
> org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppSshDriver.customize(NodeJsWebAppSshDriver.java:131)
> at
> org.apache.brooklyn.entity.software.base.AbstractSoftwareProcessDriver$3$2.run(AbstractSoftwareProcessDriver.java:175)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
> at
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Note that running the Node.js tests DOES work, just not the entity on it's own
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (BROOKLYN-483) Brooklyn cannot initiate first SSH connection on Azure
Thomas Bouron created BROOKLYN-483:
--
Summary: Brooklyn cannot initiate first SSH connection on Azure
Key: BROOKLYN-483
URL: https://issues.apache.org/jira/browse/BROOKLYN-483
Project: Brooklyn
Issue Type: Bug
Affects Versions: 0.11.0
Reporter: Thomas Bouron
I'm trying to deploy a very simple blueprint
{code}
location: azure-sng-minimal
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
{code}
on a minimal Azure location:
{code}
brooklyn.catalog:
id: azure-sng-minimal
itemType: location
name: "Azure Southeast Asia (SNG) Minimal"
item:
type: jclouds:azurecompute
brooklyn.config:
regionId: Southeast Asia
identity: /Users/thomasbouron/.ssh/azure.p12
credential:
endpoint:
https://management.core.windows.net/341751b0-f348-45ce-9498-x
{code}
Brooklyn is able to provisioned the VM but fails to initiate the first SSH
connection:
{code}
2017-04-19 10:38:23,702 INFO 334 o.a.b.r.r.ApplicationResource
[qtp235840421-124] Launched from YAML: location: azure-sng-minimal
- type: "elasticsearch-node-tests_19042017_103735:1.0.2-SNAPSHOT" ->
BasicApplicationImpl{id=b6lgwpmnrj} (Task[start]@tfqRf4JU)
2017-04-19 10:38:23,858 INFO 129 o.a.b.e.s.b.l.MachineLifecycleEffectorTasks
[ager-iWm4jv3o-17] Starting VanillaSoftwareProcessImpl{id=f7iv5s8u2x},
obtaining a new location instance in JcloudsLocation[Azure Southeast Asia (SNG)
Minimal:/amp/azure.p12@azkm52sknu] with ports [22, 9330, 9200]
2017-04-19 10:38:24,760 INFO 125 o.a.b.l.j.JcloudsLocation [ager-iWm4jv3o-17]
Creating VM
azurecompute:https://management.core.windows.net/341751b0-f348-45ce-9498-x@VanillaSoftwareProcessImpl{id=f7iv5s8u2x}
in JcloudsLocation[Azure Southeast Asia (SNG)
Minimal:/users/thomasbouron/.ssh/azure.p12@azkm52sknu]
2017-04-19 10:39:09,962 INFO 106 j.compute [user thread 0] Cloud Service
(brooklyn-oonk80-root-elastic-b6lg-elasticsearchnod-f7iv-caa) created with
operation id: 76008c93b18d74c797f17958fa336eb6
2017-04-19 10:39:36,713 INFO 106 j.compute [user thread 0] Deployment created
with name: brooklyn-oonk80-root-elastic-b6lg-elasticsearchnod-f7iv-caa
2017-04-19 10:41:53,917 INFO 106 j.ssh [user thread 1] <<
(jclouds:pw[cdfb4472683ad9b4f7e159935dbc439a]@40.71.103.245:22) error acquiring
{hostAndPort=40.71.103.245:22, loginUser=jclouds, ssh=null,
connectTimeout=6, sessionTimeout=6} (attempt 1 of 50): Exhausted
available authentication methods
2017-04-19 10:41:56,108 INFO 106 j.ssh [user thread 1] <<
(jclouds:pw[cdfb4472683ad9b4f7e159935dbc439a]@40.71.103.245:22) error acquiring
{hostAndPort=40.71.103.245:22, loginUser=jclouds, ssh=null,
connectTimeout=6, sessionTimeout=6} (attempt 2 of 50): Exhausted
available authentication methods
2017-04-19 10:41:58,946 INFO 106 j.ssh [user thread 1] <<
(jclouds:pw[cdfb4472683ad9b4f7e159935dbc439a]@40.71.103.245:22) error acquiring
{hostAndPort=40.71.103.245:22, loginUser=jclouds, ssh=null,
connectTimeout=6, sessionTimeout=6} (attempt 3 of 50): Exhausted
available authentication methods
...
{code}
Looks like the default {{loginUser}} picked by jClouds is wrong. I know I can
specify my own {{loginUser}} but I would expected jClouds to do this for me on
basic locations
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (BROOKLYN-336) Policy added even though the API returns an error
[
https://issues.apache.org/jira/browse/BROOKLYN-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-336:
---
Description:
Deploying this simple blueprint:
{code:title=Bar.java|borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
name: Test
{code}
then heading to the policy tab to add a
`org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't work.
The UI displays the error coming back from the API but the policy is added
anyway. See attached gif to see it the bug in action
was:
Deploying this simple blueprint:
{code:title=Bar.java|borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
name: Test
{code}
then heading to the policy tab to add a
`org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't work.
The UI displays the error coming back from the API but the policy is added
anyway.
> Policy added even though the API returns an error
> -
>
> Key: BROOKLYN-336
> URL: https://issues.apache.org/jira/browse/BROOKLYN-336
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: Thomas Bouron
> Attachments: brooklyn-policy-bug.gif
>
>
> Deploying this simple blueprint:
> {code:title=Bar.java|borderStyle=solid}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
> name: Test
> {code}
> then heading to the policy tab to add a
> `org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't
> work. The UI displays the error coming back from the API but the policy is
> added anyway. See attached gif to see it the bug in action
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BROOKLYN-336) Policy added even though the API returns an error
[
https://issues.apache.org/jira/browse/BROOKLYN-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bouron updated BROOKLYN-336:
---
Description:
Deploying this simple blueprint:
{code:title=blueprint.yaml|borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
name: Test
{code}
then heading to the policy tab to add a
`org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't work.
The UI displays the error coming back from the API but the policy is added
anyway. See attached gif to see it the bug in action
was:
Deploying this simple blueprint:
{code:title=Bar.java|borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
name: Test
{code}
then heading to the policy tab to add a
`org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't work.
The UI displays the error coming back from the API but the policy is added
anyway. See attached gif to see it the bug in action
> Policy added even though the API returns an error
> -
>
> Key: BROOKLYN-336
> URL: https://issues.apache.org/jira/browse/BROOKLYN-336
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: Thomas Bouron
> Attachments: brooklyn-policy-bug.gif
>
>
> Deploying this simple blueprint:
> {code:title=blueprint.yaml|borderStyle=solid}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
> name: Test
> {code}
> then heading to the policy tab to add a
> `org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't
> work. The UI displays the error coming back from the API but the policy is
> added anyway. See attached gif to see it the bug in action
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BROOKLYN-336) Policy added even though the API returns an error
Thomas Bouron created BROOKLYN-336:
--
Summary: Policy added even though the API returns an error
Key: BROOKLYN-336
URL: https://issues.apache.org/jira/browse/BROOKLYN-336
Project: Brooklyn
Issue Type: Bug
Affects Versions: 0.9.0
Reporter: Thomas Bouron
Deploying this simple blueprint:
{code:title=Bar.java|borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
name: Test
{code}
then heading to the policy tab to add a
`org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy` which shouldn't work.
The UI displays the error coming back from the API but the policy is added
anyway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-275) Private Key Data description in the Add BYON Location Wizard is misleading
[
https://issues.apache.org/jira/browse/BROOKLYN-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299819#comment-15299819
]
Thomas Bouron commented on BROOKLYN-275:
Not fixed yet [~johnmccabe], I'm looking at it right now.
FYI, [there is another
ticket|https://issues.apache.org/jira/browse/BROOKLYN-270] for the multiline
I'm also looking at.
> Private Key Data description in the Add BYON Location Wizard is misleading
> --
>
> Key: BROOKLYN-275
> URL: https://issues.apache.org/jira/browse/BROOKLYN-275
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: John McCabe
>
> Attempting to add a BYON location via the Catalog wizard you are prompted for
> the following:
> {code}
> Private Key Data
> The contents of the private key file to use to connect to the machines (if
> using key access, where the corresponding public key is in the
> .authorized_keys file on the servers)
> {code}
> This implies that you must paste the *contents* of your private key file
> however this field is currently maping to {{privateKeyFile}} which takes a
> path to the key file on the Brooklyn node FS.
> This needs to be updated to push the contents of the textarea to
> {{privateKeyData}}.
> *NOTE*: Also observed that if you paste a multi-line key it wasn't being
> indented correctly, not sure if that was a result of populating the
> {{privateKeyFile}} tag (suspect not tho...), we should handle multi-line key
> data as if the user copy-pastes from their private key file thats what
> they'll be pasting, also needs to handle the begin/end comments in a standard
> private key file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-270) BYON Location GUI Generates Bad-formatted YAML File
[
https://issues.apache.org/jira/browse/BROOKLYN-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15289199#comment-15289199
]
Thomas Bouron commented on BROOKLYN-270:
Humm I see what is going on here. Each configuration key is treated as a basic
string but the {{privateKeyFile}} should be multiline hence prefixed by a {{|}}.
If the text field keep the line breaks, the UI could prepend {{|}} without too
much trouble.
> BYON Location GUI Generates Bad-formatted YAML File
> ---
>
> Key: BROOKLYN-270
> URL: https://issues.apache.org/jira/browse/BROOKLYN-270
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0
> Environment: apache-brooklyn-0.9.0-bin on Mac OS X 10.11.4
>Reporter: Mike Zaccardo
> Labels: byon, gui
>
> When attempting to add a BYON location with a private key file through the
> GUI, the generated YAML file is improperly formatted and results in the
> following error when the user tries to save:
> ERROR Invalid YAML: while scanning a simple key; could not found expected
> ':'; in 'reader', line 12, column 1: vfyF2M3xG3z5MUPuqeCveLhkI/1t26mW ... ^
> The location can only be added after the user manually fixes the formatting
> in the YAML editor view.
> Here is a comparison of generated vs. manually fixed:
> https://gist.github.com/mikezaccardo/34ea0c38b232bf125a059f1b1913c486
> ^^ Note that the private key is a harmless / throwaway from a Vagrant box.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-266) NPE when deploying Riak Node on MacOS
[
https://issues.apache.org/jira/browse/BROOKLYN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278309#comment-15278309
]
Thomas Bouron commented on BROOKLYN-266:
Thanks [~alex.heneveld], that solves it... but there are few other behind:
# the {{expandedinstall.dir}} is not setup when installing on Mac which makes
the entire thing collapse. I tested to set the sensor to the same value as
{{install.dir}}, seems to work.
# the {{customize}} script does a {{ulimit -n 65536 || true}} but on Mac OS,
{{ulimit}} does not take any arguments which make the deployment fail.
> NPE when deploying Riak Node on MacOS
> -
>
> Key: BROOKLYN-266
> URL: https://issues.apache.org/jira/browse/BROOKLYN-266
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.10.0
> Environment: Mac OS
>Reporter: Thomas Bouron
>
> When deploying a simple Riak Node to MacOS, using the following blueprint:
> {code:borderStyle=solid}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.nosql.riak.RiakNode
> {code}
> The Riak node entity throws a NPE during the install phase with the following
> stack trace:
> {code}
> Failed after 0ms: NullPointerException
> java.lang.NullPointerException
> at
> org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.installMac(RiakNodeSshDriver.java:211)
> at
> org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.install(RiakNodeSshDriver.java:116)
> at
> org.apache.brooklyn.entity.software.base.AbstractSoftwareProcessDriver$2$6.run(AbstractSoftwareProcessDriver.java:159)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
> at
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BROOKLYN-266) NPE when deploying Riak Node on MacOS
Thomas Bouron created BROOKLYN-266:
--
Summary: NPE when deploying Riak Node on MacOS
Key: BROOKLYN-266
URL: https://issues.apache.org/jira/browse/BROOKLYN-266
Project: Brooklyn
Issue Type: Bug
Affects Versions: 0.10.0
Environment: Mac OS
Reporter: Thomas Bouron
When deploying a simple Riak Node to MacOS, using the following blueprint:
{code:borderStyle=solid}
location: localhost
services:
- type: org.apache.brooklyn.entity.nosql.riak.RiakNode
{code}
The Riak node entity throws a NPE during the install phase with the following
stack trace:
{code}
Failed after 0ms: NullPointerException
java.lang.NullPointerException
at
org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.installMac(RiakNodeSshDriver.java:211)
at
org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.install(RiakNodeSshDriver.java:116)
at
org.apache.brooklyn.entity.software.base.AbstractSoftwareProcessDriver$2$6.run(AbstractSoftwareProcessDriver.java:159)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
at
org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-262) No error thrown when adding app yaml to the catalog
[
https://issues.apache.org/jira/browse/BROOKLYN-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15270850#comment-15270850
]
Thomas Bouron commented on BROOKLYN-262:
There are 2 issues here:
# The catalog should refuse a YAML that is not formatted correctly, i.e. does
not start with `brooklyn.catalog`
# The composer should detect in which mode we are based on what is typed. I
would go even further than that and remove the mode toggle from the UI as it is
only there to change the submit button label + example that can be inserted.
> No error thrown when adding app yaml to the catalog
> ---
>
> Key: BROOKLYN-262
> URL: https://issues.apache.org/jira/browse/BROOKLYN-262
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0
>Reporter: John McCabe
>Priority: Minor
>
> Adding application yaml to the catalog composer results in the app being
> added to the catalog rather than an error thrown.
> For example, adding the following to the composer with {{catalog}} selected
> rather than {{application}}:
> {code}
> location: localhost
> name: tomcat
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
> id: tomcat
> name: Tomcat
> war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-246) Unable to add byon locations
[
https://issues.apache.org/jira/browse/BROOKLYN-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225989#comment-15225989
]
Thomas Bouron commented on BROOKLYN-246:
When I added the location wizard, the first format of location described in the
issue worked during my tests. So the bug probably comes from something merged
at the same time or after.
> Unable to add byon locations
>
>
> Key: BROOKLYN-246
> URL: https://issues.apache.org/jira/browse/BROOKLYN-246
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: John McCabe
>Priority: Blocker
>
> Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly
> build 0.10.0-SNAPSHOT from master I'm seeing the following behaviour.
> 1. Attempting to add a BYON location via jsgui is rejected with the following
> error:
> {code}
> Could not resolve item 'testingid': Transformer for Brooklyn OASIS CAMP
> interpreter gave an error creating this plan: No class or resolver found for
> location type byon
> {code}
> 2. Trying the the generated JSON via the composer also fails:
> {code}
> brooklyn.catalog:
> version: 0.0.1
> items:
> - id: testingid
> itemType: location
> item:
> type: byon
> brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> hosts:
> - 10.10.10.102
> {code}
> 3. *BUT* this works:
> {code}
> brooklyn.catalog:
> version: 0.0.1
> items:
> - id: testingid
> itemType: location
> item:
> type: byon:(hosts="10.10.10.102")
> brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
