Closed ashcrow closed 8 years ago
Just asking: is there some reason why network options needs to be split out as a separate JSON object? Seems like address
and any other options could sit alongside name
and type
without conflict. If it's just convention that's fine; no strong opinion.
Just asking: is there some reason why network options needs to be split out as a separate JSON object? Seems like address and any other options could sit alongside name and type without conflict. If it's just convention that's fine; no strong opinion.
At this point it would be fine to have address
sit along side but if/when other networks are added I believe they will end up taking vastly different options. Instead of trying to guess them I went with a fuzzy json object.
At this point it would be fine to have address sit along side but if/when other networks are added I believe they will end up taking vastly different options. Instead of trying to guess them I went with a fuzzy json object.
Makes sense. On further thought, probably better practice to keep the static and variant parts separate (as you have it).
:arrow_up:
Nice. :+1:
@rh-atomic-bot r+
:pushpin: Commit 1166295 has been approved by mbarnes
:hourglass: Testing commit 1166295 with merge b91267b...
What is up with homu lately? I'll merge manually.
Squashed locally, retested and pushed to master
.
This adds support for using flannel in client-server mode. For more information please see https://github.com/coreos/flannel/blob/master/Documentation/client-server.md
The following endpoints have been added:
A network is defined via a name, type, and options.
Example: