Re: [HTCondor-users] HTCondor OCI Support?

[Oliver Freyermuth <freyermuth@xxxxxxxxxxxxxxxxxx>]

Dear Todd, 

Am 20.05.2018 um 21:03 schrieb Todd Tannenbaum:
> 
> 
>> On May 18, 2018, at 7:40 PM, Oliver Freyermuth <freyermuth@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> Dear experts,
>>
>> reading through the slides from HEPiX:
>> https://indico.cern.ch/event/676324/contributions/2981843/attachments/1651270/2641144/TannenbaumT_WhatsNew_HEPiX_Spring_2018.pdf
>> I find a lot of mentioning of Singularity and Docker, but wonder whether it would not be significantly easier
>> and future-proof to implement OCI support? 
>> Singularity is also adding OCI compatibility, and Docker already has that with Docker-runc. It would hopefully allow
>> to get rid of a lot of specialties. 
>>
>> Any plans on this? 
>>
> 
> Yes, we are looking at this. 

Thanks, that's really appreciated! Looking forward to it :-). 

> 
> 
>> Also, the talk sadly does not mention that while Singularity can be executed without setuid root on modern OS,
> 
> Yep. Actually I did mention this during the talk, and it is also mentioned in the slides as well. 

Yep - I meant that while the talk mentions that it can be executed without setuid root, it does not mention that condor_ssh_to_job will fail if done so. 

> 
> 
>> condor_ssh_to_job fails in that environment, and especially interactive jobs are a strong point in the container world. 
> 
> Agree completely.  The current v8.7 HTCondor supports condor_ssh_to_job with Docker universe, and we expect it to work with singularity for the next release. 

Good! I hope this also relates to operation without setuid root? 
In that case, sshd currently fails due to pts deviced being owned by the wrong uid / gid in the container,
hence my two linked bugreports (asking RHEL to allow mounting devpts in user namespaces, and asking OpenSSH guys to remove that check). 

> 
>> It would be nice if there would be a working setup not requiring privileges either in form of a root-owned daemon or setuid root binaries,
> 
> Agree again, we will make a point of testing it all out with non-root. However we also need to make certain it works with âolderâ distros like rhel7 (and rhel6) plus root since (unfortunately) much of the community is stuck running these distros for years to come. 

>= RHEL 7.4 supports user namespaces / singularity without setuid root / runc "rootless" containers / charliecloud all just fine. 
The main issue is that it needs to be enabled by administrators manually. Since RHEL 6 is EOL in about 1.5 years if I remember correctly, and up-to-date RHEL 7 supports user namespaces just fine,
I would say most of the community will be using systems supporting containers without root very soon. 
Of course, things should keep working with older distros for at least the following 1.5 years, but after that, there's not much reason to invest a lot of energy into pre-RHEL 7 issues. 

Many thanks for your very positive replies! 

All the best,
	Oliver

> 
> Best regards
> Todd
> 
> 
>> and I don't see a hard technical "blocker" for that. 
>> Having
>> https://bugzilla.redhat.com/show_bug.cgi?id=1522992 and 
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2813
>> solved would certainly help, but one could surely workaround those. 
>>
>> Cheers,
>>    Oliver
>>
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>>
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature