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/INSTRM-1914 Instrument control development <p>When we need to edit configuration file and reload, we should be <b>forbidden</b> to edit the installed tagged version of pfs_instdata.<br/> But right now, the other option is to stop the actor, setup another pfs_instdata and start the actor again which is basically overkill.</p> <p>Just add optional configPath to actor.reloadConfiguration, so that $PFS_INSTDATA_DIR point to another directory, which can be edited in place.</p> INSTRM-1914

add optional configPath to actor.reloadConfiguration

Task Normal Open Unresolved arnaud.lefur arnaud.lefur SPS Fri, 31 Mar 2023 16:47:51 +0000 Wed, 24 Jan 2024 20:14:05 +0000 tron_actorcore 0 3 <p>Doesn't this mean that we won't know which exact version we're running? Just how onerous is it to run a setup version (which needn't be tagged if you're trying to circumvent the system?)</p> <p>We were thinking that the argument specifying the new <tt>pfs_instdata</tt> root would in almost all cases be for a different tagged version. In any case the <tt>version_pfs_instdata</tt> MHS key (and for FITS-writing actors the corresponding card) would change to the <tt>git describe --dirty</tt> for the new root. </p> <p>Some actors are problematic to restart. Specifically, the gatevalve gets closed and the H4 DAQ powered off when the controlling actor for each is stopped. That is a property of the kernel driver along with the polarity of the signal lines.</p> <p>So you'd <tt>reload</tt> the new code into a running actor?</p> <p>Configuration not code, but yes. Tell a running actor to use <tt>pfs_instdata 1.2</tt> version of its configuration instead of the <tt>pfs_instdata 1.1</tt> one it was built against. In <b>practice</b> this is mostly sane, since all current actors load a single config file, which boils down to a single python dictionary. The risk is that other parts of the actor's configuration would change but not get "applied". </p> <p>One alternative was to support some "patching mechanism", where you basically allow an update of that dict. </p> <p>We don't love these mechanisms, but are scared worse by not having any. I'd like, at the very least, to have a printout of changes when loading a new version.</p> <p>Bump. We are and will be testing various ion pump controller configurations on SM3. I made the (very limited) changes to the installed tagged version, but am very unhappy about doing that. Did not want to cycle the gatevalve.</p> <p>Hmm, thought: we could probably ensure that any new config version is on a git branch based directly off the starting tag. Not sure how, but that feels like something git can let you determine without too much work.</p> Relates INSTRM-2158 Development Rank 0|zzswo7: Story Points 1.0