Viewing and Setting Properties

Properties can be set to inform the Compute Software platform of your workload characteristics, performance objectives, and other considerations (full list of Properties in the table below). Properties ensure that your action items are finely tuned and actionable.

Core Concepts

A property is defined by choosing the property name, picking the resources it applies to by assigning a view, and setting the configuration inputs required by the property. Typically, a property affects many resources.

The configuration inputs are determined by the Property’s Name. The resources the configuration inputs affect are determined by the property’s Scope and View. Since multiple properties can exist for the same name, a certain Specificity (more below) is used to decide which property configuration inputs apply to each resource.

Property Names

A property’s name determines what the property does. For example the AWS RDS Idle Resolution Cost property specifies the engineering time and effort, translated into dollars, of deleting an idle RDS instance. All properties have a default value that can be overridden for any view.

Scope and View

The Scope restricts what resources the property could apply to. Certain properties, like AWS RDS Idle Resolution Cost, will only apply to AWS RDS instances and never to AWS EC2 instances, for example. The scopes used are as follows.

Every set property also has an associated view. The view further restricts the set of resources the property affects. The same views you already use can be reused when setting a property. To learn more about views, visit the Views documentation.

Specificity

Specificity is the method by which the platform decides which property value to use for a resource when multiple property values are set for a given property name. For example, say you set the AWS RDS Idle Resolution Cost twice: once for all RDS instances in us-west-2 and once for all RDS instances in AWS Account 123456789. You must have a methodology for deciding which property value to use for the RDS instances that are in both us-west-2 and account 123456789.

How is specificity calculated?

Specificity is a weight given to the property’s view to determine how selective it is. Every view has a specificity weight that can be compared to another view and has a global order. The specificity is computed by the following rules.

1. The number of filter categories selected (more categories is more specific).

2. The rank of the filter categories selected (a higher rank is more specific).

3. The number of filter category options selected for each category (more options selected is less specific).

4. “Tag” filter categories (resource tags and cloud account tags) are sorted lexicographically (earlier is more specific).

Filter Category Ranking

1. Has action items

2. Terraform workspace name

3. Cloud provider

4. Cloud account tags

5. Integration name

6. AWS account ID

7. GCP Project

8. Azure resource group

9. Region

10. AWS VPC ID

11. Resource mode

12. Resource state

13. Service kind

14. Service

15. Instance family

16. AWS EC2 tenancy

17. Resource name contains

18. Resource name ends with

19. Resource name starts with

20. Resource name

21. AWS RDS instance engine

22. Resource tags

23. AWS EC2 platform details

24. AWS EC2 usage operation

25. AWS AMI ID

26. AWS EC2 ID

27. Any platform resource UUID

Examples

View specificity is best understood by comparing two views to see which is more specific. We will walk through some examples for each specificity rule described previously. The examples use a view syntax as following to define each view:

<Filter Category1> = <value1>, <value2>, ..., <valueN>; ... 

1. Filter Category Count

• View1: Region = us-east-1

• View2: Region = us-east-1; AWS Account ID = 123456789

View2 is more specific because it has two filter categories (Region and AWS Account ID) and View1 only has one filter category (Region).

2. Filter Category Rank

• View1: Region = us-east-1

• View2: Service = AWS EC2

View1 and View2 have the same number of filter categories, so we must move to rule 2. Using rule 2, we see View2 is more specific because the Service filter category has a higher rank than the Region filter category.

3. Filter Category Options Selected

• View1: Region = us-east-1, us-west-2

• View2: Region = us-east-1

View1 and View2 have the same number of filter categories, and the same filter category rank, so we must move to rule 3. Using rule 3, we see View2 is more specific because it has less filter category options (1) than View1 (2).

4. Tags

• View1: Resource Tag = team:production

• View2: Resource Tag = environment:production

View1 and View2 have the same number of filter categories, and the same filter category rank, and the same number of filter category options, so we must move to rule 4. View2 is more specific because its tag key (environment) comes before View1’s tag key (team) in a lexicographic sort.

Status

Every Property Name has a Status of either Set or Inherited. If the Property Name is Set, it means the property has configuration inputs set at the current view. An inherited property means the property’s configuration inputs are defined in a less specific view, and the current view is inheriting those configuration inputs.

Getting Started

To create your first property, log into the Compute Software platform and navigate to the Properties section.

1. Determine the property you would like to set by scanning the All Properties table, and click the link on the property’s name. For this example, we will configure the AWS EC2 Minimum IOPS property.

2. On the property page for AWS EC2 Minimum IOPS, click the radio button for “Set Property.” By default, this property is set to a minimum IOPS of 0, meaning we have no minimum. Changing from “Inherit Property” to “Set Property” means that we will be setting this minimum IOPS property for all resources in the Affected Resources section.

3. In the “Notes” field, we can optionally fill out a reason for setting this property. It is highly recommended to add notes of you or other users to reference later. For this example, we’re increasing the minimum IOPS to 10,000 since this application performs a lot of I/O.

4. You’ll notice that the Save button is currently disabled. We cannot save a property in a predefined or Unsaved view, and we are currently in the predefined “All Accounts” view. We need to create a new view that matches the resources that require 10,000 IOPS. Toggle the Filters UI and select the filters necessary. In this case, we know all of the instances in our AWS account with the ID “111111111111” require 10,000 IOPS.

5. Click “Save as new view” and give the view a name. Click “Save View.”

6. The application will automatically update your current view to the newly saved view, and the “Save” button will become clickable.

7. Prior to saving the property, we first inspect the resource that will be affected by adding this property.

8. Everything looks as expected, so we click the “Save” button. The property is now set.

Properties Available

The following properties are available.

Existing Properties

Every property that has been explicitly set by a platform user can be seen in the “Set Properties” table. Clicking the platform name will take you to that property’s view and page. Clicking the view will navigate you to the view that property uses.

Resource Properties

Every platform resource will have some number of properties that get applied to it. You can discover the current properties applying to a resource by navigating to the Resources tab, opening a resource drawer, and clicking the Properties tab. The properties displayed will be the most recent properties set for that resource.