Openshift tips, tricks and cheats

Posted: 9 January 2017 in OpenShift

Here are a few tips and tricks and stored commands I use when dealing with Openshift.

start/stop openshift

systemctl start atomic-openshift-master

systemctl stop atomic-openshift-master

start/stop docker

systemctl start docker

systemctl stop docker

Login as an administator

oc login -u system:admin

Configure login into an external docker repository

oc secrets new-dockercfg docker-snapshots \
 --docker-username=$LDAP_USERNAME \
 --docker-password=$LDAP_PASSWORD \

Manually login in he private docker repository

export AUTH_TOKEN=`oc whoami -t`

At the moment, I’m playing with the release plugins in a sandbox project and it’s created lots of tags. I want to start afresh, so I’ve written a little utility to get rid of all the tags

git tag --list | xargs -I {} git tag -d {}
git fsck --unreachable 2>&1 | grep 'unreachable tag' | awk {'print $3'} | xargs git show | grep ^tag | awk {'print $2'} | xargs -I {} git push origin :refs/tags/{}

(2 years since the last post, … shocking 😀 )

I love this. I also have a headache now…


A co-worker of mine recently ran across this post by Eamonn McManus, “Using the builder pattern with subclasses,” and after due consideration, settled on what McManus calls “a shorter, smellier variant.”

Shorter because:

  1. it has only one Builder class per class

Smellier because:

  1. it uses raw types
  2. the builder’s self() method requires an unchecked cast

Frankly, I don’t find the shortness here a compelling argument for the smell, but I also think there’s more shortness to be found in McManus’ design while remaining fragrant. Thus:

 class Shape { private final double opacity; public double getOpacity() { return opacity; } public static abstract class Builder<T extends Shape> { private double opacity; public Builder<T> opacity(double opacity) { this.opacity = opacity; return this; } public abstract T build(); } public static Builder<?> builder() { return new Builder<Shape>() { @Override public Shape build() { return new Shape(this); } }; } protected Shape(Builder<?> builder) {…

View original post 300 more words

lapis server 1.2.9

Posted: 18 July 2014 in Teamsite

It has been a somewhat short sprint with not a lot to talk about. The interface is getting more and more usable, which is a good thing since I’m using it to manage the sprints. The filters and comparators and really helping with this.

Server instance name

the lapis start program has been modified to take a second argument which is used to distinguish between multiple running instances. The argument is simply there to appear on the command line when checking the running processes as shown below:

$ ps -ef | grep LapisServer.jar laurent 21255 21010 5 10:42 ? 00:01:26 java -Djava.util.logging.config.file=etc/ -DinstanceName=dev -jar lib/LapisServer.jar etc/ laurent 21067 21065 5 10:42 ? 00:00:39 java -Djava.util.logging.config.file=etc/ -DinstanceName=tst -jar lib/LapisServer.jar etc/

Before this was introduced, there was no real way to find out which process was for which instance. Now I know…

Due Date & Priority

I’ve added the due date and priority to workflows and tasks to complete the move towards Getting Things Done. Along with that, I created due date filters and comparators and priority filters and comparators.

Lapis Server 1.2.8

Posted: 7 July 2014 in Teamsite

It just never stops! Lapis Server 1.2.8 is now done, but it’s a release that is part of a bigger program of work, so I’m straight on 1.2.9

I had to create a few things to make it all available as a software platform.

  • a Signup process (signup form, signup servlet, signup workflow (it’s pretty nice that after signup up to a workflow engine, the workflow engine uses a workflow to send you a nice email – it uses an email task!)
  • Some terms and conditions and a privacy policy
  • A new stylesheet
  • Changes to the login process to include “forgot username”, “forgot password” functionalities. Again, both of these use a workflow to send the emails
  • Rewrite rules to make sure you can’t see all the workflows you’re not supposed to.
  • Role based security constraints to match what will be the various packages. The tomcat realm class now reads the role of the user so the web app has the same roles as the Lapis server.
  • Web Interface improvements, such as moving the tasks link into its own menu, links to the privacy policy and terms and conditions
  • A task status filter (active, completed, rejected, all) which somehow had been missed out in the design process and is DEFINITELY required to make it user friendly. The default is “active”, so that the task link is effectively a link to your current to-do list.
  • An available workflows datasource to make it more user friendly by selecting workflows from a drop-down list instead of typing them in. The datasource only lists the files the user has access to.
  • Changes to the server to be able to bind itself to a specific network interface in multi-home network environments such as that of the redhat cloud.
  • Changes to the client command line tools to bind themselves to a specific network interface in multi-home network environments such as that of the redhat cloud.

what’s next?

as part of my 1.2.9 sprint, I am looking at finishing the integration of the redhat environment (with the shutdown and startup scripts and a whole round of testing) and send a link to a few people to do a soft launch and gather feedback before getting me a real domain name!
After that, I’ll see how to get a payment solution in place to offer upgrades and start the process of making changes towards working with an organisation’s groups.