text:
Bump to 0.0.6

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: AntoinePrv conda-forge-linter


text:
Add ijpulidos and mikemhenry as maintainers

@ijpulidos and @mikemhenry: We could really use your help as maintainers of the YANK feedstock (our absolute free energy tool which uses openmmtools). Would that be OK?

Yes!

source: gharchive/issue

authors: jchodera mikemhenry

repo: conda-forge/yank-feedstock

license_type: permissive

license_source: github-api


text:
Fix libsodium pinning

Libsodium is not actually pinned in the current build, so when I upgraded zeromq it kept an old version of libsodium, resulting in shared library import errors. The pin will get picked up if conda_build_config.py is renamed to conda_build_config.yaml.

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Re-rendered with the latest conda-smithy

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks for catching that!

source: gharchive/pull-request

authors: conda-forge-linter minrk ryanvolz

repo: conda-forge/zeromq-feedstock


text:
updating conda env fails with file not found

I'm following the caching example and it's consistently failing when looking for the environment.yml file. It seems to expand the path to the file twice, even though I'm not explicitly expanding the path?
Specifically, the error is:
Error: ENOENT: no such file or directory, open '/home/runner/work/myrepo/myrepo/home/runner/work/myrepo/myrepo/myfolder/env.yml'

The action looks like this:
name: test-on-pr

on:
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Cache conda
        uses: actions/cache@v1
        env:
          # Increase this value to reset cache if env.yml has not changed
          CACHE_NUMBER: 1
        with:
          path: ~/conda_pkgs_dir
          key:
            ${{ runner.os }}-conda-${{ env.CACHE_NUMBER }}-${{
            hashFiles('myfolder/env.yml') }}
      - uses: conda-incubator/setup-miniconda@v2
        with:
          activate-environment: anaconda-client-env
          channel-priority: strict
          environment-file: myfolder/env.yml
          use-only-tar-bz2: true # IMPORTANT: This needs to be set for caching to work properly!
      - name: Cache pip
        uses: actions/cache@v2
        with:
          # This path is specific to Ubuntu
          path: ~/.cache/pip
          # Look to see if there is a cache hit for the corresponding requirements file
          key: ${{ runner.os }}-pip-${{ hashFiles('myfolder/env.yml') }}
          restore-keys: |
            ${{ runner.os }}-pip-
            ${{ runner.os }}-
      - name: Install dependencies
        run: |
          # $CONDA is an environment variable pointing to the root of the miniconda directory
          $CONDA/bin/conda env update --file myfolder/env.yml --name base
      - name: Test with pytest
        run: |
          pytest myfolder/tests

Thanks in advance for your help!

Hm... actual logs/links to workflows would be most instructive.
Failing that:

on which step is it actually failing?

is there any more context? warnings?

have you tried one of the simpler examples?

I generally consider caching "gravy", as it brings with it exciting new challenges and failure modes

have you tried with an environment that is not named base or root?

These are "semi-magical" from conda's perspective, and are treated specially

running the env update (and the pip cache) a second time isn't going to do anything
have you tried setting your shell (in this case shell: bash -l {0}), avoiding the whole $CONDA thing?

looks complicated... unless you are actually building conda

Unfortunately, it's in a private repo :( Building the environment takes a really long time so I'd like to cache if at all possible.
It's failing on ##[group]Run conda-incubator/setup-miniconda@v2, and there are no more warnings :( Since it fails before getting to the $CONDA part, I haven't tried adjusting that.
There are some dependencies resolved by pip - what's the best way to cache and uncache those if the cache block doesn't do anything?

If the pip cache were to be effective, you'd want to do it before the initial call to setup-miniconda... or drop the environment-file altogether, and just rely on setup-miniconda to... setup miniconda, call conda env update yourself, etc.
To really have an impact on the environment setup duration, you'd want to use conda-lock off-line and check in the lockfile...

Not the case for the original poster, but I experienced a similar error because I accidentally deleted the checkout step
      - uses: actions/checkout@v4

authors: CBroz1 bollwyvl sam-hoffman

repo: conda-incubator/setup-miniconda

license: MIT


text:
Add counters and gauges following SDK standard

Resources

https://netflix.github.io/conductor/metrics/client/

Done: https://github.com/conductor-sdk/conductor-go/releases/tag/v1.2.3

repo: conductor-sdk/conductor-go


text:
Consider changing mime_for_path's parameter type to a generic that impls AsRef

This is a minor issue, and one that
mime_for_path's parameter type is &Path. However, having a generic parameter that accepts any type that implements AsRef<Path> might be a more favorable.
I do recognize the possibility of the current parameter type being a deliberate decision. I wanted to bring this issue to your attention on the off chance that it wasn't.

Since the project is no longer being used by crates.io we are deprecating it and will be closing this issue.

repo: conduit-rust/conduit-mime-types


text:
CDH | Add configuration file when launching

Let's keep this PR as draft until initdata is finished, as after merging this PR kernel cmdline will no longer be used to parse kbs and kbc parameters.
This PR adds ability of setting configurations like aa_kbc_params, kbs pub key via a file when launching CDH. At the same time, parsing them from kernel cmdline is supported as a legacy way.
In future, if initdata mechanism is well implemented, we could deprecate the kernel cmdline way.

cc @fitzthum @danmihai1 @bpradipt

Fixes the logic and notes to ensure the initialization resources from KBS must be put under /run/confidential-containers/cdh. Now ready for review.

Hi @portersrc I have fixed the things following your suggestions. PTAL
Hi @fitzthum I have fixed things you suggested. There are still some discussions left. PTAL

Just rebased the upstream code to fix CI.

Btw, we might want to think about providing a default config file as well (in addition to the example). This would ship with all platforms that don't support InitData (or maybe with all platforms in general and then it would be overwritten by the init data). This would help with package stuff in Kata but we can do it in a separate PR.

Hey @mkulke does this pr look good now?

@mkulke let me think more about this before merging.

@mkulke Thanks for the link.
I quickly glanced at the issue. The unsafe key point is for multithread application due to the synchoronization and race of the envs. That means if the setting time and reading time are not easy to ensure, frequent modification would make the reader get a wrong env. However, in CDH this PR, the setting time is always the initialization of CDH when no code will call to read. After the initialization, the envs are fixed, and then the submodules could read the will-never-changed env.
BTW in kata-agent, we have already used this for a long time. An env is set in kata-agent https://github.com/kata-containers/kata-containers/blob/CCv0/src/agent/src/main.rs#L433
and then this env will be read in ocicrypt-rs https://github.com/confidential-containers/guest-components/blob/main/ocicrypt-rs/src/lib.rs#L40
This is isomorphism to this PR now.
TBO env might not be the best choice, and probably I should do some refactoring to deliver the parameter in function call. However for now, I think it's ok. wdyt?

BTW in kata-agent, we have already used this for a long time. An env is set in kata-agent https://github.com/kata-containers/kata-containers/blob/CCv0/src/agent/src/main.rs#L433
and then this env will be read in ocicrypt-rs https://github.com/confidential-containers/guest-components/blob/main/ocicrypt-rs/src/lib.rs#L40

yes, I am aware, and I find this equally not-pretty. arguably ocicrypt-rs is a slightly different case (while our own code, it's supposed to be a re-implementation an original lib and it's called by kata, which is a different project).
So, if we have to resort to a global variable to pass down parameters to consumers, would we able to use a "proper" global variable?
https://docs.rs/once_cell/latest/once_cell/#safe-initialization-of-global-data

TBO env might not be the best choice, and probably I should do some refactoring to deliver the parameter in function call. However for now, I think it's ok. wdyt?

I might be neurotic about those things, so maybe let's get another opinion on this.

So, if we have to resort to a global variable to pass down parameters to consumers, would we able to use a "proper" global variable?

IMO kms could have ability to work as a separate crate, which provides the toolset to interact with different kinds of KMSes (including KBS). Thus I choose to use env.
Certainly, if kms would only be used in CDH, it will only be a module and we can use OnceCell. FWIW now, it seems still reasonable that kms would not aim to serve only CDH but more scenarios.
I prefer to keep it as-is. Let's collect some more ideas, kindly ping @fitzthum @1570005763 @portersrc

Yeah, I am also a bit suspicious of this ENV flow, but I think it isn't quite an anti-pattern. I think we can see this as setting up a one-time configuration for a child component. As the CDH evolves I think we should try to come up with something more robust. I have mentioned in the past that I don't like our reliance on the filesystem for other configuration parameters, but for now I guess I can live with this.

Let me merge this now. Any problems could be raised by an issue.

authors: Xynnn007 fitzthum mkulke


text:
DO NOT MERGE: tracking 0.5.x

Anything we want on the testnet-3 should be back ported to this branch.
Mainly the minor fixes with error messages, adjusting valset, etc

No more 0.5.x maintenance. Closing

repo: confio/poe-contracts


text:
Error message: failed to process message, error adding vote

repeated error message
May 18 15:13:28 dryrunnet-sentry-1 docker[31762]: #033[90m3:13PM#033[0m #033[1m#033[31mERR#033[0m#033[0m failed to process message #033[36merr=#033[0m"error adding vote" #033[36mheight=#033[0m529644 #033[36mmodule=#033[0mconsensus #033[36mmsg_type=#033[0m*consensus.VoteMessage #033[36mpeer=#033[0mc43fdcc59863363bee6dd436c71936744beca9be #033[36mround=#033[0m0
You can find those error messages on all the sentry and validator nodes, it is not causing a degrading effect on the performance, it just showing as an error, not sure if it has something to do with the webapp

