You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by "ssivikt@gmail.com" <ss...@gmail.com> on 2013/12/08 12:27:33 UTC
Setup Firewall (Security groups) via compute service
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.
Thank you.
Re: Setup Firewall (Security groups) via compute service
Posted by Ignasi Barrera <ig...@gmail.com>.
Yes, it makes perfect sense.
The SecurityGroupExtension defines the "listSecurityGroupsForNode"
method. You could call it to get the security groups for an existing
node, and then use the extension to modify the desired ones.
[1] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/extensions/SecurityGroupExtension.java#L56
On 9 December 2013 13:02, ssivikt@gmail.com <ss...@gmail.com> wrote:
> Thank you too!
> SecurityGroupExtension seems to be more unified then the TemplateOptions
> extensions but it's still unclear how to link a certain rules to a specific
> network or node.
>
> ComputeService allows us to create nodes. But what if I want just to update
> an existing entity? Does it make any sense? E.g. if I'll create node using
> Template and TemplateOptions as a node specification than to change node's
> firewall settings I need to recreate the node. Or I'm wrong..
>
>
> On 12/09/2013 02:04 AM, Ignasi Barrera wrote:
>>
>> 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!
>>
>
Re: Setup Firewall (Security groups) via compute service
Posted by "ssivikt@gmail.com" <ss...@gmail.com>.
Thank you too!
SecurityGroupExtension seems to be more unified then the TemplateOptions
extensions but it's still unclear how to link a certain rules to a
specific network or node.
ComputeService allows us to create nodes. But what if I want just to
update an existing entity? Does it make any sense? E.g. if I'll create
node using Template and TemplateOptions as a node specification than to
change node's firewall settings I need to recreate the node. Or I'm wrong..
On 12/09/2013 02:04 AM, Ignasi Barrera wrote:
> 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!
>
Re: Setup Firewall (Security groups) via compute service
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Just to complete Andrew's answer, there is also the SecurityGroupExtension
> for the ComputeService.
Thanks for clarifying that, Ignasi! Learned something new again ;-)
Note that this extension is in beta and is only available on
1.7.0-SNAPSHOT [1].
ap
[1]
https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/ComputeService.java#L394
Re: Setup Firewall (Security groups) via compute service
Posted by Ignasi Barrera <ig...@gmail.com>.
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" <ap...@qrmedia.com> escribió:
> Quoting "ssivikt@gmail.com" <ss...@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
>
Re: Setup Firewall (Security groups) via compute service
Posted by "ssivikt@gmail.com" <ss...@gmail.com>.
Andrew, Ignasi, thank you very much for your time! It helps :)
Re: Setup Firewall (Security groups) via compute service
Posted by Andrew Phillips <ap...@qrmedia.com>.
> create own data centers). What's Context and how does it correlate to
> View (seems Context aims to provide the basic abstraction layer to the
> whole cloud provider features).
As regards this: you're looking at a transitional phase, which
unfortunately complicates things a bit ;-)
As described in the ContextBuilder Javadoc [1], there are basically
two things you can work with in jclouds: a specific API, or a portable
View. As explained in the Javadoc, the relationship can be
one-to-many: some APIs support both blobstore as well as compute
functionality, for example. But in most cases, the link is one-to-one.
When you use a context builder to get an *instance* of an API, it is
wrapped in a context object that basically represents this
instantiation. The "new style" is to use the ApiContext [2], but users
will not often see that as the encouraged style is to use the
ContextBuilder to go straight to the API object via
ContextBuilder.buildApi [3]. Users can still get at the context object
through ContextBuilder.build [4] if they really want to, though.
Which context a particular type of API should use is indicated by the
ApiMetadata, by the way [5].
Now to Views. First, the views that a given API supports are also
determined by the ApiMetadata [6, 7]. To get a view rather than an API
object, users should call ContextBuilder.buildView [8], specifying the
view type desired. Obviously, the system will complain if the view
type is not one of the ones declared in the metadata.
Because views provide an abstraction layer, there is sometimes the
need to get back to the underlying API in order to do API- or
provider-specific stuff (your choice: if you know you're talking at
AWS EC2 through a ComputeServiceContext, you can decide to get just
the generic EC2Api, or the provider-specific AWSEC2Api). This is
achieved using View.unwrapApi [9] to get the API object, or
View.unwrap if you really want the context object (so View.unwrapApi
and View.unwrap basically mirror ContextBuilder.buildApi vs.
ContextBuilder.build).
If all this was clear already, great, and apologies for the
repetition. Otherwise, hope this helps!
ap
[1] http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html
[2] http://javadocs.jclouds.cloudbees.net/org/jclouds/rest/ApiContext.html
[3]
http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html#buildApi(java.lang.Class)
[4]
http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html#build(com.google.common.reflect.TypeToken)
[5]
http://javadocs.jclouds.cloudbees.net/org/jclouds/apis/ApiMetadata.html#getContext()
[6]
http://javadocs.jclouds.cloudbees.net/org/jclouds/apis/ApiMetadata.html#getViews()
[7]
https://github.com/jclouds/jclouds/blob/master/apis/atmos/src/main/java/org/jclouds/atmos/AtmosApiMetadata.java#L87
[8]
http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html#buildView(java.lang.Class)
[9]
http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html#unwrapApi(java.lang.Class)
[10]
http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html#unwrap(com.google.common.reflect.TypeToken)
Re: Setup Firewall (Security groups) via compute service
Posted by "ssivikt@gmail.com" <ss...@gmail.com>.
Thank you! It was very informative and helpful.
> 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.
As for now I'm trying to figure out Location concepts: what is region,
zone, data center, availability zone, host and so on. How to dynamically
extend available Locations list (in case if user is able to create own
data centers). What's Context and how does it correlate to View (seems
Context aims to provide the basic abstraction layer to the whole cloud
provider features).
Digging down through the code helps to find relations between concepts.
So, time to time, between this and then, I'm on that way :)
Re: Setup Firewall (Security groups) via compute service
Posted by Andrew Phillips <ap...@qrmedia.com>.
Quoting "ssivikt@gmail.com" <ss...@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