No sudo in scripts

[djMax]

I don't think the sudo should be in the bootstrap scripts. If the script needs sudo, run the whole thing as sudo. Right now, you can't use the bootstrap in the docker base ubuntu image because it wants sudo, which (a) doesn't exist by default and (b) isn't really relevant there.

[djMax]

I think I see what's going on now - that the bootstrap script manages its own docker. That's fine I guess, but for real implementations, that's not the way we would prefer. I will build my own wasabi container and use mysql from (say) AWS and a separate cassandra cluster, etc. So I need some way of building that wasabi image. I can tease out what's necessary by looking at the bootstrap, but I'd argue that path should be a first class concern.

[jwtodd]

@djMax -

i could use your definition of "for real implementations?"

for me, this is quite real-and-legit as is :)

the bin scripts [ wasabi.sh, bootstrap.sh, etc ] work quite well for local dev which is the principle intent, in addition to invokable under a build environment like jenkins-or-travis ... which are both in use today.

now, a "package" command was introduced to build rpm-and-deb builds for deployment via external means, eg: chef, et al. there is no reason, as i see it, that "package" or a new peer command couldn't deploy the image to a remote docker server.

• james

[djMax]

Wasn't trying to be overly harsh - just that it's clearly dev-focused and we want to deploy in kubernetes. The whole "build on ubuntu deploy centos" thing is weird. What I'd really prefer (and am working on) is an image in docker hub

[djMax]

Also, why not just use docker compose for Cassandra + MySQL + wasabi?

[jwtodd]

all good.

yeah it originated from purely for dev needs and still suffices. early versions were on vagrant/virtualbox and started migrating to docker early on. i was amped when docker native emerged as it sped things up and resolved a number of sticky wicket issues, namely sticky dns resolution when migrating networks, etc.

to open source #wasabi much had to be aligned, locked down, etc. docker-compose would be an awesome patch/addition ... it is just back in the day it wasn't a priority, docker was a bit bumpy with regards to bugs, etc. but those days are behind us :)

i do want to add, though, that while wasabi/bin is leveraged by devs as we have established, it is also directly invoked by continuous integration systems (eg jenkins, travis-ci) to perform feature/develop/master build/release operations. this decision/opportunity allowed us to toss quite a heap of sh/curl disjoint hackary that had accumulated over time.

looking forward, i think adding a 'deploy' option to wasabi.sh to, for example, spin up an ec2 single node via teraform would be compelling. it could build on wasabi.sh 'package' ... of course this is just one deployment option, docker image push being another :)

let's do this ... what say you?

[djMax]

Definitely. I started by making a docker build-box, basically it runs a bit of bootstrap on its own and then calls build. Then will have it call container and use the docker file as it does now with docker-in-docker to build the final image. Then we can see how to distribute that down to the scripts if that's what's desired.

[jwtodd]

beautiful :)

loosely related is #125 feature/travis-test ... which is really a proto to additionally deploy-local (not cluster) docker instances and run wasabi.sh test (aka functional-tests) against said local deploy, collect jacoco-it.exec and report unit+integration tests to sonar.

i'd love to see these concerns leverage one another :)

then build out to a cluster deploy.

[djMax]

Closing in favor of the PR.