allow annotations to be set on charms

[Kapil Thangavelu]

external tools (like deployer) would like to be set vcs info (repo url, rev) on local charms as the environment maintains local charm revisions, so api clients have no way of knowing when a local charm upload can be avoided since the charm is already in the env, which is costly for fat charms.

[Anastasia (anastasia-macmood)]

New annotation client has been added deprecating the old one.
This client still annotates entities that could be annotated before - environment, machine, service, unit. However, it also annotates charms.
New calls are capable of handling bulk inputs where bulk inputs mean:
1. For getting annotations:
Provide a list of entities of interest and get a list containing either entity annotations or retrieval error for each entity requested.
2. For setting annotations:
Note that this is a current assumption as it cateers for a lot of scenarios but complicates the call... FUrther clarification from Kapil or other interested parties may change that. Take a list of list of entities and its corresponding pairs, thus setting different annotations on a list of entities.
.......{
            "Type": "Annotations",
            "Request": "Set",
            "Params": {
                 "Annotations": {{
                   "Entities": {a, b, c},
                           "Annotations": pairs1
                  },{
     "Entities": {d,e,a},
                          "Annotations": pairs2
                  }}
}}......
Here, entities a,b,c will be annotated with pairs1 whereas entities d,e,a with pairs2. Note that at the end of this call, entity a would have both pairs1 and pairs2 applied.

To keep track of clarifications, the other side of the coin is to list environment charms meeting the following requirements:
1. list of charm versioned urls present in the environment as simple array of strings;
2. provide parameter to filter charm list filter by charm name.

[Anastasia (anastasia-macmood)]

Actually, the format of arguments to set annotations has been made consistent with the rest of code base based on advice from William.

The client now will take a list of entities and their corresponding annotations, thus setting different annotations on individual entity from the entities list in one call.

E.g. entity a will be annotated with pairs1 whereas entity b with pairs2.
......{
            "Type": "Annotations",
            "Request": "Set",
            "Params": {
                 "Annotations": {
                     {"Entity": a, "Annotations": pairs1},
                     {"Entity": b, "Annotations": pairs2}
                 }
             }
}......

[Anastasia (anastasia-macmood)]

Annotations GET and SET signature as of 1.22 look like this ...
SET:
......{
            "Type": "Annotations",
            "Request": "Set",
            "Params": {
                 "Annotations": {{
                    "EntityTag": a, "Annotations": pairs1
                  },{
                    "EntityTag": b, "Annotations": pairs2
                  }}
}}......

GET:

......{
            "Type": "Annotations",
            "Request": "Get",
            "Params": {
               "Entities": {
                   {Entity {"Tag": a}},
                   {Entity {"Tag": b},
               }
            }
}......

GET RETURN:

{
    "Results": {
          {"EntityTag": a, "Annotations": pairs1, "Error": nil},
          {"EntityTag": b, "Annotations": pairs2, "Error": nil},

    }

}

[Anastasia (anastasia-macmood)]

As for list charms, rick_h is aware of plans to embed a charmstore into each state server downt he road. And some of that would be listing charms that are in that charmstore which are/could be deployed ones in the environment.

[Anastasia (anastasia-macmood)]

I have just landed a new charms client. This client can list charms.

[Anastasia (anastasia-macmood)]

I have also just landed a new CLI command

juju charms list [<charm names>]

capable of displaying in both json and yaml format all or desired charm URLs for specified Juju environment.

[Kapil Thangavelu (hazmat)]

new api works great, thanks.