The various runtimes are listed here:
https://cloud.google.com/dataproc-serverless/docs/concepts/versions/dataproc-serverless-versions
When submitting a batch job how do you set which runtime it executes under?
I tried looking in the documentation and searching the web, but no luck.
I think what you're looking for is the --version flag in gcloud CLI:
--version=VERSION
Optional runtime version. If not specified, a default version will be used.
If you are using API/Client Library then you can set it via version field in RuntimeConfig.
Related
Can someone share the procedure to upgrade rundeck 3.3.5 to 3.4.10
In order to over come log4j security vulnerability
The process is described here. Your instance is 3.3.5 so, you don't need to follow the database migration process, you can test in a non-prod env by launching the new instance over the old one.
Anyway, as good advice please backup all your instance data and test it in a non-prod environment before.
UPDATE 04/22/2022:
Rundeck 4.1.0 uses H2v2 as the default testing backend, please take a look at this if you're using H2 as the default backend.
I've installed a kubernetes cluster running kubeflow pipelines based on tekton on top of KIND using the following instructions
Now I'm getting the following error message from the Elyra pipelines editor. Running against an argo based kfp cluster works fine.
Is the kfp compiler somehow not supporting tekton? Can someone please shine some light on this?
HTTP response body:
{"error_message":"Error creating pipeline: Create pipeline failed:
Failed to get parameters from the pipelineRun: Invalid input error:
Unsupported argo version.
Expected: tekton.dev/v1beta1.
Received: argoproj.io/v1alpha1",
"error_details":"Error creating pipeline: Create pipeline failed:
Failed to get parameters from the pipelineRun: Invalid input error:
Unsupported argo version. Expected: tekton.dev/v1beta1.
Received: argoproj.io/v1alpha1"}
There are different aspects to consider here:
There is a need to perform a custom deployment to enable Kubeflow Pipelines to integrate/use a Tekton environment. As you mentioned the steps are described here.
As for Elyra support, Elyra recent releases starting with Elyra 2.x has incorporated support for KFP using Tekton and further documentation is available in the Elyra user guide
If you are still using Elyra 1.x or lower, the below still applies:
Now, related to compiling and executing the Kubeflow Pipeline on a Tekton environment, Elyra is currently using the KFP SDK python package and the regular compiler to compile and generate the default ARGO YAML (see code here). In order to support Tekton, we will need to use a different python package (kfp-tekton==0.3.0) and there is also a need for a different code path during compilation (see example).
Another aspect is that it seems that there are some incompatibilities between the two pipelines as described in the migration path.
Regarding support, the Elyra project would welcome contributions.
As of now the Tekton compiler is in a separate package. You can install it with pip install kfp-tekton==0.3.0 for kubeflow 1.2 . Here is the user guide
Currently, Elyra doesn't support compiling for kfp-tekton, only kfp-argo
There is an open Issue on that with the Elyra team
I'm following this tutorial here:
https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app-ios.html
I'm having some issues getting it to work, wondering if anyone has a working example.
Current issues:
Pods don't match up to the tutorial (awss3 and awsappsync require
different versions of AWSCore (2.6.6 vs 2.6.12)
When using using different pod versions (apsync 2.6.7 and awss3 2.6.6) - the code generated by api-appsync-codegen
doesn't compile - it doesn't create an S3Object class - but tries to
extend it.
Thanks for the help.
AppSync SDK release of 2.6.14 fixes this issue. Now it takes dependency on latest available version of code. You should be able to run pod install --repo-update and be able to get the latest installation.
Thanks,
Rohan
Is there any way to deploy a particular version of Kubernetes to ACS in Azure?
Using Azure resource manager, or az command.
It doesn't seem like template format for container service shows this info.
You can specify the version in ACS in selected regions. See the template example.
https://github.com/weinong/azure-quickstart-templates/tree/master/101-acs-kubernetes-with-version
We will be updating azure cli with this feature soon.
I suggest you to use acs-engine in this case. It is a tool for you to specify some custom definition like "orchestratorversion" for your case, and it can then generate an ARM template for deploying the k8s cluster.
You could download the acs-engine tool here https://github.com/Azure/acs-engine/releases (choose the version based on your need for the k8s version).
To achieve your goal, you have to provide a json file which the template you could find here https://github.com/Azure/acs-engine/blob/master/examples/kubernetes-releases/kubernetes1.7.json. You could alter the attribute "orchestratorversion" to either 1.5, 1.6 or 1.7 to suit your need. (or maybe 1.8 for the latest version)
When the json file is ready, you could turn it into the ARM template files by typing the following command
.\acs-engine.exe generate kubernetes.json
This will create a new directory called "_output" and you could find the azuredeploy.json and azuredeploy.parameters.json files there.
For more information about the attributes in the json file, take a look at https://github.com/Azure/acs-engine/blob/master/docs/clusterdefinition.md.
Another way you could also try is in the Deployment via Azure CLI specified here. https://github.com/Azure/ACS/tree/master/docs
In my deployments config directory I see two versions of MongoDB (1.8 and 2.0). However when I run
vmc services
from my client, only 1.8 shows up (presumably because it is default). I tried changing the default in mongodb_gateway.yml (and node.yml), but after a restart the list is unchanged.
Any idea how I can get Mongo 2.0 to show up as a provisionable service?
If I removed 1.8 from the mongodb_node.yml and mongodb_gateway.yml files and then restarted cloud foundry, 2.0 (and 1.8) appeared. The problem is that there's no way to differentiate the two, so it appears to use what you have set as the default version in the yml files. At any rate it shows up now.