@@ -41,7 +41,7 @@ Do all this inside the virtual environment.
*Note: update IP address in the request to your own where you're running WFO.*
**Creating subscriptions** (look at the `initial_input_form_generator` method of the workflow to find what properties need to be passed in the data of the POST request)
**Creating subscriptions** (look at the `initial_input_form_generator` method of the workflow to find what properties need to be in the body of the POST request)
Create process that produces a new subscription (CREATE workflow)
@@ -18,19 +18,19 @@ The following kind of configuration file needs to be exported in the variable `O
Either a non-empty list of `networks` or a non-empty list of `containers` is required in the params file per service type. Having both is redundant, but in that case containers take precedence. The `mask` parameter is irrelevant if the service type uses networks instead of containers.
### Host/network allocation
Hosts can be allocated through `ipam.new_service_host()` resulting in a host record (IPv4, IPv6, A, AAAA) and zero or more cname records. This function can be called by passing domain name, hostname, and service type (mandatory). Optinally, you can pass either ipv4/ipv6 addresses, ipv4/ipv6 networks, or nothing. Passing nothing is considered default. In that case:
Hosts can be allocated through `ipam.new_service_host()` resulting in a host record (IPv4, IPv6, A, AAAA) and zero or more CNAME records. This function can be called by passing domain name, hostname, and service type (mandatory). Optinally, you can pass either ipv4/ipv6 addresses, ipv4/ipv6 networks, or nothing. Passing nothing is considered default. In that case:
- If the service type has any container specified in the params file, networks have to be allocated before allocating hosts (through `ipam.new_service_networks()`). The mask parameter is used to create the new networks. Containers are filled up in the order that they appear in the params file.
- If the service type has any network specified in the params file, those networks are used directly to allocate hosts. Networks are filled up in the order that they appear in the params file.
If you pass addresses or networks, the module will always attempt to use those, but will fail if they don't match the configuration in the params file for the service type (i.e. if you request an address or network that places outside of the configured containers/networks).
If you pass addresses or networks, the module will always attempt to use those, but will fail if they don't match the configuration in the params file for the service type (that is, if you request an address or network that places outside of the configured containers/networks).
Networks and hosts can be allocated with extensible attributes. Networks can be created with a comment. CNAME records can be optionally created.
Networks and hosts can be allocated with extendable attributes. Networks can be created with a comment. CNAME records can be optionally created.
### Host/network deletion
The code checks that the resource you are trying to delete is allocated (in terms of IP address space) to the service as per`containers` or `networks` in the service's configuration. If not, you are not allowed to delete it.
The code checks that the resource you are trying to delete is allocated (in terms of IP address space) to the service through`containers` or `networks` in the service's configuration. If not, you aren't allowed to delete it.
No host or cname records are deleted via the `delete_service_host()` function until all passed arguments match the hostname, IP, and CNAME data of the host. If anything doesn't match, no record is deleted.
No host or CNAME records are deleted via the `delete_service_host()` function until all passed arguments match the hostname, IP, and CNAME data of the host. If anything doesn't match, no record is deleted.
### Usage examples
...
...
@@ -43,7 +43,7 @@ In this example:
- Host hA for service TRUNK uses a specific ipv4/ipv6 address pair.
- Host hB for service TRUNK uses the ipv4/ipv6 network pair.
Because TRUNK has configured containers rather than networks, `new_service_networks()` must be called first to create a network for the hA-hB TRUNK. This is not needed for LO, which automatically uses the first configured network with available space to allocate new hosts.
Because TRUNK has configured containers rather than networks, `new_service_networks()` must be called first to create a network for the hA-hB TRUNK. This isn't needed for LO, which automatically uses the first configured network with available space to allocate new hosts.
