On Thu, 30 Aug 2012, Xavier Lamien wrote:
Yes. We have a class C of external IP's.
Of course there may be some instances that will not need to use
external ip's, but many will.
hrm...so do we really want to let user to be fully responsible for the contents of the
I mean, how the content is being r/w from outside as he could open ports as we want (you
know, security and stuff...).
That's the whole point. These systems are:
1. on an isolated network from the rest of our systems
2. controlled through the head node(s) of the cloud system
3. can be easily restricted to a small number of ports, if we choose.
However, we don't need to do that. We can just let the user do whatever
and if there is a problem, terminate the instance and it is all gone.
Cheap and disposable.
If we wont make user's life easier, we could eventually manage what repositories he
has access to... x_x
We already do - but again - it doesn't matter what repos they have access
to. The systems are not meant for permanence.
Okay, Now I can understand the timeframe mentioned earlier.
Do you guys think of a better way to deal with instances availability/requests to book a
timeframe (say 1 month) of an instance?
Something where people can see what kind of instances are available, choose one which
match their criteria (or request one based on available profiles which is based on
available HW resources), set
the timeframe needed and receive an emal with all the infos to connect to it or via a
pop-up window or whatever.
It's not so much what kind of instances are available as what kind of
resources they need.
Right now here are system types I defined in euca:
vm types cpu ram disk
|- c1.medium 1 512 10
|- m1.small 1 1024 10
|- m1.large 2 1024 20
|- m1.xlarge 4 4096 40
|- c1.xlarge 8 8192 40
Those are flexible, of course, but I think they cover a pretty good range
for most cases.