{5} Assigned, Active Tickets by Owner (Full Description) (26 matches)

in network.py, chooseClientIP* are using "os.system()", which is BAD. Better use twisted !

For now commands are independent, thus we can implement commands chains. The database must be altered in order to handle commands_on_host dependencies.

There are some case where desynch may occur between:

• what the MSC plugin things
• what the scheduler things
• what the launcher things

For example a task may appear as running when it was in fact aborded, for exemple:

• the scheduler take a command, pass it to a launcher,
• the launcher takes it,
• the launcher starts to execute it,
• the launcher crashes.

If run mode is sync, the scheduler will be notified of the failure. If run mode is async, the scheduler won't be notified of the failure, so:

• command appears as being executed in database,
• will never processed again by the scheduler (as it seems to be executed)

The problem may be (partialy) solved by adding a link (somewhere) which displays:

• informations about the process:
  • how execute it,
  • how many time since the beginning,
  • ...

When a scheduler has to stop several hundred of commands, contacted launcher will likely bring a huge amount of XMLRPC answers, and the more the launchers are, the more results will be delayed as the scheduler can't handle such a number of simultaneous connection.

This should be fixed like this:

• the scheduler asks a launcher to stop some commands,
• the launcher stops the commands, but do not fire cb, but stack them
• when all commands are processed, results are collected and send to the scheduler in one unique XMLRPC request (of one XMLRPC request per 10 results).

Until now, the different stages of a job are chain-fired. In some situation it may be useful to execute a command some time after file transfer has been done.

In advanced mode, three different start modes should be proposed:

• immediate,
• scheduled (execution should be done later),
• paused (execution will be put on hold).

For now a quick action is something to perform on a client using SSH connection. It may be useful if we could do quickaction without having to connect on the client. For example WOL.

For this to be done, quickaction file specs probably needs to be enforced.

Taken from dpkg --compare-versions:

static int verrevcmp(const char *val, const char *ref) {
  if (!val) val= "";
  if (!ref) ref= "";

  while (*val || *ref) {
    int first_diff= 0;

    while ( (*val && !cisdigit(*val)) || (*ref && !cisdigit(*ref)) ) {
      int vc= order(*val), rc= order(*ref);
      if (vc != rc) return vc - rc;
      val++; ref++;
    }

    while ( *val == '0' ) val++;
    while ( *ref == '0' ) ref++;
    while (cisdigit(*val) && cisdigit(*ref)) {
      if (!first_diff) first_diff= *val - *ref;
      val++; ref++;
    }
    if (cisdigit(*val)) return 1;
    if (cisdigit(*ref)) return -1;
    if (first_diff) return first_diff;
  }
  return 0;
}

--compare-versions ver1 op ver2

Compare version numbers, where op is a binary operator. dpkg returns success (zero result) if the specified condition is satisfied, and failure (nonzero result) otherwise. There are two groups of operators, which differ in how they treat an empty ver1 or ver2. These treat an empty version as earlier than any version: lt le eq ne ge gt. These treat an empty version as later than any ver-sion: lt-nl le-nl ge-nl gt-nl. These are provided only for compatibility with control file syntax: < << <= = >= >> >.

... in a unified manner if possible (using cygwin's smbclient binary ?)

Hi,

When deploying large files, it should be interesting to show the file transfer status.

As discussed with Nicolas, perhaps you could evaluate the transfer status with periodically "du" on the client.

Regards,
Mat

In some situations a command can be in a useless state, for example a launcher taken down inducing a "WORK_IN_PROGRESS" when the command has been aborded:

• is a end date is given, the scheduler will try to stop it forever
• if no end date is given, the scheduler will never try to get it down, but the command be be shown as "in progress" forever.

As we can ask launcher for their list ob tasks, it should be useful to add a one hour periodic control, where the scheduler would ask its launcher for not-finished commands, trying to guess which are really still executed, eventually tagging those which are not as "stopped".