I'm confused as why OpenTelemetry documentaion has OpenTelemetry Python API and OpenTelemetry Python SDK.
Like when using the specification in python when we should consider pip install opentelemetry-api over pip install opentelemetry-sdk
From the github pages of the implementation.
(note: could not fit this into a comment and did not want to just post a link alone)
This repository includes multiple installable packages. The
opentelemetry-api package includes abstract classes and no-op
implementations that comprise the OpenTelemetry API following the
OpenTelemetry specification. The opentelemetry-sdk package is the
reference implementation of the API.
Libraries that produce telemetry data should only depend on
opentelemetry-api, and defer the choice of the SDK to the application
developer. Applications may depend on opentelemetry-sdk or another
package that implements the API.
In simple terms imagine a plain python or JAVA interface. An interface by itself is just a contract saying what all things it can do. But you cannot use that in your code anywhere without implementing the interface first. So interfaces are just abstract contracts(API) which needs to be have concrete implementations(SDK). It is only then can you use the SDK.
Such strategies normally help with unifying the implementations of software libraries across industry under a consistent and constant contract. There are multiple vendors out there like Datadog, New Relic, DynaTrace, Signoz and more who can now implement their own SDK if needed but at the same time comply with a standard contract that everyone abides by. This allows you as application developers to not get coupled to any one vendor. But have the option to choose the best one among them and make the swap when necessary without breaking anything in your software system.
Hope this helps answering why application may only depend on SDK.
Related
I've many legacy applications developed in Zope and I want to evolve them to enterprise grade apps.
But I didn't find sufficient documentation to develop a "modern" app in Zope:
Authentication: how can I integrate Products.PluggableAuthService?
ORM: how can I use an ORM to abstract data model in my stack?
Application Architecture: may I build a Product for each Model or for each View? Or there is another way to organize the application?
Versioning and Deploy activity.
Where can I find documentation, samples and best practice to do my task?
The standard Zope documentation is old and incomplete to my scope.
First I would try to get an overview of the state of the applications. Which Zope version are they running on? Note that the widely spread version 2.13 (or even lower) is no longer maintained, see https://www.zope.dev/developer/roadmap.html
If you know what you have, you can estimate the effort to port them on a supported version, or whether it makes more sense to replace the applications.
how can I integrate Products.PluggableAuthService
The plugin has a pretty good documentation, see https://productspluggableauthservice.readthedocs.io/en/latest/ - also have a look in the example plugins. If you have specific questions, I would suggest you to ask in the following forum - https://community.plone.org/
ORM: how can I use an ORM to abstract data model in my stack?
For Zope applications, you usually don't use an ORM. The model classes inherit from Persistent or similar.
Application Architecture: may I build a Product for each Model or for each View? Or there is another way to organize the application?
Usually, one product contains the model and the necessary views, but you can certainly also develop the applications in just one big folder. That depends on your preferences and how big the team of developers is.
Versioning and Deploy activity.
For versioning I just used git, as everybody nowadays.
For deployment, there is buildout, or pip with requirements.txt or ansible or what I used ... https://batou.readthedocs.io/en/stable/
Where can I find documentation, samples and best practice to do my task?
You could look at Plone, as Plone is a pretty modern Zope application.
The standard Zope documentation is old and incomplete to my scope.
The Zope documentation partly has been updated for Zope 4. As a matter of fact, the documentation is just too extensive, the team of maintainers is pretty small, and "nobody" starts a new Zope project nowadays.
What actually happens - it gets updated now and then when work is done on e.g. a changing behavior, then also the documentation gets updated.
Try to work with the documentation, and when you notice something outdated, try to fix / update it, that is the way I learned to work with Zope.
Other than that - I think it is pretty awesome, that Zope is still alive, working, and security patched within days as it is already more than 20 years old and the number of maintainers is pretty small.
I am looking for examples or actual documentation for Train level Openstack Octavia (Load Balancer component) python API. Everything in the OS project doc site seems to be focused on the CLI. I would like an example and possible API specification (what to pass in, what to expect out of the functions defined for the OctaviaAPI class in the component. I have been looking for a few hours with little success.
Try https://docs.openstack.org/openstacksdk/latest/user/proxies/load_balancer_v2.html. In general, projects' documentation sites don't cover Python bindings, as they are not part of the projects. OpenstackSDK is its own project.
Yeah, the client based python binds are being phased out in favor of the openstacksdk. Octavia went straight to using openstacksdk for the python bindings.
I new to SSO and I've only tried pysaml2 by far.
I am also aware of python3-saml library (and its python-saml Python 2 flavour).
I need to use one of those with Shibboleth, if it is relevant.
What are the pros and cons of pysaml2 and python3-saml?
Update:
As for 2019, I still find python3-saml to be the best option if you need to implement an SP. It is not flawless (sorry #smartin, hhehe), but it will give you much less headache than pysaml2.
Both projects are compatible with Shibboleth.
pysaml2 is older than python3-saml, right now both support py2 and py3. Both are kinda active and documented.
python3-saml follows the structure of Onelogin's SAML toolkit so if you used any other toolkit before (php-saml, ruby-saml, java-saml), will be easy for you to handle with it (similar methods, same settings).
Differences
Crypto:
pysaml2 uses as dependecy pycryptodome to handle with cryptography and implements its own xmldsig and xmlenc classes (to manipulate signatures and encryption on XMLs).
python3-saml uses as dependecy python-xmlsec and delegates on it the signature/encryption of XML elements.
Functionality:
pysaml2 let you deploy an Identity Provider or a Service Provider
python3-saml is focused on the Service Provider
Settings:
In my opinion, python3-saml is easier than pysaml2, settings are more precise and its repo contains code examples on how integrate a django or a flask app and a guide at the docs.
Note: I'm the author of python3-saml
I search for OpenID-library, which works with python3. I need to be an OpenID-provider and OpenID-consumer. tornado.auth provides only consumer functionality. What I can use to implement provider functionality, or how it can be implemented with tornado?
Does anybody uses python3-openid (fork of python-openid)? How it works?
python3-openid is the Python 3 version of python-openid, which has been more or less the reference library for OpenID in Python for several years. So it should implement everything you need. (Disclaimer: I ported python3-openid over and am the maintainer of the PyPI package).
However, for Tornado you will need a non-blocking implementation, ideally using Tornado's HTTPClient classes, and currently python3-openid does not provide that -- if you'd like to implement it, though, I'll gladly work on your pull request!
I went with pyoidc because it is listed as a "Certified Relying Party Library" on the official list of "Certified OpenID Connect Implementations" directly on the website for the OpenID standard. It runs on Python 3.5+ and also doubles as a full OAuth2.0 implementation.
I know this is an old post but it is still relevant. One should not screw around when it comes to things like security and authentication, it could very well save your job to stick with officially recommended or certified libraries - if anything goes wrong, at least your choice of authentication library can't be called into question!
have you tried this, i found it on pypi:
http://pypi.python.org/pypi/python3-openid/3.0.1
what is the advantage of using a python virtualbox API instead of using XPCOM?
The advantage is that pyvb is lot easier to work with.
On the contrary the documentation for the python API of XPCOM doesn't exist, and the API is not pythonic at all. You can't do introspection to find methods/attributes of an object, etc. So you have to check the C++ source to find how it works or some python scripts already written (like vboxshell.py and VBoxWebSrv.py).
On the other hand pyvb is really just python wrapper that call VirtuaBoxManager on the command line. I don't know if it's a real disadvantage or not?
I would generally recommend against either one. If you need to use virtualization programmatically, take a look at libvirt, which gives you cross platform and cross hypervisor support; which lets you do kvm/xen/vz/vmware later on.
That said, the SOAP api is using two extra abstraction layers (the client and server side of the HTTP transaction), which is pretty clearly then just calling the XPCOM interface.
If you need local host only support, use XPCOM. The extra indirection of libvirt/SOAP doesn't help you.
If you need to access virtualbox on a various hosts across multiple client machines, use SOAP or libvirt
If you want cross platform support, or to run your code on Linux, use libvirt.
From sun's site on VirtualBox python APIs:
SOAP allows to control remote VMs over
HTTP, while XPCOM is much more
high-performing and exposes certain
functionality not available with SOAP.
They use very different technologies
(SOAP is procedural, while XPCOM is
OOP), but as it is ultimately API to
the same functionality of the
VirtualBox, we kept in bindings
original semantics, so other that
connection establishment, code could
be written in such a way that people
may not care what communication
channel with VirtualBox instance is
used.
From that article, I'm having trouble seeing the difference between "python virtualbox API" and "XPCOM". Could you provide a link to the API you're thinking of?