[#MOP-23] provide a sysadmin feature for locking down the repo and going into offline mode

Forge: MOP

provide a sysadmin feature for locking down the repo and going into offline mode

Created: 03/Aug/09 06:22 PM Updated: 04/Aug/09 07:46 AM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

1.0

Description

« Hide

the current download of mop comes with nothing; so its empty. For it to be useful things need to be downloaded from typically the internet. Once the correct stuff has been installed, a sysadmin might wanna lock things down so mop turns into a offline mode by default; having all its requirements installed.

So we might want some kinda command so a sysamin could take a mop distro and lock it down.

e.g. from a clean install of mop

mop download activemq camel cxf
mop lock

this would download all the transitive requirements of those projects (using aliases - more on that later) - then mop 'lock' would lock things down, setting offline mode on by default (by writing to say mop.home/mop.properties "offline = true" or something).

folks could always disable this later, to download more stuff...

mop unlock
mop download servicemix
mop lock

To help with installing binary distros together with dependent jars; we might want to allow aliases for packages; even if we just encode some common ones in the out of the box distro.

e.g. to download/install activemq, you have to use...

mop install org.apache.activemq:apache-activemq:zip:bin:5.2.0 targetDir

we can default to zip/tar.gz based on platform; but we can't easily deduce what the binary distro is; so maybe we need some kinda alias

activemq -> org.apache.activemq:apache-activemq:${type}:bin:${version}

so folks can do either

mop install activemq
mop install activemq:5.2.0

in lockdown mode we might want to deafult to mop.home/repostory by default. in developer mode we might wanna reuse ~/.m2/repository

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Hiram Chirino added a comment - 03/Aug/09 07:58 PM

seems like your saying you can only install stuff when mop is "unlocked"
I don't think sysadmin need this at all.

I also don't like the download command. I'd rather call that install command.
and rename your install command to perhaps unpack | generate | create .

So for me the ideal most natural workflow for a sysadmin would be:

from a clean install of mop.. sys admin would let it know it's going to be in production mode.

mop mode production
mop install activemq camel cxf

this would download and install all the transitive requirements of those projects including project assemblies. Note that install runs in online mode.

To create an activemq instance.. you would run:

mop unpack activemq

And this would run in offline mode by default due to the production mode setting. If the assembly must have be previously installed.

[ Permlink | « Hide ]

Hiram Chirino added a comment - 03/Aug/09 08:00 PM

I think that making install/uninstall/list/upgrade be operations which exclusively relate to managing the mop repository would maintain things simple. It was kinda outlined in:
http://fusesource.com/issues/browse/MOP-7

[ Permlink | « Hide ]

James Strachan added a comment - 04/Aug/09 07:46 AM

BTW the reason I introduced the "download" command was to differentiate the execution commands (jar/run/exec/war/spring/guice etc) from the install commands (install/upgrade/list/whatever else - the rpm/yum-ish stuff) - where download purely just fetches remote stuff into the local repo without doing any kind of execution or unpacking. e.g. you might want to download the jars/wars for stuff; so that in offline mode you can then execute stuff (without doing a binary install).

If we were just building a kinda rpm/yum tool, things would be simple; we could just be like rpm/yum.

Though I see mop as being a variety of things to different people

an alternative to mvn/ant/java command line tools for dev folks wanting to run some java, jar, war, spring, guice, ear, jbi, bundle, whatever from the command line
a neat way for developers to install/run open source software itself, example programs, test cases, soak tests, performance tests and so forth without having to delve into mvn/ant/shell stuff
a sysadmin-ish tool for installing/uninstalling/updating software packages like the binary distros of activemq, servicemix, jetty, tomcat et al

The first two need to start in online mode unless the user turns it off. The sysadmin tool's install/update commands should definitely be in online mode by default.

But a sysadmin person would mostly just be installing stuff right? e.g. installing packages & services - setting up daemons and not actually arbitrarily running jar/war/run/spring/guice stuff from the command line? So the only real difference the sysadmin role for mop is that the execution stuff tends to be in offline mode for sysadmins - if they use those commands at all?. I wonder if sysadmins would ever use the execution stuff? Wouldn't they prefer an alternative to run/exec/war/jar/spring/guice et al - where they create a daemon/service/script to run things (which are in offline mode - only using local stuff).

Maybe we just need something like this...

mop [offline|online] to switch purely the execution stuff (everything but install/upgrade) to work in offline/online mode - this could then write to ~/.mop.properties the offline/online mode
install/upgrade default to online (would someone ever want an offline install - e.g. installing only from local repo?) - maybe someone who was super anal about what artifacts could be used could just limit the remote repos to a local-ish one on the intranet?
a sysadmin alternative to run/exec/jar/war/spring/guice et al - where instead of actually running things, we generate a kinda installation which has the same effect.

For example; a sysadmin would install binary packages like the activemq broker; but if they wanted to run a load testing producer/consumer which is just a (say) executable jar or spring main - they may want to create an offline install of the executable. Not sure what to call it, lets maybe say something like "mop package someDir name <command>")

e.g.

mop package fooDir123 runFoo jar myGroup:myArtifact:123

Then in the directory fooDir123 there would be a lib dir with all the jars required; then a script runFoo (with a .bat for windows) which sets the classpath and runs the jar?

[ Show » ]

James Strachan added a comment - 04/Aug/09 07:46 AM BTW the reason I introduced the "download" command was to differentiate the execution commands (jar/run/exec/war/spring/guice etc) from the install commands (install/upgrade/list/whatever else - the rpm/yum-ish stuff) - where download purely just fetches remote stuff into the local repo without doing any kind of execution or unpacking. e.g. you might want to download the jars/wars for stuff; so that in offline mode you can then execute stuff (without doing a binary install). If we were just building a kinda rpm/yum tool, things would be simple; we could just be like rpm/yum. Though I see mop as being a variety of things to different people

an alternative to mvn/ant/java command line tools for dev folks wanting to run some java, jar, war, spring, guice, ear, jbi, bundle, whatever from the command line
a neat way for developers to install/run open source software itself, example programs, test cases, soak tests, performance tests and so forth without having to delve into mvn/ant/shell stuff
a sysadmin-ish tool for installing/uninstalling/updating software packages like the binary distros of activemq, servicemix, jetty, tomcat et al

The first two need to start in online mode unless the user turns it off. The sysadmin tool's install/update commands should definitely be in online mode by default. But a sysadmin person would mostly just be installing stuff right? e.g. installing packages & services - setting up daemons and not actually arbitrarily running jar/war/run/spring/guice stuff from the command line? So the only real difference the sysadmin role for mop is that the execution stuff tends to be in offline mode for sysadmins - if they use those commands at all?. I wonder if sysadmins would ever use the execution stuff? Wouldn't they prefer an alternative to run/exec/war/jar/spring/guice et al - where they create a daemon/service/script to run things (which are in offline mode - only using local stuff). Maybe we just need something like this...

mop [offline|online] to switch purely the execution stuff (everything but install/upgrade) to work in offline/online mode - this could then write to ~/.mop.properties the offline/online mode
install/upgrade default to online (would someone ever want an offline install - e.g. installing only from local repo?) - maybe someone who was super anal about what artifacts could be used could just limit the remote repos to a local-ish one on the intranet?
a sysadmin alternative to run/exec/jar/war/spring/guice et al - where instead of actually running things, we generate a kinda installation which has the same effect.

mop package fooDir123 runFoo jar myGroup:myArtifact:123

Then in the directory fooDir123 there would be a lib dir with all the jars required; then a script runFoo (with a .bat for windows) which sets the classpath and runs the jar?