[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