https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INFRA-70 Software Development Infrastructure <p>Could we get a PFS development web server? The immediate use-case is for a conda channel for patches/additions to the LSST conda installation. But one can imagine others (documentation, ICS conda channel).</p> <p>For conda, http or https, and only serving static files. rsync'ing files in might be sufficient write access. </p> INFRA-70

Provide PFS http server for conda repository

Story Major Won't Fix Won't Fix shimono cloomis Fri, 21 Oct 2016 14:03:20 +0000 Fri, 13 Oct 2017 09:02:15 +0000 Fri, 13 Oct 2017 09:02:15 +0000 0 2 <p>Pages at <a href="https://pfspipe.ipmu.jp" class="external-link" rel="nofollow">https://pfspipe.ipmu.jp</a> is managed under git (at github, no auto deploy).<br/> We can have any directory specific to this purpose, managed under git.</p> <p>OK,</p> <ol> <li>How do the actual ``pfspipe`` pages get updated after the github repo gets changed?</li> <li>Where in the pfs_www repo would a static and hidden directory containing a tree of files of various types and names go?</li> </ol> <p>For conda there will be big .tgz files, etc. </p> <p>1. periodic update and/or one-time hand operation by sysadmin<br/> 2. pfs_www is for pfs.ipmu.jp, which is under simple CMS. it's not easy to handle various types</p> <p>&gt; For conda there will be big .tgz files, etc. <br/> I was afraid so, actually.<br/> Then, it should be better to have some space via putting files, or to build conda repository at server.<br/> Easiest way in server operation point of view, is to provide one WebDAV URI (on pfs.ipmu.jp or pfspipe), which is in public at some point on pfspipe. e.g.:<br/> webdav: <a href="https://pfs.ipmu.jp/webdav-pfspipe/" class="external-link" rel="nofollow">https://pfs.ipmu.jp/webdav-pfspipe/</a><br/> public point: <a href="https://pfspipe.ipmu.jp/conda/" class="external-link" rel="nofollow">https://pfspipe.ipmu.jp/conda/</a></p> <p>If you are thinking to have non-autogen-ed documents, I'd suggest to host in pfs_www_pipe repo. If you are thinking to have autogen-ed documents like via sphinx, ask to build dedicated processing environment on server or consider to follow other documents (like readthedocs).</p> <p>webdav would work, I think. Though rsync would easier. Access does need to be pretty general: allow deleting things, etc. Definitely non-autogen-ed. Sorry....</p> <p>If you have ipv6, <a href="http://odie.toestub.org:8088" class="external-link" rel="nofollow">http://odie.toestub.org:8088</a> has a sample tree with just one product in it. That's what I'd like to be able to actively maintain. (Sorry, that host is all I have complete access to right now). <tt>conda search --override-channels -c <a href="http://odie.toestub.org:8088/stack" class="external-link" rel="nofollow">http://odie.toestub.org:8088/stack</a></tt> is how it would appear to most.</p> <p>ok.</p> <p>site: <a href="https://pfspipe.ipmu.jp/conda/" class="external-link" rel="nofollow">https://pfspipe.ipmu.jp/conda/</a><br/> webdav: <a href="https://pfs.ipmu.jp/webdav-conda/" class="external-link" rel="nofollow">https://pfs.ipmu.jp/webdav-conda/</a> (login required)<br/> rsync: ssh to pfs.ipmu.jp:/server/services/conda/</p> <p>if you could configure, please close this.</p> <p>Thanks for all the work. In the end we will not use conda distributions.</p> <p>Since, <br/> &gt; Thanks for all the work. In the end we will not use conda distributions.<br/> changed resolution to WONTFIX, and filed <a href="https://pfspipe.ipmu.jp/jira/browse/INFRA-162" title="Remove all configurations for INFRA-70" class="issue-link" data-issue-key="INFRA-162"><del>INFRA-162</del></a>.</p> Development Rank 0|ii00v3: