ktsakalozos
commented
7 years ago LGTM!
____ __
/ __/__ ___ _____/ /__
_\ \/ _ \/ _ `/ __/ '_/// ./_,// //_\ version 1.5.1 /_/
And from master:
____ __
/ __/__ ___ _____/ /__
_\ \/ _ \/ _ `/ __/ '_/// ./_,// //_\ version 2.1.0 /_/
Setup our release bits (hieradata and puppet recipes) and package repository based on the bigtop_version layer option.
Currently only '1.1.0' and 'master' are supported. For 1.1.0, we still have to construct a funky repo url since the repo only supports trusty (x86) and vivid (ppc). For master, we'll pull packages straight from the ci system.
While we're here, let's simplify the layer options. Given the version, we can construct everything else we need:
remove bigtop_release_url We don't need the user to set a release tarball url since we can git clone it based on the version branch. This will break in a restricted env that cannot access github, but it would probably break anyway trying to wget a blob from apache.org. The right way to handle restricted envs is to use resources so we can fall back to a release package if git cloning fails. This is on the roadmap for a future rev.
remove bigtop_repo_url As mentioned earlier, we can construct this for 1.1.0, and we have a static repo url to use for master.
remove bigtop_hiera: There's no good reason to ever let someone change these as they are baked all over the bigtop release source. If these need to be customized, the user will need to do that in a forked bigtop release repo that can be attached as a resource in the future (see above).