On Wed, Aug 29, 2012 at 9:33 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
That would be as a plug-in. writing it it's just a question of time/resources availability.
If we wont make user's life easier, we could eventually manage what repositories he has access to... x_x
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.
On Wed, 29 Aug 2012 20:53:06 +0200
Xavier Lamien <laxathom@xxxxxxxxxxxxxxxxx> wrote:
...snip...
I think initially we are not wanting to interface with fas directly.
> > Are you taking into account the FAS format (user, sponsors, Admin)
> > for the
> access level?
> Unless you guys don't intend to plug it to FAS.
> Otherwise, that sounds reasonable.
We could revisit that I suppose... it might be nice to have groups in
fas update the cloud permissions, but I have no idea how hard that will
be.
That would be as a plug-in. writing it it's just a question of time/resources availability.
Yes. We have a class C of external IP's.
> > +1 on this default. Which lead me to ask :
> Does intance aims to be accessible from outside of the fpo network?
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...).
I mean, how the content is being r/w from outside as he could open ports as we want (you know, security and stuff...).
>Just something based on them, or related I guess.
> Right, however, we're not targeting the same user neither the same use
> cases, right?
> Or are you saying we could word something based on them?
Yeah, true.
> sounds reasonable.
> However, I think we should more focus on security and critical bugs
> affecting the instances and not just update for the fun. As said,
> user can handle its updates itself.
If we wont make user's life easier, we could eventually manage what repositories he has access to... x_x
Yes. we have already largely phased out public test systems in favor of
> Additional questions:
>
> Does this "private cloud" intend to replace the publictests.* system
> in place in a near future?
$application.dev instances for development of applications.
If we can work it, I'd love for our *dev instances to move to this as
well. I suspect many of them are idle a lot of the time, and it would
be great to have it so a dev could just bring one up, work on it, and
then snapshot/drop it.
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.
>Please do!
> I may have more questions following up.
Thanks for the input.
--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
