Re: New debconf template for lava-server
Sorry, no patch yet, but I'd only end up needing to produce half a
dozen revisions.
(Oh, I missed your followup until I'd nearly finished.)
Neil Williams wrote:
> lava-server is in the NEW queue and contains some debconf templates.
>
> https://ftp-master.debian.org/new/lava-server_2014.05.11.14-1.html
>
> Linaro Automated Validation Architecture server
A server for validating something Automatically, but it's hard to find
out quite what.
> This package replaces lava-deployment-tool to provide the
If this replaces lava-deployment-tool because that's being retired,
maybe "it replaces the old lava-deployment-tool".
> 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.
Okay, so apparently the validation server is some sort of big complex
clustery platform that runs on my web server. But I still have no
clue what it does apart from validate something. Googling around,
apparently it does software testing, but I'm still not sure whether
that means testing that it runs properly on ARM hardware or just
general testing.
If I understood it better the syntactic ambiguity wouldn't matter, but
as it is, I don't immediately see how the "as well as" fits in. It
could be:
This package replaces lava-deployment-tool [...] as well as the
scheduler and dispatcher.
[...] to run the validation server [...] as well as the scheduler
and dispatcher.
[...] to run [it] as a lava-server virtual host as well as [running
it as] the scheduler and dispatcher.
Or several other things, though the middle one's looking most likely.
If so, maybe it could say "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.
As opposed to a used database - it's always cheaper to get them
secondhand. Is there a better way of saying that?
although limitations in the remote worker design
require the installation of a database which will not be used.
or maybe
although design limitations mean that it always
installs a database (unused on a remote worker).
> Feedback would be useful at this stage - not looking for translations yet.
>
> lava-server.templates and templates.pot are attached.
So they are. Of course I can assume anybody reading these already
understands much more than I do about LAVA, whereas the description
needs to be clear enough to let people completely unfamiliar with the
software feel confident in filing it under "not for me".
> 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.
> .
> Configuration of remote dispatchers is currently experimental
> and a single master instance is recommended.
This is confusing - do I understand that the recommended "single
master instance" configuration isn't the same as the configuration
that mentions the word "master"?
Oh, and this doesn't make it clear what I'm supposed to do if this
machine is to be one of the experimental dispatchers. Answer "no",
presumably?
_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.
Canonically "PostgreSQL".
> 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.
> .
> Note that you will have to ensure that the lava-coordinator
> configuration is correct.
It's possible this should be an "error" rather than a "note", but I'm
never sure where the dividing line is. Meanwhile, it's not safe to
talk about the back or confirm buttons - not all debconf front-ends
are the same. Does the whiptail front-end still label the back button
as "cancel"? And the spec explicitly allows for front-ends lacking
the "backup" capability (though I don't know if there are any).
Also, I don't see what's going on here. Select "abort" to change
something and "okay" to change something else? Is it:
You asked for a standalone configuration, but this system looks like a
remote worker for a distributed configuration. You can either go back
and change your answer or proceed with reconfiguring this system as
specified.
...or is it:
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.
(But what answer do I change to say I want this system to be a
worker?)
> .
> Note that you will have to ensure that the lava-coordinator
> configuration is correct.
That's if I choose "carry on"?
> 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.
> .
> 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.
So my first guess was wrong and this is
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.
> Template: lava-server/instance-name
> Type: string
> Default: default
> _Description: Name for this LAVA instance:
> LAVA servers typically 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.
"Typically" implies it's not essential, which is contradicted by the
next two templates.
LAVA servers need to have an instance name. [...]
> 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'.
Now surely this one's a "Type: error"? Or lava-server/instance-name
could just say "a blank name will be replaced by the default" and
handle it silently with no extra template.
> Template: lava-worker/master-instance-name
> Type: string
> Default: default
> _Description: Name of 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.
This should probably say "the master LAVA server" (but "running
lava-server" is okay).
> Template: lava-worker/db-server
> Type: string
> _Description: Name of the master scheduler for this worker:
If this doesn't need to be a name, maybe it should be
_Description: Master scheduler for this worker:
(but see lava-server/missingname.)
> 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.
Inconsistent capitalisation of Master.
> .
> 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/missingname
> Type: note
> _Description: Missing LAVA instance name
> An instance name must be specified for LAVA-server. Using
> the instance name 'default'.
As above.
> Template: lava-server/missingip
> Type: note
> _Description: Missing server IP address
> The IP address of the master scheduler must be specified.
Again an error. But didn't you say "hostname or IP address"?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: