brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Azhar I Hashmi" <>
Subject "using variable later in postprovisionscript or any other script"
Date Thu, 22 Jan 2015 01:10:58 GMT


Brooklyn provides a way to define variable and set their value using
sensor.  However, I am not able to successfully use those variables.  I
could not find those variables. I defined them in two different ways to use
them later in post script but was not able to find them. Here is a piece of
the YAML blueprint example:

      type: brooklyn.entity.webapp.tomcat.TomcatServer
      id: tomcatServer
          privateNetworkOnly: false
        https.port: 8443+
        MY_VARIABLE: $brooklyn:formatString("%s",

Question 1:  How do I use these variables in my scrips?
Question 2: I need following jars and xml file in Tomcat/apache catalina
lib and conf directories respectively.  However, following piece of yaml
blueprint put them under /home/...../install/...../lib/  and
/home/...../install/..../conf/ directories.  I need the jar files under lib
folder of Catalina/tomcat 's lib directory and .xml file under
/home/..../apps/.......TomcatEntity/conf  directory.  Is there a variable
that I can use in <key,value> pair instead of lib/ and conf/ directories?

": lib/tomcat-dbcp-7.0.30.jar
": lib/mysql-connector-java-5.1.10.jar
          "https://provision/tomcat-users.xml": conf/tomcat-users.xml


From:	Alex Heneveld <>
Date:	01/21/2015 06:08 PM
Subject:	Re: "force resolution of localhost to be loopback, otherwise we
            hit problems"


If the localhost IP is set up right there should be no problem changing
or removing the flag in the launch script for that one case.

Background though is exactly as Richard described.  Several people have
hit problems deploying to "localhost" because localhost is mapped to a
bad IP address.

This can happen in clouds where /etc/hosts is foolishly set up.

Worse, on Mac it was sometimes the case that localhost resolves to the
subnet IP.  That IP would be cached, and then if you change wifi points,
localhost deployments could get very confused.  This might be better in
yosemite (localhost resolves to for me at least) but it's hard
to be sure.  Maybe someone else knows better?

Why do you want localhost to resolve to something else?  It seems unusual.


On 19/01/2015 10:34, Richard Downer wrote:
> Sam,
> I would guess that if the hostname/domain name are properly configured
> everything should work. Unfortunately, it's easy to *not* quite
> configure networking correctly.
> My understanding of the canonical way to set the system hostname and
> domain name is as follows:
> /etc/hosts:
>  hostname hostname.domainname localhost
> # that must be the first non-comment line
> Configure the system hostname (without domainname); IIRC, on
> Debian-derivatives you write it to the file /etc/hostname, and on
> RedHat-derivatives there's a variable in /etc/sysconfig/network
> Then either run "hostname newhostname" or "service network restart" or
> Check it works:
> # hostname
> (returns the bare hostname)
> # hostname --fqdn
> (returns the hostname and DNS domainname)
> On 18 January 2015 at 10:32, Sam Corbett <>
>> BrooklynServiceAttributes defines the property and has a comment saying:
>> /** in some cases localhost does not resolve correctly
>>   * (e.g. to an interface which is defined locally but not in operation,
>>   * or where multiple NICs are available and java's
>> InetAddress.getLocalHost() strategy is not doing what is desired);
>>   * use this to supply a specific address (e.g. "" or a
specific IP
>> on a specific NIC or FW)
>>   */
>> I guess this answers my question but it doesn't give me much assurance.
>> On 18 January 2015 at 10:02, Sam Corbett <>
>> wrote:
>>> Hi,
>>> The `brooklyn` launch script sets
>>> `-Dbrooklyn.location.localhost.address=` with the cryptic
>>> explanation that 'otherwise we hit problems'. Can anybody explain what
>>> problems are avoided? I have a case in which I'd like the hostname of a
>>> localhost location to be the hostname of the machine, but I'd also like
>>> know what will happen if I change or remove the flag.
>>> Thanks,
>>> Sam

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message