Re: cf-deployment 3.0

Marco Voelz

Dear Josh, dear David,

Thanks David for sharing your past experiences in the RelInt team. I can sympathize with the stories you shared and understand the motivation for the planned changes better.

Now that cf-deployment 3.0 is there, let me tell you "how it went": It now means you have to switch to bosh-dns to receive security updates.

There is a number of reasons why we didn't introduce bosh-dns yet in our production system:

  • This ~200 lines of .yml just for aliasing DNS names [1], as the story making this obsolete isn't done yet [2]
  • This needs to be replicated e.g. in the ops-file to rename the network [3] which makes it even more terrible to maintain
  • There were open issues [4] that are important for larger-scale deployments. I give you that this is fixed now with dns-release 1.8.0 – but this came after you released cf-deployment 3.0
  • Parts of the above issue try a fix by introducing an experimental flag to get feedback from teams. Given this actually *is* an issue, I'd want to wait what comes out of this.
  • Other teams are still surprised from time to time by bosh-dns behavior and are looking into whether this might have implications they need to deal with [5]

Moreover, I think although everyone knew that bosh-dns was going to be a requirement at some point in time, the fact that this would be 3.0 was poorly communicated (I might have missed a mail there, but I cannot remember this. I would have raised my concerns earlier if that would have been the case).

For our production environment, we now have a few choices, all of them bring me headaches:
  • adopt bosh-dns *right now* although we don't feel good about it, 
  • try to bring back consul for a while (not even sure that's possible) and otherwise follow cf-deployment 3.0
  • backport security fixes only to a cf-deployment 2.x based production env

All of this brings me back to: As someone responsible for a cf-deployment production environment, I find it incredibly difficult having to deal with breaking changes like this on a regular basis to get security fixes. 

Warm regards

From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Wednesday, July 18, 2018 11:54:06 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0

Thanks Geoff, Marco, Chip, Jesse, Bernd, and David for sharing your feedback and thoughts. You’ve expressed valid concerns and provided valuable context that I take to heart. I really appreciate the time and effort required for meaningful dialogue about the impacts of the proposed release cadence.

While the RelInt team's primary goal remains supporting the CF Foundation engineering teams and their ability to validate their commits in CI, your points underscore a tension we’re acutely aware of.

We’re trying to meet the needs of both the CFF Contributor and Operator and the ‘trick’ is to find a sustainable balance between the two. However, on occasions where we must prioritize one over the other we’re going to favor the CFF Contributor.  

I mentioned this earlier, but it’s worth restating that the RelInt team doesn’t have any plans provide LTS support and as Chip and Jesse pointed out that has traditionally been a value-added service provided by commercial vendors.  

In the spirit of iteration, I’d like to propose we proceed with the release cadence I originally outlined and see how it goes.

Again, thank you for providing such valuable feedback.


Josh Collins

_Current_ PM of CF Release Integration

Join { to automatically receive all group messages.