Package and update mrl , 100% automated

Hi !! looking for a clean solution to do it.

I want to automate mrl update and installation, end user side ( dev or master branch )

This is what I do today as a poc, fully automated  :

- detect if remote revision number has changed

https://github.com/MyRobotLab/inmoov/blob/master/InmoovScript/system/upd...

- Ask user to update

https://www.youtube.com/watch?v=iE9QTWzpNoo

- close mrl , replace jar + script ( soon it will be only jar )

https://github.com/MyRobotLab/inmoov/blob/master/InmoovScript/system/upd...

- Using this bat to force mrl installation ( problem ALL dependencies are redownloaded , it take a lot of time )

https://github.com/MyRobotLab/inmoov/blob/master/tools/RESET_MRL.bat

 

This worky great ! But I don't know all mrl subtilities, I think it can be enhanced. What do you think ?

calamity's picture

Hi Anthony Grog will probably

Hi Anthony

Grog will probably know more about it

You certainly don't need to install all dependencies, just the one that are required to run the script(s)

MRL have a nice feature that it will install dependency that are not installed when need. The problem is that the dependency is not alway usable when it just get installed.

I usually don't install all dependency before running MRL. I just lauch my script and if it need dependency not installed, it will download them and I restart.

Not exactly what you want (user should not have to manually restart when a new dependency is need), but it's probably possible to create an "install script" that create the services need in your inMoov script. That will download the dependency needed (instead of all dependency) and save a bit of time and bandwith

just an idea

GroG's picture

There is a whole service

There is a whole service dedicated to manage, restart, start new instances ....
Its called the "Agent"

Its purpose it to manage MRL instances, just as Runtime manages MRL services .
Everyone uses it, but they don't realize they do.

Whenever you start MRL your actually starting the Agent, and the Agent starts the MRL you use.

Take a look at processes explorer when myrobotlab.jar starts ..  it shows 2 processes.
The first one is the Agent's process .. started with "java -jar myrobotlab.jar"
It started the "real" myrobotlab instance - the one everyone uses, it contains all the necessary JNI & JNA command line entries, and default services to start.

How do you get to this service ?

MRL has its own command line interpreter.   I like using it.  
At the command line type "ls"
You'll see it list the current running services ..

You can inspect each service with the cli 
It has the same api as the webgui.
If I want to see the data of the runtime i can do this

ls /runtime

or look at the methods I can do this

ls /runtime/

or if i want to call a method I can do this

/runtime/start/arduino/Arduino

Pretty cool no ? 

But now to get back to the Agent ...  how do you get to the Agent from the command line ?  Its in a totally different process ! 

No matter, all you have to do is "detach" from the current myrobotlab process

detach

now when I ls I see the Agent's services in its process (I've moved from process to process)

The Agent can control many local instances of MRL.
It can start them, stop them, upgrade them etc...

To look at the processes the Agent is currently controlling do this

/agent/lp

lp is "list processes"

Here you can see I'm running 1 locally built mrl process - with process id 0

I could kill it - with 

/agent/kill/0

but lets not do that, instead lets start a UI

To show a UI I just start the admin webgui.

/agent/startWebGui

Grrr .. looks like the GUI's borked

Anyway - you "previously" could manage multiple mrl instances - with kill, shutdown & auto-update

Heh, 
Here is a previous post where it looks like your asking the same question ;)

http://myrobotlab.org/content/agent-or-how-mrl-starts 

moz4r's picture

Thank guys ! I will focus on

Thank guys ! I will focus on only needed dependencies

about the agent. I remember the initial discussion and worky great when I test it. I think I will look forward to use it, so I can remove a step, the reboot and manual replace step.
Problems we need to take care , exemple if I use the agent to update the jar, and if mrlcomm is a new version inside the new jar, mrlcomm.ino is not updated. Same problem about dependencies. So you confirm I still need this .bat to make a clean install after the update ? https://github.com/MyRobotLab/inmoov/blob/master/tools/RESET_MRL.bat

Or maybe I can do it java or python side, it is better I think ( but some folders cant be deleted if java is launched )

GroG's picture

The Agent was a good start to

The Agent was a good start to support multiple versions and automatic updates, but its not done.   It would have no problem starting, stopping, or even removing jars.  The challenge would be when it was necessary to update itself.   But even this could be done in a robust way ..

If you've ever played Minecraft - they start with a "Launcher" - which launches a version ..
The versions are (for the most part) completely isolated.

The Agent was a similar idea to this Minecraft "Launcher".  And the idea of seperate directories is an easy way to provide isolation between the versions.  
A "communal" directory for the repo - would allow all versions to use the same repo.  This concept works well too as the bulk of the repo doesn't change often compared to the rapidly changing myrobotlab.jar.

However, it would be worth having the "branch" name in the directory structure, and a repo as this corresponds exactly to what we currently maintain on github.

agent /
       devleop /
              repo /
                   myrobotlab.2021 /
                   myrobotlab.2022 /
                   myrobotlab.2023 /
       master  /
              repo /
                    myrobotlab.1723 /
                    myrobotlab.1758 /

Having a bat file isolates the functionality to Windows, and is a seperate piece.  Deployment is usually more desirable with fewer "pieces".  It was working this way for a while, but I took it out, because there were a couple things which broke, and people were confused of which jar was executing and where log files were.

juerg's picture

marytts

My process of updating to a new MRL version is creating a new folder, copy the myrobotlab.jar into it, start it up and select "install all" from the runtime. 

Yes, it takes a while but it usually doesn't bother me. With fast changing versions being produced of course an "autoupdate" with downloading only required jar's would be very welcome.

I run my MRL on ubuntu and have a german marytts jar. The problem here is that with my approach and every new version I also need to provide the language-jar into the libraries/jar folder AND remember to restart MRL after the copy.

Is there an option I can have that jar in my own marytts-folder and have MRL pick it up from there? Or would starting MRL with a script and do the copy before starting MRL be the simpler solution?

Your autoupdate might also have the problem that in many cases of MRL-failures the question is "did you do a fresh install into an empty folder" - so I assume - unless all these issues can be solved - the autoupdate will be of limited use?

GroG's picture

The Agent was designed to

The Agent was designed to install a new version of mrl into a new folder.  All MRLs of the same repo branch were to share the same repo.

There is some danger in auto-update .. in that it requires a restart of mrl, and you will loose the state of that running instance.  For example, what if you were working on a script and all of a sudden boom ...

A black-out time would be nice - at least it wouldn't interfere when you were actively using it ...  For example only update during the hours of 12:00 AM - 3:00 AM