Skip to content
This repository has been archived by the owner on Mar 21, 2019. It is now read-only.

Architect Roadmap #10

Closed
ghost opened this issue Apr 15, 2018 · 3 comments
Closed

Architect Roadmap #10

ghost opened this issue Apr 15, 2018 · 3 comments
Assignees
Labels
research Requires research

Comments

@ghost
Copy link

ghost commented Apr 15, 2018

Looking at what we have so far for the automaton spec from #3 :

A = Automaton {
  -- METADATA
  -- PROTOCOLSPEC
  -- DEPENDENCIES
  -- STATESPEC
  -- ARTIFACTSPEC
}

-> @olligobber #6 will look into the Protocol Specification using session types and other techniques so that the end user or us can provide a generic set of protocol specifications that Overwatch may use to do its packet analysis. I think this research into session types may also turn out to be a way to formalise @CMCDragonkai's ideas about automaton composition in #9. Will also continue to work on all the related monitoring/proiling techniques in Overwatch as he works on the specification.

-> @mokuki082 #8 will work on the Artifact specification in Architect and continue to work on the docker bindings in haskell, and associated configuration to do with virtual networks. The end goal here I think is to produce a unified interface that allows us to bring up the artifact on the local machine and network them virtually as required, through a single interface (and encode any details about the Artifact as necessary in Automaton as above). I'll be working in this area to integrate the interface with substituting the automaton names/content hashes listed in the dependencies inside the artefact, with the correct IP once the virtual network link has been established.

-> @Kneedler #11 I'll continue to explore the Dependency specification design, along with @CMCDragonkai's ideas about what it means to combine/compose an automaton (literally the possible ways we can classify different sets of interactions between two or more automatons), looking at if/how we can do dependency injection and live garbage collection of dependencies. I'll also work with @olligobber in this department to make sure that whatever model we choose for modelling dependencies between automatons integrates with the monitoring system information we can get from Overwatch (so that we have a path to automatically deploying automatons in some optimal configuration based on the monitoring system information).

@CMCDragonkai
Copy link
Member

We should convert this to the Github Projects Kaban Board style soon.

@CMCDragonkai
Copy link
Member

@Kneedler Can you figure out what are the implications of hash collisions on a distributed system? Like ours since we are going to have hashes pointing to Automatons and its friends.

@CMCDragonkai CMCDragonkai self-assigned this Aug 14, 2018
@CMCDragonkai CMCDragonkai added the research Requires research label Aug 14, 2018
@CMCDragonkai
Copy link
Member

CMCDragonkai commented Aug 14, 2018

This is now specced out in other issues.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
research Requires research
Development

No branches or pull requests

1 participant