I'm unable to get the secret's payload from openstack4j, it always returns null.
Secret secret = os.barbican().secrets().get("19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60");
secret.getPayload(); //Always returns null
The same works when using the OpenStack CLI,
openstack secret get --payload_content_type 'application/octet-stream' --file secret-payload http://x.x.x.x:9311/v1/secrets/19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60
I'm using the below OpenStack4j version,
Bundle-Name: OpenStack4j Core,
Bundle-Version: 3.6.0
OpenStack is in Queens version.
Let me know if someone can help on this.
Regards,
Srini
Related
I am trying to create a simple app that will output the payload after the webhook "pull_request_review_thread" is triggered with any action. Here is the link to the related webhook: Pull_request_review_thread Github Docs
However, this code:
app.on("pull_request_review_thread", async(context) =>{ app.log.info(context.payload); })
gives the error:
Argument of type '"pull_request_review_thread"' is not assignable to parameter of type 'keyof EventTypesPayload | (keyof EventTypesPayload)[]'
Am I missing something?
The problem was not having the latest version of #octokit/webhooks-types. It can be checked with the command "npm ls #octokit/webhooks-types" , current latest version is 5.8.0
I am trying to establish a SFTP connection in Airflow 1.10.14 with the SFTPOperator from airflow.providers.sftp.operators.sftp or airflow.contrib.operators.sftp_operator.
The contrib operator and the providers package are equivalent ("providers" packages are backported from Airflow 2.0 which do not make use of the contrib operators anymore), and depend on the same Python modules: paramiko, pysftp, and sshtunnel.
My pip freeze:
paramiko==2.7.2 (latest release)
pysftp==0.2.9 (latest release)
sshtunnel==0.1.5 (latest release is 0.4.0)
It works fine with a simple user/password and a private key without a passphrase but it fails when I use an encrypted key protected by a passphrase:
"ERROR - private key file is encrypted" when I set "private_key_passphrase" param alone in the connection
"ERROR - Authentication failed" when I set the "password" alone or both "password" and "private_key_passphrase".
Note that it works well in all cases with the SSHOperator (in this case, the key passphrase is set in the "password" param), thus I believe the problem is in the pysftp module.
Thanks for your help.
We moved to a new authenticated Nexus to act as a proxy to get dependencies.
I've tried to to give SBT (1.1.1) the credentials it needs, in multiple ways, but I always endup getting :
[error] Unable to find credentials for [Sonatype Nexus Repository Manager # nexus3.company.com]
[debug] CLIENT ERROR: Unauthorized url=https://nexus3.company.com/repository/maven2-proxy-all/org/scala-sbt/actions_2.12/1.1.1/actions_2.12-1.1.1.pom
It's repeated for a lot of dependencies.
I've created a .credentials file in my project as follow:
realm=Sonatype Nexus Repository Manager
host=nexus3.company.com
user=xxxxx
password=xxxxx
Here's what I've tried, based on inputs I got from other threads on the internet:
Adding the path to this credentials file in the command : -Dsbt.boot.credentials=.credentials
Adding the path to this credentials file to an environment variable : $SBT_CREDENTIALS = PATH
Adding the following line in the build.sbt : credentials += Credentials(new File(".credentials"))
Adding the following line in the build.sbt : credentials += Credentials("Sonatype Nexus Repository Manager", "nexus3.company.com", "xxxxx", "xxxxxx")
Checking what's going on with a proxy : my requests don't seem to have any authorization header and all come back as HTTP 401
And yet, when I access the URL mentioned from the same machine, with the credentials in the file, there is no issue at all.
I'm running out of ideas here :(
After more attempts, adding :
~/.sbt/1.0/credentials.sbt
credentials += Credentials("Sonatype Nexus Repository Manager", "nexus3.company.com", USER, PWD)
AND
The SBT_CREDENTIALS variable mentioned above,
Seems to do the job.
I also updated the image we use for our pipelines, not sure if it helped.
Here's a transcript so far:
$ sbt new lagom/lagom-scala.g8
[info] Loading global plugins from /Users/abrahma/.sbt/1.0/plugins
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
ssh://git#github.com/lagom/lagom-scala.g8.git: Auth fail
I've verified authentication with
GitHub:
$ ssh -T git#github.com
Hi agam! You've successfully authenticated, but GitHub does not provide shell access.
Also verified that I can access the repo in question (i.e. I can do the following, in a separate location):
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
Edit: fwiw I'm able to work around whatever the root cause is here:
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
g8 file:///Users/abrahma/tmp/lagom-scala.g8
I ran into this problem as well, and solved it by removing the following from my ~/.gitconfig:
[url "git#github.com:"]
insteadOf = https://github.com/
Are you using OpenSSH 7.8 or newer, and have you recently created your private key?
If so you might be running into the issue described in “Invalid privatekey” when using JSch aka jsch#129.
The root cause was discovered to be the ssh private key mismatch.
The question has a workaround to convert the key file to an older format if that's the error you're seeing.
You need to add your SSH key to the agent:
ssh-add ~/.ssh/id_rsa
I am trying to launch a very basic VM using Apache Brooklyn 0.8 on OpenStack ( Liberty) setup . I have mentioned the option
auto-create-floating-ip true
in the YAML but I see the following error-
java.lang.IllegalArgumentException: Floating IPs are required by
options, but the extension is not available!
Blueprint used:
location:
jclouds:openstack-nova:
endpoint: https://myurl
identity: tenant-name:username
credential: "My-password"
jclouds.openstack-nova.auto-create-floating-ips: true
name: VM
services:
- type: brooklyn.entity.basic.EmptySoftwareProcess
name: Empty software process
provisioning.properties:
imageId: RegionOne/image-id
keyPair: my-keypair-name
securityGroups: my-security-group
privateKeyFile: /path/to/my-key/in/brooklyn-machine
loginUser: ubuntu
templateOptions:
availabilityZone: nova
Any help ?
Thanks in advance .
This error normally means one of two things:
that the OpenStack endpoint you are targeting does not support the Nova floating IP extension; or
the namespace is different from a "normal" OpenStack setup, so jclouds fails to correctly retrieve the available extensions (e.g. this currently happens for OpenStack devtest).
Can your provision a VM using floating IP manually? If no, it is likely (1) above - see the cloud provider's docs, or ask the administrator which extension should be used instead.
If yes, it is likely (2) - see the jira issue JCLOUDS-1013. You can check this using the nova python client, running the commands below:
nova list-extensions | grep FloatingIps
nova --debug list-extensions 2>&1 | grep namespace
If the namespace is equals to http://docs.openstack.org/compute/ext/fake_xml, then you'll need a special jclouds "provider" for openstack-devtest, to tell jclouds to expect this alternate namespace.
Work has been done by Andrea Turli at Cloudsoft for this. The code is at https://github.com/cloudsoft/jclouds-openstack-devtest, and there is a pre-built jar at https://drive.google.com/a/cloudsoftcorp.com/file/d/0Bxv4hWMwaFRKRWtsMFdhZlZnek0/view?usp=drive_web. This code may well move into the github jclouds org over time.
Note this code is written against jclouds 1.9.2. That means you'd have to upgrade to Brooklyn 0.9.0. Or if you really want to stick to Brooklyn 0.8.0, create a fork of jclouds-openstack-devtest so you can update the pom/code to be against jclouds 1.9.1.
To use the jclouds-openstack-devtest jar, put it into $BROOKLYN_HOME/lib/patch/, restart Brooklyn, and change your location definition to jclouds:openstack-devtest-compute (instead of jclouds:openstack-nova).
jclouds-openstack-devtest jar with Brooklyn 0.10 solved the above issue