text:
[release/1.2] Prepare v1.2.13 release

depends on:

[ ] https://github.com/containerd/containerd/pull/4025 [release/1.2 backport] Fix container pid race condition
[ ] https://github.com/containerd/containerd/pull/4001 [release/1.2] bump cgroups dependency to address blkio issue
[ ] https://github.com/containerd/containerd/pull/4028 [release/1.2] backport: Set octet-stream content-type on put request
[ ] https://github.com/containerd/containerd/pull/4015 [release/1.2 backport] Pin to libseccomp 2.3.3
[ ] https://github.com/containerd/containerd/pull/4031 [release/1.2 backport] Update Golang 1.12.17

The thirteenth patch release for containerd 1.2 fixes a regression introduced
in v1.2.12 that caused container/shim to hang on single core machines, fixes an
issue with blkio, and updates the Golang runtime to 1.12.17.
Notable Updates

Fix container pid race condition containerd#4025
Update containerd/cgroups dependency to address blkio issue containerd#4001
Set octet-stream content-type on PUT request containerd#4028
Pin to libseccomp 2.3.3 to preserve compatibility with hosts that do not have libseccomp 2.4 or up installed containerd#4015
Update Golang runtime to 1.12.17, which includes a fix to the runtime contrainerd#4031

Generated release notes (incomplete, because dependent PR's haven't been merged yet);
containerd 1.2.13
Welcome to the v1.2.13 release of containerd!
The thirteenth patch release for containerd 1.2 fixes a regression introduced
in v1.2.12 that caused container/shim to hang on single core machines, fixes an
issue with blkio, and updates the Golang runtime to 1.12.17.
Notable Updates

Fix container pid race condition containerd#4025
Update containerd/cgroups dependency to address blkio issue containerd#4001
Set octet-stream content-type on PUT request containerd#4028
Pin to libseccomp 2.3.3 to preserve compatibility with hosts that do not have libseccomp 2.4 or up installed containerd#4015
Update Golang runtime to 1.12.17, which includes a fix to the runtime contrainerd#4031

Please try out the release binaries and report any issues at
https://github.com/containerd/containerd/issues.
Contributors

Sebastiaan van Stijn

Changes

9a517f681 Prepare v1.2.13 release

Dependency Changes
Previous release can be found at v1.2.12

Codecov Report

Merging #4033 into release/1.2 will increase coverage by 3.67%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release/1.2    #4033      +/-   ##
===============================================
+ Coverage        44.19%   47.87%   +3.67%
===============================================
  Files              100       91       -9
  Lines            10847     8483    -2364
===============================================
- Hits              4794     4061     -733
+ Misses            5313     3688    -1625
+ Partials           740      734       -6

Flag
Coverage Δ

#linux
47.87% <ø> (ø)
:arrow_up:

#windows
?

Impacted Files
Coverage Δ

remotes/docker/auth.go
63.82% <0%> (-3.97%)
:arrow_down:

remotes/docker/status.go
21.42% <0%> (-3.58%)
:arrow_down:

platforms/cpuinfo.go
3.77% <0%> (-0.85%)
:arrow_down:

log/context.go
36.84% <0%> (-0.66%)
:arrow_down:

namespaces/context.go
55% <0%> (-0.56%)
:arrow_down:

errdefs/grpc.go
74.6% <0%> (-0.4%)
:arrow_down:

remotes/docker/pusher.go
0% <0%> (ø)
:arrow_up:

content/local/locks.go
100% <0%> (ø)
:arrow_up:

labels/validate.go
100% <0%> (ø)
:arrow_up:

platforms/defaults.go
100% <0%> (ø)
:arrow_up:

... and 57 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35bd7a5...9a517f6. Read the comment docs.

Rebased, updated mailmap, and updated the generated release notes above https://github.com/containerd/containerd/pull/4033#issuecomment-586925285
@dmcgowan @estesp @mikebrow @fuweid @Random-Liu this should be ready for review

Found a couple really minor typos, but we might as well fix

Thanks @estesp - fixed the nits 👍
I noticed that the last part of the generated Markdown is a bit confusing:

Dependency Changes
Previous release can be found at v1.2.12

github.com/containerd/cgroups  4994991857f9 -> c4b9ac5c7601

Wondering if "previous release can be found at..." should be after the dependency change

Opened https://github.com/containerd/release-tool/pull/9 for the above

authors: codecov-io estesp thaJeztah


text:
platforms.Normalize(): do not reset OSVersion and OSFeatures

fixes https://github.com/containerd/containerd/issues/6168
Commit fb0688362cafb5c24cfe6bd4f83765a0515af374 (https://github.com/containerd/containerd/pull/1403) implemented the Normalize() function, but marked these fields as deprecated.
It's unclear what the motivation was for this (https://github.com/containerd/containerd/pull/1403#discussion_r199289449), as the fields are part of the OCI Image spec. On Windows, the OSVersion field specifically is important when matching images (as kernel versions may not be compatible).
This patch updates platforms.Normalize() to preserve the OSVersion and OSFeatures fields.
As a follow-up, we should look at defining an appropriate string-representation for these fields (possibly as part of the OCI Spec), and update platforms.Parse() accordingly.

@tonistiigi @crazy-max @kevpar ptal

Oh, arf... I just now see that https://github.com/containerd/containerd/pull/6491 is also being reviewed (but only preserves OSVersion

@thaJeztah It seems to be a bit more complicated than just preserving these values. see https://github.com/containerd/containerd/pull/6491#issuecomment-1026170393.  I pushed a commit that demonstrates those and about to push a commit that proposes a fix.

@dmcgowan do you have any idea about what is the proper change for this?

I think this part of the change "should be" correct, but the other ticket is about nerdctl (currently) not having a correct matcher for the LCOW situation.

I agree this looks correct to me, I need this patch for everything to work properly as mentioned in https://github.com/containerd/containerd/pull/6491#discussion_r797892855

source: gharchive/pull-request

authors: crosbymichael jsturtevant thaJeztah

repo: containerd/containerd

license_type: permissive

license_source: github-api


text:
Integration: Alter TestContainerPids for Windows

The point of this test is to see that we successfully can get all of the pids running in the container and they match the number expected, but for Windows this concept is a bit different. Windows containers essentially go through the usermode boot phase of the operating system, and have quite a few processes and system services running outside of the "init" process you specify. Because of this, there's not a great way to say "there should only be N processes running" like we can ensure
for Linux.
With all that said, on Windows check that we're at least greater than one ("init"+system services).

Can we not expect and test for >=N+1?

Yea we could do that. I've been thinking maybe we change the windows longCommand to 'cmd /c ping -t localhost' so there's two processes we launched, OR we launch an exec for windows in this test and just check that the two (init + exec) processes we launched exist by their IDs.

authors: dcantah sparr


text:
Check channel close when receiving events from fsnotify watcher of cni conf dir

fix #1612

@abel-von The cri repo only receives bugfix for release/1.4 or release/1.3. Could you mind to file pr to https://github.com/containerd/containerd first and then backport ? thanks!

@abel-von The cri repo only receives bugfix for release/1.4 or release/1.3. Could you mind to file pr to https://github.com/containerd/containerd first and then backport ? thanks!

https://github.com/containerd/containerd/pull/4825
if the PR is accepted, shall I summit the PR to release/1.4 or release 1.3 here?

@abel-von The cri repo only receives bugfix for release/1.4 or release/1.3. Could you mind to file pr to https://github.com/containerd/containerd first and then backport ? thanks!

containerd/containerd#4825
if the PR is accepted, shall I summit the PR to release/1.4 or release 1.3 here?

Yes! Thanks!

authors: abel-von fuweid

repo: containerd/cri


text:
Fix Windows Path Handling in LogURIGenerator()

Issue:
On Windows, the LogURIGenerator() function in containerd/containerd fails when it checks if the logURI path is absolute. This is due to the leading slash in the parsed logURI, which causes the check to fail and results in an error, ultimately leading to the command's failure.
The logURI parameter is a binary path formatted as a URI, for example:
"binary:///C:/Program Files/nerdctl.exe?_NERDCTL_INTERNAL_LOGGING=C%3A%5CProgramData%5Cnerdctl%5C052055e3"

When parsed with url.Parse(logURI), the resulting u.Path is:
"/C:/Program Files/nerdctl.exe"

The leading slash is incorrect for Windows paths and causes issues when the path is later checked for being absolute.
To resolve this issue, the leading slash must be removed from the u.Path before the absolute path check is performed. This ensures the path is correctly recognized as an absolute path on Windows systems.

Waiting for the changes from Set stderr to empty string when using terminal on Windows to be available in the latest Containerd v2 release.

Hey @TinaMor
2.0.0 rc4 just dropped and we moved nerdctl (and testing env) to it.
Curious if the change in containerd got in?

authors: TinaMor apostasie

repo: containerd/nerdctl


text:
Add mario and nicola as owners

you are both now in the OWNERS and REVIEWERS.

/lgtm

i will manually merge this as it is not code based once tests pass

authors: baude inknos

repo: containers/libhvee


text:
Improve cmd/podman/shared/container.go documentation

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Documentation inside cmd/podman/shared/container.go can be improved:

All periods should end with ..
Some syntax error can be fixed, e.g.: // PBatch is performs batch operations on a container in parallel
Documentation should follow Go reccomendations, .e.g. when documenting an element, the comment should being begins with the name of the element it describes.

@marcov Have you seen any improvements on this?  @TomSweeneyRedHat What do you think?

I think I just assigned it to myself so I won't forget it.  @marcov I'd be happy to hear what you think none the less.

@TomSweeneyRedHat thank you for taking care. I intentionally left the assignee open :wink:

I think the PR from @EmilienM cleaned this up.  I see two additional issues; one spelling error and one missing period at the end of a comment.  When i  look at this file all exported functions are documented which is the golang standard.  Unless we want to hold this issue open for the two nits, I consider this complete and ready for close.

Given the current state, I'm ok to close this

source: gharchive/issue

authors: TomSweeneyRedHat baude marcov rhatdan

repo: containers/libpod


text:
rootless: not require userns for help/info/version

these commands do not require to be root in an userns
Closes: https://github.com/containers/libpod/issues/1263
Signed-off-by: Giuseppe Scrivano gscrivan@redhat.com

podman help and podman version work but podman info gives me the following error:
could not get runtime: chown /home/vrothberg/.local/share/containers/storage/vfs: operation not permitted

@giuseppe Can we add integration tests for those three cases? Just to avoid any potential regressions.

@giuseppe podman info isn't working with the latest commit.

done, I've updated the PR title

@rh-atomic-bot r+

authors: giuseppe vrothberg


text:
Varlink proxy

One direct call without proxy
$ varlink  -A '/home/harald/podman --log-level debug varlink --timeout 1 \$VARLINK_ADDRESS' call io.podman.GetVersion
INFO[0000] running as rootless
DEBU[0000] Initializing boltdb state at /home/harald/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /home/harald/.local/share/containers/storage
DEBU[0000] Using run root /run/user/1000
DEBU[0000] Using static dir /home/harald/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/harald/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Not configuring container store
{
  "built": "2019-03-01T16:20:39+01:00",
  "git_commit": "bb45d844143b20c937e6eb742df06dc008911b5b",
  "go_version": "go1.11.5",
  "os_arch": "linux/amd64",
  "remote_api_version": 1,
  "version": "1.2.0-dev"
}

And one with reexec and proxy:
$ varlink  -A '/home/harald/podman --log-level debug varlink --timeout 1 \$VARLINK_ADDRESS' call io.podman.GetInfo
INFO[0000] running as rootless
DEBU[0000] Initializing boltdb state at /home/harald/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /home/harald/.local/share/containers/storage
DEBU[0000] Using run root /run/user/1000
DEBU[0000] Using static dir /home/harald/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/harald/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Not configuring container store
INFO[0000] running as rootless
WARN[0000] The configuration is using `runtime_path`, which is deprecated and will be removed in future.  Please use `runtimes` and `runtime`
WARN[0000] If you are using both `runtime_path` and `runtime`, the configuration from `runtime_path` is used
DEBU[0000] Initializing boltdb state at /home/harald/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /home/harald/.local/share/containers/storage
DEBU[0000] Using run root /run/user/1000
DEBU[0000] Using static dir /home/harald/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/harald/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay: mount_program=/usr/bin/fuse-overlayfs
DEBU[0000] backingFs=xfs, projectQuotaSupported=false, useNativeDiff=false, usingMetacopy=false
{
  "info": {
    "host": {
      "arch": "amd64",
      "buildah_version": "1.7.1",
      "cpus": 2,
      "distribution": {
        "distribution": "fedora",
        "version": "29"
      },
      "hostname": "localhost.localdomain",
      "kernel": "4.18.16-300.fc29.x86_64",
      "mem_free": 1174843392,
      "mem_total": 2088931328,
      "os": "linux",
      "swap_free": 2147479552,
      "swap_total": 0,
      "uptime": "1h 47m 11.26s (Approximately 0.04 days)"
    },
    "insecure_registries": [],
    "podman": {
      "compiler": "gc",
      "git_commit": "bb45d844143b20c937e6eb742df06dc008911b5b",
      "go_version": "go1.11.5",
      "podman_version": "1.2.0-dev"
    },
    "registries": [
      "docker.io",
      "registry.fedoraproject.org",
      "quay.io",
      "registry.access.redhat.com",
      "registry.centos.org"
    ],
    "store": {
      "containers": 0,
      "graph_driver_name": "overlay",
      "graph_driver_options": "overlay.mount_program=/usr/bin/fuse-overlayfs",
      "graph_root": "/home/harald/.local/share/containers/storage",
      "graph_status": {
        "backing_filesystem": "xfs",
        "native_overlay_diff": "false",
        "supports_d_type": "true"
      },
      "images": 0,
      "run_root": "/run/user/1000"
    }
  }
}
INFO[0000] varlink service expired (use --timeout to increase session time beyond 1 ms, 0 means never timeout)

Gofmt errors - make gofmt should fix

@baude PTAL

/ok-to-test

Not  ready to be merged, but request for comments.

@haraldh Any update on this?

@haraldh Are you still working on this?

@rhatdan currently not... waiting for feedback
@baude ?

LGTM .. need @giuseppe to review the rootless bits.

could we take the rootless bits to another PR/delay them for now?
I am working on a huge refactoring for rootless where we will use only one namespace for the storage, and varlink should work out of the box without any extra handling for rootless (except fixing the paths for the unprivileged user).

authors: baude giuseppe haraldh mheon rhatdan


text:
Add links to readthedocs on docs/readme

Add a couple of links to the new ReadTheDocs site
for the libpod man pages from the docs/readme.md.  Many users
go to github.com/{project}/docs looking for the man pages for
the project and their location is not evident on the current
readme.md.
Signed-off-by: TomSweeneyRedHat tsweeney@redhat.com

/test images

LGTM

@mheon @baude @giuseppe @vrothberg @QiWang19 @jwhonce PTAL

/lgtm

authors: TomSweeneyRedHat jwhonce rhatdan


text:
adding security options fields to container create dialog

Adding security options fields to container create dialog.

Signed-off-by: Navid Yaghoobi n.yaghoobi.s@gmail.com

LGTM

authors: navidys rhatdan

repo: containers/podman-tui


text:
ModuleNotFoundError: No module named 'pbr'

Traceback while importing podman
Python 3.7.4 (default, Jul  9 2019, 16:32:37)
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import podman
Traceback (most recent call last):
File "", line 1, in
File "/home/vikasmulaje/contribution/podman/python-podman/podman/init.py", line 8, in
from pbr.version import VersionInfo
ModuleNotFoundError: No module named 'pbr'

Hello,
Thanks for these changes.
How did you install podman before launching your repl?
Normally we don't need pbr in requirements since pbr is already installed by using setup_requires (cf. https://github.com/containers/python-podman/blob/master/setup.py#L6).
Your changes are not earthquake so we can consider merge them anyway but I'm surprising by your error and it can be interesting to see how you install podman.

Please reword your commit message with something like:
[fix] add pbr to requirements

Avoid issues when using podman from path in <your situation and your context and how you install podman>

Thanks

Hi,
I followed these steps to install podman:

git clone https://github.com/containers/python-podman.git
cd ~/python-podman
python3 setup.py clean -a && python3 setup.py sdist bdist
python3 setup.py install --user
pip3 install -r requirements.txt

After this when I try to import podman
Got above trackback

LGTM

authors: 4383 jwhonce vikasmulaje

repo: containers/python-podman


text:
Add runtime flag so we can alternatively serve via vllm

Also added 'ls' alias for 'list'. Port logic is buggy, just support --port for now. Pass 'args' to pull function, instead of "args.store".

I think we make a breaking change here, "vllm serve" only serves .gguf file correctly with .gguf extension, so we might be better off storing files like:
~/.local/share/ramalama/models/ollama/granite-code:latest
like this instead:
~/.local/share/ramalama/models/ollama/granite-code:latest.gguf

Can we play games with symbolic links?  I am not that concerned about breaking changes at this point, since we have not released anything yet.

Above are symlinks, so the cleanest way is to make a breaking change and change this symlink:
~/.local/share/ramalama/models/ollama/granite-code:latest
to this one:
~/.local/share/ramalama/models/ollama/granite-code:latest.gguf
Also logged a bug with vllm:
https://github.com/vllm-project/vllm/issues/7993
It's supposed to be possible to do this without the extension by using flags like "--quantization gguf --load-format gguf" but it doesn't work. GGUF inference is like 3 weeks old in vllm, they were using other formats before.

ramalama would solve this problem for many:
https://github.com/vllm-project/vllm/issues/1441
This is one of the most commented issues in vllm... vllm focuses more on enterprise grade GPUs, so it frustrates people they don't support Apple Devices...
Whereas with ramalama, one could test locally via:
ramalama --runtime llama.cpp serve, etc.
and if they want to use vllm on a deployment server, they could do:
ramalama --runtime vllm serve, etc.
potentially....

Some of these things are bug fixes I'm gonna split those out into another PR

Excited for this! https://github.com/ollama/ollama/issues/3953
There was some interest in that issue in the feature so we should make sure to highlight it as a feature.

vllm support will probably be completed, once there is a new release of vllm, to get some PRs like:
https://github.com/vllm-project/vllm/pull/8056
vllm release pretty frequently though, so it shouldn't be too far away...

I think we may need to make a breaking change here, "vllm serve" only serves .gguf file correctly with .gguf extension, so we might be better off storing files like:
~/.local/share/ramalama/models/ollama/granite-code:latest
like this instead:
~/.local/share/ramalama/models/ollama/granite-code:latest.gguf

I'm not sure how feasible it is for this project, but a FuSE filesystem for dynamically managing models instead of symlinks could be an option

I think we may need to make a breaking change here, "vllm serve" only serves .gguf file correctly with .gguf extension, so we might be better off storing files like:
~/.local/share/ramalama/models/ollama/granite-code:latest
like this instead:
~/.local/share/ramalama/models/ollama/granite-code:latest.gguf

I'm not sure how feasible it is for this project, but a FuSE filesystem for dynamically managing models instead of symlinks could be an option

Not sure we wanna go here right now. For one, we support macOS native. This problem in particular will go away in the next version of vllm when the above PR gets merged.
But... I'd still be interested in hearing a more detailed example/explanation of why FuSE filesystem would help us here...
Although it would be preferably to have a fs-agnostic solution if at all possible...

This is very basic support for the --nocontainer case, but may unblock other efforts like:
#150

LGTM

@kannon92 basic support for this was merged

@ericcurtin from an ilab side of things I have been trying to see if we can get operations like generate on a mac using vllm. Could this help with that? it seems like the discourse here is saying that vllm works on the mac using ramalama?

What this PR enables is the option to do:
$ ramalama --runtime vllm serve some-model

or
$ ramalama --runtime llama.cpp serve some-model

llama.cpp and vllm have different primary design goals. llama.cpp was written primarily with commodity grade systems in mind like a macbook, mac mini, etc. vllm was written with almost the opposite priority, to run on huge enterprise-grade systems with lots of vram and powerful gpus.
So with this change, one could test on macOS with llama.cpp as a runtime but deploy to some enterprise server with vllm as a runtime.

authors: cdoern ericcurtin kannon92 matbee-eth rhatdan

repo: containers/ramalama

license: MIT


text:
Prepare Release v1.3.1

🚢

In the future when fixing a release, please document what was wrong with the previous one 🙏 Since the v1.3.1's changelog is just Prepare release, it's really not clear at the moment

authors: Ullaakut kevinpollet

repo: containous/maesh


text:
Unable to use X-Forwarded-Proto header in sslProxyHeaders setting

Do you want to request a feature or report a bug?

Bug

What did you do?

Similar to https://github.com/containous/traefik/issues/1924, we would like to use a Google Cloud HTTP load balancer that handles SSL termination and forwards traffic to Traeffik using the HTTP protocol. In order to issue HTTPS redirects for plain HTTP requests, we need to setup SSL redirection based on the X-Forwarded-Proto header that will be set to http or https respectively.
What did you expect to see?
Requests that include the X-Forwarded-Proto: https header should not get redirected.
What did you see instead?
When using the X-Forwarded-Proto header, all requests got redirected regardless of the value. This is not the case when using a different header name such as X-Test.
Using the docker-compose environment below, here's a simple test case (remember to uncomment the other container label while testing the X-Test header):
$ docker-compose up

$ curl -i -H "Host: whoami.localhost" -H "X-Forwarded-Proto: http" localhost:3000
HTTP/1.1 301 Moved Permanently (CORRECT)

$ curl -i -H "Host: whoami.localhost" -H "X-Forwarded-Proto: https" localhost:3000
HTTP/1.1 301 Moved Permanently (WRONG - EXPECTED 200)

$ curl -i -H "Host: whoami.localhost" -H "X-Test: http" localhost:3000
HTTP/1.1 301 Moved Permanently (CORRECT)

$ curl -i -H "Host: whoami.localhost" -H "X-Test: https" localhost:3000
HTTP/1.1 200 OK (CORRECT)

I am pretty sure it has something to do with the changes made in https://github.com/containous/traefik/pull/5836.
Output of traefik version: (What version of Traefik are you using?)

2.2.11

What is your environment & configuration (arguments, toml, provider, platform, ...)?
version: "3.4"

services:
  traefik:
    image: traefik:2.2.11
    container_name: traefik
    command:
      - --api
      - --api.insecure=true
      - --log.level=DEBUG
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entryPoints.http.address=:3000
    ports:
      - 3000:3000 # LB
      - 8080:8080 # dashboard
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: containous/whoami
    container_name: simple-service
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.localhost`)"
      - "traefik.http.routers.whoami.entrypoints=http"
      - "traefik.http.middlewares.https-redirect.headers.sslredirect=true"
      - "traefik.http.middlewares.https-redirect.headers.sslproxyheaders.X-Forwarded-Proto=https"
      # - "traefik.http.middlewares.https-redirect.headers.sslproxyheaders.X-Test=https"
      - "traefik.http.routers.whoami.middlewares=https-redirect"

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
(paste your output here)

Duplicate of #6790, #4273, #7003
Fixed by #7230

Why was this closed? I just tried again using Traeffik 2.2.11 and the issue remains. Please consider testing my setup.

The sslredirect option is not  recommended to create a redirection.
Please the use the redirectscheme middleware instead.
https://docs.traefik.io/v2.2/middlewares/redirectscheme/

That works nicely when using two separate endpoints but won't work if SSL is terminated at the cluster LB level. You even highlighted the introduction of the sslRedirect option with v1.5 for exactly this usage case, in combination with the sslProxyHeaders option (v1.6). Both options work great, except when using the X-Forwarded-Proto header. Why can't that be implemented as well?

I think that you are looking for this option https://docs.traefik.io/v2.2/routing/entrypoints/#forwarded-headers
FYI sslRedirect only do a redirect on port 443 https://github.com/unrolled/secure/blob/368ad3ae8f053cb99f4fd4c73987d191672082b3/secure.go#L331

I think that you are looking for this option https://docs.traefik.io/v2.2/routing/entrypoints/#forwarded-headers

That made it work indeed, thanks! Maybe the documentation can be updated to showcase which headers don't get trusted by default?

authors: ldez niksauer

repo: containous/traefik


text:
Link some provider logs to Traefik

Description

DynamoDB: provide Traefik logger the client
ECS: provide Traefik logger the client

Design LGTM.
May be refactored du to https://github.com/containous/traefik/pull/1746#issuecomment-312886904

Close because I'm merge this PR with #1746

authors: emilevauge ldez


text:
Add documentation for Træfik on docker swarm mode

Still a little bit work in progress, I need to add output of commands 👼.
Also small update on the swarm one.
/cc @containous/traefik
🐸
Signed-off-by: Vincent Demeester vincent@sbr.pm

Hi, I've tested this docs with the 1.1.0-rc1 and it is not correct.
In you examples you are missing the needed labels to let traefik check the services. I've tried this instead with success:
docker network create traefik-net --driver overlay

docker service create \
  --name traefik \
  --constraint=node.role==manager \
  --publish 80:80 --publish 8080:8080 \
  --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
  --network traefik-net \
  traefik:camembert \
  --docker \
  --docker.swarmmode \
  --docker.domain=docker.localhost \
  --docker.watch \
  --logLevel=DEBUG \
  --web

docker service create \
    --name whoami0 \
    --network traefik-net \
    --label "traefik.backend=whoami" \
    --label "traefik.frontend.rule=Host:whoami.docker.localhost" \
    --label "traefik.port=80" \
    emilevauge/whoami

docker service create \
    --name whoami1 \
    --network traefik-net \
    --label "traefik.backend=whoami" \
    --label "traefik.frontend.rule=Host:whoami.docker.localhost" \
    --label "traefik.port=80" \
    emilevauge/whoami

$ curl -H Host:whoami.docker.localhost http://localhost
Hostname: 640be50494d2
IP: 127.0.0.1
IP: ::1
IP: 10.0.6.7
IP: 10.0.6.6
IP: fe80::42:aff:fe00:607
IP: 172.21.0.4
IP: fe80::42:acff:fe15:4
GET / HTTP/1.1
Host: whoami.docker.localhost
User-Agent: curl/7.43.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 10.255.0.4
X-Forwarded-Host: whoami.docker.localhost
X-Forwarded-Proto: http
X-Forwarded-Server: 57dd126575c5

 $ curl -H Host:whoami.docker.localhost http://localhost
Hostname: c5c321cac154
IP: 127.0.0.1
IP: ::1
IP: 10.0.6.5
IP: 10.0.6.4
IP: fe80::42:aff:fe00:605
IP: 172.21.0.3
IP: fe80::42:acff:fe15:3
GET / HTTP/1.1
Host: whoami.docker.localhost
User-Agent: curl/7.43.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 10.255.0.4
X-Forwarded-Host: whoami.docker.localhost
X-Forwarded-Proto: http
X-Forwarded-Server: 57dd126575c5

It would be nice to have 2 separate networks for the whoami backends.
I wilk probably add an example with traefik, docker-compose bundle, docker service deploy where separate networks are even more important

@ralphtheninja thanks :angel:
@bvis Yes, I forgot --label "traefik.port=80" in my example, thanks :angel:. I can make an example of what you describe but that's not what I was going for here. I'm using the same image twice because I'm lazy :joy: but I really want 2 different service served by Træfik as they were different app.
@weitzj I definitely went for the simplest example ever here :sweat_smile:. We could enhance the documentation with multiple network (one for each app served) and a way to update the traefik service to connect to those as needed (but doesn't look like there is a docker service update --add-network yet though :sweat:).

Needs a rebase :)

Unless I am mistaken there is a slight error with how the placement contraint is declared, the official syntax is --constraint string not --constraint=string

https://docs.docker.com/engine/reference/commandline/service_create/#/specify-service-constraints---constraint

@tlvenn both should work the same 👼

Ya I didnt check but figured it would however I believe it would be a little bit better to stick with the official syntax, especially given that's the one you are already using for the other options ;)
Anyway, I am nitpicking, thanks in any case, for putting the doc together.

:stuck_out_tongue_closed_eyes:

One new question, did you investigate the --endpoint-mode option ? By default docker will use and create a virtual ip to load balance itself the service. One can use --endpoint-mode dnsrr to disable VIP and rely on simple dns round robin. Their documentation seems to suggest to use this when using your own load balancer, which is what we are doing.

You can configure the service to use DNS round-robin directly without using a VIP, by setting the --endpoint-mode dnsrr when you create the service. DNS round-robin is useful in cases where you want to use your own load balancer.

Should we update the doc to reflect that ?

Should we update the doc to reflect that ?

Make a PR and lets discuss that instead ;)

Well there is no point to create a PR if we dont even agree it should be amended...
The doc works perfectly fine as it is, it just create an un necessary IP for the service being load balanced by Traefik.
In the end, there are 3 choices:

Keep it simple and dont mention --endpoint-mode dnsrr
Amend the doc to use --endpoint-mode dnsrr and explain it.
Amend the doc to mention --endpoint-mode dnsrr as an option to avoid creating the VIP.

In case we choose 2 or 3, I am happy to create the PR.

One last comment, for security purpose, the docker socket should really be mounted in read only mode so that in the unlikely event the container is compromised, it does not mean the whole cluster has been taken over...

authors: bvis emilevauge ralphtheninja tlvenn vdemeester weitzj


text:
[FlexFields] Fields disabled for editing are being shown

Describe the bug
Fields disabled for editing are still shown in FlexFields editor page
To Reproduce
Steps to reproduce the behavior:

Create a content model with a hidden field (Disabled Editing field)

Disabled Editing field is being shown on FlexFields editor page

Disabled field is not shown on default editor page

Expected behavior

Disabled field should be hidden on FlexFields editor page by default
The hidden field should reappear when writer toggle hidden fields

Additional context
I did an exploration of contentful SDK API and found that we are able to get the disabled state from SDK Field API Reference

sdk.field.getIsDisabled()
sdk.field.onIsDisabledChanged(callback)

Not sure if this would be helpful in designing a solution

Thank you raising this and giving the additional context. We will look into this and get back to you once fixed.

@lilbitner would you be able to help with the PR raised to fix this issue (https://github.com/contentful/marketplace-partner-apps/pull/949)

@JinHao-L I merged in @vipulchadda's fix and it is now deployed to production. Can you please verify that this issue is now resolved? Thank you!

@whitelisab @vipulchadda
Hi, I have verified that the fix works great! Thanks alot for the prompt fix 👍
Will close this issue

authors: JinHao-L vipulchadda whitelisab

repo: contentful/marketplace-partner-apps


text:
@contentstack/utils brings a lot of dependencies that I would expect to be devDependencies

I am looking at two similar lambda functions - one with a deployment package of 500Kb and another of 12Mb. The difference is in how many node_modules each of them bring and specifically how many different babel-* modules one needs. I looked into it and all babel-* dependencies are coming from contenstack -> @contenstack/utils. So the difference between the two lambda functions is really in one using contenstack and one not.
Would you please double check that you indeed need to bring the whole babel ecosystem into the fold with @contentstack\utils?
This lambda used to run over contenstack HTTP API and in those days it weighted half of what it weighs now having migrated to the SDK.

Thanks for raising the issue @pveller, we will check this at our end and we will inform you our findings.

Hi @pveller,
We have updated the @contentstack/utils package dependency and move babel-* from the dependency to dev-dependency. New version v3.13.2 for contentstack is published.
Can you please check if you are still facing the issue?

Hi @pveller,
We are closing this issue for now. If you have any concern or issue you can re-open or create new issue on Contentstack JS repository.

authors: pveller uttamukkoji

repo: contentstack/contentstack-javascript


text:
Support Jetbrains IDE EAP versions e.g. v2023.3

Validations

[x] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[x] I'm not able to find an open issue that requests the same enhancement

Problem
Can't use plugin if using EAP version
Solution
May just work by bumping Compatibility Range to include v2023.3 https://plugins.jetbrains.com/plugin/22707-continue/versions

@ciarancourtney Just updated our plugin.xml, and submitted a new version to the store. I'll let you know once they accept it! Should be by tomorrow morning

@ciarancourtney They did accept the version referenced above, but just to keep you updated I felt that things were a bit buggy and not up to speed with VS Code, so took some time to make a few big reliability changes. New version will probably be out Monday, but I'll let you know!

Any updates here?

@ciarancourtney Yes, sorry we did end up releasing a new version (0.20). The versions accepted in plugin.xml are <idea-version since-build="223.0" until-build="233.*"/>.

@ciarancourtney Finally got around to submitting a new version (will likely be ready in the store tomorrow morning) and found the second place that I had missed to update compatibility. This one should be 223+ (so unbounded on the "until" end of the range)

@ciarancourtney closing this issue as it appears to have been resolved. Let me know if you're still seeing any other problems!

authors: ciarancourtney sestinj

repo: continuedev/continue


text:
increase gemini 1.5 pro contextLength

Description
Gemini 1.5 Pro increased context window to 2M tokens: https://developers.googleblog.com/en/new-features-for-the-gemini-api-and-google-ai-studio/
Checklist

[x] The base branch of this PR is dev, rather than main
[x] The relevant docs, if any, have been updated or created

nice

authors: pzaback sestinj


text:
Switch policies/AEP config not supported in Contiv

Maybe a known issue. Filing it to document.
While deploying contiv, realized that the phys-dom association to attached entity profile has to be done manually . I had to create the following on APIC GUI before we could deploy the policies:

Switch profile/Interface Profile/Policy groups.
Attached entity profile.
Phys dom association with attached entity profile.

Yes @santosh76 . You need to configure those things on APIC side in order to make this Contiv-ACI integration work. We are in the process of providing documentation for this one.

@santosh76 - as @gaurav-dalvi mentioned, this is working as designed. Contiv is not expected to take over the physical network configuration; rather work with creating tenants/epgs/app-profile/contracts for container workloads. The goal was to not create 1:1 wrapper on top of ACI object model with Contiv, rather provide the integration with container schedulers/composers.

The limitation is documented. So closing this issue

authors: gaurav-dalvi jainvipin santosh76

repo: contiv/netplugin


text:
Checkout

[ ] Set up Stripe

[ ] Support credit cards
[ ] Support Apple Pay

[x] Set up PayPal
[x] Hook everything up to the UI
[x] Send orders to Slack
[x] Set up cash

user enters email and name and address etc manually
gets sent to Slack as `Cash (incomplete)

Still want to add credit cards and (maybe) apple pay but closing since checkout flow is complete


text:
different attributes in different installations

Hi all,
I'm using gpfit in two different machines. After I run a fitting routine in my data I get certain attributes for the output. The "good" machine shows:
pr.pprint(smafit.__dict__.keys())
['posymap',
 'mfac',
 'ivar',
 'constraint',
 'evaluate',
 'dvars',
 'numpy_bools',
 'bounds',
 'substitutions',
 'max_err',
 'fitdata',
 'varkeys',
 'rms_err']

Whereas the "bad" machine shows:
pr.pprint(smafit.__dict__.keys())
['oper',
 'unsubbed',
 'right',
 'evaluate',
 'nomials',
 'substitutions',
 'p_lt',
 'varkeys',
 'm_gt',
 'last_used_substitutions',
 'left']

I use the fitdata attribute to extract the coefficients in a nice way and import them im MATLAB for post-processing. Why is the attribute list so different in these two installations? I cloned gpfit today in the old (bad) machine to see if there was any update but it doesn't see to affect the attribute list. None of the attributes available in the "bad" machine contains the coefficient in a nice format for extraction.

Hi @iclucho ! Both objects are created with the same code?
If so my guess it's that they're different versions of gpfit; we added the FitConstraintSet class pretty recently, and it looks like that's what you're seeing in the former, while the latter is probably a standard ArrayConstraintSet. What does type(smafit) show for each of them?

Hi bqpd. Thanks for your reply.
Indeed, both objects are generated with the same code. At the moment I only have access to the "bad" machine. There, when typing type(smafit), I get:
<class 'gpfit.fit_constraintset.FitCS'>
I recloned the gpfit version today to see if it would make a difference but so far nothing.

Great! Yeah, looks like that's the newest version: https://github.com/hoburg/gpfit/blob/master/gpfit/fit_constraintset.py#L15
It might not be on pypi yet, so if you installed the 'bad' version with pip install gpfit, that could explain it.

Sorry for the version confusion! GPfit hasn't had a proper owner/maintainer for a year; I'll hopefully be stepping to get it better documented /organized / etc this Fall.

Created #92 to add to PyPI

authors: bqpd iclucho pgkirsch

repo: convexengineering/gpfit


text:
Org feature

Adds organization feature to datatools.

Codecov Report

Merging #44 into dev will increase coverage by 0.01%.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             dev     #44      +/-   ##
========================================
+ Coverage   0.02%   0.03%   +0.01%
========================================
  Files        278     285       +7
  Lines       8244   10851    +2607
  Branches       0    3313    +3313
========================================
+ Hits           2       4       +2
- Misses      8242   10847    +2605

Impacted Files
Coverage Δ

src/main/client/common/components/Sidebar.js
0% <ø> (ø)
:white_check_mark:

src/main/client/common/user/UserSubscriptions.js
0% <ø> (ø)
:white_check_mark:

src/main/client/manager/actions/user.js
0% <ø> (ø)
:white_check_mark:

src/main/client/common/util/util.js
0% <ø> (ø)
:white_check_mark:

src/main/client/admin/actions/admin.js
0% <ø> (ø)
:white_check_mark:

src/main/client/common/containers/App.js
0% <ø> (ø)
:white_check_mark:

...c/main/client/manager/components/RecentActivity.js
0% <ø> (ø)

...main/client/manager/components/FeedSourceViewer.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/components/SignsViewer.js
0% <ø> (ø)
:white_check_mark:

src/main/client/admin/reducers/index.js
0% <ø> (ø)
:white_check_mark:

... and 270 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05d746e...d32a0f2. Read the comment docs.

authors: codecov-io landonreed

repo: conveyal/datatools-manager

license: mit

license_source: bigquery


text:
Fix link to "Internal Apps doc" on "App Parameters" page

Release Playbook

[ ] Rebase against master
[ ] Code review
[ ] Merge into master
[ ] Verify changes at http://site-staging.convox.com
[ ] Promote release on site-production in the convox/production Rack

LGTM

 https://github.com/convox/site/pull/323

authors: idris soulshake

repo: convox/site


text:
[Feature]: Docmost Template

Description
I want a template for Docmost merged into this Coolify repo.
Suppose you can get a Docmost template working and merged I consider that the bounty is complete.
Minimal Reproduction (if possible, example repository)
n/a
Exception or Error
No response
Version
n/a

/attempt #2732

/attempt #2732

Please check my work @DeVoresyah at https://github.com/coollabsio/coolify/pull/2747
Thank you..

Please check my work @DeVoresyah at #2747
Thank you..

you need to attempt first, the bounty is not detected

@ayntk-ai can you check this?

/attempt #2732

I already did attempt on the bounty @DeVoresyah

@DeVoresyah What do I need to check?

@DeVoresyah What do I need to check?

test his template/pr

@DeVoresyah Looks good to me, have to wait for the maintainer to merge to fully say that it is working.

@DeVoresyah Looks good to me, have to wait for the maintainer to merge to fully say that it is working.

yes, now just wait, @andrasbacsai can you take look on this / merge this PR ?

@DeVoresyah in v314, this will be released. Please send the bounty to @alfinauzikri when this is merged.

Thank you @andrasbacsai

@DeVoresyah in v314, this will be released. Please send the bounty to @alfinauzikri when this is merged.

sure, as always~!

just want to inform @alfinauzikri  , that the bounty will be sent at the end of the month. I need to wait for approval from the finance.

Okay, that's fine @DeVoresyah .
Thank you..

Thank you @DeVoresyah :)

authors: Anshgrover23 DeVoresyah alfinauzikri andrasbacsai ayntk-ai

repo: coollabsio/coolify


text:
[Bug]: Nixpacks change version / config file not working

Description
im currently facing issues deploying my monorepo, because im using the latest version of pnpm and catalog: which is not supported on the old version of nixpacks, just recently nixpacks added support for pnpm v9, i have "packageManager": "pnpm@9.9.0", and node engine set to 20, but the deployment always seems to use :
╔═══════════════════ Nixpacks v1.24.1 ══════════════════╗
║ setup │ nodejs_20, pnpm-8_x, openssl, curl, wget ║
║───────────────────────────────────────────────────────║
║ install │ pnpm install ║
║───────────────────────────────────────────────────────║
║ build │ pnpm build:next ║
║───────────────────────────────────────────────────────║
║ start │ pnpm start:next ║
╚═══════════════════════════════════════════════════════╝

i've also added a nixpacks.toml file in the parent folder, but coolify doesnt seem to be taking that into consideration when building the app:
buildImage = 'ghcr.io/railwayapp/nixpacks:ubuntu-1725321821'

[phases.install]
cmds = ["npm install -g corepack", "corepack enable", "corepack prepare pnpm@9.9.0 --activate", "pnpm install"]

would be greate to be able to change the nixpacks version to use the latest one
Minimal Reproduction (if possible, example repository)
use "packageManager": "pnpm@9.9.0", in ur monorepo package.json file and the catalog: feature as well with some packages.
Exception or Error
No response
Version
v4.0.0-beta.329

@andrasbacsai is there a way to upgrade the nixpacks version ? im stuck here, i even had to test Dokploy just to make sure that is not the config, and it seems to deploy just fine there with that nixpacks config file, any ideas why its not using the config file i have inside of coolify ?

@Flowko Nixpacks will be updated with the next version. Please wait for it to be released soon. And could you then please retest?

ofc, thank you

my app deployment keep failing because of Nixpack issue, any way to at least get it work for now?

I'm stuck with the same issue. My app kepps restarting itself some some reasong  and the only log I get is /bin/bash: -c: option requires an argument

@devhe4d You have the same issue? Or some different?
@LUK3D That sounds like a different one. Do you have a start command set?


text:
Getoutline service

https://app.getoutline.com/share/770a97da-13e5-401e-9f8a-37949c19f97e/doc/docker-7pfeLP5a8t

@andrasbacsai   Kindly Add and Vote for this request here: https://feedback.coolify.io/

Closing this one in favor of: https://feedback.coolify.io/posts/58/service-getoutline

authors: andrasbacsai compgeniuses


text:
fix: don't add networks key if network_mode is used

Always use next branch as destination branch for PRs, not main

https://github.com/coollabsio/coolify/issues/3336
You can try with the docker-compose file from the issue or with any docker compose file with network_mode: host.
I also added a check to skip the network create command if we're not using any network (possible if network mode host is used)
Before:

After:

no error
Note: As I don't know the service, I simply checked that the service started.
Tested on something I know:
version: '3.8'
services:
  redis:
    image: 'redis:7.4.0-alpine'
    container_name: redis
    command: 'redis-server --port 1234'
    network_mode: host

you'll see that redis-cli -p 1234 works

I simply wrapped everything related to the networks field with an if, not that great as it increase the indent. But I suppose there will be a refactor to clean that method as it's like 800 lines of code. So I kept it that way.

Thank you for the PR!

authors: Vahor andrasbacsai


text:
refactor: UI

HeaderWithButton component
Created due to inconsistency in styling. The new component is dynamic in the way, to prevent any future copy/paste of the same render structure. My idea is to merge more things into reusable components, so it would be possible to redesign whole UI (if needed) with ease.
Files on trcp-experminetal  were not modified (beside beta.svelte component).

Services - Storage: better responsibility + less wrapping elements/classes

Servers - Usage: max three decimals + space after comma

Thanks for the PR. 💜
I would like to concentrate on v4. That is why I do not plan to add more features to v3.


text:
Some animations not updating while playing sound in Windows Media Player

Originally noted in issue #286
To reproduce: On the Windows 98 demo, play a wave sound file, and as it is playing, hover the cursor over the play button.
Expected: The tooltips should show up immediately and the sound playback should be uninterrupted.
Observed: The sound is interrupted, and only when you move the mouse does the tooltip animation start to update, and the next sound fragment is played.
Other kinds of animation also produce this effect, e.g. opening the start menu, opening menus, and minimising the window.

(Note: Excuse my username, this is a temporary account)
This is a problem I experience a lot. When I load "The Microsoft Sound.wav" and play it in Windows Media Player, usually hovering over something like the x button to close the window will stop the audio and prevent the animation from continuing. In order to let the animation complete and continue playing audio, you have to move the cursor.
This is most likely an error using Javascript to emulate/virtualize Windows, or the code used for Windows 98 on v86.


text:
CLI anchor idl command to use dump base64 for set-buffer and close

A proposal for discussion.
We need to use IDL upgrade from anchor being called from multisig wallet of SPL Governance.
There is a way to pass a custom base64 instruction that is placed into proposal.
A way is to ask anchor idl cli to generate such instruction format instead of execution. As there could be called write-buffer -> set-authority it's all fine to have such functionality only for the set-buffer command.
I asked about it at discord (https://discord.com/channels/889577356681945098/889577399308656662/1105766024650956851) but haven't got any response if there is some way to do so.
This is a solution to get base64 printed. I will be glad for review and happy to hear about better solutions.

Thank your @acheroncrypto for the review and your points.
I updated the code to address the review part.
About the other commands. This change was done from perspective where the idl authority is in use. When the authority is a multisig - it could not be just spl gov but it could be some other multisig system  - then the multisig requires to sign.
From that I think the set-authority (https://github.com/coral-xyz/anchor/blob/master/lang/syn/src/codegen/program/idl.rs#L289) is one more command to be added into the scope.
(erase authority and write buffer can be done in two steps)

@acheroncrypto I discussed this PR with my colleague and he has got a really nice point that the flag should be only like --print-only without forcing to provide the current authority manually. If you be so kind and check the PR with this new adjustment it would be great. Thank you.

I think this looks much better.
One issue is that we are completely recreating Instruction and AccountMeta structs. What would you say to using bincode encoding instead of borsh to get rid of this duplication?

One issue is that we are completely recreating Instruction and AccountMeta structs. What would you say to using bincode encoding instead of borsh to get rid of this duplication?

Thanks @acheroncrypto for the feedback. Sorry I missed the point about the bincode in the first post.
I'm fine to use the bincode serialization but the deserialization at spl gov or serum multisig work with borsh and I'm not sure how those two (bincode vs borsh) may work together.
I  did some experiments
https://github.com/ochaloup/anchor/commit/3db02022630f944b7a95e0769465083fefe3b170#diff-c1f8f7498da827a634bddc8a7559198bc99b296e9d9e8b91a70b503662995b8cR1975
and the results are different. It seems the borsh align the type while bicode somehow strip additional 0. The bincode output fails to be decoded by e.g., spl gov UI processing.
It's like
borsh
 DPRl9bEiiOHiF8/bqgrjrSFA8fetonnejseq+Zra59sDAAAAZNYA/eqUTTit8mSlVRWZCfA/KzcYPpqXMVZTCg5j64cAAQEUEwbrCwK1nWBRfcsHmsSPv3Hq9xKaNnH3AoQH4ngFAAFY1yGdsjj432ypEHVaegNWnDLmTi9zdrRFcIm8Q9RyBwEBCQAAAED0vHin6WkKAw==

[12,244,101,245,177,34,136,225,226,23,207,219,170,10,227,173,33,64,241,247,173,162,121,222,142,199,170,249,154,218,231,219,3,0,0,0,100,...

bincode
DPRl9bEiiOHiF8/bqgrjrSFA8fetonnejseq+Zra59sDZNYA/eqUTTit8mSlVRWZCfA/KzcYPpqXMVZTCg5j64cAAQEUEwbrCwK1nWBRfcsHmsSPv3Hq9xKaNnH3AoQH4ngFAAFY1yGdsjj432ypEHVaegNWnDLmTi9zdrRFcIm8Q9RyBwEBCUD0vHin6WkKAw==

[12,244,101,245,177,34,136,225,226,23,207,219,170,10,227,173,33,64,241,247,173,162,121,222,142,199,170,249,154,218,231,219,3,100,...

Would you know how to make the bincode to generate the serialized output aligned to borsh expectations?

Would you know how to make the bincode to generate the serialized output aligned to borsh expectations?

Yes, we can transform the bincode serialized data if SPL Governance only accepts borsh encoding. I can add this functionality if you'd like.

Yes, we can transform the bincode serialized data if SPL Governance only accepts borsh encoding. I can add this functionality if you'd like.

If you link me to an example in a repo or some doc I would be glad to learn.
If it's easier for you to add it then I will be happy if you can.

If you link me to an example in a repo or some doc I would be glad to learn.
As you've figured, bincode uses 8 bytes(LE) to store the length of the elements meanwhile borsh is using 4 bytes(LE). We can remove extra 4 bytes to make the instructions compatible with borsh.

If it's easier for you to add it then I will be happy if you can.
I've added it but seems like I don't have the rights to push to this branch, could you allow edits by maintainers?

@acheroncrypto awesome, it works nicely. I fixed merge conflicts, squashed my commits and placed your one on top.
It's ready for a final review, I assume.

@acheroncrypto awesome, it works nicely. I fixed merge conflicts, squashed my commits and placed your one on top. It's ready for a final review, I assume.

Thanks, it looks great. Could you add a feature entry to the CHANGELOG for this PR?

Thanks, it looks great. Could you add a feature entry to the CHANGELOG for this PR?

I updated the changelog, hopefully in format similar to others.

authors: acheroncrypto ochaloup

repo: coral-xyz/anchor


text:
Update client3:async-http-client-backend-zio, ... to 3.8.7

Updates

com.softwaremill.sttp.client3:async-http-client-backend-zio
com.softwaremill.sttp.client3:circe
com.softwaremill.sttp.client3:core
com.softwaremill.sttp.client3:slf4j-backend
com.softwaremill.sttp.client3:zio

from 3.3.18 to 3.8.7.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.client3" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.softwaremill.sttp.client3" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #437.


text:
CORE-12581: run signing service direct from flow operations processor…

This is a back-merge of https://github.com/corda/corda-runtime-os/pull/3801 from 5.1.
Please see Dickon's description there.

Looks like a worthwhile simplification, yes.  Beyond that, I'm not sure I can comment further.

Closed in favour of https://github.com/corda/corda-runtime-os/pull/3890

repo: corda/corda-runtime-os


text:
Ошибка Cannot read property '0' of undefined  at ResizeObserver.

Опишите проблему
На версии core-components 39.3.0, появляется ошибка  Uncaught TypeError: Cannot read property '0' of undefined
at ResizeObserver. (var n = e[0].contentBoxSize[0].inlineSize;)

Выяснил, что ошибка появляется в функции:
   const handleElementsResize = (entries: ResizeObserverEntry[]) => {
            if (Array.isArray(entries[0].contentBoxSize)) {
                const [{ inlineSize }] = entries[0].contentBoxSize;

                collapseElements(inlineSize);
            } else {
                // old browser compatibility. See https://caniuse.com/mdn-api_resizeobserverentry_contentboxsize
                collapseElements(entries[0].contentRect.width);
            }
        };

Строка : const [{ inlineSize }] = entries[0].contentBoxSize;
Файл: use-collapsible-elements.ts
Ожидаемое поведение
Не должно быть ошибки
Десктоп:

OS: Windows 10
Browser: Chrome
Version: 79

Это исправлено в 42.12.0.

authors: Lacronts MaximRhz

repo: core-ds/core-components


text:
fix(*): tslib added to external dependencies

После фикса функции хелперы будут импортироваться из tslib, а не встраиваться в код.

Pull Request Test Coverage Report for Build 4133485954

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 80.469%

Totals

Change from base Build 4131288458:
0.0%

Covered Lines:
7390

Relevant Lines:
8364

💛  - Coveralls

authors: Lacronts coveralls


text:
Robots.txt: Disallow /users and /LOCALE/users

I propose modifying the BadgeApp's "robots.txt" to disallow following (and indexing) of anything in /users.
The GDPR is obviously very sensitive about user data, and we display some user data.  If another site scrapes spiders the data (say for a web search), then I think it's primarily the problem of the other site to ensure that the data disappears in a reasonable period of time. That said, we can make it much less likely that user data will show up spidered data at all, by expressly telling spiders to not look at those pages.   Then, if a user account is deleted, that user data will be disappear much more quickly.  In addition, if we make a mistake and accidentally provide private data (primarily the email address), it won't be indexed in other places in most cases - reducing the damage caused if we make a mistake.  Disallowing in robots.txt removes the user pages from search results, but I think it's unlikely people would normally want to see our user pages as search results, and in a separate pull request I propose setting those pages to "noindex" anyway (which also removes them from search results).  Using robots.txt will also counter the web crawling of user pages that, while not a big deal, causes us some work that is unlikely to help anyone.
See the robots.txt specification and Google robots.txt.  The latter describes how Google does things and adds more capabilities, in particular, Google has "Allow", and if there's a conflict, the longest (most specific rule) wins.  We shouldn't specify "/users/" since both /users and /users/ map to "index" (and we need the rules to cover both, so just using "/users" is simpler).  There are no resources starting with "/users" that aren't user-related.
User-Agent: *
Allow: /

That would be changed to:
User-agent: *
Disallow: /users
Disallow: /en/users
Disallow: /fr/users
Disallow: /ja/users
Disallow: /ru/users
Disallow: /zh-CN/users
Disallow: /de/users
Allow: /

We'd have to document this in our instructions on how to create new locales.

repo: coreinfrastructure/best-practices-badge


text:
Expose hosts' /var/log to the kubelet by default

The kubelet creates symlinks that capture the pod name, namespace, container name & Docker container ID to the Docker logs for pods in the /var/log/containers directory on the host.
By mapping the volume for this directory to the kubelet container by default, it becomes easier to use cluster level logging in Kubernetes, i.e., fluentd-elasticsearch, if the user choose to (see my comment in #320).
This PR updates both single-node and multi-node configurations.
(I should probably update some documentation as well, but first I want to know how you guys feel about this.)

I'm in favor of this, as it fixes https://github.com/coreos/coreos-kubernetes/issues/322#issuecomment-244144227. What do you think @colhom?
You are correct, the docs will need to be updated in all of the manual example manifests, etc.

LGTM

@robszumski I figured there was no documentation about exposing the /var/log directory to the kubelet, but apparently I was wrong.
Should I change anything there?

I am strongly in favor of this change.

@danielfm yes, it is documented there, but if we are going to do this by default we need to remove the example from there and add it to each of the example units in all of the guides.
I think thats these, in addition to what you've already changed:
https://github.com/coreos/coreos-kubernetes/blob/master/Documentation/deploy-master.md#create-the-kubelet-unit
https://github.com/coreos/coreos-kubernetes/blob/master/Documentation/deploy-workers.md#create-the-kubelet-unit

Nice, I think you got all of em.

Is there anything else I need to do to get this merged?

Overall this lgtm. @chancez or @colhom can you confirm these changes work for you? I've not ever setup any k8s log aggregation

I've been running my clusters with this mod for at least three months, but of course, the more people testing this the better!

@aaronlevy these emulate exactly what i've had in a patch file for multiple months, if I find sometime I can validate exactly this PR on vagrant etc (no time for much else), but all the changes look fine to me.
I personally prefer the --flag=value form with the =, but thats not really a big deal and I'd rather get this in.

Thanks @danielfm.

authors: AlmogBaku aaronlevy chancez colhom danielfm robszumski

repo: coreos/coreos-kubernetes


text:
README: Conventionalize

Update README.md to follow docs style, correct and clarify language.

/cc @gyuho @philips

lgtm. Thanks!

authors: gyuho joshix

repo: coreos/etcd-play


text:
Option to pretty print json

It would be nice if there's an option to pretty print the json when requesting things over the http interface.
Something like this would be nice:
curl -L http://127.0.0.1:4001/v2/keys/?recursive=true&pretty=true

This would make working with curl much easier and remove the need to install some json-prettifying tool to pipe the output to.

@F21 We probably will not do this at server-side if it can be done at client side. Yea. Pipe it to json-prettifying tool please. :)

echo '{"foo": "lorem", "bar": "ipsum"}' | python -m json.tool

Check out https://github.com/stedolan/jq

@xiang90 @yichengq Fair point. I will be closing this then :smile:
@agokjr That tool looks awesome! Thanks for mentioning it!

repo: coreos/etcd


text:
proxy: client 127.0.0.1:6155 closed request prematurely

Hi,
i am running a cluster version 2.1.1 and have some local proxys version 2.1.1 running, sometimes the etcdctl connection via proxy fails with this errors, then i need to restart the proxy to get it working again.
etcdctl  -u root user list
Password:
context deadline exceeded
this is in the logs
Aug 29 18:22:03 example.com etcd2[2646]: 2015/08/29 18:22:03 proxy: client 127.0.0.1:6155 closed request prematurely
Aug 29 18:22:03 example.com etcd2[2646]: 2015/08/29 18:22:03 proxy: client 127.0.0.1:6156 closed request prematurely
Aug 29 18:22:03 example.com etcd2[2646]: 2015/08/29 18:22:03 proxy: client 127.0.0.1:6157 closed request prematurely
Aug 29 18:22:03 example.com etcd2[2646]: 2015/08/29 18:22:03 proxy: client 127.0.0.1:6158 closed request prematurely
Aug 29 18:22:03 example.com etcd2[2646]: 2015/08/29 18:22:03 proxy: client 127.0.0.1:6159 closed request prematurely
At the same time when using etcdctl with the real cluster , it does work

ok you can reproduce this with
while true ; do etcdctl ls  ; done
btw. i have removed all localhost client urls from the cluster, now i do not need to restart the proxy to get it working again

You have to provide more information. I do not have the configuration of your cluster. See https://github.com/coreos/etcd/blob/master/Documentation/reporting_bugs.md
But this all localhost advertised client urls looks very suspicious. See https://github.com/coreos/etcd/blob/master/Documentation/configuration.md#-advertise-client-urls

Hi,
this is my cluster config, i have eliminated all localhost advertise client urls
[member]
ETCD_NAME="zkm1"
ETCD_DATA_DIR="/var/lib/etcd/etcd1.etcd"
ETCD_LISTEN_PEER_URLS="http://zkm01.example.net:2380"
ETCD_LISTEN_CLIENT_URLS="http://zkm01.example.net:2379,http://127.0.0.1:2379"
[cluster]
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://zkm01.example.net:2380"
ETCD_INITIAL_CLUSTER="zkm1=http://zkm01.example.net:2380,zkm6=http://zkm6.example.net:2380,zkm4=http://zkm4.example.net:2380,zkm2=http://zkm02.example.net:2380,zkm5=http://zkm5.example.net:2380,zkm3=http://zkm03.example.net:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
ETCD_ADVERTISE_CLIENT_URLS="http://zkm01.example.net:2379"

@f0 @floriankoch Still see the same issue after removing localhost client endpoints? Are you sure zkm01.example.net does not resolve to localhost?

yes
if i list my cluster members, no localhost are shown.
bfd4023b0c6e8d6: name=zkm1 peerURLs=http://zkm01.example.net:2380 clientURLs=http://zkm01.example.net:2379
1f029defcea02404: name=zkm6 peerURLs=http://zkm6.example.net:2380 clientURLs=http://zkm06.example.net:2379
a80cff776210b15c: name=zkm2 peerURLs=http://zkm02.example.net:2380 clientURLs=http://zkm02.example.net:2379
bd19b4ffc2b7182d: name=zkm3 peerURLs=http://zkm03.example.net:2380 clientURLs=http://zkm03.example.net:2379
d8f2630822b402e5: name=zkm5 peerURLs=http://zkm5.example.net:2380 clientURLs=http://zkm05.example.net:2379

@f0 @floriankoch OK. I will try to reproduce this myself. Ideally, you can try to run the Procfile in etcd repo to set up a local cluster with proxy and verify you can reproduce this issue.

We're seeing this too but I can't replicate it using etcdctl (on the proxy nodes). I can say that we're doing a lot of watches on the proxy nodes and using the claws/aioetcd python client (which is probably doing something weird).
Also 2.1.1.

The same thing started happening to me after upgrade from coreos stable to coreos beta.
Sep 07 13:02:02 test etcd2[677]: 2015/09/7 13:02:02 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:02 test etcd2[677]: 2015/09/7 13:02:02 proxy: marked endpoint http://10.240.135.37:4001 unavailable
Sep 07 13:02:02 test etcd2[677]: 2015/09/7 13:02:02 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:07 test etcd2[677]: 2015/09/7 13:02:07 proxy: marked endpoint http://10.240.135.37:4001 available
Sep 07 13:02:10 test etcd2[677]: 2015/09/7 13:02:10 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:10 test etcd2[677]: 2015/09/7 13:02:10 proxy: marked endpoint http://10.240.135.37:4001 unavailable
Sep 07 13:02:10 test etcd2[677]: 2015/09/7 13:02:10 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:10 test etcd2[677]: 2015/09/7 13:02:10 proxy: client 127.0.0.1:41939 closed request prematurely
Sep 07 13:02:15 test etcd2[677]: 2015/09/7 13:02:15 proxy: marked endpoint http://10.240.135.37:4001 available
Sep 07 13:02:16 test etcd2[677]: 2015/09/7 13:02:16 proxy: client 127.0.0.1:41941 closed request prematurely
Sep 07 13:02:17 test etcd2[677]: 2015/09/7 13:02:17 proxy: client 127.0.0.1:41936 closed request prematurely
Sep 07 13:02:17 test etcd2[677]: 2015/09/7 13:02:17 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:17 test etcd2[677]: 2015/09/7 13:02:17 proxy: marked endpoint http://10.240.135.37:4001 unavailable
Sep 07 13:02:17 test etcd2[677]: 2015/09/7 13:02:17 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:18 test etcd2[677]: 2015/09/7 13:02:18 proxy: client 127.0.0.1:41948 closed request prematurely
Sep 07 13:02:22 test etcd2[677]: 2015/09/7 13:02:22 proxy: marked endpoint http://10.240.135.37:4001 available
Sep 07 13:02:24 test etcd2[677]: 2015/09/7 13:02:24 proxy: client 127.0.0.1:41952 closed request prematurely
Sep 07 13:02:25 test etcd2[677]: 2015/09/7 13:02:25 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:25 test etcd2[677]: 2015/09/7 13:02:25 proxy: marked endpoint http://10.240.135.37:4001 unavailable
Sep 07 13:02:25 test etcd2[677]: 2015/09/7 13:02:25 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:26 test etcd2[677]: 2015/09/7 13:02:26 proxy: client 127.0.0.1:41958 closed request prematurely
Sep 07 13:02:27 test etcd2[677]: 2015/09/7 13:02:27 proxy: client 127.0.0.1:41960 closed request prematurely
Sep 07 13:02:28 test etcd2[677]: 2015/09/7 13:02:28 proxy: client 127.0.0.1:41962 closed request prematurely
Sep 07 13:02:30 test etcd2[677]: 2015/09/7 13:02:30 proxy: marked endpoint http://10.240.135.37:4001 available
Sep 07 13:02:30 test etcd2[677]: 2015/09/7 13:02:30 proxy: client 127.0.0.1:41964 closed request prematurely
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: marked endpoint http://10.240.135.37:4001 unavailable
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: client 127.0.0.1:41950 closed request prematurely
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: client 127.0.0.1:41954 closed request prematurely
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout
Sep 07 13:02:32 test etcd2[677]: 2015/09/7 13:02:32 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout

@f0 @soellman @micahhausler I failed to reproduce with a 3 member cluster + 1 proxy setup. Can you provide me a way to reproduce this issue? From the logging, this simply means the client closed a http request before it gets the response.

@michalmedvecky

Sep 07 13:02:02 test etcd2[677]: 2015/09/7 13:02:02 proxy: failed to direct request to http://10.240.135.37:4001: dial tcp 10.240.135.37:4001: i/o timeout

Your proxy cannot connect to the etcd cluster you set. You have to check your configuration.

No I can't reproduce it with a test cluster.. I'm guessing that the client I'm using is buggy.
However I think that the message "proxy: client xxx closed request prematurely", if the operation isn't actually a problem for etcd, should be at debug level and not show up in the regular log.

@soellman I am still not sure if this is a client error or a proxy error. My best guess is that: this is a client error. So I want to reproduce it make sure. However I failed :(

@soellman https://github.com/soellman I am still not sure if this is a client error or a proxy error. My best guess is that: this is a client error. So I want to reproduce it make sure. However I failed :

Sorry guys, my problem was that one of my etcd nodes was really down.

@michalmedvecky Ah. OK. No problem. I have to count on @f0 then. :)

@fasaxc @webner @mwitkow-io @sorah
I know you guys are running etcd with proxy in production. Have you tried etcd 2.1? Do you see this behavior?

@f0 Kindly ping.

I have etcd 2.1.2 in production and see some of these (every couple of hours):
proxy: client 127.0.0.1:37676 closed request prematurely
But the proxy seems to be rock stable.

@webner Do you think they are actually client issues?

I have etcd 2.0.12 and see some of these , just like:
Sep 15 15:14:16 core-1-85 etcd2[1091]: 2015/09/15 15:14:16 proxy: client 127.0.0.1:51512 closed request prematurely
Sep 15 15:14:22 core-1-85 etcd2[1091]: 2015/09/15 15:14:22 proxy: client 127.0.0.1:51495 closed request prematurely
Sep 15 15:17:26 core-1-85 etcd2[1091]: 2015/09/15 15:17:26 proxy: client 127.0.0.1:51758 closed request prematurely
Sep 15 15:19:13 core-1-85 etcd2[1091]: 2015/09/15 15:19:13 proxy: client 127.0.0.1:51743 closed request prematurely
Sep 15 15:20:56 core-1-85 etcd2[1091]: 2015/09/15 15:20:56 proxy: client 127.0.0.1:51760 closed request prematurely
Sep 15 15:20:57 core-1-85 etcd2[1091]: 2015/09/15 15:20:57 proxy: client 127.0.0.1:51787 closed request prematurely
Sep 15 15:21:00 core-1-85 etcd2[1091]: 2015/09/15 15:21:00 proxy: client 127.0.0.1:51799 closed request prematurely
Sep 15 15:21:01 core-1-85 etcd2[1091]: 2015/09/15 15:21:01 proxy: client 127.0.0.1:51800 closed request prematurely
when this appeared , I cannot read data from etcd with etcdctl, and report as :
Error from server: 501: All the given peers are not reachable (failed to propose on members [http://127.0.0.1:4001] twice [last error: Unexpected HTTP status code]) [0]

@xiang90
ok now i am using 2.1.3 on all sides (server , proxy, client (etcdctl)) i can NOT reproduce the problem any longer!
Using a proxy 2.1.1, i can reproduce it!
So it seems fixed.
regards f0

@shenshouer Can you reliable reproduce this? After reading through all these, I think it is not a proxy issue. Probably you have set some timeout on the client side, and the client reaches its timeout and closes connection. We should probably move the proxy logging level to debug.

@xiang90
core@core-1-85 ~ $ systemctl status -l etcd2
● etcd2.service - etcd2
   Loaded: loaded (/usr/lib64/systemd/system/etcd2.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/etcd2.service.d
           └─20-cloudinit.conf
   Active: active (running) since Wed 2015-09-09 19:28:58 CST; 6 days ago
  Main PID: 1091 (etcd2)
   Memory: 7.1M
  CPU: 14min 1.571s
   CGroup: /system.slice/etcd2.service
           └─1091 /usr/bin/etcd2

Sep 16 10:03:53 core-1-85 etcd2[1091]: 2015/09/16 10:03:53 proxy: client 127.0.0.1:56653 closed request prematurely
Sep 16 10:07:58 core-1-85 etcd2[1091]: 2015/09/16 10:07:58 proxy: client 127.0.0.1:56651 closed request prematurely
Sep 16 10:09:37 core-1-85 etcd2[1091]: 2015/09/16 10:09:37 proxy: client 127.0.0.1:56588 closed request prematurely
Sep 16 10:10:39 core-1-85 etcd2[1091]: 2015/09/16 10:10:39 proxy: client 127.0.0.1:56695 closed request prematurely
Sep 16 10:12:59 core-1-85 etcd2[1091]: 2015/09/16 10:12:59 proxy: client 127.0.0.1:56623 closed request prematurely
Sep 16 10:16:55 core-1-85 etcd2[1091]: 2015/09/16 10:16:55 proxy: client 127.0.0.1:56561 closed request prematurely
Sep 16 10:18:00 core-1-85 etcd2[1091]: 2015/09/16 10:18:00 proxy: client 127.0.0.1:56703 closed request prematurely
Sep 16 10:20:07 core-1-85 etcd2[1091]: 2015/09/16 10:20:07 proxy: client 127.0.0.1:56675 closed request prematurely
Sep 16 10:20:08 core-1-85 etcd2[1091]: 2015/09/16 10:20:08 proxy: client 127.0.0.1:56677 closed request prematurely
Sep 16 10:23:01 core-1-85 etcd2[1091]: 2015/09/16 10:23:01 proxy: client 127.0.0.1:56721 closed request prematurely

and in /run/systemd/system/etcd2.service.d/20-cloudinit.conf
core@core-1-85 ~ $ cat /run/systemd/system/etcd2.service.d/20-cloudinit.conf
[Service]
Environment="ETCD_ADVERTISE_CLIENT_URLS=http://10.12.1.85:2379,http://10.12.1.85:4001"
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/c741d71c1d69fd82b0d1ce90f342de3b"
Environment="ETCD_INITIAL_ADVERTISE_PEER_URLS=http://10.12.1.85:2380"
Environment="ETCD_LISTEN_CLIENT_URLS=http://10.12.1.85:2379,http://10.12.1.85:4001,http://127.0.0.1:2379,http://127.0.0.1:4001"
Environment="ETCD_LISTEN_PEER_URLS=http://10.12.1.85:2380,http://10.12.1.85:7001"
Environment="ETCD_NAME=core-1-85"
and in /var/lib/coreos-install/user-data
coreos:
  etcd2:
    name: core-1-85
    discovery: https://discovery.etcd.io/c741d71c1d69fd82b0d1ce90f342de3b
    listen-client-urls: http://10.12.1.85:2379,http://10.12.1.85:4001,http://127.0.0.1:2379,http://127.0.0.1:4001
    advertise-client-urls: http://10.12.1.85:2379,http://10.12.1.85:4001
    listen-peer-urls: http://10.12.1.85:2380,http://10.12.1.85:7001
    initial-advertise-peer-urls: http://10.12.1.85:2380
  update:
    group: stable
    reboot-strategy: off
  fleet:
    public-ip: 10.12.1.85
    metadata: "role=minion"
  flannel:
    interface: 10.12.1.85
  units:
    - name: etcd2.service
      command: start
    - name: setup-network-environment.service
      command: start
      content: |
        [Unit]
        Description=Setup Network Environment
        Documentation=https://github.com/kelseyhightower/setup-network-environment
        Requires=network-online.target
        After=network-online.target
        [Service]
        ExecStartPre=/usr/bin/timedatectl set-timezone Asia/Shanghai
        #ExecStartPre=/usr/bin/ntpdate -u cn.pool.ntp.org
        ExecStart=/opt/bin/setup-network-environment
        RemainAfterExit=yes
        Type=oneshot
    - name: fleet.service
      command: start
    - name: flanneld.service
    ......

@xiang90   can i something? For me the Probem is gone with the update to 2.1.3

For posterity, this blog post exactly describes the problem. The engineer on our team who first saw this agrees that this is our exact issue.
http://www.projectclearwater.org/adventures-in-debugging-etcd-http-pipelining-and-file-descriptor-leaks/

@xiang90  do you still need more infos?

@f0 I think @soellman has a reasonable explanation. We need to wait for the upstream to solve https://github.com/golang/go/issues/13165 before looking into this again.

@f0 @soellman
Basically, HTTP pipelining behavior does not work well with go's http close notification. Please take a look at golang/go#13165 for more information. The best fix is to disable pipelining in the client library you are using. etcd/client does not use pipelining.

authors: f0 floriankoch michalmedvecky shenshouer soellman webner xiang90