These are chat archives for cloudsoft/brooklyn-tosca

29th
Oct 2015
Jose
@kiuby88
Oct 29 2015 07:28
Hi @/all. I have a little question.
How coul we deploy to entities in the same VM? should we use SameServer? In this case, the Brooklyn NodeTypes should contain a host (property/requirement) right?
Andrea Turli
@andreaturli
Oct 29 2015 07:39
Not sure I get your question. SameServer looks reasonable but isn't placement strategy suppose to deal with this situation?
Jose
@kiuby88
Oct 29 2015 07:41
I think so. But I do not know as placement strategy could deal with this situation :-)
Because, placement strategy can add a location to an entity. But each entity will use its own VM (provisiones machine).
Andrea Turli
@andreaturli
Oct 29 2015 07:44
Maybe a configuration on the policy? location.brooklyn = localhost
sameserver = true
Just a rough idea
Jose
@kiuby88
Oct 29 2015 09:17
Thanks @andreaturli
Jose
@kiuby88
Oct 29 2015 09:34
we could avoid sameserver property. If a policy contains a node number greater than 1 it will create a SameServer EntitySpec and these nodes will be added as children
Andrea Turli
@andreaturli
Oct 29 2015 09:36
what are the properties of the policy currently?
Jose
@kiuby88
Oct 29 2015 09:36
```
groups:
add_brooklyn_location:
members: [ mysql_server, tomcat_server ]
policies:
  • brooklyn.location: localhost
Andrea Turli
@andreaturli
Oct 29 2015 09:37
with this add_brooklyn_location each member will be hosted on a new VM, yes?
Jose
@kiuby88
Oct 29 2015 09:38
yes, because the location is added to entitySpec
Andrea Turli
@andreaturli
Oct 29 2015 09:38
actually
groups:
  add_brooklyn_location:
    members: [ mysql_server, tomcat_server ]
    policies:
      brooklyn.location: aws-ec2:eu-west-1
I think this is the case we want to discuss, localhost is not really useful here
Jose
@kiuby88
Oct 29 2015 09:39
I think so
Andrea Turli
@andreaturli
Oct 29 2015 09:40
ok so with this add_brooklyn_location what will happen now?
Jose
@kiuby88
Oct 29 2015 09:40
currently, aws-ec2:eu-west-1 location will be added to each entitySpec
Andrea Turli
@andreaturli
Oct 29 2015 09:40
example?
Jose
@kiuby88
Oct 29 2015 09:41
mysql_server and tomcat_server
Andrea Turli
@andreaturli
Oct 29 2015 09:41
I mean a complete YAML example, please
but this uses localhost
Andrea Turli
@andreaturli
Oct 29 2015 09:43
ok thanks. starting from that yaml, if you replace localhost with aws-ec2 what is the expected behavior? mysql and tomcat on 2 different VMs?
Jose
@kiuby88
Oct 29 2015 09:44
here is
yes, two VM will be created
Andrea Turli
@andreaturli
Oct 29 2015 09:44
ok
Jose
@kiuby88
Oct 29 2015 09:44
because JcloudsLocation will be added to each entityspec
Andrea Turli
@andreaturli
Oct 29 2015 09:44

so you said

we could avoid sameserver property. If a policy contains a node number greater than 1 it will create a SameServer EntitySpec and these nodes will be added as children

Jose
@kiuby88
Oct 29 2015 09:44
and each one will provision its own VM
Andrea Turli
@andreaturli
Oct 29 2015 09:45
I think this should be the default
and that’s why I was suggesting an extra config for the policy sameServer: true
which will instead force all of the members to be installed on the same VM
Jose
@kiuby88
Oct 29 2015 09:49
it is ok for me
Andrea Turli
@andreaturli
Oct 29 2015 09:50
is it so important at this stage?
Jose
@kiuby88
Oct 29 2015 09:51
Yes, It is
Andrea Turli
@andreaturli
Oct 29 2015 09:51
may I ask you why?
Jose
@kiuby88
Oct 29 2015 09:51
of course
Andrea Turli
@andreaturli
Oct 29 2015 09:51
sameServer is a special case in the cloud
Jose
@kiuby88
Oct 29 2015 09:52
I am trying to close the SeaClouds’ use cases
Andrea Turli
@andreaturli
Oct 29 2015 09:52
there is no use case in SeaClouds that requires SameServer
Jose
@kiuby88
Oct 29 2015 09:55
I am not sure. For example, a datacollector will be deployed on the same VM that a server (for example apache + php mod). I mean, they are two different NodeTemplates that should be deployed ont he same VM.
Andrea Turli
@andreaturli
Oct 29 2015 09:56
ah! I see your point. But this is not a usecase requirement, it is an internal requirement
Jose
@kiuby88
Oct 29 2015 10:00
Yes. But, in any case I should manage this point.
Andrea Turli
@andreaturli
Oct 29 2015 10:02
another option is to use something like https://gist.github.com/andreaturli/2e11ef31f993ca2e06c5
where https://gist.github.com/andreaturli/2e11ef31f993ca2e06c5#file-placementpolicy-yaml-L15 could have an additional requirement like sameHost: JBoss6Server
is it possible in TOSCA?
@ahgittin what do you think about it? ^^
Jose
@kiuby88
Oct 29 2015 10:33
Currently, this alternative allows to define the provision properties easily.
Andrea Turli
@andreaturli
Oct 29 2015 10:42
@kiuby88, you mean the second option?
Jose
@kiuby88
Oct 29 2015 10:42
Yes
Andrea Turli
@andreaturli
Oct 29 2015 10:43
does tosca offers this kind of requirement out-of-the-box?
Alex Heneveld
@ahgittin
Oct 29 2015 16:10
hi @andreaturli @/all i’ve commented at https://gist.github.com/andreaturli/2e11ef31f993ca2e06c5
sameserver feels kludgy to me
Andrea Turli
@andreaturli
Oct 29 2015 16:13
Andrea Turli
@andreaturli
Oct 29 2015 16:20
@ahgittin you mean
tosca_definitions_version: tosca_simple_yaml_1_0_0_wd03
description: Custom template
template_name: My App
template_version: 0.1.0-SNAPSHOT

imports:
 - tosca-normative-types:1.0.0.wd03-SNAPSHOT

topology_template:
 node_templates:
   a_server:
     type: tosca.nodes.Compute
     properties:
       mem_size: 4 gb
   script_hello:
     type: tosca.nodes.SoftwareComponent
     requirements:
     - host: a_server
     interfaces:
       Standard:
         create: https://raw.githubusercontent.com/ahgittin/tosca-demo/master/script1/scripts/create.sh
         configure: https://raw.githubusercontent.com/ahgittin/tosca-demo/master/script1/scripts/configure.sh
         start: https://raw.githubusercontent.com/ahgittin/tosca-demo/master/script1/scripts/start.sh
         stop: https://raw.githubusercontent.com/ahgittin/tosca-demo/master/script1/scripts/stop.sh  
   JBoss6Server:
     type: org.apache.brooklyn.entity.webapp.jboss.JBoss6Server
     requirements:
     - host: a_server
   CassandraNode:
     type: org.apache.brooklyn.entity.nosql.cassandra.CassandraNode
     requirements:
     - host: a_server

 groups:
   add_brooklyn_location:
     members: [ a_server ]
     policies:
     - brooklyn.location: aws-ec2:eu-west-1
?
Jose
@kiuby88
Oct 29 2015 16:23
probably, moreover you should another NodeTemplate
a_server:
  type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
Andrea Turli
@andreaturli
Oct 29 2015 16:23
not really, @kiuby88
I think with the above YAML, I’m trying to deploy on 3 a_server provisioned on aws
Jose
@kiuby88
Oct 29 2015 16:24
Sorry Andrea
I did not see
a_server:
     type: tosca.nodes.Compute
     properties:
       mem_size: 4 gb
my fault
Andrea Turli
@andreaturli
Oct 29 2015 16:28
np @kiuby88
;)
Alex Heneveld
@ahgittin
Oct 29 2015 21:02
@andreaturli +1
also i’d always assumed if brooklyn is given an abstract node (e.g. tosca.nodes.Compute) it can at its discretion decide the concrete impl of this — as opposed to A4C needing to replace it with a concrete node (although there’s nothing wrong with the latter either) /cc @nakomis
BTW to me it’s ambiguous whether Compute is a spec for a machine (e.g. possibly in a cloud) — e.g. could JcloudsLocation be a subtype of Compute… and/or would a machine instance e.g. SshMachineLocation and/or EmptySoftwareProcess be a subtype Compute. feels like both could be permitted but they are totally different semantics!