On Wed, Aug 29, 2012 at 8:03 PM, Seth Vidal <skvidal(a)fedoraproject.org>wrote:
On Wed, 29 Aug 2012, Kevin Fenzi wrote:
> 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
> 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.
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.
+1 as well.
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
> 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.
Are you taking into account the FAS format (user, sponsors, Admin) for the
Unless you guys don't intend to plug it to FAS.
Otherwise, that sounds reasonable.
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
> We need to repave everything and re-install it in a controlled and
> documented manner.
+1. right now my steps have been:
1. new machines
2. setup repos
3. setup network devices (bridging, masquerading, dns, etc)
4. install euca software
5. configure eucalyptus.conf (and for node controllers libvirt.xsl)
6. do the euca initializing/registering and running of
7. reboot and make sure everything is up.
What expectation do we want on reboots? They can go down at any
> time, or 'we will try and let you know if we want to reboot things' or
> we plan on doing a maint window every X and your instances WILL be
I'd say users should plan for them to go down. Just like with ec2
I'd say that really depend on the purpose of the reboot/shutdown.
Any of your
statement can be taken into account.
We should level this depending on if we're facing a security issues, or
whatever that force us to act on the instance.
What timeframe should we tell people they can use instances?
Ask the user but default to one working week? (5days?)
What does this timeframe stand for?
Do we want to kill them after some specific time?
Does that mean oversee the inactivity or something and shut right down the
Note that if we want to use this for dev instances, we may want to at
> least snapshot before taking down.
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
> 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. By
default I'd say 22,80,443 and ping should be sufficient for remote.
+1 on this default. Which lead me to ask :
Does intance aims to be accessible from
outside of the fpo network?
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
and how much in total, I'd think.
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
Right, however, we're not targeting the same user neither the same use
Or are you saying we could word something based on them?
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.
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.
Running ami-creator to generate a new image is not very difficult,
Does this "private cloud" intend to replace the publictests.* system in
place in a near future?
I may have more questions following up.
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB