Difference between revisions of "22.05.2013 Accounting and Policy portlets"
From D4Science Wiki
(→Requirements) |
(→Discussion) |
||
| (6 intermediate revisions by the same user not shown) | |||
| 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 | + | * 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. | * We need to allow the portlet's user to show info based on user role scope and consider Service2Service policies. | ||
=== Actions === | === Actions === | ||
| − | * ENG will circulate a document describing the portlet functionalities and the usage flow (by the EOW) to Lino and Andrea in order to produce an (internal) validation about the requirements and usability of the current implementation of the portlet. | + | * Up to now it's not possible to remove/edit simultaneously multiple policies. Antonio to evaluate options to allow this when the same action - e.g. activation or deactivation is foreseen for many of them (it would suggest to consider a "cloning function").The item should be renamed as "gHN". |
| + | * 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. | * Next week will be a conference call to discuss the preliminary validation results and to define possible corrective actions. | ||
| Line 30: | Line 31: | ||
** Navigating the details about the accounting data there will be only if requested by the user. | ** 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. | ** We could follow the model represented by Google Analytics. | ||
| − | ** Listing all the | + | ** Listing all the information in terms of records (or something like that) should be the last step of the user experience. |
Andrea Manzi: | Andrea Manzi: | ||
| Line 37: | Line 38: | ||
Andrea Manieri: | Andrea Manieri: | ||
* We need to model the interaction between user and accounting system. | * 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 | + | * 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 Amazon cost metrics). |
* 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. | * 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. | ||
| Line 62: | Line 63: | ||
===Actions=== | ===Actions=== | ||
| − | * | + | * 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). (Ermanno) |
* To verify at which extent the implementation of a customizable portlet according to the queries on the accounting data is possible. (Antonio and Ermanno) | * 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) | * 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) | * 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) | ||
Latest revision as of 15:38, 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
- Up to now it's not possible to remove/edit simultaneously multiple policies. Antonio to evaluate options to allow this when the same action - e.g. activation or deactivation is foreseen for many of them (it would suggest to consider a "cloning function").The item should be renamed as "gHN".
- 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 information in terms of records (or something like that) should be the last step 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 Amazon cost metrics).
- 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
- 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). (Ermanno)
- 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)
