Hello Oliver,
Your work is of interest to us and one our developers has tried
to contact you via email. Unfortunately, the message bounced for
some reason. Someone will reach out to you very soon.
We do welcome contributions. I apologize for our lack of response
so far.
...Tim
On 12/12/2017 06:23 PM, Oliver
Freyermuth wrote:
Dear developers,
since I have not yet received any feedback and from the archives it seems htcondor-devel has not seen any bidirectional activity
in the last months, I wonder whether this list is actually dead?
Receiving no feedback, I have in the meantime opened a PR on GitHub:
https://github.com/htcondor/htcondor/pull/18
Sadly, this is now also over a month old, by now has conflicts, and I did not receive any feedback on it.
I also asked related questions and given suggestions concerning the container implementations in HTCondor on htcondor-users,
again without reply (not unexpected, since I was asking in a conceptual way, for which the devel-list seems better suited).
So it seems to me all channels which I would expect to be used for interactions with developers are dead.
Are external contributions welcome at all?
Cheers,
Oliver
Am 02.11.2017 um 18:06 schrieb Oliver Freyermuth:
Dear developers,
since my last question might have been too specialized for others to find (especially in htcondor-users),
I'm now asking in a more generic manner on the devel mailing list.
What's the best way to get started with HTCondor development, and in which way are contributions expected?
I would be interested in writing a charliecloud "plugin" (very much like the singularity plugin, only the wrapper and of course some parameters
are different / do not exist).
Looking at the way the singularity plugin implementation is done, the procedure seems straightforward.
Background and reasoning (already explained on the htcondor-users list):
Charliecloud should allow to easily resolve the condor_ssh_to_job issue,
since an unprivileged "nsenter" call is sufficient to enter the container. This could be done via the authorized-keys injection or ForceCommand.
So as Cluster-admin it would be my first choice in terms of security (no setuid root / no root daemon) whenever user namespaces are sufficient,
especially since it can run extracted containers built with docker or singularity, so no new work is needed.
That's why I'd like to see it supported in HTCondor, but of course nothing comes for free, so I'm offering to implement things.
Do I simply get started, at some point submit a PR on github / a mail here, and then we discuss implementation details?
Or is there another preferred way?
Or is somebody else interested in it / already working on that?
Cheers,
Oliver
_______________________________________________
HTCondor-devel mailing list
HTCondor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel
_______________________________________________
HTCondor-devel mailing list
HTCondor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel
--
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736
|
|