text:
Kafka.System.Exception: Could not load file or assembly Confluent.Kafka or Confluent.SchemaRegistry

Description
I have recently upgraded Confluent.Kafka and Confluent.SchemaRegistry, librdkafka to 1.4.0. As soon as I build the project it is working successfully locally in Debug mode. It starts to throw an error with following error.
System.IO.FileLoadException: Could not load file or assembly 'Confluent.SchemaRegistry, Version=1.3.0.0, Culture=neutral, PublicKeyToken=34ce5df5fa699c09' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I saw in project.assets.json and Nuget UI from VS19 where
Confluent.SchemaRegistry.Serde is at 1.3.0 and which had dependency of 1.3.0 versions it seems that's where it fails with above error while Building Producer. I tried to find what actually is looking for version 1.3.0 and I am suspecting Confluent.SchemaRegistry.Serde version 1.3.0 is culprit here. However I am beginner to this, not sure.
I tried to minimize the error by putting following application Binding Redirects at .config level which helped but which is according to me is Little Hack.
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">       <dependentAssembly>         <assemblyIdentity name="Confluent.Kafka" publicKeyToken="12c514ca49093d1e" culture="neutral"/>         <bindingRedirect oldVersion="0.0.0.0-1.4.0.0" newVersion="1.4.0.0"/>       </dependentAssembly>     </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">       <dependentAssembly>         <assemblyIdentity name="Confluent.SchemaRegistry" publicKeyToken="34ce5df5fa699c09" culture="neutral"/>         <bindingRedirect oldVersion="0.0.0.0-1.4.0.0" newVersion="1.4.0.0"/>       </dependentAssembly>     </assemblyBinding>
My questions are,

Is Confluent.SchemaRegistry.Serde required with new Confluent.Kafka and Confluent.SchemaRegistry v1.4.0?
Why discrepancy between locally and on server?

As being naive to this concept, guide me over this.
How to reproduce
Upgrade NuGet Packages Confluent
Checklist
All Nuget packages:
Confluent.Kafka = v1.4.0
librdkafka.redist = v1.4.0
Confluent.SchemaRegistry = v1.4.0
Confluent.SchemaRegistry.Serdes = v1.3.0 (which NuGet UI shows as stable version)
.NET Framework = v4.7.2
Used outer .bat file to generate POCO classes.
Server Box = Win2k8 R2 Server 64-bit (installed till .NET v4.7.2 compatibility)
Please provide the following information:

[ ] A complete (i.e. we can run it), minimal program demonstrating the problem. No need to supply a project file.
[X] Confluent.Kafka nuget version.
[ ] Apache Kafka version.
[ ] Client configuration.
[X] Operating system.
[ ] Provide logs (with "debug" : "..." as necessary in configuration).
[ ] Provide broker log excerpts.
[ ] Critical issue.

Confluent.SchemaRegistry.Serdes has effectively become Confluent.SchemaRegistry.Serdes.Avro and there is also Confluent.SchemaRegistry.Serdes.Protobuf and Confluent.SchemaRegistry.Serdes.Json
see: https://github.com/confluentinc/confluent-kafka-dotnet#referencing

note: there are some minor errors in the README.md related to this that have already been fixed on the 1.4.x branch and will be on master with the release of 1.4.2 in a few days.

Thank you @mhowlett for your prompt response. I will add Confluent.SchemaRegistry.Serdes.Avro to my project via NuGet. Another question, to add this at Nuget level, do I have to remove any other Nuget package to remove conflict?
For example, since you introduced Confluent.SchemaRegistry.Serdes.Avro, does that mean I should remove either Confluent.Apache.Avro or Confluent.SchemaRegistry ?
Asking out of curiosity. Thanks.

you shouldn't need to reference Confluent.SchemaRegistry explicitly - it will be included transitively by way of referencing Confluent.SchemaRegistry.Serdes.Avro. Same with Confluent.Apache.Avro, except in this case, this is no longer actually the correct dependency - it's been swapped out for Apache.Avro in > v1.4.0. Just reference Confluent.SchemaRegistry.Serdes.Avro.

@mhowlett I'm facing some weird issue. My application is working fine with the .net framework 4.6.2 but the same code is giving an error in .net core 6.0 Local: Value serialization error
---> Confluent.SchemaRegistry.SchemaRegistryException: ; error code: -1"
Is there any changes between these two libraries? As you mentioned I'm just referring "Confluent.SchemaRegistry.Serdes.Avro." in .net core as other required assemblies are already there as dependency.

repo: confluentinc/confluent-kafka-dotnet


text:
cp-kafka error Failed to construct kafka producer

install with k8s, k8s version 1.18, cp-kafka version 6.1.0
6.2.0 the same error!

kafka.log
kafka.txt

yes, I change service config , has been resolved, now I add install all project, schema-registry error

yes, I change service config, has been resoled, now I install other all, schema-registry error

See #548 for a fix

source: gharchive/issue

repo: confluentinc/cp-helm-charts

license_type: permissive

license_source: github-api


text:
Is this project dead?

I don't see any upates on this project.
Is it dead?
Maybe it should be moved into a new organization?
This fork seems more updated: https://github.com/andre-hub/gotk3
Maybe start from there?

We don't have any projects currently in development that are using gotk3 so I have not been spending my time keeping it up to date with the latest gtk releases.  If that changes I may look into updating the package again.
I also don't use gtk on the desktop anymore and have personally come to the conclusion that wrapping C GTK calls isn't a very good way to write a GUIs for Go programs.  It involves far too much context switching (cgo is very expensive) and there are known memory leaks which I'm not sure how to solve.  A better solution would be to use Go 1.5 to create a C archive or shared object with core application logic and link that to a c/c++/rust/whatever project where the GUI databindings are.  This is similar to how Go is used to write iOS and Android apps.
The code is open source under an ISC license so anyone can take our stuff and continue development on a fork.  The community can decide which fork is the blessed one.

Thanks for the response!
I was also thinking of a seperate project for the GUI.
Seems like the best way to go.

license: isc

license_source: bigquery


text:
[feat] Add auth function for authorizing user

AccessToken, RefreshToken 발급 함수 작성
테스트 결과 클라이언트 쿠키에 정상적으로 저장됨을 확인
close #2

react와 webpack을 사용하지 않는 환경에서 서버 주소로 접근할 경우 cors에러 발생. 반려 부탁드립니다.

수정해주세요~

source: gharchive/pull-request

authors: NamgungJongMin parkseonup

license: MIT


text:
Move page-up/page-down gestures to opt-in in settings

We have virtual keys for pg up and pg down; can we remove the "drag on the left side of the screen" gesture? @kruton @jklein24

:+1: from me on this - I've found the page up/down on the left side of the screen really unexpected before really paying attention to the instructions. It's particularly confusing when not in a context where pgup/dn works correctly. It just sort of makes scrolling seem broken. @kruton, are you ok with removing this? I guess we could always add a setting to keep it there, but I'd rather kill it altogether.

+1 - I've also found this functionality confusing and unexpected.

Would be nice to make it optional because I'm use to it :-)

Accidentally removed this in #277. Please let me know if we want to keep this feature.

I think we should keep it around in settings because I'm sure @alescdb isn't alone in being used to this behavior.

@rhansby, feel free to do this in another PR once your giant one lands.

+1 for keeping it, even as an option. I verymuch use it all the time - e.g. running IRC clients via screen

authors: alescdb bengolds jklein24 khorimoto leonerd rhansby

repo: connectbot/connectbot


text:
Make options read from delegate

By applying this, the touch visualizer window could not change active status dynamically.
(for instance, changed by NSUserDefaults values or other preference values)

Code changes look good, but the README.md needs updates to explain the code changes.

updated. thanks

btw, I didn't update the podspec file. You could test it and after it's okay, submit an update. Thanks.

Yeah, I'll update the .podspec, do any last clean up, fix any minor formatting issues in the README and test it later this week/weekend.  Programming something else in Swift right now :).

cool :+1:

any update on podspec? :smile:

authors: joeblau sodastsai

repo: conopsys/COSTouchVisualizer

license: mit


text:
fix: update crate

Fix the clippy warning in CI due to crate versioning.

Updating Cargo.lock should be enough here. @karlem is on it.

authors: cryptoAtwill raulk

repo: consensus-shipyard/ipc


text:
model.predict does not expect model.cond to return a pandas Series

Hi, thanks for the great package.
It appears that the recent change to use formulaic_contrasts has introduced a bug in model.predict() because this function is not expecting model.cond() to return a pandas Series.
It appears that previously, the return value of model.cond() was a pandas DataFrame but now it is a single row, represented as a pandas Series

Hi Mark,
thanks for filling the PR. You are right. Thanks for spotting this :)
I merged the PR.
Best,
Constantin

authors: const-ae keller-mark

repo: const-ae/pyLemur


text:
Have a default "welcome" article that explains how to use the app (and how to edit/delete itself)

Even if nothing has been typed

Can be done with a store similar to drafts - called help or tutorial
Multiple posts, each explaining a different feature
After a post or draft is created, these posts can be accessed from left button -> nav list -> help/tutorial

repo: constellational/iOS


text:
Add logging

Introduce logging to Construct.

Each context should have it's own logger accessible via ctx.log() and ctx.err().
Should be an api get_logger which returns a logger for the current ctx.
StreamHandler to print to stdout and FileHandler to print to append to a file ~/.construct/log.txt
Add another handler to print to GUI console viewer

Introduced logging configuration via dictConfig. Now we just need to actually add some logging info to the ActionRunner. Users can define a LOGGING section in their CONSTRUCT_CONFIG file a la nameko/django.

repo: construct-org/construct


text:
🛑 rosebud.partouze-cagoule.fr is down

In 5cf5363, rosebud.partouze-cagoule.fr (https://rosebud.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rosebud.partouze-cagoule.fr is back up in 82ea73b.

repo: constructions-incongrues/status


text:
🛑 trashley.incongru.org is down

In 487088c, trashley.incongru.org (https://trashley.incongru.org) was down:

HTTP code: 503
Response time: 82 ms

Resolved: trashley.incongru.org is back up in 1b6274a.


text:
🛑 quickoschantenoel.musiqueapproximative.net is down

In d78e555, quickoschantenoel.musiqueapproximative.net (https://quickoschantenoel.musiqueapproximative.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: quickoschantenoel.musiqueapproximative.net is back up in 27e5102.


text:
🛑 lagrandepurge.resterdigne.net is down

In 131826b, lagrandepurge.resterdigne.net (https://lagrandepurge.resterdigne.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: lagrandepurge.resterdigne.net is back up in a38343e.


text:
🛑 partouze-cagoule.fr is down

In e5ef023, partouze-cagoule.fr (https://partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: partouze-cagoule.fr is back up in 1640dc1.


text:
Renamed API Framework

Hey,
I accidentally noticed the other day that my tiny framework is mentioned here :) Thank you very much!
I'd like to send you a PR, because I recently renamed the project and gave it more robust foundations. And of couse, I continue supporting the container-interop interface!
P.S.: I hope that the standard gets more adoption one day, as it's a great idea!

:+1: merging!

authors: kocsismate mnapoli

repo: container-interop/container-interop


text:
Add Buildah buildstep plugin

Maintainers will complete the following section:

[x] Commit messages are descriptive enough
[ ] "Signed-off-by:" line is present in each commit
[x] Code coverage from testing does not decrease and new code is covered
[x] JSON/YAML configuration changes are updated in the relevant schema
[x] Changes to metadata also update the documentation for the metadata
[ ] Pull request includes link to an osbs-docs PR for user documentation updates
[x] New feature can be disabled from a configuration file

LGTM, just a couple inline questions.
Should we start documenting this feature right away? I mean, should this already include a PR for osbs-docs?
Also, the 1st commit does not have a signed-off-by line. I wouldn't oppose to waiving that one for this PR though.

I would leave out the documentation for the time being, until we have a plugin that can actually work.
We should have Signed-Off-By though.

Waiving third party signed off by entry

rn updated: - new Buildah buildstep plugin

authors: athos-ribeiro rcerven twaugh

repo: containerbuildsystem/atomic-reactor


text:
certificate signed by unknown authority

i have a local registry and try to pull image with ctr.
But failed with:
ctr: failed to do request: Head https://xxx/v2/library/nginx/manifests/1.10.1-alpine:x509: certificate signed by unknown authority

Both -k and --plain-http tryied, but failed yet.
it is a public image and can be pulled by docker pull

Looks like the -k flag is not being properly handled by ctr, I will make a PR to fix this

I tried on upstream and this is working now. @crosbymichael I think it can be closed

@gianarb thanks for verifying

authors: crosbymichael dmcgowan gianarb ikaven1024

repo: containerd/containerd


text:
cache: fix null pointer access when cachemanager.Disable is true

Filesystem.cacheMgr is null when cacheManager.Disable is configured to be true, thus cause null pointer access. Fix it by always create the cacheMgr object no matter cacheManager.Disable is true or false.

Why not check if the cacheMgr is nil?
It seems WithEnableStargz and referrerMgr,  also have the same problem.

Why not check if the cacheMgr is nil? It seems stargzResolver and referrerMgr also have the same problem.

With the evolution of nydus-snapshotter, cache manager becomes mandatory instead optional now. On the other hand, stargzResolver and referrerMgr are optional.

repo: containerd/nydus-snapshotter


text:
Document full set up with k3s

There is a large amount of assumed knowledge and set up in the current instructions so it would be useful to have documentation of a full run through of setup and usage with k3s.
I'm working on getting this running in my lab using k3s. If I get it all working, I can write up the commands I used.

I have an example that runs a shim developed on top of runwasi working on k3d.
Check out this here: https://github.com/Mossaka/k3d-wasm
Particularly containerd-shim-spin-v1 is a spin shim binary. Here is the source code.

Hey, I finally got a chance to play with this. I think I got it working on k3s but have a few issues:
I can see the shim running when the "pod" gets deployed! So I'm pretty sure my containerd config is read correctly.
I have to adapt a little since I can't use the example service as written. When I add a service and ingress, I get a "Bad Gateway" back from my ingress controller so something is weird with the networking. I'm assuming that the "pod" is exposing port 80, right? I see that in the code that it's listening on 0.0.0.0:80.
Also, I'm not seeing logs and when I delete the pod, it gets stuck in terminating.

Hey, I finally got a chance to play with this. I think I got it working on k3s but have a few issues:
I can see the shim running when the "pod" gets deployed! So I'm pretty sure my containerd config is read correctly.
I have to adapt a little since I can't use the example service as written. When I add a service and ingress, I get a "Bad Gateway" back from my ingress controller so something is weird with the networking. I'm assuming that the "pod" is exposing port 80, right? I see that in the code that it's listening on 0.0.0.0:80.
Also, I'm not seeing logs and when I delete the pod, it gets stuck in terminating.

I have the same problem with microk8s

@defims do you have the walkthrough for bootstrapping and using in microk8s? That would be useful AND I can test your repro

@defims do you have the walkthrough for bootstrapping and using in microk8s? That would be useful AND I can test your repro

I use macos and my steps is below:
install microk8s on macos:
brew install ubuntu/microk8s/microk8s
microk8s install
microk8s shell microk8s-vm
sudo usermod -aG microk8s $USER
sudo chown -f -R $USER ~/.kube
newgrp microk8s
microk8s enable dns
microk8s stop
microk8s start

install wasmtime and build the shims
cd ~
curl https://wasmtime.dev/install.sh -sSf | bash
git clone https://github.com/containerd/runwasi.git runwasi-wasmtime
sudo apt-get install build-essential
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cd runwasi-wasmtime
make build
make install

configue containerd
edit containerd config(/var/snap/microk8s/4172/args/containerd-template.toml), add 5 line:
    # add 5 line blew
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmedge]
      runtime_type = "io.containerd.wasmedge.v1"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
      runtime_type = "io.containerd.wasmtime.v1"

and the total file is:
# Use config version 2 to enable new configuration fields.
version = 2
oom_score = 0

[grpc]
  uid = 0
  gid = 0
  max_recv_message_size = 16777216
  max_send_message_size = 16777216

[debug]
  address = ""
  uid = 0
  gid = 0

[metrics]
  address = "127.0.0.1:1338"
  grpc_histogram = false

[cgroup]
  path = ""

# The 'plugins."io.containerd.grpc.v1.cri"' table contains all of the server options.
[plugins."io.containerd.grpc.v1.cri"]

  stream_server_address = "127.0.0.1"
  stream_server_port = "0"
  enable_selinux = false
  # sandbox_image = "k8s.gcr.io/pause:3.1"
  sandbox_image = "lank8s.cn/pause:3.7"
  stats_collect_period = 10
  enable_tls_streaming = false
  max_container_log_line_size = 16384

  # 'plugins."io.containerd.grpc.v1.cri".containerd' contains config related to containerd
  [plugins."io.containerd.grpc.v1.cri".containerd]

    # snapshotter is the snapshotter used by containerd.
    snapshotter = "${SNAPSHOTTER}"

    # no_pivot disables pivot-root (linux only), required when running a container in a RamDisk with runc.
    # This only works for runtime type "io.containerd.runtime.v1.linux".
    no_pivot = false

    # default_runtime_name is the default runtime name to use.
    default_runtime_name = "${RUNTIME}"

    # add 5 line blew
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmedge]
      runtime_type = "io.containerd.wasmedge.v1"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
      runtime_type = "io.containerd.wasmtime.v1"

    # 'plugins."io.containerd.grpc.v1.cri".containerd.runtimes' is a map from CRI RuntimeHandler strings, which specify types
    # of runtime configurations, to the matching configurations.
    # In this example, 'runc' is the RuntimeHandler string to match.
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
      runtime_type = "${RUNTIME_TYPE}"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime]
      # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
      runtime_type = "${RUNTIME_TYPE}"

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime.options]
        BinaryName = "nvidia-container-runtime"

   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
      runtime_type = "io.containerd.kata.v2"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
        BinaryName = "kata-runtime"

  # 'plugins."io.containerd.grpc.v1.cri".cni' contains config related to cni
  [plugins."io.containerd.grpc.v1.cri".cni]
    # bin_dir is the directory in which the binaries for the plugin is kept.
    bin_dir = "${SNAP_DATA}/opt/cni/bin"

    # conf_dir is the directory in which the admin places a CNI conf.
    conf_dir = "${SNAP_DATA}/args/cni-network"

  # 'plugins."io.containerd.grpc.v1.cri".registry' contains config related to the registry
  [plugins."io.containerd.grpc.v1.cri".registry]

    # 'plugins."io.containerd.grpc.v1.cri".registry.mirrors' are namespace to mirror mapping for all namespaces.
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
        endpoint = ["https://registry-1.docker.io", ]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:32000"]
        endpoint = ["http://localhost:32000"]

build wasi-demo-app and run it with ctr
cd crates/wasi-demo-app && cargo build --features oci-v1-tar
microk8s ctr image import --all-platforms img.tar
microk8s ctr run --rm --runtime=io.containerd.wasmtime.v1 ghcr.io/containerd/runwasi/wasi-demo-app:latest wasi-demo-app

test wasmedge server code
As I know wasi network standard still on the way, and wasmedge is for to wasmtime, and second-state/runwasi is a fork of containerd/runwasi, but there is no way to post issue to second-state/runwasi, so the test code below is base on wasmedge
install wasmedge and shims
cd ~
curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash -s -- -p /usr/local
git clone https://github.com/second-state/runwasi.git
cd runwasi
git submodule init
git submodule update
rustup default nightly
make build FEATURES=wasmedge
sudo make install RUNTIME=wasmedge

