Make plugin system for additional commands

[jorgemoralespou]

We need to find a way to add additional commands to provision stuff (nexus, gitlab, tech-preview,...) that will get the commands from a directory. Can be current or can be in the profile, although I think current is better, since then oc-cluster can always load additional commands that can be pulled from git.

This way we can move some stuff into the plugin mechanism, so that users can create their own without needing to modify this script.

[bjartek]

The simplest I can think of here is doing like they do with /etc/profile.d.

That is inside the profile we make we create a plugins.d folder. Then in the appropriate place in the run script we do

for f in $__profile/plugins.d/*.sh; do
    [[ -r $f ]] || continue
    . $f
done

We have to create some guidelines for how to write plugins. They should basically do all code in a function of their own and prefix it with the name of the plugin.

So say we want a plugin that enables jenkins pipelines. We have flag that turns it ok. And if it is on create a files in plugins.d called jenkins.sh. That jenkins.sh file has a jenkins_main function that is called at the bottom of it.

[bjartek]

I guess the plugin system has to restart the cluster once it is done customizing it. So the flow is

oc cluster up do all the plugins oc cluster down oc cluster up

or something like that.

[jorgemoralespou]

Well, there will be different types of plugins, and we'll need to better describe them: There will be:

• plugins that add runtime commands to manage the cluster (like snapshots, persistence,...)
• plugins that configure/bootstrap the cluster and require to restart the cluster (change config)
• plugins that configure/bootstrap the cluster but do not require restart (add templates, add software [deploy-nexus, deploy-gitlab,...])

We need to define how these will be implemented and described. Sadly I'll be next 2 weeks at conferences, but I'll try to use some time during these to think/document this. Feel free to keep contributing/discussing.

And by the way, thanks for all what you're doing so far, it's been amazing.

[jorgemoralespou]

Restarting a cluster works with:

docker stop origin && docker start origin

[jorgemoralespou]

Completions can be optional. I don't want completions to stop us from doing this, so if it's complex then it should have no completions.

[bjartek]

Have a look in my branch plugin-system.

It is pretty rough right now but it works for enabling pipelines even though you get an error after restarting the origin container.

https://github.com/bjartek/oc-cluster-wrapper/blob/plugin-system/oc-cluster

This script has support for adding thew flags and new commands. See the test plugin for a command and the pipelines plugin for a flag.

I use the an directroy in the filesystem as a dispatch table. filenames are commands/flags and the contents of the files are the name of the function to run.

A plugin can set the varaible RESTART_CLUSTER to true and the origin container will be restarted at the end of the run command

[jorgemoralespou]

@bjartek I'm reviewing this. To be honest, seems too complex, also as there's very few comments and I'm no bash expert, I'll have to look into it throughly.

/cc @GrahamDumpleton can you review this and make comments as well?

[bjartek]

I was really unsure on how to approach this. I do not know what skill set you people have, and do not want to step on toes.

I can always add more comments if that is needed to understand what is going on here.

My personal opinion on this (having coded bash almost daily for a year) is that we are approaching the real pain point here. Bash is simply not the best tool for doing a plugin system or creating portable complex stuff. My reasonings are as follows

• You do not know what version of bash the user is running
• You do not know the OS/arch (and there are differences)
• Using thirdparty tools is hard. You cannot guarantee a specific version unless you explicitly check for it, and that makes the tool hard to install for some. Let's say somebody is in a linux distro that has a older version of a required dependency.
• In my pipelines plugin i used sed to simply change the value of a YAML file. This is as you pointed out Jorge error prone and complex. In Go you would simply use a YAML parser and change the value in a secure way.

The best thing for complex logic here would be to send PR's to the oc cluster command directly IIRC. We can always add functionality, but doing it as a plugin system is hard.

[bjartek]

I pushed some comments to my code.

[jorgemoralespou]

@bjartek I have pushed a plugins branch, with what I envision as a simple plugin mechanism. It's not fully working but you can test doing:

oc-cluster --user oc-cluster --pipelines oc-cluster user-add (this doesn't do anything yet)

The rest of the stuff should be working as before

https://github.com/openshift-evangelists/oc-cluster-wrapper/tree/plugins

Just take a look and tell me whether this is too different, more complex, easier, or anything. I would like to have a super-simple approach. As I would like any non "basher" to easily craft plugins.

/cc @GrahamDumpleton You should also take a look

[GrahamDumpleton]

Not sure I like installation of a plugin being by a long opt.

Would perhaps prefer something like:

oc-cluster plugins enable user

This would enable/install the plugin.

In case it made sense in some cases to be able to rollback plugin, also:

oc-cluster plugins disable user

To get a list of plugins and whether currently enabled:

oc-cluster plugins list

and what the plugin is about:

oc-cluster plugins help user

[bjartek]

Sorry for not replying sooner, I have been busy with personal stuff.

After reviewing your code i can understand why you though my solution was complex. Yours works in a very different manner. It basically adds stuff to an already running profile.