`pvxlist` does not appear to show PVs behind PVAGateway

[jembishop]

The pvxlist command from pvxs does not appear to show PVs behind PVAGateway, only the status PVs that the PVAGateway provides. Is there a way to get around this so we can list all the pvs behind the PVAGateway? Thanks

[mdavidsaver]

I think this is a duplicate of #118

[jembishop]

Sorry I didn't see that issue!

Could I ask, would you be open to this being added? I think that in practice every EPICS deployment will have a PVAGateway for security reasons and it makes the useful pvxlist command ineffective in this setup. I don't think one should have to set up the whole channelfinder stack just to do this.

I could try implementing this when I have the time, don't have that much knowledge of EPICS though so it will take me a while.

[mdavidsaver]

I understand that from the prospective of a small installation CF looks like a lot of trouble to replicate pvlist ... | grep .... Consider though. How would this scale up? Isn't this the moral equivalent of an RDB application doing SELECT * FROM ... for every query? What would this process look like when pvlist is transferring and returning eg. 500,000 record names every time? Where might this line of thinking might lead an efficiency minded engineer? Caching? Moving query processing to the server(s)?

This starts to look a lot like ChannelFinder...

Could I ask, would you be open to this being added?

I don't want to simply say "no", but I would suggest the you first take some time to study all of the uses cases CF tries to handle, and how it does so efficiently. I certainly won't claim CF is a perfect solution. The first time admin. experience is particularly painful for anyone not used to dealing with web. apps. (those who are seem to be sufficiently numbed) Maybe in the end you do decide to write something different. I still think you would do well to understand the good and the bad of CF in the same way that CF is informed by experience with its predecessors.

[jembishop]

Our site has < 100, 000 PVs. So if each channel name is about 64 bytes long then that would be about 5MB of data, assuming EPICS makes no effort to compress these. That would be pretty quick to load on our fast internal network from purely a data perspective. And we would probably be fine with this running every 10mins or so, the purpose is really to just give people a reference to pull up to see what pvs are on a network. But maybe there are EPICS protocol details I don't know about that slow that down, I haven't actually tested it. I would argue that dumping pvxlist into postgres (which would take a few seconds) then querying that is quite a lot less complex than channel finder, which seems to involve 3 separate services, one of which runs on the IOC itself, its own custom binary protocol, udp broadcast, python 2.7 etc.

As a team, we are still evaluating which way to go in terms of configuration management. I personally think that storing configuration data in edge nodes, then broadcasting that in is a bad idea. In my ideal setup we have all .db information in the form of a relational database, and as part of the IOC deployment process, that information is templated into a .db file (and all the other epics shell stuff) then deployed using a generic IOC image (for each device type). Something similar would be done for p4p servers, probably directly using the relational db. This is roughly the approach used by ibek I believe but they use yaml instead of relational db. In terms of the "live" information like whether the IOC is active or not, I would use the IOC stats module.

I would be interested to hear what your opinions are on what the best approach is, given your considerable experience in the area.

In my ideal setup, you wouldn't even need the pvxlist as all the pv metadata would be centrally stored. But using pvxslist would be a good sanity check.