Patch Set 2:
For me, this case is the same as the srs-enb pre-init scripts.
I agree with you that the best solution is to add these new features to OGT the way you propose (creating specific classes that add this support/features) and that's what we should do in the future.
Right now we're under heavy development, with a lot of changes and testing, so the idea of the pre/post init script is very good to us, because it allows to run utilities/scripts that will help us to debug the system. I see two big advantages with this: we can do it faster with a script that adding this new feature to OGT and some of this utilities may be temporal and don't make sense to add them to OGT(for example the dmesg before and after the launch of the srs-enb).
My proposal is to add the pre/post run scripts feature to the srs-ms and srs-enb. Then we can list and discuss the feature that each script adds and decide whether to add it to OGT or not (sometimes may be not needed because it's temporal, sometimes won't be worth it, because it's too unstable to add it and most of the times we will add them)
Does it sound good to you?
Patch-set: 2
CC: Gerrit User 1000186 <1000186@035e6965-6537-41bd-912c-053f3cf69326>
Patch Set 2:
So, after the discussions we had previously on this topic, what do you plan to use these for in the end?
IIRC this is to run device-specific stuff like making sure UHD device is fine, running dmesg, etc.
My proposal regarding this was to have device-specific ogt python classes handling all this, and then based on attribute config, load them from ms-srs, enb-srs, etc. Like the "BBU" class, or have a "UHDUtils" class (we could then for instance make use of it ourselves at sysmocom to reset the device if ever needed).
So I'm not saying I'm not going to merge this, but I'd like to find out what we conclude regarding those topics.
Patch-set: 2
Uploaded patch set 2.
Patch-set: 2
Subject: srs-ms: allows to run given scripts before the execution of the UE.
Commit: 7a57fa9a42
Tag: autogenerated:gerrit:newPatchSet
Groups: 785816a860
Patch Set 1:
Hi,
If you "don't want to give the ue the knowledge of what it is executing", then to me it looks like it's not the proper place to do it, since that's the object class which controls and manages one UE. Playing with lots of system-wide options there doesn't look correct.
All system-wide configuration should in general be done outside of OGT, since the idea is that you may end up running whatever else in the same node at the same time (be it from same OGT instance or another one).
I have the feeling you are trying to hook tons of generic features turning OGT into a full-blown network orchestrator, and hence you are adding a lot of complexity which imho shouldn't be here, since the environment is already complex enough. I don't want to end up with dozens of shell scripts to be moved and executed here and there if it can be avoided. And I'm pretty sure in the long run you don't want to end up there either.
I'm not against adding stuff like that if really necessary, but I'd really like to discuss them one by one and see how it can be done in a good way. What exactly do you need to check and how? What's the exact problem and what do you need to do to solve it? Feel free to contact me over email or jabber if you want to discuss this further. Also feel free to contact me if you plan to add new features, I may be able to give you some hints to drive you into a good direction from start and speed up your development.
For instance, in the case of powercycling the uhd device if it's not working, there's 3 ways I can quickly think could work:
[1] In the jenkins job / script calling osmo-gsm-tester, connect to the remote host where you plan to run stuff (if it's a static setup) and make sure it's reset.
[2] Have a systemd service running in each of those nodes which for instance is executed every 5 min and checks if no ssh user is in, then reset the device if needed
[2] If there's a specific command you want to call in order to clean up something, add that explicitly to OGT code, instead of generic scripts. You can even generate and scp bash scripts on the fly from within OGT. You can define new tags on run_nodes or srsue resources if needed too in order to mark specific actions.
Patch-set: 1
Patch Set 1:
> Patch Set 1:
>
> (1 comment)
>
> Again, this commit is missing information on WHY is this needed, or how is it going to be used. Without this information I cannot evaluate the commit and/or propose better alternatives.
Hi Pau,
Sorry about the lack of information. My idea behind this commit is to allow the srs-ue execute a list of given scripts before launching the program. I don't want to give the ue the knowledge of what it is executing, as it can be different scripts bases on a hardware model or other parameters.
For example, I'm using it to check whether the uhd driver is working properly or not, and powercycling the device in case that it is not working.
My idea is passing this scripts for the devices that need it and only execute it in those devices, independently of other properties. For example, 2 srsdevices can use uhd, but for any reason I just want to run the script/check in of them, so the script is passed to the one I want to check through the resources.conf.
Do you have a better idea of how I could achieve this??
Thank you very much.
Patch-set: 1
Patch Set 1:
(1 comment)
Again, this commit is missing information on WHY is this needed, or how is it going to be used. Without this information I cannot evaluate the commit and/or propose better alternatives.
Patch-set: 1
CC: Gerrit User 1000074 <1000074@035e6965-6537-41bd-912c-053f3cf69326>
Uploaded patch set 1.
Patch-set: 1
Change-id: I718e686b5844f2f07eda820914678052f1008182
Subject: srs-ms: allows to run given scripts before the execution of the UE.
Branch: refs/heads/master
Status: new
Topic:
Commit: 918cdddbf3
Tag: autogenerated:gerrit:newPatchSet
Groups: baaaa2ecd3
Private: false
Work-in-progress: false
Gerrit User 1000204