Hi Moritz,
Nobody else seems to have
ideas on that or nobody else seems to be interested in g-Eclipse. Great, so let’s
do it our way without taking care about the others ;-)
So maybe we are going
into deeper waters now …
What do we want to implement?
1)
Security Groups
2)
Key Pairs
3)
Elastic IPs
What is there within (g-)Eclipse?
a)
Project Folders
b)
Resource Categories
c)
Views
d)
Preferences
e)
Properties
f)
Editors
So now the prize question
is how could a mapping look like?
Going more into detail
about g-Eclipse …
a)
are thought to be containers of local (or at least “virtually
local” like the connections) resources that may be applied to remote
resources
b)
are thought to be containers of real remote resources
c+d+e+f) not specified further within this context
Now the EC2 side …
1)
Are these remote? I mean
is there also a remote pool where these are stored? For me it looks like these
are editable items. So why not having a simple editor for them. If they are
indeed remote, why not having a dedicated EFS implementation that accesses the
security group pool and lists the
groups as children? Double-clicking these children would open the editor, editing,
saving back, isn’t that the lilfecycle of the security group management?
2)
The auth token view is not used for authentication! It is used for creating
and managing
authentication tokens!!! Authentication is done with the auth token providers.
Since we are talking about creating and
managing key pairs we are talking
about creating and managing auth tokens. So this is what the auth token
view is intended to do. Do not duplicate functionality here somewhere else,
just use what is there and if
necessary enhance the existing functionality.
3)
The elastic IP is in fact a property of your running instance, right? So you should handle
it as such. Nevertheless here we are talking about a real remote pool of elastic
IPs, therefore I would suggest to put these under the VO subtree.
Please do not try to put
everything now under the VO subtree. I know this is possible now. Nevertheless
we should keep things in sync as much as possible. We always claim that
g-Eclipse nearly looks the same for any
middleware/Grid, now do not prove the contradictory.
So when speaking about
the project structure for AWS I could think about something like this:
AWS Project
+ Connections
| +Security Group
Pool
| + group1
| +
group2
+ AWS VO
+
Computing
+ Services
| + Images
| +
Elastic IPs
+ Storage
I know that Images and Elastic IPs are not services in the Grid sense.
Nevertheless I think they fit under the services branch.
I may also be completely wrong with my assumptions. If this is the case please
correct me J
Mathias
Von: geclipse-dev-bounces@xxxxxxxxxxx
[mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im
Auftrag
von Moritz Post
Gesendet: Donnerstag, 19. Juni
2008 12:53
An: Developer
mailing list
Betreff: Re: AW: AW:
[geclipse-dev] Supporting AWS infrastructure in g-Eclipse
Hi Mathias
Thanks for the details, let’s
go through them …
=== Security Groups ===
The actions of the view allow to add/remove security groups, which are than shown in the list to the top of
the view. Each security group can than be selected to add and remove entries in its
permission list (context menu).
Are these security groups specific for an AMI or a running instance? In any case, how about a properties
page within the properties dialog? Of course a view could do it as well …
but you know we already have a lot of views.
These security groups are completely decoupled from an AMI or a running instance.
They are attached when launching an
AMI but their management is
independent.
I think, due to the new category based VO subfolder layout, we could also
create a folder structure like this:
AWS VO
\-- Instances
\-- Images
\-- Security Groups
\-- my security group
\-- another
security group
\-- Storage
To add a security group you would rightclick on "Security Group" and choose "Add Security Group". Is it
possible to attach actions to a Category? On a particular security group you
could than add an action to display the properties in some kind of
dialog to edit the rules in a table form similar to the one in the screenshot.
Also you could display the details of the security group in the properties
dialog.
=== Keypairs ===
You add/remove keypairs via the views actions.To add a keypair you choose a
name for the keypair and
a local file to save the generated private key to. This keypair is also
the one you specify in the launch dialog if you want to login without a password.
This is clearly an authentication token, right?! So
we should implement it as such.
It seams like it, but it is not really used as such.
When you create one you are given a pk file. You specify the name of the
keypair in the launch dialog and
when the instance is running,
you insert the ok file in the SSH2 preferences to login to an EC2 instance.
so you don't make use of it in the context of geclipse.
Also... It could be an
authentication token but that would mean,
that you would need to create an
authentication token (AWSToken) to create a keypair token. You would need to
fetch the keypair name.
This scenario feels kind of awkward since you would create a token but not use
it for authentication.
A possibility would be to make an
entry at the AWS VO subfolder.
=== Elastiv IPs ===
In this view you can
allocate an
address. Allocating means
to request a fixed ip from the EC2 infrastructure. This address can than be attached to a running EC2 instance. When the EC2 instance is terminated the ip gets
disassociated from the EC2 instance but stays in the pool of
assigned IPs (causing costs).
Also here I tend to use a properties page.
Nevertheless as you mentioned the pool of assigned IPs I would rather see the
IP as a grid resource. Maybe it would be possible to have a resource category
holding these IPs?
Grid resource as in grid element? I could image to add
them their. When you have one of these ips assigned to you, you could
rightclick on a running instance and choose "Assign Elastic IP" -> list of
ips -> "1.2.3.4"
greets Moritz
