Runtime change/get of brick parameter/status

Bug #695811 reported by Abbakus
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Virtualbricks
Fix Released
Medium
Virtualbricks

Bug Description

With reference to bugs:

https://bugs.launchpad.net/virtualbrick/+bug/692285 (time based events)
https://bugs.launchpad.net/virtualbrick/+bug/692036 (brick's status info)

can be useful to have a way to change the parameters of running bricks (where applicable, for example wirefilter) and a way to get some status info of running bricks (wirefilter packet queue length for example). These two features, coupled with time based events can do:
-> Time based network events (brick-shutdown, brick-start, wirefilter loss percentage change, ...) using an event timer loaded with proper actions for parameters settings.
-> Update the GUI at fixed time interval with running-brick's status informations (wirefilter queue lenght, and so on), using an event timer loaded with proper actions for information retrieving.

I suggest to add a method to the Brick base class, named for example cmd_exec(string cmdname). This method connect to the management socket (if exist, is not open, and possibly keeping it open), write the cmdname and read the result then return it.

For example (wf is a valid wirefilter instance), doing

">wf getinfo <parameter>"

virtualbricks, using cmd_exec, show the retrieved status/parameter information
(i tend to distinguish between parameter and status, for example, in wirefilter queue length is a status info (read only), loss is a parameter and a status info too). Look at wirefilter command line showinfo command.

The same for ">wf setinfo <parameter> <values>".

At present wirefilter does not offer a way to get queue length status alone; I'm considering to implement this and other useful status informations as stand alone commands.

Of course the GUI need to expose a way to show the current status of a brick and the automatic refresh period (as gnome system monitor applet does for instance).

IMHO these features can be easily achieved on the first prototype and are of great impact and greatly increase the possibilities.

In attachment a trivial example of information retrieving via socket (the management socket of wirefilter must exist).

Revision history for this message
Abbakus (abbakus) wrote :
Changed in virtualbrick:
importance: Undecided → Wishlist
Revision history for this message
Abbakus (abbakus) wrote :

I forgot to mention that that new feature can be also useful to shutdown vde-bricks using the vde-shell shutdown command instead of sending SIGTERM. This is because SIGTERM is managed as SIGKILL by vde-components and there is not a "clean" exit which is needed while profiling using gprof (I already sent that bug report and a solution to vde project).

Changed in virtualbrick:
status: New → Triaged
importance: Wishlist → Medium
Changed in virtualbrick:
status: Triaged → In Progress
assignee: nobody → Virtualbricks (virtualbricks)
milestone: none → 0.3
Changed in virtualbrick:
status: In Progress → Fix Committed
Changed in virtualbrick:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.