On Thu, Oct 17, 2013 at 01:45:14PM +0200, Stephan Kulow wrote:

Hi,

For years everyone having to touch the webui gets frustrated that he can't access the DB as good rails applications do. So we introduced new routes in the API to dump raw .json for things the webui needed and similiar nasty things that always meant having 2-3 places to change if you wanted to have a new feature in the webui.

So Ancor and me did some research how to make the webui access the API models in the most sane way and I went ahead during hackweek (where I was home sick, but that's another story :) and made the webui a rails engine as part of the API. You can read about rails engines at http://guides.rubyonrails.org/engines.html - engines are basically rack apps within rack apps and the magic is in config/routes.rb of API:

mount Webui::Engine, at: "/webui2", as: 'webui_engine'

Webui::Engine is a 'gem' that lives in src/api/webui and looks very familiar to everyone who knows the old src/webui. The main difference is that everything is in a namespace to avoid clashes between API and Webui code. E.g. src/webui/app/controller/home_controller moved to src/api/webui/app/controllers/webui/home_controller.rb (i.e. one more /webui in the path).

This makes it possible to use API models directly in the Webui code, but it needs to be done with care as the permissions handling is right now done purely in API controllers. So there are quite some things we can cleanup, but first I want to finish the merge.

So if you now `rails s` in API, you get a /webui2 route that should look very familiar. As the webui code still calls into the $api, I switched development rails server to unicorn and it starts 4 "workers", one will be the webui and one the API, but for some reason 2 workers stalled at times, so I went for 4 :)

For testing it's even more complex as the test case can't call into itself, so I still start a webrick "test API" and this had some fun consequences as there are now 2 API processes during testing, one being the test case and the other the test API. To make caching work (i.e. one process being able to delete the cache when things become inconsistent) I had to switch testing to memcached store, which is rather sad.

And I also had to switch away from transactional fixtures for the webui tests as this required a transaction in both of the above processes and I was unable to make one process reading the INSERTS of the other reliable (in case someone thinks 'transaction isolation level' now - it's not reliable :). So after a lot of hair pulling (and people knowing me know how hard *that* is for me), I went for database cleaner truncating the tables after each test case and refilling the fixtures. This is fortunately not as slow as it sounds.

I already started to move code out of the webui controllers currently in the API "back" into the webui. As I said, it needs to be done with care, but it feels to good to sanitize the code.

I also started to deploy the code on build-test.opensuse.org, but they show some problems with the deployment, that I need to fix before we can go on.

Hi Stephan, even if I was able to get about 50% of information, I'd say good work and thanks for that. I am looking forward for better webui for OBS. Thanks for your work Michal Vyskocil

Greetings, Stephan

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org