Multiple use of RockOns and use of virtual network adapters

Hi all,

doing a litte development it would be really helpful, if one can use the rockOn feature to quickly set up a database, for a short test, and then take it down again, and do this for several projeccts in parallel. Out of this use case arrive two featuree requests

  1. would it be possible to give a “name” to a rockOn when it is installed such that it is possible to have two RockOns of the same type (eg database) be installed at the same time and run simultaneously ?
  2. would it be possible to add a “virtual network card” in the network setup with it’s own IP address, and allow at installation of the Rockon to specify which “card” to use. This would allow the “usual” behaviour of leaving the ports on default and addressing the different databases by individual ip addresses

Any thougths?



Actually I would like to see that feature as well (similar to some extent, like ability to hide database internally within system so it’s not accessible from outside)

  1. To separate connections to different interfaces / IP addresses, you will need different instances of docker it self.
  2. Rockons with different name / ID is possible.
  3. You actually can have multiple interfaces created on single physical interface
  4. virtual interfaces are possible as well,

Care to do some coding ? Any help helps :slight_smile:

Do mean me with help? I do vba coding for a living and have touched on python quite a while back on private terms out of curiosity, so not sure how much help I would be, but I would give it a try.


Hey, I’m a good old C person and a system architect, still managed to hack python around to put a feature in that I wanted.

There is a tutorial written by this guys on how to contribute to project - dead simple to follow, I felt weird following it “it can’t be that simple!”.

That reminds me I was supposed to ad the MAC for teamed interfaces :confused:

1 Like

@Tomasz_Kusmierz Just linking to the Contributing to Rockstor - Overview section of the official docs. Hopefully this contains the tutorial you were referring too.:slight_smile: Now written and edited by a number of the founders and contributors so getting better all the time hopefully.

If a particular desired feature seems a little large to start off with one can always pick an easier existing open issue to learn the ropes on.

@Tomasz_Kusmierz Hehe, good on you trying to get the whole community involved :wink:. As one man said:

It was nice to learn Python; a nice afternoon.

The languages are indeed not so hard to read, what I found the hardest part is figuring out how all the front/backend parts are connected together. This relies heavily on directory structures and still feels like a bit of an occult art to me, being used to compiled languages (C++) :stuck_out_tongue:. I may see about adding one or two sections to the docs to clarify our directory tree.

Isn’t this why we have Linux ? “if you want to use something cool for free - chip in and motivate other to do the same” :slight_smile:

I hate python with my gut ( embedded C background :smiley: ), but for this type of a project, Python is more of less bang on !

@sfranzen some explanation on:

  • JSON (most people have no clue what it is!)
  • that there are objects predefined somewhere in code and that those are sometimes duplicated (
  • which process is created from which file (with little python background, working out which file contains a source code for process fired from within CRON was “not fun”)
  • general high level view architecture (again working out whenever config data ends up in json or db is “not fun”)