Why is eups distrib needing write access to a product stack and database?

Support
#1

Hello, I read this sentence on B.3.4 of the eups manual. My use case is that I have the stack accessible through CVMFS, which is great, but I now want the sims distrib on top of it, which is not installed in CVMFS. I set load the LSST config and then add a local path to EUPS_PATH with the ups_db created there.

I get :

cohen@port-jct:~/lsst/dm/stack/lsst_sims$ eups distrib install lsst_sims -t sims
[ 1/69 ] cfitsio 3360.lsst4 done.

[ 2/69 ] doxygen 1.8.5 (already installed) done.
eups distrib: You don’t have permission to assign a global tag b1748 in /cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v11.0/ups_db

so cfitsio is more recent than the CVMFS stack version, and thus is correctly downloaded. But doxygen is recognized as installed in the stack, and thus this fails as the code wants to write to the corresponding ups_db. Is this write access really needed in such a case where precisely the package is recognized as installed and ready to be used? And why not use the write access to the local repository if the remote one is not accessible, if indded there is a need to watermark somehow the db of installed packages from the stack?

#2

I think it’s a bug in EUPS (or lack of a feature?).

When EUPS sees a new tag on the server, it tries to tag the product in question. But I think the way tagging is implemented, it must reside in the same ups_db where the product is declared, unless it’s a “user tag” (i.e., your username, or a tag of the form “$USER:something” (I think, I never use this latter form – @RHL will know) ). So this will fail if the product’s database directory is not writable.

Workarounds I could think of:

  • Copy everything from the CVMF stack to a writable directory, and then point your EUPS_PATH there.
  • Modify EUPS by changing the if statement that tests writability, and just return instead of throwing an exception. The fact the tag is missing will not be an issue (dependencies are looked up by version, and I presume you won’t explicitly be setup-ing the low-level stuff like doxygen).
  • Try overlaying a UnionFS filesystem over CVMFS, to gain writability.
#3

Thanks @mjuric, I guess I am still unclear about your very first sentence (apart from the fact that it does look like a bug to me!) : eups writes down (already installed) so it recognized the package in the CVMFS eups_path and matched the tag as identical there and in the server. So why does it need to tag it again, and why would setup fail if the package to be set up is in a non writeable distro place? Of course you are right that I would not eups setup doxygen… but I am still baffled by the intended logic.
Thx for the pointer to the code, I will raise the issue there.

#4

Let me try to explain it better – I think the issue is a combination of two things:

  • EUPS tags have to live in the same ups_db where the product is declared
  • When EUPS does installs, it checks the server for all tags a particular product has, and then tries to tag the local copy with them.

So, imagine you already have doygen 1.8.5 installed, and that it was installed with a tag b1500 (I don’t know exactly which tag is in the CVMFS distro). But then when you install sims, EUPS may see that doxygen 1.8.5, in addition to b1500 has (on the server) some additional tags (e.g., b1800, and definitely sims). So it tries to apply those tags to the installed product, and fails (because the directory is not writable).

I think it may be the case that it just blindly applies all the tags (i.e., it tries to apply even the tags that already exist) – that is something that we could fix. But even then, it would want to write any new tags into the products dir (that is not writable). That part requires a more complicated fix (it’s a “missing feature” I obliquely referred to in the previous reply).

#5

ok, thanks.So the difference with the cfitsio case in my initial post is that cfitsio 3360.lsst4 is not in the cvmfs repoditory, and thus eups happily downloads it and puts all the tags locally. But doxygen is the same version, so eups does not download it, but then if the tags are different it tries to add the tags remotely instead of locally. If the tags had been the same in the server and in the CVMFS, would the problem still have occurred?

For reference here is the eups list output:

cohen@port-jct:~/lsst/dm/stack/lsst_sims$ eups list cfitsio
3360.lsst3 b1710 b1711 sims_development b1713 fe_test[/cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v11.0] b1716 b1712 b1694 b1731 v11_0 w_2015_40 current sims[/cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v11.0] fe_test2 qserv[/cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v11.0] b1701 b1700 b1709 b1728 b1725 b1724 sims_2_1_0 2015_09 v11_0_rc3 w_2015_39
3360.lsst4 sims[/home/cohen/lsst/dm/stack/lsst_sims] sims_2_1_2 sims_2_1_3 fe_test[/home/cohen/lsst/dm/stack/lsst_sims] qserv_2015_11 qserv_latest dax_latest b1802 w_2015_47 b1809 qserv-dev b1828 b1849 w_2016_03 b1781 b1843 qserv[/home/cohen/lsst/dm/stack/lsst_sims] b1825 dax_2015_11 v11_1_rc1 b1817 w_2015_50 b1812 b1856 b1852 b1842 b1854 b1790 b1791 w_latest

