I couldn't stomach purchasing the $150 for GCP's support service for this one question. I'm just looking to understand the schedule for Cloud Build Node.js versions. It's still stuck on Node.js v10.10 and my projects are starting to require higher versions to build. According to Cloud Build's changelog, I don't believe the Node.js version has updated in years. Any ideas?
As per the official Github repository:
Our client libraries follow the Node.js release schedule. Libraries are compatible with all current active and maintenance versions of Node.js.
So, this means it should work with Node.js 12 and the updates should be more constant. In addition to that, in here, it says that if you are using a Cloud Build config file, you can use Node.js 12, so the Node.js' latest version should be compatible with Cloud Build.
To summarize, by the repository, it should follow Node.js schedule. However, in case you think this is not occurring, I would recommend you to raise a bug on the Google's Issue Tracker - it's free, by the way - so they can assess this.
Related
I am trying to collect logs/metrics from kafka connector in GCP.
I read the documentation
It seems that ops agent only support till Apache Kafka Version 3.0.0 and I am using Kafka version 3.2.3.
May I know if there is any roadmap of version support of Kafka in ops agent?
Or any alternatives I can do for this? Please advise.
From a technical standpoint, there is no hard requirement that the version of Kafka you use is within the range documented. You're free to try using a newer version than what's documented (the Ops Agent will not forbid you from doing this), and it "might" work; it's just not officially supported or tested.
That being said, I tried running version 3.2.3 through the Ops Agent integration tests and they all passed, so there's a decent chance that 3.2.3 would work fine for you.
On the 13th of May 2021 GCP added composer-1.17.0-preview.0-airflow-2.0.1 to their composer version list.
It has already been upgraded a few times since then with "Full support end date" for each version, however it is still flagged as a Preview version.
I have already created a composer instance of composer-1.17.0-preview.7-airflow-2.0.2 and it seems to work smooth.
My question is what is the meaning of this "preview version"?
Is it production worthy? If not, what is the purpose of it?
I think it should run smoothly and is ready to run production traffic, the main thing you don't get with preview, I believe, the main difference is that this version has no full guarantees that "official" release has.
I think this is mainly about https://cloud.google.com/composer/docs/concepts/versioning/composer-versioning-overview#version-deprecation-and-support - so you might expect that you might need to migrate to newer officially supported version of Airflow sooner than those, and that some, particular things will not be fully supported during the migration.
So while you do not have all the benefits of running a managed service (which typically frees you from worrying about maintenance pretty much completely), in this case you might expect some small maintenance and migration overhead when the officially supported version is released.
However my opinion is that it should be production-ready in general and if you are considering starting your Airflow installatiom, Airlfow 2.0.2 is a good choice. At the recent Composer Airflow Summit talk the Composer team mentioned that they are going to move out of preview for Airflow 2 pretty soon. Also Airflow 2 as a product released by the community have moved a long way in Airflow 2 than it was in 1.10.
Unlike 1.10.* versions - Airflow 2 fully follows SemVer approach. This means that migration to 2.* versions should be easy and backwards compatible. Airflow community treats the "SemVer" approach and promises very seriously https://github.com/apache/airflow#semantic-versioning
So I'd say you should expect very little disruptions even if you have to migrate sooner rather than later to newer version of Airlfow in Composer.
Composer's support for Airflow 2 is now on the GA level. Please, take a look at the release notes: https://cloud.google.com/composer/docs/release-notes#September_15_2021
I installed Cloudfoundry (approximately version v220) on OpenStack and I want to work with private Docker images on Cloudfoundry.
I would like to run docker registry/repository (Doc|Github) server on Cloudfoundry.
I found tutorials on how to install it directly on a machine/VM (1|2|3).
Is there something to be said against running it on Cloudfoundry?
How do I install it?
Is Diego or something like that already providing the registry/repository service?
I thought Diego was part of Cloudfoundry but reading the CF release notes it looks like I have to install Diego separately is that correct (see "Recommended Diego Version")?
It is possible to run private Docker images on Cloudfoundry and there is a CF-specific registry you can use. In order to do that, there are a number of extra steps that you will need to undertake.
To answer your last question first, we must tease apart what exactly is meant by "Diego is a part of Cloud Foundry". Cloud Foundry is deployed using BOSH, which among other things has a concept of a release. A release is in essence a versioned collection of source code, configuration, dependencies, etc. that your system needs to run. I would recommend reading the BOSH docs to gain more of an understanding as to exactly what BOSH is.
Historically, Cloud Foundry has been made up of a single BOSH release, cf-release, but that is no longer the case. Diego itself is deployed as a separate release, diego-release, and that is what is being referred to in the cf-release release notes. To ensure compatibility, each release of cf-release publishes which release of diego-release is being run alongside.
Diego does support an internal docker registry that can run private docker images, but in order to do so, you must deploy another BOSH release and configure it correctly. That bosh release is the diego-docker-cache-release, the README should hopefully help in getting you started. This cf-dev post by the current Diego PM might also be helpful in setting it up. If you run into any problems or issues, I would recommend posting to the cf-dev mailing lists as the CF community and developers maintain a closer watch on that communication channel.
The documentation for CloudFoundry indicates that Node.js version 0.8.2 is supported. However, when I run "vmc runtimes" against my local micro edition, it only lists node and node06 (not node08)
I'm running 0.8.2 locally on my box -- how can I upgrade Micro edition so that it also has 0.8.2 installed?
Micro Cloud Foundry 1.2 was released before Node.js 0.8.2 support was added. MCF currently cannot be upgraded to support it. However, a new MCF version is planned for the very near future which will bring parity to all the feature on CloudFoundry.com. We also plan a faster release cadence of MCF so it doesn't fall behind on features.
It's not completely trivial to patch MCF 1.2 to add node 0.8, you'd need to install the relevant packages as well as add information to the Cloud Foundry manifest files to enable it to advertise the node08 runtime.
However, the next Micro Cloud Foundry release should be available pretty soon so if you can hold on just a little longer, we should have some good news for you :-)
Out of interest, what application are you looking to build / run that requires 0.8.x?
Micro Cloud Foundry has just been updated to be in sync with the codebase on github so it now supports Node.js 0.8.2. Read the announcement here: http://blog.cloudfoundry.com/2012/11/08/new-release-of-micro-cloud-foundry/
I'm looking for possibility to allow any users of certain project of Jira start (trigger) certain Hudson builds. Is it possible without creating own Jira plugin?
I would have expected this feature to be available with the Marvelution JIRA Hudson Integration, which offers functionality pretty similar to he one offered by the JIRA Bamboo Plugin (e.g. build status reporting) - surprisingly though, triggering builds as you desire seems not to be available in either one yet, despite an obvious feature indeed (the JIRA Bamboo Plugin has related/partial support at least, see Running a Bamboo Build when Releasing a Version).
Consequently you might want to file a feature request for the Marvelution JIRA Hudson Integration first rather than developing your own from scratch immediately, maybe it is going to be considered.
Please note that this plugin doesn't support JIRA 5.0 yet, but the respective version 5.0.0 is scheduled for May 24, 2012.