Update landscape-client package to 1.0.25

We've got tarballs released to https://launchpad.net/landscape-client/+download

We're going to be running the client in staging for a while to test it. The attached branch builds and installs correctly on Intrepid. Is there anything else we need to do in the SRU process? We don't want to get the client into intrepid immediately, because we want to test it for a while, but we would like to make sure we get through the process early so by the time we're done testing we can push it up.

Please provide a summary of changes in that version. Does it change anything else than adding this new feature? Any bugs, UI changes, protocol/ABI breaks, backward compatibility, and so on?

As for testing, please have it uploaded to Jaunty ASAP, and also to the intrepid-proposed queue. This can stay in intrepid-proposed for testing for a while, and feedback should be collected in this bug; preferably from real Landscape users, but if your team or QA is testing it, that's great as well.

There were some other changes, which I'm putting into the changelog:

  * New upstream release supporting custom graphs (LP: #306360)
    - PATH is now set for scripts in script execution (LP: #257018)
  * debian/landscape-client.postinst: Work around chfn/system user problem
    by not specifying a --gecos (LP: #238755)
  * debian/landscape-client.logrotate: logrotate no longer reports spurious
    errors when the client isn't running (LP: #271767)

I'm not sure what type of detail you want to know for the various code changes, so I'll try to be thorough. I'm looking through the entire diff from the current intrepid version to this new version to write this list of changes:

In addition to the changes above, the feature of custom graphs required some changes:

 - The client now sends a list of the types of messages that it can accept to the server. This is to allow the server to determine whether any given client will support a particular feature. For example, it's used now to determine if the client supports custom graphs before sending a message to the client.

 - In order to thoroughly support the previous point, we had to change the code that handles messages (in the manager and monitor) to tell the broker which messages that it handles. This involves a new dbus call to the broker. The broker itself now maintains a registry of handlers for messages instead of doing ad-hoc message introspection when handling a message so that we can know which types it handles.

 - This accepted types stuff has a minor optimization so that the client doesn't have to send the full list of accepted types on every exchange with the server; the server keeps the list of accepted types and sends a hash of all of them to the client on every exchange; the client only sends the full list again if the hash doesn't match its current list.

 - Since the custom graph code uses a lot of same functionality as the script execution code, the script execution code was refactored to allow reuse of the same code. Methods were refactored into smaller bits for easier reuse and some class hierarchies were restructured.

 - The custom graph feature is actually being made available as a part of the script execution plugin: so if the user already has include_manager_plugins = ScriptExecution in his configuration file, custom graphs will Just Work. This also drove some of the refactoring in the script execution code (scriptexecution.py).

 - A new "manager.database" sqlite database was added to /var/lib/landscape/client/ to store custom graph-related data. It's called "manager.database" because it's not actually restricted to custom graphs, but will be used for any other data storage needs of the manager. custom graphs is just the first user.

 - Of course, new unit tests were added and existing unit tests were updated for all these changes.

As for non-custom-graph related changes:

 - An accidentally duplicated method in the load average plugin was removed

If you'd like something more thorough than this, or just some clarification of specific issues, please ask.

I'll attach a branch shortly for jaunty.

Ok, I've attached a jaunty branch. It's exactly the same as the intrepid branch but with a different changelog entry. I've functionally tested it on a jaunty machine. I've subscribed ubuntu-core-dev to sponsor this upload.

Should I be doing anything else for a jaunty upload?

Please do not subscribe ubuntu core dev to bugs.

(You wanted ubuntu-main sponsors subscribed to this - please see https://wiki.ubuntu.com/MOTU/Contributing#Preparing%20New%20Revisions )

This seems more appropriate for intepid-backports than -updates.

Any sponsors: please hold off on uploading this for now. During testing we've found a bug in the new custom graphs code that we'd like to get fixed. We'll do a 1.0.25 and I'll update this ticket shortly.

Ok, we've done a new upstream release 1.0.25 which fixes the bug we found, which is bug #307314. This bug prevented multiple custom graphs on the same machine. The release is at https://launchpad.net/landscape-client/trunk/1.0.25.

We also found bug #307321, which broke custom graphs after an upgrade of the package.

Another bug fix was included since 1.0.24, which causes sysinfo to ignore squashfs when calculating "nearly full" filesystems: bug #303284.

Alright, two new branches for 1.0.25 on jaunty and intrepid have been attached to this ticket.

Sorry for all the trouble.

This bug was fixed in the package landscape-client - 1.0.25-0ubuntu0.9.04

---------------
landscape-client (1.0.25-0ubuntu0.9.04) jaunty; urgency=low

  * New upstream release supporting custom graphs (LP: #306360)
    - Multiple custom graphs can be used at the same time (LP: #307314)
    - PATH is now set for scripts in script execution (LP: #257018)
  * debian/landscape-common.postinst: Only chown parts of /var/lib/landscape
    because we now store files in it that should maintain their ownership
    (LP: #307321).
  * debian/landscape-client.postinst: Work around chfn/system user problem
    by not specifying a --gecos (LP: #238755)
  * debian/landscape-client.logrotate: logrotate no longer reports spurious
    errors when the client isn't running (LP: #271767)

 -- Christopher Armstrong <email address hidden> Thu, 11 Dec 2008 17:11:08 -0800

I reviewed the diff. The majority is test cases, and bug fixes which look okay to me. The only debatable thing is the custom graph feature, which is quite large and intrusive.

I see the value of adding such kind of new features to LTS releases such as hardy, but for normal 18 month releases this is bending the SRU rules too much IMHO.

This is the only purpose of the SRU exception, as far as Landscape is concerned. Not upgrading it means that
users of released distributions will never get any new features, for the whole life time of the given distribution. The problem is aggravated when considering that the users *will* see the new features in the user interface, and will try to use them, and will get a note saying something like "This feature isn't available on some of the selected computers. Please upgrade to a newer client release.", and the new client release won't be available.

This was a major item for us when we proposed introducing Landscape in the distribution, and we discussed these details ahead of time because we knew of the potential issues. Blocking that kind of release now will mean we'll have to fallback to providing upgrades via a non-standard repository as we used to do.

As per discussion that happened elsewhere, I'm writing in the ubuntu wiki (i.e., a public place) a proposal for rules for Landscape client packages upgrades. Once it's ready for review, I'll publish the URL here (it's not hidden and the url is easy to guess, I just don't want it to be reviewed right now while it is still being written).

The document is at https://wiki.ubuntu.com/LandscapeUpdates feel free to provide feedback.

The wiki doc is not yet approved, but I moved on with the tests to gain some time.

All but the distro upgrade tests have been performed. The distro upgrade ones take more time, and I'm still working on my setup to streamline that process. Once they are done, I'll write more details here.

1.0.25 is about to become obsolete. I'm closing this ticket now and once we have 1.0.27 (next week probably) we will open a new SRU request for Intrepid with 1.0.27.