~bkerensa/ubuntu/precise/landscape-client/fix-for-962974

« back to all changes in this revision

Viewing changes to landscape/constants.py

  • Committer: Bazaar Package Importer
  • Author(s): Free Ekanayaka
  • Date: 2010-07-28 08:14:02 UTC
  • mfrom: (1.1.18 upstream)
  • Revision ID: james.westby@ubuntu.com-20100728081402-2ygupluqwc2bbe8j
Tags: 1.5.4-0ubuntu0.10.10.0
* New upstream version (LP: #610744):

  - The Eucalyptus management plugin reports the output of the
    'euca-describe-availability-zones verbose' command, which includes
    information about the available instance types and the maximum
    number of each instance type that the cloud can support (LP: #599338)

  - Check if the package directory exists before trying to check the
    package changer lock in the dbus-proxy. This fixes a bug when upgrading
    a dbus-landscape which never registered (LP: #603514).

  - Allow an LDS server to bootstrap new cloud instances with its own CA,
    which is picked up by the client, written to a file on the instance, and
    used in subsequent exchanges with the server (LP: #605079).

  - Skip loopback interface when reporting device info (LP: #608314)

  - Disable landscape-sysinfo when load is more than 1 (LP: #608278)

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
"""
 
2
Hold constants used across landscape, to reduce import size when one only needs
 
3
to look at those values.
 
4
"""
 
5
 
 
6
APT_PREFERENCES_SIZE_LIMIT = 1048576 # 1 MByte
 
7
 
 
8
SUCCESS_RESULT = 1
 
9
ERROR_RESULT = 100
 
10
DEPENDENCY_ERROR_RESULT = 101
 
11
POLICY_STRICT = 0
 
12
POLICY_ALLOW_INSTALLS = 1
 
13
POLICY_ALLOW_ALL_CHANGES = 2
 
14
 
 
15
# The amount of time to wait while we have unknown package data before
 
16
# reporting an error to the server in response to an operation.
 
17
# The two common cases of this are:
 
18
# 1.  The server requested an operation that we've decided requires some
 
19
# dependencies, but we don't know the package ID of those dependencies.  It
 
20
# should only take a bit more than 10 minutes for that to be resolved by the
 
21
# package reporter.
 
22
# 2.  We lost some package data, for example by a deb archive becoming
 
23
# inaccessible for a while.  The earliest we can reasonably assume that to be
 
24
# resolved is in 60 minutes, when the smart cronjob runs again.
 
25
 
 
26
# So we'll give the problem one chance to resolve itself, by only waiting for
 
27
# one run of smart update.
 
28
UNKNOWN_PACKAGE_DATA_TIMEOUT = 70 * 60