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
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 ?
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
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)
To separate connections to different interfaces / IP addresses, you will need different instances of docker it self.
Rockons with different name / ID is possible.
You actually can have multiple interfaces created on single physical interface
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
@Tomasz_Kusmierz Just linking to the Contributing to Rockstor - Overview section of the official docs. Hopefully this contains the tutorial you were referring too. Now written and edited by a number of the founders and contributors so getting better all the time hopefully.
@seethap
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 . 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++) . I may see about adding one or two sections to the docs to clarify our directory tree.
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”)
. As one man said:
. I may see about adding one or two sections to the docs to clarify our directory tree.
), but for this type of a project, Python is more of less bang on !