You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by "Aled Sage (JIRA)" <ji...@apache.org> on 2017/04/27 16:48:04 UTC

[jira] [Commented] (BROOKLYN-398) Provisioning property minRam not dealt with correctly

    [ https://issues.apache.org/jira/browse/BROOKLYN-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986998#comment-15986998 ] 

Aled Sage commented on BROOKLYN-398:
------------------------------------

[~drigodwin] I can't reproduce this in {{aws-ec2:us-east-1}}.

I tried using:
{noformat}
location:
  jclouds:aws-ec2:us-east-1:
    minRam: 2gb
services:
- type: server
{noformat}

It translated this to {{minRam: 2000}}, and chose {{m3.medium}}:
{noformat}
2017-04-27 17:29:47,433 DEBUG o.a.b.l.j.JcloudsLocation [brooklyn-execmanager-eUBet91C-3]: jclouds using templateBuilder PortableTemplateBuilder[ports=[22], locationId=us-east-1, imageChooserFunction=org.apache.brooklyn.location.jcl
ouds.BrooklynImageChooser$ImageChooserFromOrdering, minRam=2000] for provisioning in JcloudsLocation[AWS Virginia:AKIAI2WAOFFAPVI5SQEQ@qox5xwt4eh] for aws-ec2:us-east-1@EmptySoftwareProcessImpl{id=j36nt2q1gx}
2017-04-27 17:29:47,434 DEBUG jclouds.compute [brooklyn-execmanager-eUBet91C-3]: >> searching params({imageChooser=org.apache.brooklyn.location.jclouds.BrooklynImageChooser$ImageChooserFromOrdering, locationId=us-east-1, minRam=2000
, minRam=2000})

2017-04-27 17:29:47,664 DEBUG o.a.b.l.j.JcloudsLocation [brooklyn-execmanager-eUBet91C-3]: jclouds using template {image={id=us-east-1/ami-5492ba3c, providerId=ami-5492ba3c, name=RightImage_CentOS_7.0_x64_v14.2.1_HVM_EBS, location={
scope=REGION, id=us-east-1, description=us-east-1, parent=aws-ec2, iso3166Codes=[US-VA]}, os={family=centos, arch=hvm, version=7.0, description=411009282317/RightImage_CentOS_7.0_x64_v14.2.1_HVM_EBS, is64Bit=true}, description=Right
Image_CentOS_7.0_x64_v14.2.1_HVM_EBS, version=14.2.1_HVM_EBS, status=AVAILABLE[available], loginUser=root, userMetadata={owner=411009282317, rootDeviceType=ebs, virtualizationType=hvm, hypervisor=xen}}, hardware={id=m3.medium, provi
derId=m3.medium, processors=[{cores=1.0, speed=3.0}], ram=3840, volumes=[{type=LOCAL, size=10.0, device=/dev/sda1, bootDevice=true, durable=false}, {type=LOCAL, size=4.0, device=/dev/sdb, bootDevice=false, durable=false}], supportsI
mage=Predicates.and(Predicates.alwaysTrue(),Predicates.or(requiresVirtualizationType(hvm),requiresVirtualizationType(paravirtual)),Predicates.alwaysTrue(),Predicates.alwaysTrue())}, location={scope=REGION, id=us-east-1, description=
us-east-1, parent=aws-ec2, iso3166Codes=[US-VA]}, options={scriptPresent=true, userMetadata={Name=brooklyn-op2ttn-aledsage-applicationid-id26-server-j36n-wkhz, brooklyn-user=aledsage, brooklyn-app-id=id26gv8u4o, brooklyn-app-name=Ap
plication (id26gv8u4o), brooklyn-entity-id=j36nt2q1gx, brooklyn-entity-name=Server, brooklyn-server-creation-date=2017-04-27-1729}, userDataCksum=2f4a740b}} / options {scriptPresent=true, userMetadata={Name=brooklyn-op2ttn-aledsage-
applicationid-id26-server-j36n-wkhz, brooklyn-user=aledsage, brooklyn-app-id=id26gv8u4o, brooklyn-app-name=Application (id26gv8u4o), brooklyn-entity-id=j36nt2q1gx, brooklyn-entity-name=Server, brooklyn-server-creation-date=2017-04-2
7-1729}, userDataCksum=2f4a740b} to provision machine in aws-ec2:us-east-1@EmptySoftwareProcessImpl{id=j36nt2q1gx}
{noformat}

When I used {{minRam: 2000}} I got the same behaviour: it chose {{m3.medium}}.

Looking at the output of {{./bin/brooklyn cloud-compute list-hardware-profiles --location jclouds:aws-ec2:us-east-1}} I confirm that {{m3.medium}} has {{ram=3840}}. It could have instead chosen {{t2.small}} (with {{ram=2048}}:
{noformat}
		{id=t2.small, providerId=t2.small, processors=[{cores=1.0, speed=0.2}], ram=2048, supportsImage=Predicates.and(requiresRootDeviceType(ebs),requiresVirtualizationType(hvm),Predicates.alwaysTrue(),Predicates.alwaysTrue())}
		{id=m3.medium, providerId=m3.medium, processors=[{cores=1.0, speed=3.0}], ram=3840, volumes=[{type=LOCAL, size=10.0, device=/dev/sda1, bootDevice=true, durable=false}, {type=LOCAL, size=4.0, device=/dev/sdb, bootDevice=false, durable=false}], supportsImage=Predicates.and(Predicates.alwaysTrue(),Predicates.or(requiresVirtualizationType(hvm),requiresVirtualizationType(paravirtual)),Predicates.alwaysTrue(),Predicates.alwaysTrue())}
{noformat}

The choice of image was:
{noformat}
	Image us-east-1/ami-5492ba3c {
		{id=us-east-1/ami-5492ba3c, providerId=ami-5492ba3c, name=RightImage_CentOS_7.0_x64_v14.2.1_HVM_EBS, location={scope=REGION, id=us-east-1, description=us-east-1, parent=aws-ec2, iso3166Codes=[US-VA]}, os={family=centos, arch=hvm, version=7.0, description=411009282317/RightImage_CentOS_7.0_x64_v14.2.1_HVM_EBS, is64Bit=true}, description=RightImage_CentOS_7.0_x64_v14.2.1_HVM_EBS, version=14.2.1_HVM_EBS, status=AVAILABLE[available], loginUser=root, userMetadata={owner=411009282317, rootDeviceType=ebs, virtualizationType=hvm, hypervisor=xen}}
	}
{noformat}

I'm going to close this issue because with 0.11.0-rc2, the 2gb and 2000 behave the same.

If you think it's behaving wrong (e.g. should have chosen {{t2.small}}) then could you please raise a bug in jclouds, as we pass this info straight through to let jclouds choose the most appropriate hardwareId.

> Provisioning property minRam not dealt with correctly
> -----------------------------------------------------
>
>                 Key: BROOKLYN-398
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-398
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Duncan Godwin
>             Fix For: 0.11.0
>
>
> When launching a VM, and a provisioning property of {{minRam: 2gb}} is set, a machine with 4gb is provisioned. When {{minRam: 2000}} is set, a machine with 2gb is provisioned.
> [This line|https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L1272] indicates that both should launch a machine with 2gb of ram but this appears to not be the case.
> Tested on openstack and AWS.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)