Launchpad Entry: server-lucid-landscape-refresh
Packages affected: landscape-client, smart
With a new version of Ubuntu on the horizon, a new landscape client version has to be released in order for landscape users to use new landscape features.
With each new landscape release, additional features have been added. The landscape-client package has to be updated and an SRU has to be filed in order for Ubuntu workstations and servers to take advantage of those features.
- Eric is a systems administrator with 50 workstations and wants to update his machines to Lucid.
- Kenny is a systems administrator with 10 Jaunty and Karmic workstations and wants to apply a security update to the workstation
- Flo is a network administrator who wants to try out UEC and wants landscape to manage the implementation.
The landscape-client package will be ready to upload in time for alpha2.
The coding and package preparation is done by the landscape team. However the package review, uploading, and SRU tasks are done by the Server Team.
The landscape team makes changes to landscape by adding features and bug fixes to landscape. Then they do some QA before release and ask the server team to do the appropriate actions in order for it to be uploaded to the archive.
No UI changes done by the Ubuntu Server team, we are just the intermediary for the landscape team.
No code changes are expected by the Ubuntu Server team, we are just the intermediary for the landscape team.
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
In order to test the landscape refersh, the Ubuntu Server Team will run the new landscape-client against the staging server and smoke test the landscape-client.
The only unresolved issue is that the landscape team would like to preform an upgrade without user interaction however they will bring this up with the foundations team.
BoF agenda and discussion
=== New client for lucid cycle === New client in lucid SRU for new version every two month (from intrepid and >) New client will provide ability to run dist-upgrade New client should land for alpha2 Issue: upgrade should be non-interactive and not fail * Difficult to solve on a per-package basis * Could be solved on the upgrader side ? --> raise the issue with foundations ==== new features ==== smart package locking (equiv of apt-pinning) api for package management task do release upgrade integrate landscape with existing idm backend === Cloud feature brainstorming === ==== on the roadmap ==== * machine template library - ebs volume - security group - machine type * report IP address as a result of describe instance * manage non landscape instance * automated scaling: define rules that allow to automatically start new instances * script scheduling ==== brainstorming ==== * automated rebundling * quota definition (no api for that in euca)