State of vb-debug branch

Dear Lars,
     Thank you for your interest on Virtualbricks. At present there
is a huge effort from Marco Giusti and Francesco Apollonio, two
students of mine (Apollonio actually has already graduated with me),
to get the Virtualbricks code ready to be released as 1.0 in a short
time (hopefully one month).
As a TLC professor, I am more a final user than an expert of the
code. In other words, I uses VB since its first versions, debugs it
and also suggests the features that seems to me necessary for both
research and teaching use of VB. I cannot answer all your technical
questions but I can provide you with further information about the
development state and aims.
1) the 1.0 (now in vb-debug) is based on a largely rewritten code; it
was in fact essential to improve the stability of the code; the
features are mostly (but not always) the same, but the code is often different.
2) a lot of past and present efforts are devoted to the project
management (menu file). In particular, projects are now identified by
the name of the directory where the project files are contained (one
directory for each project), instead of a number, which makes project
handling much easier. In the 1.0 it will be possible from the VB interface:
a) to export/import a project in just one compressed file
b) to delete a project (to be added in these days)
c) to save a project under a different name
d) to rename an existing project (to be added in these days)
The aim is to make straightforward the share of projects between
different users, by handling projects as it were files.
As a possible application example, in these days I am distributing to
my students one VB project for each lab activity. The students are
able to carry out the lab work, with the possibility also to go on by
adding complexity to the proposed layout and to save their
modifications under a different name. To build differentially,
starting from an existing project, is clearly essential also in
research applications to speed up the set up of new projects.
3) We still need some work both on the VDE Wirefilter code (or maybe
in a new branch of it) and on its graphical interface (which must be
totally redesigned) before getting ready for 1.0.
4) We still need to improve the usability of VB. I am taking
advantage of my present students (10 TLC and 10 computer science
engineering) as debuggers. And I can tell you that there are still a
lot of "small" things that can prevent a successful use of VB. We
have to fix all of these before releasing 1.0. In these days a new
internal debug version is released by Marco Giusti every week, with this aim.
Your comments are really helpful for this purpose too. I hope that
you can continue to provide us with them as soon as new debug
versions will be released. They are fully appreciated.
Yours,
     Carlo

At 00.06 04/11/2013, Lars Kruse wrote:
>New question #238583 on Virtualbricks:
>https://answers.launchpad.net/virtualbrick/+question/238583
>
>Hi,
>
>I am happy that I stumbled upon the virtualbricks tool. It looks
>like a good way for setting up complex environments for software tests.
>
>I pushed some minor changes and fixes to the
>lp:~devel-sumpfralle/virtualbrick/nitpicking branch.
>Please take a look, which commits you consider to be useful.
>
>Right now I reached the point where I cannot continue without
>touching the existing code structure. Thus I stopped and wait for
>directions or hints.
>
>
>I only see only few major issues with the current code:
>
>1) Network interfaces
>Interfaces of virtual machines and e.g. the Capture interface are
>not stored in the configuration file.
>Probably the handling/modelling of these settings is not finished?
>Or do you have a specific plan? Any details?
>The same goes for restoring the interfaces.
>
>2) State detection during startup
>The current code does not try to discover the current state of
>configured bricks, right?
>I would like to see that virtualbricks can be closed without
>stopping all bricks.
>
>But probably there are other things that need to be implemented,
>before the features of the trunk branch are restored, or? Could you
>summarize these, so I get a better feeling how/if/where I can continue?
>
>
>I have some more questions - maybe someone with a good feeling for
>the code can find the time to answer them:
>
>A) Do I understand it correctly that there will be a non-gui mode
>for running a previously defined setup from the command line?
>
>B) How will the connection to remote setups work in the future? Will
>it be two different setups connected together? Or will I be able to
>see/edit the remote setup? (just curious)
>
>C) What is the current set of communication channels? The linked
>mailing list is not reachable. Is there an IRC channel?
>
>D) What is the current state of the tests?
>
>
>keep up the good work!
>cheers,
>Lars
>
>--
>You received this question notification because you are a member of
>Virtualbricks, which is an answer contact for Virtualbricks.

