f5networks / f5-common-python Goto Github PK
View Code? Open in Web Editor NEWPython SDK for configuration and monitoring of F5® BIG-IP® devices via the iControl® REST API.
Home Page: https://f5-sdk.readthedocs.org
License: Apache License 2.0
Python SDK for configuration and monitoring of F5® BIG-IP® devices via the iControl® REST API.
Home Page: https://f5-sdk.readthedocs.org
License: Apache License 2.0
Maybe this is done... in which case I guess you should just close this issue.
Many of the methods in the RESTInterfaceCollection
subclasses have set_* methods that all do very similar things. This can be added to the base class in a way they can use.
The add_member() method in the pool.py interface accepts default keyword arguments, yet the first if statement checks to ensure these keyword arguments are set. If not, then the method returns false, and the member is not created. It should raise an exception (of some kind) and the necessary keyword arguments should just become positional (required) arguments.
https://github.com/F5Networks/f5-common-python/blob/develop/f5/bigip/interfaces/pool.py#L364
This issue occurs during the peering process. Here is the traceback:
Nov 09 23:12:35: delaying prior to checking hostname
Nov 09 23:12:37: set folder to /Common blindly attempting to avoid exception on get_hostname
Nov 09 23:12:37: check hostname: host-10-4-4-49.int.liTraceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/f5/onboard/bigip/cluster_generic.py", line 533, in main
BIGIP_CLUSTER_GENERIC.set_up()
File "/usr/lib/python2.7/dist-packages/f5/onboard/bigip/cluster_generic.py", line 103, in set_up
self.cluster_devices(all_devices, tg_list)
File "/usr/lib/python2.7/dist-packages/f5/onboard/bigip/cluster_generic.py", line 223, in cluster_devices
bigip_config['password']
File "/usr/lib/python2.7/dist-packages/f5/bigip/interfaces/__init__.py", line 235, in wrapper
return method(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/f5/bigip/interfaces/cluster.py", line 333, in add_peer
% os.path.basename(self.mgmt_dev.get_local_device())
AttributeError: 'Cluster' object has no attribute 'mgmt_dev'
neratesystems.com
Nov 09 23:12:37: host name set
Will drop this into the debugger to investigate.
RESTInterfaceCollection calls property json instead of method json() on response object returned by request methods. For example: response.json.get instead of response.json().get.
The repo is missing some files and structure from the team template. Add basic directory structure and sample files for the team to start to fill in during their development.
Some modules, like rule.py, do not currently expose a "get_all" API. RESTInterfaceCollection provides an _get_items so all modules _should_be able to provide a simple wrapper to get this functionality for free.
The remove_metadata method can throw an exception that is not handled. Add try-catch block
Add new targets to create Debian and RedHat packages using docker containers.
Create a sample functional test using a live BIG-IP VE to demonstrate how to test the API against real resources.
Create unit tests.
API functions should return an object when calling create, for the new "thing" created, otherwise raise an error. The current code is inconsistent in that it returns True or False for some errors and raise for others. The caller cannot tell from a False return what went wrong.
API functions currently declare all arguments as 'conditional' (i.e. key=default). This makes it impossible to know how to use an API without code and live VE exploration. For instance, the nat create API only requires name, ip_address and orig_ip_address. But I have to look in the GUI to figure that out, and also iterate in the code trying different combinations.
Required args MUST NOT have a default value to force proper usage by the caller.
This is usually after a device is peered, as shown in the snippet below. From the official F5 Documentation, this issue usually reflects a possible conflict among two or more devices because more than one device contains changes that have not been synchronized to the device group. Possibly a timing issue in the cluster.py code.
Nov 10 16:11:18: Adding peer host-10-4-4-55.int.lineratesystems.com
Nov 10 16:11:23: Added peer host-10-4-4-55.int.lineratesystems.com
Nov 10 16:11:23: waiting 5 secs for peer to add
Nov 10 16:11:28: Wait until device_trust_group is in sync...
Nov 10 16:11:29: device_trust_group sync status: red, Disconnected
Nov 10 16:11:29: Waiting 2 seconds fore checking sync state again.
Nov 10 16:11:31: device_trust_group sync status: red, Disconnected
Nov 10 16:11:31: Waiting 2 seconds fore checking sync state again.
Nov 10 16:11:33: device_trust_group sync status: yellow, Changes Pending
Nov 10 16:11:33: Waiting 2 seconds fore checking sync state again.
Nov 10 16:11:35: device_trust_group sync status: yellow, Changes Pending
Nov 10 16:11:35: Waiting 2 seconds fore checking sync state again.
Link to F5 BigIP documentation where the information about sync states was pulled from (https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-11-2-1/7.html)
Unless they don't (In which case this issue is really a "question".). I'm assigning to ye' olde packaging czar.
All traffic groups are forced to standby once they are created. This is presumably to test that the failover process works correctly. From F5's Official Documentation, when all traffic groups defined on a host failover to the standby, thus the host has no active traffic groups left, then the system itself is labeled as Online (STANDBY). https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-11-5-0/8.html
You can use the BIG-IP® Configuration utility to view the current failover state of a device in a device group. An Active failover state indicates that at least one traffic group is currently active on the device. A Standby failover state indicates that all traffic groups on the device are in a Standby state.
The simple bug here may be that there were no standby traffic groups defined on one or more devices, so when all active traffic groups failover (to the standby devices defined), one or more devices goes into standby because it is not listed as a standby for any of the traffic groups.
Should test dependencies (e.g. mock, responses, pytest) be in requirements.txt?
Should there be a switch that allows an installer to choose whether or not they want test dependencies? If yes, then how should the switch be implemented?
What should it be set to by default?
I suppose @jlongstaf, @pjbreaux, @swormke, and I should at least know what policy we decide on, so we can correctly implement in future repositories.
I'm tentatively assigning this to @richbrowne since he's the packaging czar. (As always I believe we should feel free to reassign issues willy-nilly.)
There is a lot of redundant code in the interface classes that we can replace with a base class that they inherit. If they have special logic it can be overloaded, but the basics are all the same:
exists()
delete()
delete_all()
_get()
_get_named_object()
The implementation of BigIP ltm property returns the cm collection instead of the ltm collection.
The bug is that checking a string for truthiness, as long as it is non-empty, will return True. This fixes that issue to check for the string "true".
There's a reference to a different (ltm/arp
) RESTInterfaceCollection from the ltm/pool
RESTInterfaceCollection. Since the BigIP object is necessarily the mediator for inter-RESTInterfaceCollection interactions, I need to refactor it now.
In order to be better organized for future interfaces we need to break them up into a more hierarchical structure. We can follow the structure of the organizing collections in the same way the REST API does.
/ltm/
/net/
/cm/
/sys/
...
For now we return True, this should be more carefully considered when we look at code that consumes these collections.
This includes unit tests for the nat.py
module
The repository was restructured significantly. The setup.py needs to be changed to reflect this refactor and should be reversioned.
The delete_all
method seems to delete resources from a BigIP object in a way that is defined in the interface, i.e. it's a method of the RESTInterfaceCollection, but in a way that doesn't use any of the particular structure of the BigIP itself.
My thought is that this may be an improper location for this abstraction.
Lower level (closer to the BigIP) operations live in the appropriate interface-collection that inherits from the RESTInterfaceCollection
, (e.g. a pool
, or a nat
) those classes support operations that make sense in the context of a pool (e.g. the delete
operation of a pool
systematically removes all /members
of a particular ~folder~name
'd pool). So the delete
operation in a pool
removes multiple things, but in a way that's constrained by its definition. This seems correct to me.
A consumer of the RESTInterfaceCollection
class should also be able to call its delete
method with arbitrary suffixes in order to delete
resources in a way that is unconstrained by the structure of the resources on the BigIP object itself.
So... in short, I don't think we should implement support for operations on the BigIP object, except those that respect the BigIP's structure, and are implemented inside the RESTInterfaceCollections that inherit from the RESTInterfaceCollection.
Currently there is a restriction that the tests need to be run from the root directory of the project in pool.py
. Change this to use the built in os directives and find the path dynamically.
The OpenStack hacking package (https://github.com/openstack-dev/hacking#id1) is a set of flake8 plugins that enforce the OpenStack project reference style guide. Need to fix the flake8 errors in all Python modules.
In particular we are migrating from the old "interfaces" to the:
https://devcentral.f5.com/d/icontrol-rest-user-guide-version-1150
compliant "root_collections" nomenclature.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.