Kudos and General Questions

[Tom Buckley-Houston]

Hi there,

Just wanted to say what a fantastic idea OpenRuko, I'm surprised it's not getting way more exposure. It makes so much sense to do this seeing as things like the Heroku client and Buildpacks already exist.

I've managed to get the Vagrant VM running, it's passing most of the tests, but failing at 80-update at the moment, I'll have a bit more of a play and report back if I get stuck. I added the bridged mode to get access to the VM from my host. I might try one of those Vagrant to AWS tools, see if I can get this running out in the wild.

I'm interested in the choice of Node, is that just a preference, or are there other technical reasons for it? Also, I've never seen the use of Postgres functions like you've used for the API. Interested to learn more about these approaches so I might be able to help.

One thing that I haven't figured out yet is how you could spread dynos across multiple machines, so that you can scale OpenRuko itself. Is it simply a matter of having more VMs that just have dynohost running on them?

Thanks,

tom :)

[Maxence]

Hi Tom,

I don't have answers to all of your questions, but I'll try to answer.

Keep in mind that I'm not a core contributor and they might answer something else ;)

I think everybody here think that OpenRuko is a fantastic idea.It's still in it's early age of developpement, has  - from what I know  - been firstly developed more like a Proof Of Concept.

I'm think the project is not mature enough to face a massive exposure.

I'm not sure how you find OpenrRuko, but Matt did a great blog article on what he was doing this summer.

You are right, currently the update is not working properly. I know that @Filirom1 is working on it, but any help is welcome.

I'm not sure why Matt choose Node, but from my point of view, it's a great choice. 

As you see, there is no CPU intensive operation inside the code, and everything that we do (create a new repo, push, ...) is event based.

Concerning scaling, i'm not sure if somebody already tried this, but you got the idea.

Please let us know if you try this or launch an instance on AWS.

Max

--
 
 

[Romain]

With a reply to all it's better, 

Hi Tom, 

It's good to see that you were able to run OpenRuko with Vagrant.

I am quite interested in the Vagrant to AWS tools. If it works it will be awesome for Openruko ;)

OpenRuko is in early age. And the 80-update failure is due to a bug in the postgresql functions. I will try to fix it soon.

About node.js and postgresql, I am not in a position to answer you because I am not the creator of the project. But I really love node.js ;)

About scaling, OpenRuko will be scalable as soon as we change the httprouting with something better.

Curently httprouting proxy request to localhost, but we should proxy to the right host.

Then, you will be able to scale OpenRuko by adding more dynohost.

Dynohost do long polling on apiserver to get jobs.

The next big steps are: 

* implementing a good httprouting based on hipache

* fix skipped/failing tests in apiserver (I am trying to replace postgresql with redis for instance and provision_job. This is quite experimental but looks nice)

Cheers

2012/12/14 Maxence <max...@maxired.fr>

--
 
 

[Marsup]

Only to add up to the answer on "why Node.js", I would say that the very low memory footprint added to the ability to spawn servers and make them talk over a socket in a few lines of code make it a pretty good fit for the job.

And as already said by Max, the evented I/O aspect makes a lot of sense here.

[Romain]

This commit fix the update repo issue : https://github.com/openruko/apiserver/commit/1d63d8c79f27c62cf4c072589778c236d55fa3e8

2012/12/14 Marsup <mar...@gmail.com>

--
 
 

[Tom Buckley-Houston]

Thanks for all your replies. I've been having a lot of fun, playing with the VM and learning how everything works, it's complicated but fascinating. I've managed to get it working by pushing a repo from my host machine to the VM, so next step AWS!

Everything seems to be working, apart from occasionally Postgres won't start up on boot, it errors because it can't find (or doesn't have permission to access the lock file). I haven't been able to find a reproducible cause though.

I've learnt a lot and should really write up some notes about it, because there's so many different parts and it's not all documented. It'd be nice to have more more verbose commentary in the code too. Also, I wondered whether it might be useful to have dev branches for the critical repos seeing as they are being pulled in live each time Vagrant runs the Chef recipes. That way there could be more stability in the VM builds.

The reasoning behind Node.js makes sense, it is great for concurrent programming and has an extremely light memory footprint and blazing speed. What about off loading API logic into Postgres functions? I've never seen that before, apart housekeeping functions for managing cascades and triggers and so on in MySQL.

So I actually have a use case for OpenRuko, it's essentially a crowd-funded Paas, I've blogged about it here http://tombh.co.uk/crowdfunded-paas/ Seems a bit ambitious but I'm going to try and get a working prototype running.

I'm wondering how such a platform can be managed once it's up and running, how do you do continuous integration on such a complex platform. Can Chef handle all that? Or perhaps something like Cloud Foundry's BOSH would be better?

tom :)

[Maxence]

Hi tom ,

I'm glad you succeed to make everything working, looks like the Vagrant VM was a good idea.

I haven't notice yet the problem with Postgres, but to be honest, i don't really stop and restart the VM.

It would be great if you could write documentation ;)  

Filirom1 made some times ago somes slides about the mechanisms inside Openruko, but I can't find them. It would be great if he could (re)share  them.

About the dev branch, I can't remember about a release version of the project.

This might come, but until now it was not possible at all.

Moreover, keep in mind that currently, the code is nowhere ready to production.

Thanks to the last commits, it seems just stable enough to run and be used by a single user (or very trusted persons) on your developer machine.

Finally, the Vagrant VM has mainly been done in order the help the developers of the project to run it.

I started last week a chef-solo installation based on the recipes of the VM. This might be a better way of installing the system on a existing linux. Please remind me if I don't to share it. 

About the Postgres functions, this is a choice of Matt. He is really experimented with this. 

I'm not sure about that, mainly because it requires competences and I think it's bad for testability.

I'm not sure of your definition of continuous integration, and at which level do you see it.

If you think about an apps, it will be handled directly by openruko.

If you think at the platefoms levels, I haven't think much about that. 

Chef might be enough if we don't increase complexity much. (CloudFoundry made BOSH because they have something like 40 different types of machines).

I've seen in your blog post that you studied cloudFoundry. Did you have a look at openShift and what's your opinion about it ? 

Max"

tom :)

--
 
 

[Romain]

Hi Tom,

Le dimanche 16 décembre 2012, Tom Buckley-Houston a écrit :

Thanks for all your replies. I've been having a lot of fun, playing with the VM and learning how everything works, it's complicated but fascinating. I've managed to get it working by pushing a repo from my host machine to the VM, so next step AWS!

For AWS we will need to refactor chef recipes, to remove reference on the vagrant user.

 

Everything seems to be working, apart from occasionally Postgres won't start up on boot, it errors because it can't find (or doesn't have permission to access the lock file). I haven't been able to find a reproducible cause though.

Quite strange about the postgres boot error. Never see it before...

 

I've learnt a lot and should really write up some notes about it, because there's so many different parts and it's not all documented. It'd be nice to have more more verbose commentary in the code too. Also, I wondered whether it might be useful to have dev branches for the critical repos seeing as they are being pulled in live each time Vagrant runs the Chef recipes. That way there could be more stability in the VM builds. 

Sure, if you want to blog about what you learned in OpenRuko, we will be pleased that you do so ;)

Since Friday, we use OpenRuko in production. It doesnt mean that OpenRuko is bug free, but it implies that we will now split the master branch (dev) from the 0.1.x branch (stable). We also need to refactor the postresql setup script to use migration tools, ...

The reasoning behind Node.js makes sense, it is great for concurrent programming and has an extremely light memory footprint and blazing speed. What about off loading API logic into Postgres functions? I've never seen that before, apart housekeeping functions for managing cascades and triggers and so on in MySQL.

I am not at ease with psql scripts but it does the work quite well.

 

So I actually have a use case for OpenRuko, it's essentially a crowd-funded Paas, I've blogged about it here http://tombh.co.uk/crowdfunded-paas/ Seems a bit ambitious but I'm going to try and get a working prototype running.

So good, 

 

I'm wondering how such a platform can be managed once it's up and running, how do you do continuous integration on such a complex platform. Can Chef handle all that? Or perhaps something like Cloud Foundry's BOSH would be better?

As I said before, it will be easier with stable branch and db migration tools:

https://github.com/openruko/apiserver/issues/8

This issue too need to be done

https://github.com/openruko/dynohost/issues/9

 

tom :)

--
 

Cheers 

Romain

 

 

[Romain]

Yes you're right right Maxence, the slides are hosted here: http://prezi.com/lm189lyg-ums/openruko/

Keep in mind that at this time, I was very new to the project. So some pieces are not totaly exact, but the whole picture is there.

[Romain P]

Nowhere to production is quite harsh. It is not as ready as OpenShift or CloudFoundry. But we have it working on a single server and have few internal projects deployed on it. But nothing very serious.

Keep in mind that it´s still under developement, but we will now try to keep a stable branch and make migrations possible.

[Matt Freeman]

Hi guys,

Why node.js?

Mainly because it was what I was working with at the time, but I think the event loop fits quite well, I know there are shoe horned solutions with Ruby (EventMachine) and Twisted (painful) but node.js was out the box, plus good lightweight libs for what I needed to do. The only other one I consider is Go-lang, but Im still a newb at go, I was intending to rewriting the gitmouth in go as the crypto/ssh library is a thing of simplicitic beauty in a quick sprint I did and it would remove all the ballache of Twisted Conch.  Unfortunately past few months Ive been drowning in multiple projects, slipped deadlines, and unexpected annoyances (~4 days without power etc..)..

Why postgres?

If I was to start again i would keep the domain model entirely in memory, and log the events that cause the change to a transaction log, this would make testing super easy, and implements feature much simplier, and reduce the dependency burden. This is called event sourcing if not familiar, note of caution: .net/j2ee devs are making this area more complicated than neccessary so dont be put off by 440 page discussions mixing DDD with event sourcing - this is common in .net/j2ee for even trivial things like should a { be a new line or not.

Can it scale?

The dynohosts call into the API server, the API server makes them wait a period of time, and see what other dynos called in, it then  distributes jobs to  the leasts burdened dynos (well at least thats the plan, I cant remember if dynhosts is reporting number of dynos back yet). At this bridge the solutions were numerous but this 'pull' solution was the least painful in terms of introducing dependencies. I never intended openruko to scale to the level of Heroku, just a few dozens servers or so. We/you can certainly explore big-scale solutions though but I think we should get openruko solid.

And just note, thanks for all the commits and patches, and special thanks to Filirom1 for taking the lead on this project.  I hope to get some time in new  year to get back involved.

On 18 December 2012 05:50, Romain P <fili...@gmail.com> wrote:

Nowhere to production is quite harsh. It is not as ready as OpenShift or CloudFoundry. But we have it working on a single server and have few internal projects deployed on it. But nothing very serious.

Keep in mind that it´s still under developement, but we will now try to keep a stable branch and make migrations possible.

--

--
Matt Freeman - @nonuby - http://blog.nonuby.com

[Maxence]

On Mon, Dec 17, 2012 at 11:50 PM, Romain P <fili...@gmail.com> wrote:

Nowhere to production is quite harsh. It is not as ready as OpenShift or CloudFoundry. But we have it working on a single server and have few internal projects deployed on it. But nothing very serious.

What I mean is that the solution is working well but (The current master) can't be used for running non-trusted code.

 

Keep in mind that it´s still under developement, but we will now try to keep a stable branch and make migrations possible.

--

[Romain]

@Maxence you forget to mention that you write a pull request that completely isolates dynos. 

https://github.com/openruko/dynohost/pull/8

The isolation go even further that what Heruko did, because the network too is isolated.

Which means that an app in a dyno is not able to see that other apps are listening on 0.0.0.0

It also makes lxc debugging easier, because rurorun is not mandatory for the container to boot.

But I really need some times to read and understand what is done in the ubuntu template, before merging it.

And I dont have much time before Christmas :/

@Matt I didnt know that you thought of using event sourcing. Quite interesting. I am not at ease with psql, but my branch with redis proves that it is as complex as psql functions. 

I will take a look at domains and events, if it ease provisioning and instances management, it will be perfect.

Cheers 

Romain

[Tom Buckley Houston]

I was hoping to have more time to give a detailed reply, but I'm leaving for holiday without Internet now. But just wanted to say thanks for all the comments and links, really appreciate it.

Happy Holidays!
tom :)

[Tom Buckley-Houston]

Max, to reply to the point about continuous integration. I'm just wondering about how to manage a cloud infrastructure. I'm very familiar with how to develop a SaaS application, using staging environments and continuous integration servers like Jenkins and Travis for example. But how does one manage a PaaS!? How do you update multiple instances of the dynohost possibly running on different servers? I know of things like Chef's Knife, the Marionnette Collective and BOSH.

I did look into Cloud Foundry, I think it's an amazing thing and fantastic that it's open source and so actively developed. It's very complicated though, there are so many pieces to it, which is understandable. Of course Open Shift isn't open source and also is still in beta so I don't even know how much it's going to cost. The thing I like about Openruko is that it's simpler and doesn't seem to have the backing of any commercial interests, like VMWare in Cloud Foundry's case.

tom :) 

[Maxence]

Hi Tom,

Since I'm not very familiar with the tools you mentioned, I won't try to answer.

As a previously said, if you are asking about updating Openruko you might need theses tools. Playing with the reverse proxy would also be a good solution. 

We would also need some tools to move the container to a specific host, ...

About OpenShift, it is both a PaaS operated by Red Hat, and an opensource project running the PaaS. 

Max

[Tom Buckley-Houston]

OMG, I never realised OpenShift was open source and it's on Github too. It doesn't seem to work with AWS or Debian-based OSs, but still it's impressive. It does make me wonder about implementing my crowdfunded PaaS with it, but I still like Openruko a lot. I'll see how it goes.

tom :)