|
4 | 4 |
|
5 | 5 | ### Features |
6 | 6 |
|
7 | | -* Added support for IPv6, can now connect to a splunkd listening on an IPv6 |
8 | | - address. |
| 7 | +* Support for IPv6, can now connect to a splunkd listening on an IPv6 address. |
| 8 | +* Improvements to entity state management |
| 9 | +* Improvements to usability of entity collections |
9 | 10 | * Improvements to unit tests |
10 | 11 |
|
11 | 12 | ### Breaking changes |
12 | 13 |
|
13 | | -* Renamed the core module from `splunk` to `splunklib`. The Splunk product |
14 | | - already ships with an internal Python module named `splunk` and the name |
15 | | - conflict with the SDK prevented installing the SDK into Splunk Python sandbox |
16 | | - for use by Splunk extensions. |
| 14 | +#### Module name |
17 | 15 |
|
18 | | -* Update all classes in the core library modules to use new-style classes |
19 | | -* Rename Job.setpriority to Job.set_priority |
20 | | -* Rename Job.setttl to Job.set_ttl |
| 16 | +The core module was renamed from `splunk` to `splunklib`. The Splunk product |
| 17 | +ships with an internal Python module named `splunk` and the name conflict |
| 18 | +with the SDK prevented installing the SDK into Splunk Python sandbox for use |
| 19 | +by Splunk extensions. This module name change enables the Python SDK to be |
| 20 | +installed on the Splunk server. |
| 21 | + |
| 22 | +#### State caching |
| 23 | + |
| 24 | +The client module was modified to enable Entity state caching which required |
| 25 | +changes to the `Entity` interface and changes to the typical usage pattern. |
| 26 | + |
| 27 | +Previously, entity state values where retrieved with a call to `Entity.read` |
| 28 | +which would issue a round-trip to the server and return a dictionary of values |
| 29 | +corresponding to the entity `content` field and, in a similar way, a call to |
| 30 | +`Entity.readmeta` would issue in a round-trip and return a dictionary |
| 31 | +contianing entity metadata values. |
| 32 | + |
| 33 | +With the change to enable state caching, the entity is instantiated with a |
| 34 | +copy of its entire state record, which can be accessed using a variety of |
| 35 | +properties: |
| 36 | + |
| 37 | +* `Entity.state` returns the entire state record |
| 38 | +* `Entity.content` returns the content field of the state record |
| 39 | +* `Entity.metadata` returns the metadata field of the state record |
| 40 | + |
| 41 | +`Entity.refresh` is a new method that issues a round-trip to the server |
| 42 | +and updates the local, cached state record. |
| 43 | + |
| 44 | +`Entity.read` still exists but has been changed slightly to return the |
| 45 | +entire state record and not just the content field. Note that `read` does |
| 46 | +not update the cached state record. The `read` method is basically a thin |
| 47 | +wrapper over the corresponding HTTP GET that returns a parsed entity state |
| 48 | +record instaed of the raw HTTP response. |
| 49 | + |
| 50 | +The entity _callable_ returns the `content` field as before, but now returns |
| 51 | +the value from the local state cache instead of issuing a round-trip as it |
| 52 | +did before. |
| 53 | + |
| 54 | +It is important to note that refreshing the local state cache is always |
| 55 | +explicit and always requires a call to `Entity.refresh`. So, for example |
| 56 | +if you call `Entity.update` and then attempt to retrieve local values, you |
| 57 | +will not see the newly updated values, you will see the previously cached |
| 58 | +values. The interface is designed to give the caller complete control of |
| 59 | +when round-trips are issued and enable multiple updates to be made before |
| 60 | +refreshing the entity. |
| 61 | + |
| 62 | +The `update` and action methods are all designed to support a _fluent_ style |
| 63 | +of programming, so for example you can write: |
| 64 | + |
| 65 | + entity.update(attr=value).refresh() |
21 | 66 |
|
22 | | -* Naming context - previously the binding context (`binding.Context`) and all |
23 | | - tests & samples took a single (optional) `namespace` argument that specified |
24 | | - both the app and owner names to use for the binding context. However, the |
25 | | - underlying Splunk REST API takes these as separate `app` and `owner` arguments |
26 | | - and it turned out to be more convenient to reflect these arguments directly |
27 | | - in the SDK, so the binding context (and all samples & test) now take separate |
28 | | - (and optional) `app` and `owner` arguments instead of the prior `namespace` |
29 | | - argument. |
| 67 | +And |
30 | 68 |
|
31 | | - You can find a detailed description of Splunk namespaces in the Splunk REST |
32 | | - API reference under the section on accessing Splunk resources at: |
| 69 | + entity.disable().refresh() |
| 70 | + |
| 71 | +An important benefit and one of the primary motivations for this change is |
| 72 | +that iterating a collection of entities now results in a single round-trip |
| 73 | +to the server, because every entity collection member is initialized with |
| 74 | +the result of the initial GET on the collection resource instead of requiring |
| 75 | +N+1 round-trips (one for each entity + one for the collection), which was the |
| 76 | +case in the previous model. This is a significant improvement for many |
| 77 | +common scenarios. |
33 | 78 |
|
34 | | - * http://docs.splunk.com/Documentation/Splunk/latest/RESTAPI/RESTresources |
| 79 | +#### Collections |
| 80 | + |
| 81 | +The `Collection` interface was changed so that `Collection.list` and the |
| 82 | +corresponding collection callable return a list of member `Entity` objects |
| 83 | +instead of a list of member entity names. This change was a result of user |
| 84 | +feedback indicating that people expected to see eg: `service.apps()` return |
| 85 | +a list of apps and not a list of app names. |
| 86 | + |
| 87 | +#### Naming context |
| 88 | + |
| 89 | +Previously the binding context (`binding.Context`) and all tests & samples took |
| 90 | +a single (optional) `namespace` argument that specified both the app and owner |
| 91 | +names to use for the binding context. However, the underlying Splunk REST API |
| 92 | +takes these as separate `app` and `owner` arguments and it turned out to be more |
| 93 | +convenient to reflect these arguments directly in the SDK, so the binding |
| 94 | +context (and all samples & test) now take separate (and optional) `app` and |
| 95 | +`owner` arguments instead of the prior `namespace` argument. |
| 96 | + |
| 97 | +You can find a detailed description of Splunk namespaces in the Splunk REST |
| 98 | +API reference under the section on accessing Splunk resources at: |
| 99 | + |
| 100 | +* http://docs.splunk.com/Documentation/Splunk/latest/RESTAPI/RESTresources |
| 101 | + |
| 102 | +#### Misc. API |
| 103 | + |
| 104 | +* Update all classes in the core library modules to use new-style classes |
| 105 | +* Rename Job.setpriority to Job.set_priority |
| 106 | +* Rename Job.setttl to Job.set_ttl |
35 | 107 |
|
36 | 108 | ### Bug fixes |
37 | 109 |
|
|
0 commit comments