Project

General

Profile

action #467

Update the webIU to control os-autoinst

Added by aplanas about 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Development
Start date:
2013-05-20
Due date:
2013-05-23
% Done:

100%

Estimated time:
16.00 h

Description

The new os-autoinst signaling system need to be managed from the webUI via named pipe. Create the UI buttons and implement the client side of the JSONRPC protocol

History

#1 Updated by aplanas almost 9 years ago

  • Estimated time set to 16.00 h

#2 Updated by ancorgs almost 9 years ago

  • % Done changed from 0 to 40
  • Status changed from New to In Progress

I spent a lot of time trying to make some javascript json-rpc client play nicely with our API. I finally give up and wrote a rpc proxy server side, so javascript asks the server (via AJAX) to do the real json-rpc call and to pass the result back to the browser. It should be very easy to remove that proxy and use a real javascript json-rpc in the near future, as the proxy is rather dumb.

Buttons for set_interactive, continue and step_waitforneedle are already working (not committed yet).

"Only" the needles editor is missing.

#3 Updated by ancorgs almost 9 years ago

I pushed the new interface today and also some changes to os-autoinst itself. A new line in apache2 configuration is needed (also pushed to the template /etc, of course). I'm having a lot of problems executing os-autoinst in my system, so I cannot verify that the new interface is running smoothly in every case, but I wanted to push it in order to get feedback. It's not worse than the one we already had.

Some improvements are still needed.

I also fixed some minor issues in the needles editor by coolo request.

#4 Updated by ancorgs almost 9 years ago

  • % Done changed from 40 to 80

#5 Updated by ancorgs almost 9 years ago

  • % Done changed from 80 to 100
  • Status changed from In Progress to Resolved

Updated to use the new jsonrpc centralized API instead of messaging the workers directly.

As the new API follows a new approach with the possibility of queuing/dequeuing commands, I spent some hours implementing a new interface for managing this queue in a very flexible way, but it ended being confusing and not really useful. So I dropped most of the work and implemented an improved version of the already existing good old approach.

#6 Updated by aplanas almost 9 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF