This project was created to house edge micro-services that can be easily built, tested, and published to any open horizon management hub.
Open Horizon documentation repository coming soon! For the time being, you can learn more about Open Horizon here.
Before you can publish and use any of the services in this repository, you must first deploy your own Horizon Management Hub. This can be done with one simple command using the deploy-mgmt-hub.sh script located in the devops repository. This will give you with a Management Hub with several services, policies and patterns published in the exchange.
Edge nodes must first be registered with a Management Hub before services can be deployed to them. The agent-install.sh script is a fast and easy way to register an edge node with a Management Hub, more information can be found in the open-horizon/anax repository. Edge nodes can be either a device or a cluster. Open Horizon edge cluster capability helps you manage and deploy workloads from a management hub cluster to remote instances of OpenShift® Container Platform or other Kubernetes-based clusters.
Typically, edge devices have a prescriptive purpose, provide (often limited) compute capabilities, and are located near or at the data source. Currently supported edge device OS and architectures:
If you have a service you would like to contribute to the open-horizon-services project, please login or create a Matrix account if you have not yet, visit the open-horizon-examples on the device you are logged in with, and press Join the discussion. Upon doing so, your account is enabled to send public messages in this room. Then, send a message in the room that follows the example below; it contains the tag #new-edge-service, notifies @tfine:chat.lfx.linuxfoundation.org (this address is able to be selected from the dropdown menu after typing @tfine), and contains a brief description of the service you want to add, the desired name of the service, and a list of the github usernames of each maintainer/contributor you would like added to your new repo(s). Please note, we do have a naming convention where microservices designed to be a building-block and incorporated into a variety of edge solutions, like service-mqtt, are prepended with "service-".
You may follow the format of the following example for your message in the chat:
new-edge-service @tfine:chat.lfx.linuxfoundation.org Hello, I would like a new service repo created with the name of {name}. The maintainers will be {@maintainer1, @maintainer2, ...}
Each service in the open-horizon-services project has a similar structure, and set of files, in an attempt to make each service as easy as possible to build, test, publish, and deploy. See the web-helloworld-python service for an example of the minimum set of files a service should have.
init - mostly used for operator services to create the scaffolding of a new operator, or any form of code generation required to buildbuild - build the containerdev - open a shell in the container for development, with source dir mounted. See web-helloworld-python for an example of how this is donerun - run container locallystop - stop and remove the containeragent-run - deploy the container to your edge node using the agentagent-stop - stop the container running from agent-run test - assumes container is running. See web-helloworld-python for one example of how this can be donepush - to docker compliant registrypublish - verify and publish the serviceclean - calls stop and also removes the container imagedistclean - clean as much as possible, e.g., remove all container and all images, and docker network prune, etc.Each service should at least have a service definition json file that can be used to publish the service to a management hub. See the service.json file of the web-helloworld-python service for an example.
Similar to the instructions above for contributing a microservice, if you want to add a top-level service that is designed to be used as a deployment pattern or policy, we ask you still create a post on the Matrix chat server open-horizon-examples channel and tag it with #new-edge-service, provide a brief description of the service, and include a list of the github usernames of each maintainer/contributor you would like added to your new repository. However, the name of your edge solution should be capitalized, similar to the Achatina (add link when we have it merged) service.
init - mostly used for operator services to create the scaffolding of a new operator, or any form of code generation required to buildbuild - build the containerdev - open a shell in the container for development, with source dir mounted. See web-helloworld-python for an example of how this is donerun - run container locallystop - stop and remove the containeragent-run - deploy the container to your edge node using the agentagent-stop - stop the container running from agent-run test - assumes container is running. See web-helloworld-python for one example of how this can be donepush - to docker compliant registrypublish-service - verify and publish the servicepublish-pattern - publish the pattern using the properties defined in the pattern.json fileregister-pattern - register an edge node with the published patternclean - calls stop and also removes the container imagedistclean - clean as much as possible, e.g., remove all container and all images, and docker network prune, etc.Each service designed to be composed as a deployment pattern should have a service definition json file and a deployment pattern json that can be used to publish the service to a management hub. See the service.json and pattern.json file of the Achatina (add link when we have it merged) service for an example.