What I'm up to

[Tom Buckley-Houston]

Hiya,

With the great news that 

https://github.com/nuxlli and

https://github.com/rogerleite are building on Openruko with their Azuki platform I'd just thought I'd say what I'm working on, in the hope that no-one's working on the same thing at the same time.

I've already implemented separation of the API server and Dynohost server.

Next I will try and get vagrant-openruko automatically building on drone.io, so we have CI alerts.

Then I will go through all of Openruko's code and comment on everything that I understand, in order to help new people coming to the project. I will also create a new doc in the repo that outlines how the entire platform actually works.

Then I will be implementing a crediting system (only for slotbox initially), that builds of the existing heartbeats functionality, it won't accept money, but it will deny access to dynos if an app doesn't have enough credits. I will be most interested in talking to the Azuki folk about this.

Then I will think of launching Slotbox itself.

tom :)

[Romain]

Hi, 

The separation of API server and DynoHost server is a great contribution !

Without that it was not possible to use OpenRuko in a cluster.

The CI is always welcome ;) It's good to know that the repo is in good state before coding.

I think we can start an architecture documentation.

In CloudFoundry, this non official doc is really great : http://apidocs.cloudfoundry.com/router

I think we can get inspiration from it.

One of the advantage of OpenRuko is that it's easier to setup and understand than OpenShift or CloudFoundry.

2013/3/29 Tom Buckley-Houston <t...@tombh.co.uk>

tom :)

--
You received this message because you are subscribed to the Google Groups "OpenRuko" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openruko+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeff Lindsay]

You guys should be building around Docker (docker.io) now that it's released. ;)

--
Jeff Lindsay
http://progrium.com

[Romain]

https://github.com/openruko/dynohost/issues/16 ;)

2013/3/29 Jeff Lindsay <prog...@gmail.com>

[Romain]

buildstep and gitreceive looks interesting too ;)

2013/3/29 Romain <fili...@gmail.com>

[Jeff Lindsay]

With enough good primitives, I should be able to throw together my own Heroku pretty easily. :D

I'm hoping OpenRuko produces more independently useful primitives, as opposed to the CloudFoundry approach of: "yes, they're independent components, but strongly coupled"

[Romain]

I don't know if you already tried it, but you may like it : https://github.com/heroku/slug-compiler

2013/3/29 Jeff Lindsay <prog...@gmail.com>

[Jeff Lindsay]

Not yet! Awesome. I wish they'd open their streaming rendezvous infrastructure.

[Romain]

You can also check this : 

https://github.com/technomancy/sokoban

https://github.com/ddollar/mason

https://github.com/nzoschke/ngitx

https://github.com/nzoschke/code

They all works at Heroku

2013/3/29 Jeff Lindsay <prog...@gmail.com>

[Romain]

On my side I start a port of gitmouth in GO:

https://github.com/openruko/gitmouth/issues/2

2013/3/29 Romain <fili...@gmail.com>

[Jeff Lindsay]

Implementing SSH in Go? Sounds rough. 

[Romain]

Ssh is already implemented http://godoc.org/code.google.com/p/go.crypto/ssh

Le vendredi 29 mars 2013, Jeff Lindsay a écrit :

Implementing SSH in Go? Sounds rough. 

On Fri, Mar 29, 2013 at 3:12 PM, Romain <fili...@gmail.com> wrote:

On my side I start a port of gitmouth in GO:

https://github.com/openruko/gitmouth/issues/2

2013/3/29 Romain <fili...@gmail.com>

Hi, 

The separation of API server and DynoHost server is a great contribution !

Without that it was not possible to use OpenRuko in a cluster.

The CI is always welcome ;) It's good to know that the repo is in good state before coding.

I think we can start an architecture documentation.

In CloudFoundry, this non official doc is really great : http://apidocs.cloudfoundry.com/router

I think we can get inspiration from it.

One of the advantage of OpenRuko is that it's easier to setup and understand than OpenShift or CloudFoundry.

2013/3/29 Tom Buckley-Houston <t...@tombh.co.uk>

Hiya,

With the great news that 

https://github.com/nuxlli and

https://github.com/rogerleite are building on Openruko with their Azuki platform I'd just thought I'd say what I'm working on, in the hope that no-one's working on the same thing at the same time.

I've already implemented separation of the API server and Dynohost server.

Next I will try and get vagrant-openruko automatically building on drone.io, so we have CI alerts.

Then I will go through all of Openruko's code and comment on everything that I understand, in order to help new people co

--
Jeff Lindsay
http://progrium.com

[Jeff Lindsay]

Nice. You should write it to trigger a generic hook script like gitreceive. I'd even use it. ;)

[Matt Freeman]

And its a much nicer interface* than Python twisted, plus Twisted Conch is vulnerable to a DOS in some rare instances. The implementation at the moment is essentially a proxy, if the client is sending more information than the onward leg can handle it can cause some issues, you can see my poorly explained scenario in more detail here http://stackoverflow.com/questions/13117502/twisted-conch-flow-control , I never got to the bottom of validating the workarounds/solution on the Twisted framework

In comparison Go ssh library is a thing of beauty in terms of how streams are represented! I just didnt know about it at the time, otherwise I wouldnt have spent weeks with Conch, probably days with Golang.

Go is best suited to this type of work in my opinion, easy deployment, lightweight coroutines and no Twisted baggage.

--