|
1 | 1 | # Splunk Python SDK Changelog |
2 | 2 |
|
3 | | -## v0.1.0a |
| 3 | +## 0.8.0 (beta) |
| 4 | + |
| 5 | +### Features |
| 6 | + |
| 7 | +* Improvements to entity state management |
| 8 | +* Improvements to usability of entity collections |
| 9 | +* Support for collection paging - collections now support the paging arguments: |
| 10 | + `count`, `offset`, `search`, `sort_dir`, `sort_key` and `sort_mode`. Note |
| 11 | + that `Inputs` and `Jobs` are not pageable collections and only support basic |
| 12 | + enumeration and iteration. |
| 13 | +* Support for event types: |
| 14 | + - Added Service.event_types + units |
| 15 | + - Added examples/event_types.py |
| 16 | +* Support for fired alerts: |
| 17 | + - Added Service.fired_alerts + units |
| 18 | + - Added examples/fired_alerts.py |
| 19 | +* Support for saved searches: |
| 20 | + - Added Service.saved_searches + units |
| 21 | + - Added examples/saved_searches.py |
| 22 | +* Sphinx based SDK docs and improved source code docstrings. |
| 23 | +* Support for IPv6 - it is now possible to connect to a Splunk instance |
| 24 | + listening on an IPv6 address. |
| 25 | + |
| 26 | +### Breaking changes |
| 27 | + |
| 28 | +#### Module name |
| 29 | + |
| 30 | +The core module was renamed from `splunk` to `splunklib`. The Splunk product |
| 31 | +ships with an internal Python module named `splunk` and the name conflict |
| 32 | +with the SDK prevented installing the SDK into Splunk Python sandbox for use |
| 33 | +by Splunk extensions. This module name change enables the Python SDK to be |
| 34 | +installed on the Splunk server. |
| 35 | + |
| 36 | +#### State caching |
| 37 | + |
| 38 | +The client module was modified to enable Entity state caching which required |
| 39 | +changes to the `Entity` interface and changes to the typical usage pattern. |
| 40 | + |
| 41 | +Previously, entity state values where retrieved with a call to `Entity.read` |
| 42 | +which would issue a round-trip to the server and return a dictionary of values |
| 43 | +corresponding to the entity `content` field and, in a similar way, a call to |
| 44 | +`Entity.readmeta` would issue in a round-trip and return a dictionary |
| 45 | +contianing entity metadata values. |
| 46 | + |
| 47 | +With the change to enable state caching, the entity is instantiated with a |
| 48 | +copy of its entire state record, which can be accessed using a variety of |
| 49 | +properties: |
| 50 | + |
| 51 | +* `Entity.state` returns the entire state record |
| 52 | +* `Entity.content` returns the content field of the state record |
| 53 | +* `Entity.access` returns entity access metadata |
| 54 | +* `Entity.fields` returns entity content metadata |
| 55 | + |
| 56 | +`Entity.refresh` is a new method that issues a round-trip to the server |
| 57 | +and updates the local, cached state record. |
| 58 | + |
| 59 | +`Entity.read` still exists but has been changed slightly to return the |
| 60 | +entire state record and not just the content field. Note that `read` does |
| 61 | +not update the cached state record. The `read` method is basically a thin |
| 62 | +wrapper over the corresponding HTTP GET that returns a parsed entity state |
| 63 | +record instaed of the raw HTTP response. |
| 64 | + |
| 65 | +The entity _callable_ returns the `content` field as before, but now returns |
| 66 | +the value from the local state cache instead of issuing a round-trip as it |
| 67 | +did before. |
| 68 | + |
| 69 | +It is important to note that refreshing the local state cache is always |
| 70 | +explicit and always requires a call to `Entity.refresh`. So, for example |
| 71 | +if you call `Entity.update` and then attempt to retrieve local values, you |
| 72 | +will not see the newly updated values, you will see the previously cached |
| 73 | +values. The interface is designed to give the caller complete control of |
| 74 | +when round-trips are issued and enable multiple updates to be made before |
| 75 | +refreshing the entity. |
| 76 | + |
| 77 | +The `update` and action methods are all designed to support a _fluent_ style |
| 78 | +of programming, so for example you can write: |
| 79 | + |
| 80 | + entity.update(attr=value).refresh() |
| 81 | + |
| 82 | +And |
| 83 | + |
| 84 | + entity.disable().refresh() |
| 85 | + |
| 86 | +An important benefit and one of the primary motivations for this change is |
| 87 | +that iterating a collection of entities now results in a single round-trip |
| 88 | +to the server, because every entity collection member is initialized with |
| 89 | +the result of the initial GET on the collection resource instead of requiring |
| 90 | +N+1 round-trips (one for each entity + one for the collection), which was the |
| 91 | +case in the previous model. This is a significant improvement for many |
| 92 | +common scenarios. |
| 93 | + |
| 94 | +#### Collections |
| 95 | + |
| 96 | +The `Collection` interface was changed so that `Collection.list` and the |
| 97 | +corresponding collection callable return a list of member `Entity` objects |
| 98 | +instead of a list of member entity names. This change was a result of user |
| 99 | +feedback indicating that people expected to see eg: `service.apps()` return |
| 100 | +a list of apps and not a list of app names. |
| 101 | + |
| 102 | +#### Naming context |
| 103 | + |
| 104 | +Previously the binding context (`binding.Context`) and all tests & samples took |
| 105 | +a single (optional) `namespace` argument that specified both the app and owner |
| 106 | +names to use for the binding context. However, the underlying Splunk REST API |
| 107 | +takes these as separate `app` and `owner` arguments and it turned out to be more |
| 108 | +convenient to reflect these arguments directly in the SDK, so the binding |
| 109 | +context (and all samples & test) now take separate (and optional) `app` and |
| 110 | +`owner` arguments instead of the prior `namespace` argument. |
| 111 | + |
| 112 | +You can find a detailed description of Splunk namespaces in the Splunk REST |
| 113 | +API reference under the section on accessing Splunk resources at: |
| 114 | + |
| 115 | +* http://docs.splunk.com/Documentation/Splunk/latest/RESTAPI/RESTresources |
| 116 | + |
| 117 | +#### Misc. API |
| 118 | + |
| 119 | +* Update all classes in the core library modules to use new-style classes |
| 120 | +* Rename Job.setpriority to Job.set_priority |
| 121 | +* Rename Job.setttl to Job.set_ttl |
| 122 | + |
| 123 | +### Bug fixes |
| 124 | + |
| 125 | +* Fix for GitHub Issues: 2, 10, 12, 15, 17, 18, 21 |
| 126 | +* Fix for incorrect handling of mixed case new user names (need to account for |
| 127 | + fact that Splunk automatically lowercases) |
| 128 | +* Fix for Service.settings so that updates get sent to the correct endpoint |
| 129 | +* Check name arg passed to Collection.create and raise ValueError if not |
| 130 | + a basestring |
| 131 | +* Fix handling of resource names that are not valid URL segments by quoting the |
| 132 | + resource name when constructing its path |
| 133 | + |
| 134 | +## 0.1.0a (preview) |
4 | 135 |
|
5 | 136 | * Fix a bug in the dashboard example |
6 | 137 | * Ramp up README with more info |
7 | 138 |
|
8 | | -## v0.1.0 |
| 139 | +## 0.1.0 (preview) |
9 | 140 |
|
10 | | -* Initial Python SDK release |
| 141 | +* Initial Python SDK release |
0 commit comments