HaystackLastWrite facet persists

[arohloff]

When running nhaystack v3.0.1 service on N4.7, integrated to SkySpark 3.0.25, issue with a clearn uninstall of nhaystack driver.
Unable to uninstall nhaystack from N4 station because of persistent dependencies, even after clearing out all nhaystack palette objects and rebuilding cache, removing broken refs.

The haystackLastWrite facet is added to the Niagara points after a point write from a remote haystack server (SkySpark). This facet does get removed, even after point write is released, and all nhaystack service actions are attempted (clear caceh, remove borken refs, re-initialize, disable/enable). This creates a dependency that does not allow for nhaystack module to be uninstalled and station restarted cleanly.

[ci-richard-mcelhinney]

Hi Adam,

I'm interested in your use-case here? Could you explain the scenario a little more?

Also, if we could work on a series of steps to recreate the issue that would be great. Happy to work with you in understanding this issue.

[arohloff]

For sure. So use case is that we needed to uninstall nhaystack cleanly from a Niagara station. The station had performance issues and the station adminstrator wanted to isolate any unknowns during troubleshooting. Prior to that, we had been running nhaystack and sending point overrides (level 8) from a remote haystack server.
We did the following steps in attempt to uninstall:

• remove all nhaystack palette objects (equip, site), and run the removeBrokenRefs and rebuild cache actions.
• disable nhaystack service.
• uninstall nhaystack module through the software manager.
• restart station
  Station failed to restart due to it detecting some nhaystack object. We were unable to find any nhaystack objects using the program service. So we opened up the XML bog file and searched for "nh:". That pointed us to a number of points that had a haystackLastWrite component (see pic)
  

We then manually went into each point that had that component and deleted it. After that tried uninstalling the module and reboot, and it worked!

[ci-richard-mcelhinney]

Thanks @arohloff for the clear description. I can see the issue now and it's something I've never given thought to, in terms of uninstalling modules and the cleanup process a module should implement. In Niagara there are ways of doing this using the en masse so that you don't have to go to each point and delete them.

I can evaluate implementing a cleanup action that removes traces of nhaystack prior to removing the service from the station and uninstalling the module but that will take some time. Do you think it would be a better approach to just document in the wiki here so that others can lookup the process for removing the nhaystack module

How many Jaces would you do this on? Is this a once off or do you do it periodically/semi-regularly?

[ci-richard-mcelhinney]

@arohloff what do you think? Would some extra documentation do the trick here or is there more needed? Could you provide some insight into how often this sort of cleanup would be needed?

[arohloff]

Ideally the nhaystack service would never allow residual nhaystack objects/facets/components to be left over, and there would be an action that would definitely remove these. I have no idea of the complexity of that. Niagara stations undergoe maintenance or major overhauls from time to time, and being able to clear out nhaystack objects during these events is needed.

Short of a cleanup action button that handles this, if there was documentaiton to explain how to do this without needing platform access, that would be helpful. Again, when we tried to search for the nhaystack components via the Niagara program service, it did not come up with anything. If there are other ways to do this, it would be great to have this documented.

[ci-richard-mcelhinney]

@arohloff just as an update to this ticket...I'm currently reviewing the nhaystack code base in order to see if and where this 'haystackLastWrite' slot is used. There is a chance that we may be able to remove it should it not be used. However, let me check further and provide an update later this week.

[arohloff]

@ci-richard-mcelhinney thanks for the update!