presslabs / cobalt Goto Github PK

http://www.dabeaz.com/coroutines/Coroutines.pdf
http://sdiehl.github.io/gevent-tutorial/

• General Description
• Pros / cons
• Implementation decision

after please close PR #4

https://github.com/containership/node-btrfs/blob/master/.drone.yml

• Python nu are require_once equivalent, daca ai ceva in global scope si dai import poti schimba referinte din alte module ce depind de tine, daca is incarcate de mai multe ori.
• Importuri circulare - cum sa scapi / bad smell?
• __init__.py +__all__

Each possible failure must have all these points covered

• General concept + Detailed explanation
• Affected components + risks
• Solutions / preventions
• Steps to reproduce (time slices /order of events)

Fallacies of Distributed Computing

{
"name": "test",
"state": "cloning",
"meta": {
"test": 1
},
"requested": {
"reserved_size": 2,
"constraints": ["test2"]
},
"control": {
"parent_id": 234567
}
}

Api-> scheduling -> pending -> cloning (attach node) -> pending without parent_id -> requested = like the parent -> ready

When deleting from the api it should check if the volume has clones pending.

test_process_with_watch_ignore_ttl_deleting

Also move the tests for the methods moved into the parent.

Engine fallback, agent not deleting / loosing data,
or causing duplicates.

And also provide Location header for the resource url.

Also write tests for it.

Each btrfs root mount should have a marker as a file that dictates the machine name. Each agent should pick that up at boot, otherwise registered volumes risk getting orphaned.

This is partly covered by the integration tests. Maybe not 100% necessary.

• What components
• How are they linked
• What needs to be managed by cobalt
• what is out of its scope

Splitting this issue in #63 and #62

Depends on #51

On a post with an id set consider it to be a clone request.

http://blog.hownowstephen.com/post/50743415449/gevent-tutorial

Coroutines in gevent have to yield before blocking operations, that yield can't be done if the code uses C for doing the blocking part. To fix this one has to rely on pure python equivalent implementations => slower.

Asyncio can deal with this just fine as it itself is partly written in C and handles that just fine.

Then stop the leader and see it fallback.

It should be at the first level, or at the etcd key level.

For instance if the current leader dies off, the others are waiting in a perpetual loop,
after another one becomes the leader it will not know what index to start from it will start from the beginning of time / etcd raft index batch thingy.

perform an initial GET and capture X-Etcd-Index
for the first watch, use that as the waitIndex
for subsequent watches, use the previous response's modifiedIndex as the waitIndex

Have a watch timeout and then restart the process -> health check cronish

It should accept 2 mount points,

The disk, and the config

The one without a parent.

Python vs Go

• Similarities / Differences -> paralelism / controll etc
• Good to have concepts
• Kubernetese / etcd / fleet written in Go why?
• Community / Ease of testing / Library multitude
• Choice -> Fast prototyping

For the api if the conclusion is to go for Go

https://realpython.com/blog/python/python-ruby-and-golang-a-web-Service-application-comparison/

Something even faster than Martini and seems to be remarkably similar.
https://gin-gonic.github.io/gin/

And explain why Cobalt is more appropriate.

Or consider using http://stackoverflow.com/a/16524426

• Why the separation (Pros & Cons)
• Decoupling / Security

• What will we manage
• What can the user change
• Resources implicated

All etcd related code should be wrapped in try..catch