build hyper-demo and run it with ctr
sudo apt-get install docker-ce
sudo make demo/out/hyper_img.tar
microk8s ctr images --all-platforms import demo/out/hyper_img.tar
microk8s ctr run --rm --net-host --runtime=io.containerd.wasmedge.v1 docker.io/library/hyper-demo:latest testclient /client.wasm

run it with kubectl
microk8s kubectl apply -f wasm.yml

wasm.yml:
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: discuzq
  annotations:
    kubernetes.io/ingress.class: "traefik"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wasmtest
            port:
              number: 3000
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmedge
handler: wasmedge
---
kind: Service
apiVersion: v1
metadata:
  name: wasmtest
  labels:
    name: wasmtest
spec:
  ports:
  - name: wasmtest3000
    protocol: TCP
    port: 3000
  selector:
    app: wasmtest
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: wasmtest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wasmtest
  template:
    metadata:
      labels:
        app: wasmtest
    spec:
      runtimeClassName: wasmedge
      containers:
      - name: wasmtest
        image: docker.io/library/hyper-demo:latest
        imagePullPolicy: Never
        ports:
        - containerPort: 3000

visit 192.168.205.3:3000
got bad gateway

@defims do you have the walkthrough for bootstrapping and using in microk8s? That would be useful AND I can test your repro

@squillace I use macos and my steps is below:
install microk8s on macos:
brew install ubuntu/microk8s/microk8s
microk8s install
microk8s shell microk8s-vm
sudo usermod -aG microk8s $USER
sudo chown -f -R $USER ~/.kube
newgrp microk8s
microk8s enable dns
microk8s stop
microk8s start

install wasmtime and build the shims
cd ~
curl https://wasmtime.dev/install.sh -sSf | bash
git clone https://github.com/containerd/runwasi.git runwasi-wasmtime
sudo apt-get install build-essential
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cd runwasi-wasmtime
make build
make install

configue containerd
edit containerd config(/var/snap/microk8s/4172/args/containerd-template.toml), add 5 line:
    # add 5 line blew
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmedge]
      runtime_type = "io.containerd.wasmedge.v1"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
      runtime_type = "io.containerd.wasmtime.v1"

and the total file is:
# Use config version 2 to enable new configuration fields.
version = 2
oom_score = 0

[grpc]
  uid = 0
  gid = 0
  max_recv_message_size = 16777216
  max_send_message_size = 16777216

[debug]
  address = ""
  uid = 0
  gid = 0

[metrics]
  address = "127.0.0.1:1338"
  grpc_histogram = false

[cgroup]
  path = ""

# The 'plugins."io.containerd.grpc.v1.cri"' table contains all of the server options.
[plugins."io.containerd.grpc.v1.cri"]

  stream_server_address = "127.0.0.1"
  stream_server_port = "0"
  enable_selinux = false
  # sandbox_image = "k8s.gcr.io/pause:3.1"
  sandbox_image = "lank8s.cn/pause:3.7"
  stats_collect_period = 10
  enable_tls_streaming = false
  max_container_log_line_size = 16384

  # 'plugins."io.containerd.grpc.v1.cri".containerd' contains config related to containerd
  [plugins."io.containerd.grpc.v1.cri".containerd]

    # snapshotter is the snapshotter used by containerd.
    snapshotter = "${SNAPSHOTTER}"

    # no_pivot disables pivot-root (linux only), required when running a container in a RamDisk with runc.
    # This only works for runtime type "io.containerd.runtime.v1.linux".
    no_pivot = false

    # default_runtime_name is the default runtime name to use.
    default_runtime_name = "${RUNTIME}"

    # add 5 line blew
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmedge]
      runtime_type = "io.containerd.wasmedge.v1"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
      runtime_type = "io.containerd.wasmtime.v1"

    # 'plugins."io.containerd.grpc.v1.cri".containerd.runtimes' is a map from CRI RuntimeHandler strings, which specify types
    # of runtime configurations, to the matching configurations.
    # In this example, 'runc' is the RuntimeHandler string to match.
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
      runtime_type = "${RUNTIME_TYPE}"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime]
      # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
      runtime_type = "${RUNTIME_TYPE}"

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime.options]
        BinaryName = "nvidia-container-runtime"

   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
      runtime_type = "io.containerd.kata.v2"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
        BinaryName = "kata-runtime"

  # 'plugins."io.containerd.grpc.v1.cri".cni' contains config related to cni
  [plugins."io.containerd.grpc.v1.cri".cni]
    # bin_dir is the directory in which the binaries for the plugin is kept.
    bin_dir = "${SNAP_DATA}/opt/cni/bin"

    # conf_dir is the directory in which the admin places a CNI conf.
    conf_dir = "${SNAP_DATA}/args/cni-network"

  # 'plugins."io.containerd.grpc.v1.cri".registry' contains config related to the registry
  [plugins."io.containerd.grpc.v1.cri".registry]

    # 'plugins."io.containerd.grpc.v1.cri".registry.mirrors' are namespace to mirror mapping for all namespaces.
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
        endpoint = ["https://registry-1.docker.io", ]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:32000"]
        endpoint = ["http://localhost:32000"]

build wasi-demo-app and run it with ctr
cd crates/wasi-demo-app && cargo build --features oci-v1-tar
microk8s ctr image import --all-platforms img.tar
microk8s ctr run --rm --runtime=io.containerd.wasmtime.v1 ghcr.io/containerd/runwasi/wasi-demo-app:latest wasi-demo-app

test wasmedge server code
As I know wasi network standard still on the way, and wasmedge is similar to wasmtime, and second-state/runwasi is a fork of containerd/runwasi, but there is no way to post issue to second-state/runwasi, so the test code below is base on wasmedge
install wasmedge and shims
cd ~
curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash -s -- -p /usr/local
git clone https://github.com/second-state/runwasi.git
cd runwasi
git submodule init
git submodule update
rustup default nightly
make build FEATURES=wasmedge
sudo make install RUNTIME=wasmedge

build hyper-demo and run it with ctr
sudo apt-get install docker-ce
sudo make demo/out/hyper_img.tar
microk8s ctr images --all-platforms import demo/out/hyper_img.tar
microk8s ctr run --rm --net-host --runtime=io.containerd.wasmedge.v1 docker.io/library/hyper-demo:latest testclient /client.wasm

run it with kubectl
microk8s kubectl apply -f wasm.yml

wasm.yml:
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: discuzq
  annotations:
    kubernetes.io/ingress.class: "traefik"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wasmtest
            port:
              number: 3000
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmedge
handler: wasmedge
---
kind: Service
apiVersion: v1
metadata:
  name: wasmtest
  labels:
    name: wasmtest
spec:
  ports:
  - name: wasmtest3000
    protocol: TCP
    port: 3000
  selector:
    app: wasmtest
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: wasmtest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wasmtest
  template:
    metadata:
      labels:
        app: wasmtest
    spec:
      runtimeClassName: wasmedge
      containers:
      - name: wasmtest
        image: docker.io/library/hyper-demo:latest
        imagePullPolicy: Never
        ports:
        - containerPort: 3000

visit 192.168.205.3:8080
got bad gateway

I test the new vesion with k3s and everything works.
https://github.com/containerd/runwasi/issues/52#issuecomment-1418617119

Thanks for sharing!! @defims

I make a pull request #65, so k3s can be easily tested by running make test/k3s

Closing this one as it's documented in https://github.com/containerd/runwasi/pull/66

authors: Mossaka agracey defims squillace

repo: containerd/runwasi


text:
Create podman_ps to ps all containers running on a system

This script looks for all conmon (container monitor) processes running on the host. It then runs a shell executing podman ps $ARG in each one of the user sessions listing the containers that are currently running.

Replaces: https://github.com/containers/podman/pull/18760

@Luap99 @edsantiago @nalind @cevich FYI Moved to examples.

repo: containers/appstore


text:
Add an internal-tests run-privileged-integration

status: Don't error out if not booted
For now, just print out nothing.  This helps a future integration
testing scenario.

Add an internal-tests run-privileged-integration
Add a feature to enable internal tests.  I originally started
by matching
https://github.com/ostreedev/ostree-rs-ext/commit/6543c855580da3a3f2a85bc8b4a294b4c92c2829
but since here the binary is really end user facing and not just
a demo, we shouldn't enable the feature by default.
If in the future we split off the tiny CLI bit out of the workspace,
then we could auto-enable but that seems not worth it.

/approve

/retest

Hmm, need to do some tweaks to the Prow config here; I don't think we want to use approve/lgtm, just CI tests.  (But this is obviously subject to a larger debate for consistency inside the containers/ GH org)

authors: cgwalters jmarrero

repo: containers/bootc


text:
podman health check phase3

podman will not start a transient service and timer for healthchecks.
this handles the tracking of the timing for health checks.
added the 'started' status which represents the time that a container is
in its start-period.
the systemd timing can be disabled with an env variable of
DISABLE_HC_SYSTEMD="true".
added filter for ps where --filter health=[starting, healthy, unhealthy]
can now be used.
Signed-off-by: baude bbaude@redhat.com

i would love for people to play with this some more so I'm putting it up here for review to get more eyes on it.

Once you get the last bits in, a "how healthcheck works in podman" type of blog would be most excellent.

LGTM on my end. @rhatdan @TomSweeneyRedHat @vrothberg PTAL

/lgtm

authors: TomSweeneyRedHat baude mheon rhatdan

repo: containers/libpod


text:
bump(github.com/containers/storage,github.com/containers/image)

Bump github.com/containers/storage and github.com/containers/image, to commits 06b6c2e4cf254f5922a79da058c94ac2a65bb92f and 93bced01015eb94bec4821df1876314be8197680, respectively.
This should incorporate the fixes for manifest digest mismatches that were made for CRI-O in https://github.com/cri-o/cri-o/pull/2066 and https://github.com/cri-o/cri-o/pull/2071.

/approve
LGTM once tests go green

bot, retest this please

Oh dear, it's the 1.0 branch. CI is 100% broken here, the code to actually run Papr was removed on their end.

Need to land #2891 first to fix CI for this branch

@nalind Please rebase and we can merge

Rerunning ubuntu test - seems like it's a flake. Will merge once green.

/lgtm

authors: mheon nalind rhatdan


text:
[Makefile] Ensure .gopathok dependency is met for varlink

When executing make in parallel, e.g make -j8, there is a chance steps are
executed at the same time. There is a chance .gopathok and the actual varlink
generation happening at the same time, causing a race and ultimately failing the
build.
Ensuring the .gopathok dependency is met at the actual step fixes the problem.
Signed-off-by: Morten Linderud morten@linderud.pw

LGTM, nice catch/fix @Foxboron !

LGTM
On Sat, Jan 11, 2020, 10:12 Tom Sweeney notifications@github.com wrote:

LGTM, nice catch/fix @Foxboron https://github.com/Foxboron !
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/pull/4842?email_source=notifications&email_token=AB3AOCG7XAJXEEPVS7QRPMTQ5HOVFA5CNFSM4KFR3QIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWD6MQ#issuecomment-573325106,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3AOCEZLTYB7CPYGVL5G3LQ5HOVFANCNFSM4KFR3QIA
.

/approve

/hold

/lgtm

/hold cancel

authors: Foxboron TomSweeneyRedHat baude mheon


text:
zbus update and a fix

Hi there,
zbus maintainer here. :wave: I wanted to help out a bit with zbus part of this project so providing this PR.

Hi @zeenix , Thank you so much, PR looks good but CI is red.

Hi @zeenix , Thank you so much, PR looks good but CI is red.

Thanks for the quick response. make test was fine on my Fedora machine. I'll check..

Not really? The API process for firewalld is very synchronous - we can't do much while waiting for responses from the server.
Thanks for this, by the way - I've really been neglecting the firewalld/dbus bits of the project.

The main problem with zbus is the MSRV requirement, which makes it impossible to build on stock debian/ubuntu, see https://github.com/containers/netavark/pull/355 and the ubuntu20_build job

Not really? The API process for firewalld is very synchronous - we can't do much while waiting for responses from the server.

Ah ok. There is spawn_blocking API for turning blocking calls to async but I'm not familiar enough with the code to say if that's worth it.

Thanks for this, by the way - I've really been neglecting the firewalld/dbus bits of the project.

No worries.

The main problem with zbus is the MSRV requirement, which makes it impossible to build on stock debian/ubuntu, see #355 and the ubuntu20_build job

Most of the MSRV bumps were not planned ones but we tackled the issue of unintentional bumps a month back. What's left now is to decide how recent an MSRV we can require w/o breaking things for debian. If 6 months old releases are OK then that's good enough for me as well.

The main problem with zbus is the MSRV requirement, which makes it impossible to build on stock debian/ubuntu, see #355 and the ubuntu20_build job

I'm having a bit of difficulty figuring out the latest MSRV that would be good for debian. Could you please let me know which version is that and I'll see if I can port to that version?

For ubuntu 2004 at least it seems to be 1.59 at the moment: https://packages.ubuntu.com/focal/rustc.
Debian stable seems to shippe a much older version with 1.48: https://tracker.debian.org/pkg/rustc.
I don't think we have to support debian given that the version is very old but v1.59 seems reasonable to me.

I don't think we have to support debian given that the version is very old but v1.59 seems reasonable to me.

Agreed and I've a much better chance of succeeding. :) I'll see what I can do.

I briefly looked into what 1.60 features zbus depends on and one that seems impossible to port back from (w/o it being a breaking change) is use of dep: features introduced in cargo 1.60. Any ideas?

I briefly looked into what 1.60 features zbus depends on and one that seems impossible to port back from (w/o it being a breaking change) is use of dep: features introduced in cargo 1.60. Any ideas?

Can we just wait for ubuntu to update the version? Looks like 22.10 ships with rust v1.61 so I guess we could wait and see if they will backport it to the other ubuntu versions as well.

Can we just wait for ubuntu to update the version? Looks like 22.10 ships with rust v1.61 so I guess we could wait and see if they will backport it to the other ubuntu versions as well.

Seems they've done that already. I rebased again my work (was trivial actually) so the Ubuntu20 CI jobs still fails, maybe it needs an update?

oh, I had forgotten that the issue wasn't just that they don't ship Rust 1.60 but rather that they don't ship zbus 3. Since they do have the MSRV for zbus 3, they should be able to upgrade now.

@Luap99 I feel like there is a bit of a chicken&egg situation involved if you want to only depend on rust crates already packaged in the distro.
Wouldn't it be better to leave that problem to distros themselves and just ensure that this project along w/ all its deps can be built with Rust tools available in the distro in question?

@Luap99 I feel like there is a bit of a chicken&egg situation involved if you want to only depend on rust crates already packaged in the distro.
Wouldn't it be better to leave that problem to distros themselves and just ensure that this project along w/ all its deps can be built with Rust tools available in the distro in question?

Wait, the debian/ubuntu cargo install does not use the official crates.io index? Do they only pull from debian sources? If this is the case I agree we should not wait for them. I only care about a to fast moving MSRV.

Hmm, maybe this error is caused by https://github.com/rust-lang/cargo/issues/10623?

The latest version should be 1.61 in ubuntu 2004, however our image is not updating on quay.io? https://quay.io/repository/libpod/ubuntu20rust
@baude PTAL

Wait, the debian/ubuntu cargo install does not use the official crates.io index?

I am not sure about the details but the CI clearly shows that current failure is about too old zbus. Otherwise, we'd have this resolved 22 days ago. :)

Hmm, maybe this error is caused by rust-lang/cargo#10623?

Ah, makes sense.

I only care about a to fast moving MSRV.

As we have it checked in the CI now in zbus, accidental bumps hopefully would never happen anymore and I don't intend to bump to too new MSRV, no matter how appealing a new feature might be. :) I promise you that. :) I think a 6 months grace period is good enough in the Rust world but I'll still first check availability in Ubuntu LTS before bumping.

Yes we should be good in the future, I look into why the quay.io auto builder did not rebuild the image so far.
In any case could you rebase this PR, we no longer use tokio for netlink and just make blocking calls.

In any case could you rebase this PR

Sure.

we no longer use tokio for netlink and just make blocking calls

Interesting.

/lgtm
/approve

Yay!

authors: Luap99 flouthoc mheon zeenix

repo: containers/netavark


text:
feature: add dashboard

feature: add dashboard
What does this PR do?
Adds the following:

A dashboard that lists all the current builds
View current running build container logs
Viewing the completed build log
Deleting one build
Deleting multiple builds / bulk deletion
Be able to click and open the build output directory

Screenshot / video of UI

What issues does this PR fix or reference?

Closes https://github.com/containers/podman-desktop-extension-bootc/issues/196
How to test this PR?

Start a build
View it in the dashboard
Delete the build
Try building another build..
View the logs (click on the log button)
Click on the folder button (should open in default file manager on
your system)

Signed-off-by: Charlie Drage charlie@charliedrage.com

Requires https://github.com/containers/podman-desktop-extension-bootc/pull/192 to be merged (based upon that PR)

Ready for review 👍 @deboer-tim

Ready for another review!
https://github.com/containers/podman-desktop-extension-bootc/assets/6422176/ff791b8a-b464-4c6b-9013-066698f39269
Some notes:

Suggested changes implemented
Progress column now removed
Scope reduced (no more leftover api calls such as "navigate to container")
Keeping it nice and super simple


text:
Add support for CPU hot add/remove

For hot-add, we have to know what CPUs are available using
query-hotpluggable-cpus.
For hot-remove we only need to know the CPUs ids in order to avoid the
use of 1 query 1 cpu, hotplugAddCPUs and hotRemoveCPUs receive the
total amount of CPUs to hot add or hot remove.
depending of the container's state, pod's resources are updated.
for example, if the container has a CPU constraint of 4 vCPU and it is stopped,
then these 4 vCPUs are removed.
another example, if the container is ready to be started and it has a CPU
constraint of 3 vCPUs, 3 vCPUs are added and the constraint is sent to the
agent to limit CPU usage of the container.
With this patch the fractional part of the CPU constraint is also honoured,
for example, if the container has a CPU constraint of 5.5, then 6 vCPUs are
added to the POD and a constraint of 5.5 CPUs is applied to the container
fixes #511
Signed-off-by: Julio Montes julio.montes@intel.com

@devimc CI is not passing here. #589 has been solved, and I don't think #591 is the reason why tests are failing, right ?
Could you please make the tests passing on this PR ?

@sboeuf let me apply #591 and see if that fixes the CI

pssst hey @sboeuf  take a look to the CI

@devimc thx ! I'll do the review !

@devimc is that ready for a new review ?

@sboeuf changes applied, thanks

@sboeuf changes applied, thanks
depends on https://github.com/clearcontainers/packaging/pull/279

@sboeuf I think your design is different than mine, you want to share vCPUs between containers while I don't. Correct me if I''m wrong, but in your design if we have 1 container with a constraint of 2 vCPUs, the VM should have 2 vCPUs, but if a new container is created with a constrain of 3 vCPUs, then only 1 vCPUs will be added, the idea is good but is not the correct solution. In order to don't have containers fighting for the CPU usage, each container should have assigned the number of vCPUs that it needs, we can not exceed the maximum number of actual physical cores because docker and kubernetes validates that before starting the container, if quota/period is greater than the actual number of physical cores the container won't start, also in qemu.go I have a validation to do not exceed the maximum number of vCPUs, in that way when the container is destroyed only its resources are hot removed (if it has any), that means we will not remove CPUs used by other containers neither the runtime will try to remove cold plugged vCPUs.

@sboeuf

Do you realize that we're always going to end up with number_of_CPUs_on_the_VM = coldplugged_CPUs + (container_i * number_of_CPUs_for_container_i) ?

Yes, when a CPU constrain is not specified for a container, then it will use the CPUs cold plugged.

How are we going to handle the constraint of the container process inside the VM so that we won't end up using only the first CPUs (0,1,2 for instance for a second container that needs 3 CPUs, but the first container needed 2 CPUs) ?

Before creating a container, the runtime check if a CPU constraint was specified, if so, then N cpus are hot added and the agent places the container inside a CPU cgroup, containers without CPU constraint have less priority than containers with CPUs constraint. For example, if default_vcpus is 1 and this pod configuration is used:
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu
spec:
  containers:
  - name: container1
    image: vish/stress
    args:
    - -cpus
    - "4"
  - name: container2
    image: vish/stress
    resources:
      limits:
        cpu: "4"
    args:
    - -cpus
    - "4"

both containers container1 and container2 will try to consume 400% of CPU. When container1 is created the VM only have 1 vCPU, hence container1 uses 100% of CPU. When container2 is created, 4 vCPUs are hot added, container2 is placed inside a CPU cgroup, and it consumes 400% of CPU while container1 only 100%

@devimc Ok this is pretty clear, but I thought we had to specify which CPU (0, 1, 2, ..., N) we're gonna use for each container. If the kernel handles the workload on its own, then that's fine to only specify the number of CPU for each process and we don't have to bother with this. Is that right ?
Now, about the coldplugged CPU, I think we can do better here. In case all the containers running will have some CPU constraints, the number of CPUs coldplugged will never be used. We're wasting resources here.
So I'd like that we take into account the number of coldplugged CPUs before we start hotplugging more CPUs. Also, I think that we should handle the non-constrained containers as if they had some CPUs to hotplug. The only way to do that is to define a default amount of CPUs that we expect acceptable to run a non-constrained container.
Does that make sense ?

@sboeuf

I thought we had to specify which CPU (0, 1, 2, ..., N) we're gonna use for each container.

when I started with this, I thought the same, but that is not needed because the kernel automatically runs the workload in N vCPUs. Also we cannot decide what vCPUs the container have to use, the user can decide this docker --cpuset-cpus(in another PR I'll add support for this option).

If the kernel handles the workload on its own, then that's fine to only specify the number of CPU for each process and we don't have to bother with this. Is that right ?

that's correct.

Now, about the coldplugged CPU, I think we can do better here. In case all the containers running will have some CPU constraints, the number of CPUs coldplugged will never be used. We're wasting resources here.

It depends, to deal with this limitation, in https://github.com/clearcontainers/runtime/pull/1041 I'm changing default_vcpus to 1, this vCPU can be used for other processes, remember that our containers are not running alone in the VM, we have other process running, like the kernel, systemd(journal, etc) and the agent.
I agree with you, if the user changes default_vcpus to a number greater than 1, then we will be wasting resources, for that reason I'll document this in https://github.com/clearcontainers/runtime/pull/1041

So I'd like that we take into account the number of coldplugged CPUs before we start hotplugging more CPUs. Also,

and we do, these coldplugged vCPUs are used by containers without CPU constraints, it's up to the user decides the resources available for the containers without a CPU constraint.

I think that we should handle the non-constrained containers as if they had some CPUs to hotplug. The only way to do that is to define a default amount of CPUs that we expect acceptable to run a non-constrained container.

In runC, if containers don't have a CPU constraint, they will try to consume all the resources needed to complete theirs task, they will compete for the resources. Cold plugged vCPUs are used and shared between  the containers without CPU constraint, if the user want to give more priority to one container over these resources, He/She can use docker --cpu-shares (I'll add support for this option in other PR)

Following our discussion on IRC with @devimc, the change looks good and can now be merged as long as we document very well all the behavior we expect with unconstrained vs constrained containers.
LGTM

@devimc please take a look why this is failing so that we can move forward and get this merged ;)

authors: devimc sboeuf

repo: containers/virtcontainers


text:
Custom error pages doesn't work for a Marathon app

Do you want to request a feature or report a bug?
Bug
What did you do?
Deployed a Marathon app with following configuration:
traefik.enable: true
traefik.frontend.rule: Host:example.com
traefik.protocol: http
traefik.backend.healthcheck.path: /health
traefik.frontend.entryPoints: http
traefik.backend.loadbalancer.method: drr
traefik.frontend.errors.rapi.query: "/"
traefik.frontend.errors.rapi.backend: -api-json-errors
traefik.frontend.errors.rapi.status: 500-599

furthermore I've deployed added another Marathon app for handling errors.
What did you expect to see?
The main app is scaled to 0 instances, thus there no backend available to handle requests. I'd expect Traefik to handle request with the error handling backend: backend-api-json-errors.
What did you see instead?
time="2018-10-10T19:48:20Z" level=error msg="Caught HTTP Status Code 503, returning error page"
time="2018-10-10T19:48:20Z" level=debug msg="Reporting span 6dd11af5a0cce03d:13a5eb1db3b05976:6dd11af5a0cce03d:1"
time="2018-10-10T19:48:20Z" level=error msg="Recovered from panic in http handler: runtime error: invalid memory address or nil pointer dereference"

Output of traefik version: (What version of Traefik are you using?)
Version:      v1.7.1
Codename:     maroilles
Go version:   go1.11
Built:        2018-09-28_10:24:34PM
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?

{
 "LifeCycle": {
  "RequestAcceptGraceTimeout": 0,
  "GraceTimeOut": 0
 },
 "GraceTimeOut": 0,
 "Debug": false,
 "CheckNewVersion": true,
 "SendAnonymousUsage": false,
 "AccessLogsFile": "",
 "AccessLog": {
  "file": "/var/log/traefik/traefik.log",
  "format": "common"
 },
 "TraefikLogsFile": "",
 "TraefikLog": null,
 "Tracing": {
  "Backend": "jaeger",
  "ServiceName": "traefik",
  "SpanNameLimit": 0,
  "Jaeger": null,
  "Zipkin": null,
  "DataDog": null
 },
 "LogLevel": "DEBUG",
 "EntryPoints": {
  "api": {
   "Address": "xxxx",
   "TLS": null,
   "Redirect": null,
   "Auth": null,
   "WhitelistSourceRange": null,
   "WhiteList": null,
   "Compress": false,
   "ProxyProtocol": null,
   "ForwardedHeaders": null
  },
  "http": {
   "Address": "xxxx",
   "TLS": null,
   "Redirect": null,
   "Auth": null,
   "WhitelistSourceRange": null,
   "WhiteList": null,
   "Compress": true,
   "ProxyProtocol": null,
   "ForwardedHeaders": null
  },
  "ping": {
   "Address": "xxxx",
   "TLS": null,
   "Redirect": null,
   "Auth": null,
   "WhitelistSourceRange": null,
   "WhiteList": null,
   "Compress": false,
   "ProxyProtocol": null,
   "ForwardedHeaders": null
  }
 },
 "Cluster": null,
 "Constraints": [],
 "ACME": null,
 "DefaultEntryPoints": [
  "http"
 ],
 "ProvidersThrottleDuration": 2000000000,
 "MaxIdleConnsPerHost": 200,
 "IdleTimeout": 0,
 "InsecureSkipVerify": false,
 "RootCAs": null,
 "Retry": {
  "Attempts": 0
 },
 "HealthCheck": {
  "Interval": 30000000000
 },
 "RespondingTimeouts": {
  "ReadTimeout": 0,
  "WriteTimeout": 0,
  "IdleTimeout": 180000000000
 },
 "ForwardingTimeouts": null,
 "AllowMinWeightZero": false,
 "Web": null,
 "Docker": null,
 "File": {
  "Watch": true,
  "Filename": "/etc/traefik/rules.toml",
  "Constraints": null,
  "Trace": false,
  "TemplateVersion": 0,
  "DebugLogGeneratedTemplate": false,
  "Directory": "",
  "TraefikFile": ""
 },
 "Marathon": {
  "Watch": false,
  "Filename": "",
  "Constraints": null,
  "Trace": false,
  "TemplateVersion": 0,
  "DebugLogGeneratedTemplate": false,
  "Endpoint": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "Domain": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "ExposedByDefault": false,
  "GroupsAsSubDomains": false,
  "DCOSToken": "",
  "MarathonLBCompatibility": false,
  "FilterMarathonConstraints": false,
  "TLS": null,
  "DialerTimeout": 60000000000,
  "ResponseHeaderTimeout": 60000000000,
  "TLSHandshakeTimeout": 5000000000,
  "KeepAlive": 10000000000,
  "ForceTaskHostname": false,
  "Basic": null,
  "RespectReadinessChecks": true
 },
 "Consul": null,
 "ConsulCatalog": null,
 "Etcd": null,
 "Zookeeper": null,
 "Boltdb": null,
 "Kubernetes": null,
 "Mesos": null,
 "Eureka": null,
 "ECS": null,
 "Rancher": null,
 "DynamoDB": null,
 "ServiceFabric": null,
 "Rest": null,
 "API": {
  "EntryPoint": "api",
  "Dashboard": true,
  "Debug": false,
  "CurrentConfigurations": null,
  "Statistics": null,
  "DashboardAssets": null
 },
 "Metrics": {
  "Prometheus": {
   "Buckets": [
    0.1,
    0.3,
    1.2,
    5
   ],
   "EntryPoint": "api"
  },
  "Datadog": null,
  "StatsD": null,
  "InfluxDB": null
 },
 "Ping": {
  "EntryPoint": "ping"
 },
 "HostResolver": null,
 "ConfigFile": "/etc/traefik/traefik.toml"
}

Here's a stacktrace of failing request:
time="2018-10-18T09:33:48Z" level=error msg="Caught HTTP Status Code 503, returning error page"
time="2018-10-18T09:33:48Z" level=error msg="Recovered from panic in HTTP handler [127.0.0.1:38036 - /health]: runtime error: invalid memory address or nil pointer dereference"
time="2018-10-18T09:33:48Z" level=error msg="Stack: goroutine 6859 [running]:\ngithub.com/containous/traefik/middlewares.recoverFunc(0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/middlewares/recover.go:40 +0x1b7\npanic(0x21d58a0, 0x4530f40)\n\t/usr/local/go/src/runtime/panic.go:513 +0x1b9\ngithub.com/containous/traefik/middlewares.(*Retry).ServeHTTP(0xc000cbf860, 0x7fc743112168, 0xc0001ac960, 0xc000135c00)\n\t/go/src/github.com/containous/traefik/middlewares/retry.go:38 +0x5e8\ngithub.com/containous/traefik/middlewares/tracing.(*HTTPHandlerWrapper).ServeHTTP(0xc000cbf890, 0x7fc743112168, 0xc0001ac960, 0xc000135c00)\n\t/go/src/github.com/containous/traefik/middlewares/tracing/wrapper.go:63 +0xd5\ngithub.com/containous/traefik/middlewares/errorpages.(*Handler).ServeHTTP(0xc0003898f0, 0x7fc743112078, 0xc0001ac920, 0xc000135600, 0xc000943a80)\n\t/go/src/github.com/containous/traefik/middlewares/errorpages/error_pages.go:102 +0x867\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2935200, 0xc0003898f0, 0xc0010e0960, 0x7fc743112078, 0xc0001ac920, 0xc000135600)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.(*Negroni).ServeHTTP(0xc000cbff20, 0x7fc743112118, 0xc000cd1300, 0xc000135600)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:81 +0xee\ngithub.com/containous/traefik/vendor/github.com/containous/mux.(*Router).ServeHTTP(0xc0007c8300, 0x7fc743112118, 0xc000cd1300, 0xc000135600)\n\t/go/src/github.com/containous/traefik/vendor/github.com/containous/mux/mux.go:133 +0xf1\ngithub.com/containous/traefik/middlewares.(*HandlerSwitcher).ServeHTTP(0xc00000c008, 0x7fc743112118, 0xc000cd1300, 0xc0005fbf00)\n\t/go/src/github.com/containous/traefik/middlewares/handlerSwitcher.go:24 +0x6f\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.Wrap.func1(0x7fc743112118, 0xc000cd1300, 0xc0005fbf00, 0xc000943a60)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:41 +0x4d\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.HandlerFunc.ServeHTTP(0xc000962600, 0x7fc743112118, 0xc000cd1300, 0xc0005fbf00, 0xc000943a60)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:24 +0x4e\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2939e00, 0xc000962600, 0xc000962700, 0x7fc743112118, 0xc000cd1300, 0xc0005fbf00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x7fc743112118, 0xc000cd1300, 0xc0005fbf00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\nnet/http.HandlerFunc.ServeHTTP(0xc000943a40, 0x7fc743112118, 0xc000cd1300, 0xc0005fbf00)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\ngithub.com/containous/traefik/middlewares.(*RequestHost).ServeHTTP(0x45711d0, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00, 0xc000943a40)\n\t/go/src/github.com/containous/traefik/middlewares/request_host.go:20 +0x1ec\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2935020, 0x45711d0, 0xc0009626e0, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\nnet/http.HandlerFunc.ServeHTTP(0xc000943a20, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\ngithub.com/containous/traefik/vendor/github.com/NYTimes/gziphandler.GzipHandlerWithOpts.func1.1(0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/NYTimes/gziphandler/gzip.go:292 +0x263\nnet/http.HandlerFunc.ServeHTTP(0xc000a91950, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\ngithub.com/containous/traefik/middlewares.(*Compress).ServeHTTP(0x45711d0, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00, 0xc000943a20)\n\t/go/src/github.com/containous/traefik/middlewares/compress.go:21 +0xe1\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2934f20, 0x45711d0, 0xc0009626c0, 0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x7fc743112118, 0xc000cd1300, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\ngithub.com/containous/traefik/vendor/github.com/thoas/stats.(*Stats).ServeHTTP(0xc00095e120, 0x294c000, 0xc0009439e0, 0xc0005fbe00, 0xc000943a00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/thoas/stats/stats.go:64 +0xc2\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2936f80, 0xc00095e120, 0xc0009626a0, 0x294c000, 0xc0009439e0, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x294c000, 0xc0009439e0, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\ngithub.com/containous/traefik/middlewares.(*metricsMiddleware).ServeHTTP(0xc00096e000, 0x294c040, 0xc000943920, 0xc0005fbe00, 0xc000943940)\n\t/go/src/github.com/containous/traefik/middlewares/metrics.go:66 +0x2fc\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x29350e0, 0xc00096e000, 0xc000962680, 0x294c040, 0xc000943920, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x294c040, 0xc000943920, 0xc0005fbe00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\nnet/http.HandlerFunc.ServeHTTP(0xc000943860, 0x294c040, 0xc000943920, 0xc0005fbe00)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\ngithub.com/containous/traefik/middlewares/accesslog.(*LogHandler).ServeHTTP(0xc00087d1d0, 0x7fc7431120e8, 0xc0001ac8f8, 0xc0005fbd00, 0xc000943860)\n\t/go/src/github.com/containous/traefik/middlewares/accesslog/logger.go:181 +0xba9\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2935120, 0xc00087d1d0, 0xc000962660, 0x7fc7431120e8, 0xc0001ac8f8, 0xc0005fbd00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x7fc7431120e8, 0xc0001ac8f8, 0xc0005fbd00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\ngithub.com/containous/traefik/middlewares/tracing.(*entryPointMiddleware).ServeHTTP(0xc0009620c0, 0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00, 0xc0009437e0)\n\t/go/src/github.com/containous/traefik/middlewares/tracing/entrypoint.go:36 +0x44e\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x29352a0, 0xc0009620c0, 0xc000962640, 0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP-fm(0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x60\nnet/http.HandlerFunc.ServeHTTP(0xc0009437c0, 0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\ngithub.com/containous/traefik/middlewares.NegroniRecoverHandler.func1(0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00, 0xc0009437c0)\n\t/go/src/github.com/containous/traefik/middlewares/recover.go:24 +0x87\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.HandlerFunc.ServeHTTP(0x2702070, 0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00, 0xc0009437c0)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:24 +0x4e\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.middleware.ServeHTTP(0x2939e00, 0x2702070, 0xc000962620, 0x7fc743112078, 0xc0001ac8d8, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:33 +0x9c\ngithub.com/containous/traefik/vendor/github.com/urfave/negroni.(*Negroni).ServeHTTP(0xc0003064b0, 0x295bcc0, 0xc00108cee0, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/urfave/negroni/negroni.go:81 +0xee\ngithub.com/containous/traefik/vendor/github.com/containous/mux.(*Router).ServeHTTP(0xc00095e1e0, 0x295bcc0, 0xc00108cee0, 0xc0005fbc00)\n\t/go/src/github.com/containous/traefik/vendor/github.com/containous/mux/mux.go:133 +0xf1\ngithub.com/containous/traefik/h2c.Server.Serve.func1(0x295bcc0, 0xc00108cee0, 0xc0005fb600)\n\t/go/src/github.com/containous/traefik/h2c/h2c.go:78 +0x409\nnet/http.HandlerFunc.ServeHTTP(0xc000978020, 0x295bcc0, 0xc00108cee0, 0xc0005fb600)\n\t/usr/local/go/src/net/http/server.go:1964 +0x44\nnet/http.serverHandler.ServeHTTP(0xc0009680d0, 0x295bcc0, 0xc00108cee0, 0xc0005fb600)\n\t/usr/local/go/src/net/http/server.go:2741 +0xab\nnet/http.(*conn).serve(0xc00067f360, 0x295e140, 0xc000cd1040)\n\t/usr/local/go/src/net/http/server.go:1847 +0x646\ncreated by net/http.(*Server).Serve\n\t/usr/local/go/src/net/http/server.go:2851 +0x2f5\n"
time="2018-10-18T09:34:40Z" level=info msg="Skipping same configuration for provider marathon"

Could you try this image ldez/traefik:retry

With the provided image it seems to be working:
time="2018-10-18T22:09:59Z" level=error msg="Caught HTTP Status Code 503, returning error page"

Closed by #4075.

authors: deric ldez traefiker

repo: containous/traefik


text:
DNS challenge with ACME-DNS certificate provider always fails with wildcard domains

Do you want to request a feature or report a bug?
Bug
What did you do?
To enable HTTPs on internal systems of my company, we set up an acme-dns reverse proxy server. I configured a certificate provider in Traefik with dns challenge type acme-dns. As we work heavily with subdomains, I configured some Traefik http routers of our Docker containers with a wildcard sans domain and main base domain, as described here.
Additionally i configured the acme-dns account information with the account data I had from a manual dns registration.
What did you expect to see?
The https secured internal websites should use a valid certificate provided by Let's Encrypt.
What did you see instead?
The websites used the Traefik default certificate, generated on container startup. Taking a look into the Traefik logs showed me failing dns challenges, the expected token could not be found in the DNS TXT record of my domain.
Taking a look into the internet accessible DNS information (e.g. as here) showed that the TXT record was successfully created.
The TXT record looked for example as follows:
XB48qJflIZ1X8PNO0UiRPeBpapaStxhzHYWJ1XgJ0sQ
nt-UaHpPSYv0BfCEMgzqm1UjDoNZfamCghFQiGNJWQA

Traefik logged it was searching for XB48qJflIZ1X8PNO0UiRPeBpapaStxhzHYWJ1XgJ0sQ (the first part of the TXT record) but found nt-UaHpPSYv0BfCEMgzqm1UjDoNZfamCghFQiGNJWQA (the second part of the TXT record after
) instead. For me this looks like the acme-dns provider just would have to check the correct part of the TXT record to validate the domain.
Output of traefik version: (What version of Traefik are you using?)
Version:      2.1.1
Codename:     cantal
Go version:   go1.13.5
Built:        2019-12-12T19:01:37Z
OS/Arch:      linux/amd64

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

services:
  traefik:
    image: traefik:2.1
    command: >
      --entryPoints.https.address=:443
      --providers.docker
      --providers.docker.network=webgateway
      --providers.docker.exposedbydefault=false
      --api
      --certificatesresolvers.test
      --certificatesresolvers.test.acme.dnschallenge
      --certificatesresolvers.test.acme.dnschallenge.provider=acme-dns
      --certificatesresolvers.test.acme.email=XXX@YYYY.ZZZZ
      --certificatesresolvers.test.acme.storage=/etc/traefik-certs/acme.json
      --certificatesresolvers.test.acme.keytype=RSA4096
      --log
      --log.level=INFO
      --log.format=json
    restart: always
    ports:
      - "443:443"
    environment:
      ACME_DNS_API_BASE: https://INTERNAL-ACME-DNS-SERVER-ADRESS
      ACME_DNS_STORAGE_PATH: /etc/traefik-certs/acme-dns.json
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${CERT_STORAGE_PATH}:/etc/traefik-certs
    networks:
      webgateway:
    labels:
      traefik.enable: true
      traefik.http.routers.traefik.rule: Host(`${BASE_DOMAIN}`) && ( PathPrefix(`/api`) || PathPrefix(`/dashboard`) )
      traefik.http.routers.traefik.service: "api@internal"
      traefik.http.routers.traefik.tls.certresolver: test
      traefik.http.routers.traefik.tls.domains[0].main: ${BASE_DOMAIN}
      traefik.http.routers.traefik.tls.domains[0].sans: "*.${BASE_DOMAIN}"
      traefik.http.routers.traefik.entrypoints: https

networks:
  webgateway:
    name: webgateway

Additional information: using the acme.sh script on the same domain with same account configuration could obtain a valid certificate from Let's Encrypt.
Log output of current failure reproduction:
time="2020-01-08T14:41:38Z" level=info msg="Configuration loaded from flags."
{"level":"info","msg":"Traefik version 2.1.2 built on 2020-01-07T18:23:57Z","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Static configuration loaded {\"global\":{\"checkNewVersion\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"https\":{\"address\":\":443\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{}}},\"providers\":{\"providersThrottleDuration\":2000000000,\"docker\":{\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}`)\",\"network\":\"webgateway\",\"swarmModeRefreshSeconds\":15000000000}},\"api\":{\"dashboard\":true},\"log\":{\"level\":\"DEBUG\",\"format\":\"json\"},\"certificatesResolvers\":{\"test\":{\"acme\":{\"email\":\"profil@data-experts.de\",\"caServer\":\"https://acme-v02.api.letsencrypt.org/directory\",\"storage\":\"/etc/traefik-certs/acme.json\",\"keyType\":\"RSA4096\",\"dnsChallenge\":{\"provider\":\"acme-dns\"}}}}}","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"\nStats collection is disabled.\nHelp us improve Traefik by turning this feature on :)\nMore details on: https://docs.traefik.io/v2.0/contributing/data-collection/\n","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"Starting provider aggregator.ProviderAggregator {}","time":"2020-01-08T14:41:38Z"}
{"entryPointName":"https","level":"debug","msg":"Start TCP Server","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"Starting provider *docker.Provider {\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}`)\",\"network\":\"webgateway\",\"swarmModeRefreshSeconds\":15000000000}","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"Starting provider *acme.Provider {\"email\":\"XXX@YYY.ZZZ\",\"caServer\":\"https://acme-v02.api.letsencrypt.org/directory\",\"storage\":\"/etc/traefik-certs/acme.json\",\"keyType\":\"RSA4096\",\"dnsChallenge\":{\"provider\":\"acme-dns\"},\"ResolverName\":\"test\",\"store\":{},\"ChallengeStore\":{}}","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"Testing certificate renew...","providerName":"test.acme","time":"2020-01-08T14:41:38Z"}
{"level":"info","msg":"Starting provider *traefik.Provider {}","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Configuration received from provider test.acme: {\"http\":{},\"tls\":{}}","providerName":"test.acme","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Configuration received from provider internal: {\"http\":{\"services\":{\"api\":{},\"dashboard\":{}}},\"tcp\":{},\"tls\":{}}","providerName":"internal","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"No default certificate, generating one","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Provider connection established with docker 19.03.5 (API 1.40)","providerName":"docker","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Configuration received from provider docker: {\"http\":{},\"tcp\":{}}","providerName":"docker","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Provider event received {Status:start ID:d3e568d1c96241c01f623b7d8c244af6fa94356028046c232a4e863c819b5946 From:traefik:2.1 Type:container Action:start Actor:{ID:d3e568d1c96241c01f623b7d8c244af6fa94356028046c232a4e863c819b5946 Attributes:map[com.docker.compose.config-hash:b79f73264b9211e72fd1038a91c12fba09cf0e5a42ae174eb2e1a7fbca2b965b com.docker.compose.container-number:1 com.docker.compose.oneoff:False com.docker.compose.project:ceres com.docker.compose.project.config_files:docker-compose.yaml com.docker.compose.project.working_dir:/home/ceres com.docker.compose.service:traefik com.docker.compose.version:1.25.0 image:traefik:2.1 name:ceres_traefik_1 org.opencontainers.image.description:A modern reverse-proxy org.opencontainers.image.documentation:https://docs.traefik.io org.opencontainers.image.title:Traefik org.opencontainers.image.url:https://traefik.io org.opencontainers.image.vendor:Containous org.opencontainers.image.version:v2.1.2 traefik.enable:True traefik.http.routers.traefik.entrypoints:https traefik.http.routers.traefik.rule:Host(`staging.ceres.data-experts.net`) \u0026\u0026 ( PathPrefix(`/api`) || PathPrefix(`/dashboard`) ) traefik.http.routers.traefik.service:api@internal traefik.http.routers.traefik.tls.certresolver:test traefik.http.routers.traefik.tls.domains[0].main:staging.ceres.data-experts.net traefik.http.routers.traefik.tls.domains[0].sans:*.staging.ceres.data-experts.net]} Scope:local Time:1578494498 TimeNano:1578494498714568105}","providerName":"docker","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"Configuration received from provider docker: {\"http\":{\"routers\":{\"traefik\":{\"entryPoints\":[\"https\"],\"service\":\"api@internal\",\"rule\":\"Host(`staging.ceres.data-experts.net`) \\u0026\\u0026 ( PathPrefix(`/api`) || PathPrefix(`/dashboard`) )\",\"tls\":{\"certResolver\":\"test\",\"domains\":[{\"main\":\"staging.ceres.data-experts.net\",\"sans\":[\"*.staging.ceres.data-experts.net\"]}]}}},\"services\":{\"traefik-ceres\":{\"loadBalancer\":{\"servers\":[{\"url\":\"http://172.18.0.2:80\"}],\"passHostHeader\":true}}}},\"tcp\":{}}","providerName":"docker","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"No default certificate, generating one","time":"2020-01-08T14:41:38Z"}
{"level":"debug","msg":"No default certificate, generating one","time":"2020-01-08T14:41:38Z"}
{"entryPointName":"https","level":"debug","middlewareName":"tracing","middlewareType":"TracingForwarder","msg":"Added outgoing tracing middleware api@internal","routerName":"traefik@docker","time":"2020-01-08T14:41:40Z"}
{"entryPointName":"https","level":"debug","middlewareName":"traefik-internal-recovery","middlewareType":"Recovery","msg":"Creating middleware","time":"2020-01-08T14:41:40Z"}
{"level":"debug","msg":"No default certificate, generating one","time":"2020-01-08T14:41:40Z"}
{"level":"debug","msg":"Looking for provided certificate(s) to validate [\"staging.ceres.data-experts.net\" \"*.staging.ceres.data-experts.net\"]...","providerName":"test.acme","time":"2020-01-08T14:41:41Z"}
{"level":"debug","msg":"Domains [\"staging.ceres.data-experts.net\" \"*.staging.ceres.data-experts.net\"] need ACME certificates generation for domains \"staging.ceres.data-experts.net,*.staging.ceres.data-experts.net\".","providerName":"test.acme","time":"2020-01-08T14:41:41Z"}
{"level":"debug","msg":"Loading ACME certificates [staging.ceres.data-experts.net *.staging.ceres.data-experts.net]...","providerName":"test.acme","time":"2020-01-08T14:41:41Z"}
{"level":"debug","msg":"Building ACME client...","providerName":"test.acme","time":"2020-01-08T14:41:41Z"}
{"level":"debug","msg":"https://acme-v02.api.letsencrypt.org/directory","providerName":"test.acme","time":"2020-01-08T14:41:41Z"}
{"level":"debug","msg":"Using DNS Challenge provider: acme-dns","providerName":"test.acme","time":"2020-01-08T14:41:42Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net, *.staging.ceres.data-experts.net] acme: Obtaining bundled SAN certificate","time":"2020-01-08T14:41:42Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2178466231","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2178466232","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: use dns-01 solver","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Could not find solver for: tls-alpn-01","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Could not find solver for: http-01","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: use dns-01 solver","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Preparing to solve DNS-01","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Preparing to solve DNS-01","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Trying to solve DNS-01","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Checking DNS record propagation using [127.0.0.11:53]","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] Wait for propagation [timeout: 1m0s, interval: 2s]","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:43Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:45Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:47Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:49Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:51Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:53Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:55Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:57Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:41:59Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:01Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:03Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:05Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:07Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:09Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:11Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:13Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:15Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:17Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:19Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:21Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:23Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:25Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:27Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:29Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:31Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:33Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:35Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:37Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:39Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:41Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Trying to solve DNS-01","time":"2020-01-08T14:42:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Checking DNS record propagation using [127.0.0.11:53]","time":"2020-01-08T14:42:43Z"}
{"level":"debug","msg":"legolog: [INFO] Wait for propagation [timeout: 1m0s, interval: 2s]","time":"2020-01-08T14:42:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:45Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:47Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:49Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:51Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:53Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:55Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:57Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:42:59Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:01Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:03Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:05Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:07Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:09Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:11Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:13Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:15Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:17Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:19Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:21Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:23Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:25Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:27Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:29Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:31Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:33Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:35Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:37Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:39Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Waiting for DNS record propagation.","time":"2020-01-08T14:43:41Z"}
{"level":"debug","msg":"legolog: [INFO] [*.staging.ceres.data-experts.net] acme: Cleaning DNS-01 challenge","time":"2020-01-08T14:43:43Z"}
{"level":"debug","msg":"legolog: [INFO] [staging.ceres.data-experts.net] acme: Cleaning DNS-01 challenge","time":"2020-01-08T14:43:43Z"}
{"level":"debug","msg":"legolog: [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2178466231","time":"2020-01-08T14:43:43Z"}
{"level":"debug","msg":"legolog: [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2178466232","time":"2020-01-08T14:43:44Z"}
{"level":"error","msg":"Unable to obtain ACME certificate for domains \"staging.ceres.data-experts.net,*.staging.ceres.data-experts.net\" : unable to generate a certificate for the domains [staging.ceres.data-experts.net *.staging.ceres.data-experts.net]: acme: Error -\u003e One or more domains had a problem:\n[*.staging.ceres.data-experts.net] time limit exceeded: last error: NS 000-w16-dc01.nlberlin.deg.local. did not return the expected TXT record [fqdn: staging.ceres.data-experts.de., value: nt-UaHpPSYv0BfCEMgzqm1UjDoNZfamCghFQiGNJWQA]: \n[staging.ceres.data-experts.net] time limit exceeded: last error: NS 000-w16-dc01.nlberlin.deg.local. did not return the expected TXT record [fqdn: staging.ceres.data-experts.de., value: XB48qJflIZ1X8PNO0UiRPeBpapaStxhzHYWJ1XgJ0sQ]: \n","providerName":"test.acme","time":"2020-01-08T14:43:44Z"}

Hello,
Thank you for this detailed report, but unfortunately without any logs is pretty difficult to help you.

Hello @ldez ,
I could reproduce the problem on another internal staging system and appended my current logs. As you might recognize, Traefik version changed from version 2.1.1 to 2.1.2.
With best regards,
Marcus

I also have the same issue. One thing I noticed is that there were 2 TXT records (with different values) created during the process.

One thing I noticed is that there were 2 TXT records (with different values) created during the process.

It's expected: one for the wildcard (*.exmaple.com), one the root domain (exmaple.com)
Could you open an issue on https://github.com/go-acme/lego

thanks for the confirmation @ldez  I turned on the debug mode and found the similar message.
In my case,  I suspected some kind of race condition and maybe some issue with the DNS resolver. So I tried the following and it actually worked. Hope it will help others.
- "--certificatesresolvers.mydnschallenge.acme.dnschallenge.resolvers=8.8.8.8:53"
- "--certificatesresolvers.mydnschallenge.acme.dnschallenge.delayBeforeCheck=5"

for provider: cloudflare. delayBeforeCheck=5 fix the issue.

In my case using dreamhost I've added resolvers: '8.8.8.8:53 and also just waited. It seems that dreamhost is so sloooow, 47min to validate the first recorrd and 21min to validate wildcard record :(
Hope it will help someone too.

I'm not sure I got the `--certificatesresolvers.myresolver.acme.dnschallenge.resolvers' option right, but I think this is the DNS server where Lets Encrypt looks for the TXT record.
So if I set the option to the IP address from my my domain registrar DNS Server  (in my case 	185.181.104.74 for inwx.de Nameserver )  plus the delayBeforeCheck option to 100, it works perfectly.

Hi! I'm Træfiker :robot: the bot in charge of tidying up the issues.
I have to close this one because of its lack of activity :disappointed:
Feel free to re-open it or join our Community Forum.

authors: Persi chuanma ldez oceanBT skjoher traefiker vladdancer


text:
Allow insecure-registries

Hey everyone, it seems like this container doesn't provide any way to trust self-signed certificates. In my case we have an internal GitLab server with it's own docker repository and I'm getting the following error in my logs:
failed to configure transport: error pinging v2 registry: Get "https://private-gitlab.company.lan:5555/v2/": tls: failed to verify certificate: x509: certificate signed by unknown authority
On my host I have the following /etc/docker/daemon.json:
{
...
  "insecure-registries" : ["private-gitlab.company.lan:5555"],
...
}

On my non-swarm Docker server where I use watchtower it works just fine, maybe that helps finding the solution.
I already tried working around the issue using "DOCKER_OPTS" like so but it didn't seem to help:
...
    environment:
      DOCKER_OPTS: --insecure-registry=private-gitlab.company.lan:5555
...
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - docker-conf:/root/.docker:ro

Am I missing something or is this currently not supported? Is there a workaround?
Best regards

the insecure registry is "HTTP" method, self-signed certificate likely needs to mount the certificate into docker container https://docs.docker.com/engine/security/certificates/

I hate to be that guy but I think you got that wrong:
An insecure registry is either not using TLS (i.e., listening on plain text HTTP), or is using TLS with a CA certificate not known by the Docker daemon

Docker docs #insecure-registries
Your mentioned link also says
On Linux any root certificates authorities are merged with the system defaults, including the host's root CA set. If you are running Docker on Windows Server, or Docker Desktop for Windows with Windows containers, the system default certificates are only used when no custom root certificates are configured.

I added the certificate on the host where the container is running. From there I can curl the server just fine without any certificate warning. It also works using the watchtower container but that unfortunately doesn't support swarm

I hate to be that guy but I think you got that wrong:
An insecure registry is either not using TLS (i.e., listening on plain text HTTP), or is using TLS with a CA certificate not known by the Docker daemon

Ah ok, I'm really wrong assuming insecure is HTTP, my bad.

Docker docs #insecure-registries
Your mentioned link also says
On Linux any root certificates authorities are merged with the system defaults, including the host's root CA set. If you are running Docker on Windows Server, or Docker Desktop for Windows with Windows containers, the system default certificates are only used when no custom root certificates are configured.

I added the certificate on the host where the container is running. From there I can curl the server just fine without any certificate warning. It also works using the watchtower container but that unfortunately doesn't support swarm

Yes, if the docker "on the host". If the docker inside container like shepherd did, that mean no way to read certificate.
You keep mentioning watchtower, I assume this as ignoring ssl error "skip TLS verify"? Maybe Im just dead wrong. Then watchtower implementation is different level from shepherd. As shepherd basically just automate "docker service update", so when docker cant read the read the certs it basically docker daemon that spits the error. Then this leading me to assume need to mount the certificate to shepherd.

Oh, I thought that when mapping /var/run/docker.sock it would use the host's docker. Seems like I got that wrong. Thanks for pointing me in the right direction :)
I got certificates working like this:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro # mount host ca-certificates to container
      - docker-conf:/root/.docker:ro

It still didn't update though so I switched from mounting docker-conf:/root/.docker to using REGISTRY_HOST, REGISTRY_USER and REGISTRY_PASSWORD. I don't like that it logs in again on every interval but now it seems to update just fine.
For anyone else encountering this, my full compose file looks like this:
version: '3.8'

services:
  shepherd:
    image: containrrr/shepherd
    environment:
      FILTER_SERVICES: label=shepherd.autoupdate
      IMAGE_AUTOCLEAN_LIMIT: 3
      REGISTRY_HOST: https:/private-gitlab.company.lan/
      REGISTRY_USER: docker-swarm
      REGISTRY_PASSWORD: iwonttellyoumypassword
      SLEEP_TIME: 1m
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
    deploy:
      mode: replicated
      replicas: 1
      resources:
        limits:
          cpus: '1'
          memory: 1G
      placement:
        constraints:
          - node.role == manager

Yes, it use host docker to connect, but thats it, the additional files that needed like your cert doesnt exist inside container.

repo: containrrr/shepherd


text:
Fixes HMS-3020: Adding VNC geometry

HMS-3020
Relates to https://github.com/RHEnVision/provisioning-backend/pull/751 , https://github.com/osbuild/image-builder/pull/901

@swadeley

https://issues.redhat.com/browse/HMS-HMS-3020

/test

https://issues.redhat.com/browse/HMS-3020

authors: akhil-jha jlsherrill mshriver


text:
Add option to specify when original or monkey patched version is run

It would be nice if you could say you want the stand in version to run on invocations 1, 3, 4, etc. And in other cases, the original function would execute.

This will be closed by #19. We are going to provide a start and stop point, along with the times the stand in has been invoked. Anything beyond that can be done in user logic.

repo: continuationlabs/stand-in


text:
VNF pods CrashLoopBackOff

Hello,
After deploying contiv vpp with vagrant an deploying the SFC controller following the demo example. The deployed VNFs (1 to 4) from the example always result in a CrashLoopBackOff.
Is this related to the VNFs YAML files or what please?

SFC controller demo is now superseded by SFC functionality built into Contiv-VPP CNI itself. Still work in progress, but already does something. Take a look at https://github.com/contiv/vpp/tree/master/k8s/examples/sfc

authors: AdelBouridah rastislavszabo

repo: contiv/vpp