A New Packaging Approach - CLI Tools Pushing Apps and the Story about the #loggregator “space drain” experiment #loggregator


Adam Hevenor
 

Back Story
The Loggregator team has recently been seeing a ton of benefit from developing CLI plugins. Specifically they are quick to develop, and distribute and lend themselves well to rapid iteration based on feedback. Developing our noisy neighbor nozzle we worked closely with the Pivotal early access program to meaningfully shape the final product that we eventually posted here. This feedback loop helped us focus on the trying to solve specific packaging UX problems with a plugin and arrived at a new techniques that packaged apps along with a CLI plugin. We have since taken those ideas a step further.

Space Drain
We recently started enhancing the "drain" functionality of Loggregator  with a plugin and it’s been a long standing idea to allow app developers to drain their whole space. If you look at the doc, you’ll see that multiple teams weighed in and the effort was shelved due to a break in conventions and a lack of clarity (at the time) around the precise persona. In my mind I filed this under high value/high complexity and figured we’d come back to it eventually.

But our noisy neighbor nozzle experience got us thinking. What if we we packaged an application with the CLI that was pushed when you ran a command, and that application managed the drain bindings for all the apps in your space. All of a sudden an initiative that involved 3 or more teams, was simplified into a 4 or 5 points in our backlog. Part of the work was figuring out some of the packaging technique so we ended up cutting a version of this in the latest cf-drain release

(It’s helpful for context to try this out which you can do so with the following command.)

Feedback & Pro / Cons
I am posting this because I want feedback on this approach before taking it further. The pattern is a liberating one and we have several ideas that we are considering executing on that follow this same approach. 

Pro’s

  • Rapid Iteration with established versioning approach
  • Ability to deliver pushable apps without compile instructions or OS specific scripts
  • Self Service for App Developers

Con’s

  • The auth model seems in-elegant. (UAA Team has been providing some feedback on this and I hope to improve this experience)
  • Self Service for App Developers (I am listing this as a con also because controlling operators may find this problematic)

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.