You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be good if we can make Gini compatible with Python3, since support for version 2 will be dropped soon. Also, since the structure is quite complicated, we should improve the quality in terms of code commenting, modularization, following style guides, etc.
Add code commenting: This helps us understand how the GUI components interact and how front-end - back-end communicate. This makes debugging and improving routing/compiling algorithm possible.
Add tests and travis integration: There used to be TravisCI for Gini3: https://github.com/anrl/gini3. We can adapt from the old test suite and add more cases
Regarding modularization, the models on the backend and frontend are currently inconsistent, and I also think it's a good idea to separate components into 2(+) categories: host elements (end devices) and network elements (switch/routing devices)
When building Gini using Scons, it's better if we structure each component the similar to the source code, as in it should be split into lib/frontend and lib/backend. This makes adding/removing python packages easier
E.g: a python file can import another module using from backend import ... instead of using relative module path
ovs Python package: https://pypi.org/project/ovs/. They don't document this so it's rather unofficial or not really what we're using ovs for? We can have a look at this file however for some idea on how to bind ovs calls, and subprocess calls ourselves in general
One thing to consider is to run gbuilder (and consequently, other components) as root, so we don't need to change a lot of the configurations (setuid bits, wiresharks, docker, etc) during installation.
One obvious advantage of this is we can now run ovs-docker without having to create a netns directory and change ownership first. Since it's a bash script instead of a binary executable, setuid bit has zero effect.
Activity
trungams commentedon Mar 8, 2019
Regarding modularization, the models on the backend and frontend are currently inconsistent, and I also think it's a good idea to separate components into 2(+) categories: host elements (end devices) and network elements (switch/routing devices)
trungams commentedon Mar 10, 2019
When building Gini using Scons, it's better if we structure each component the similar to the source code, as in it should be split into lib/frontend and lib/backend. This makes adding/removing python packages easier
E.g: a python file can import another module using
from backend import ...instead of using relative module pathtrungams commentedon Mar 10, 2019
Rely on SDK instead of subprocess calls to manage docker (and ovs). Pox is already good to use
trungams commentedon Mar 14, 2019
One thing to consider is to run gbuilder (and consequently, other components) as root, so we don't need to change a lot of the configurations (setuid bits, wiresharks, docker, etc) during installation.
One obvious advantage of this is we can now run ovs-docker without having to create a netns directory and change ownership first. Since it's a bash script instead of a binary executable, setuid bit has zero effect.
https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts