LandscapeRefreshSpec

Summary

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.

Rationale

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.

User stories

  • 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.

Assumptions

The landscape-client package will be ready to upload in time for alpha2.

Design

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.

Implementation

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.

UI Changes

No UI changes done by the Ubuntu Server team, we are just the intermediary for the landscape team.

Code Changes

No code changes are expected by the Ubuntu Server team, we are just the intermediary for the landscape team.

Migration

Include:

  • 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.

Test/Demo Plan

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.

Unresolved issues

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)


CategorySpec

LandscapeRefreshSpec (last edited 2009-11-30 15:32:23 by CPE0006258ec6c1-CM000a73655d0e)