Servicenow Rest API link broken after Upgrade to San Diego - rest

I am pulling a report on sc_req_item table, this is the command:
curl --user username:password https://myurl.service-now.com/api/now/table/sc_req_item?sysparm_display_value=true&sysparm_exclude_reference_link=true&sysparm_limit=1
I am getting this error:
{"error":{"detail":"NullPointerException Check logs for error trace or enable glide.rest.debug property to verify REST request processing","message":"NullPointerException"},"status":"failure"}'
It was working fine before the upgrade to latest release(san diego).
and also QA and DEV are returning results, only issue is with PROD.
Could you guys please help.

Did you check the system log? The most likely culprits are a function field, a calculated field, or a before query business rule.

Check if the sc_req_item table in Production corresponds to the versions available in your QA and DEV environments.
You could also test the request in production without the sysparm_display_value set to true.

Related

How to verify a contract on Avalanche testnet using Brownie

I am trying deploy and verify a contract using brownie on avalanche testnet.
The contract deploys and verifies fine on kovan. It deploys on avalanche testnet but I cannot get it verified.
The default brownie does not come with an explorer for avax testnet(kept getting explorer error) so I tried to add it.
I have tried variations of the testnet.snowtrace.io and they all give connection error except:
https://testnet.snowtrace.io/api - gives valueerror: error
I am using export SNOWTRACE_TOKEN= as per the documentation for avalanche and obtained an API key from https://snowtrace.io
Any idea IF and how this can be accomplished?
this does not seem to work on avax-test, using manual workaround so far ...
https://github.com/eth-brownie/brownie/issues/1417
Actually by default brownie "avax-test" network doesn't have set explorer field, So we have to set it manually by running below command,
brownie networks modify avax-test explorer=https://api-testnet.snowtrace.io/api
And you will able to verify contract.
Don't forget to add env variable,
SNOWTRACE_TOKEN=YOUR_TOKEN

Why am I getting this "unauthorized" error when trying to mirror OKD installation images from Quay.io?

I have been working on an installation of OKD on an air-gapped environment. The first major step has been mirroring the OKD images so that they can be moved over to the new environment and pulled locally. I've been following a combination of the OpenShift documentation and this article, as well as this resource for getting my certificates set up. I have been making slow but consistent progress.
However, I am now having trouble when attempting to actually mirror the files using
oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
--to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
--to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
I get the following, encouraging response:
info: Mirroring 120 images to host.okd-registry.dns:5000/ocp4/openshift4 ...
followed by blobs: and manifests: lines, and finally the line
stats: shared=0 unique=7 size=105.3MiB ratio=1.00
I then get about 50 lines stating
error: unable to retrieve source image quay.io/openshift-release-dev/ocp-v4.0-art-dev manifest
sha256:{some value}: unauthorized: access to the requested resource is not authorized
I have a quay account but I am not sure if that is required even after my research, and if it is, where or how I would log into it. I have attempted doing so using oc login followed by various addresses within the release structure, but if this is the solution, I may be using the wrong arguments as I have not been able to find any instructions on doing this.
I have also tried the command with sudo. I doubt that is an issue but I tried it anyway.
I suppose the issue could be with my certificates, but I am not sure how to determine if this is the case.
Any guidance or suggestions would be much appreciated.
It has been determined that the OKD documentation is inaccurate at the time that I am posting this answer, and was instructing readers to pull from the OCP image repository rather than the OKD repository, which apparently requires additional credentials. A bug has been logged and the documentation will hopefully be updated soon.
The correct environment variables and full command to mirror the images are as follows:
LOCAL_REGISTRY=localhost:5000 (or your local domain name and port for the registry)
LOCAL_REPOSITORY=okd
LOCAL_SECRET_JSON=<full path to your pull secret>
OCP_RELEASE=4.5.0-0.okd-2020-10-15-235428
PRODUCT_REPO=openshift
RELEASE_NAME=okd
ARCHITECTURE=not-used-in-okd
oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
--to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE} --dry-run

Kubeflow fails to deploy using both CLI and Console

I deleted my KF cluster last night to create a new one (using kubectl cluster command not Kfctl delete), and then when I tied to create a new one, it fails, it does not work with CLI not Console. I found other people have run into this issue before, for example (here and here)
"However, as I said even with CLI my deployment fails, the error from console is:
ailed to apply: (kubeflow.error): Code 500 with message: coordinator Apply failed for gcp: (kubeflow.error): Code 500 with message: gcp apply could not update deployment manager Error could not update storage-kubeflow.yaml; Insert deployment error: googleapi: Error 403: Request had insufficient authentication scopes.
More details:
Reason: insufficientPermissions, Message: Insufficient Permission"
and the error I get from Console is:
"Please enable APIs for your project and try again
Please enable cloud resource manager API: https://console.developers.google.com/apis/api/cloudresourcemanager.googleapis.com/ and iam API: https://console.developers.google.com/apis/api/iam.googleapis.com/"
Note that this error is wrong, all the apis are active already. I'm quite sure this is a bug of KF but not sure how to find a workaround, any thoughts?
With CLI, I'm using my own account which has "owner" privileges.
Thanks
It seems you have an issue with IAM and the installation of Kubeflow, a 3rd party product that itself is not supported by us; nevertheless I went ahead and dig some information about this Machine Learning product.
The main issues (and although it seems you already cover permissions) are permissions, number of projects and some fine grained points.
I was checking and found out the following things that may help
a) Troubleshooting Kubeflow 1
b) Deploying Kubeflow in GKE[2]
c) Kubleflow auto deployer for GKE[3]
There are also some discussion about a mismatch permissions setting in Kubeflow that may be worth reading [4]
Finally there is a group that, also on a best-effort basis due the nature of Kubeflow:"google-kubeflow-support#google.com" that may come in handy.
I trust this information will be useful for you to solve your issue

proget Failed to process request. 'There was an error processing the request: Invalid API key.'

I recently setup Proget to try its nuget and chocolatey servers. Now when I try to publish packages to nuget feed through a teamcity build, I keep on getting error "proget Failed to process request. 'There was an error processing the request: Invalid API key.'.". I've made 100% sure that the name and password are working fine and specified API key as per Proget doco (i.e. username:password ) . THat feed already has one package which I published on the day I installed Proget for trying out. What could have gone wrong?
I found a work around.
[1] I confirmed that my username:password combination is correct.
[2] Then I renamed that original feed to feed_old (or whatever you
want or even delete it if it doesn't have anything important in it) I
had created for trying out and which wasn't allowing publishing
through teamcity and giving the error message as per the question's
message.
[3] Created new feed with the name I wanted.
[4] Confirmed that the username I was using in API key had necessary
privileges to publish to this new feed I just created.
[5] Then tested the publishing to this feed through teamcity and
VOILA!! it worked.
I don't know why this happened in the first place though. It would be good to find out and be able to fix underlying reason rather than using the above mentioned workaround.

Sending events to the dev version of a ruleset via HTTP

I've been writing an endpoint that sends events to a KRL ruleset via HTTP GET (based on the documentation here), in this format:
http://cs.kobj.net/blue/event/{domain}/{eventname}/{appid}
That works great when the version of the app I want to test is the same one that's deployed. I don't always want to deploy before testing it, though. Using the stated format for calling the dev version doesn't work. It still calls the deployed version of my ruleset:
http://cs.kobj.net/blue/event/{domain}/{eventname}/{appid}:kynetx_app_version=dev
What am I doing wrong?
{appid}:kynetx_app_version=dev
is a query parameter so it needs to come after a '?' or a '&'
Changing your query to the following should get it to work
http://cs.kobj.net/blue/event/{domain}/{eventname}/{appid}/?{appid}:kynetx_app_version=dev