Admin refactor :)

[Fraser Scott]

Hi all,

The admin code needs a refactor so that we can extract stuff required by the admin and the agent commands. It is also a mess that needs to be cleaned up. I was thinking of using an approach loosly inspired by MVC.

Currently we have the core repo which contains relatively simple and mostly independant packages like x509, document, crypto, entity and fs etc. There are relationships within core, for example entity to document and entity to x509.

The admin repo (and tool) "implements" documents etc and ties everything together through the file system. So an actual CA is basically a serialised (json) CA encrypted in document container somewhere on the file system. Exactly where on the filesystem it is comes through from the admin tool with the filesystem itself managed using the core "fs" package.

As a breakdown of the current components in the admin repo, we have

cli

 - different files handle different commands, e.g. runNode.go for pki.io node <command> [...]

 - pki.io.go handles logging setup

concept of a nodeApp and adminApp

 - both use logging and can exit/panic the app

nodeApp

 - Sees the world like a node (agent running on a server) eventually will

 - node specific config file inside the "org" directory

 - a single server can be a node for different orgs

 - tries to implement common operations

adminApp

 - Sees the world as an admin

 - admin specific config

I was thinking of something like this for after a refactor

   $ pki.io ca update test-ca ...

* set up system-wide environment such as loggin etc in pki.io.go

* route to ca/update (controller/action)

* update() in ca controller creates a new CA "model" using filesystem setup and calls caModel.Update()

* update() in ca controller writes to log or perhaps to standard out (view)

* errors in update() write to log or perhaps panic() (view)

Some of the controllers would need to be used by both the admin and agent tool, so I thought perhaps we could have a "controllers" package in core. Or perhaps it would make more sense to have a controllers repo with a package for each controller. We would also need to have something similar for "models".

What is the difference between a CA "model" and whats in ca.go in core/x509? Good question. Either the CA model is another layer of abstraction that takes some sort of storage api object and implements the usual CRUD operations. Or, perhaps we shouldn't have separate models and that x509/ca.go should be updated to take the api object and implement CRUD along with all the other operations (e.g Generate, Sign etc)

In summmary, some stuff needs to be written to the admin filesystem in various places, some stuff needs to be written to the node filesystems in various places, and some stuff is either written to the filesystem or eventually to a web API.

Desparetely need your thoughts because now is the time to get this right. A major refactor again later will be an even bigger PITA.

Cheers :)

[Fraser Scott]

Finally have some sort of prototype.

https://gist.github.com/zeroXten/690d675cbdc3ac09fbd4

Any thoughts or questions?

[Jon Bonazza]

Looks great to me! Very clean! Things seem to be coming along. =)

--
You received this message because you are subscribed to the Google Groups "pki.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pki_io+un...@googlegroups.com.
To post to this group, send email to pki...@googlegroups.com.
Visit this group at http://groups.google.com/group/pki_io.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pki_io/1601238c-8ac4-46ae-96cc-ee98c5b10649%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fraser Scott]

:D

The APIs will probably need a lot of work later one, but just sticking to the current structure. I guess the "controllers" are the focus for the moment.

[Athanasios Kostopoulos]

+1 from me. Does that mean that we have an API structure that I can start working on?

To view this discussion on the web, visit https://groups.google.com/d/msgid/pki_io/CAE_GQbHkt8Td%2B5oL6SJcG0YpWkg4Xw8DPg0vhw2CihFhqkNz9A%40mail.gmail.com.

[Fraser Scott]

On Tuesday, 11 August 2015 08:19:14 UTC+1, athanasioskostopoulos wrote:

+1 from me. Does that mean that we have an API structure that I can start working on?

In theory yeah. The API as it stands at the moment content agnostic - it only really cares about storing and retrieving documents, and basic message queue functionality. All Org metadata is encrypted and stored in an index document. That will probably be fine for now, but I doubt it will scale to thousands of nodes without sharding or putting matadata in some sort of query-able structure. I guess if we just continue with what we've got, we can refactor later.

If you want to get an idea of the API, have a look at core/fs/api.go as this implements the filesystem version.