@andreaturli I've addressed your comments and added a method to allow binding
an existing public ip, which is also convenient. Something like:
`IpOptions.builder().subnet(subnet1).publicIpId("pub-ip-id").build()`. I've
also fixed a couple race conditions when creating security groups; the jclouds
code did not wait until they were in provisioning state "Succeeded".
Regarding your comments:
>don't we need to deprecate subnetId and virtualNetworkName before removing
>them, maybe?
We don't do that in labs. Labs is a place to experiment with the providers, get
familiar with their APIs and best practices. if we kept backwards compatibility
there we wouldn't be able to never move forward with the development of new
providers.
>with the second option options.networks(subnetId2, subnetId2, ...); how the
>nodes will get a public IP?
It doesn't. If you are explicit about network configuration you also need to be
explicit about public IPs. That method exists to properly implement the
portable options, but portability has limitations. If you need more fine
grained control you need to use the provider-specific ones. (Also take into
account that when building nodes in concrete subnets only the gateway one is
likely to have an ip address, so I think it is a good compromise for the
portable abstraction).
>as a broader discussion, I really think we are pushing jclouds compute to the
>limit: it's original ability to manage nodes nowadays requires a lot of
>networking resource to be created "around" the node before the provisioning
>can happen. I wonder if it's time for a jclouds network abstraction where
>jclouds can manage concepts like vpc, subnets, security groups so the jclouds
>compute abstraction can then consume those resources created in a portable
>way. Of course this is well beyond the scope of this PR, but I'd like to know
>your thoughts on that.
Absolutely. We should file a story in JIRA and create a page in the wiki to
define how we want it to look like, by looking at how the different major
providers implement networking, what they offer and what we want to cover.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/386#issuecomment-297668892
