Short verion:
-Is Midonet still on the roadmap for VPC support in Eucalyptus?
-If so what version from their non-enterprise repo should work with Euca 4.4.5 VPC? (http://builds.midonet.org/)
Long version with context:
I was trying to install Eucalyptus 4.4.5 with VPC and midonet. It appears that the enterprise midonet repos/services are not available and that Midokura isn't taking emails at sale# or info# addresses. This is broken for example: https://www.midokura.com/midonet-enterprise/
From my perspective it looks like Midokura dropped enterprise support entirely and midonet.org is the only resource available.
I took a swing at the installation with midonet 5.2 from their builds (http://builds.midonet.org/) based on the most recent Eucalyptus 4.4.5 install docs which specify enterprise version mem-5.2
Trying this I ran into tons of .rpm dependency issues installing on RHEL 7.6/7.7 and never got off the ground.
Midonet VPC support is currently planned for Eucalyptus 5.
5.2.x is the correct version, you would need these yum repositories enabled:
http://builds.midonet.org/midonet-5.2/stable/el7/
http://builds.midonet.org/misc/stable/el7/
Which use the gpg key:
http://builds.midonet.org/midorepo.key
So something like:
# midokura.repo
[midokura]
name=Midokura Enterprise MidoNet
baseurl=http://builds.midonet.org/midonet-5.2/stable/el7/
enabled=1
fastestmirror_enabled=0
gpgcheck=1
gpgkey=https://builds.midonet.org/midorepo.key
#midokura-misc.repo
[midokura-misc]
name=MEM 3rd Party Tools and Libraries
baseurl=http://builds.midonet.org/misc/stable/el7/
enabled=1
fastestmirror_enabled=0
gpgcheck=1
gpgkey=https://builds.midonet.org/midorepo.key
Related
enter image description hereI am trying to UIKitCatalog app for simulator.
Downloaded zip file from : https://github.com/appium/ios-uicatalog
Unzip the folder
Open the terminal and navigate to the UIKitCatalog folder
Build the app by command npm install
Problem: I am facing 11 vulnerabilities (2 moderate, 9 high).
What did i try to resolve : i tried npm audit fix and npm audit fix --force commands but still unable to resolve them.
Please guide me how to resolve it.
**********************************************************************************
# npm audit report
glob-parent <5.1.2
Severity: high
glob-parent before 5.1.2 vulnerable to Regular Expression Denial of Service in enclosure regex - https://github.com/advisories/GHSA-ww39-953v-wcq6
fix available via `npm audit fix --force`
Will install gulp#3.9.1, which is a breaking change
node_modules/chokidar/node_modules/glob-parent
node_modules/glob-stream/node_modules/glob-parent
chokidar 1.0.0-rc1 - 2.1.8
Depends on vulnerable versions of glob-parent
node_modules/chokidar
glob-watcher >=3.0.0
Depends on vulnerable versions of chokidar
node_modules/glob-watcher
gulp >=4.0.0
Depends on vulnerable versions of glob-watcher
Depends on vulnerable versions of vinyl-fs
node_modules/gulp
appium-gulp-plugins >=3.0.0
Depends on vulnerable versions of gulp
Depends on vulnerable versions of gulp-debug
Depends on vulnerable versions of gulp-mocha
Depends on vulnerable versions of mocha
node_modules/appium-gulp-plugins
gulp-debug >=4.0.0
Depends on vulnerable versions of gulp
node_modules/gulp-debug
gulp-mocha >=7.0.0
Depends on vulnerable versions of gulp
Depends on vulnerable versions of mocha
node_modules/gulp-mocha
glob-stream 5.3.0 - 6.1.0
Depends on vulnerable versions of glob-parent
node_modules/glob-stream
vinyl-fs >=2.4.2
Depends on vulnerable versions of glob-stream
node_modules/vinyl-fs
nanoid 3.0.0 - 3.1.30
Severity: moderate
Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2
fix available via `npm audit fix`
node_modules/nanoid
mocha 8.2.0 - 9.1.4
Depends on vulnerable versions of nanoid
node_modules/mocha
11 vulnerabilities (2 moderate, 9 high)
To address issues that do not require attention, run:
npm audit fix
To address all issues (including breaking changes), run:
npm audit fix --force
Terraform provider for Azure in Mac is problematic so i installed using the workaround mentioned here m1-terraform-provider-helper.
After reinstalling terraform as below the provider for Azurerm is still not compatable for Mac arm devices.
# Removed any existing Terraform binary (/usr/bin/terraform and/or /usr/local/bin/terraform)
# Install m1-terraform-provider-helper
brew install kreuzwerker/taps/m1-terraform-provider-helper
# Install Terraform
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
# Install the hashicorp/template version v2.2.0
m1-terraform-provider-helper install hashicorp/template -v v2.2.0
terraform init
Initializing provider plugins...
- Finding hashicorp/azurerm versions matching "2.46.0"...
╷
│ Error: Incompatible provider version
│
│ Provider registry.terraform.io/hashicorp/azurerm v2.46.0 does not have a package available for your current platform, darwin_arm64.
How do i go about fixing this? Appreciate the help.
Using the latest azurerm provider version = "=3.0.1" fixes this. Here is the config.
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "=3.0.1"
}
}
}
Snowflake is not showing in the connections dropdown.
I am using MWAA 2.0 and the providers are already in the requirements.txt
MWAA uses python 3.7 dont know if this can be a thing
Requirements.txt:
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.0.2/constraints-3.7.txt"
asn1crypto
azure-common
azure-core
azure-storage-blob
boto3
botocore
certifi
cffi
chardet
cryptography
greenlet
idna
isodate
jmespath
msrest
numpy
oauthlib
oscrypto
pandas
pyarrow
pycparser
pycryptodomex
PyJWT
pyOpenSSL
python-dateutil
pytz
requests
requests-oauthlib
s3transfer
six
urllib3
apache-airflow-providers-http
apache-airflow-providers-snowflake
#apache-airflow-providers-snowflake[slack]
#apache-airflow-providers-slack
snowflake-connector-python >=2.4.1
snowflake-sqlalchemy >=1.1.0
\
If anyone is in this trouble, instead of choosing Snowflake in the dropdown, you can choose AWS as the connection and will work fine.
It took me a while to finally figure this one out after trying many different parameter combinations.
My full Snowflake URL is:
https://xx12345.us-east-2.aws.snowflakecomputing.com
The correct format for the Host field is:
xx12345.us-east-2.snowflakecomputing.com
For the Extra field, this is what worked for me:
{
"account": "xx12345.us-east-2.aws",
"warehouse": "my_warehouse_name",
"database": "my_database_name"
}
Make sure you put Amazon Web Services for the Conn Type, like #AXI said.
Also, I have these modules defined in my requirements.txt file:
apache-airflow-providers-snowflake==1.3.0
snowflake-connector-python==2.4.5
snowflake-sqlalchemy==1.2.4
My Airflow version is 2.0.2.
According to MWAA docs, it should be enough to add apache-airflow-providers-snowflake==1.3.0 to the requirements file. When I added it to the existing MWAA env, where I had already tried many different combinations of packages, it helped partially. It was possible to create a connection using CLI, but not with UI.
But, when I created a new clean MWAA env with the requirements file as stated in mentioned AWS doc, it worked well. The connection was available in UI.
I am using Firebase latest version in my unity 2018. While build my project unity says
iOS framework addition failed due to a CocaPods installation
failure.This will will likely result in an non-functional xCode
Project.
This is my Pod file.
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '9.0'
target 'Unity-iPhone' do
pod 'Firebase/Analytics', '5.4.0'
pod 'Firebase/Auth', '5.12.0'
pod 'Firebase/Core', '5.12.0'
pod 'Firebase/Database', '5.12.0'
pod 'Firebase/Messaging', '5.9.0'
pod 'GoogleAppMeasurement', '5.3.0'
end
When i try to install pod using
pod install .
It says
[!] CocoaPods could not find compatible versions for pod
"Firebase/Auth":
In Podfile:
Firebase/Auth (= 5.12.0)
Specs satisfying the `Firebase/Auth (= 5.12.0)` dependency were
found, but they required a higher minimum deployment target.
I have update latest version of cocapods also...
But the workspace is not created..
How to solve the problem...
thanks in advance.
I have solved this issue.
1) First you have change to .net3.5 to .net 4x
2) Update dotnet4 package....(firebase messaging, Dynamic etc to dotnet4 package)
3) Go and Search Unity.Compat,Unity.Task, Unity.Compat in dotnet45 Folder. Enable With your desired package(ios,Editor,Stand alone).
4) Deselect the Unity.Compat, Unity.Task in 3.5 Version. (ios,Editor, stand alone).
By following the above method . I have solved this error.
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