Ohai cloud network enhancements

[mattray]

Proposed updates to the network plugin to handle networks not named 'public' or 'private'.

[caryp]

While not all IaaS platforms support multiple named networks, we are seeing more advanced networking options being offered and evolving. I think this proposal helps support custom networking moving forward. For example: I may have a third high-bandwidth "backup" network on openstack that is different than the "local" network and a similar setup in my EC2 VPN with an elastic network interface and I want my recipe to work on both clouds without it needing to traverse the cloud-specific plugins/attributes. This change could support this.

That being said, my original intention for the cloud plugin is to enable users to write recipes that are cloud agnostic. So I think we should consider keeping the "public" and "local" network namespaces as the defaults that should be populated -- if applicable. While it is not guaranteed to always work on every cloud, for many years I have used these namespace to write cookbooks that work successfully across many public and private clouds. For example: if I need a public facing IP for my webserver -- look here; if I need something for local replication -- look here.

I currently have a proposal for a cloud_v2 plugin open. Perhaps we can apply support for network namespaces to this change?

[caryp]

Question:

• node['cloud']['networks']['NAME_OR_ID']['associated'] : would this be a list of both IPv4 and IPv6 addresses? Does it make sense to separate it into something like associated_ipv4 and `associated_ipv6?

A couple specific changes I recommend are:

• node['cloud']['networks']['local'] is to be populated as a collection of all discovered IP addresses for the node that adhere to the Address Allocation for Private Networks (RFC 1918)
• node['cloud']['networks']['public'] is to be populated as a collection of all discovered IP addresses for the node that don't fall under the Address Allocation for Private Networks (RFC 1918)

Thoughts?

[mattray]

I like the associated_ipv4/6 suggestion, I'll add that shortly.

For the RFC 1918 values, there are already node['cloud']['public_ips'] and node['cloud']['private_ips'] attributes from Ohai's existing cloud plugin, I think I'm inclined to keep that there and leave the node['cloud']['networks']['NAME_OR_ID'] auto-populated by iterating over the server's networks. It's quite possible the 'private' network returned by an API isn't adhering to RFC 1918, but when I look in node['cloud']['networks']['private'] I would still expect to find the API values.
https://github.com/opscode/ohai/blob/6-stable/lib/ohai/plugins/cloud.rb#L31

There's lots of interesting choices in the existing cloud plugin, but right now there's a gap in listing networks. We will extend the existing cloud plugin initially, then go back and try to clean it up where it's redundant or wrong.

[caryp]

I think extending what exists in node[:cloud] makes sense for filling the networks gap in the short term. We can push forward in cleaning up what is redundant or wrong possibly in node[:cloud_v2]

[nathenharvey]

This PR is currently on the agenda for our next IRC developers' meeting.

Please let me know if it gets merged or otherwise closed before then so that the agenda can be updated.

Thanks!

[nathenharvey]

@mattray can you please add the appropriate copyright notice to this RFC before our meeting tomorrow?

## Copyright

This work is in the public domain. In jurisdictions that do not allow for this,
this work is available under CC0. To the extent possible under law, the person
who associated CC0 with this work has waived all copyright and related or
neighboring rights to this work.

[lamont-granquist]

👍

[thommay]

👍

[jonlives]

@chef/rfc-editors this is approved for merge once @mattray removes the line regarding Ohai 8

[ranjib]

👍

[btm]

👍 given no breaking changes which I incorrectly inferred from the note about Ohai 8.

[martinb3]

👍 we end up using something similar for node['rackspace']['private_networks'][0...i]['label'] from the Rackspace Ohai data. It would be useful to have it across all cloud providers so we could write more reusable library cookbooks that supported labelled interfaces.

[caryp]

nice!

[mattray]

@chef/rfc-editors @jonlives @btm requested change made.

[btm]

We acknowledge the change was made at today's IRC meeting :).

We will merge this.

[btm]

rebased into d078167, merged into master and accepted as RFC046.