[Pkg-linaro-lava-devel] Bug#754149: [RFR] templates://lava-server/{lava-server.templates}

Justin B Rye justin.byam.rye at gmail.com
Sat Jul 12 12:11:04 UTC 2014


[...]
> Template: lava-server/missingname
> Type: error
> _Description: Missing LAVA instance name
>  An instance name must be specified for LAVA-server. Using
>  the instance name 'default'.
                     ^       ^
The Smith Project "house style" prefers doublequotes.

[...]
> Template: lava-worker/db-server
> Type: string
> _Description: Name of the master scheduler for this worker:
>  Each remote worker needs to connect to a master scheduler
>  running lava-server. This hostname or IP address will be
>  used to connect to the master database.

I never did quite understand where it allowed IP addresses and where
it allows names.  If here it really doesn't mind how you identify the
master scheduler, we could simplify the description:

  _Description: Master scheduler for this worker:

Compare the previous one ("Name of the master instance for this
worker:"), where the admin is being asked to *invent* a name for the
master.  The distinction might be even clearer if that was "Name for
the master instance".

[...] 
> Template: lava-server/missingname
> Type: error
> _Description: Missing LAVA instance name
>  An instance name must be specified for LAVA-server. Using
>  the instance name 'default'.
                     ^       ^
Same agai- wait a minute... duplicate template!  I missed this last
time around.

(Isn't there some sort of lintian check for this?)

> Template: lava-server/missingip
> Type: error
> _Description: Missing server IP address
>  The host name or IP address of the master scheduler must be specified.

Another case where I was confused.  IP address?  Or just a way of
identifying the machine?

In the control file:

[...]
> Package: lava-server
[...]
> Description: Linaro Automated Validation Architecture server
>  LAVA is a continuous integration system for deploying operating
>  systems onto physical and virtual hardware for running tests.
>  Tests can be simple boot testing, bootloader testing and system
                                                       ^
Harvard comma, just for stylistic standardisation.  It's a lot of
repeats of the words "test" and "testing", but never mind.

>  level testing, although extra hardware may be required for some
>  system tests. Results are tracked over time and data can be
>  exported for further analysis.
>  .
>  This package provides the Apache and WSGI configuration and LAVA
>  support files to run the validation server on the local Apache
>  instance as a lava-server virtual host as well as the scheduler
>  and dispatcher.

Assuming I've understood this correctly my suggestion was to make that
"as well as running".

>  .
>  This package can be configured as the master scheduler or as a
>  remote worker, although limitations in the remote worker design
>  mean that an unused database will need to be installed.

As opposed to a used database - I suggested:

                  although design limitations mean that it always
   installs a database (unused on a remote worker).

> Package: lava
[...]
> Description: Linaro Automated Validation Architecture metapackage
[...]

>  Metapackage to bring in all LAVA components on a single
>  machine. Some dependencies require the Linaro Tools PPA.

"This is a", or "This metapackage brings..."
 
> Package: lava-dev
[...]
> Description: Developer support for LAVA

I had the synopses standardised in "$suite - $component" format,
making this
  Description: Linaro Automated Validation Architecture - developer support

[...]
>  This package provides a helper script to build LAVA packages
>  from local git working copies and support for running the
>  LAVA unit tests locally.
                                ↑
Add a comma to make it harder to misread as "from workingcopies and
support".  Oh, and should it be Git?
 
> Package: lava-server-doc
[...]
> Description: documentation for lava-server

I had "$suite - server documentation"

>  This package contains an offline copy of the LAVA
>  Manual available on each instance running LAVA server.

It's not clear to me whether that's
 * "of the particular manual that is available"
 * "of the manual, which also happens to be available"
 * "of the manual, which is thereby made available"
but I'll assume it's obvious for people who might install it.

>  .
>   - an overview of LAVA
>   - help on installing and configuring LAVA
>   - test developer guide to writing LAVA tests
>   - use cases and examples
>   - administrator guide for managing a LAVA lab
>   - developer guide

Room for some more trivial d-l-e-house-style tweaks.

Wait, why is my patch messing with dependencies?  Am I diffing against
an obsolete version?

Why-The-Name footnote: the part I'm not sure about is whether it's a
coincidence that LAVA is nearly but not quite an example of LAMP
software.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package
-------------- next part --------------
diff -ru lava-server-2014.06.02.17.pristine/debian/control lava-server-2014.06.02.17/debian/control
--- lava-server-2014.06.02.17.pristine/debian/control	2014-07-08 21:31:59.000000000 +0100
+++ lava-server-2014.06.02.17/debian/control	2014-07-12 13:03:13.812158759 +0100
@@ -29,22 +29,22 @@
  postgresql, postgresql-client, postgresql-common,
  ${python:Depends}, ${misc:Depends}
 Recommends: ntp, lava-coordinator, lava-server-doc
-Description: Linaro Automated Validation Architecture server
+Description: Linaro Automated Validation Architecture - server
  LAVA is a continuous integration system for deploying operating
  systems onto physical and virtual hardware for running tests.
- Tests can be simple boot testing, bootloader testing and system
+ Tests can be simple boot testing, bootloader testing, and system
  level testing, although extra hardware may be required for some
  system tests. Results are tracked over time and data can be
  exported for further analysis.
  .
  This package provides the Apache and WSGI configuration and LAVA
  support files to run the validation server on the local Apache
- instance as a lava-server virtual host as well as the scheduler
- and dispatcher.
+ instance as a lava-server virtual host as well as running the
+ scheduler and dispatcher.
  .
  This package can be configured as the master scheduler or as a
- remote worker, although limitations in the remote worker design
- mean that an unused database will need to be installed.
+ remote worker, although design limitations mean that it always
+ installs a database (unused on a remote worker).
 
 Package: lava
 Architecture: all
@@ -53,34 +53,33 @@
  lava-dev, lava-tool, lavapdu-client, linaro-image-tools, ntp | ntpdate,
  tftpd-hpa, vmdebootstrap, ${misc:Depends}
 Recommends: lavapdu-daemon
-Description: Linaro Automated Validation Architecture metapackage
+Description: Linaro Automated Validation Architecture - metapackage
  LAVA is a continuous integration system for deploying operating
  systems onto physical and virtual hardware for running tests.
- Tests can be simple boot testing, bootloader testing and system
+ Tests can be simple boot testing, bootloader testing, and system
  level testing, although extra hardware may be required for some
  system tests. Results are tracked over time and data can be
  exported for further analysis.
  .
- Metapackage to bring in all LAVA components on a single
+ This metapackage brings in all LAVA components on a single
  machine. Some dependencies require the Linaro Tools PPA.
 
 Package: lava-dev
 Architecture: all
 Section: devel
-Depends: build-essential, ca-certificates, devscripts, dpkg-dev,
- debhelper (>= 8.0.0), fakeroot, git, libdistro-info-perl,
- django-testscenarios,
+Depends: ca-certificates, devscripts, dpkg-dev, debhelper (>= 8.0.0),
+ fakeroot, git, libdistro-info-perl, django-testscenarios,
  python | python-all | python-dev | python-all-dev,
  python-sphinx (>= 1.0.7+dfsg) | python3-sphinx, po-debconf,
  python-mocker, python-setuptools, python-versiontools,
  ${misc:Depends}
 Recommends: sbuild
-Description: Developer support for LAVA
+Description: Linaro Automated Validation Architecture - developer support
  LAVA is a continuous integration system for deploying operating
  systems onto physical and virtual hardware for running tests.
  .
  This package provides a helper script to build LAVA packages
- from local git working copies and support for running the
+ from local Git working copies, and support for running the
  LAVA unit tests locally.
 
 Package: lava-server-doc
@@ -90,20 +89,20 @@
 Conflicts: linaro-dashboard-bundle-doc
 Provides: linaro-dashboard-bundle-doc
 Replaces: linaro-dashboard-bundle-doc
-Description: documentation for lava-server
+Description: Linaro Automated Validation Architecture - server documentation
  LAVA is a continuous integration system for deploying operating
  systems onto physical and virtual hardware for running tests.
- Tests can be simple boot testing, bootloader testing and system
+ Tests can be simple boot testing, bootloader testing, and system
  level testing, although extra hardware may be required for some
  system tests. Results are tracked over time and data can be
  exported for further analysis.
  .
  This package contains an offline copy of the LAVA
- Manual available on each instance running LAVA server.
+ Manual available on each instance running LAVA server:
  .
-  - an overview of LAVA
-  - help on installing and configuring LAVA
-  - test developer guide to writing LAVA tests
-  - use cases and examples
-  - administrator guide for managing a LAVA lab
-  - developer guide
+  * an overview of LAVA;
+  * help on installing and configuring LAVA;
+  * test developer guide to writing LAVA tests;
+  * use cases and examples;
+  * administrator guide for managing a LAVA lab;
+  * developer guide.
diff -ru lava-server-2014.06.02.17.pristine/debian/lava-server.templates lava-server-2014.06.02.17/debian/lava-server.templates
--- lava-server-2014.06.02.17.pristine/debian/lava-server.templates	2014-07-08 21:31:59.000000000 +0100
+++ lava-server-2014.06.02.17/debian/lava-server.templates	2014-07-12 13:05:48.475979976 +0100
@@ -1,26 +1,28 @@
 Template: lava-server/master
 Type: boolean
 Default: true
-_Description: Is this a single master instance of LAVA?
- LAVA can be set up in one of two ways, as a single instance
- with attached devices or as a master instance and remote
- dispatchers providing (more) devices.
+_Description: Is this a standalone master instance of LAVA?
+ LAVA can be set up in either of two ways: as a single standalone
+ master instance with attached devices, or in a distributed
+ configuration with a central master instance and remote dispatchers
+ providing (more) devices.
  .
- Configuration of remote dispatchers is currently experimental
- and a single master instance is recommended.
+ Configuration of remote dispatchers is currently experimental, so
+ the standalone configuration is recommended.
 
 Template: lava-server/db-port
 Type: string
 Default: 5432
-_Description: Port number of the postgresql database:
- Please enter the port number for the postgresql database.
+_Description: Port number of the PostgreSQL database:
+ Please enter the port number for the PostgreSQL database.
 
 Template: lava-server/worker-note
 Type: note
 _Description: This install looks like a remote worker
- You have asked for a master instance install but the current install
- looks like a remote worker install. Select back to change this or
- confirm to proceed and change to a master instance.
+ You asked for this system to be set up as master instance for a
+ distributed configuration, but this system looks like a remote worker.
+ You can either go back and change your answer or proceed with
+ reconfiguring this system as specified.
  .
  Note that you will have to ensure that the lava-coordinator
  configuration is correct.
@@ -28,9 +30,10 @@
 Template: lava-server/master-note
 Type: note
 _Description: This install looks like a master instance
- You have asked for a remote worker install but the current install
- looks like a master instance. Select back to change this or
- confirm to proceed and change to a remote worker.
+ You asked for this system to be set up as a remote worker for a
+ distributed configuration, but this system looks like a master
+ instance. You can either go back and change your answer or proceed
+ with reconfiguring this system as specified.
  .
  Note that you will have to ensure that the lava-coordinator
  configuration is changed to point to the master instance for
@@ -41,38 +44,38 @@
 Type: string
 Default: default
 _Description: Name for this LAVA instance:
- LAVA servers typically have an instance name. If this is a new
+ LAVA servers need to have an instance name. If this is a new
  instance, you can safely use the default name. If this is an upgrade
  of a previous LAVA instance, specify the instance name here to
  upgrade the database or use a different name to start fresh with
  a new database.
 
 Template: lava-server/missingname
-Type: note
+Type: error
 _Description: Missing LAVA instance name
  An instance name must be specified for LAVA-server. Using
- the instance name 'default'.
+ the instance name "default".
 
 Template: lava-worker/master-instance-name
 Type: string
 Default: default
-_Description: Name of the master instance for this worker:
+_Description: Name for the master instance for this worker:
  LAVA servers need to have an instance name. Each remote
  worker must be given the instance name of the master
- lava-server which it will poll for new jobs to run
+ LAVA server which it will poll for new jobs to run
  on the devices attached to the worker.
 
 Template: lava-worker/db-server
 Type: string
-_Description: Name of the master scheduler for this worker:
+_Description: Master scheduler for this worker:
  Each remote worker needs to connect to a master scheduler
  running lava-server. This hostname or IP address will be
  used to connect to the master database.
  .
- To work with remote nodes, the Master needs to be configured
+ To work with remote nodes, the master needs to be configured
  to allow the database to listen to the workers. An SSH key also
  needs to be generated on the worker and added to the master list
- of authorized_keys. Ensure that the Master allows remote access
+ of authorized_keys. Ensure that the master allows remote access
  from workers before submitting jobs or health checks.
  .
  You can continue setting up the worker, as long as
@@ -107,13 +110,7 @@
  running lava-server. The worker will use this username to contact
  the database.
 
-Template: lava-server/missingname
-Type: note
-_Description: Missing LAVA instance name
- An instance name must be specified for LAVA-server. Using
- the instance name 'default'.
-
 Template: lava-server/missingip
-Type: note
+Type: error
 _Description: Missing server IP address
- The IP address of the master scheduler must be specified.
+ The host name or IP address of the master scheduler must be specified.
-------------- next part --------------
Template: lava-server/master
Type: boolean
Default: true
_Description: Is this a standalone master instance of LAVA?
 LAVA can be set up in either of two ways: as a single standalone
 master instance with attached devices, or in a distributed
 configuration with a central master instance and remote dispatchers
 providing (more) devices.
 .
 Configuration of remote dispatchers is currently experimental, so
 the standalone configuration is recommended.

Template: lava-server/db-port
Type: string
Default: 5432
_Description: Port number of the PostgreSQL database:
 Please enter the port number for the PostgreSQL database.

Template: lava-server/worker-note
Type: note
_Description: This install looks like a remote worker
 You asked for this system to be set up as master instance for a
 distributed configuration, but this system looks like a remote worker.
 You can either go back and change your answer or proceed with
 reconfiguring this system as specified.
 .
 Note that you will have to ensure that the lava-coordinator
 configuration is correct.

Template: lava-server/master-note
Type: note
_Description: This install looks like a master instance
 You asked for this system to be set up as a remote worker for a
 distributed configuration, but this system looks like a master
 instance. You can either go back and change your answer or proceed
 with reconfiguring this system as specified.
 .
 Note that you will have to ensure that the lava-coordinator
 configuration is changed to point to the master instance for
 this remote worker. You can then remove the lava-coordinator
 package from the remote worker.

Template: lava-server/instance-name
Type: string
Default: default
_Description: Name for this LAVA instance:
 LAVA servers need to have an instance name. If this is a new
 instance, you can safely use the default name. If this is an upgrade
 of a previous LAVA instance, specify the instance name here to
 upgrade the database or use a different name to start fresh with
 a new database.

Template: lava-server/missingname
Type: error
_Description: Missing LAVA instance name
 An instance name must be specified for LAVA-server. Using
 the instance name "default".

Template: lava-worker/master-instance-name
Type: string
Default: default
_Description: Name for the master instance for this worker:
 LAVA servers need to have an instance name. Each remote
 worker must be given the instance name of the master
 LAVA server which it will poll for new jobs to run
 on the devices attached to the worker.

Template: lava-worker/db-server
Type: string
_Description: Master scheduler for this worker:
 Each remote worker needs to connect to a master scheduler
 running lava-server. This hostname or IP address will be
 used to connect to the master database.
 .
 To work with remote nodes, the master needs to be configured
 to allow the database to listen to the workers. An SSH key also
 needs to be generated on the worker and added to the master list
 of authorized_keys. Ensure that the master allows remote access
 from workers before submitting jobs or health checks.
 .
 You can continue setting up the worker, as long as
 remote database access is enabled before jobs are submitted.

Template: lava-worker/db-name
Type: string
_Description: Name of the database on the master:
 Please enter the name of the database on the master scheduler
 running lava-server. The worker will use this name to contact
 the database.

Template: lava-worker/db-user
Type: string
_Description: Username for the database on the master:
 Please enter the username for the database on the master scheduler
 running lava-server. The worker will use this username to contact
 the database.

Template: lava-worker/db-port
Type: string
Default: 5432
_Description: Port number of the database on the master:
 Please enter the database port number for the database on the
 master scheduler running lava-server. The worker will use this
 port to contact the database.

Template: lava-worker/db-pass
Type: string
_Description: Password for the database on the master:
 Please enter the password for the database on the master scheduler
 running lava-server. The worker will use this username to contact
 the database.

Template: lava-server/missingip
Type: error
_Description: Missing server IP address
 The host name or IP address of the master scheduler must be specified.
-------------- next part --------------
Source: lava-server
Section: net
Priority: optional
Maintainer: Debian LAVA team <pkg-linaro-lava-devel at lists.alioth.debian.org>
Uploaders: Antonio Terceiro <terceiro at debian.org>,
 Neil Williams <codehelp at debian.org>,
 Fathi Boudra <fabo at debian.org>, Jordi Mallach <jordi at debian.org>
Build-Depends: debhelper (>= 8.0.0),
 python | python-all | python-dev | python-all-dev,
 python-sphinx (>= 1.0.7+dfsg) | python3-sphinx, po-debconf,
 python-mocker, python-setuptools (>= 3)
X-Python-Version: 2.7
XS-Testsuite: autopkgtest
Standards-Version: 3.9.5
Homepage: http://www.linaro.org/projects/test-validation/
Vcs-Git: https://github.com/Linaro/pkg-lava-server.git
Vcs-Browser: https://github.com/Linaro/pkg-lava-server

Package: lava-server
Architecture: all
Provides: lava-scheduler, lava-dashboard, linaro-django-xmlrpc
Conflicts: lava-scheduler, lava-dashboard, linaro-django-xmlrpc
Replaces: lava-scheduler, lava-dashboard, linaro-django-xmlrpc
Depends: apache2, adduser, diffstat, fuse, iproute2,
 libapache2-mod-uwsgi, libapache2-mod-wsgi, lshw,
 python-daemon, python-dateutil, python-django-auth-openid (>= 0.5-2),
 python-setuptools,
 libjs-jquery-cookie, libjs-jquery-flot (>= 0.8.2), openssh-client,
 postgresql, postgresql-client, postgresql-common,
 ${python:Depends}, ${misc:Depends}
Recommends: ntp, lava-coordinator, lava-server-doc
Description: Linaro Automated Validation Architecture - server
 LAVA is a continuous integration system for deploying operating
 systems onto physical and virtual hardware for running tests.
 Tests can be simple boot testing, bootloader testing, and system
 level testing, although extra hardware may be required for some
 system tests. Results are tracked over time and data can be
 exported for further analysis.
 .
 This package provides the Apache and WSGI configuration and LAVA
 support files to run the validation server on the local Apache
 instance as a lava-server virtual host as well as running the
 scheduler and dispatcher.
 .
 This package can be configured as the master scheduler or as a
 remote worker, although design limitations mean that it always
 installs a database (unused on a remote worker).

Package: lava
Architecture: all
Section: metapackages
Depends: lava-server, lava-server-doc, lava-dispatcher, lava-coordinator,
 lava-dev, lava-tool, lavapdu-client, linaro-image-tools, ntp | ntpdate,
 tftpd-hpa, vmdebootstrap, ${misc:Depends}
Recommends: lavapdu-daemon
Description: Linaro Automated Validation Architecture - metapackage
 LAVA is a continuous integration system for deploying operating
 systems onto physical and virtual hardware for running tests.
 Tests can be simple boot testing, bootloader testing, and system
 level testing, although extra hardware may be required for some
 system tests. Results are tracked over time and data can be
 exported for further analysis.
 .
 This metapackage brings in all LAVA components on a single
 machine. Some dependencies require the Linaro Tools PPA.

Package: lava-dev
Architecture: all
Section: devel
Depends: ca-certificates, devscripts, dpkg-dev, debhelper (>= 8.0.0),
 fakeroot, git, libdistro-info-perl, django-testscenarios,
 python | python-all | python-dev | python-all-dev,
 python-sphinx (>= 1.0.7+dfsg) | python3-sphinx, po-debconf,
 python-mocker, python-setuptools, python-versiontools,
 ${misc:Depends}
Recommends: sbuild
Description: Linaro Automated Validation Architecture - developer support
 LAVA is a continuous integration system for deploying operating
 systems onto physical and virtual hardware for running tests.
 .
 This package provides a helper script to build LAVA packages
 from local Git working copies, and support for running the
 LAVA unit tests locally.

Package: lava-server-doc
Architecture: all
Section: doc
Depends: ${sphinxdoc:Depends}, ${misc:Depends}
Conflicts: linaro-dashboard-bundle-doc
Provides: linaro-dashboard-bundle-doc
Replaces: linaro-dashboard-bundle-doc
Description: Linaro Automated Validation Architecture - server documentation
 LAVA is a continuous integration system for deploying operating
 systems onto physical and virtual hardware for running tests.
 Tests can be simple boot testing, bootloader testing, and system
 level testing, although extra hardware may be required for some
 system tests. Results are tracked over time and data can be
 exported for further analysis.
 .
 This package contains an offline copy of the LAVA
 Manual available on each instance running LAVA server:
 .
  * an overview of LAVA;
  * help on installing and configuring LAVA;
  * test developer guide to writing LAVA tests;
  * use cases and examples;
  * administrator guide for managing a LAVA lab;
  * developer guide.


More information about the Pkg-linaro-lava-devel mailing list