On Wed, Aug 29, 2012 at 8:03 PM, Seth Vidal <email@example.com>
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
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.
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.
We need to test more with the admin/command line tools.
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.
We need to figure out how we want to setup groups/users/etc.
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.
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.
+1. right now my steps have been:
We need to repave everything and re-install it in a controlled and
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 euca-modify-properties
7. reboot and make sure everything is up.
I'd say users should plan for them to go down. Just like with ec2 instances.
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 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.
Ask the user but default to one working week? (5days?)
What timeframe should we tell people they can use instances?
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 instance?
Note that if we want to use this for dev instances, we may want to at
least snapshot before taking down.
not clear on this either. I think for a little while we'll have our hands full with just:
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?
- copr builders
- randomn instances
- fedora qa
- fedora apps instances
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.
What ports do we want to allow folks to use? Anything? 80/443/22 only?
+1 on this default. Which lead me to ask :
Does intance aims to be accessible from outside of the fpo network?
and how much in total, I'd think.
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
don't we have something similar with regard to fedorapeople or fedorahosted?
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
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?
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.
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?
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, though.
Does this "private cloud" intend to replace the publictests.* system in place in a near future?
I may have more questions following up.