---
# System prepended metadata

title: Recipe Contract Notes 11/19/2020
tags: [New Relic]

---

###### tags: `New Relic`

# Recipe Contract Notes 11/19/2020

## Distro

Our first iteration stresses the importance of distro based on how we've defined the folder structure of recipes. In the current design we need to do this to support different installation paths for OHI's/Infra-agent.

Outside of the OHI/Infra-agent use-case, this would support 3rd-party/contributors to write recipes that have distro/version/flavor/family/<foo-type>-specific requirements.

## Take Aways

1. Not all Linux recipes care about distro
1. Not all Windows recipes will care about Windows version
1. Paths for contract
  a. Discover distro in cli and pass it as optional field to recipeSearch() or recommendations()
    1. Pro - More rigid, more predictable
    1. Con - More logic in the newrelic-cli
  b. Pass data in the form of key/value pairs, expand recipe schema to include `searchExpression` or `filterExpression`
    1. Pro - More flexible
    1. Con - hard(er) for a user looking at the schema to understand how to get recipes
1. Recipe - be able to define what data it cares about. newrelic-cli would pass to service. Iteratively pass more and more data to the recipe service, each iteration runs another recipe that yields more information.
1. What is a recipe? Better definition
1. recipeSearch() would be full list based on filtering, recommendations() would be more restrictive, demanding more information up front to ensure we return valid/useful recipes.

## Raw Notes

1. newrelic-cli asks for operatingSystemType recipe or one overarching recipe (WINDOWS, DARWIN, LINUX)
2. First recipe figures out distro
3. Chains or triggers a 2nd newrelic-cli call for recipes but now with the distro

1. Recipe declares data it cares about

Recipe:
```yaml
tags:
  VERSION_CODENAME: 1.0.0
```

2. newrelic-cli -> recipeSearchCriteria(<tags from the cli attempting host info>)
3. Find match in recipes with matching tags


input RecipeSearchCriteria {
  name: String
  platform: Platform
}

type Platform {
  systemType: OS_TYPE

  # Pass all, or filter down to ones we carry about
  properties: [KeyValueType]

  properties: [NameSpaceValueType]

  # properties: OsProperties
}

type NameSpaceValueType {
  
  # Examples:
  # - from cat etc/os_release, converting to array of key/value pairs

  # - rpm -E %{rhel}

  # PS C:\Users\julie> systeminfo /fo csv | ConvertFrom-Csv | select OS*, System*, Hotfix* | Format-List 
  # key: "OS Name" value: "Microsoft Windows 10 Pro"

  namespace: String
  value: [KeyValueType]
}

# type OsProperties {
#   distro: String
#   version: String
# }

type KeyValueType {
  key: String
  value: String
}

enum OS_TYPE {
  WINDOWS
  DARWIN
  LINUX
}

input VariantInput {
  os: String
  targetEnvironment: String
}