42ity / fty-common Goto Github PK

One possibility is to include in this common lib a singleton object which can store any usefull informations for other agents.
2 Examples :
-Store the id and or the uuid of the rackcontroller, so an agent can get this informations from this singleton object instead of make a request to fty-info. Of course the singleton object will make a request to fty-info the first time an agent will request this informations => less request to fty-info.

-In our case, etn-ipm1 send a message to etn-amqp to notify any changes and etn-amqp will try to send this change to an IPM1 connected to the IPC or not !. So if the etn-amqp store the information "the ipc is connected to an IPM1" in the singleton object , the etn-ipm1 will check this information and send or not the change to etn-amqp. => less useless messages send between agents.

Instead of doing a bit of git magic to introduce sources along with their commit history into fty-common repository (so we can later inspect who did what - and why, thanks to commit messages, regardless of which repo hosted the code at that time) a snapshot of source files were just copied into fty-common making it as if an initial commit happened a few days ago. Original files are removed from fty-rest in the meanwhile, making it complicated to inspect their history.

A possible solution may be to make a clone of fty-rest repo (as of Mar 5 2018 or so; maybe using the advanced git commands to cut codebases into submodules etc.), and apply a series of "git mv" and "git rm" commands to rearrange it into current state of fty-common (and then overlay the changes done in fty-common afterwards). If this works well, it will add the searchable history without changing the current codebase state and without requiring an invasive force-push to the fty-common upstream repo.