logs before and after the error message:
May 18 14:10:01 dryrunnet-validator-3 docker[35149]: #033[90m2:10PM#033[0m #033[32mINF#033[0m Saving AddrBook to file #033[36mbook=#033[0m/root/.tgrade/config/addrbook.json #033[36mmodule=#033[0mp2p #033[36msize=#033[0m40
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m indexed block #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mtxindex
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m committed state #033[36mapp_hash=#033[0mF1DA7DE79080608ACAE28D0BC4412AFA29A76F9750161264CD148DB5AFF62381 #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mstate #033[36mnum_txs=#033[0m0
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m commit synced #033[36mcommit=#033[0m436F6D6D697449447B5B3234312032313820313235203233312031343420313238203936203133382032303220323236203134312031312031393620363520343220323530203431203136372031313120313531203830203232203138203130302032303520323020313431203138312031373520323436203335203132395D3A38313235367D
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m executed block #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mstate #033[36mnum_invalid_txs=#033[0m0 #033[36mnum_valid_txs=#033[0m0
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m privileged contract callback #033[36mmodule=#033[0mx/poe #033[36mtype=#033[0mvalidator_set_updater
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m finalizing commit of block #033[36mhash=#033[0m46DE324A87A4003357F3A4128FF95155A33F08D246DC41BAD8F48E3B05A56FB9 #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mconsensus #033[36mnum_txs=#033[0m0 #033[36mroot=#033[0m38BA01E4D39DC992FCF48D38B2F22850658AF96383CA58928E8DECC5D73602D9
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m received complete proposal block #033[36mhash=#033[0m46DE324A87A4003357F3A4128FF95155A33F08D246DC41BAD8F48E3B05A56FB9 #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mconsensus
May 18 14:09:59 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m received proposal #033[36mmodule=#033[0mconsensus #033[36mproposal=#033[0m{"Type":32,"block_id":{"hash":"46DE324A87A4003357F3A4128FF95155A33F08D246DC41BAD8F48E3B05A56FB9","parts":{"hash":"3529979D43D45BB148299B38C88C64D062916DC273981FB22EC4A1275A480F70","total":1}},"height":528982,"pol_round":-1,"round":0,"signature":"PGK7MOIpgm9jABzAGUPSD3uQr/maHFg1197OAIj+0+pY3jsEI147fACoZZphu7mzarlO1xMZSV0Dsky+Ai9bCg==","timestamp":"2022-05-18T14:09:58.995744432Z"}
May 18 14:09:58 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m Timed out #033[36mdur=#033[0m4462.936307 #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mconsensus #033[36mround=#033[0m0 #033[36mstep=#033[0m1
May 18 14:09:54 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[1m#033[31mERR#033[0m#033[0m failed to process message #033[36merr=#033[0m"error adding vote" #033[36mheight=#033[0m528982 #033[36mmodule=#033[0mconsensus #033[36mmsg_type=#033[0m*consensus.VoteMessage #033[36mpeer=#033[0mc43fdcc59863363bee6dd436c71936744beca9be #033[36mround=#033[0m0
May 18 14:09:54 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m failed attempting to add vote #033[36merr=#033[0m"expected 528981/1/2, but got 528981/0/2: unexpected step" #033[36mmodule=#033[0mconsensus
May 18 14:09:54 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m indexed block #033[36mheight=#033[0m528981 #033[36mmodule=#033[0mtxindex
May 18 14:09:54 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m committed state #033[36mapp_hash=#033[0m38BA01E4D39DC992FCF48D38B2F22850658AF96383CA58928E8DECC5D73602D9 #033[36mheight=#033[0m528981 #033[36mmodule=#033[0mstate #033[36mnum_txs=#033[0m0
May 18 14:09:54 dryrunnet-validator-3 docker[35149]: #033[90m2:09PM#033[0m #033[32mINF#033[0m commit synced #033[36mcommit=#033[0m436F6D6D697449447B5B35362031383620312032323820323131203135372032303120313436203235322032343420313431203536203137382032343220343020383020313031203133382032343920393920313331203230322038382031343620313432203134312032333620313937203231352035342032203231375D3A38313235357D

Thanks for reporting. The error is thrown in Tendermint and not really an issue if we don't loop in the steps. The code doc gives some reasons:

  	// Either
  	// 1) bad peer OR
  	// 2) not a bad peer? this can also err sometimes with "Unexpected step" OR
  	// 3) tmkms use with multiple validators connecting to a single tmkms instance
  	// 		(https://github.com/tendermint/tendermint/issues/3839).

https://github.com/tendermint/tendermint/blob/v0.34.19/consensus/state.go#L1983-L1989
The common case that I can see in the info log is:  "expected 704279/1/2, but got 704279/0/2: unexpected step". No further info available from the logs

authors: alpe migmeneses

repo: confio/tgrade


text:
Subscribe to many topics and async processing of messages

Description
I have a single consumer which subscribe to all wanted topics (let say 5). Then I need to process all messages from one topic one by one (sync), but in parallel(async) between topics. When consumer  receive a message, it should redirect it to the corresponding thread by topic. Looks like 5 topics = 5 processing thread.
Is it ok approach, or should I create  a consumer for each topic? Now all topics have 1 partition, but it will be extended in the future.
If it is ok to have single consumer  for many topics, then could you please suggest how to implement it? There are any common patterns or something like that in this package?
Thank you in advance.

your suggestion (one consumer, 1 thread per topic, each managing a queue of messages that is populated by the consume loop) sounds good to me.
in the future we may improve the consumer API for this use case.

But how can I implement this? Should I create some manager, that will get numbers of Subscriptions from consumer, then create thread for each, then check if (consumeResult.Topic == "A") => to thread A ...
Are there any solutions?

something like that, yes. we don't have any examples yet.

What about partitions? Should I be process in parallel too by one consumer?

authors: Marusyk mhowlett

repo: confluentinc/confluent-kafka-dotnet


text:
chore: update repo by service bot

This is a routine update from cc-service-bot based on the service.yml in your repo. This PR
should be approved and merged as soon as CI passes.

CHANGELOG
FILE NAME - CHANGED BY - COMMIT MESSAGE
.semaphore/cp_dockerfile_build.yml - framework - chore: update repo semaphore task
.semaphore/cp_dockerfile_promote.yml - framework - chore: update repo semaphore task

repo: confluentinc/kafka-streams-examples


text:
TopologyBuilder methods return the builder to allow methods to be chained together.

Since the methods returned void before, this change has no impact on existing code.

@rhauch Thank you for the pull request. There seems to be a conflict. Would you resolve it so that I can merge?

@ymatsuda, I've rebased upon the latest upstream branch, and also added JavaDoc for the public methods in TopologyBuilder. Let me know if there are more problems.

Thanks!

authors: rhauch ymatsuda

repo: confluentinc/kafka


text:
Swift Package Manager

I am trying to add this dependency with Swift Package Manager and I am getting attached error.
I tried to add with all version rules (up to next major, up to next minor, range, exact) in Xcode

Let me try and give you feedback.

Are you using Xcode 11?
If you want to install FMPhotoPicker via SwiftPM, you must use Xcode 12 and above since there are some feature FMPhotoPicker needs but not be supprted by odler version of SwiftPM.
For Xcode 11 or older, you can use Carthage or Cocoapod.

authors: congnd emrdgrmnci

repo: congnd/FMPhotoPicker


text:
When building from source, the UI bundle*.js files do not get generated and installed automatically

Building from git on a Pine64
Ran make deps, make and npm run build in the app directory however the bundle.js files do not appear to have been created.
Copying them from the latest alpha release "fixed" the solution, however the docs may need updating to fix this properly.

Can you paste the output of the make command?

I'll have to re-run it tonight or this weekend to get that, but I'll do it as soon as I can.

I was unable to reproduce this issue. npm run build in the app directory creates a bundle.js - I tested both on linux and mac, and it successfully works in CI also. Are there any error messages that show up?

No response, closing.

authors: dkumor proffalken

repo: connectordb/connectordb

license_source: bigquery


text:
Create Connext Mocks for local testing

Background
Create Connext Mocks that can be easily imported for local testing.
From Derby:
"So basically, this is our cross chain setup. The most important picture is the second picture on this page: https://derby-finance.gitbook.io/derby-finance-docs/developers/architecture/cross-chain which shows all the external triggers that need to be initiated by a keeper network. These triggers are all cross chain actions except from the trigger represented by arrow 8.
We work with cross chain provider contracts (XProvider.sol) which sit between Connext.sol and our contracts. This is shown in the 3rd picture on the same page.
To simulate all cross chain stuff we basically only need to simulate xcall in Connext.sol because that’s the only point of interaction with your technology. Since local testing all takes place on the same simulated local blockchain the Connext.sol Mock contract in our repo only just routes the function calls. You can see it implemented here: derby-yield-optimiser/contracts/Mocks/Connext/ ConnextMock.sol
Note that the 2nd picture could be simplified if we would use callbacks and if we would use authenticated messaging and transferring of funds in 1 call (instead now those have been done in two separate calls).
So again, the ConnextMock.sol is a very basic setup (maybe almost the most minimalistic setup possible). Hope the idea is clear, and hope you agree with this setup. Any feedback is always more than welcome!!"
Connext Mock: https://github.com/derbyfinance/derby-yield-optimiser/blob/master/contracts/Mocks/Connext/ConnextMock.sol

Impact: 4
See the discussion in Sprint Poker #27
Powered by Parabol

Urgency: 3
See the discussion in Sprint Poker #27
Powered by Parabol

Urgency: 3
See the discussion in Sprint Poker #30
Powered by Parabol

Started on this, building a sharable framework for e2e mock testing.

authors: just-a-node rhlsthrm

repo: connext/monorepo


text:
add Set Tokens

为确保 Token Profile 的顺利通过，务必逐一确保以下检查项并补充项目资料：
.json 及 .png 文件检查项

[ ] logo 尺寸：120*120 px
[ ] logo 背景：透明
[ ] 代币有至少一笔成功的转账记录
[ ] 此项对于 ERC-20 项目方：合约地址有大小写（做 checksum）
[ ] .json 和 .png 文件名一致（包括大小写）

项目资料：
官方公告：
团队背景：
项目基本情况：
媒体报道：
收录的交易所：
转账所需 Gas Limit（对 ERC-20 项目方）：（默认为 60000）

Please check the following to ensure a successful verification of Token Profile
.json and .png document checklists

[x] logo dimensions: 120*120 px
[x] logo background: Transparent
[x] At least one transaction on the token contract
[x] For ERC-20 project teams: Upper and lower capitalized alphabets in token address (For checksum purposes)
[x] Same document name for both .json and .png (Including capitalization)

Project background:
Official announcement: https://medium.com/set-protocol/strategy-enabled-tokens-coming-soon-to-tokensets-28b163e64250
Project team background: Set is building open sourced software to enable anyone to create, manage, and acquire tokenized portfolios of assets. Applications such as decentralized robo-advisors, tokenized trading strategies, and decentralized ETFs can be built on Set Protocol. Set is based in San Francisco and completed a series seed fundraising of $2M dollars led by Craft Ventures and Vy Capital with participation from Kindred Ventures, DFJ, Haystack, and Social Capital.
Project basic information: Set is building open sourced software to enable anyone to create, manage, and acquire tokenized portfolios of assets.
Media publications:
Tradeable exchanges: tokensets.com
Recommended Gas Limit (For ERC-20 project teams) for transaction: (Default is 60,000) 60,000

there is some problem need to be solved as label shows and below pic.

Welcome to recommend imToken 2.0 to your token holders to manage their token.

authors: richardliang tstt

repo: consenlabs/token-profile


text:
Update package.json links and version

This should be self explanatory

Thanks!

repo: consindo/waka

license: mit


text:
remove old go1.8 NoGoError code

Removes the since rolled back change to build.NoGoError Go 1.8+ workaround.
Fixes gb#690

@freeformz i'm going to commit this to fix #690. I grabbed the test fixture from the bug report and it passes fine on all versions of Go from 1.4 to tip.

repo: constabulary/gb


text:
WB#92_ng-template-loader

resolve issue #92
Добавил обработку template 'ов через ngtemplate-loader.
Этот loader при каждой сборке приложения webpack'ом регистрирует template'ы в angular $templateCache. Таким образом актуальные template'ы всегда есть на стороне пользователя в main.[content-hash].js сборке, у которой есть content-hash в имени файла, что гарантирует актуальность отдаваемых nginx'ом данных.
Т.к. templat'ы теперь хранятся в сборке из webpack и make файлов были удалены строчки с перекладыванием views папки.

Эта ошибка давно существовала в ветке feature/v2_carbonfay_round1 и не связана с изменениями в этом PR'e.

@pavel-rakhmanov Проверь пожалуйста ещё раз. Я когда писал, то кажется проверял до и после применения пул реквеста. С ним интерфейс не работает

@evgeny-boger, мы тестировали сборку make файлом. Но в ветке feature/v2_carbonfay_round1 присутствует ошибка webpack config файла: при запуске npm run build ошибка при добавлении чанков в index файл. И запустить приложение, собранное make файлом просто нельзя - в консоли 3 ошибки.
Я исправил webpack файл (пока закомментировал плагины, которые некорректно работают), мы развернули билд после make файла на дефолтном конфиге nginx (default.wb) с максимальным кешированием для ветки WB#92_ng-template-loader.
Все view файлы после обновления сборки на сервере корректно обновляются, но ошибка в консоли на странице widgets как и в ветке feature/v2_carbonfay_round1 присутствует.

@pavel-rakhmanov А где вы собираете? Какое окружение? Странно, что у меня оно собирается, может чего-то версии другие

Прошу прощения за задержку с review. Проверил, действительно не смог воспроизвести проблему с незагружающимися виджетами, в этом месте всё хорошо. Переход с v1 тоже работает, ничего лишнего не кешируется больше.
Смущают две вещи:

Все шаблоны попадают в main.js, а код попадает в отдельные модули (history.js и т.п.), которые динамически подгружаются. Получается, что динамическая подгрузка тут работает странно: код подгружается, а шаблоны нет. Можно это малой кровью поправить?

почему-то в исходниках торчат полные пути на сборочной машине:

@evgeny-boger,
по поводу шаблонов в main: я не достаточно хорошо понимаю 1й angular. Знаю, что так, как вы пишете, можно сделать с компонентами - они представляют собой скрипт с указанием представления для него. Все же скрипты для страниц приложения сделаны через директивы. Малой кровью я не смогу это сделать. Нужно больше читать про сам angular.
по поводу полных путей:  заменил на относительные.

authors: evgeny-boger pavel-rakhmanov

repo: contactless/homeui


text:
Container Desktop install fails with NullReferenceException

Container Desktop build number
v1.1.11
Windows build number
10.0.22621.0
Steps to reproduce

Remove existing Container Desktop files from C:/Program Files/Container Desktop
Download latest installer from github
Run installer

Expected Behavior
No response
Actual Behavior
Installation finishes with Finished undoing resources, eventlog shows:
Failed to applying at ["InstallWslDistro"] "Install Container Desktop WSL distribution": "Object reference not set to an instance of an object."
System.NullReferenceException: Object reference not set to an instance of an object.
   at ContainerDesktop.Wsl.WslService.<>c__DisplayClass8_0.<IsInstalled>b__0(String x)
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   at ContainerDesktop.Wsl.WslService.IsInstalled(String distroName)
   at ContainerDesktop.DesiredStateConfiguration.WslDistro.Test(ConfigurationContext context)
   at ContainerDesktop.DesiredStateConfiguration.ConfigurationManifest.<Apply>g__Apply|10_0(IEnumerable`1 resources, ConfigurationContext ctx, Int32 initialCount, Int32 countModifier, <>c__DisplayClass10_0& )

Related to #67

I also have the same.
Error in Event log the same as @maartengo.
Last entry in AppData\Local\ContainerDesktop\logs\log.txt:
[ERR] Could not initialize and start the daemon.
ContainerDesktop.Services.ContainerEngineException: Could not initialize and start the daemon.
   at ContainerDesktop.Services.DefaultContainerEngine.InitializeAndStartDaemon() in D:\a\container-desktop\container-desktop\container-desktop\ContainerDesktop\Services\DefaultContainerEngine.cs:line 396
   at ContainerDesktop.Services.DefaultContainerEngine.<Start>b__22_1() in D:\a\container-desktop\container-desktop\container-desktop\ContainerDesktop\Services\DefaultContainerEngine.cs:line 86
   at Polly.Policy.<>c__DisplayClass108_0.<Execute>b__0(Context _, CancellationToken _)
   at Polly.Policy.<>c__DisplayClass138_0.<Implementation>b__0(Context ctx, CancellationToken token)
   at Polly.Retry.RetryEngine.Implementation[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Action`4 onRetry, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider)
   at Polly.Retry.RetryPolicy.Implementation[TResult](Func`3 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy.Implementation(Action`2 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy.Execute(Action`2 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy.Execute(Action action)
   at ContainerDesktop.Services.DefaultContainerEngine.Start() in D:\a\container-desktop\container-desktop\container-desktop\ContainerDesktop\Services\DefaultContainerEngine.cs:line 74
   at ContainerDesktop.App.<>c__DisplayClass16_0.<AppStartup>b__0() in D:\a\container-desktop\container-desktop\container-desktop\ContainerDesktop\App.xaml.cs:line 44
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__272_0(Object obj)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)

Hi, I faced the similar issue.
I checked in registry editor HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss and it contains extra entry line AppInstallerCache.
I guess the root of NPE is here https://github.com/container-desktop/container-desktop/blob/45a84fef51f998e9a7bb0505c276900f09d1070a/container-desktop/Wsl/WslService.cs#L65. Probably need to add checking that DistributionName is not null
After removing this extra entry in registry -- Container Desktop was installed successfully
Raised: https://github.com/container-desktop/container-desktop/pull/80/files

Can confirm that removing AppxInstallerCache resolved the issue

authors: maartengo nulls sergbolshakov

repo: container-desktop/container-desktop


text:
Fix mypy/annotations in atomic_reactor/util.py

Maintainers will complete the following section

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

change to annotations in codebase, no release notes needed

repo: containerbuildsystem/atomic-reactor


text:
ctr run hangs with the error of pty request

Create and exit containers frequently , sometimes the ctr run hangs with error printing ERRO[0000] console resize error="rpc error: code = 2 desc = bad file descriptor, as follow:
# ctr run --id mytest -t docker.io/library/busybox:latest
/ # exit
# ctr run --id mytest -t docker.io/library/busybox:latest
/ # exit
# ctr run --id mytest -t docker.io/library/busybox:latest
ERRO[0000] console resize                                error="rpc error: code = 2 desc = bad file descriptor"
******block here******

# ps -ef |grep mytest
root     10762  7602  0 11:27 pts/1    00:00:00 ctr run --id mytest -t docker.io/library/busybox:latest
root     10803 10770  0 11:27 pts/5    00:00:00 runc --log /run/containerd/linux/mytest/log.json --log-format json start mytest
root     10812 10499  0 11:27 pts/10   00:00:00 grep --color=auto mytest

The status is STOPPED
# ctr ls
ID       PID       STATUS
mytest   10787     STOPPED

@miaoyq thanks for splitting this into a separate issue.  I'll take a look at it tomorrow and see if I can reproduce.  Do you have any tips for reproducing this bug?  I've yet to see it on my system.

@crosbymichael  I'm sorry to reply so late.
Create and exit containers as follow:
# ctr run --id mytest -t docker.io/library/busybox:latest
/ # exit

Repeat the operation quickly. (Press the ↑ and Enter keys alternately)

@miaoyq #893 was merged that addressed some other issues related to -t.  I cannot reproduce this error on current master.  Could you try again to see if you still get the error?

@ehazlett  I could not reproduce this error also.  :+1:

Thanks for checking!  I think this can be closed.

Thanks all.. going to close for now

authors: crosbymichael ehazlett estesp miaoyq

repo: containerd/containerd


text:
If capabilities are explicitly added then also add them to the ambient set.

This change makes it so that we add capabilities to the ambient set if they are explicitly added. So in kubernetes if we add a capability to the container securityContext then that capability will be added to the ambient set in addition to the inheritable, effective, permitted and bounding sets. This will allow users to run a container as non-root while giving it just the capabilities it needs, without having to apply file capabilities and allowing privilege escalation.
If ALL capabilities are added then we don't add ALL capabilities to the ambient set because that would make a non-root user essentially root. We also don't add the defaultUnixCaps i.e. the default capabilities that are always added to inheritable, effective, permitted and bounded sets to the ambient capability set as that will also make non-root user as power full as root.

/cc @qiutongs

/cc @tallclair

/cc @mikebrow

Adding @mikebrow - this is RE: https://github.com/kubernetes/enhancements/pull/2757

/ok-to-test
Tagged this as "impact/changelog" as this does change the behavior for non-Kubernetes users of the containerd client library who are setting capabilities.

So in kubernetes if we add a capability to the container securityContext then that capability will be added to the ambient set in addition to the inheritable, effective, permitted and bounding sets.

I remember that the reason we want a K8s/CRI api change for the ambient set, is to make the api backward compatible, and avoid underlying behavior change.
Assuming users already have a pod adding some capabilities for a non-root pod by mistake, this would change the behavior for them unexpectedly?

Assuming users already have a pod adding some capabilities for a non-root pod by mistake, this would change the behavior for them unexpectedly?

Wouldn't it make the behavior what the user expected to happen? An in a user would assume adding a capability to the securityContext of the container should add the capability in a form that it is usable.

Wouldn't it make the behavior what the user expected to happen?

The problem is that we don't know whether users do it intentionally or by mistake. The behavior has been there for so long, that we may not be able to treat it as a bug fix. :/

gut says a feature gate in k8s and a new bool/mask over CRI to /f ambient..

See https://github.com/containerd/containerd/blob/main/pkg/cri/server/container_create_linux.go#L238

Woops! haha I forgot to update that. Good catch!

Closing due to inactivity, feel free to re-open the pull request anytime if you continue working on this.

authors: Random-Liu dmcgowan mikebrow samuelkarp vinayakankugoyal


text:
boilerplate needs to support no copyright year

See thread here https://github.com/containerd/containerd/pull/2108...
So plan is to fix our boilerplate test to support YEAR being optional.
Then I can move our version of boiler tests to containerd/containerd....

#647 was merged. Close this one.

authors: Random-Liu mikebrow

repo: containerd/cri


text:
Fix indent in cni.template.

Fix indent in cni.template.
Signed-off-by: Lantao Liu lantaol@google.com

yeah not if the parser does not care.. and there is no format check...


text:
[WIP]refactor: config and daemonconfig package

Signed-off-by: Gaius gaius.qi@gmail.com

Codecov Report
Base: 33.21% // Head: 34.84% // Increases project coverage by +1.62% :tada:

Coverage data is based on head (84c21e0) compared to base (a6fc3af).
Patch coverage: 64.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #267      +/-   ##
==========================================
+ Coverage   33.21%   34.84%   +1.62%
==========================================
  Files          29       27       -2
  Lines        3110     3022      -88
==========================================
+ Hits         1033     1053      +20
+ Misses       1969     1862     -107
+ Partials      108      107       -1

Impacted Files
Coverage Δ

pkg/daemon/config.go
0.00% <ø> (ø)

pkg/daemon/daemon.go
0.00% <0.00%> (ø)

pkg/daemon/rafs.go
2.32% <ø> (ø)

pkg/manager/daemon_adaptor.go
0.00% <ø> (ø)

pkg/manager/manager.go
20.89% <0.00%> (-0.27%)
:arrow_down:

pkg/manager/mode.go
0.00% <0.00%> (ø)

internal/containerd-nydus-grpc/command/flags.go
93.33% <27.77%> (ø)

internal/containerd-nydus-grpc/logging/logging.go
73.33% <100.00%> (ø)

pkg/slices/slices.go
100.00% <100.00%> (ø)

pkg/blob/blob_manager.go
29.59% <0.00%> (-3.07%)
:arrow_down:

... and 9 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter gaius-qi

repo: containerd/nydus-snapshotter


text:
fix: github action for conformance

This PR adds the OCI_CROSSMOUNT_NAMESPACE environment variable in the
github action config file. This enables us passing all the test cases.
Signed-off-by: jay-dee7 jasdeepsingh.uppal@gmail.com

@guacamole lets merge this one after #31

Looks awesome, everything passes!!! 🥇

repo: containerish/OpenRegistry


text:
Drop vergen dependency

We only need the version, build time, rust target triple, and git commit
for the version command. These values can easily be generated with little
code so we do not need an extra dependency for this.
The main reason for this change is that vergen will fail if no git
commit is found. On distro build systems this is often the case since
they build from a source tar without the git repo. Instead of erroring
we should just show an empty commit in the version output.
Fixes #93

code LGTM

/hold cancel

authors: Luap99 baude flouthoc

repo: containers/aardvark-dns


text:
creation of json logger.rs and boilerplate code implemented

What type of PR is this?
This PR is the start of my contribution to the JSON log driver implementation over here.

/kind feature

What this PR does / why we need it:
I have added the boilerplate code and did a bit tweaks to container_log.rs.
Which issue(s) this PR fixes:
As of now its is a draft PR and it doesn't fix anything but will later on be worked with and give container logs in JSON/Splunker output.

Special notes for your reviewer:
Does this PR introduce a user-facing change?

None

need some guidance from @haircommander  over writing tests for loggers....

repo: containers/conmon-rs


text:
Validate ENV/LABEL Change options in varlink

If you pass in an invalid CHANGE ENV or LABEL option without the "=" character
podman crashes.
Signed-off-by: Daniel J Walsh dwalsh@redhat.com

Closes: https://github.com/containers/libpod/issues/2869

LGTM

LGTM once we clear our lint issues

@rhatdan Rebase to fix lint and I'll merge

Please merge this when it finishes.

Closes: https://github.com/containers/libpod/issues/2869

Still unhappy tests @rhatdan

@mheon @baude @vrothberg @TomSweeneyRedHat @giuseppe Tests pass now can someone give this a /lgtm

/lgtm

authors: TomSweeneyRedHat baude mheon rhatdan

repo: containers/libpod


text:
pkg/varlinkapi/virtwriter/virtwriter.go: simplify func Reader

simplify func Reader

/ok-to-test

/approve

/lgtm

/hold

LGTM, nice simplification
/hold cancel

authors: baude haraldh mheon


text:
fix systemd generate tests

Add the default.target to the failing tests.
Signed-off-by: Valentin Rothberg rothberg@redhat.com

LGTM

Restarted the armada of flakes.

LGTM assuming happy tests

/lgtm
/hold

/hold cancel

authors: TomSweeneyRedHat edsantiago mheon vrothberg


text:
Make minimal change to allow for ramalama to build on EL9

The base version of python shipped with EL9 is python-3.9 and the setuptools shipped with that is too old to understand most of the pyproject.toml input. So the setup.py must contain the name of the project and the version for it to properly build a package in EL9.

LGTM

Nice

authors: ericcurtin rhatdan smooge

repo: containers/ramalama


text:
Explore the use of clone to reduce the number of forks youki does in creating containers

With the release of clone as a new systemcall in kernel version 5.7^, we can now use it to hopefully reduce the number of forks youki does when creating a container (See here).
cc @utam0k @Furisto @flxo

5.7 is indeed too recent, so I think that when we support clone3, we should also support it to work with 5.4 at the same time.

What I got from @flxo's comment on #10, clone2 should give use benefits over the current fork strategy. I say we explore that first.

I have implemented it with the following considerations in mind.
https://github.com/opencontainers/runc/blob/93a01cd4d0b7a0f08abc36c2ebc85a0543b25647/libcontainer/nsenter/nsexec.c#L680-L725
But now youki may get the advantage by using clone(2). I think this may be a challenge. This area has been well commented on by @YJDoc2 . If anyone wants to try it, I will support it.

Just a heads up, I am currently also making changes in this area, so please coordinate with me to avoid stepping on each others toes.

Can I help to take look at this issue? My understanding is if we can enter user namespace and pid namespace together through a single clone(2), the resulting process can then become the init process (YP -> YI, instead of creating YC). We currently have to fork twice because we need to fork once to enter into user namespace, and fork again to enter into the correct pid namespace. Is this understanding correct?

Can I help to take look at this issue? My understanding is if we can enter user namespace and pid namespace together through a single clone(2), the resulting process can then become the init process (YP -> YI, instead of creating YC). We currently have to fork twice because we need to fork once to enter into user namespace, and fork again to enter into the correct pid namespace. Is this understanding correct?

@yihuaf Thanks for your interest. Your understanding is correct. Would you like to take the challenge? However, I think we need to carefully explore whether the double fork had any security implications, and I'd like you to refer to the runc code and check that as well.
https://github.com/opencontainers/runc/blob/93a01cd4d0b7a0f08abc36c2ebc85a0543b25647/libcontainer/nsenter/nsexec.c#L680-L725

Just a heads up, I am currently also making changes in this area, so please coordinate with me to avoid stepping on each others toes.

@Furisto  I'm assuming this is finished, is that correct?

You can assign this to me then. I will keep the referenced runc code in mind.

@yihuaf I'll assign you. I'm looking forward to your PR :)

authors: Furisto nimrodshn tsturzl utam0k yihuaf

repo: containers/youki


text:
webDAV

Hi,
I wonder to know if it is possible to access webDAV resources (in my case a KeyPass database) in a webDAV share behind a traefik reverse proxy.
This seems to be similar to this issue [1] relating to apache.
If so, how to do so?
Thank you,
giopas
[1] http://stackoverflow.com/questions/1110710/webdav-behind-a-reverse-proxy

I don't think there is anything in particular that should stop this from working... There are a few complexities to webdav so there could be some issues...
Why not try it out? If there are any issues we can try to fix them.

Hi errm,
thanks for your reply. I try to explain my set-up.
I want to access a KeyPass db in a webDAV folder located in a different server (within the same LAN) where Traefik is installed.
The file is directly accessible on: http://10.0.0.3/DAV/Pass.kdbx
I want then to create a reverse proxy with Traefik to access to this file.
I am thinking of doing this (but it does not work):
[backends.general]
    [backends.general.servers.server1]
    url = "http://10.0.0.3"

[frontends.webdav]
    backend = "general"
    priority = 99
    passHostHeader = true
    entrypoints = ["http"]
    [frontends.webdav.routes.webdav_1]
    rule = "Host:webdav.mydomain.com;Path:/DAV/"

How to do so in the right way? Thanks!

@errm can you please help me on this or suggest me where to look at? Thanks in advance!

I think you are just missing the port from the backend url...
Could you paste the log if you have any more issues?

Hi @errm , I managed to make webDAV partially work:
[backends.general]
    [backends.general.servers.server1]
    url = "http://10.0.0.3:80"

[frontends.webdav]
    backend = "general"
    priority = 99
    passHostHeader = true
    entrypoints = ["http"]
    [frontends.webdav.routes.webdav_1]
    rule = "Host:webdav.mydomain.com"

However this is not the correct way as I need to go to http://webdav.mydomain.com/DAV/myfile.kdbx to access the resource, whether my intention is to directly go to http://webdav.mydomain.com/myfile.kdbx.
How can I do this?
By the way I have activated the log in traefik.toml as follows but I have no information saved in the log:
# Traefik logs file
# If not defined logs to stdout
traefikLogsFile = "traefik.log"
loglevel = "DEBUG"

Thanks

Hi there,
anyone ( @errm maybe) could help on how to use a subdomain to redirect to a specific subfolder?
In my example above I want to access to reverse proxy http://10.0.0.3:80/DAV/ to http://webdav.mydomain.com/
How to do so?
Thank you,
giopas

Hi there,
I'm also trying to use Traefik with Nextcloud (the official nextcloud:12-apache image), web access works fine, but I'm having trouble with Cal/CardDAV, e.g. with DAVDroid:
EXCEPTION:
at.bitfire.dav4android.exception.InvalidDavResponseException: Expected 207 Multi-Status, got 200

Just a quick heads up, my issue is/was actually related to https://github.com/containous/traefik/issues/2351 .
Reverting to 1.4.0 fixed the issue for now.

I'll close the issue due to inactivity but feel free to re-open if needed.

authors: errm giopas jacksgt traefiker

repo: containous/traefik


text:
SwarmMode - Not routing on worker node

Hi,
I want to set up a 2 nodes swarm cluster (1 manager, 1 worker)
I have traefik running on master, with theses options (i took pr 728 which i found is the last with functionnal dashboard)
docker service create \
--constraint "node.role == manager" \
--name traefikswarm \
--network swarm_net \
--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
--label "traefik.frontend.rule=Host:traefik.swarm.mydomain.org" \
--label "traefik.backend=traefikswarm" \
--label "traefik.port=81" \
-p 85:80 \
containous/traefik:pr-728 --web --retry --retry.attempts=10 --docker --docker.domain=swarm.mydomain.org --docker.swarmmode --logLevel=DEBUG --entryPoints='Name:http Address::80' --defaultEntryPoints=http --web.address=":81"

Then i run whoami service on manager node :
docker service create \
--replicas 2 \
--network swarm_net \
--name whoamiswarm \
--label "traefik.frontend.rule=Host:whoami.swarm.mydomain.org" \
--label "traefik.port=80"  \
--constraint "node.role == manager"  \
emilevauge/whoami

That's OK I can access http://whoami.swarm.mydomain.org:85/
I remove service and start same conf on worker node :
docker service create \
--replicas 2 \
--network swarm_net \
--name whoamiswarm \
--label "traefik.frontend.rule=Host:whoami.swarm.mydomain.org" \
--label "traefik.port=80"  \
--constraint "node.role == worker"  \
emilevauge/whoami

As expected the container start on worker and traefik dashboard show me an entry to the VIP, like :
http://10.0.0.7:80
But then traefik can't access it
Logs :
time="2016-11-14T09:41:21Z" level=warning msg="Error forwarding to http://10.0.0.7:80, err: dial tcp 10.0.0.7:80: getsockopt: no route to host"
What am I missing ?
Thanx for reading

Some tests with 2 ubuntu containers :
I ran 2 ubuntu :

One in manager node, in swarm net
One in worker node in swarm net
They can't reach each other on the VIP
So I think it's a docker issue, not traefik
But info on that appreciated ! :D

Have you made sure you have all the required ports open? If your overlay is encrypted you will also need to make sure you can send ESP packets.
https://docs.docker.com/engine/swarm/swarm-tutorial/#/open-ports-between-the-hosts

Yeah thanks
I check all that, but I think I'm facing a NAT problem
I got Network Address Translation between hosts, so I use the "advertise-addr" to tell consul on which IP the host is joinable
That's OK for consul, but I think the network overlay on vxlan don't support that for the moment
Tring to find info on that on docker github...
Thanks

After some tests, its clearly a docker swarm config issue itself. I don"t know what i'm missing.
If somebody have a docker swarm behind NAT OK, please tell me !
To reproduce my setup, it's quite easy.
Take 2 windows Hosts (let's say IP 192.168.1.11 a 192.168.1.12)
Install docker toolbox on PC 1 (internal IP 10.0.0.2-NAT and 192.168.99.100-bridge)
Install docker toolbox on PC 2 (internal IP 10.0.0.2-NAT and 192.168.99.100-bridge)
On each PC, place NAT forwarding on the swarm ports
https://docs.docker.com/swarm/plan-for-production/#/network-access-control
So that for example 192.168.1.11:2377/tcp redirect to VirtualBoxPC1 : 10.0.0.2:2377/TCP
Now i'm trying do do a swarm init on docker PC 1 and a swarm join on PC 2
(Have to play with --advertise-addr & --listen-addr)
Then :

create an overlay network
create service like nginx running on PC 1 on that network
create service like nginx running on PC 2 on that network

Try to ping/curl between then by VIP

/close
Closing cause no pb with real swarm cluster
I think I got a pb with NAT and port forcarding


text:
Add CORS middleware

This adds CORS middleware and basic implementation for docker provider (without service labels for now).

Ping @matevzmihalic @containous/traefik
IMHO, it adds a lot of complexity in labels (and only in Docker provider). Don't you think there is a simpler way?

Due to inactivity, closing this PR. If you still want to work on this, feel free to open a new one :)

Does this PR https://github.com/containous/traefik/pull/1236 solves the issue?

@holms I still don't know, it was a question asked 1 year and an half ago. I gave up using traefik since. Good luck

@holms I gave up using traefik since.

What did you use as an alternative?

authors: GuillaumeCisco JohnathanMaravilla emilevauge matevzmihalic


text:
cmd/goexports,stdlib: parallelize symbols generation for stdlib

Fixes #314.

needs #311.

As I say, I'm working on the goexports command to add a smarter generation by platform.
Use parallelism is a good idea but I will change the core of goexports.
Then we will wait until I finished the smarter generation.

ok. alternatively: we could make goexports smarter and recognize (like go list does) the "meta" package stdlib and have it automatically generate wrappers for all the packages that are in stdlib.

I do not understand why you close this PR. We are really interested in this PR.

If it's a problem, I can review this PR before creating mine, I try to do my best.

authors: ldez sbinet

repo: containous/yaegi


text:
Adds controls to alter the table dimensions

This updates the table extension to be usable for real projects.

Thnx, very usable 👍

This look awesome, definitely something I'd want to see merged before I start using this plugin.
Does anyone actively maintain this repo??

@omonk you can just use the code from this branch yourself. Very easy.

Of course! Very easy to do as you said but it would be great to see it merged into master as well.

Agree

i don't have merging rights anymore. maybe @realityking or @Shy can help. :)

:wave: Hi everyone! You can use my fork which also merges this PR: https://github.com/ljvmiranda921/ui-editable-table :tada:
git clone git@github.com:ljvmiranda921/ui-editable-table.git
cd ui-editable-table
npm install

Notes:

Merges @dmcb's Pull Request that adds controls to alter table dimensions.
Uses the modern contentful extension CLI. The previous one is already deprecated.
Allows input of the Environment ID via the CONTENTFUL_ENVIRONMENT environment variable.

@ljvmiranda921 thanks for doing that. This project is indeed not maintained. I'll check if we can archive it. :)

authors: dmcb ljvmiranda921 maartenvanbenthem omonk stefanjudis

repo: contentful-labs/ui-editable-table


text:
Wordpress posts table gives InvalidValue error

I'm trying to use this script with a Wordpress database. I followed the README and created this simple import.rb file.
require 'contentful/database_importer'

class WordPressPostsTable
  include Contentful::DatabaseImporter::Resource

  self.table_name = 'wp_posts'
  self.content_type_id = 'wordpress_posts'
  self.content_type_name = 'Wordpress Post'

  id Contentful::DatabaseImporter::IdGenerator::Base, template: '{{content_type_id}}_{{title}}_{{index}}'

  field :post_title, maps_to: :title, type: :string
  field :post_content, maps_to: :content, type: :text
end

Contentful::DatabaseImporter.setup do |config|
  config.space_name = 'Blog'
  config.database_connection = 'mysql://wordpress:wordpress@db:3306/wordpress'
  config.locale = 'en-US'
end

Contentful::DatabaseImporter.run!

But when I try to run this with bundle exec ruby import rb, it returns with this stacktrace.
/usr/local/lib/ruby/2.3.0/time.rb:302:in `local': ArgumentError: argument out of range (Sequel::InvalidValue)
    from /usr/local/lib/ruby/2.3.0/time.rb:302:in `make_time'
    from /usr/local/lib/ruby/2.3.0/time.rb:366:in `parse'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/core.rb:334:in `string_to_datetime'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/timezones.rb:136:in `convert_input_timestamp'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/timezones.rb:77:in `convert_timestamp'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/database/misc.rb:300:in `to_application_timestamp'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:387:in `call'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:387:in `block in yield_rows'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:387:in `each'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:387:in `yield_rows'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:333:in `block in fetch_rows'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:192:in `_execute'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/utils/mysql_mysql2.rb:37:in `block in execute'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/database/connecting.rb:301:in `block in synchronize'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/connection_pool/threaded.rb:107:in `hold'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/database/connecting.rb:301:in `synchronize'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/utils/mysql_mysql2.rb:37:in `execute'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:1135:in `execute'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:374:in `execute'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/adapters/mysql.rb:318:in `fetch_rows'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:155:in `each'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:52:in `block in all'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:1052:in `_all'
    from /usr/local/bundle/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:52:in `all'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/resource_class_methods.rb:74:in `all'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/json_generator.rb:43:in `create_entries'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/json_generator.rb:14:in `block in generate_json'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/json_generator.rb:11:in `each'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/json_generator.rb:11:in `generate_json'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer/json_generator.rb:78:in `generate_json!'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer.rb:37:in `generate_json!'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer.rb:42:in `generate_json_file!'
    from /usr/local/bundle/gems/contentful-database-importer-0.6.0/lib/contentful/database_importer.rb:71:in `run!'
    from import.rb:28:in `<main>'

Any idea what this could be?

Hey @rainmaker2k,
I'm not entirely sure what may be going on without more context, apparently, the SQL Driver is failing to fetch a date from your wordpress table, but I can't for sure confirm this without knowing the structure of your database.
Cheers


text:
Change color of rich text

Is there any way to change the color of the rich text? Looking on Contentful, the only formatting options are related to bold, italic, etc -- no color options. And the underlying UITextView in this framework is private so it's not possible to access it directly and change the textColor. Am I missing something here, or is this feature just not available?

@oliveira-marcio ah thank you. I suspect this is the intended approach. I appreciate your help 🙏🏻


text:
Long edits are getting cut off / finish early

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS:       Windows 11 23H2 (Build 22361.4169)
- Continue: v0.8.52
- IDE:      VSCode 1.92.1
- Model:    deepseek-coder-v2:latest
- config.json:

{
  "models": [
    {
      "title": "Ollama",
      "provider": "ollama",
      "model": "AUTODETECT"
    }
  ],
  "customCommands": [
    {
      "name": "test",
      "prompt": "{{{ input }}}\n\nWrite a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
      "description": "Write unit tests for highlighted code"
    },
    {
      "name": "desc",
      "prompt": "{{{ input }}}\n\nWrite a comprehensive comment for each block of the selected code. It should describe what it does and show possible caveats.",
      "description": "Comment the highlighted code"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Starcoder 3b",
    "provider": "ollama",
    "model": "starcoder2"
  },
  "allowAnonymousTelemetry": false,
  "embeddingsProvider": {
    "provider": "transformers.js"
  },
  "contextProviders": [
    {
      "name": "open",
      "params": {
        "onlyPinned": false
      }
     }
  ],
  "experimental": {
    "readResponseTTS": true
  },
  "ui": {
    "showChatScrollbar": true
  },
  "docs": []
}

Description
While trying to convert a big Python2 file to Python3, output always stops after ~103 ± 3 lines.
It sometimes cuts off in the middle of a variable or function name.
The source-script is almost 600 lines.
The Ollama-log doesn't show any errors. It behaves as if the answer is complete after 2-3 Minutes:
[GIN] 2024/09/19 - 15:00:08 | 200 |         2m40s |       10.8.0.21 | POST     "/api/generate"
[GIN] 2024/09/19 - 15:03:41 | 200 |         2m18s |       10.8.0.21 | POST     "/api/generate"

I'm not sure if this is a timeout-issue or token exhaustion or something else entirely.
The Model has a context length of 163840 and an embedding length of 2048
When using starcoder2 (16384 context length and 3072 embedding length), I get ~150 lines.
To reproduce

Find a big Python 2 script and open it in VS-Code
Select All, press Ctrl+I
Enter "Convert this Python2 program to Python3"

Log output
No response

Hi @Snowman-25 , thanks for the detailed writeup here. Interesting that the line cutoff is so consistent.
Nothing obvious comes to mind for me here, @sestinj , any thoughts?

Same issue I used gemini flash and pro models both got cutoff at a similar area.

You can try setting completionOptions.maxTokens in your config.json. We recently increased the default value for this, and I believe that the change is still in pre-release

You can try setting completionOptions.maxTokens in your config.json. We recently increased the default value for this, and I believe that the change is still in pre-release

yep this fixed it for me . I was previously adding  "maxTokens": 4096, which wasn't working but now adding :
"completionOptions": {
"maxTokens": 4096
},
fixes it for me .

Any specific reason why maxTokens isn't equal to the context length of the selected model? I may be confusing words here though, not an AI model expert

authors: Haripritamreddy Patrick-Erichsen Snowman-25 btebbutt sestinj

repo: continuedev/continue


text:
make demo, make ssh-build is not working with Vagrant 1.8.5

Here is the error log :
make ssh-build
vagrant box update
==> netplugin-node3: Checking for updates to 'contiv/centos72'
   netplugin-node3: Latest installed version: 0.7.0
   netplugin-node3: Version constraints: 0.7.0
   netplugin-node3: Provider: virtualbox
==> netplugin-node3: Box 'contiv/centos72' (v0.7.0) is running the latest version.
CONTIV_NODE_OS= vagrant up
Bringing machine 'netplugin-node1' up with 'virtualbox' provider...
Bringing machine 'netplugin-node2' up with 'virtualbox' provider...
Bringing machine 'netplugin-node3' up with 'virtualbox' provider...
==> netplugin-node1: Checking if box 'contiv/centos72' is up to date...
==> netplugin-node1: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> netplugin-node1: flag to force provisioning. Provisioners marked to run always will still run.
==> netplugin-node1: Running provisioner: shell...
SSH authentication failed! This is typically caused by the public/private
keypair for the SSH user not being properly set on the guest VM. Please
verify that the guest VM is setup with the proper public key, and that
the private key path for Vagrant is setup properly as well.
make[1]: *** [start] Error 1
make: *** [demo] Error 2

I met this same problem, it seems to be a file permission issue.
Here's a command line to change it, open another terminal and run it when you see 'make demo' trying to connect to a demo node:
vagrant ssh netplugin-node1 -c 'chmod 700 .ssh; chmod 600 .ssh/authorized_keys'

@yuxiangning : Please take a look at this PR add that line Vagrantfile of netplugin repo.
If you have Vagrant 1.8.5 and Vbox 5.1 then it will solve your purpose.
Otherwise,
Please install vagrant 1.8.4 and Vbox 5.0

@gaurav-dalvi thank you!

Fixed via this PR : https://github.com/contiv/netplugin/pull/504
Closing !

authors: gaurav-dalvi yuxiangning

repo: contiv/netplugin


text:
Reimplement simple robot tests

sanity.robot implements simple "host to pod" and "pod to pod" communication. This suite is compatible and rely on the test environment created by vagrant.
Setting up and running robot on windows is now available too, see readme.

Coverage decreased (-0.1%) to 72.008% when pulling e086307dc2fade88413750a22d84491b36a1442d on pgubka:dev into 36e3af3608cf87aa1cab926a5ed0dec2d018e9d8 on contiv:dev.

authors: coveralls pgubka

repo: contiv/vpp


text:
🛑 CC - BACKOFFICE POC is down

In 0780b4f, CC - BACKOFFICE POC (https://dev.netz-sap.macoapp.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CC - BACKOFFICE POC is back up in fb96253 after 8 minutes.

repo: conuti-das/status-nbsap


text:
how can play with stream bytes without videourl

Hello, I have a video stream as bytes in mybackend. Like the below;
string pathAndFilename = "file://file.xx.xom.tr//video.mp4";
        WebClient webClient = new WebClient();
        using (Stream stream = webClient.OpenRead(pathAndFilename))
        {
            // Process image...
            byte[] data1 = new byte[stream.Length];
            stream.Read(data1, 0, data1.Length);

        }

How can give this bytes to videcomponent to play? Is it possible playing with byte stream without giving any url?

If you can get the byte stream into format that a <video> element would understand (blob, MediaStream, base64 encoded string) then it will work. If you aren't playing a video from youtube or facebook etc, ReactPlayer just renders a basic <video> under the hood.

repo: cookpete/react-player


text:
[Bug]: terminal websocket error / never connecting

Error Message and Logs

Steps to Reproduce

go to terminal
observe error in console

Example Repository URL
No response
Coolify Version
v4.0.0-beta.358
Are you using Coolify Cloud?
No (self-hosted)
Operating System and Version (self-hosted)
No response
Additional Information
To be able to update my logto instance i need to run database alterations via CLI but the terminal doesn't connect.
Previously I was able to do it via execute command
The domain is proxied by cloudflare. The terminal works correctly on the test instance of coolify (another server) with coolify 4.0.0-beta.347 the same coolify version which would suggest that it has something to do with the CF configs
Possibly related to https://github.com/coollabsio/coolify/discussions/2825 (still investigating)
https://github.com/coollabsio/coolify/issues/3649

Very odd - after changing my instance domain to another domain, saved, set it back... the websocket connection now works

repo: coollabsio/coolify


text:
Fix WebKit conditionalUI issues

Why
Mobile WebKit versions below iOS 17.4 have strict (and buggy) rules the restrict when conditional UI can be started. In this task we add extra logic that starts conditional UI only after the first user click on the component.
Acceptance criteria

[ ] passkey login, passkey register and conditional UI still work
[ ] tests should be conducted on iOS Safari and Chrome (pre 17.4 and 17.4)
[ ] regression tests should be conducted on MacOS Safari and Chrome

Can be tested here: https://feature-user-action-research.react.playground.corbado.io/pro-6698593986287122356/auth

repo: corbado/javascript


text:
🛑 Guangdianyun is down

In b0f594c, Guangdianyun (https://www.guangdianyun.tv) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Guangdianyun is back up in 9be2207.

repo: corcd/charlotte


text:
CORE-20247: InvalidParamsException: unable to find master wrapping key XXXXX in tenant YYYYY

In rare cases we have got a clash when generating key alias. This caused wrapping key not being saved in tenant's db as the alias was already cached as used. When generating key pair for the alias, wrapping key couldn't be find and the operation has failed.
The clashes happened, because we converted random uuid into string and then into bytes before converting it to hex and taking 12 chars. Conversion to string diluted the randomness of the uuid.
We are introducing a new function that converts uuid into bytes directly, keeping the randomness and therefore preventing the clashes to happen much less often.
Here is the output of random uuid (0), using new conversion + toHexString (1) and using old conversion toString().toByteArray() + toHexString (2)
0: 4b40ae93-2342-4295-9ee7-7b0e4dff12cb
1: 4B40AE93234242959EE77B0E4DFF12CB
2: 34623430616539332D323334322D343239352D396565372D376230653464666631326362
0: 2b57f797-ab8c-47ff-9dfa-3f9c2f4d836b
1: 2B57F797AB8C47FF9DFA3F9C2F4D836B
2: 32623537663739372D616238632D343766662D396466612D336639633266346438333662
0: 83452f7a-a4db-4b73-91ca-e8130cb5a0d7
1: 83452F7AA4DB4B7391CAE8130CB5A0D7
2: 38333435326637612D613464622D346237332D393163612D653831333063623561306437

Is there other places we want to address this? We could raise a separate ticket for it.

Is there other places we want to address this? We could raise a separate ticket for it.

Yes, there are other places. I wanted to do it in a separate PRs, but it does make sense to raise a separate ticket (done here).

repo: corda/corda-runtime-os


text:
Release v0.3.0

Update CHANGELOG.
The version number will stay at 0.3.0 until the next release. No more pre-release version bumping as discussed on Telegram.

Should we include the internal changes in the CHANGELOG?

Version information in API output (#52)
Integrate connection pooling for redis with r2d2 (#43, #45)

changelog fixed.

Sure, looks like I forgot that one!

Ah, that's already included here:
- [added] Top level `get_version` function (#4)
- [added] Add `LibraryVersions` status modifier (#4)

nice :smile: :rainbow:

Cool, will merge and release as soon as CI is done.

repo: coredump-ch/spaceapi-server-rs


text:
Force update gem nokogiri to '1.11.0.rc4'

This counters CVE-2020-26247,
"XML::Schema input is now "untrusted" by default".
For more information, see:
https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m
This is debatable. We are almost certainly not vulnerable, because we
never use Nokogiri's XML Schema system. In addition, this recommended
fix uses a release candidate version of a library, instead of a final
release, and we generally avoid doing that. However, it's hard to be
certain that there's no exploit, and this release candidate
appears to be very solid for our purposes. I think there
are good arguments to use this nokogiri release candidate, and that there
are also good reasons not to use it. Sadly I must make some decision;
no decision is a decision. I've made a judgement call to
use the release candidate version with the security update.
I think the risk is smallest if we upgrade now for this specific case.
Signed-off-by: David A. Wheeler dwheeler@dwheeler.com

@jdossett - I intend to merge this soon.

repo: coreinfrastructure/best-practices-badge


text:
Bloodhound: getIntersection - compare same as sorting

There is a huge bug.
If my ids are integers, they got sorted as string ( from js definition of sort - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort ), but compared as integers.
It is not really working for me!!

:shrug:


text:
Clair does not find any layer {"Error":{"Message":"could not find layer"}}

I'm new to Clair and haven't been able to perform any analysis operations so far.
Please check the steps I've followed and guide me towards a solution.
Some of the issues raised here indicate Clair does not work with docker versions newer that 1.9, while other say only the local image analysis is impacted. My version is 1.12
# docker --version
Docker version 1.12.6, build 78d1802

I've installed Clair using the Kubernetes approach.
Health is working:
curl -X GET -I http://192.168.53.150:30061/health
HTTP/1.1 200 OK
...

Namespace GET call works:
curl -X GET -i http://192.168.53.150:30060/v1/namespaces
HTTP/1.1 200 OK
...
{"Namespaces":[{"Name":"debian:7"},{"Name":"debian:8"},{"Name":"debian:unstable"},{"Name":"debian:9"},{"Name":"ubuntu:12.04"},{"Name":"ubuntu:16.10"},{"Name":"ubuntu:12.10"},{"Name":"ubuntu:15.10"},{"Name":"ubuntu:15.04"},{"Name":"ubuntu:14.04"},{"Name":"ubuntu:16.04"},{"Name":"ubuntu:14.10"},{"Name":"ubuntu:13.04"},{"Name":"centos:6"},{"Name":"centos:5"},{"Name":"centos:7"}]}

The first image I tried to scan was the official centos provided image which i've pulled, tagged and pushed to my local registry.
docker  history --no-trunc localhost:5000/centos
IMAGE                                                                     CREATED             CREATED BY                                                                                SIZE                COMMENT
sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf   4 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]                                                                0 B
<missing>                                                                 4 weeks ago         /bin/sh -c #(nop)  LABEL name=CentOS Base Image vendor=CentOS license=GPLv2 build-date=20170406     0 B
<missing>                                                                 4 weeks ago         /bin/sh -c #(nop) ADD file:807143da05d70138e54c4a25c6c3ea64ad1096982333ef3b94a366580be40f52 in /    192.5 MB

Verifying a layer can be retrieved from local registry (executed also in the Clair container):
curl -X GET -i http://192.168.53.150:5000/v2/centos/blobs/sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf
HTTP/1.1 200 OK
...
{"architecture":"amd64","config":{"Hostname":"f85c553c1496",
...

Now comes the POST layer call to Clair:
curl -X POST -i http://192.168.53.150:30060/v1/layers -d '{"Layer": {"Name": "sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf","Path": "192.168.53.150:5000/v2/centos/blobs/sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf","Format": "Docker"}}'

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=utf-8
Server: clair
Date: Fri, 05 May 2017 11:07:55 GMT
Content-Length: 45

{"Error":{"Message":"could not find layer"}}

Clair log shows these entries:
2017-05-05 11:07:55.737827 E | worker: layer sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf: failed to extract data from 192.168.53.150:5000/v2/centos/blobs/sha256:a8493f5f50ffda70c2eeb2d09090debf7d39c8ffcd63b43ff81b111ece6f28bf: could not find layer
2017-05-05 11:07:55.737934 I | api: 172.77.29.1:58121 "POST /v1/layers" 400 (2.231936ms)

Thanks!

Hi there,
You're having this issue because you're POSTing a manifest and not a layer. To use the Clair API correct, you must iterate over the list of layers in the proper order (base layer -> leaf) and provide Clair the URLs for those with their respective Parents.
You also need to use a unique name for the Name field and not only the SHA256 checksum. This is because Clair layer names must be globally unique, but SHA256s can appear multiple times in a given ancestry and across the ancestries of different images.

Thanks for the quick response.
Based on your answer my next question would be: how do I get to the layer ids?
The little info I've found hints the layers are available using docker inspect:
docker inspect 8315978ceaaa
...
"RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:d73c31c5daa6dd0f708bb547d48d103b63004fa8365515a0e40b4af620347148"
            ]
        }
    }
]

When using this id in the layers POST I get the same problem. Furthermore the Path created with this id no longer works and shows this error:
{"errors":[{"code":"BLOB_UNKNOWN","message":"blob unknown to registry","detail":"sha256:d73c31c5daa6dd0f708bb547d48d103b63004fa8365515a0e40b4af620347148"}]}

The api_v1.md documentation shows the Path is created like this:
"Path": "https://mystorage.com/layers/523ef1d23f222195488575f52a39c729c76a8c5630c9a194139cb246fb212da6/layer.tar",

Other issue here suggest it is based on the local docker registry with "-" instead of namespace:
"Path": "localhost:5000/v1/-/blobs/....",

How can I obtain the layer.tar file?
Thanks!

I also have the same question...

Have you read https://github.com/coreos/clair/blob/master/Documentation/api_v1.md#post-layers?

How can I obtain the layer.tar file?

This depends on the registry with which you're integrating. This is beyond the scope of Clair maintainers to be answering, so you should refer to the docker registry docs. The quick description is that Manifests contain the list of layers and the registry API has a route for downloading individual layers.

Thanks for pointing out the manifest contain the layers. You had mentioned earlier I had posted a manifest and got fixated it was THE ONE manifest that has the layers, but you were referring probably to the format.
@chen-dwolla Hope this helps you.
This is the docker registry I'm using:
docker search registry
NAME                                      DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
registry                                  The Docker Registry 2.0 implementation for...   1452      [OK]

This is an example how to retrieve the manifest for a specified image and tag:
curl -X GET -i http://192.168.178.25:5000/v2/centos/manifests/latest
...
{
   "schemaVersion": 1,
   "name": "centos",
   "tag": "latest",
   "architecture": "amd64",
   "fsLayers": [
      {
         "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
      },
      {
         "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
      },
      {
         "blobSum": "sha256:32c4f4fef1c65e47e41704aabeb99e984f1c01e3541e48354b09300fa5b2d068"
      },
      {
         "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
      }
   ],
...

Now the POST calls to the Clair API work:
curl -X POST -i http://192.168.178.25:6060/v1/layers -d
'{"Layer": {"Name": "test1",
"Path": "http://192.168.178.25:5000/v2/centos/blobs/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
"Format": "Docker",
"ParentName": ""}}'

And one more example with parent:
curl -X POST -i http://192.168.178.25:6060/v1/layers -d
'{"Layer": {"Name": "test2",
"Path": "http://192.168.178.25:5000/v2/centos/blobs/sha256:32c4f4fef1c65e47e41704aabeb99e984f1c01e3541e48354b09300fa5b2d068",
"Format": "Docker",
"ParentName": "test1"}}'

Finding out the results (don't forget about the query parameters):
 curl -X GET -i http://192.168.178.25:6060/v1/layers/test2?features&vulnerabilities
{
   "Layer":{
      "Name":"test2",
      "NamespaceName":"centos:6",
      "ParentName":"test1",
      "IndexedByVersion":3,
      "Features":[
         {
            "Name":"chkconfig",
            "NamespaceName":"centos:6",
            "VersionFormat":"rpm",
            "Version":"1.3.49.5-1.el6",
            "AddedBy":"test2"
         },
         {
            "Name":"curl",
            "NamespaceName":"centos:6",
            "VersionFormat":"rpm",
            "Version":"7.19.7-52.el6",
            "Vulnerabilities":[
               {
                  "Name":"RHSA-2017:0847",
                  "NamespaceName":"centos:6",
                  "Description":"The curl packages provide the libcurl library and the curl utility for downloading files from servers using various protocols, including HTTP, FTP, and LDAP. Security Fix(es): * It was found that the fix for CVE-2015-3148 in curl was incomplete. An application using libcurl with HTTP Negotiate authentication could incorrectly re-use credentials for subsequent requests to the same server. (CVE-2017-2628) This issue was discovered by Paulo Andrade (Red Hat).",
                  "Link":"https://access.redhat.com/errata/RHSA-2017:0847",
                  "Severity":"Medium",
                  "FixedBy":"0:7.19.7-53.el6_9"
               }
            ],
            "AddedBy":"test2"
         },

Thanks again!

@tituslup Thanks a lot, it's really helpful.
@jzelinskie Thank you for the explanation as well.

authors: Quentin-M chen-dwolla jzelinskie tituslup

repo: coreos/clair


text:
Setting node label container-linux-update.v1.coreos.com/reboot-paused=true does not prevent reboots

Doc says:
reboot-paused   true/false

May be set to true by an admin so the update-operator will ignore a node. Note that CLUO only coordinates reboots, update_engine still installs updates which are applied when a node reboots (e.g. powerloss).

kubectl label nodes kylebrown-worker-0 container-linux-update.v1.coreos.com/reboot-paused=true

A customer reported this did not stop node reboots. Will spend some time confirming in my own cluster.

What version of CLUO? Any logs from the update-operator?

Oh wait. Docs show container-linux-update.v1.coreos.com/reboot-paused=true as a label, but its an annotation. Can you annotate the node instead? We can fix the docs.

Please re-open if there's an issue with the annotation.
kubectl annotate nodes kylebrown-worker-0 container-linux-update.v1.coreos.com/reboot-paused=true

authors: dghubble kbrwn

repo: coreos/container-linux-update-operator


text:
Allow for UID to be specified

Services like NFS require the use of consistent UID numbers.  Allowing specification of a UID should simplify account management across systems.

+1 both for GID and UID.

The patch for this is pretty trivial, just add "uid": "--uid" to the list of arguments in add_user. There's a PR over at LaunchPad. The diff from there is:
=== modified file 'cloudinit/distros/__init__.py'
--- cloudinit/distros/__init__.py	2015-01-26 16:14:06 +0000
+++ cloudinit/distros/__init__.py	2015-04-14 14:36:25 +0000
@@ -318,6 +318,7 @@
             "gecos": '--comment',
             "homedir": '--home',
             "primary_group": '--gid',
+            "uid": '--uid',
             "groups": '--groups',
             "passwd": '--password',
             "shell": '--shell',

Just be aware that you must specify the uid argument as a string, otherwise it will not be included.
In other words, do:
  uid: "500"

not
  uid: 500

+1 for GID / UID.

+1 for GID/UID

authors: akadoya brianredbeard jonhoo ntrifunovic terrisgit

repo: coreos/coreos-cloudinit


text:
Label overlay directories appropriately

New files and copy_up() operations on overlayfs will check permissions
against the security context on the upper directories in the overlayfs
mounts. Label them all appropriately.

Part of the fix for https://github.com/coreos/bugs/issues/1015

lgtm

repo: coreos/docker