Open bmpotter opened 4 years ago
@bmpotter Can I work on this issue? I started experimenting with Open Horizon through the all in one deployment and this seems a useful utility.
@bmpotter, I have a few questions, these utilities are they meant for when any of the above 4 has a change in the source code? You mentioned only the binaries by which I guess you meant horizon
and horizon-cli
packages. Also, should a way be added to reflect the updates made to the source code not only from the remote but from local also?
I also wanted to ask is there a reference to how the agbot image was built for this utility. Some parts of its working is still a mystery to me (I did find how the e2edev-agbot was built, is it similar?).
Thanks.
The primary use case i had in mind is: i'm a developer wanting to make some code changes to 1 of the mgmt hub components. So i need to make my code changes, build it, and get it running in the mgmt hub so i can test it. The mgmt hub components are all docker images, so the straightforward way to do this is build the docker image with an updated version/tag, and run deploy-mgmt-hub.sh -u
to get it running. But that is a slow iteration cycle when you need to code/test a lot of times. The more streamlined approach is to rebuild just the executable (usually what is started by the start cmd of the docker image), then copy it into the running container, and run deploy-mgmt-hub.sh -r <container
. This technique needs to be tested for each mgmt hub component, documented, and if necessary provide small utility scripts to make it as easy as possible.
A similar approach could apply to the agent: rebuild the anax
executable, replace it on the host, and run systemctl restart horizon
In the all-in-1 environment, a few utilities would help to automate the development process of building the modified source code of 1 of the components (agbot, agent, css, exchange, sdo) and restarting the service with it.