Re: Cloud status report and request for feedback on policies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






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 instance?
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.

-sv


_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure



[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux