What are the requirements other than bandwidth for the official mirrors
listed at http://fedora.redhat.com/Download/mirrors.html. In particular
do we require them to carry the complete copy including source images
and packages? If not we should probably enforce that or list the mirrors
which only have binary packages as partial mirrors. We can run some
routine checks in a period basis automatically to cross verify this.
We have a proof of concept up and running for the wiki upgrade at:
We've got a little bit of work to do in testing, the two sites do look
We need the web guys (and maybe the doc guys?) to look at the website
and see what needs to be done and report whats broken. This is
something we'd like to get out by the end of February so it will be
ready for the Fedora 7 release.
Patrick: Who from the website team would be a good point person to
coordinate the upgrade with?
At present we provide two @fedoraproject.org addresses to everyone who
has a fedoraproject account.
Notting pointed out that its only a matter of time before we have a
collision in first.last. Should we just get rid of it? I don't know
of anyone using it.
i have recently join the fedora infrastructure list, so maybe this survey
would appear to you a bit odd.
i have taken a deeper look at what have been discussed regarding the config
many of you have strong experience in different kind of tools like glump,
puppet, cfengine ...
but i haven't seen any checkup list on :
- what's the aim of a new config management system.
- how far we want this tool to manage servers config (system,services, both
of them, anything else maybe ....).
- system limitations (for example : no ruby tools because it has been sealed
that ruby should be installed on servers ).
i've seen jeff ollie has made a little wiki page listing all config
management tools suggested, with pros and cons,
here's my little suggestion:
we should list :
- what the new config tool should do for us
- perhaps how we want this tool to work, (agent/server or something else)
- system things for example : no ruby, if there an agent so it should
communicate securely with his server .....
looking at jeff wiki's page and other solutions discussed on the list, and
see if there is any tool listed there which answer all our requirements,
if not then 2 choice :
- take a look around and find the "right" tool
- lower a little bit our requirements, so one of the tools listed would
answer them (definitely the worst solution ).
-build a test environment with the chosen tool, so everyone can play with it
(the more people become familiar with it, the best it would be ;) )
- make a deployment schedule.
- deploy and enjoy the work done by all people involved in ;=)
here my personal view:
what the new config tool should do for us:
this tool should help us managing system and services configurations of all
by managing, i mean :
- building new config to deploy.
- easily and smoothly updating several config
- versioning all config created and/or updated
how we want this tool to work:
- all tasks should be done securely, agent/server tool or not.
- the tool should give us some report on how tasks goes.
well as I'm not used on how servers are deployed , i can't really answer
this point but,
IMHO, whatever tool is chosen, it should not require something that may
change how our systems works, this tool should be nearly invisible system
about the right tool, after looking at threads in the list archive and
looking at jeff page, glump seems to be a good start
3) and 4) would come along the way after all question for 1) and 2) are
who's next to answer this little survey ? :)
hoping this would help
Even though we won't get much use regarding caching, do you guys think
it will be worth it to upgrade to current stable release of Moin Moin.
There's bound to be many features that we can use and it'd be good to
freshen up the wiki before the next release. (hopefully a good month
before the next release so we can workout any bugs)
Ahmed and Paulo, How much work would it take given your tests?
Anyone know of any of these guests that we can get rid of?
db2 18 512 1 -b---- 17750.7
doc-library 55 256 1 -b---- 1279.8
fdstest 23 512 1 -b---- 12236.5
metrics 56 256 1 -b---- 1983.3
plonetest 34 512 1 -b---- 16944.8
test6 47 512 1 -b---- 1330.0
bzrtest 40 512 1 -b---- 9511.6
fedhosting 47 512 1 -b---- 17422.0
mail 50 512 1 -b---- 2347.8
mercurial 45 512 1 -b---- 69931.4
pkgdbtest 51 512 1 -b---- 3150.4
I need to make some room for will :-D Also, Most of these boxes could
easily run test with 256 or 128 M of ram. If you get a moment log in
and lower yours or send me a request so I can do it. I'll have a
request form done soon so in the future expiration dates and official
contacts are defined.
I'm Will Woods, and I'm the lead tester / head of QA for Fedora.
We're hard at work on bunches of tools and ideas to help test Fedora and
make things better.. faster.. stronger.
Right now, we've got a couple of repositories of packages for testing
that live in David Malcolm's people page:
We're also going to be writing some web apps that will need somewhere to
live - something to keep track of testing progress / results, some
bugzilla-related stuff, a frontend for an automated test lab, and so on.
We don't have any hosting for any of it right now, but I'd like this
stuff to live somewhere like http://qa.fedoraproject.org/.
I'd like to have an official QA repo for our test tools and test
packages, hosted at something like http://qa.fedoraproject.org/repo/.
Most importantly, we need some help very soon. We currently have a
problem - dmalcolm is out of disk quota, so he can't push bugfixed
versions of the test tools out until we get a new host for the repos.
This is bad!
The amount of disk space we'll need is quite small - I think the
packages currently take up something like 3MB. We'll be collecting test
data and results and accumulating tests, but I don't anticipate this
being a significant amount of data (say >10GB) for months, maybe years.
Can we make this stuff happen? How do we get started?
Thanks in advance for the help, guys.