Skip to content

What does the mobile app need to have? #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
algorys opened this issue May 11, 2018 · 4 comments
Open

What does the mobile app need to have? #1

algorys opened this issue May 11, 2018 · 4 comments
Labels
question Further information is requested

Comments

@algorys
Copy link
Collaborator

algorys commented May 11, 2018

@ddurieux , @mohierf and others:

I open this issue to discuss what should be displayed or not in the mobile application.

What are your ideas, should we let the user trigger actions (acknowledges, downtimes, ...), what could be useful information, should we have services of hosts or just number of services, etc... ?

@algorys algorys added the question Further information is requested label May 11, 2018
@mohierf
Copy link

mohierf commented May 11, 2018

IMHO, the mein interesting information is:

  • alignak status
  • alignak backend status
  • hosts problems
  • services problems

And, from this very synthetic information, being able to have a more detailed view for each:

  • alignak daemons status
  • hosts problems list, and then, an host view
  • services problems list, and then, an host view

@algorys
Copy link
Collaborator Author

algorys commented May 15, 2018

Ok, here is what I think:

  • alignak status: it's doable. To know that alignakdaemon endpoint is not necessarily available for a backend if I'm not wrong ?

  • alignak backend status: doable without problem.

  • hosts problems: having all the default hosts seems to me anyway required. So OK.

  • services problems: I am afraid to meet the same problem as for Alignak-app, if there are thousands of services, it will require a long and resource-intensive request. So I see for this case two solutions:

    • View services through the host view (this will require a fair request for these services)
    • Or, use a paging system and display only the first 50 services in problem ... (so make a request for the services 'CRITICAL', 'WARNING', 'UNREACHABLE', then if the user clicks on the next page, make the request again on the next page... But to see also if the filter system of the backend is not going to slow down the request too.

I have not yet taken into account the arrival of the Web Service of the next version of Alignak. It may solve these problems.

For detailed views:

  • alignak daemons status only if endpoint is available
  • hosts and services list depending of solution choosed before.

@mohierf
Copy link

mohierf commented May 16, 2018

  1. for the Alignak status, the best is to get information from the arbiter Web Service on the /get_stats endpoint. You will have a global Alignak status and a per-daemon detailed status

  2. IMHO paginating the hosts/services list is a must-have. Get the services sorted by criticity and then paginate

  3. The next Alignak version Web services may have to solve this ... if some endpoints/services are missing, I will add them.

Let us discuss this !

@algorys
Copy link
Collaborator Author

algorys commented May 16, 2018

@mohierf yes, I'll wait for next stable release to begin to work on these new endpoints.

This new field can also improve requests in future for problems.

And/Or maybe a new /problems endpoint can be a good idea ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants