Difference between revisions of "22.05.2013 Accounting and Policy portlets"
From D4Science Wiki
(→Requirements) |
(→Requirements) |
||
Line 12: | Line 12: | ||
* We need to display the information related to the serviceClass and the serviceName in the form "serviceClass:serviceName" pair, because serviceClass includes serviceName. | * We need to display the information related to the serviceClass and the serviceName in the form "serviceClass:serviceName" pair, because serviceClass includes serviceName. | ||
* We need to understand and evaluate the portlet usability when the number of services increase. | * We need to understand and evaluate the portlet usability when the number of services increase. | ||
− | |||
* It's necessary to add the port number to distinguish between different services on different hosts. | * It's necessary to add the port number to distinguish between different services on different hosts. | ||
* During the create policy process will be not available the Service field selection, because if the services number grows the services list will be not readable. In order to reduce the number of (defined) policies that are displayed, it might be useful to filter (through a search bar) on some fields (such as serviceClass, serviceName and host). | * During the create policy process will be not available the Service field selection, because if the services number grows the services list will be not readable. In order to reduce the number of (defined) policies that are displayed, it might be useful to filter (through a search bar) on some fields (such as serviceClass, serviceName and host). |
Revision as of 14:14, 23 May 2013
Details
- Description: Meeting notes on Resource Accounting and Policy portlets
- Date: 22-May-2013
- Topics: Policy management, Resource accounting, portlets, requirements
- Participants: Andrea Manieri (ENG), Andrea Manzi (CERN), Antonio Savini (ENG), Ermanno Travaglino (ENG), Pasquale Pagano (CNR), Luigi Fortunati (CNR).
Policy management portlet
Requirements
- We need to display the information related to the serviceClass and the serviceName in the form "serviceClass:serviceName" pair, because serviceClass includes serviceName.
- We need to understand and evaluate the portlet usability when the number of services increase.
- It's necessary to add the port number to distinguish between different services on different hosts.
- During the create policy process will be not available the Service field selection, because if the services number grows the services list will be not readable. In order to reduce the number of (defined) policies that are displayed, it might be useful to filter (through a search bar) on some fields (such as serviceClass, serviceName and host).
- We need to allow the portlet's user to show info based on user role scope and consider Service2Service policies.
Actions
- Antonio and Ciro we'll need to assess the portlet usability when the number of services increase (order of 50-60 as baseline, up to three times more).
- ENG will circulate a document describing the portlet functionalities and the usage flow (by the EOW) to Lino and Andrea Manzi in order to produce an (internal) validation about the requirements and usability of the current implementation of the portlet.
- Next week will be a conference call to discuss the preliminary validation results and to define possible corrective actions.
Resource Accounting portlet
Discussion
Lino:
- We need to follow the "visual-information seeking mantra" [Shneiderman, 1996] model when the amount of data is enormous and constantly growing:
- Navigating the details about the accounting data there will be only if requested by the user.
- We could follow the model represented by Google Analytics.
- Listing all the informations in terms of records (or something like that) should be the last stemp of the user experience.
Andrea Manzi:
- As a first step the portlet might visualize charts and then the users can go deep, reaching the "raw" accounting information (records).
Andrea Manieri:
- We need to model the interaction between user and accounting system.
- We need to understand who are the users and what information should be displayed. The identified user's categories are: infrastructure managers, vo managers, vre managers and end users. Furthermore, we could have a "guest" user in order to display a limited set of data and functionalities of the accounting system for exploitation purposes. (billing, with the cost of metric application amazon).
- Up to now we expected only the accounting data visualisation with a temporal metric. Are there any other metrics? Lino: No, it's enough to visualize the temporal evolution of the accounting data.
Andrea Manzi:
- We need to have a scope based data-aggregation: in the infrastructure, we've an scope-based hierarchy and an user who logs in the root scope (/d4science) then he/she can see all the data of all the vo and vre.
Lino:
- Graphs (and views) will be pre-calculated in order to expose them into the dashboard and if I want to update the data then I'll need to request it.
Luigi:
- Measurable values that may come out even from a calculation (eg counting a certain number of records)
- Relationship between a measure and an aggregate measure based on a number of dimensions: what are the measures
Lino:
- Execution: number of vm that are used?
- Once defined the use cases -> customizable portlets based on the query
Andrea Manieri:
- It would be desirable/useful to have a customizable accounting portlet, in order to "easily" add new resources that we want to take into account (as well as on the accounting data-model)
Lino:
- We need to outline (at least in principle, at design level) the introduction of a billing sub-system that will work on the accounting data.
Actions
- Ermanno to better define user role, use cases per role. To check that the resource model may include Cloud resources at various level of an eInfrastructure (i.e. EGI) or resource providers (Amazon, GAE, Azure).
- To verify at which extent the implementation of a customizable portlet according to the queries on the accounting data is possible. (Antonio and Ermanno)
- The data exposed in the portlet will be aggregated both per scope and per user, according to the user's roles inside the infrastructure. (Antonio and Ermanno)
- Regarding the Execution resource type we need to understand if the number of VMs used by a job is available and if it will be published as an accounting information. (Ermanno)