Cloud status report and request for feedback on policies

[Kevin Fenzi]

On Wed, 29 Aug 2012 14:03:26 -0400 (EDT)
Seth Vidal <skvidal at fedoraproject.org> wrote:

> 
> 
> 
> On Wed, 29 Aug 2012, Kevin Fenzi wrote:
> 
> > Greetings.
> >
> > I thought I would give a quick status update on our private cloud
> > work (which skvidal has been doing. Thanks skvidal! )
> >
> > Our hardware in all in and working.
> > Our network is up and working.
> > We have a test instance of eucalyptus up and running with a pair of
> > machines.
> >
> > Short term:
> >
> > I'd like to test out Openstack on another 3 nodes or so. It's come a
> > ways since we evaluated it last.
> 
> +1
> fed-cloud02 is the other 'head' system. If we take that and 04-05 -
> then that should give us a base to test more with.

Yep. I can work on that, or you can if you like. 

> > We need to test more with the admin/command line tools.
> 
> I've been using the command line tools exclusively for all the euca
> stuff. The web interface i've only used to verify that some setting
> changes have occurred.

Cool. 

> > We need to figure out how we want to setup groups/users/etc.
> 
> 
> My concept at the moment is to identify groups who will repeatedly
> need to create instances and create an 'account' for them. Then
> delegate admin access on those 'accounts' to specific users.
> 
> For people who just need an instance now to test with - we do that 
> ourselves and flag the instance as having  a short life span and who
> it is for.

Yeah, we could use our existing ticketing system for the 'one off' type
instances like that. 

...snip...

> I'd say users should plan for them to go down. Just like with ec2 
> instances.

ok.

> > What timeframe should we tell people they can use instances?
> 
> Ask the user but default to one working week? (5days?)

That sounds reasonable. I am sure we will get some "Oh, I need another
week" "Oh, I never got to it, give me another". 

Do we have some way to tell if a instance is doing anything? 
I guess we could possibly log network traffic with iptables and key off
that, but if it was a compute instance with no networking stuff going
on... 

> > Do we want to kill them after some specific time?
> 
>    yes
> 
> > Note that if we want to use this for dev instances, we may want to
> > at least snapshot before taking down.
> 
>   agreed
> 
> 
> > What sort of policy do we want on "Fedora relatedness" for
> > instances? I don't think we want to offer general instances for
> > people, but how to explain the line? Do we want to specifically
> > forbid any uses?
> 
> not clear on this either. I think for a little while we'll have our
> hands full with just:
>   - copr builders
>   - randomn instances
>   - fedora qa
>   - fedora apps instances

Yeah. I just want people to have clear expectations that this is not to
"run their blog or irc bouncer" in 24x7 forever. (Unless we do wish to
allow that). 

> > What ports do we want to allow folks to use? Anything? 80/443/22
> > only?
> 
> 
> So if the user has a euca 'account' then they can create their own 
> security policy "group" which controls what can access that instance.

ok. Just any account or an 'admin' account? 

> By default I'd say 22,80,443 and ping should be sufficient for remote.

Agreed. 
> 
> > How about persistent data storage? We promise to keep data for X
> > timeframe? We make no promises? We keep as long as we have storage
> > available?
> 
> and how much in total, I'd think.

Yeah, a quota type setup would be nice, but probibly not implemented. 

> > I think we should have a very broad 'catch all' at the end of the
> > policy allowing us to refuse service to anyone for any reason,
> > allowing us to shutdown instances that cause problems. Or should we
> > word that more narrowly?
> 
> 
> don't we have something similar with regard to fedorapeople or 
> fedorahosted?

I guess it's implied... 

For Fedorapeople we have: 

Do not distribute anything on fedorapeople.org that Fedora itself
cannot distribute for legal reasons. Nothing on the ForbiddenItems list
or otherwise non distributable by Fedora. 
Do not upload your private .ssh keys. While Fedora IT works hard on
keeping the servers secure, break ins will happen and private keys
uploaded can be downloaded and brute-forced easily these days.
Private .ssh keys if found during an audit will be deleted.

> > How often do we want to update images? Say we have a Fedora 17 image
> > for folks, would we want to update it daily with updates? weekly?
> > Just when we feel like it? When security bugs affect ssh ? When
> > security issues affect the kernel?
> 
> Updating it daily seems excessive, the user can update it on their
> own of course. Given a short cycle of fedora I'd say maybe a couple
> of times a release and try to stay relatively on top of new kernels.
> 
> Running ami-creator to generate a new image is not very difficult,
> though.

Thats good. If we do them on some schedule (weekly or bi-weekly or
whatever) they could also be a useful tool... 

I would like an instance with updates as of 2012-08-29, because right
after that some update blew up and I want to find out why. (as a qa
type thing). 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120829/6c6a1106/attachment.sig>