Open vipinvkmenon opened 5 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/168448936
The labels on this github issue will be updated when the story is started.
Hi @vipinvkmenon many thanks for creating this feature request. I'm curious as to whether cf routes
which lists the service and the bound apps would be suitable for your needs? Or cf service
. Thanks for your feedback.
Hi @abbyachau. Thank you for your response. π
However, no it does not serve the immediate purpose. π
You are right in the sense that cf routes | grep app-name
will give me the routing-service-instances bound to the app and cf services | grep app-name
will give me the list. However, these are additional commands that need to be run, making it more or less indirect and tedious to get the info for a single application. Again, if the number of routes or the number of applications in a given space is large, this is slightly time-consuming.
The context of this particular request is mainly to improve the time for operations for various engineering teams.
Currently, an engineering team in order to get a summary of the application (where, please note: time is of the essence, especially for support-teams, L1 teams, SRE etc), will need to go through multiple commands to get them.
As mentioned earlier the intent of this particular feature is, to quickly provide the details of all the bound service-instances for a particular/single app.
It is in the interest of time to provide this quick summary with a single command rather than running through multiple commands to get the quick details/summary of the application.
Therefore it has been a common wish that the cf app provides some more details in the app summary, mainly list of bound service-instances.
What I mean is, when I do cf app App-Name
I should be able to give the list of bound service-instances along with the application stats in a single command.
Based on my experience and interactions fellow engineers I believe it is an enhancement that will add good value to the. Looking forward to hearing from you π.
Hey @vipinvkmenon thanks for those details. We don't plan on enhancing the app
display on v6
cli but can start a conversation about v7
cli. How many service instances, on average, would you say you have bound to an app? And would additional details like status
of the service instance be interesting as well? Thanks.
cc @addytripathi @waterlink
Hi @abbyachau
Thank you for your response. We've had instances where we've seen applications bound up to even 7 service instances. Yes getting the status of each service is a requirement. The most immediate need is the summary of the list of bound service instances.
There have been cases where a given deployment in a space has 10+ microservices and a lot more service-instances bound to them. It becomes a great effort when a given space has a large number of applications service-instances and doing
cf services | grep <my-app>
becomes time-consuming. Large Deployments with several microservices and service-instances become a core part of several enterprise application solutions as such quickly finding if any of these services go down and quickly gathering information/summary of the status of the application and all its bound service-instances need to be done in as less time as possible.
Therefore, you see, getting the immediate summary of bound services is very much needed... We need to leverage the cli to effectively use to API's to give these kinds of information in as little commands as possible.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed.
What's the user value of this feature request?
One of the first commands that operators and developers look to get a summary of the details of an app is the
cf app
. As such this command has become the quick stop quick details of an app. This command is especially crucial to SRE and support engineers to get a quick glance of the details of the apps in downtime and provide quick details.My request is that it would be really great if the command would also provide the list service-instances that the app is bound to.
During downtimes and firefights, it becomes very necessary to get such details as quick as possible.
Current methods include:
cf env
: Too verbose for quick glancescf services | grep app-name
: Not the most intuitive approach when a simple command should give it and time-consuming if there are a large number of services in a given space.cf curl /v2/apps/:app_guid/service_bindings
: again to verbose and wordy for quick glancesWho is the functionality for?
All users for the cf CLI especially operators/deployer of the app, SREs, Support Engineers etc who need to get a quick summary of everything related to the application.
How often will this functionality be used by the user?
Many a time, I've heard service engineers say if there was a one-stop to get this detail in a single go of the app summary. The cf app is one of the most common commands used for getting details of the app, (probably even the first command used) Whenever there is a need to know a summary of the deployed application.
How often will they use this feature?
Quite often, Whenever there is a need to know a summary of the deployed application
Who else is affected by the change?
As the output is not JSON and designed to be Human/Reader-friendly, no it should not break anything. Code implementation when the app calls v2/v3 APIs will need be checked..
Is your feature request related to a problem? Please describe.
Whenever I need to quickly get a glance of services bound to an app I have to always go through the cf env or go to the application's manifest to see bound app or list
or grep through cf service and then skim through.
Describe the solution you'd like This is a small addition to the existing set of info. It would be much better if just like how running instances are provided with the list of bound service instances and type are listed.
since an API is already available it just needs to be added to the cli call
Describe alternatives you've considered As of now, the alternatives are the said steps mentioned above
Additional context Possible Hiccup....V3compatibility Anyhow, I would love to work on this provide a PR if it seems to be a worthy add on :)