I'm seeing an issue where the SoftLayer API is missing the serverRoom field for over 75% of our servers. I've confirmed this using both their python and ruby libraries (https://softlayer-api-python-client.readthedocs.org/en/latest/api/managers/hardware/#SoftLayer.managers.hardware.HardwareManager.list_hardware and https://softlayer.github.io/ruby/server_locate/ respectively). Note that the ruby code I'm running is simply one of their published examples.
It seems like SoftLayer has a naming convention of creating FQDN like [dataCenter].[serverRoom].[rackNumber].[slotNumber]. I'm not sure if it is just another indicator of the problem or helpful in troubleshooting the root cause, but the servers that are missing serverRoom seem to be named incorrectly by SoftLayer, according to what appears to be SoftLayer's naming convention. They are named [dataCenter].[rackNumber].[slotNumber], notably missing serverRoom.
Basically it looks like their database (which I assume is backing their API) is just missing the serverRoom for most of the hosts, or they named most of our hosts incorrectly and the database can't account for it, so the info is missing when I call their API. Does anyone have a similar experience where SoftLayer perhaps named things wrong, or forgot to do this data entry, or are there some other/different API calls I should be making beyond what SoftLayer themselves recommend?
I tried to verify and reproduce the issue that you mentioned, but I couldn't. please Submit a ticket with all the information that you can provide to verify and isolate this issue.
SoftLayer support confirmed that there was a some sort of block on hidden sites where this info wasn't displayed via their API. Thanks to #ruber-cuellar was who said something similar in one of his comments, but I disagree that "There is not an issue." From my perspective there definitely was an issue that they (SoftLayer support) needed to resolve on their end before their example API calls started showing us all the info. Special thanks to ALLmightySPIFF on #softlayer who was able to repro the issue for me and provided a realtime response.
Related
Im using this lib for a while, everything was working great. Using it to query cpu utilization of gcloud machines.
this is my code:
query_obj = Query(metric_service_client, project, "compute.googleapis.com/instance/cpu/utilization",
minutes=mins_backward_check)
metric_res = query_obj.as_dataframe()
Everything was working fine until lately it started to fail.
I'm getting:
{AttributeError}'WhichOneof'
Deubbing it, i see it fails inside "as_dataframe()" code, specifically in this part:
data=[_extract_value(point.value) for point in time_series.points]
When it tries to extract the value from the point object.
The _extract_value values code seems to use the WhichOneof attribute which seems to be related to protobuff lib.
I didn't change any of those libs versions, anyone has any clue what causes it to fail now?
If you're confident (!) that you've not changed anything, then this would appear to be Google breaking its API and you may wish to file an issue on Google's issue tracker on one of these components:
https://issuetracker.google.com/issues/new?component=187228&template=1162638
https://issuetracker.google.com/issues/new?component=187143&template=800102
I think Cloud Monitoring is natively a gRPC-based API which would explain the protobuf reference.
A good sanity check is to use APIs Explorer and check the method you're using there to see whether you can account for the request|response, perhaps:
https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.timeSeries/query
NOTE Your question may be easy to parse for someone familiar with the Cloud Monitoring Python SDK but isn't easy to repro. Please consider providing a simple repro of your issue, including requirements.txt and a full code snippet.
I would greatly benefit from a list of all the available headers that App Service can forward to my (keyword PYTHON) Function. Or if someone knows how to "list-all", that would be awesome.
Through asking questions on SO, I see that the request IP addressed can be gleaned using:
req.headers.get("X-FORWARDED-FOR").
I need the Hostname that a request is coming from.
Looks like this is possible using C# Functions. But I either did it wrong using req.headers.Host or its not available for Python.
Is it possible using Python?
For this requirement, you just need to use req.headers.get("host"). I test it in my side, it works fine on azure portal.
If there is someone out there who has already worked with SOLR and a python library to index/query solr, would you be able to try and answer the following question.
I am using the mySolr python library but there are others out (like pysolr) there and I don't think the problem is related to the library itself.
I have a default multicore SOLR setup, so no authentication required normally. Don't need it to access the admin page at http://localhost:8080/solr/testcore/admin/ either
from mysolr import Solr
solr = Solr('http://localhost:8080/solr/testcore/')
response = solr.search(q='*:*')
print("response")
print(response)
This code used to work but now I get a 401 reply from SOLR ... just like that, no changes have been made to the python virtual env containing mysolr or the SOLR setup. Still...something must have changed somewhere but I'm out of clues.
What could be the causes of a SOLR 401 reponse?
Additional info: This script and mor advanced script do work on another PC, just not on the one I am working on. Also, adding "/select?q=:" behind the url in the browser does return the correct results. So the SOLR is setup correctly, it has probably something to do with my computer itself. Could windows settings (of any kind) have an impact on how SOLR responds to requests from python? The python env itself has been reinstalled several times to no avail.
Thanks in advance!
The problem was: proxy.
If this exact situation was ever to occur to someone and you are behind a proxy, check if your HTTP and HTTPS environmental variables are not set. If they are... this might cause the python session to try using the proxy while it shouldn't (connecting to localhost via proxy).
It didn't cause any trouble for months but out of the blue it did so whether you encounter this or not might be dependent on how your IT setup your proxy or made some other changes...somewhere.
thank you everyone!
I am trying to implement an assertion consumer for signed WS-Federation tokens as part of a SSO system. I know that simplesamlphp has (undocumented) ws-fed support, but I'm using a Django stack. It looks like djangosaml2 pysaml2 doesn't support the WS-Federation specification as they expect XML with a 'Response' root node, and not a 'RequestSecurityTokenResponseCollection' root node.
Has anyone run into this before? Is there a python library out there that can help me? I'm tempted just to roll my own consumer, but I'm afraid I might slip up and create a security vulnerability due to my lack of X509 and xml knowledge.
Thanks!
I use django-auth-adfs for adfs authentication. I'm not sure how WS-Federation fits in the mix in a Python application, however, if you are authenticating to ADFS, this library does a decent job.
Is there a way to unsubscribe from a user's presence? I no longer want to receive updates on /_ah/xmpp/presence/... for a particular user. I can't seem to find a simple API call to do that.
After digging around the XMPP protocol I found this which seems to indicate that doing a send_presence with presence type of 'unsubscribe' should work. Unfortunately digging into the GAE's xmpp API it appears that it defines
_VALID_PRESENCE_TYPES = frozenset([PRESENCE_TYPE_AVAILABLE,
PRESENCE_TYPE_UNAVAILABLE,
PRESENCE_TYPE_PROBE])
Which means I can't even do a send_presence(user_to_remove, status="", presence_type="unsubscribe") (PRESENCE_TYPE_AVAILABLE and others are just strings like "available" as per the xmpp specificiation)
Has anyone come across this issue or know how to achieve this ?
It seems that you can't. The docs (and the docstring) confirm that presence_type accepts a subset of the types defined in RFC 3921.
You can submit this as a feature request to the issue tracker.
As an experiment, you could re-implement your own "send_presence" that does the same thing as the existing function, without the check for valid presence types. Not officially sanctioned but worth a try.
One thing to note is that this won't block clients from re-subscribing from your bot or from badly-behaved clients ignoring it.
And as Drew mentioned, please do submit an issue on the issue tracker.