cohen@port-jct:~/lsst/dm/stack/lsst_sims$ eups list doxygen
1.8.5 sims b824 b1630 n20150327_b949 b780 b1731 w_2015_22 w_2015_40 b660 b1100 b261 opsim_3_3_0 opsim_3_3_1 opsim_3_3_2 b858 qserv-dev b1232 b1231 b701 b182 sims_2015_06_18 b1701 b1700 maf_0_3 b1259 b1709 b1203 test b1421 b1541 2015_01 2015_04 2015_05 2015_06 2015_07 v9_2-rc1 2014_09 2015_03 b376 2014_08 2015_08 2015_09 b1327 w_2015_30 w_2015_33 w_2015_35 b1226 w_2015_36 w_2015_39 w_2015_38 b1539 b1710 b1711 b1712 b1713 b1716 webserv_1 b1491 b801 b1454 b1153 b1412 sims_2016_06_26 b1419 b1551 v11_0 2014_10 2014_11 2014_12 b604 w_2015_26 b601 sims_2_0_1 sims_2_0_0 t20141107_b449 w_2015_29 b609 b1565 w_2015_37 maf_1_0_1 t20150915-b1692 b1687 v9_1_1 b750 b551 current b512 b513 t20150914-b1689 t20150914-b1688 b299 v11_0_rc2 v11_0_rc3 b1657 v11_0_rc1 sims_2015_05_30 b1109 sims_2015_06_23 2015_02 t20150421_b1109 fe_test b949 b944 b1499 b345 sims_w_2015_30 n20150416_b1100 b991 b1471 b1476 sims_2015_07_18 webserv_2 b1643 b1486 b1641 b449 t20150914-b1690 b1597 v10_1 v10_0 b1647 b1490 b1592 b1215 b974 v10_1_rc3 b1505 b1468 b1506 b1501 deprecated_db_access b1503 b337 b1182 maf_1_0_0 b539 b1267 b531 t20141205_b531 b1175 b1171 b1679 b1677 b1675 b427 b437 sims_2_1_0 sims_development b1326 b1693 b1323 b1614 v10_1_rc2 b1207 v10_1_rc1 b1694 b1108 b1690 sims_2015_06_18b b1692 b1192 b759 v9_2 v9_1 b173 b1191 b176 b245 b649 b1105 b1104 b1660 b641 b879 maf_1_0_2 fe_test2 b1665 v3_2_1 n20150419_b1104 qserv maf0_2 b1062 t20141208_b539 b1728 b1683 b557 maf_1_1 b992 b1216 b1725 b1724 b1688 b1689 b330 maf_0_2_2 b792 b598 b1288 b1289 b163 b751 b710 b658 b652 b650 b842 setup

#6

so I guess one question is : why not also download locally same versions but with different tags. Maybe that would amount to reinstalling the whole stack, I don’t know.

#7

Right!

Doxygen is the same version, so it doesn’t download it. But tags are different so it tries to add the tags that it found on the server, to the local (read-only) directory.

I am not sure (don’t know how it’s coded up right now); but that is a problem we could fix relatively easily (just check if the tag exists before trying to write it). Except that this – having identical tags on the server and locally – virtually never happens in a typical situation where you’re using eups distrib install to install new versions; every build will add a new set of tags (the b in the tag name stands for “build”), so there will always be new tags. And that may require some re-engineering to handle (though @RHL or @price should weigh in when they get a chance; I may be overblowing the difficulties).

And yes, if you try to download/build everything to a writable stack, it’s equivalent to a reinstall from scratch.

#8

Re user tags: They are declared in your ~/.eups directory [Warning: due to work by developers whose initials are not rhl there’s stuff in there that looks like a cache but isn’t. I never had the heart to fix all that stuff]. User tags are your user name, or something declared as a user tag in your ~/.eups/startup.py file, e.g.

hooks.config.Eups.userTags.append(“tmp”)
The rhl:tmp form is used to refer to my tmp tag.

The other complication is that the afore-mentioned developer invented a second way to store “system” tags. So things are a mess – but we could add externally-stored tags if needed. Certainly whining rather than aborting seems reasonable.