You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parsing ip output is error prone and provides lot of unnecessary duplication. All the data that is necessary to configure should be (and in fact is) provided by means of droplet metadata, exposed via convenient REST API.
eth0_ip4s=$(ip address show dev "$eth0_name" | grep 'inet ' | sed -r 's|.*inet ([0-9.]+)/([0-9]+).*|{ address="\1"; prefixLength=\2; }|')
eth0_ip6s=$(ip address show dev "$eth0_name" | grep 'inet6 ' | sed -r 's|.*inet6 ([0-9a-f:]+)/([0-9]+).*|{ address="\1"; prefixLength=\2; }|' || '')
I'd accept a PR for this, as long as it falls back to parsing ip address output, so that non-DigitialOcean systems still work, although I'm not really convinced the parsing is any more error-prone than using a ReST API, my reasoning being that ip address output is always going to be there and probably never going to change format, whereas a hardcoded host address and path could very well change or fail in some novel way.
The lines could otherwise be beautified by using a few bash functions that call each other.
Parsing
ip
output is error prone and provides lot of unnecessary duplication. All the data that is necessary to configure should be (and in fact is) provided by means of droplet metadata, exposed via convenient REST API.Existence and lack of specific keys gives one great inspection abilities with minimal effort.
The
interfaces
endpoint contains precise information on amount and intention of interfaces:The text was updated successfully, but these errors were encountered: