text:
Unable to push images in GCR - “Caller does not have permission 'storage.buckets.create'.”

I'm using Standalone Docker credential helper authentication option to push docker images in GCR from local machine. Ran following command locally which created config.json file at following path - C:\Users\sunny.goel.docker
docker-credential-gcr configure-docker
Then I issued following command to get the credential for us.gcr.io region and noticed that secret returned in output doesn't match with auth attribute value for us.gcr.io region in config.json file. Shouldn't it match ideally ?
echo "https://us.gcr.io" | docker-credential-gcr get
Moreover, where can we find the caller information to assign the required roles (storage admin) ? I do see a number of service accounts but am not sure which one is used to create storage buckets ?

Assuming you're using gcloud and not a JSON key or environment-based auth, gcloud auth list should show you the current active account.
The auth attribute value in the config file is probably leftover from doing a docker login with some credentials. You shouldn't need an auths entry for the credential helper to work, e.g. my config looks like this:
{
	"auths": {},
	"credHelpers": {
		"asia.gcr.io": "gcr",
		"eu.gcr.io": "gcr",
		"gcr.io": "gcr",
		"us.gcr.io": "gcr"
	}
}

It may be that you just need to clear that secret in the auths entry.

I hit the similar issue while i was trying to upload the docker image to GCR, i ran the following sequence of command,

Created a service account and assigned Storage Admin privileges.
Downloaded the JSON key
Executed docker-credential-gcr configure-docker
Logged with docker command - docker login -u _json_key -p "cat ./mygcrserviceaccount.JSON" https://gcr.io
Tried pushing the image gcr - docker push gcr.io/project-id/imagename:tage01

It failed with following error,
denied: Token exchange failed for project 'project-id'. Caller does not have permission 'storage.buckets.create'. To configure permissions, follow instructions at: https://cloud.google.com/container-registry/docs/access-control

I tried giving every possible permission to my service account through IAM role but it would fail with same error.
After reading this issue  i did the following changes,

Stored the JSON key into variable GOOGLE_APPLICATION_CREDENTIALS=/path/to/mygcrserviceaccount.JSON
Executed docker push command - 'docker push gcr.io/project-id/imagename:tage01'

Voila, it worked like a charm!
Thanks .


text:
0.0.6

Hello,
When i add
"com.google.gcloud" % "gcloud-java-datastore" % "0.0.6",
into my project, i got
sbt.ResolveException: unresolved dependency: joda-time#joda-time;RELEASE: not found
Here is full log:
[info] Resolving com.google.oauth-client#google-oauth-client-appengine;1.20.0 ..[info] Resolving joda-time#joda-time;RELEASE ...
[warn] 	module not found: joda-time#joda-time;RELEASE
[warn] ==== local: tried
[warn]   /Users/axxxx/.ivy2/local/joda-time/joda-time/RELEASE/ivys/ivy.xml
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/joda-time/joda-time/RELEASE/joda-time-RELEASE.pom
[info] Resolving com.google.apis#google-api-services-datastore-protobuf;v1beta2-[info] Resolving com.google.http-client#google-http-client-protobuf;1.15.0-rc ..[info] Resolving com.google.apis#google-api-services-datastore;v1beta2-rev23-1.1[info] Resolving com.github.jsimone#webapp-runner;7.0.34.1 ...
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	::          UNRESOLVED DEPENDENCIES         ::
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	:: joda-time#joda-time;RELEASE: not found
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn] 	Note: Unresolved dependencies path:
[warn] 		joda-time:joda-time:RELEASE
[warn] 		  +- com.google.gcloud:gcloud-java-core:0.0.6
[warn] 		  +- com.google.gcloud:gcloud-java-datastore:0.0.6
[warn] 		  +- usernameinuse:my-project_2.11:0.1
[trace] Stack trace suppressed: run last :update for the full output.
[error] (:update) sbt.ResolveException: unresolved dependency: joda-time#joda-time;RELEASE: not found
[error] Total time: 2 s, completed Jul 2, 2015 2:22:14 PM

Sorry, didn't notice the dependency
after adding
"joda-time" % "joda-time" % "2.8.1"
work fine

source: gharchive/issue

repo: GoogleCloudPlatform/gcloud-java

license_type: permissive

license_source: github-api


text:
Monitoring  permission issue

The example of "listresources.go" runs fine.
I try metric "logging.googleapis.com/log_entry_count" and it works fine.
Problem is that I change the metric to "pubsub.googleapi.com/subscription/***", and I got the permission error
Error 403: User  does not have permission to see metric pubsub.googleapi.com/subscription/byte_cost, forbidden
Any idea? Thx.

Find metric typo. Fixed.

repo: GoogleCloudPlatform/golang-samples


text:
Implement Policy wrapper.

Implement IAM Policy wrapper for Policy and use it as response for Get/SetIamPolicy.

This was done as part of #939.

authors: coryan paprat

repo: GoogleCloudPlatform/google-cloud-cpp


text:
Cant connect Adafruit ESP32 Huzzah

Going off the Esp32-lwmqtt sample I am trying to connect my Adafruit ESP32 Huzzah board. Previously I had it working with using a RSA256 key that I would get from an AppEngine endpoint but I want the device to be able to generate the JWT to remove the app engine endpoint call.
I used openssl to create the public/private ec.pem keys
Replaced the private_key_str with the priv value from running the command
openssl ec -in ec_private.pem -noout -text
When I run the program I print the JWT to serial and put it in jwt.io and it says the JWT has a "Invalid Signature" so naturally the mqtt library kicks back saying back username or password.
Did I miss something?
Also what is the root_cert used for? I dont see it being used anywhere in the esp32 files

Hi @tyczj I am trying to compile the lwmqtt example correctly too. But, I have this problem when I executed it.

Does you know how to solve it?
I don't have the error you have mentioned, so I don't know how to solve it.

Go lwmqtt guthun page , you can find in their error list readme

Hi @Gior80 ,
Do you refer to this link:
https://github.com/GoogleCloudPlatform/google-cloud-iot-arduino/blob/master/README.md ?

https://github.com/256dpi/lwmqtt/blob/master/include/lwmqtt.h#L243
https://github.com/256dpi/lwmqtt/blob/master/include/lwmqtt.h#L11

Back to my issue....
To rule out the known issue of

Some private keys do not correctly encode to the Base64 format that required for the device bridge. If you've tried everything else, try regenerating your device credentials and registering your device again with

I went a created new public/private ec keys and I still have the issue

Fixed my issue, I missed configuring the time before creating the JWT

authors: Gior80 jesuspisa tyczj


text:
NoSuchMethodError for com.google.cloud.bigquery.BigQueryOptions.getHttpTransportFactory

I am trying to upload to bigquery from my java app running on app-engine.
the dependecy in my pom:
<dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>google-cloud-bigquery</artifactId>
    <version>0.8.0-beta</version>
</dependency>

Here is my initial code:
import com.google.cloud.bigquery.*;

public class MyClass {
	public static myFuction() throws Exception {
		BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();
    }

when I run this locally I succed, but when running on app-engine
I am receiving a NoSuchMethodError  error:
Exception in thread "main" java.lang.NoSuchMethodError: com.google.cloud.bigquery.BigQueryOptions.getHttpTransportFactory()Lcom/google/cloud/HttpServiceOptions$HttpTransportFactory;
	at com.google.cloud.bigquery.spi.DefaultBigQueryRpc.<init>(DefaultBigQueryRpc.java:83)
	at com.google.cloud.bigquery.BigQueryOptions$DefaultBigQueryRpcFactory.create(BigQueryOptions.java:49)
	at com.google.cloud.bigquery.BigQueryOptions$DefaultBigQueryRpcFactory.create(BigQueryOptions.java:43)
	at com.google.cloud.ServiceOptions.getRpc(ServiceOptions.java:482)
	at com.google.cloud.bigquery.BigQueryImpl.<init>(BigQueryImpl.java:184)
	at com.google.cloud.bigquery.BigQueryOptions$DefaultBigqueryFactory.create(BigQueryOptions.java:39)
	at com.google.cloud.bigquery.BigQueryOptions$DefaultBigqueryFactory.create(BigQueryOptions.java:33)
	at com.google.cloud.ServiceOptions.getService(ServiceOptions.java:469)
	at com.google.cloud.ServiceOptions.service(ServiceOptions.java:463)

I also tried using just
	  <dependency>
                  <groupId>com.google.cloud</groupId>
                  <artifactId>google-cloud</artifactId>
                  <version>0.8.0</version>
        </dependency>

but it still didn't work

deleting dependencies and rebuilding the project solves the issue

repo: GoogleCloudPlatform/google-cloud-java


text:
GCS Upload failure from CRC32C mismatch

While uploading files on via google-cloud-storage 1.0.2 / java 8, infrequently there are error messages indicating that a file has failed to upload due to CRC32C mismatch (where the calculated CRC32C=AAAAAA==, see this.
Sample code we used to produces this:
void uploadToGcs (String path, byte[] content, String mimeType, String cacheControl) {
	Builder blobBuilder = BlobInfo.newBuilder(getBucketName(), path);
	blobBuilder.setCacheControl(cacheControl);
	blobBuilder.setContentType(mimeType);
	BlobInfo blob = blobBuilder.build();

	try {
		storageClient.create(blob, content);
	} catch (StorageException e) {
		LOG.error("Failed to upload: " + path);
		throw e;
	}
}

Logs:
May 31 11:56:48 Uploading File: my-folder-1/test_file_882 on thread 1, size: 408148 bytes
May 31 11:56:48 Uploading File: my-folder-2/test_file_882 on thread 2, size: 408148 bytes
May 31 11:56:53 Uploading File: my-folder-2/test_file_883 on thread 2, size: 354568 bytes
May 31 11:56:57 Uploading File: my-folder-2/test_file_884 on thread 2, size: 315652 bytes
May 31 11:57:01 Uploading File: my-folder-2/test_file_885 on thread 2, size: 394800 bytes
May 31 11:57:05 Uploading File: my-folder-2/test_file_886 on thread 2, size: 391980 bytes
May 31 11:57:09 Failed to upload: my-folder-1/test_file_882 on thread 1
May 31 11:57:09 ERROR - restarting runner: : com.google.cloud.storage.StorageException: Provided CRC32C "eThpEg==" doesn't match calculated CRC32C "AAAAAA==".|at com.google.cloud.storage.spi.v1.HttpStorageRpc.translate(HttpStorageRpc.java:189)|at com.google.cloud.storage.spi.v1.HttpStorageRpc.create(HttpStorageRpc.java:240)|at com.google.cloud.storage.StorageImpl$3.call(StorageImpl.java:151)|at com.google.cloud.storage.StorageImpl$3.call(StorageImpl.java:148)|at com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:93)|
May 31 11:57:09 Uploading File: my-folder-2/est_file_887 on thread 2, size: 322984 bytes
May 31 11:57:12 Uploading File: my-folder-2/est_file_888 on thread 2, size: 429204 bytes
May 31 11:57:13 Uploading File: my-folder-1/est_file_882 on thread 1, size: 408148 bytes
May 31 11:57:13 Uploading File: my-folder-1/est_file_883 on thread 1, size: 354568 bytes
May 31 11:57:13 Uploading File: my-folder-1/est_file_884 on thread 1, size: 315652 bytes

The uploading is done with two threads uploading files sequentially (a file is generated every 4 seconds), note that thread 2 continue to upload successfully for the duration of the error in thread 1, thus we can rule out general connectivity issue. Also note that it took a long time (21 seconds) for the error to bounce back.
Can anyone shed light to this behavior?
Thanks!

@garrettjonesgoogle Please let me know if there are anything else I can provide to help with the investigation.

I am seeing this same issue in the golang client client library cloud.google.com/go/storage . I believe this issue is cloud-side raher than sdk-side

I was not able to reproduce the problem from @josephui 's example, using random data files of similar size. This suggests to me the problem may be data-dependent.
Per @mkrufky 's https://github.com/GoogleCloudPlatform/google-cloud-java/issues/2099#issuecomment-318707288, I suggest opening an issue tagging the API on StackOverflow.

According to b/64605503 , when retrying 503 errors, sometimes 0 bytes are sent instead of the original set of bytes. Re-opening to investigate.

This comment https://github.com/GoogleCloudPlatform/google-cloud-java/issues/2099#issuecomment-318707288 implies that there is similar behavior for golang client. Seems suspicious that 2 different clients have same bug.
Also, regarding Storage retries on 503, there was a recent bug about retrying on 503 not working at all in java client library https://github.com/GoogleCloudPlatform/google-cloud-java/issues/2098.
It is worth mentioning that Java Veneer clients send requests with "Accep" header which prefers text/html content over application/json (the 503 retrying bug was caused by receiving text response instead of json from the server in case of 503 error code).

Fixed by https://github.com/GoogleCloudPlatform/google-cloud-java/pull/2359 . We will make a release for this soon.

authors: garrettjonesgoogle josephui mkrufky tcoffee-google vam-google


text:
Add an interactive release builder.

This change adds an interactive CLI to the dev/google-cloud tool to create releases.
$ dev/google-cloud rb

The tool makes use of the Github API. To avoid rate-limiting errors, set GH_OAUTH_TOKEN environment variable to a Github OAuth token.
Please take it for a test drive and let me know what you think. I'm sure that as it is used, we'll find ways to tweak it and improve its usefulness.

Another thing to consider. How does it work when you run the tool again with some new commits? Can the tool only asks for the new commits, or do you need to start over?

Right now, you'd need to start over. Is the case you mention one you've encountered already?

@jdpedrie Actually not yet, probably we can start over and that's fine.

source: gharchive/pull-request

authors: jdpedrie tmatsuo

repo: GoogleCloudPlatform/google-cloud-php


text:
Speech v1

This updates our manual client library to the Speech v1 API.
This entails several backwards incompatible changes:

The language_code parameter is no longer optional anywhere. It must be explicitly specified, and does not default to 'en-US'.
The sync_recognize method has been renamed to recognize on every class where it appears.
The async_recognize method has been renamed to long_running_recognize on every class where it appears.
The sample_rate parameter and property has been renamed to sample_rate_hertz everywhere it appears.

Additionally, the backend API contains a backwards incompatible change which does not require a code change in the client library, but will likely require one downstream: The START_OF_SPEECH, END_OF_SPEECH, and END_OF_AUDIO events have been removed.

LGTM pending CI

@gguuss Are the samples ready for this? We are ready to push it out once your documentation is updated.

I'll let y'all know when I have my change in a branch

Sample changes staged here

@lukesneeringer seems weird that the samples have to do speech_client.speech_api.x?

@jonparrott We do not. Those changes are red in the diff. :-)

@gguuss I am ready to push this to PyPI, as soon as you say you are ready.

@gguuss Poke. (This is due today, so I will push it to PyPI around noon regardless.)

I'm ready to go.

hello

authors: dhermes gguuss jonparrott lukesneeringer nandoz

repo: GoogleCloudPlatform/google-cloud-python


text:
[Proposal] Make Google::Cloud::Storage::File#copy receive storage_class as a option.

We got following error sometimes when copying a object to another bucket.
Google::Cloud::Error: uploadTooLarge: Copy spanning locations and/or storage classes could not complete within 30 seconds. Please use the Rewrite method (https://cloud.google.com/storage/docs/json_api/v1/objects/rewrite) instead.
In the source bucket storage class of objects vary.
To avoid this error, instead of using rewrite, we are planning to copy a object with destination storage class. (then eventually move storage class by lifecycle.)
However Google::Cloud::Storage::File#copy doesn't seem to able to take storage_class as an option.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/19acd3c29e15d3b76d56cd860a437da67bbccfa0/google-cloud-storage/lib/google/cloud/storage/file.rb#L481
gsutil cp has -s <class option.
https://cloud.google.com/storage/docs/gsutil/commands/cp

-s 	The storage class of the destination object(s). If not specified, the default storage class of the destination bucket is used. Not valid for copying to non-cloud destinations.

So I think we can specify storage class to copy operation. Right?
I'm willing to create a PR to this change, but I'm not sure how to...
https://cloud.google.com/storage/docs/json_api/v1/objects/copy
No mention about storage class option in REST API doc of copy.

Related: #1196

@hiroshi I investigated this, and I am nearly certain that gsutil cp does a rewrite when invoked with a storage class change. This passage in storage/docs/gsutil/commands/cp supports it:

Copies spanning locations and/or storage classes cause data to be rewritten in the cloud, which may take some time (but still will be faster than downloading and re-uploading). Such operations can be resumed with the same command if they are interrupted

Thus, copying (vs rewriting) is not a solution to your issue. The correct API method for changing storage classes is Objects.rewrite, which is resumable using rewriteToken as mentioned in the passage above, and also in the Objects.rewrite docs:

A token to use in subsequent requests to continue copying data. This token is present in the response only when there is more data to copy.

Thus, #1196 should resolve your issue. I will close this issue now, so please subscribe to #1196 for notifications.

I don't understand about Objects.rewrite yet, but what I want to do is keep storage class on copy to avoid slow transfer.
Anyway, I'll revisit the issue later.

authors: blowmage hiroshi quartzmo

repo: GoogleCloudPlatform/google-cloud-ruby


text:
Fixes to enable Docker build to work under Debian without dind

Made a couple changes to the Dockerfile and the supervisord.conf to correct these 2 issues:

The docker build was not completing successfully because curl wasn't installed and it is required, and it tried to create a "docker" user group that doesn't seem to be needed anymore.

The container was generating a bunch of error messages because it was trying to launch wrapdocker which no longer exists since the container doesn't use dind.

This is awesome, thanks @coleca. I've been building the image with the packer.json and missed that curl was missing when built with Dockerfile. Good catch on the supervisor errors. Thanks again!

authors: coleca evandbrown

license_source: bigquery


text:
Add test webapp module for quickstart

Create a /tests/test-war-quickstart that tests the quickstart facility of jetty.
The sample project should be sufficiently complex.   Perhaps either the spring petclinic, or the cdi/weld petclinic.

Since the existing spring petclinic is broken (due to Dandelion bug) we'll have to build our own spring petclinic.
We could include a known slow (to scan) jar file org.webjars:extjs:5.1.0.jar to be sure that the quickstart actually works.
I think we'll have to dig into the logs to test if this startup was truly "quick" or not.

Issue #33 is also a spring petclinic testcase (non-quickstart version)

I think this is only useful to test if the gcloud sdk offers quickstart as an option during the deploy step. Is this the case @meltsufin or @aslo ?

As quickstart support is not directly supported by the SDK, let's close this one for now.

authors: gregw janbartel joakime

repo: GoogleCloudPlatform/jetty-runtime


text:
Cannot find kubernetes-server-linux-amd64.tar.gz

$ git clone https://github.com/GoogleCloudPlatform/kubernetes/
$ cd kubernetes
$ cluster/kube-up.sh
Starting cluster using provider: gce
Project: ric-cccwiki (autodetected from gcloud config)
!!! Cannot find kubernetes-server-linux-amd64.tar.gz

Note that I have GCE set up, and everything worked well with 0.3 version.
There are no instructions on why would I need it or where do I build it.
Also, where do I find current version?
Riccardo Carlesso <ricc@>

This one bit me too.  Perhaps it's worth updating the help message in https://github.com/GoogleCloudPlatform/kubernetes/blob/bd0156c65a60df0fe87ec6f484f022320412a292/cluster/kubectl.sh#L84
./build/run.sh hack/build-cross.sh does not appear to create the needed tarballs, and make release takes quite a while ... perhaps make release-skip-tests ?
FWIW I got here with a source checkout rather than a binary distro because the distro did not include local cluster scripts that I wanted to try out.

There already is make release-skip-test.  It is aliased as make quick-release too.  See https://github.com/GoogleCloudPlatform/kubernetes/blob/master/Makefile#L101

authors: jbeda palladius pwais

repo: GoogleCloudPlatform/kubernetes


text:
Set resource limit for fluentd-elasticsearch container based on data …

…collected by #5880
@saad-ali @satnam6502

It would be nice to have a few words about why these limits were chosen.

I said above: based on https://github.com/GoogleCloudPlatform/kubernetes/issues/5880#issuecomment-113984085  :-)

Is fluentd-gcp being left off accidentally or intentionally (out of concern that its constraints are slightly different from fluentd-es)?

I would not expect the fluentd-gcp resource usage to be very different from fluentd-elasticsearch.

Neither would I

I am closing this one, and will send a new pr to address all addons resource limit soon. Thanks!


text:
Fix debian 10 test for rabbitmq

Description
The following error has popped up in integration tests, appears that new versions of rabbitmq are difficult to install on debian 10.
Running apt-get update... done.

        The repository is setup! You can now install packages.
        + sudo apt-get update
        Hit:1 https://packages.cloud.google.com/apt google-compute-engine-buster-stable InRelease
        Hit:2 https://packages.cloud.google.com/apt cloud-sdk-buster InRelease
        Hit:3 https://deb.debian.org/debian buster InRelease
        Hit:4 https://deb.debian.org/debian-security buster/updates InRelease
        Hit:6 https://deb.debian.org/debian buster-updates InRelease
        Hit:7 http://ppa.launchpad.net/rabbitmq/rabbitmq-erlang/ubuntu bionic InRelease
        Hit:8 https://deb.debian.org/debian buster-backports InRelease
        Hit:5 https://packagecloud.io/rabbitmq/rabbitmq-server/debian buster InRelease
        Reading package lists...
        + sudo apt-get install -y rabbitmq-server
        ...
        The following packages have unmet dependencies:
         rabbitmq-server : Depends: erlang-base (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    erlang-base-hipe (>= 1:26.0) but it is not going to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-crypto (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-eldap (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-inets (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-mnesia (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-os-mon (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-parsetools (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-public-key (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
        E: Unable to correct problems, you have held broken packages.
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-runtime-tools (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-ssl (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-syntax-tools (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-tools (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable
                           Depends: erlang-xmerl (>= 1:26.0) but 1:25.3.2.2-1rmq1ppa1~ubuntu18.04.1 is to be installed or
                                    esl-erlang (>= 1:26.0) but it is not installable

How has this been tested?
To be tested in kokoro. Validated that the install command works in a deb10 image.
Checklist:

Unit tests

[X] Unit tests do not apply.
[ ] Unit tests have been added/modified and passed for this PR.

Integration tests

[ ] Integration tests do not apply.
[X] Integration tests have been added/modified and passed for this PR.

Documentation

[X] This PR introduces no user visible changes.
[ ] This PR introduces user visible changes and the corresponding documentation change has been made.

Minor version bump

[X] This PR introduces no new features.
[ ] This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
[ ] This PR bumps the version.

SLES15 arm test appears to just be a network fluke completely unrelated to the PR, not re-running tests unless required.

Both of these are certainly flakes. I'm fine to merge this since it's pretty obvious in the diff that this is only for Debian-based third party apps tests and those all passed.

authors: braydonk dehaansa

repo: GoogleCloudPlatform/ops-agent


text:
feat: allow environment variable for GMP Grafana datasource-syncer

It's requested by a customer who wants to pass the Grafana API token as an environment variable when deploy the datasource-syncer on Cloud Run.
The environment variable could have the API token as plain text or get the value from the GCP's Secret Manager service.

Hi there, any chance we can get a container image built with this fix?  looks like it was merged but there are no new published containers yet.

Hey @benholtz - apologies for the delay. We should be able to publish an image within a week. I'll post here with any updates.

Hey @benholtz - the datasource-syncer should be available for use now:
docker pull gke.gcr.io/prometheus-engine/datasource-syncer:v0.14.0-gke.0

Let us know if you have any questions or issues.

Hey @benholtz - instructions have been updated, PTAL: https://cloud.google.com/stackdriver/docs/managed-prometheus/query#grafana-oauth

authors: benholtz lyanco pintohutch xiangshen-dk

repo: GoogleCloudPlatform/prometheus-engine


text:
Make setup-kcc.sh -p the default - to enable the GKE cluster public endpoint

see -p flag introduced to switch from default public to default private
https://github.com/ssc-spc-ccoe-cei/gcp-tools/pull/53
Following triage of
#534
and
#539
something off with my clean KCC env obrien.industries (will check the diffs on setup-kcc.sh) - as my older 6 week kcc.landing.systems - even with the admission errors will edit the yaml no problem
root_@cloudshell:~ (kcc-kls-cluster3)$ kubectl edit validatingwebhookconfiguration/gatekeeper-validating-webhook-configuration
Edit cancelled, no changes made.
root_@cloudshell:~ (kcc-kls-cluster3)$

Triaging connection
older server working has 35 address in .kube/config
    server: https://35.203.120.71
  name: gke_kcc-kls-cluster3_northamerica-northeast1_krmapihost-kcc-kls3

newer server has private address
    server: https://172.16.0.130
  name: gke_kcc-oi-cluster_northamerica-northeast1_krmapihost-kcc-oi

Found above issue - forgot to add -p for public endpoint
ran./setup-kcc.sh -af kcc.env
for
https://github.com/ssc-spc-ccoe-cei/gcp-tools/commit/941d542e5024144b541136e19700b50cd8eaf895

fix
michael@cloudshell:~/kcc-oi/github/gcp-tools/scripts/bootstrap (kcc-oi)$ ./setup-kcc.sh -afp kcc.env
aiting for operation [projects/kcc-oi2-cluster/locations/northamerica-northeast1/operations/operation-1695933801715-606715bd057e8-f452780e-92d1cb2e] to complete...done.
Created instance [kcc-oi2].
Fetching cluster endpoint and auth data.
kubeconfig entry generated for krmapihost-kcc-oi2.

##INFO - Config controller get credentials

Fetching cluster endpoint and auth data.
kubeconfig entry generated for krmapihost-kcc-oi2.

##WARNING - configure-kcc-access.sh script should be run once connectivity to the cluster is established using bastion host / proxy.
ichael@cloudshell:~/kcc-oi/github/gcp-tools/scripts/bootstrap (kcc-oi2-cluster)$ kubectl get nodes
NAME                                                STATUS   ROLES    AGE     VERSION
gk3-krmapihost-kcc-oi2-default-pool-6fc83c0e-ss20   Ready    <none>   9m12s   v1.27.3-gke.100
gk3-krmapihost-kcc-oi2-pool-1-28f0e374-tzw8         Ready    <none>   3m43s   v1.27.3-gke.100
gk3-krmapihost-kcc-oi2-pool-1-ae2f0850-4kmt         Ready    <none>   7m32s   v1.27.3-gke.100
gk3-krmapihost-kcc-oi2-pool-1-c9c2a582-9sdc         Ready    <none>   2m47s   v1.27.3-gke.100

fix 755
michael@cloudshell:~/_t (duet-ai-old)$ git clone https://github.com/ssc-spc-ccoe-cei/gcp-tools.git
Cloning into 'gcp-tools'...
remote: Enumerating objects: 337, done.
remote: Counting objects: 100% (192/192), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 337 (delta 88), reused 84 (delta 37), pack-reused 145
Receiving objects: 100% (337/337), 1.56 MiB | 19.76 MiB/s, done.
Resolving deltas: 100% (115/115), done.
michael@cloudshell:~/_t (duet-ai-old)$ cd gcp-tools/
devcontainer/     .git/             .github/          pipeline-samples/ scripts/
michael@cloudshell:~/_t (duet-ai-old)$ cd gcp-tools/scripts/bootstrap/
michael@cloudshell:~/_t/gcp-tools/scripts/bootstrap (duet-ai-old)$ ls
configure-kcc-access.sh  README.md  setup-kcc.sh
michael@cloudshell:~/_t/gcp-tools/scripts/bootstrap (duet-ai-old)$ ls -la
total 28
drwxr-xr-x 2 michael michael 4096 Oct  1 22:40 .
drwxr-xr-x 6 michael michael 4096 Oct  1 22:40 ..
-rw-r--r-- 1 michael michael 2043 Oct  1 22:40 configure-kcc-access.sh
-rw-r--r-- 1 michael michael  726 Oct  1 22:40 .env.sample
-rw-r--r-- 1 michael michael 2993 Oct  1 22:40 README.md
-rw-r--r-- 1 michael michael 8151 Oct  1 22:40 setup-kcc.sh
michael@cloudshell:~/_t/gcp-tools/scripts/bootstrap (duet-ai-old)$ chmod 755 setup-kcc.sh
michael@cloudshell:~/_t/gcp-tools/scripts/bootstrap (duet-ai-old)$ ls -la
total 28
drwxr-xr-x 2 michael michael 4096 Oct  1 22:40 .
drwxr-xr-x 6 michael michael 4096 Oct  1 22:40 ..
-rw-r--r-- 1 michael michael 2043 Oct  1 22:40 configure-kcc-access.sh
-rw-r--r-- 1 michael michael  726 Oct  1 22:40 .env.sample
-rw-r--r-- 1 michael michael 2993 Oct  1 22:40 README.md
-rwxr-xr-x 1 michael michael 8151 Oct  1 22:40 setup-kcc.sh


text:
Update the base branch to main

This updates the env variable for the base branch to point to main

@morganchen12 - Can you kindly take a look?

repo: GoogleCloudPlatform/repository-gardener


text:
terraformer import google doesn't work

version.tf
provider "google" {
credentials = file("key.json")
  project = "project_name"
  region  = "asia-east1"
  zone    = "asia-east1-b"
}
terraform init

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/google from the dependency lock file
- Using previously-installed hashicorp/google v4.62.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

terraformer import google --resources=firewall --connect=true --projects=project_name

terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "4.0.0"
}
}
required_version = ">= 0.13"
}
4.0.0 it works for me

I'm experiencing the same problem as well.

Used this provider 4.0.0, but it didn't work for me. Also used 5.24.0, which also not working.  Created new ticket: https://github.com/GoogleCloudPlatform/terraformer/issues/1862

repo: GoogleCloudPlatform/terraformer


text:
'002D' Unicode printed instead of hyphen '-'

Resource names keep printing 002D for '-' (assumed unicode) is there a way to avoid this? or is this API specific. Apologies if in documentation somewhere, have not found anything related

I am also seeing this.

Stale bots are pointless and do not help project quality 🙂

I just had another one closed. I wish I had time to fix it all but I don't imagine closing issues that people have encountered and raised to try and make your product better...

I started using this tool and noticed similar issue after importing aws-sg's, something like
resource "aws_security_group" "tfer--us-002D-east-002D-1-002D-example_default-002D-public_sg-002D-dh1gga2b":
BTW: are we expected to see tfer-- prefix and sg-id suffix in resource name?
Cc: @meshuga
Please suggest?

With help of my colleague found this interesting issue https://github.com/GoogleCloudPlatform/terraformer/issues/378  and this https://github.com/GoogleCloudPlatform/terraformer/pull/263, so it's by design as per the discussion in references issues and PR. So this can probably be closed for now?

You can post-process the output (trivially sed -e 's/-002D-/-/g'  but can do in python or whatever you like) but the unmodified output including escaped "-"s to 002D makes the human readability of the files questionable.
If you're purely machine processing then it doesn't much matter if it's left as-is, but with human readability of the output to assess what's there before running a restore, it creates a significant pain point for operational use.  Object names for complex naming schemes (necessary for semantic context in complex clouds, hybrid, or DC environments) easily break past a single line of output once substituted and become very hard to manually parse.
I understand the need to escape characters which aren't allowed in Terraform object names.  But escaping the dash itself was not precisely necessary (the unicode escape sequences for everything else are still distinct and unambiguous if dash isn't escaped) and postprocessing the -0026D- out is a minimal readability fix.  I think this reasonably should be a command line option to not escape the simple dash (yes for everything else).  My go fu is weak but am working on fixing that, hopefully can build a patch for that and submit it.

authors: AzySir deepak-kosaraju georgewilliamherbert whyman


text:
set the registry for image URL replacement

Previously the README always assumed gcr.io/config-management-release. With this change, the source registry is updated dynamically based on where the images were actually published.

/assign @nan-yu

repo: GoogleContainerTools/kpt-config-sync


text:
shorten timeout for some docker commands

docker image inspect: 5s
docker image pull: 5min
docker run: 5min
docker version: 5s

close #2005

@Shell32-Natsu I have looked at it. I am contemplating if we should abstract out all the docker command execution in a separate pkg first. I am also noticing that ctx is not wired all the way from top, wondering if we should do all that first and then adjust the timeouts.

I am not sure how should ctx be passed all the way from top. For every docker command we need to invoke cancel. Can these commands share a same ctx?

Have an offline discussion with @droot, it's important for us to add a short timeout for internal check like docker version and docker image inspect. But for long operation like image pull and docker run we should carefully consider the default timeout and how to expose this time to user. So in this PR I will only add time out for version and image inspect commands.

repo: GoogleContainerTools/kpt


text:
rollouts: rename RemoteRootSync to RemoteSync

Split out from https://github.com/GoogleContainerTools/kpt/pull/3850. This one will likely have merge conflicts with https://github.com/GoogleContainerTools/kpt/pull/3850, so will need a rebase.
Renames RemoteRootSync to RemoteSync. This controller will eventually support RepoSyncs in addition to RootSyncs, hence the rename.

Update the docs (getting-started-guide) specifically and verify it.

If I'm looking at the right doc, it doesn't specify anything about RemoteRootSync, so I don't think there is anything to update there.


text:
Create alignment between design and development component libraries

Description
There are inconsistencies between the design and development UI component libraries. Review and note updates needed to align.
Acceptance Criteria

[ ] Note changes in Design system google sheet: https://docs.google.com/spreadsheets/d/1B3P0pP8SWTYsNN9xtVefBJmcd0RK54kS2sh5LzLnmiw/edit#gid=1161341563
[ ] Coordinate and review with design system team to plan next steps

Will include design review per web component.

repo: GovAlta/ui-components


text:
Footer design documentation update

Background:
Footer component was recently added to the ui-component library, this has necessitated some changes to the Figma usage documentation
Acceptance criteria:

[x] Design documentations converted into "new" Figma format
[ ] Design docs reviewed by PO

Documentation and Figma component updated here for review: https://www.figma.com/file/3pb2IK8s2QUqWieH79KdN7/❖-Components-|-DDI-DS?node-id=5638%3A223852


text:
🛑 Grammle.de is down

In 9f19833, Grammle.de (https://grammle.de) was down:

HTTP code: 424
Response time: 10814 ms

Resolved: Grammle.de is back up in ed52ef1 after 4 minutes.

repo: Grammle/status

license: MIT


text:
Make the color picker functional

The color picker for the primary/secondary working colors gets drawn but does not let users select a color yet. This needs to become functional, and also the resulting color should be sent to the WASM wrapper by calling the update_primary_color and update_secondary_color functions, in order to affect the color drawn by subsequent shapes.

Assigned to @FuriouZz.

You can assign this issue to me 🙂 @Keavon

authors: FuriouZz Keavon

repo: GraphiteEditor/Graphite


text:
Convert the 24 NudgeSelectedLayers keys into a shorter loop

We have 24 very similar NudeSelectedLayers lines here in the input mapper. Similar to how we do it below with the number keys defined in a loop, we should take those 24 and use a for loop with some logic to replicate the 24 lines more cleanly.

Duplicate of #248


text:
docs: use "Graviti-example" as the user name in example code

creator
owner
committer

Task linked: CU-2gh5pa0 所有样例代码的数据集 owner 都改为 graviti 相关的

authors: GravitiRob graczhual

repo: Graviti-AI/graviti-python-sdk


text:
Graylog frontend is not displayed after proxying

The problem is that after I put graylog, elastic and mongo on the same internal docker network next to nginx to cheat dns, graylog stops displaying the frontend at the domain address. There seem to be no errors, but it seems to me that some components are not pulled from elastic. All other services in containers on which dns is assigned by analogy work fine. Proxy works out everywhere. No errors were found in the nginx log.
mongodb:
    image: mongo:3
    volumes:
      - mongo_data:/data/db
    networks:
      vpcbr:
        ipv4_address: 172.20.0.10

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.10
    volumes:
      - es_data:/usr/share/elasticsearch/data
    environment:
      - http.host=0.0.0.0
      - transport.host=localhost
      - network.host=0.0.0.0
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    networks:
      vpcbr:
        ipv4_address: 172.20.0.11

  graylog:
    image: graylog/graylog:3.3.5
    volumes:
      - graylog_data:/usr/share/graylog/data
    environment:

      - GRAYLOG_PASSWORD_SECRET=2FLGyoUpYDhkVMSo89EsSxqF84DMxSnuZgpHFTqepBti671f2H4l8RQzNRWB51HGYVeLASVDlo3jYLkDxjLvoQPjE7uWnHKh

      - GRAYLOG_ROOT_PASSWORD_SHA2=564a5fcf9ceb22a225acd62ddf728fd92f666a02348fbabb2607454659c89965
      - GRAYLOG_HTTP_EXTERNAL_URI=http://88.198.189.243:9000/
    links:
      - mongodb:mongo
      - elasticsearch
    depends_on:
      - mongodb
      - elasticsearch
    ports:
      # Graylog web interface and REST API
      - 9000:9000
      # Syslog TCP
      - 1514:1514
      # Syslog UDP
      - 1514:1514/udp
      # GELF TCP
      - 12201:12201
      # GELF UDP
      - 12201:12201/udp
    networks:
      vpcbr:
        ipv4_address: 172.20.0.12

Graylog container log:

    2020-09-22 09:15:09,337 INFO : org.graylog2.shared.initializers.PeriodicalsService - Not starting [org.graylog2.periodical.ContentPackLoaderPeriodical] periodical. Not configured to run on this node.
2020-09-22 09:15:09,337 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.GarbageCollectionWarningThread] periodical, running forever.
2020-09-22 09:15:09,345 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexerClusterCheckerThread] periodical in [0s], polling every [30s].
2020-09-22 09:15:09,348 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexRetentionThread] periodical in [0s], polling every [300s].
2020-09-22 09:15:09,348 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexRotationThread] periodical in [0s], polling every [10s].
2020-09-22 09:15:09,349 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.NodePingThread] periodical in [0s], polling every [1s].
2020-09-22 09:15:09,349 INFO : org.graylog.plugins.pipelineprocessor.periodical.LegacyDefaultStreamMigration - Legacy default stream has no connections, no migration needed.
2020-09-22 09:15:09,354 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.VersionCheckThread] periodical in [300s], polling every [1800s].
2020-09-22 09:15:09,354 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.ThrottleStateUpdaterThread] periodical in [1s], polling every [1s].
2020-09-22 09:15:09,356 INFO : org.mongodb.driver.connection - Opened connection [connectionId{localValue:4, serverValue:65}] to mongo:27017
2020-09-22 09:15:09,362 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.events.ClusterEventPeriodical] periodical in [0s], polling every [1s].
2020-09-22 09:15:09,364 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.events.ClusterEventCleanupPeriodical] periodical in [0s], polling every [86400s].
2020-09-22 09:15:09,366 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.ClusterIdGeneratorPeriodical] periodical, running forever.
2020-09-22 09:15:09,367 INFO : org.mongodb.driver.connection - Opened connection [connectionId{localValue:5, serverValue:66}] to mongo:27017
2020-09-22 09:15:09,368 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexRangesMigrationPeriodical] periodical, running forever.
2020-09-22 09:15:09,374 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexRangesCleanupPeriodical] periodical in [15s], polling every [3600s].
2020-09-22 09:15:09,379 INFO : org.graylog2.shared.initializers.PeriodicalsService - Not starting [org.graylog2.periodical.UserPermissionMigrationPeriodical] periodical. Not configured to run on this node.
2020-09-22 09:15:09,379 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.ConfigurationManagementPeriodical] periodical, running forever.
2020-09-22 09:15:09,384 INFO : org.mongodb.driver.connection - Opened connection [connectionId{localValue:6, serverValue:67}] to mongo:27017
2020-09-22 09:15:09,385 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.LdapGroupMappingMigration] periodical, running forever.
2020-09-22 09:15:09,386 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.IndexFailuresPeriodical] periodical, running forever.
2020-09-22 09:15:09,402 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.periodical.TrafficCounterCalculator] periodical in [0s], polling every [1s].
2020-09-22 09:15:09,404 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog2.indexer.fieldtypes.IndexFieldTypePollerPeriodical] periodical in [0s], polling every [3600s].
2020-09-22 09:15:09,406 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.scheduler.periodicals.ScheduleTriggerCleanUp] periodical in [120s], polling every [86400s].
2020-09-22 09:15:09,412 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.plugins.sidecar.periodical.PurgeExpiredSidecarsThread] periodical in [0s], polling every [600s].
2020-09-22 09:15:09,425 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.plugins.sidecar.periodical.PurgeExpiredConfigurationUploads] periodical in [0s], polling every [600s].
2020-09-22 09:15:09,438 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.plugins.views.search.db.SearchesCleanUpJob] periodical in [3600s], polling every [28800s].
2020-09-22 09:15:09,439 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.events.periodicals.EventNotificationStatusCleanUp] periodical in [120s], polling every [86400s].
2020-09-22 09:15:09,444 INFO : org.graylog2.periodical.Periodicals - Starting [org.graylog.plugins.collector.periodical.PurgeExpiredCollectorsThread] periodical in [0s], polling every [3600s].
2020-09-22 09:15:10,037 INFO : org.graylog2.shared.initializers.JerseyService - Enabling CORS for HTTP endpoint

Elastic container log:

    [2020-09-22T09:19:03,734][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [aggs-matrix-stats]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [analysis-common]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [ingest-common]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [ingest-geoip]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [ingest-user-agent]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [lang-expression]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [lang-mustache]
[2020-09-22T09:19:03,735][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [lang-painless]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [mapper-extras]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [parent-join]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [percolator]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [rank-eval]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [reindex]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [repository-url]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [transport-netty4]
[2020-09-22T09:19:03,736][INFO ][o.e.p.PluginsService     ] [IydRrw7] loaded module [tribe]
[2020-09-22T09:19:03,737][INFO ][o.e.p.PluginsService     ] [IydRrw7] no plugins loaded
[2020-09-22T09:19:07,264][INFO ][o.e.d.DiscoveryModule    ] [IydRrw7] using discovery type [zen] and host providers [settings]
[2020-09-22T09:19:07,738][INFO ][o.e.n.Node               ] [IydRrw7] initialized
[2020-09-22T09:19:07,739][INFO ][o.e.n.Node               ] [IydRrw7] starting ...
[2020-09-22T09:19:07,872][INFO ][o.e.t.TransportService   ] [IydRrw7] publish_address {127.0.0.1:9300}, bound_addresses {127.0.0.1:9300}
[2020-09-22T09:19:07,893][WARN ][o.e.b.BootstrapChecks    ] [IydRrw7] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2020-09-22T09:19:10,970][INFO ][o.e.c.s.MasterService    ] [IydRrw7] zen-disco-elected-as-master ([0] nodes joined), reason: new_master {IydRrw7}{IydRrw7lSBCRibR_7MIV_w}{RNANG_WEQ5CViJwdMfW7Aw}{localhost}{127.0.0.1:9300}
[2020-09-22T09:19:10,991][INFO ][o.e.c.s.ClusterApplierService] [IydRrw7] new_master {IydRrw7}{IydRrw7lSBCRibR_7MIV_w}{RNANG_WEQ5CViJwdMfW7Aw}{localhost}{127.0.0.1:9300}, reason: apply cluster state (from master [master {IydRrw7}{IydRrw7lSBCRibR_7MIV_w}{RNANG_WEQ5CViJwdMfW7Aw}{localhost}{127.0.0.1:9300} committed version [1] source [zen-disco-elected-as-master ([0] nodes joined)]])
[2020-09-22T09:19:11,027][INFO ][o.e.h.n.Netty4HttpServerTransport] [IydRrw7] publish_address {172.20.0.11:9200}, bound_addresses {0.0.0.0:9200}
[2020-09-22T09:19:11,028][INFO ][o.e.n.Node               ] [IydRrw7] started
[2020-09-22T09:19:11,189][WARN ][o.e.d.c.j.Joda           ] [IydRrw7] 'y' year should be replaced with 'u'. Use 'y' for year-of-era. Prefix your date format with '8' to use the new specifier.
[2020-09-22T09:19:11,476][INFO ][o.e.g.GatewayService     ] [IydRrw7] recovered [3] indices into cluster_state
[2020-09-22T09:19:12,164][INFO ][o.e.c.r.a.AllocationService] [IydRrw7] Cluster health status changed from [RED] to [GREEN] (reason: [shards started [[graylog_0][0]] ...]).
[2020-09-22T09:19:14,891][WARN ][o.e.d.r.a.a.i.RestGetMappingAction] [IydRrw7] [types removal] The parameter include_type_name should be explicitly specified in get mapping requests to prepare for 7.0. In 7.0 include_type_name will default to 'false', which means responses will omit the type name in mapping definitions.

 Mongo log

    2020-09-22T09:20:45.878+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2020-09-22T09:20:45.878+0000 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=7513M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2020-09-22T09:20:47.775+0000 I STORAGE  [initandlisten] WiredTiger message [1600766447:775861][1:0x7f414cb47a40], txn-recover: Main recovery loop: starting at 3/3119872
2020-09-22T09:20:47.988+0000 I STORAGE  [initandlisten] WiredTiger message [1600766447:988130][1:0x7f414cb47a40], txn-recover: Recovering log 3 through 4
2020-09-22T09:20:48.106+0000 I STORAGE  [initandlisten] WiredTiger message [1600766448:106856][1:0x7f414cb47a40], txn-recover: Recovering log 4 through 4
2020-09-22T09:20:48.197+0000 I STORAGE  [initandlisten] WiredTiger message [1600766448:197045][1:0x7f414cb47a40], txn-recover: Set global recovery timestamp: 0
2020-09-22T09:20:48.246+0000 I CONTROL  [initandlisten]
2020-09-22T09:20:48.246+0000 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-09-22T09:20:48.246+0000 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2020-09-22T09:20:48.246+0000 I CONTROL  [initandlisten]
2020-09-22T09:20:48.258+0000 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2020-09-22T09:20:48.259+0000 I NETWORK  [initandlisten] listening via socket bound to 0.0.0.0
2020-09-22T09:20:48.260+0000 I NETWORK  [initandlisten] listening via socket bound to /tmp/mongodb-27017.sock
2020-09-22T09:20:48.260+0000 I NETWORK  [initandlisten] waiting for connections on port 27017
2020-09-22T09:20:48.341+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42338 #1 (1 connection now open)
2020-09-22T09:20:48.341+0000 I NETWORK  [conn1] received client metadata from 172.20.0.12:42338 conn1: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.347+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42340 #2 (2 connections now open)
2020-09-22T09:20:48.348+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42342 #3 (3 connections now open)
2020-09-22T09:20:48.348+0000 I NETWORK  [conn2] received client metadata from 172.20.0.12:42340 conn2: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.348+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42344 #4 (4 connections now open)
2020-09-22T09:20:48.348+0000 I NETWORK  [conn3] received client metadata from 172.20.0.12:42342 conn3: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.348+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42346 #5 (5 connections now open)
2020-09-22T09:20:48.348+0000 I NETWORK  [conn4] received client metadata from 172.20.0.12:42344 conn4: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.348+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42348 #6 (6 connections now open)
2020-09-22T09:20:48.348+0000 I NETWORK  [conn5] received client metadata from 172.20.0.12:42346 conn5: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.349+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42350 #7 (7 connections now open)
2020-09-22T09:20:48.349+0000 I NETWORK  [conn6] received client metadata from 172.20.0.12:42348 conn6: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.349+0000 I NETWORK  [listener] connection accepted from 172.20.0.12:42352 #8 (8 connections now open)
2020-09-22T09:20:48.349+0000 I NETWORK  [conn7] received client metadata from 172.20.0.12:42350 conn7: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }
2020-09-22T09:20:48.349+0000 I NETWORK  [conn8] received client metadata from 172.20.0.12:42352 conn8: { driver: { name: "mongo-java-driver|legacy", version: "3.12.1" }, os: { type: "Linux", name: "Linux", architecture: "amd64", version: "4.9.0-12-amd64" }, platform: "Java/Oracle Corporation/1.8.0_265-b01" }

Graylog proxy conf:

    server {
  listen 80;
  server_name graylog.com;
  location / {
    return 301 https://$host$request_uri;
  }

  location ^~ /.well-known/acme-challenge {
    alias /var/lib/dehydrated/acme-challenges;
   # allow all;
   # default_type "text/plain";
  }
}
server {
  listen 443 ssl;
  ssl_certificate /var/lib/dehydrated/certs/graylog.whaleapp.team/fullchain.pem;
  ssl_certificate_key /var/lib/dehydrated/certs/graylog.whaleapp.team/privkey.pem;

  server_name graylog.com;

  location / {
    proxy_read_timeout 300;
    proxy_set_header        Host $host:$server_port;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_set_header        X-Graylog-Server-URL http://$server_name/api;
    proxy_pass          http://172.20.0.12:9000;
    #proxy_read_timeout  90;
    #proxy_redirect off;
    proxy_redirect      http://172.20.0.12:9000 https://graylog.com;
    proxy_http_version 1.1;
    proxy_request_buffering off;
  }
}

Fixed with proxy_set_header        X-Graylog-Server-URL https://$server_name;


text:
一直提示更新，感觉有缓存？？？

new WebUpdateNotificationPlugin({
checkInterval: 1 * 60 * 1000, // 1分钟刷新一次
logVersion: true,
checkImmediately: true,
hiddenDismissButton: true,
notifyProps: {
title: '系统更新',
description: '系统有新版本发布，请刷新界面及时更新！',
buttonText: '刷新'
},
notificationConfig: {
placement: 'topRight',
hiddenDismissButton: true
}
})
操作步骤：
1、提示升级后，点击了刷新
2、关闭窗口
3、再次打开刚才的界面
4、还是提示 升级。

估计你们的 index.html 有缓存啊，建议 spa 把缓存都禁用
location / {
  index index.html index.htm;
  if ( $uri = '/index.html' ) { # 首页不缓存
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
  try_files $uri $uri/ /index.html; # 兼容 history 路由模式，找不到的文件直接重定向到 index.html
}

页面已经加过了
如下：

页面已经加过了
如下：

会重复提示更新，说明本地的版本号（挂载在 index.html）和远程的版本号不一致。所以八成是 index.html 还有缓存。
如果 nginx 已经设置了禁用 index.html 的缓存，那看下 index.html 的响应是否有对应的响应头，我估计是 nginx 的配置没有生效

页面已经加过了
如下：

估计你们的 index.html 有缓存啊，建议 spa 把缓存都禁用
location / {
  index index.html index.htm;
  if ( $uri = '/index.html' ) { # 首页不缓存
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
  try_files $uri $uri/ /index.html; # 兼容 history 路由模式，找不到的文件直接重定向到 index.html
}

nginx加过了 ，但是这样做之后，所有界面都不缓存了。。每次刷新都不走缓存了。。

authors: GreatAuk zhangdaba

repo: GreatAuk/plugin-web-update-notification


text:
Add csv-lookup docs to if-docs

What
Add link to csv-lookup README on reference.plugins page of if-docs
Why
It's currently missing
Context
We document all our builtins on if-docs/reference/plugins, but we do not have a link to csv-lookup.
Prerequisites/resources
none
SoW (scope of work)

[ ] add link to if/builtins/csv-lookup to if-docs/reference/plugins page

Acceptance criteria

[ ] link is added

Closed by https://github.com/Green-Software-Foundation/if-docs/pull/98#pullrequestreview-2171693751

repo: Green-Software-Foundation/if


text:
Update test.py

updated unit test to test cube method

Hey @jkoors this looks great!
Only thing I'd change is how you submitted two pull requests, one for the code and one for the source. In the future, I'd submit one with both of them in the same pull request. I'll duplicate this exact comment on the other PR, so you'll hopefully see it.
Nice work!

authors: GregHilston jkoors

repo: GregHilston/github-tutorial-calculator


text:
feat: Add metrics for cache hit/miss for object store cache

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
Add two cache metrics to record cache hit/miss. #1276

Metric names:

lru_cache.hit
lru_cache.miss

Metric labels:

lru_cache.name: its value is set as "path"
lru_cache.range: its value is set as the range in the read arguments.

Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)

Add metrics to record cache hit/miss

Note: I'm not sure about these:

Which labels should we use. I assume the cardinality of "range" is limited, and it's helpful to include it as a label. Let me know if my understanding is wrong.
Naming convention about the metrics.

Checklist

[ ]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)
#1276

@nearsyh Thanks a lot for your contribution, there are some minor suggestions.

@killme2008 Just to confirm, is there anything else I need to do for this PR?

@nearsyh Thx, I'm going to merge this as all checks have passed.

@nearsyh Congrats on your first PR! Thank you.

authors: evenyag killme2008 nearsyh

repo: GreptimeTeam/greptimedb


text:
fix: executes pending ddls if region memtable is empty while scheduling next flush

I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
What's changed and what's your intention?
This PR fixes an issue: If a region schedules itself to flush again but its memtable is empty, then it will return success directly without clearing the FlushStatus and executing pending DDL requests.
So an alter request may be blocked for a long time in this situation:

the region triggers a flush
the region wants to flush again, it adds the flush task to the pending flush list
the region receives an alter request and it adds the requests to the pending DDL list
the region doesn't receive any write request
the flush job is finished and the worker schedules the same region to flush
the region checks the memtable and marks the pending flush request as success immediately because the memtable is empty, but lefts the alter request in the list

There is a debug assertion in the scheduler to detect a similar case. This PR also adds two tests to cover this case in different level.
Checklist

[ ] I have written the necessary rustdoc comments.
[ ] I have added the necessary unit tests and integration tests.
[ ] This PR requires documentation updates.

Fixes #4120


text:
fix: e2e

fix https://github.com/GreptimeTeam/gtctl/pull/195#issuecomment-1990187957

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 37.76%. Comparing base (7861241) to head (6109f6f).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #197   +/-   ##
========================================
  Coverage    37.76%   37.76%
========================================
  Files           16       16
  Lines         1300     1300
========================================
  Hits           491      491
  Misses         704      704
  Partials       105      105

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

repo: GreptimeTeam/gtctl


text:
The OPENAI API key is not properly configured.

I have no idea how to fix this, I have tried reinstalling and starting from scratch and I don't know what to do, any advice please?

me too

Read the last line. The errors say that you are not using the cookie or gpt-4

Hello,
I do have a similar issue, i tried for hours to fix this but no use
Note : i do have OpenAI membership , so i do have access to ChatGPT-4
I think i setup my API key correctly :

But i am getting the following error :

from the logs :

Any advises ?

There is no free OpenAI API usage now. You need to link a payment method in order to use OpenAI API. @SmailDH

Same error here - I have GPT4 membership.
$ export OPENAI_KEY="..."
$ pentestgpt-connection
Your CHATGPT_COOKIE is not set. Please set it in the environment variable.
#### Test connection for chatgpt cookie
The cookie is not properly configured with ChatGPT Cookie. Please follow README to update cookie through `export CHATGPT_COOKIE=<your cookie>`
#### Test connection for OpenAI api (GPT-4)
The OpenAI API key is not properly configured. Please follow README to update OpenAI API key through `export OPENAI_KEY=<>`.
The error is below: 'ChatGPTAPI' object has no attribute 'token_compression'
#### Test connection for OpenAI api (GPT-3.5)
The OpenAI API key is not properly configured. Please follow README to update OpenAI API key through `export OPENAI_KEY=<>`
The error is below: 'ChatGPTAPI' object has no attribute 'config'

::::::::::::::
chatgpt_connection_test.log
::::::::::::::
2023-07-22 14:00:32.532 | ERROR    | pentestgpt.utils.chatgpt:get_authorization:127 - Expecting value: line 1 column 1 (char 0)
2023-07-22 14:00:32.533 | ERROR    | pentestgpt.utils.chatgpt:get_authorization:128 - You encounter an error when communicating with ChatGPT. The most likely reason is that your cookie expired.
2023-07-22 14:00:32.664 | ERROR    | pentestgpt.utils.chatgpt:get_conversation_history:293 - Failed to retrieve history
2023-07-22 14:00:32.918 | ERROR    | pentestgpt.utils.APIs.chatgpt_api:_chat_completion:96 - Token size error; will retry with compressed message
2023-07-22 14:00:33.082 | ERROR    | pentestgpt.test_connection:main:87 - 'ChatGPTAPI' object has no attribute 'config'
::::::::::::::

@adrastee I'll update the documentation accordingly. Please use OpenAI API access for now. The cookie usage is depracated because OpenAI blocks the cookie access to ChatGPT.
I guess by "GPT4-membership", you mean that you have an access to ChatGPT plus; it does not provide you the access to GPT4 API. To use the tool now, you need an OpenAI API key.

I don't understand what is being said here. Apologies in advance if you already covered this, but it's just not clear.
I do NOT have a paid account, but I still have an API key from OpenAI.
I run export OPENAI_KEY='<key>' inside the venv. All good so far, but when I try pentestgpt-connection, I get this:

Just to clarify, are you saying that this API Key from OpenAI only becomes active after giving them my payment information?

@xpelican Yes the key is only active once you provide the payment methods.

Hello,
I have a paid subscription and I get the GPT-3.5 version to work, however, the GPT-4 is throwing an error something about token_compression:
The error is below: 'ChatGPTAPI' object has no attribute 'token_compression'
In the log I see this line:
2023-08-04 14:01:05.075 | ERROR    | pentestgpt.utils.APIs.chatgpt_api:_chat_completion:97 - Token size error; will retry with compressed message
What could be the issue?

Paid subscription here as well. Same errors as others have noticed.
`$ pentestgpt-connection
Your CHATGPT_COOKIE is not set. Please set it in the environment variable.
Test Connection for OpenAI api (GPT-4)

The OpenAI API key is not properly configured. Please follow README to update OpenAI API key through 'export OPENAI_KEY=<>'.
The error is below: 'ChatGPTAPI' object has no attribute 'token_compression'

Test Connection for OpenAI api (GPT-3.5)
The OpenAI API key is not properly configured. The likely reason is that you do not link a payment method to OpenAI so your key is not active. Please follow README to update OpenAI API key through 'export OPENAI_KEY=<>'
The err rot is below: 'ChatGPTAPI' object has no attribute 'config'
Test connection for chatgpt cookie
The cookie is not properly configured.`

Would these deprecated cookie functions be removed at a later version? I got a bit confused as too the warnings being spit out I thought I was missing something in the config but nvm
@GreyDGL Do you want me to open a pull request with this modification? (Cookie function removal //comment out)

I'm having this issue? i am using windows 11.
can you help me with this?

I don't understand what is being said here. Apologies in advance if you already covered this, but it's just not clear.
I do NOT have a paid account, but I still have an API key from OpenAI.
I run export OPENAI_KEY='<key>' inside the venv. All good so far, but when I try pentestgpt-connection, I get this:

Just to clarify, are you saying that this API Key from OpenAI only becomes active after giving them my payment information?

Same issue, any solution so far?

repo: GreyDGL/PentestGPT


text:
Consider adding support for picking up dropped items

Newest patch supports dropping items on the ground.

@Therzok I have no plan on updating drop clearing to drop items on the ground.

authors: GreyHak Therzok

repo: GreyHak/dsp-drone-clearing


text:
Please add support for Serialization of Fortran classes, and subroutine arguments declared intent(in).

The non-descriptive error message :
SENA-shallow-water/build/src/fortran/serialbox_pp/module_shallow_water_model.f90:341:74:

  341 |     call fs_read_field(ppser_serializer_ref, ppser_savepoint, 'b', this%b)
      |                                                                          1
Error: There is no specific subroutine for the generic 'fs_read_field' at (1)

Displays when trying to Serialize data as part of a Fortran class - class(shallow_water_model_type), intent(  in) :: this.
As well as when trying to serialize data passed as Fortran subroutine arguments declared intent(in)
SENA-shallow-water/build/src/fortran/serialbox_pp/module_shallow_water_model.f90:344:73:

  344 |     call fs_read_field(ppser_serializer_ref, ppser_savepoint, 'xps', xps)
      |                                                                         1
Error: There is no specific subroutine for the generic 'fs_read_field' at (1)

Steps to Reproduce:
clone SENA-shallow-water repository
Insert Serialbox directives into subroutines adv_nsteps_model, update_interior_model, or update_boundaries_model (within  module_shallow_water_model.f90)
Build the code following README.md or build.sh

Thanks for your report. Unfortunately, we cannot easily invest resources to fix problems appearing in codes outside of our collaborations.
However, this is an open source project and we happily take contributions to improve Serialbox (after signing the contributor agreement).
Alternatively, it might increase the changed to get a fix if you provide a minimal standalone example that reproduces the issue (stackoverflow style https://stackoverflow.com/help/minimal-reproducible-example).

authors: havogt robgonzalezpita

repo: GridTools/serialbox


text:
Fix getting $IP value

Hi, I not detailed investigate it issue, but in my setup (just redis-cluster 3.2.12 & 4.0.10) it fails on entrypoint on string echo "yes" | ruby /redis/src/redis-trib.rb create --replicas 1 ${IP}:7000 ${IP}:7001 ${IP}:7002 ${IP}:7003 ${IP}:7004 ${IP}:7005 because ${IP} was not set, so I change regexp which put value into it variable.

On what OS did you run this fix on? And on what docker version and if, what compose version?

In this case I use in without compose.
Host:
└──╼ $cat /etc/issue
Ubuntu 16.04.5 LTS \n \l
└──╼ $docker -v
Docker version 18.06.1-ce, build e68fc7a

In container:
└──╼ $docker exec -it redis-cluster bash
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@redis-cluster:/data# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.21.0.15  netmask 255.255.0.0  broadcast 172.21.255.255
        ether 02:42:ac:15:00:0f  txqueuelen 0  (Ethernet)
        RX packets 60197  bytes 5927538 (5.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49741  bytes 3632547 (3.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 5817346  bytes 8551654554 (7.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5817346  bytes 8551654554 (7.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@redis-cluster:/data# cat /etc/issue
Debian GNU/Linux 9 \n \l

After googling I find better solution and update PR

@Grokzen host running on Ubuntu 16.04, local ifconfig looks like this:
└──╼ $ifconfig
br-a625704bf8f4 Link encap:Ethernet  HWaddr 02:42:5f:c8:61:3e
          inet addr:172.23.0.1  Bcast:172.23.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:5fff:fec8:613e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:40536008 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29716578 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3331190533 (3.3 GB)  TX bytes:3175970707 (3.1 GB)

docker0   Link encap:Ethernet  HWaddr 02:42:24:c4:28:e0
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

enp3s0    Link encap:Ethernet  HWaddr f0:79:59:6c:88:e3
          inet addr:10.20.0.160  Bcast:10.20.0.255  Mask:255.255.255.0
          inet6 addr: fe80::15c3:c176:1385:fb7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8497010 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1840972 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9765246311 (9.7 GB)  TX bytes:220728957 (220.7 MB)

other virtual interfaces i skip from copy-paste.
And i'm too not able to test how it works in another setup, sry.

Yeah, i think i found the issue, i did a fresh pull of the base image and it looks like they upgraded that version to Debian 9 release that cause this error to present itself. I guess that only new people and fresh builds would see this error as people that use older incarnations of redis:3.2 base image do not have the issue.

I guess that only new people and fresh builds would see this error
You're right, without custom pull of existing image you will use locally-cached image.
In this case I may suggest fix FROM redis:3.2 to something like this FROM redis@sha256:<hash which you may see in docker inspect> to avoid unpredictable update base image.

That could work. Will look into that.

@c1rno Hardcoded the sha256 value in the Dockerfile. It should prevent this issue in the future hopefully

repo: Grokzen/docker-redis-cluster