Hi
I do agree that it is good for geclipse to have a consistent feel for
each supported middleware. But here is my problem... The user doesn't
care! When we look at grid technologies, management and usage is rather
difficult. Hence we provide great tooling to ease the accessing of
these resources. For AWS it is pretty much the opposite. Using AWS from
the command line is not really a pain and using the Cloud Studio
certainly is a breeze. And now we have geclipse.. making a simple
technology complicated... Negative Tooling! This is not about us. It is
about them (the users).
The reason why anybody would want to use the AWS support in geclipse is
because of the addon value we provide. This includes direct access to a
ssh shell, editing of files in an s3 bucket, maybe copying a file from
one grid middleware to AWS via the EFS implementations (although rather
unlikely). At some point
in the future we hopefully integrate with the TM project... These are
the things which make the AWS gEclipse implementation a worthwhile
undertaking.
But in the end... if the things which are easy to begin with get
complicated... tooling fails. And i don't expect geclipse aws users to
be grid users. That said... lets comment on your mail. :)
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?
Placing it under connections, alongside mounted S3 buckets, feels kind
of misplaced for me. These things (administrative entities) are more
like remote resources for me. They are kept remote and managed
remotely. This is why i would prefer to have them under the AWS VO. But
what i could image is that you are able to mount a security group from
the AWS VO into the "local resources area" but in a different folder
than connections. Thereby you have your favorite security groups
nearby. I completely agree with the doubleclick-open-dialog scenario.
That would be the best solution to edit a security group.
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.
I do understand how the mechanism works.... and that is why it feels
awkward to me ;) The keypairs you manage are not used for
authentication in the same way as containing login/password data. They
contain only a name which is stored remotely on EC2 and a corresponding
private key file. Thats it. When creating this name and the private key
file, one could use the "new authtoken" button/wizard but beyond that,
there is no need for an auth token.
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.
Agreed.
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
AWS is not the grid. I think the user would be more happy with
descriptive folder names than to have similarities with other
middlewares.
I hope you don't get me wrong here. It is the user i am concerned
about. :)
greets
Moritz
|
