It would be possible to provide a full-automated deployment:
The administrator stores a new release into the GridFS by using the filename "release"! TODO: What happens, if the cluster is mixed UNIX and Windows servers and/or mixed 64/32 bits, etc.? Then, we would need different builds...
Running servers are polling these files every ~5 minutes
The current release state of every node inside the cluster is tracked by a own database collection. We need a unique hostnames for this! Every IP address inside the whole data center must be unique!
After an node has updated, the release information in the collection is updated.
At the startup, check if there is the ocean-upgrade application present. If not, do not run the automated upgrade thread for this machine!
After a node find a new release:
The current process downloads the new release and stores it in his root folder.
The current process starts the ocean-upgrade application and provides the current PID and his own application / executable name.
ocean-upgrade will shutdown the server, delete the last release, rename the new release and boots up the new release! TODO: Let say the node runs on FreeBSD: Here we need to execute something like "services XYZ start", etc. Maybe the necessary command or method should be configurable for every node?!
The application ocean-upgrade stops!
It would be possible to provide a full-automated deployment:
- [ ] The administrator stores a new release into the GridFS by using the filename "release"! **TODO:** What happens, if the cluster is mixed UNIX and Windows servers and/or mixed 64/32 bits, etc.? Then, we would need different builds...
- [ ] Running servers are polling these files every ~5 minutes
- [ ] The current release state of every node inside the cluster is tracked by a own database collection. ~We need a unique hostnames for this!~ Every IP address inside the whole data center must be unique!
- [ ] After an node has updated, the release information in the collection is updated.
- [ ] At the startup, check if there is the ocean-upgrade application present. If not, do not run the automated upgrade thread for this machine!
- [ ] After a node find a new release:
- [ ] The current process downloads the new release and stores it in his root folder.
- [ ] The current process starts the ocean-upgrade application and provides the current PID and his own application / executable name.
- [ ] ocean-upgrade will shutdown the server, delete the last release, rename the new release and boots up the new release! **TODO:** Let say the node runs on FreeBSD: Here we need to execute something like "services XYZ start", etc. Maybe the necessary command or method should be configurable for every node?!
- [ ] The application ocean-upgrade stops!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
It would be possible to provide a full-automated deployment:
We need a unique hostnames for this!Every IP address inside the whole data center must be unique!changed the description