Thanks for this, the solution you came up with seems OK to me, but I find
this commit pretty unfortunate.
This is a totally non-backwards compatible change to a critical core part
of how the BOINC server works. It definitely breaks C@H's apps for example
(just checked) without modifications on our end, and I imagine many other
projects as well.
If the server had some sort of release schedule with release notes for each
release, a project maintainer could see this change before updating and
make the necessary changes. As it stands, if I'm a project maintainer that
occasionally git pulls the server software and doesn't keep their eyes
glued to this mailing list, I'm never going to catch this commit and I'm
going to waste a huge amount of time figuring out why my project broke the
next time I update. (I think I'm partially echoing a few concerns brought
up by Christian Beer in other threads here)
Even worse, AFAIK (tell me if I'm wrong) there's no way for my
boinc2docker_create_work script to detect which version of the server is
currently installed, whether its a version before or after this commit,
which means I can't support both versions of the server software
I'd urge you to revert this commit from master and put it on a separate
branch while we solve the above issues (the solutions could well be simple
and quick, but until then I don't think this change belongs on master yet)
On Fri, Jan 13, 2017 at 9:50 AM, David Anderson <da...@ssl.berkeley.edu>
> I made two changes to the input template mechanism:
> 1) I got rid of the <number> and <file_number> elements.
> The list of <file_ref>s now corresponds to the list of <file_info>s
> (i.e. the first <file_ref> goes with the first <file_info>, etc.)
> If you have input templates where the lists are in different orders,
> you'll need to reorder them.
> 2) I added support for "constant input files",
> listed in the input template with a <physical_name> specifying the file.
> These files aren't included in the list of input files passed to
> or other job-submission APIs.
> This supports the nanoHUB use case, where Docker layers are input files
> but the job submitter doesn't know about them.
> This is described here:
> I've tested all the various cases, but I may have missed something.
> Let me know if any problems.
> -- David
> boinc_projects mailing list
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
boinc_dev mailing list
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.