Skip to content

Instantly share code, notes, and snippets.

@cfjedimaster
Created November 8, 2016 22:41
Show Gist options
  • Save cfjedimaster/2c8b53ae833728ed9a749895f723fc3c to your computer and use it in GitHub Desktop.
Save cfjedimaster/2c8b53ae833728ed9a749895f723fc3c to your computer and use it in GitHub Desktop.
Meric -
Joe, Erin and I were speaking and we wanted to make sure we were being clear about some of our thoughts in regards to a proposed LB API vs APIC.
If you already understand what I'm saying, please forgive us, we just feel it's important to ensure folks understand where we're coming from.
You've asked about the capabilities of the APIC CLI vs slc. While I've found that a LB developer *could* make use of the APIC CLI (especially with the modifications I suggested),
we want to be clear that our argument for a proper LB CLI is *not* about features. It is about using the *appropriate* tool for the job.
APIC is not appropriate for LB developers for two main reasons:
a) It is way over powered for what a LB developer needs
b) It is a commercial product, and yes, you do not have to pay for it, but amongst developers, this can lead to them avoiding it
While obviously we want LB developers to get introduced to APIC and make use of it, having a proper LB CLI gives us a *clear* message to them
without "muddying the waters" so to speak with a solution that does 900% more than they need and is not FOSS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment