I'd like to inherit my core projects from my main gateway into a secondary gateway. Basically, I want to be able to have a single source of truth for my core scripting and templating, but be able to have projects that depend on those things be running in another gateway. Is there a way / best way to do this?
Hmm, some options:
- CTRL+C, CTRL+V
- EAM Module
- Git?
1 Like
Okay this is maybe probably definitely a bad idea, but I wonder if you could use sshfs to mount the folder of the parent project on the remote gateway and then create a symlink to the mount on the local gateway under the appropriate data/projects/$projectName folder...
1 Like
Oy! Definitely. I can image a comms hiccup stalling the entire gateway.
1 Like
Seems like the EAM would be the way to go, thanks for that link. Does it support event based transfers if I want to force lockstep between the systems? Or does it only support triggered or timed execution?
While I could probably make the sshfs link work better than Phil might think, since I could be running both gateways containerized with access to reliable filesystems, I'd much rather use a supported mechanism for this.
I think you can create a "Send Project" task and then invoke it with system.eam.runTask.
Ok that might be the place to go, I can put that into a gateway script. Do you think it will behave as expected tucked into a Gateway Update script?
Looks like it mostly works, although I'd like to identify the file that is being saved during the update so that I can route to the correct EAM task and only sync a file that is handled in those tasks and only sync the file that was updated.
I accessed the 'resources' dictionary as referenced at the top of the "Project Update Script" window and it looks like {'modified': [{'name': 'event-scripts', 'path': 'ignition/event-scripts', 'resourceType': 'ignition/event-scripts'}], 'removed': [], 'added': [], 'manifestChanged': False}. What I really want is for it to spit out the project name; it didn't so I guess I will use system.util.getProjectName() which should work since this always has to be saved from inside a client designer.
I can't find a way to check upstream for if EAM Agent Tasks exist before I call them, the only system.eam options are "getGroups" (I guess I could put each of the agents tasks in their own group that has the same name and check that way? Seems clunky). I could call them and let them bounce if nothing exists to execute, but that is going to fill my log with unuseful errors.
I take it that it is not common to have multiple gateways that are kept in lockstep?
No, as this sort of thing causes project restarts, and that is often disruptive to production. Synchronization is scheduled for outage windows among my clients, for the most part.
It'd be pretty easy to set up rsync + cron nightly 
It really depends on how much you actually expect this 'core' to change, how critical it is that you get updates immediately vs eventually, and a bunch of other constraints only you are really going to know.
1 Like
I understand for a slower-evolving production system why we'd want to schedule at most nightly or developer-initiated syncs, but this system is in continuous development at a pretty fast pace so having the systems lockstepped could be a mode we are looking to have (amongst the other slower, more regular modes).
I've got it logic-gated in my gateway update script now (behind both permission and estop status tags), it seems to be working well enough
3 Likes
We are in the same situation as you. A single parent project that is used globally and is actively being developed and used in production. Go-Go-Go Fast-Fast-Fast. It’s not fun.
The grouping sounds interesting. Could you create a group of resources that are updated together, in EAM?
That would help with resource dependency.
I think you can yes, I've so far only gotten to individual agent tasks but there's definitely something designed for group execution in there
1 Like