Is your feature request related to a problem? Please describe.
When using Telemetry Streaming while also managing configuration with AS3 in /Common/Shared on the same device, unless you are careful to incorporate the declarations for objects created by TS back into your AS3 declarations, any management of /Common/Shared through AS3 can potentially delete objects created by Telemetry Streaming. (At the very least, the AS3 declaration may fail as it tries to delete undeclared objects in that partition).
For example, Telemetry Streaming will create virtual servers, logging profile and pools in /Common/Shared. If you are also making changes to /Common/Shared in other AS3 declarations, AS3 will attempt to delete those TS configurations (when performing a POST rather than a PATCH).
Describe the solution you'd like
I would like to see an update to the Telemetry Streaming FAQ that mentions the overlap between TS and AS3 with a recommendation to make sure you remember to incorporate any configuration into any AS3 declarations that also manipulate the /Common/Shared partition.
Describe alternatives you've considered
I've considered using a PATCH command for any declaration within the /Common/Shared partition, however it does break the declarative model (as per AS3 best practices )
Don't use the TS API, instead configure relevant objects using AS3 directly. This is definitely an option once you understand what TS is doing under the covers, but as there is a TS API, people will use it and potentially have this issue.
The Telemetry Streaming API should create objects under its own partition rather than /Common/Shared to avoid any overlap. I prefer this solution as a long term change, although I don't know if there are any objects that MUST live in /Comon to wrok.
Additional context
This issue does not cause any actual deletion of configuration as far as I can tell. When AS3 tries to remove TS created configuration, it fails as certain objects are in use and therefore can't be deleted. Based on this, simply updating some documentation to make the user aware is likely the best approach.
Is your feature request related to a problem? Please describe.
When using Telemetry Streaming while also managing configuration with AS3 in
/Common/Sharedon the same device, unless you are careful to incorporate the declarations for objects created by TS back into your AS3 declarations, any management of/Common/Sharedthrough AS3 can potentially delete objects created by Telemetry Streaming. (At the very least, the AS3 declaration may fail as it tries to delete undeclared objects in that partition).For example, Telemetry Streaming will create virtual servers, logging profile and pools in
/Common/Shared. If you are also making changes to/Common/Sharedin other AS3 declarations, AS3 will attempt to delete those TS configurations (when performing a POST rather than a PATCH).Describe the solution you'd like
I would like to see an update to the Telemetry Streaming FAQ that mentions the overlap between TS and AS3 with a recommendation to make sure you remember to incorporate any configuration into any AS3 declarations that also manipulate the
/Common/Sharedpartition.Describe alternatives you've considered
I've considered using a PATCH command for any declaration within the
/Common/Sharedpartition, however it does break the declarative model (as per AS3 best practices )Don't use the TS API, instead configure relevant objects using AS3 directly. This is definitely an option once you understand what TS is doing under the covers, but as there is a TS API, people will use it and potentially have this issue.
The Telemetry Streaming API should create objects under its own partition rather than
/Common/Sharedto avoid any overlap. I prefer this solution as a long term change, although I don't know if there are any objects that MUST live in /Comon to wrok.Additional context
This issue does not cause any actual deletion of configuration as far as I can tell. When AS3 tries to remove TS created configuration, it fails as certain objects are in use and therefore can't be deleted. Based on this, simply updating some documentation to make the user aware is likely the best approach.