Project

General

Profile

Actions

Bug #1517

closed

Order dependent, ambiguous YAML in multi-detect.

Added by Jason Ish over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Both the tenants and mappings section of multi-detect contain problematic YAML.

For tenants we have:

1. multi-detect:
2.   tenants:
3.   - tenant:
4.     id: 1
5.     yaml: somefile.yaml

It is unclear if the "tenant" on line 2 is supposed to be a key with an empty value, or be the parent of "id" and "yaml", which would actually look like:

1. multi-detect:
2.   tenants:
3.   - tenant:
4.       id: 1
5.       yaml: somefile.yaml

It is also order dependent, for example the following will fail:

1. multi-detect:
2.   tenants:
3.   - id: 1
4      tenant:
5.     yaml: somefile.yaml

Despite being equivalent when it comes to YAML.

Question: Is the "tenant" keyword necessary here? Could we not just have:

1. multi-detect:
2.   tenants:
3.   - id: 1
4.     yaml: somefile.yaml

Since it is expected that each item in the sequence should be a tenant. Or is the plan to have multiple kinds of tenants? In which case we should probably have a "type" field denoting the type of tenant.

The mappings fields has all the same issues. As the "selector" tells us what the mappings are selecting on, we could probably get by with:

multi-detect:
  selector: vlan

  mappings:
  - vlan-id: 1000
    tenant-id: 1

Then when processing the list of mappings, fail if vlan-id is not found. Similarly if a future subnet selector was added, we would fail when handling the list of mappings if a subnet keyword wasn't present. Such a change would make the YAML order independent.

Actions

Also available in: Atom PDF