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


Mike Youngstrom
 

It is an interesting idea/concept.

I'd say the auth model is a significant Con and potential large hurdle.  I'm assuming the username and password passed with the cli is then used by the pushed app to continually query the space for new apps and bind the service, correct?  I'm interested in seeing what UAA and Perm could come up with to improve this.  It seems you'd either need to dynamically generate a service account with developer access to the space.  Or figure out some way to give apps running in a space the ability to create a token to do management operations in the space it exists in.  Neither seems very simple.

Another Con would be lack of operator control over upgrading such a feature.  If new versions this app are released end users would need to know to run the command again to upgrade it.  Might be tricky as CC APIs evolve and such.  Anything that the user doesn't feel like they have ownership over I as the operator would like to be able to upgrade for them.  A CLI plugin pushed app sits in the middle somewhere.

It seems to me a simpler approach to the original problem of sending all logs for apps in a space to a drain could be solved with a service broker.  This broker would need CF_ADMIN client credentials but could simply scan all spaces for instances of itself then binding itself to all apps in spaces where it finds itself.  As a broker it could be upgraded by the operators and would provide less permission complexities.

Thoughts?

Mike

On Mon, Mar 19, 2018 at 4:17 PM, Adam Hevenor <ahevenor@...> wrote:

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.