Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

freebsd: improve init resiliency and jenkins environment #228

Closed
wants to merge 6 commits into from

Conversation

jbergstroem
Copy link
Member

We have to sunset our freebsd vm's at Voxer. This commit replaces The FreeBSD ones and then some:

  • resolve java path which makes changes to openjdk "just work"
  • remove unnecessary environment variables

With this, we will unfortunately not test for 32-bit freebsd any longer (because DO only have 64-bit freebsd vm's). On the other hand, we now run two 64-bit vm's in parallel, allowing for slightly higher throughput.

@jbergstroem
Copy link
Member Author

This will also "fix" a few of our flaky tests related to routing since there's no magic concerning LOCALHOST and BROADCAST any longer (side effect of freebsd jails).

@jbergstroem
Copy link
Member Author

We could explore setting up a jail in one of the freebsd slaves. Thinking this would hurt automating through ansible.

The current FreeBSD lives behind a VPN at [Voxer](http://voxer.com).
Should you need access, speak to [https://github.com/rvagg](rvagg) for
further information.
These machines lives at DigitalOcean, running as default VM's.

This comment was marked as off-topic.

@rmg
Copy link

rmg commented Oct 26, 2015

Some very minor nits...

Assuming the decision has already been made and this is just the code for it, LGTM.

@jbergstroem
Copy link
Member Author

@rmg said:
Assuming the decision has already been made and this is just the code for it

We were told by Voxer to sunset the current resources. We've now got two 64-bit FreeBSD bots running at DO and I've asked twitter for more.

@joaocgreis
Copy link
Member

I did not run this, but the changes LGTM.

@jbergstroem
Copy link
Member Author

Update: we're going to go with one vm at joyent and one at digital ocean. We're still short on 32-bit vm's which is unfortunate.

@Trott
Copy link
Member

Trott commented Nov 23, 2015

Is there an expected/planned date for this? (I have no idea how these cutovers work.)

@jbergstroem
Copy link
Member Author

@Trott sorry, pretty much based on effort which varies. I'll see if I can squeeze this tomorrow -- just need to free resources on DO ahead.

@Trott
Copy link
Member

Trott commented Nov 23, 2015

@jbergstroem Thanks. I don't mean to rush you or anything. There's no urgency.

@jbergstroem
Copy link
Member Author

@Trott all good, I just agree that "as soon as possibly" is a shitty eta :)

@jbergstroem
Copy link
Member Author

I've now retired the remaining bots that are either run in jails or having different network setups.

@jbergstroem
Copy link
Member Author

sorry, didn't mean to close.

@jbergstroem jbergstroem reopened this Nov 24, 2015
@jbergstroem
Copy link
Member Author

Rebasing since I already did a few things here.

@jbergstroem
Copy link
Member Author

I've retired our Voxer freebsd bots as of today. This PR kind of took another direction but I just want to make sure we get all changes in there.

A few things going on here:
 - move into the new {{id}} strategy where we use hostname
 - merge parts of the initial digitalocean migration pr
 - split variables meant for change into jenkins.conf
 - simplify all the things
@jbergstroem jbergstroem changed the title freebsd: migrate from voxer to digitalocean freebsd: improve init resiliency and jenkins environment Nov 25, 2015
@jbergstroem
Copy link
Member Author

Updating topic since this issue floated a bit more south than expected.

 - start the transition to global variables (open up for roles)
 - include variable files by default
 - avoid variables in names since they can't be expanded
 - use jinja2 templating instead of replacing variables
 - change subshelling in init script
 - make init script slightly more robust
@jbergstroem
Copy link
Member Author

I'm going to close this since I'm venturing further away from the original topic. I'll create a new PR which will illustrate a few of the simplified things we have in the pipe for our ansible stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants