Closed Bug 304343 Opened 20 years ago Closed 18 years ago

Bouncer v2.0 needs a home

Categories

(mozilla.org Graveyard :: Server Operations: Projects, task)

Product:
mozilla.org Graveyard
Component:
Server Operations: Projects
Platform:
Other
Linux
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: morgamic, Assigned: oremj)

Details

Chase and I would like to get Bouncer v2.0 up and running on Chameleon soon. Would it be possible to install the necessary Python packages on this box? The Python requirements for Sentry are: * mx.DateTime <http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Download-mxBASE> * MySQLdb <http://sourceforge.net/projects/mysql-python> * Crypto <http://www.amk.ca/python/code/crypto> * cse utils <http://wiki.osuosl.org/display/howto/cse+utils> I could configure the application, but would need those modules set up. Python needs to also be a valid handler in Apache - there are a couple instances where a python script needs to handle an HTTP POST.
I installed the mod_python, mx, and MySQL-python packages via up2date. There don't appear to be packages available for any of these other modules, even on DAG's repository (a third-party RPM repo we trust that has a lot of packages RHEL doesn't ship). If at all possible for something that's going to wind up being critical infrastructure like this, I'd like to use tools we can get automatic security support on. Installing things from source means we have to stay on top of the advisories from lots of additional sources and makes it harder to keep the machine secure. That said, if these are really the tools we need, I'd prefer to load a machine with Ubuntu to let you use for it, since Ubuntu is python-crazy (if it runs in python, they have it security-supported :) ) and they have very good security support.
Priority: -- → P2
I understand. I would be totally cool with Ubuntu (I run that on my desktop) - whatever works best for everyone. :)
Summary: Chameleon + Bouncer v2.0 → Bouncer v2.0 needs a home
This is a mass-reassign of bugs that I'm not actively working on right at this moment to the default component owner, since we now have a larger IT staff than just me. These bugs will be getting redistributed to other sysadmins as sysadmin time becomes available.
Assignee: justdave → server-ops
Priority: P2 → --
Assignee: server-ops → nobody
Component: Server Operations → Server Operations Projects
QA for this component is now Justin
QA Contact: myk → justin
Ubuntu packages are: python-egenix-mx-base-dev python-mysqldb python-crypto cse utils looks like they could be bundled with the bouncer distribution... since that was also written by lars (it appears). The only one RHN does not have is python-crypto, and that is indeed in dag and dries: http://dag.wieers.com/packages/python-crypto/ http://dries.studentenweb.org/rpm/packages/python-crypto/info.html
We are ready for this. I will implement in the LVS environment. Mike: Would you prefer us to run this out of svn, or a release tarball? The latter would probably be appropriate, but I need a tarball in that case. :)
Assignee: nobody → polvi
Ok, I'll attach it later this afternoon once I have had a chance to talk to Lars about a couple of python-related issues.
build@m.o wants to make sure we don't lose needed functionality in the switch to Bouncer 2. Our plan for the migration to Bouncer 2 is to have both Bouncer 1 and 2 up and running side-by-side through a major release. If we find any issues in Bouncer 2 we'll cycle over them with morgamic and lars before moving over to Bouncer 2 completely. If we're close to having Bouncer 2, can we get it by Friday for Firefox 1.5.0.1 RC? If not, when can we expect to have it? Thanks.
We have a migration script to populate the bouncer 2 mirrors list. We'd have to create our own 1.5.0.1 records, though -- the database structure is different enough (particularly w/ hash keys) so that we'd still have to enter the products in separately. We are working on Bouncer documentation as a part of this release. Today and tomorrow I will be fleshing out the documentation at: http://wiki.osuosl.org/display/Bouncer/Home There is a public SVN repo where we could pull trunk for testing on gecko -- assuming the packages are up. Will work with Polvi to get it up by Wednesday or Thursday. Alex -- how are the packages on gecko, or is this going on a new box?
Ok - migration.py was checked in today -- this will allow us to sync the mirrors and regions between prod and our test bouncer2 installation: https://svn.osuosl.org/public/bouncer/trunk/python/migration.py So after the first part of the installation, that could be set up with cron -- to sync the mirror lists between the two.
Hi all, There are some high priority issues that have come up with stats and I have had to pull polvi off this temporarily. Is there an urgent need to have this up by 1.5.0.1 and if so what is the date which it needs to be ready? If not needed, I'd like to put this to the next 1.5.0.x release to give the team more time. Thanks, -Justin (In reply to comment #8) > build@m.o wants to make sure we don't lose needed functionality in the switch > to Bouncer 2. Our plan for the migration to Bouncer 2 is to have both Bouncer > 1 and 2 up and running side-by-side through a major release. If we find any > issues in Bouncer 2 we'll cycle over them with morgamic and lars before moving > over to Bouncer 2 completely. > > If we're close to having Bouncer 2, can we get it by Friday for Firefox 1.5.0.1 > RC? If not, when can we expect to have it? Thanks. >
I think our main concern is getting a v2 installation running off of the production DB. That is still possible without having LVS running it. What I'd like to do is schedule a cron to dump the production database running under bouncer1 to one of our databases. We could then plug our migration.py script into the picture and then use it to sync up an installation of bouncer2 running on bouncer.osouosl.org. That could provide us with the testing necessary to gauge the capabilities of bouncer 2 and detect any errors / inconsistencies / regressions. Having bouncer 2 running on LVS could be pushed back until we all agreed that the test installation's performance was acceptable.
Justin, build+release has been looking for an evaluation copy of Bouncer 2 for almost a year, though this bug was filed more recently (8/11). We would like to have a copy of it installed and available for trial for Firefox 1.5.0.1 RC. If it's looking like this might slip off sysadmins' priority list for 1.5.0.1, given the proper access I would be happy to install and configure Bouncer 2 for our temporary use. The principal issue is that we go through a full release like 1.5.0.1 once every 1-2 months. We may find an issue the first time we use it that the Bouncer 2 developers could fix in the next month with a new version ready for us to test the next time around. Note that based on my feedback, this bug could be split into two bugs. The other bug would be "Bouncer v2.0 needs a trial home" and that bug is the one I'm interested in resolving asap.
If we can't have it hosted on LVS we can use the installation at the OSL for the "trials". The migration script sends over production mirror information so you don't have to re-enter that into bouncer2. The installation is at: http://bouncer.osuosl.org/v2/php/admin/ It needs to have the locales updated, since it looks like the locale paths have changed -- but we could just as easily use this installation to track Fx 1.5.0.1 using this to gauge its performance. If there aren't any objections we can go ahead and use this one -- thoughts?
(In reply to comment #14) > The installation is at: > http://bouncer.osuosl.org/v2/php/admin/ Great! If this is a shared installation will it "look" that way to us from our login accounts? > If there aren't any objections we can go ahead and use this one -- thoughts? No objections other than knowing what version we're dealing with. I want it to be clear that we're using a specific version and that version isn't upgraded without letting us know so we can do an accurate trial. For example, if we test Bouncer 2.0.1 or 2.0.1 with some patch and that version works for us, I want us to know that so we can request exactly that be installed locally. We'll still need a home for Bouncer 2 in the Mozilla infrastructure so we can prepare for a switchover from Bouncer 1 to 2, but that work can proceed at a slower pace since using Bouncer 1 still meets our user-facing needs.
Heh - didn't realize it was that old. Just to be clear, I am talking about pushing it off for a few weeks - not months. If OSU can help the testing, that would be great but I want to make sure the production instance is hosted in LVS/Moz infrastructure. If it is urgent, I'll shift around resources to make it work. -Justin (In reply to comment #13) > Justin, build+release has been looking for an evaluation copy of Bouncer 2 for > almost a year, though this bug was filed more recently (8/11). We would like > to have a copy of it installed and available for trial for Firefox 1.5.0.1 RC. > If it's looking like this might slip off sysadmins' priority list for 1.5.0.1, > given the proper access I would be happy to install and configure Bouncer 2 for > our temporary use. > > The principal issue is that we go through a full release like 1.5.0.1 once > every 1-2 months. We may find an issue the first time we use it that the > Bouncer 2 developers could fix in the next month with a new version ready for > us to test the next time around. > > Note that based on my feedback, this bug could be split into two bugs. The > other bug would be "Bouncer v2.0 needs a trial home" and that bug is the one > I'm interested in resolving asap. >
(In reply to comment #15) > Great! If this is a shared installation will it "look" that way to us from our > login accounts? Ok, should be moved over. I've set up the mirror network there as well. Running in "parallel" means we'll have the same mirror networks. Bouncer1 doesn't track locales, so there's no comparison between the set of available files, really. Bouncer1 only knows about en-US. This is why there can't be a pure migration between the two that involves all products/versions. So the bouncer.osuosl.org link has a few things: * http://bouncer.osuosl.org/v2/php/admin/ -- admin pages * http://bouncer.osuosl.org/v2/php/download.php -- download form * http://bouncer.osuosl.org/v2/sentry/sentry1.html -- sentry reports * Cron to run scheduled updates. * Products added for 1.5. There is additional documentation here: http://wiki.osuosl.org/display/Bouncer/Installation+Guide If you have questions about loader.py (adding new products) send them my way. I tried to put some help stuff at the bottom, but it is still confusing.
Assignee: polvi → nobody
Has there been any progress on this? We'd like to get Bouncer up before the end of the year...
Severity: normal → major
I set this up at https://download2.stage.mozilla.com. All the packages for sentry should be installed. We need a script to import all the data from bouncer v1 into bouncer v2.
As oremj said, it's been staged and ready for testing/import since before ff2 launch in case of an issue. Can you guys take a look and see what you think?
Sweet - will work with oremj to verify the install. If that works, then we'll have to start migrating the mirrors.
(In reply to comment #20) > As oremj said, it's been staged and ready for testing/import since before ff2 > launch in case of an issue. BTW - we should have updated this bug if that was the case. I just didn't know. :( My bad.
We are still working on this.
Assignee: nobody → oremj
Bouncer2 now has a home and is currently severing Thundebird 2(afaik). Should we still keep this bug open?
Spoke with Mike this is setup.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.