First of all i'm glad to read that there are happy users of
virtualbricks all around the world.

Only two other considerations.

I'm currently outside my "office" (actually my home) and for this
reason I'll check your code in the next days.

Virtualbricks intends to be started without any check for bricks
already started outside virtualbricks itself, right now the only
exception is for the switch, infact vb can be linked to a switch
already started through the switch wrapper.

There is a way to create a "virtualbricks" server, always running
without a gui and configurable through a virtualbricks client that can
be closed after the configuration. Right now it's not working because
the code has been rewritten and we need to check/recode this feature.
it will be done probably for the 1.1 release.

Network interfaces' connections are saved into the .config file that
you can find in the project folder.

There will be a no-gui mode for vb in the release. now it there isn't
but it's a bug :)

In the future in a project you will be able to add some components
that actually will be executed on another machine.

we have some problems in the communication channels (official website
is offline and I'm waiting for a reply from Rainer that owns the
domain for the website, the mailing list is actually hosted by Daniele
but I don't know why it's down). you can find us in a IRC channel on
irc.freenode.org #virtualbricks or via email.

Francesco

Dear Lars,
I'm glad you find virtualbricks useful and I'm even happier to see your contribute.

I have to say I'm unprepared to receive external contributes so we are discussing these days the better way to include the code in the main repository. While the exact way to do it is not definitive we think that a big glob of code is unmanageable so another work-flow is necessary and we hope the following one is not only acceptable but favourable for both the sides.

My contribute in this discussion is highly influenced by this blog post[1], maybe it is interesting to you to read it just to know what are my basis.

[1] http://nvie.com/posts/a-successful-git-branching-model/

Here the proposed work-flow:

1. A bug report should be opened for each changeset.

2. A branch of the current development branch (vb-setup) should be created for each bug report and it must include only the code relevant to the bug linked. These branches can be, and usually they are, really lightweight at the point of they include only one commit. One of the commit should be linked to the bug report (bzr commit --fixed lp:#bugnum) but I'm not sure which one is the best, maybe the first one, but I don't know how this influence the overall workflow.

3. We check the branch, post comments and hopefully merge the branch.

As I said this work-flow is not definitive so you can contribute to improve it as you feel. I try to answer your question in the next comment.

Marco

> 2) State detection during startup

This will be a big step forward and I hope to see this feature on virtualbricks one day. I have some Idea how to implement it but now we are going to stabilize the code to release a major version of virtualbricks (1.0 :) so It is impossible for the feature to be included in the near future.

> But probably there are other things that need to be implemented,
> before the features of the trunk branch are restored, or? Could you
> summarize these, so I get a better feeling how/if/where I can continue?

The mailing list is a better place to ask this question.

> B) How will the connection to remote setups work in the future? Will it be
> two different setups connected together? Or will I be able to see/edit
> the remote setup? (just curious)

The idea is to have only one configuration, that is easier to manage. One possibility to improve virtualbricks is adding libvirt support but here I'm just imaging.

> D) What is the current state of the tests?

I'm sorry to say not good. I tried to add tests but the project require more man-power that I can give and many things are neglected.

Hi,

thank you all for your quick and comprehensive answers!

Shortly after posting my questions above I realized that currently some shell scripts will be sufficient for my specific purpose (non-interactive startup, configuration and shutdown of a set of mesh nodes). Indeed VirtualBricks helped me a lot to gain a good understanding of how to assemble all the technical pieces (vde_* and qemu) together efficiently.

Regarding the proposed methods of contributions: I consider myself just as someone who passed by, fixed some details I stumbled upon (configuration of capture interfaces, root privileges, ...) and studied the program for unrelated purposes. Out of this specific situation I would feel less inclined to follow a more regulated approach of documenting contributions. Thus I would suggest to just ignore all commits in my branch that do not expose obvious improvements on first sight.

Regarding the communication channels I would recommend to mention the IRC channel even if it is not well populated around the clock. Spontaneous short-term contributors like me will probably appreciate that a lot and thus deliver more usable commits.

I am curiously looking forward to the new release.
Have fun while improving this well structured code base!

cheers,
Lars