Launchpad Entry: foundations-karmic-repository-management
Created: NicolasBarcet
Contributors:
Packages affected:
Summary
Provide a tool that allows people managing local repository mirrors to pick which package and updates should be added to their mirror.
Release Note
For administrator managing a large number of machines, it is now possible to use WebMirrorManager to pick which packages and updates are to be deployed in their production environment, independently of Ubuntu's releases.
Rationale
Use Cases
- Joe administer a web server farm. Each time a security update is provided in -security, he needs to test in a staging environement that this update does not break his servers behaviour, and once this is done and successfull, allow it to be propagated to his production servers.
- Carla manages 200 workstations that are used by traders. They love to use the latest versions of the packages but cannot afford to not be able to not be able to do trading, so each time a new package is posted in backports, she need to check that it does not break their setup before pushing it to her local official mirror so that traders can pick them if they feel like to.
- William is in charge of the virtual appliances deployed at 2000 customers worldwide. Each appliance points to his mirror of Ubuntu packages. Each time one of the packages that are deployed on his appliances is updated, he need to check the update before putting it to his mirror for automated upgrade of his appliances.
Assumptions
- apt-mirror provides a good way to create a local mirror, but does not provide a way to easily pick which packages/versions should be mirrored
- pssh provides a great way to push updates, or pinning to multiple machines at once, but can only be used in a push mode, thus satisfying the first use case
- landscape provides a way to control updates in a satisfying manner but cannot be used in closed networks or appliance update management.
Design
- Use a mirroring tool to make a full mirror of a given suite and pockets
- Duplicate the mirror structure and allow user picking of individual packets and versions from the full mirror to create a staging mirror
- Duplicate the mirror structure and allow user picking of individual packets and versions from the staging mirror to create a production mirror
Implementation
UI
- Web based interface
- one page to initialize the mirror (defining suites and pockets) and control its regular update
- one page presenting a paginated list of packages/versions present in full mirror and not in staging, allowing to pick which packages/versions to add to staging mirror
- one page presenting a paginated list of packages/versions present in staging mirror and not in production, allowing to pick which packages/versions to add to staging mirror
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. This need not be added or completed until the specification is nearing beta.
Outstanding Issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
MathiasGug: The issue of signing the Release files should be addressed. As customized repositories are generated, they need to be signed with a valid gpg key which also need to be installed on the client systems.
MathiasGug: The backend needs to take care of pulling in the correct dependencies when moving packages from one repository to the other. Other archive consistency checks may be needed.
MathiasGug: Third party repository integration - should this be considered ? It may require much more archive consistency checks to be done.
ThierryCarrez: More use cases ? Betty manages a large Ubuntu workstations network. She wants to be able to test updates in her test environment, then push updates to a set of pilot users, then push updates to everyone else. (require more than just two areas (staging+production) to be built from the original mirror, maybe define two by default but allow more)
ThierryCarrez: More use cases ? Johnny manages a small Ubuntu workstations network in a legal-aware company. He needs to enable a couple of multiverse packages, but for obvious company-compatible licensing reasons cannot enable the whole repository. (it's not just about -security or -updates)
ThierryCarrez: More use cases ? Herbert works with Betty, he packages company software as proper .deb packages. He can leverage the existing WebMirrorManager system to pilot-test and distribute that software to his users. (offer the possibility to add custom repos... or even import packages directly ?)
WilliamGrant: This will be greatly affected (and will somewhat affect) the ArchiveReorganisation spec. I'll be at the discussion on Thursday to bring the discussed ideas over.