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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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)
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7880) | [hidden email] | [hidden email] | Mute This Topic | New Topic
Mute #loggregator

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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)


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7881) | [hidden email] | [hidden email] | Mute This Topic | New Topic
Mute #loggregator

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

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

Adam Hevenor
Yeah. Currently the user name / password is simply passed into the app. I expect well at least implement a better hook into CUPS next and for user roles that can create users we could shell out and create a strong user-name password combo. This could be pretty elegant and allow for (automated) cred rotation. 

The service broker approach is definitely an option to consider long term, but I'd like to try and figure out a way to do this within the scope the CC and UAA provide if it all possible. 
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7886) | [hidden email] | [hidden email] | Mute This Topic | New Topic
Mute #loggregator

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

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

Mike Youngstrom
Yeah. Currently the user name / password is simply passed into the app. I expect well at least implement a better hook into CUPS next and for user roles that can create users we could shell out and create a strong user-name password combo. This could be pretty elegant and allow for (automated) cred rotation. 

Sounds good.  Currently in my environment we disable user account creation instead using enterprise LDAP or OAuth.  Supporting internal users and external users isn't something I've considered in my deployments.  Might not be a problem.  Just not something I've considered before.

Thanks,
Mike
 
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7887) | [hidden email] | [hidden email] | Mute This Topic | New Topic
Mute #loggregator

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_