When cybernode is operational - it should be able to rebuild itself and update. It should be independent of external services, network parameters etc. We still rely on CircleCI and Travis for delivering builds, and DNS and TCP/IP to resolve and fetch cybernode components and software sources. An abstraction should be put in place to decouple cybernode from these dependencies. This is what this is issue is about.
[ ] draw lifecycle diagram
[ ] components in each step can be switched/upgraded
[ ] components can be added as step alternatives
[ ] each component has evolution path to other component
[ ] evolution path can addition of subtraction of features and bugs
[ ] evolution path can be path of following pros and cons
[ ] there is one main path (current version)
[ ] draw control loops
[ ] put two user stories with diagram (current build, independent build, specific build, ...)
When
cybernodeis operational - it should be able to rebuild itself and update. It should be independent of external services, network parameters etc. We still rely on CircleCI and Travis for delivering builds, and DNS and TCP/IP to resolve and fetch cybernode components and software sources. An abstraction should be put in place to decouple cybernode from these dependencies. This is what this is issue is about.[ ] draw lifecycle diagram
[ ] draw control loops
[ ] put two user stories with diagram (current build, independent build, specific build, ...)