Update SLA Management instructions #9
Conversation
|
|
||
| .. code-block:: bash | ||
|
|
||
| { | ||
| "name": "an-agreement-name", | ||
| "name": "your-service-name-here", |
There was a problem hiding this comment.
this name is a metadata attribute, respective to the resource itself, so it shouldn't be the name of the service
There was a problem hiding this comment.
This is simple workaround to make an agreement specific to a service (only for IT-1!). If the name is arbitrary, it will be used as the default agreement. @FranCarpio : can you confirm this?
| "details":{ | ||
| "id": "2018-000234", | ||
| "type": "agreement", | ||
| "name": "an-agreement-name", | ||
| "name": "your-service-name-here", |
There was a problem hiding this comment.
To give a descriptive name to an agreement. It must match the outer name.
| "guarantees": [ | ||
| { | ||
| "name": "TestGuarantee", | ||
| "constraint": "[execution_time] < 100" | ||
| "name": "*", |
There was a problem hiding this comment.
The guarantee name matches the name of the operation, but to make it simpler to have a running evaluation for any kind of service, I decided to use that special name to flag this.
There was a problem hiding this comment.
the 3 "name" attributes are confusing but if that's how it works , for now it's ok
|
|
||
| .. code-block:: bash | ||
|
|
||
| curl -X POST -d @agreement.json -H"Content-type:application/json" -H"slipstream-authn-info: super ADMIN" $CIMI_URL/api/agreement |
There was a problem hiding this comment.
isn't this documentation mean for the user? if so, then "super ADMIN" should not be used
There was a problem hiding this comment.
It is documentation for the person installing the agent, not a normal user.
If cannot use the pwd, how does the user know how the agreement can be created?
There was a problem hiding this comment.
"super ADMIN" is just for administrators and temporary. If this is meant for the person installing the agent, then the user already has an account he can use
|
@cjdcordeiro , @FranCarpio : This instructions are intended to add the agreements by the admin user, not by a normal user. Then, the normal user, when using the GUI, can run a service without worrying about agreements. The SLA Mgmt has been slightly modified to allow one agreement to cover different types of services. This is a workaround, because it cannot be this way. For IT-2, a template will be associated to the service, and an agreement will be generated for each service instance. |
|
Hi @cjdcordeiro : I updated the instructions.
|
@cjdcordeiro , @FranCarpio : please, have a look to make sure it is congruent.