Just to complete Andrew's answer, there is also the SecurityGroupExtension
for the ComputeService.
It is still a WIP, but several providers already implement it. The idea is
that all providers with firewall features will implement it, so it will be
a common/portable interface to manage firewalls.
You can get it as an Optional reference from the ComputeService, and it
will be present if the underlying provider supports it.
HTH!
I.
El 08/12/2013 23:31, "Andrew Phillips" <aphill...@qrmedia.com> escribió:
> Quoting "ssiv...@gmail.com" <ssiv...@gmail.com>:
>
> Hi all!
>> Sorry guys, I'll duplicate my question posted on the #jclouds.
>> Is there an uniform way to add node firewall settings via compute
>> service? Or it's too specific for each provider so I need to you
>> provider API directly? I'm a little bit confused in concepts and
>> terminology.
>>
>
> Hopefully, we can achieve what you're looking to do without going entirely
> "over to the provider side" ;-)
>
> Roughly, speaking, there are three levels of abstraction possible here:
>
> 1) Portable ComputeService with portable TemplateOptions [1]
>
> Here, we're calling the "standard" ComputeService and specifying only
> those options exposed by the "standard" TemplateOptions builder. This
> should allow our requests to run across multiple clouds.
>
> 2) Portable ComputeService with provider-specific TemplateOptions
>
> Here, we're again calling the standard ComputeService but are adding some
> provider-specific options to the template, by casting it appropriately,
> e.g. [2, 3]. This introduces a small dependency on the provider, but still
> shields us from the complexity of dealing with the underlying provider API.
>
> 3) Provider-specific API
>
> Here, we deal directly with the provider API, making requests for nodes
> using provider-specific calls with provider-specific options. So we
> probably won't even be using the TemplateOptions here (since they come from
> the portable ComputeService layer).
>
> This gives us the most flexibility in dealing with a specific provider,
> but obviously also introduces the tightest coupling *to* that provider.
>
> In our case, I hope option 2) will be sufficient, but you'll have to have
> a look at EC2TemplateOptions or AWSEC2TemplateOptions (if we're talking AWS
> here) to verify that.
>
> On a separate note: which parts of the terminology ("api", "provider",
> "view", other..?) are you having difficulties understanding? Sounds like a
> good candidate for a documentation update.
>
> Hope this helps!
>
> ap
>
> [1] http://javadocs.jclouds.cloudbees.net/org/jclouds/compute/options/
> TemplateOptions.Builder.html
> [2] http://javadocs.jclouds.cloudbees.net/org/jclouds/aws/ec2/compute/
> AWSEC2TemplateOptions.Builder.html
> [3] https://github.com/jclouds/jclouds-examples/blob/master/
> ec2-computeservice-spot/src/main/java/org/jclouds/
> examples/ec2/spot/MainApp.java#L78
>
