text:
Add CNDL

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://twitter.com/candle_labs
Project team background: https://candlelabs.org
Project basic information: Decentralized Human-focused metaverse - Candle (CNDL) is the utility and governance token for the Candle Protocol. This protocol is designed to decentralize social media and build out a community governed and moderated place to discuss and share thoughts and ideas.
Media publications: CoinTelegraph
Tradeable exchanges: Decoin, Tokpie, BankCEX, Coinbase
Official Announcement:
Twitter Link
Recommended Gas Limit (For ERC-20 project teams) for transaction: 40,000

1.Your PR is missing project information
2.Official Twitter is missing imToken listing announcement
3.Please don't upload more than one logo

1.Your PR is missing project information
2.Official Twitter is missing imToken listing announcement
3.Please don't upload more than one logo

Fixing now

Twitter Link

Please merge

Merge me

Please merge

Please do not delete in the local database

Fixed it

Please do not delete in the local database

Good to merge? Thanks

You have not uploaded the LOGO, please do not make changes in your database

You have not uploaded the LOGO, please do not make changes in your database

Fixed

Not sure if the project is still being maintained。

提交信息有问题，我先关闭这个 PR


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

In 1c006ba, chattedechevre.partouze-cagoule.fr (https://chattedechevre.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: chattedechevre.partouze-cagoule.fr is back up in a553398.

source: gharchive/issue

repo: constructions-incongrues/status

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 computertruck.parishq.net is down

In 292862a, computertruck.parishq.net (https://computertruck.parishq.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: computertruck.parishq.net is back up in b88ed91.


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

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

HTTP code: 0
Response time: 0 ms

Resolved: foutre.partouze-cagoule.fr is back up in 332b203 after 8 hours, 30 minutes.

Resolved: foutre.partouze-cagoule.fr is back up in 9eeb317 after 8 hours, 30 minutes.


text:
feat!: rename user to ubuntu

Rename default user from user back to ubuntu

closes #572

Surprised to learn we have some hardcoded PATHs though

yes, there the env isn't yet available 🙃

source: gharchive/pull-request

repo: containerbase/base


text:
Windows Containers are leaked when container fails to start

Description
On Windows, when passing a command to a container to run, if the command isn't valid then containerd gives error and clean up its resources but HCS still shows a container is on the system.  If you re-run container with the same name you get an error.

Steps to reproduce the issue:
ctr image pull k8s.gcr.io/pause:3.4.1
ctr.exe run --rm k8s.gcr.io/pause:3.4.1 test-1 echo c:\License.txt
ctr: hcsshim::System::CreateProcess test-1: The system cannot find the file specified.
(extra info: {"CommandLine":"echo c:\\License.txt","User":"ContainerUser","Environment":{"PATH":"C:\\Windows\\system32;C:\\Windows;"},"CreateStdInPipe":true,"CreateStdOutPipe":true,"CreateStdErrPipe":true}): unknown

Containerd doesn't know about the container:
ctr c ls
CONTAINER    IMAGE    RUNTIME
ctr t ls
TASK    PID    STATUS

but hcs has the container in the list:
 hcsdiag list
test-1
    Windows Server Container,   Unknown

Try to run a valid command:
 ctr.exe run --rm k8s.gcr.io/pause:3.4.1 test-1 cmd /c echo c:\License.txt
ctr: hcsshim::CreateComputeSystem test-1: A virtual machine or container with the specified identifier already exists.
(extra info: {"Owner":"containerd-shim-runhcs-v1.exe","SchemaVersion":{"Major":2,"Minor":1},"Container":{"Storage":{"Layers":[{"Id":"e67d9508-fe76-54e0-b098-cabfb7356fd7","Path":"C:\\ProgramData\\containerd\\root\\io.containerd.snapshotter.v1.windows\\snapshots\\24"},{"Id":"e
3732ab4-a8b2-5962-8e88-a0a76ee83d86","Path":"C:\\ProgramData\\containerd\\root\\io.containerd.snapshotter.v1.windows\\snapshots\\23"},{"Id":"51d377df-069c-5b3a-8cb0-e86be7e7cfbe","Path":"C:\\ProgramData\\containerd\\root\\io.containerd.snapshotter.v1.windows\\snapshots\\22"},
{"Id":"994b900c-05b9-5a61-b236-35342d301241","Path":"C:\\ProgramData\\containerd\\root\\io.containerd.snapshotter.v1.windows\\snapshots\\21"}],"Path":"\\\\?\\Volume{0cdda4ac-837b-11eb-b279-845c959994a0}\\"},"Networking":{"AllowUnqualifiedDnsQuery":true,"Namespace":"45B223AA-1
9BF-40D6-9F54-9578BA121B94"}},"ShouldTerminateOnLastHandleClosed":true}): unknown

Describe the results you received:
Describe the results you expected:
What version of containerd are you using:
Tried with 1.4  and 1.5
$ containerd --version
containerd github.com/containerd/containerd v1.4.3 269548fa27e0089a8b8278fc4fc781d7f65a939b
containerd github.com/containerd/containerd v1.5.0-beta.3 02334356d0774a5b194e67b5f1383fd2485ea67a

Any other relevant information (runC version, CRI configuration, OS/Kernel version, etc.):

runc --version
$ runc --version

crictl info
$ crictl info

uname -a
$ uname -a

cmd /c ver

Microsoft Windows [Version 10.0.17763.1577

/cc @kevpar

@claudiubelu

I've tried this as well with containerd v1.4.3, and can confirm the issue. I've also tried something similar with crictl, but that's not an issue there, the failed container still shows up when listing the containers (crictl --runtime-endpoint=npipe://./pipe/containerd-containerd ps), can be removed, and another can be created in its stead, which can then be started.

I've tried it out using the latest main version and latest hcsshim, and this problem doesn't occur anymore:
PS C:\tmp> ctr.exe --address //./pipe//run/containerd-test/containerd run --rm k8s.gcr.io/pause:3.4.1 test-1 echo c:\License.txt
ctr: hcs::System::CreateProcess test-1: The system cannot find the file specified.: unknown
PS C:\tmp> ctr.exe --address //./pipe//run/containerd-test/containerd run --rm k8s.gcr.io/pause:3.4.1 test-1 cmd /c echo c:\License.txt
c:\License.txt
PS C:\tmp> ctr.exe --address //./pipe//run/containerd-test/containerd container list
CONTAINER    IMAGE    RUNTIME

I've added a test that will make sure we don't have any regressions on this: https://github.com/containerd/containerd/pull/5578

I think we can close this issue. As seen in the previous comments, we haven't seen this anymore, and we have a test for it as well.
/close

authors: claudiubelu jayunit100 jsturtevant

repo: containerd/containerd


text:
Proposal: Add Clone function on Snapshotter

Proposal
Add a Clone function to the Snapshotter interface which can capture the state of an active snapshot. The output is always a writable active snapshot. It can be immediately committed without making any changes or may further altered and commit. Like any other active snapshot, it must be committed or removed. Clone on a committed snapshot allows renaming of committed snapshot without modification.
Additionally formalize that Commit finalizes an active snapshot, not allowing Remove after Commit or multiple calls to Commit on the same snapshot. This is already the current behavior of the overlay driver and should be formalized in the interface. With the existence of the Snapshot function there is no need to support multiple calls to Commit. The use case for multiple Commit would be covered by calling Snapshot + Commit.
Diff
        // After commit, the snapshot identified by key is removed.
        Commit(ctx context.Context, name, key string, opts ...Opt) error

+       // Clone copies a snapshot to a new snapshot of the same type.
+       //
+       // An active clone will create a new active snapshot with the same
+       // content but changes in one will not be reflected in the other.
+       // A committed clone will create a new read only snapshot of the
+       // same content.
+       //
+       // Options:
+       //   WithParent defines the parent to use for the target.
+       //     If the target parent differs from the source, the snapshotter
+       //     may either rebase or return ErrNotImplemented
+       Clone(ctx context.Context, target, source string, opts ...Opt) error
+
        // Remove the committed or active snapshot by the provided key.

WithParent option
Used to support parent verification or rebasing. If the parent does not exist, then the operation must error with ErrNotFound. If the parent exists, but is not the source parent, the snapshotter must either perform a rebase (applying the changes between source and source's parent to the parent) or return ErrNotImplemented (should not return ErrInvalidArgument).
WithLabels option
The new snapshot will use the labels provided through the WithLabels option. Options should not be copied over from the source
Cross namespace copying
A source namespace could be provided on the context to support cloning across namespaces. In this case the source and target may be the same name. Using the same source and target within a single namespace will always return ErrAlreadyExists.
Snapshot flow diagram changes
I diagrammed what the changes may look like to the snapshot model.
https://docs.google.com/a/docker.com/presentation/d/1LYVEkP6VdYV96IO5lhxTwujtpilhzNPAouO0qGUa4z8/edit?usp=sharing
Overlay implementation
When Clone is called in active overlay snapshot, the content of the snapshotted upper directory will be copied to a new active. When Clone is called on a commited overlay snapshot, the new snapshot will just point to the same on disk layer.
Btrfs implementation
Just uses snapshots how Commit was done previously. As part of this change Commit will also remove the original source after the snapshot is completed. Cloning a committed snapshot will just point to the original source.

google doc seems private :sweat_smile:

@AkihiroSuda updated, didn't realize default scope even with a share link was org restricted. Please give it a try.

Thanks for drawing new diagrams!  A few questions:

Would every Snapshotter be required to implement an online, mutable copy as part of Snapshot?
On slide 5, what makes undefined(a, P1) different from Prepare(a, P1)?  Is it the fact that P2's parent is P0?

We decided this dual nature was kind of confusing so left it open as a possible future function, name yet to be defined.  [...]  Should I just remove the slide?

I think that makes sense unless it's something we still want to solve for 1.0.0.  In my view, it's better to document the design that we're implementing than future potential options that we're not.

@samuelkarp agreed, when we update the design we will not include that slide. Just made the slides as a place to capture the diagrams for the future doc update.

So does this Snapshot function is just  to support Multiple Commit use case?
Also this means consumers of Snapshot drivers, must  decide prior if they want to make any changes after commit. e.g. Image builder should use snapshot + commit for intermediate builds and may use Commit  to squash the image.
Also, what will be property of Commit layer. i.e. it will be equals to View or  View is required to read only operations too? Currently overlay driver gives error Cannot commit view, If I tries to do multiple commit (https://github.com/docker/containerd/pull/582) .

This has been implemented as a subcommand in ctr

Renaming this, it threw me off as well. This is about a potential function on the Snapshotter interface not ctr snapshot.

Looking at this with experience eyes, I think there is a definite use case for this proposal for backups and other online snapshotting.
I think for sanity's sake, we should consider calling it Clone or Copy.
Adding to the 1.2 milestone.

Looking at this with experience eyes, I think there is a definite use case for this proposal for backups and other online snapshotting.

Do we support using a c8d snapshot as a persistent data volume?

Updated this with more details, considering this for 1.2 to support BuildKit cross namespace exporting

Mostly LGTM on this proposal. Glad its here.

A source namespace could be provided on the context to support cloning across namespaces. In this case the source and target may be the same name. Using the same source and target within a single namespace will always return ErrAlreadyExists.

Might want to detail this workflow a little more. How are the source and target namespaces specified?

This hasn't been in a milestone for a few releases; do we want to resurrect this and possibly see if there is interest in the community to work on it?

Just to chime in with some community interest, I just finished up a bunch of work for the upcoming Buildkit release that required extending the containerd snapshotter interface with a method called Merge. Merge is different than Clone, but has a lot of conceptual overlap with the WithParent rebasing feature described here and probably could have taken advantage of Clone if it had existed. If interested, background on the Buildkit features that required Merge are in these docs.
While I can't just literally upstream Merge and rename the method to Clone due to the differences, it would still be very nice to be able to use Clone in Merge's implementation if nothing else, so if there's still interest in Clone existing I could potentially help out with it (time permitting of course).

authors: AkihiroSuda crosbymichael dmcgowan estesp kunalkushwaha samuelkarp sipsma stevvooe


text:
1.7: Add back support for OTLP config from toml

This was broken due to 9360e37169f2ba3135f7a6f39a3ab7c9231abbd6 (backport from main).
The backport should not have broken the toml config so this more or less restores that.
This treats the env vars as preferred.
It is not perfect since, as an example, Endpoint could be set on the config and the env to set the protocol could be set and these could conflict, however I think this is an unlikely scenario and people should use one or the other, not both.
This change converts the config into the relevant environment variables before initializing tracers.
Fixes #10358

cc @vvoland

@cpuguy83 may need a similar patch for 1.6 as well, or at least I see there was a backport to 1.6 as well;

https://github.com/containerd/containerd/pull/9993


text:
[release/1.1] cherry-pick: enhance: update v1/v2 runtime

Cherrypick of https://github.com/containerd/containerd/pull/2769.
For https://github.com/containerd/containerd/issues/2709.
Only v1 change is cherry-picked.
Signed-off-by: Wei Fu fuweid89@gmail.com

Codecov Report

Merging #2774 into release/1.1 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/1.1    #2774   +/-   ##
============================================
  Coverage        48.99%   48.99%
============================================
  Files               85       85
  Lines             7603     7603
============================================
  Hits              3725     3725
  Misses            3203     3203
  Partials           675      675

Flag
Coverage Δ

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

Continue to review full report at Codecov.

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

authors: Random-Liu codecov-io


text:
Added filters to snapshots API

Fixes #3708
Added filters to snapshots and walk function interface.

@Zyqsempai thanks for working on this.  Can you sign your commits with the proper DCO? https://github.com/containerd/project/blob/master/CONTRIBUTING.md#sign-your-work
Each commit will need to be signed, feel free to keep them separate or squash and force push your branch.

The vendored snapshotters (aufs, zfs) need to be updated to the new Walk(..) signature before this change can pass CI:
cmd/containerd/builtins.go:1: vendor/github.com/containerd/aufs/aufs.go:81:9: cannot use &(snapshotter literal) (value of type *snapshotter) as snapshots.Snapshotter value in return statement: wrong type for method Walk (typecheck)

Of course there is a bit of a chicken-and-egg problem in getting those fixed and re-vendored without this change to the signature being merged--might have to temporarily point their vendors to a branch of containerd with the change?

@estesp I opened PR's for them also.

Codecov Report

Merging #3709 into master will increase coverage by 3.4%.
The diff coverage is 50.74%.

@@            Coverage Diff            @@
##           master    #3709     +/-   ##
=========================================
+ Coverage   41.98%   45.38%   +3.4%
=========================================
  Files         131      118     -13
  Lines       14536    11699   -2837
=========================================
- Hits         6103     5310    -793
+ Misses       7525     5476   -2049
- Partials      908      913      +5

Flag
Coverage Δ

#linux
45.38% <50.74%> (-0.03%)
:arrow_down:

#windows
?

Impacted Files
Coverage Δ

snapshots/storage/bolt.go
59.12% <10%> (-0.6%)
:arrow_down:

snapshots/btrfs/btrfs.go
57.39% <100%> (-0.9%)
:arrow_down:

snapshots/devmapper/snapshotter.go
66.39% <100%> (ø)
:arrow_up:

snapshots/native/native.go
52.68% <100%> (+10.26%)
:arrow_up:

snapshots/overlay/overlay.go
52.52% <100%> (ø)
:arrow_up:

metadata/snapshot.go
56.44% <50%> (+8.62%)
:arrow_up:

metadata/adaptors.go
54.63% <90.47%> (+14.16%)
:arrow_up:

remotes/docker/fetcher.go
42.5% <0%> (-7.5%)
:arrow_down:

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

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

... and 83 more

Continue to review full report at Codecov.

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

Basically, LGTM. But the CI green is not trust because the vendor check was broken 6days ago. I think we can remove the out of tree snapshotter plugins from vendor.conf shortly and then add it back after this one merged. is it ok?

@fuweid I agree, I was going to do that and forgot. Commented those out from vendor for now

authors: Zyqsempai codecov-io crosbymichael dmcgowan estesp fuweid


text:
Bump opencontainers/selinux from 1.10.0 to 1.10.1

Full Changelog:
https://github.com/opencontainers/selinux/compare/v1.10.0...v1.10.1
Specifically patch https://github.com/opencontainers/selinux/pull/173 which fixes the issue: https://github.com/containerd/containerd/issues/6767
Signed-off-by: Nabeel Rana nabeelnrana@gmail.com

Looks like you may have to run go mod tidy from within the integration/client directory as well (which also has a go.mod);
Files /home/runner/work/containerd/containerd/src/github.com/containerd/containerd/integration/client/go.mod and /tmp/tmp.PYcoKntieN/containerd/integration/client/go.mod differ
Files /home/runner/work/containerd/containerd/src/github.com/containerd/containerd/integration/client/go.sum and /tmp/tmp.PYcoKntieN/containerd/integration/client/go.sum differ

/ok-to-test


text:
[refactor] Add global flag process helper function

I'm so sorry I have to make a huge PR again.
After #1793, we have a types.GlobalCommandOptions, and for #1792 and #1791 and many refactor PR int he future, we may need to introduce a new helper function to process the global flag.
In this PR, I introduce the new helper function and use this function to process the global flag in all subcommand.
There may be some duplicated code for some subcommand like nerdctl run, I think this should be not a problem, I will merge it when I refactor the run command,
Signed-off-by: Zheao.Li me@manjusaka.me

(Not request changes)
In the current PR, most commands are refactored into a half-way state (e.g., global flag is processed (sometimes, repeatedly) whenever it's needed. Ideally, it should only be processed once at the entry of the command, and let other usage use the processed struct.
As an example, getVolumeStore calls processGlobalFlags, and getComposer calls getVolumeStore, which means each compose commands call processGlobalFlags at least twice (one in getVolumeStore, one in its own command if global flags are used).
Either way, we should highlight that helper functions (e.g., getVolumeStore) should be refactored to not call processGlobalFlags directly and instead use the struct created by the command.

nice catch. I have update all the PR to make sure call processGlobalFlags once for each command

@AkihiroSuda PTAL

repo: containerd/nerdctl


text:
drop dependency on xfs_freeze

Reported via email; we should instead just directly invoke the ioctl.  ostree has code for this we could make into a public C API, including the complex dance of doing this by forking a helper process to be robust against interruption.

This was done in https://github.com/containers/bootc/pull/102/commits/15de723ac2a9707523967aa4ee5c29875b94baa8

repo: containers/bootc


text:
WIP: Update nixpkgs

What type of PR is this?
/kind dependency-change
What this PR does / why we need it:
Bump nixpkgs.
Which issue(s) this PR fixes:

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

None

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 35.75%. Comparing base (4e0f474) to head (2444a51).
Report is 632 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2350      +/-   ##
==========================================
- Coverage   37.53%   35.75%   -1.78%
==========================================
  Files          15       15
  Lines        1268     1264       -4
  Branches      414      420       +6
==========================================
- Hits          476      452      -24
- Misses        526      552      +26
+ Partials      266      260       -6

@kwilczynski PTAL

/approve
/lgtm

/lgtm

authors: codecov-commenter kwilczynski rphillips saschagrunert

repo: containers/conmon-rs


text:
Use --systemd-cgroup for runtime commands

What type of PR is this?
/kind bug
What this PR does / why we need it:
This fixes the passing of systemd related annotations to the config, for example: https://github.com/opencontainers/runc/pull/2224
Which issue(s) this PR fixes:

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

Using `--systemd-cgroup` for runtime commands.

PTAL @rphillips @haircommander

lgtm
I'll defer to @haircommander for the final lgtm

Peter is AFK. Going to lgtm and we can iterate if we would like to change this PR further.
/lgtm

miss click
/lgtm

authors: rphillips saschagrunert


text:
Add critest run to CI

What type of PR is this?
/kind ci
What this PR does / why we need it:
We now run a critest suite with a pinned CRI-O release for each PR.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Needs https://github.com/containers/conmon-rs/pull/702 to not timeout during the attach test.
Does this PR introduce a user-facing change?

None

/lgtm

authors: haircommander saschagrunert


text:
Do not upload tarball any more

What type of PR is this?
/kind failing-test
What this PR does / why we need it:
There is no need for the artifact right now se we can stop uploading it every commit.
Which issue(s) this PR fixes:

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

None

Merging to unblock the CI

repo: containers/containrs


text:
Serve command fails silently

Hello,
Running the serve command with a wrong model name outputs a container ID that dies instantly without a reason.
Here is an example reproducer:
$ ramalama serve huggingface://ibm-granite/granite-7b-instruct
6aa6dc6cca217b28656990f69a7c602c28c40f64289d8cdb5c55e6ecccdc0828
$ ramalama ps
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
$

I tried to add an helpful message by calling the pull command before serve, but it looks like there is another issue in the glob f"{args.store}/models/*/{model}" because the Model class doesn't have a str method, resulting in the path to never match because it looks like:
ramalama/models/*/<ramalama.huggingface.Huggingface object at 0x7fa1c6e659a0>

How would you recommend to fix that issue?

I kinda wish we didn't detach by default because of reasons like this

I meant to add a check before calling ramalama.run_container in the Process CLI entrypoint, to ensure the model is pulled before starting the service.

The problem with just adding a check for the file, is that only helps debug one very specific issue. Like it is already checked if the file exists just in llama-server and we can't see the output

Right, so not detaching by default sounds great to me, may I propose such a change?

authors: TristanCacqueray ericcurtin

repo: containers/ramalama


text:
WIP: Huge Page Support: Add support for huge pages (needs qemu revendor)

Add support to launch virtual machines where the RAM is
allocated using huge pages. This is useful for running
with a user mode networking stack, and for custom setups
which require high performance and low latency.
Note: Needs revendoring of ciao/qemu changes https://github.com/ciao-project/ciao/pull/1449
Signed-off-by: Manohar Castelino manohar.r.castelino@intel.com

lgtm

just to be clear - this is 'pre-allocated' with huge pages is it?
no matter...
lgtm

@mcastelino Please rebase, the needed qemu changes should be there now.

LGTM

Coverage decreased (-0.01%) to 65.928% when pulling 27902cf28573d310ebe192bb682f5da8dbf02207 on mcastelino:topic/huge_pages into 04e519d758c64d52b51670fac68d58f2ddb752c7 on containers:master.

authors: coveralls grahamwhaley jodh-intel mcastelino sameo

repo: containers/virtcontainers

license_source: bigquery


text:
Ensure youki runs under podman

We need to be more defensive when deleting a container as podman executes delete twice and cleans up the cgroup of the container before we have a chance to clean it up.
Fixes #607

Codecov Report

Merging #613 (d0d756a) into main (52f83a0) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #613      +/-   ##
==========================================
- Coverage   70.04%   70.01%   -0.04%
==========================================
  Files          82       82
  Lines       10924    10933       +9
==========================================
+ Hits         7652     7655       +3
- Misses       3272     3278       +6

Wow, I was surprised to know that.

podman executes delete twice

LGTM

authors: Furisto codecov-commenter utam0k

repo: containers/youki


text:
Self-generated certificate is regenerated every 15 seconds

Do you want to request a feature or report a bug?
Bug
Did you try using a 1.7.x configuration for the version 2.0?

[ ] Yes
[X] No

What did you do?
I configured Traefik with Docker provider and swarmMode=true, and I deployed a service with an HTTPS entrypoint and no tls options.
What did you expect to see?
Traefik should generate a certificate for HTTPS and keep it, so that it can be added to trusted certificates in a browser.
What did you see instead?
Traefik generates a new certificate for HTTPS every 15 seconds, so the browser keeps telling that the certificate is not trusted.
Output of traefik version: (What version of Traefik are you using?)
Version:      2.0.1
Codename:     montdor
Go version:   go1.13.1
Built:        2019-09-26T16:18:03Z
OS/Arch:      linux/amd64

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
time="2019-09-30T13:54:52Z" level=debug msg="No default certificate, generating one"
...
time="2019-09-30T13:55:07Z" level=debug msg="No default certificate, generating one"
...
time="2019-09-30T13:55:22Z" level=debug msg="No default certificate, generating one"

Hi @bgranvea ,
Thanks for your interest in the project.
It seems to be a duplicate of #5381
So I will close this issue.

hum yes maybe it is the same root cause as #5381 but with swarmMode=true, it seems even worse as the certificate is regenerated even when no new container is deployed.
And I don't understand why you don't consider #5381 as a bug: IMHO the self-generated certificate feature is not usable with a browser.

Hi @bgranvea, for the "swarmMode" making this behavior even worse, it's related to the issues #5419. This issue had been closed and will be in the next 2.0.x release. You can already test it with the image containous/traefik:experimental-v2.0 if you want to live on the edge :)
As for #5381, we consider the "self generated certificate" as a "degraded" mode. If you're willing to use a self signed certificate for all of your services, we recommend generating one and setting Traefik to use it as explained in https://docs.traefik.io/v2.0/https/tls/. I personnaly use the awesome tool mkcert https://github.com/FiloSottile/mkcert which generate for multiple domains and wildcards including *.local, and install the CA in my browsers.

authors: bgranvea dduportal mmatur

repo: containous/traefik


text:
docker compose traefik2.0 not work with other docker services

Do you want to request a feature or report a bug?
Bug
Did you try using a 1.7.x configuration for the version 2.0?

[ ] Yes
[x] No

What did you do?
I setup docker-compose.yaml file with docker example whoami service. on a second docker-compose I added service whoami2.

What did you expect to see?
Firstly, expect to see routings on dashboard and services. Second expectation: see response on whoami.docker.localhost (works) and reponse on url whoami2.docker.localhost.
What did you see instead?
for bot services see information on dashboard. For whoami2.docker.localhost got "Gateway Timeout"
Output of traefik version: (What version of Traefik are you using?)

/ # traefik version
Version:      2.0.1
Codename:     montdor
Go version:   go1.13.1
Built:        2019-09-26T16:18:03Z
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
## docker-compose.yaml
version: '3.7'

services:
  traefik:
    image: "traefik:v2.0.1"
    container_name: traefik
    ports:
      - "80:80"      # The HTTP port
      - "8080:8080"  # The Web UI (enabled by --api)
    command:
      - "--log.level=DEBUG"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock  # So that Traefik can listen to the Docker events
      - ./traefik.yaml:/etc/traefik/traefik.yaml

  whoami:
    # A container that exposes an API to show its IP address
    image: containous/whoami
    labels:
      - "traefik.http.routers.whoami.rule=Host(`whoami.docker.localhost`)"

## traefik.yml

# Docker configuration backend
providers:
  docker:
    exposedbydefault: true

entryPoints:
  web:
    # Listen on port 80 for incoming requests
    address: :80

# API and dashboard configuration
api:
  insecure: true

# other-folder/docker-compose.yaml

version: '3.7'

services:

  whoami2:
    image: containous/whoami
    labels:
      - "traefik.http.routers.whoami2.rule=Host(`whoami2.docker.localhost`)"

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
docker up traefik whoami
Creating network "traefik_default" with the default driver
Creating traefik_whoami_1 ... done
Creating traefik          ... done
Attaching to traefik_whoami_1, traefik
whoami_1    | Starting up on port 80
traefik     | time="2019-10-01T20:51:55Z" level=info msg="Configuration loaded from file: /etc/traefik/traefik.yaml"

docker up traefik whoami2
Starting docker-wordpress_whoami2_1 ... done
Attaching to docker-wordpress_whoami2_1
whoami2_1    | Starting up on port 80

output whoami
curl -H Host:whoami.docker.localhost http://127.0.0.1
Hostname: 6b4f2dfe944f
IP: 127.0.0.1
IP: 172.25.0.2
GET / HTTP/1.1
Host: whoami.docker.localhost
User-Agent: curl/7.63.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 172.25.0.1
X-Forwarded-Host: whoami.docker.localhost
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: 9f14dd78222b
X-Real-Ip: 172.25.0.1

output whoami2
curl -H Host:whoami2.docker.localhost http://127.0.0.1
Gateway Timeout

Hi @fragtom , thanks for your interest in the project and this complete report!
As this is a configuration issue, could you switch to our community forum at https://community.containo.us/ to get support and knowledge from the community (maintainers included) please? The reason is that we use Github for tracking bugs and feature requests.
As a hint for your next steps (if it doesn't work use a community topic to mention me), you might want to check this page from Docker documentation at https://docs.docker.com/compose/networking/.
Each docker-compose stack has it's own private network: Traefik cannot reach the whoami containers because in another network. You have to merge the stacks OR declare external networks (https://docs.docker.com/compose/compose-file/#external-1).

@fragtom the way I  solve this I create a traefik network in the traefik's docker-compose file:
version: '3.7'
networks:
  traefik:
    name: traefik
services:
  traefik:
    image: "traefik:v2.0.1"
    container_name: 'traefik'
    networks:
      - traefik
    ports:
      - "80:80"      # The HTTP port
      - "8080:8080"  # The Web UI (enabled by --api)
    command:
      - "--log.level=DEBUG"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock  # So that Traefik can listen to the Docker events
      - ./traefik.yaml:/etc/traefik/traefik.yaml

And then use the same network in the other docker-compose files:
# other-folder/docker-compose.yaml

version: '3.7'
networks:
  traefik:
    external: true
services:

  whoami2:
    image: containous/whoami
    container_name: 'whoami'
    networks:
      - 'traefik'
    labels:
      - "traefik.http.routers.whoami2.rule=Host(`whoami2.docker.localhost`)"

Please notice the external part.
Hope this helps

That works for me, thnks
On Fri 25. Oct 2019 at 08:33, Valentin Vieriu notifications@github.com
wrote:

@fragtom https://github.com/fragtom the way I solve this I create a
traefik network in the traefik's docker-compose file:
version: '3.7'
networks:
traefik:
name: traefik
services:
traefik:
image: "traefik:v2.0.1"
container_name: 'traefik'
networks:
- traefik
ports:
- "80:80"      # The HTTP port
- "8080:8080"  # The Web UI (enabled by --api)
command:
- "--log.level=DEBUG"
volumes:
- /var/run/docker.sock:/var/run/docker.sock  # So that Traefik can listen to the Docker events
- ./traefik.yaml:/etc/traefik/traefik.yaml
And then use the same network in the other docker-compose files:
other-folder/docker-compose.yaml
version: '3.7'
networks:
traefik:
external: true
services:
whoami2:
image: containous/whoami
container_name: 'whoami'
networks:
- 'traefik'
labels:
- "traefik.http.routers.whoami2.rule=Host(whoami2.docker.localhost)"
Please notice the external part.
Hope this helps
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containous/traefik/issues/5563?email_source=notifications&email_token=AAEPGIGPC6YMIWQ72KKATVTQQKHK3A5CNFSM4I4OXPX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHK4LA#issuecomment-546221612,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEPGIG3RPNWTJLPFQZK7N3QQKHK3ANCNFSM4I4OXPXQ
.

--
--
Tom Stark
Hochäckerstr. 115
81737 München
Tel.: 01520 911 9008
--

authors: dduportal fragtom valentinvieriu


text:
Refs 2422: Add pending task metrics

Summary
Adds new metrics:
* Average queue time of pending task
* Length in queue for the oldest pending task
* Number of pending tasks
Also:
* Increases default metric calculations to 30 seconds from 5
* makes interval for metric calculation configurable
* adds log level override for metrics so you can set the rest of the app to trace while metrics are set to debugging

Testing steps
on a new db:
make run

in another tab:
make repos-import
go run cmd/external-repos/main.go nightly-jobs

This will kick off a ton of tasks, you can monitor with:
 curl localhost:9000/metrics | grep task_stats

This will update every ~30 seconds.
Checklist

[ ] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

note this is currently built ontop of https://github.com/content-services/content-sources-backend/pull/637
will rebase once merged.

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

/retest

/retest

/retest

added a test to check for queued_at updates.
Also i realized that the 'number of days' until the cdn cert expires was only calculated at startup, so i changed it to be calculated as part of the go routine that updates the metrics.  At startup it was set to zero, so to keep that from firing an alert, i set it to calculate that one metric at startup (and only that metric, because others require the db to be up, which may not actually have happened yet?)

added

authors: jlsherrill swadeley


text:
Fixes 41: Add create content modal

To test this PR, one will need to have checked out this backend PR (or have it merged to master).
This adds the bulk create modal.
This adds the following required API's:

Arch/Version repo
Validate Content
Bulk Create

Additional changes:

Added empty state/emptyTable state/Loading table state with skeleton
Worked entirely too much on gpgKey integration (80% functionality)
Hid said GPG key functionality.
Replaced @rverdile's react Context code (sorry!) to avoid this bug
Updated Eslint rules
Updated some cloud-services npm modules to latest
Added formik/Yup node modules
Fixed an issue with optimistic updates.
Added "Add 20" magic button within the create modal.
Fixed issue when deleting last item on a page > 1, where the page wouldn't navigate the user back.
Fixed issue with page not resetting when changing the search filters

Still needs:

Add readable specific field errors if bulk create fails (currently just throws generic), waiting on this ticket

Direction on what to do when we have an url that fails it's head request (currently prevents continuing):

Note on the above (not sure if this is considered a bug), pinging an address that has an http redirect will return success.
Example: https://quay.io/stuffandthings/thatprobablydontexist

https://issues.redhat.com/browse/HMSCONTENT-41

I'm guessing this appeared after hiding the gpg key section, but now the dropdown  for versions clips the end of the  section and you can't see it:

One issue:

enter a url without any version info in it
select some set of versions
go back to the url and change it slightly
versions change back to 'any version'
I thought we had mentioned this and you said it shouldn't do this, but i may be misremembering, i know you said it was tricky

seeing a weird format issue when trying to add a repo and the versions were auto-selected from the url.  The structure of the distribution_versions is wrong:
[
    {
        "name": "test4",
        "url": "http://yum.theforeman.org/katello/4.2/katello/el7/x86_64/",
        "distribution_arch": "x86_64",
        "distribution_versions": [
            [
                "el7"
            ]
        ],
        "gpgKey": ""
    },
    {
        "name": "test8",
        "url": "http://mirror.centos.org/centos/8-strea/BaseOS/x86_64/os/",
        "distribution_arch": "x86_64",
        "distribution_versions": [
            "el9"
        ],
        "gpgKey": ""
    }
]

The first object in this list was auto-selected, the 2nd one was not.  Notice that there is an array within an array in the first object which isn't valid

seeing a weird format issue when trying to add a repo and the versions were auto-selected from the url. The structure of the distribution_versions is wrong:
[
    {
        "name": "test4",
        "url": "http://yum.theforeman.org/katello/4.2/katello/el7/x86_64/",
        "distribution_arch": "x86_64",
        "distribution_versions": [
            [
                "el7"
            ]
        ],
        "gpgKey": ""
    },
    {
        "name": "test8",
        "url": "http://mirror.centos.org/centos/8-strea/BaseOS/x86_64/os/",
        "distribution_arch": "x86_64",
        "distribution_versions": [
            "el9"
        ],
        "gpgKey": ""
    }
]

The first object in this list was auto-selected, the 2nd one was not. Notice that there is an array within an array in the first object which isn't valid

Working on this now. I attempted an incomplete fix yesterday.

authors: Andrewgdewar jlsherrill


text:
Saving image loses c2pa information

Hi, thanks for the work. I am trying to save image with c2pa information in app.py code, it does save the image but then when i read c2pa information, it says there is no manifest attached.
However, when i follow the tutorial, as is, and do the curl request, then the output image saved by it, has the c2pa information.
I dont understand why would this happen? Why saving image after receiving image bytes, loses the c2pa content ? Please guide.

@app.route("/attach", methods=["POST"])
def resize():
    request_data = request.get_data()

    manifest = json.dumps({
        "title": "image2.jpg",
        "format": "image/jpeg",
        "claim_generator_info": [
            {
                "name": "c2pa test",
                "version": "0.0.1"
            }
        ],
        "assertions": [
            {
                "label": "c2pa.actions",
                "data": {
                    "actions": [
                        {
                            "action": "c2pa.edited",
                            "softwareAgent": {
                                "name": "C2PA Python Example",
                                "version": "0.1.0"
                            }
                        }
                    ]
                }
            }
        ]
    })

    builder = Builder(manifest)

    signer = create_signer(sign, SigningAlg.ES256,
                           cert_chain, "http://timestamp.digicert.com")

    result = io.BytesIO(b"")
    builder.sign(signer, "image/jpeg", io.BytesIO(request_data), result)

    with open('result.txt','w') as f:
        print(result.getvalue(),file=f)

    image = Image.open(result)

    # Save the image IO object to a file
    image.save('output_image5.jpg')

    image = Image.open(io.BytesIO(result.getvalue()))

    # # Save the image bytes to a file
    image.save('output_image6.jpg')
    with open('byte_result.txt','w') as f:
        print(result.getvalue(),file=f)

    print("End")
    return result.getvalue()

@shayan-NECX it seems you run the api successful at the first place.  however i get some issue that I need your help to confirm where is wrong ehen i follow the guide. I can't even run the curl successfully.
i also get someissues, after run the curl command I get an error when run api.py
**builder.sign(signer, "image/jpeg", io.BytesIO(request_data), result)**   File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa_api/c2pa_api.py", line 129, in sign     return super().sign(signer, format, C2paStream(input), C2paStream(output))   File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 925, in sign     rust_call_with_error(   File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 283, in rust_call_with_error     uniffi_check_call_status(error_ffi_converter, call_status)   File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 313, in uniffi_check_call_status     raise error_ffi_converter.lift(call_status.error_buf) **c2pa.c2pa.c2pa.Error.Signature: reason='COSE error parsing certificate**

what i have done is first run

python setup.py create-key-and-csr 'CN=John Smith,O=C2PA Python Demo'
kms-signing.csr file is cgenerated

then create fake rootCA

openssl req -x509 \ -days 1825 \ -newkey rsa:2048 \ -keyout rootCA.key \ -out rootCA.crt

then sign the CSR created in step 1 with the temporary test CA key
openssl x509 -req \ -CA rootCA.crt \ -CAkey rootCA.key \ -in kms-signing.csr \ -out kms-signing.crt \ -days 365 \ -copy_extensions copyall

then create chain.pem
cat kms-signing.crt rootCA.crt > chain.pem

FLASK_KMS_KEY_ID="$KMS_KEY_ID" FLASK_CERT_CHAIN_PATH="./chain.pem" flask run

curl command, i get the "COSE error parsing certificate" error from the builder.sign

Never mind, i was able to create image bytes, send as image byte string and retain C2PA information in images too. I will close the issue.
Regards,
Shayan

From: ttbuffey @.>
Sent: Tuesday, October 15, 2024 7:48 AM
To: contentauth/c2pa-python-example @.>
Cc: Bhatti, Shayan Ali @.>; Mention @.>
Subject: Re: [contentauth/c2pa-python-example] Saving image loses c2pa information (Issue #10)
You don't often get email from @.*** Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
@shayan-NECXhttps://github.com/shayan-NECX it seems you run the api successful at the first place. however i get some issue that I need your help to confirm where is wrong ehen i follow the guide. I can't even run the curl successfully.
i also get someissues, after run the curl command I get an error when run api.py
builder.sign(signer, "image/jpeg", io.BytesIO(request_data), result) File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa_api/c2pa_api.py", line 129, in sign return super().sign(signer, format, C2paStream(input), C2paStream(output)) File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 925, in sign rust_call_with_error( File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 283, in rust_call_with_error uniffi_check_call_status(error_ffi_converter, call_status) File "/Users/i302707/Documents/pii/c2pa-python-example/ven_3.10.5/lib/python3.10/site-packages/c2pa/c2pa/c2pa.py", line 313, in uniffi_check_call_status raise error_ffi_converter.lift(call_status.error_buf) c2pa.c2pa.c2pa.Error.Signature: reason='COSE error parsing certificate

what i have done is first run

python setup.py create-key-and-csr 'CN=John Smith,O=C2PA Python Demo'
kms-signing.csr file is cgenerated

then create fake rootCA

openssl req -x509 \ -days 1825 \ -newkey rsa:2048 \ -keyout rootCA.key \ -out rootCA.crt

then sign the CSR created in step 1 with the temporary test CA key
openssl x509 -req \ -CA rootCA.crt \ -CAkey rootCA.key \ -in kms-signing.csr \ -out kms-signing.crt \ -days 365 \ -copy_extensions copyall

then create chain.pem
cat kms-signing.crt rootCA.crt > chain.pem

FLASK_KMS_KEY_ID="$KMS_KEY_ID" FLASK_CERT_CHAIN_PATH="./chain.pem" flask run

curl command, i get the "COSE error parsing certificate" error from the builder.sign

—
Reply to this email directly, view it on GitHubhttps://github.com/contentauth/c2pa-python-example/issues/10#issuecomment-2413824139, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYBQUZGWZHEZPLGG5VREOELZ3UFLRAVCNFSM6AAAAABO4JOWEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJTHAZDIMJTHE.
You are receiving this because you were mentioned.Message ID: @.***>

authors: shayan-NECX ttbuffey


text:
Regarding Conan dependencies.

The current conanfile.txt in this repo is using packages that are not automatically or easily resolved.
It would be helpful to know where kwc_bintray is and add this to the README so that others can use Conan.
Digging around the commit and issue history I see that this was contributed by someone from Kai Wolf (so kwc seems to make sense). So it appears as though they have a self-hosted artifactory service but not all the packages were listed. At which point I realized that it's probably https://bintray.com/kwc which is rather easy in hindsight.
Running conan remote add kwc_bintray https://api.bintray.com/conan/kwc/conan resolved this for me.
Then you apparently also need bincrafters:
conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan
But you finally end up with the issue of the version of protobuf being requested is not apparently available in the bincrafters public conan repository. However, the requested version is available on conan-center. But still missing is protoc_installer.
It would be useful to add some documentation for the level of Conan support in the repo and how to use it.

Hi @photex,
I totally agree that Conan integration is not smooth yet. We worked together with @NewProggie to the Conan integration.
Unlike the behavior you get from Conan Center packages, we want the Conan integration to be truly optional. E.g. only the cmake_paths  generator should be used. (e.g. all target names used in CMake should be identical to those that you get by pure CMake installs).
This is why many packages were repackaged instead of using the official packages.
However, the current recommendation to build eCAL is to use submodule integration for thirdparty dependencies for an easy build on Windows, and on Linux use packages provided by the system package manager when available (e.g. on Ubuntu 18.04, hdf5, protobuf, qt, … can all be retrieved by apt-get).
More experienced users can use any way to provide the necessary dependencies.
But it still makes sense to put a chapter in the Readme file on Conan support / integration.

However, the requested version is available on conan-center. But still missing is protoc_installer.

Conan Center decided to package protoc and protobuf separately, mainly to facilitate cross-builds. With the kwc packages, they are packaged together (which I think they should be. Since they belong together, they are always required in the same version).

Good catch. I think there should be another section in the README.md containing:
# Install Conan
$ pip install --upgrade pip
$ pip install --upgrade conan
$ conan config set general.revisions_enabled=True

# Add Conan remotes with pre-compiled dependencies
$ conan remote add -f kwc_bintray https://api.bintray.com/conan/kwc/conan
$ conan remote add -f conan-center https://bintray.com/conan/conan-center
$ conan remote add -f bincrafters https://api.bintray.com/conan/bincrafters/public-conan

Let me quickly add another PR for this.

Thanks for the explanations.
@NewProggie neither bincrafters or conan-center had protoc_installer for the specified version when I tried it today. Can you verify that this works with these remotes?

actually the packages in the conan center are now being reworked to allow transparent conan usage, e.g. same target names of the packages when installed and found via cmake...
if some package is still not work this way, its a bug in the package that needs fixing...

Closing this discussion-thread due to inactivity

authors: FlorianReimold Kerstin-Keller NewProggie gocarlos photex

repo: continental/ecal


text:
How to bring continue back?

Describe the bug
My continue server always no response since some days ago.
I have tried all the ways in https://continue.dev/docs/troubleshooting but none of them could working.
Environment

Operating System: MacOS 10.15.7
Python Version: 3.11.4
Continue Version: v0.0.350
Remote develop on remote server with SSH

Console logs
Nothing appears in log file continue.log. It is empty!

My current fallback solution is to install Continue v0.0.329 which give me a suggestion to install continue extension on remote server. Now I could ask continue as always.

Sorry to hear this! To be sure, you were seeing something like this and the arrow just never disappeared? We did in fact make some changes that were intended to fix SSH right around version v0.0.329, so I'll look into what might have changed there. Is there anything else I should know about the setup so I can test on my own mac?

I just upgrade to latest v0.0.352 but still got same problem as my screenshot. I tried lsof -i :65432 | grep "(LISTEN)" | awk '{print $2} on remote server and my local computer, the continue server is only running on remote server.

I think the solution is probably to have Continue downloaded only on the local computer—this is actually the new intention since that version—should have realized this earlier.
This also has the benefit that you can use the same instance of Continue across local+remote workspaces

I don't know. For me, running continue only on remote server is good. As I don't have to care about VPN or proxy to access OpenAI API.

Hadn't considered this, sorry. It makes sense.
It's possible the issue is that the React app is local and the server is remote. If so, port forwarding would be the solution here and I could try something like this:
// If running on remote, forward the port
if (
  vscode.env.remoteName &&
  vscode.extensions.getExtension("continue.continue")?.extensionKind ===
    vscode.ExtensionKind.Workspace
) {
  await vscode.env.asExternalUri(vscode.Uri.parse(getContinueServerUrl()));
}

and then you would theoretically be able to just run the extension in remote only.
Can you test forwarding the port manually and see if this works? If so, I'll move forward with that.
But also interesting is that I've tested with my own SSH server, and am currently in a state where the server is running on the SSH server, but not locally, and things are working. I've tried both with the extension installed ONLY remote and on BOTH remote and local, like below. This makes me wonder whether a fresh start would be helpful.

Yeah, port forwarding 65432 is working. Now I have two continue server running. But the local one may not connected to the openai service and output logs.

Maybe there is one problem, I have two remote server but I could only forward one 65432 port to local. So only one remote server is actually providing continue service....

One idea is to allow the servers to run on different ports so they can both be forwarded. This seems like a reasonable option that should exist anyway to avoid port conflicts.
Do you feel this would be a good solution for you?

I found out that I can set different "continue:server url" settings for different workspace. This problem is soloved.

Good point, forgot you can just map to different ports when forwarding. Glad it's all working now!

authors: BenedictKing sestinj

repo: continuedev/continue


text:
Example adding Entra Auth to OpenAI provider

Description
Added a new attribute to base LLM to allow for handling non-apikey based authentication models.  Also moved the OpenAI header logic to async to allow for making calls to an IdP (Entra in this case).
Related to thread https://discord.com/channels/1108621136150929458/1131313996750917835/1251283613362683994
Note I know supporting SSO is a hot topic especially between the Open and possible value added release so this implementation may not be the best one to be reused by all the products.
I know we kicked around doing this IdP hit in config.ts as well, but the config load is sync for the moment so that would need to be an async model.  I also had issues with filtering the model this code would be invoked on.  If there was a LLM.model load generic (vs just a global load) it might allow for staging these environmental nuances to be staged in ~/.continue vs in the Extension itself.  Sort of pre-commit hook type world.
So this code may not be the right thing to merge, but figured it could be an example of approaching this problem and rather than bespoke providers providing a baseLLM method for auth that could be done using userspace and ideally just config.json.  One challenge in doing that might be module loading as in my example azure/identity is needed.
Checklist

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

If this path is valuable I have no problem amending the PR to include doc on using authType as control logic in a provider.
Testing
So assumes that the OpenAI endpoint is in Azure OpenAI and uses Entra for authentication, but ideally it should allow for end to end authentication using Browser path to get the access_token and refresh if its expired within the session.  This is similar to the AWS Bedrock use, but instead of requiring the user to make sure the STS is in their .aws path before calling it the token can be grabbed dynamically.  I did poke at mimicking this with azcli, but they obfuscate the access token now and sort of force you to use azcli to expose it.

@byjrack I'm impressed by how clean this change is. What you point out with the synchronous nature of config.ts + the need to include external dependencies are major reasons that we've been looking for a long-term solution to SSO, rather than the situation we'd end up in by patching on dozens of providers to our code that must be shipped to every client. The direction we're taking is to do it through our teams product, and we have something working today, though we've been testing quietly in beta. I won't rule out this PR definitively quite yet, but can I email you? It would help to know what precisely your auth+LLM setup looks like. I'm confident either way we can get this working for you

Tried to make the change reusable across the base, but I don't love the if/then logic.  You know it's a Pandora's box because every idp could need a custom package and possibly framework (some azcli requires python and then all the requests stuff). An oauth client could be pretty reusable, but the "it depends" is in the back of my mind.  A hooks model I think could work, but again lots of corner cases.
Email is on the profile.  Nothing really unique in our space, but can try to give as much info as I can.

Going to close this for reasons mentioned above and in other conversations. If we return to this will definitely look into something more extensible like hooks

authors: byjrack sestinj


text:
TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/110817

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/111105

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/111768

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/112084

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/112758

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/113867

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/120655

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/121331


text:
🛑 MPS - TESTPROCESS is down

In 0018d40, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MPS - TESTPROCESS is back up in be06f3f after 12 minutes.

repo: conuti-das/status-lfrcs


text:
Upgrade debian to 12 bookworm

Is there any plan to upgrade base debian image to 12 bookworm?

In the end we need to upgrade but there isn't any direct benefit right? Feel free to submit a PR.

authors: anyidea foarsitter

repo: cookiecutter/cookiecutter-django


text:
Update Firefly-iii version

Update Firefly-iii to version null

error getting version

repo: coostax/addon-firefly-iii


text:
new event api

Problem
Currently, anchor events are emitted through logs. This is potentially problematic since logs have a maximum size per transaction. And so one might emit an event and that event can be not present in the transaction.
Solution
Instead, perhaps a better (hack) would be to add to the anchor codegeneration a special instruction for events that does nothing. Then, when emit!(event) is called, we recursively CPI into the program with that instruction and the serialized event as data. Indexers can then use this to reliably build a table.

I would highly recommend adding a PDA log authority for this if it does get implemented. This makes it so there's no way to spoof log transactions through CPI from another program.
The PDA makes it so the only way you can invoke the log event is through self CPI.
In theory it should always be possible to properly index regardless of the log authority, but you run into far fewer edge cases. Unpacking the inner instruction data of the transaction tree is really hard because stack depth is not found in the returned object, and with this change you can be confident that any inner instruction with the log instruction is valid.
Not an easy change by any means, but it would be a win for overall devex if it was built into Anchor:
Here's an example of how this works in a native contract (with a log authority): https://github.com/Ellipsis-Labs/phoenix-v1/blob/master/src/lib.rs#L111
The invoke: https://github.com/Ellipsis-Labs/phoenix-v1/blob/master/src/program/event_recorder.rs#L133
It's tricky to optimize because you really would like to densely pack all of the emits to minimize the number of self CPIs to make. The normal emit! covers the 80/20 for contracts that don't need literally 100% of their data preserved, but you can probably implement a generalized non-optimized safe emit.

Note: one tradeoff with the PDA log authority is that it adds another 32 bytes to the transaction, which is a tough price to pay.

Jarry made some good points. There's so much wrong about using CPI to log data, from the fact it's a hack in the first place to the limitations it places on how often you can log data since you probably just want a single CPI. The current emit work fine for most people.
Adding support to anchor would just mean having a simpler helper function for sending the CPI and serializing the data needed, plus taking care of the parsing in the clients. It makes sense to have this although I can't imagine it would be in much demand except by the most intense projects.
Is Solana never going to fix the core issue here with logs dying randomly? The CPI transaction data approach is such a hack but it also shows that data can survive undamaged from the transaction. I can't believe they're not working on a solution.

It doesn't make sense to self-cpi if you're going to require an additional PDA.
Otherwise might as well just deploy a no-op program that hardcodes its list of caller programs.

IIUC benefit of self-cpi is that you reduce tx size by 32 bytes by removing a separate noop program key. Therefore, It doesn't make sense to self-cpi if you're going to require an additional PDA.

I think there's a tradeoff, and IMO having the PDA is far safer and worth the extra 32 bytes. Adding the extra key makes handling the log parsing far less error prone. Given the fact that the tx object doesn't have stack depth, it's not very difficult to effectively trick the indexer into storing bad data by calling the Log instruction directly.
Example:

Sample program A CPI's into target program T's log instruction and logs either some nonsense or false data
Downstream indexer fails to detect the malicious pattern (it's probably possible to catch, just more difficult)
DB corruption

If the PDA signs, the filter of tx success && instruction == T::log is sufficient to know that the data is safe to record

I've tagged a relevant rough draft PR of adding a no-op instruction to Anchor programs that does not require a PDA to sign (sorry Jarry).

I don't mind as I most likely won't be using this feature :)
The PDA adds more complexity, but IMO the important thing is that the indexing is done accurately, and it makes it bulletproof.
Even with stack depth, having an openly exposed log instruction won't make indexing easy. There are lots of adversarial cases that still need to be checked, I think it's still very possible to mess it up.
I think the condition that the Log instruction from program A must immediately be preceded by program A AND the stack depth has increased by 1 is sufficient for indexing without a PDA signer. As long as the logic to do this is present in the parsing code, the implementation is probably acceptable

authors: Henry-E armaniferrante jarry-xiao ngundotra

repo: coral-xyz/anchor


text:
upgrade fluentd prometheus plugin version

Currently the prometheus plugin is in version 2.0.2 and we want it to be on 2.0.3 duo to a metric bug on 2.0.2

@amit-mazor link to the issue

repo: coralogix/eng-integrations


text:
Add community notes

@kingfisher communitynote (user) (content of note) and then the bot just replies to that user's most recent message with the community note

funnier idea: let users vote on setting kingfisher's status

repo: coravacav/uofu-cs-discord-bot


text:
Opportunistic JSON detection and decoding of variables

Summary
JSON is often used for request bodies, and this is scanned properly. However, the use of JSON is quickly growing in the contents of variables such as:

cookies
query arguments (a single POST field)

The contents of a cookie or a query argument is currently treated by WAFs as a single string. The syntactical characters essential to JSON often lead to false positives in the Core Rule Set. (I estimate that about 50% of the rule exclusions I have to make are due to JSON in POST arguments.)
Therefore, I propose a feature where Coraza 'opportunistically' tries to perform JSON decoding on these variables. For instance:

read the variable until the first (non-whitespace*) character, is it [ or {
if so, send it to JSON decoder
if JSON decoder is successful, delete the original variable containing the full JSON, and walk the JSON object, creating sub variables for its values.

*Note: I didn't know from memory if valid JSON allows whitespace at the start, but I think this is valid: https://www.rfc-editor.org/rfc/rfc4627 under 2. Grammar: "Insignificant whitespace is allowed before or after any of the six structural characters."
Basic example
Let's say a client might want to send JSON in a POST parameter, such as: [{"foo": "bar"}, {"baz": "qux"}]
URL-encoded, this is: %5B%7B%22foo%22%3A%20%22bar%22%7D%2C%20%7B%22baz%22%3A%20%22qux%22%7D%5D
When I do a curl such as: curl --data 'param=%5B%7B%22foo%22%3A%20%22bar%22%7D%2C%20%7B%22baz%22%3A%20%22qux%22%7D%5D' https://lifeforms.nl/
This turns up false positives in Core Rule Set rules 942260 and 942370 (but there are often other rules that trigger also; I think there are about 5-10 rules which are notorious in this regard).
If instead, the param would not be scanned as whole, but be parsed as JSON, the CRS might end up with variables such as (for instance):
ARGS:param.foo = bar
ARGS:param.baz = qux

Most importantly, the FP is now gone. But we can still inspect the JSON contents specifically!
Another use case is cookies. Many trackers use JSON in cookies. What makes it worse is that their cookie names contain  dynamic parts (e.g. mixpanel_bacd4323434234, so it is hard to write rules against them. If the JSON string is parsed instead of doing 'dumb' string scans, these false positives would likely disappear.
Motivation

I expect a serious lowering of false positives when JSON is posted as a cookie or parameter
This would make Coraza a very attractive WAF for novice users who cannot write exclusion rules easily
It would seriously motivate me to switch to Coraza faster 😉

Possible drawbacks
We have to be careful to not introduce bypasses by this functionality. For instance, a malicious payload may be spread over multiple parts of a JSON object. But I think the requirement for it to be valid JSON is a serious roadblock for this technique; after all you cannot put a starting { or [ after comment characters. On first sight it seems to me not dangerous. But, let's at least think about this.
Finally
I have considered if this mechanism should be generic and could also used for XML, but I see XML in variables very rarely if at all. GraphQL could also be interesting to look at.

True, it's stale, but still cool. 😎

Totally
On Sun, 6 Nov 2022, 09:37 Walter Hop, @.***> wrote:

True, it's stale, but still cool. 😎
—
Reply to this email directly, view it on GitHub
https://github.com/corazawaf/coraza/issues/456#issuecomment-1304747352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYAWE5VWVSEGOACYESA3WG5U35ANCNFSM6AAAAAAQ62UUYQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

That's a great feature, I think we should consider it as it's a common issue. I also think we should extend this feature to all body processors (well, except multipart).

Because of its nature, we would have to create an operator because actions won't have access to the evaluated variables
The operator must take as parameters the parameter name, unless we provide a mechanism for the operator to know which variable is being evaluated
We will have to provide the body processor to be used, but body processors has response and request processors, which one should be used? Maybe we should refactor the body processor interface and create request body processors and response body processors
Same rules for the body processors should apply to avoid DDOS, and others
If we use the ARGS:param.param_name syntax, a user could just append a value by using: /url.php?param.param_name=hack. For that reason, this operator should also wipe all param.* variables.

CC @corazawaf/core-developers we should solve this before releasing v3.
Are we implementing this? If we are, are we recycling the body processors?
If we are recycling the body processors, should we split them into RequestBodyProcessor, ResponseBodyProcessor, ParameterBodyProcessor or should we extend our current interface and add a ProcessParameter method?

Now that v3 is almost released, I would like to start working on this. We could recycle the current bodyprocessors and implement a function that reads the body as text to find a regex, then uses the content set the content to be processed. Something like this:
<html>
...
<script>
...
var json= "{\"id\": 123}";
...

SecRule REQUEST_URL "/some/file.php" "...,phase:2,processRequestBody:'JSON:var json\s=\s"(.*)";'"

SecRule ARGS:json.id "123" "...."

We will have to run the bodyprocessor to make this work.
cc @corazawaf/core-developers

authors: jcchavezs jptosso lifeforms

repo: corazawaf/coraza


text:
fix: removes multiline from default regex modifiers [breaking]

This PR evaluates the needed changes to align Coraza to Modsec v2 behavior rather than Modsec v3 in terms of default modifiers when compiling regexes. This necessity has been raised by https://github.com/coreruleset/coreruleset/issues/3277.
We are currently running with two default modifiers:

s (dotall)
m (multiline mode)

While Modsec v2 (the reference implementation for the CRS) has:

PCRE2_DOTALL
PCRE2_DOLLAR_ENDONLY

Running the CRS rules with multiline may lead to false positives and lower performance.
Opening the PR to further discuss this, and whether we accept a breaking change for v3.* or not.

Good to see ftw passing with this change. I wouldn't merge it until seeing the PR to ModSec v3 doing the same, otherwise someone will just ask in the future why we aren't aligned with ModSec v3.

Maybe it is a good idea to coordinate this in @M4tteoP @airween

Totally 💯

Apart from aligning the behavior with ModSec, are we going to accept this breaking change and release it into a 3.x version or we aim to have it into 4.x?  If the latter is the case, I would guard the feature with a build flag and merge this PR wit the fix disabled by default

We agreed to implement this as a build tag for v3 and mandatory for v4
Once merged, another PR has to be created to remove the flag and force it by default

We agreed to implement this as a build tag for v3 and mandatory for v4

Done, added coraza.rule.no_regex_multiline build tag. It should be ready to be reviewed.

Please add this build tag to magefile.go

Done, let's if tests are happy ^_^

Looks so 🚀

authors: M4tteoP anuraaga jcchavezs jptosso


text:
dracut: add network config for auto link local

Both OpenStack and DigitalOcean require link-local auto-configuration in
order to communicate with the network metadata service.

lgtm, how does this relate to https://github.com/coreos/init/pull/216?

We are going we a slightly different approach. Trigger conditions don't work in network units and we only want to add a link-local address on the first interface when using DigitalOcean.
https://github.com/coreos/bootengine/pull/98

authors: crawford vcaputo

repo: coreos/bootengine


text:
internal: Simplify checking for supported providers and metadata function to call

This duplication bothered me a bit, so I figured I'd submit a PR to get rid of it.

Perhaps a better suggestion here: introduce a metadataFetcher() (fetchFn, error) which returns the provider-specific fetcher or an error for unknown ones, then either react to the error or invoke the returned function. While at it, please also introduce some unit-test covering positive and negative cases.

Perhaps a better suggestion here: introduce a metadataFetcher(provider string) (fetchFn, error) which returns the provider-specific fetcher or an error for unknown ones, then either react to the error or invoke the returned function. While at it, please also introduce some unit-test covering positive and negative cases.

I went down this path also, but felt that it was more than I should introduce in one go. However, I'm happy to take a pass at implementing something like this if that'd be the preferred approach.
Thanks for the review!

@lucab - is this in line with what you were thinking?

Cool, should be good now 👍

authors: joonas lucab

repo: coreos/coreos-metadata


text:
Bug: Using Kubernetes storage, always gets "Bad Request - Invalid client_id"

kubectl get oauth2clients -o yaml -n auth:
apiVersion: v1
items:
- apiVersion: oidc.coreos.com/v1
  clientID: stag
  clientSecret: <censored>
  kind: OAuth2Client
  metadata:
    creationTimestamp: 2017-02-06T17:30:30Z
    name: stag
    namespace: auth
    resourceVersion: "56746098"
    selfLink: /apis/oidc.coreos.com/v1/namespaces/auth/oauth2clients/stag
    uid: <censored>
  redirectURIs:
  - <censored>/redirect_uri
kind: List
metadata: {}
resourceVersion: ""
selfLink: ""

Client redirects to here:
https://<dex_address>/auth?scope=openid%20email%20profile&client_id=stag&state=<censored>&nonce=<censored>&redirect_uri=<censored>%2Fredirect_uri&response_type=code

No matter what client ID I tried using, response is always:
Bad Request

Invalid client_id ("stag").

(or any other client ID I've tried, of course.
BTW, with when I set it through staticClients, it does work.
Dex version: 2.1.0
Kubernetes version: 1.5.2
Many thanks guys.

Clients should be set through the dex API[0] not by editing the Kubernetes third party resources directly. We compute a hash for the "name", it's not 1-to-1.
Sorry, we should really add warning to the Kubernetes docs that users shouldn't edit the third party resources manually.
[0] https://github.com/coreos/dex/blob/master/Documentation/api.md

Oh, I got it. Thanks a lot!
I was following the directions here, BTW -
https://github.com/coreos/dex/blob/master/Documentation/storage.md
On Mon, Feb 6, 2017, 19:58 Eric Chiang notifications@github.com wrote:

Clients should be set through the dex API[0] not by editing the Kubernetes
third party resources directly. We compute a hash for the "name", it's not
1-to-1.
Sorry, we should really add warning to the Kubernetes docs that users
shouldn't edit the third party resources manually.
[0] https://github.com/coreos/dex/blob/master/Documentation/api.md
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/dex/issues/798#issuecomment-277761020, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKvJYDewJyKqdKNE0Y9VaMS5rXATmyxsks5rZ19AgaJpZM4L4gNw
.

@alon-argus yep I opened #799 to update that doc (feel free to comment). Going to keep this open until we get that merged.

authors: alon-argus ericchiang

repo: coreos/dex


text:
pod-policy: add automountServiceAccountToken to the pod policy

By default, Kubernetes will mount a service account token into the etcd
pods. This allows users to disable this via the pod-policy.

@etcd-bot ok to test

@etcd-bot retest this please

Sorry, I had violated a minor go-simple rule. This has been fixed. Hopefully CI will agree.

@etcd-bot retest this please

Took 3 tries to get tests to pass.
On the first two runs, e2eslow and unit tests passed, but jenkins-ci failed in a unique way.
Test 1: https://jenkins-etcd-public.prod.coreos.systems/job/etcd-operator/2256/console
19:21:59 --- FAIL: TestPerClusterS3AllDown (70.51s)
19:21:59 	crd_util.go:45: creating etcd cluster: test-etcd-wgb5l
19:21:59 	util.go:82: 2017-09-07 19:17:20.409401557 +0000 UTC waiting size (3), healthy etcd members: names ([])
19:21:59 	util.go:82: 2017-09-07 19:17:30.410119671 +0000 UTC waiting size (3), healthy etcd members: names ([])
19:21:59 	util.go:82: 2017-09-07 19:17:40.409618991 +0000 UTC waiting size (3), healthy etcd members: names ([])
19:21:59 	util.go:82: 2017-09-07 19:17:50.408909517 +0000 UTC waiting size (3), healthy etcd members: names ([test-etcd-wgb5l-0000])
19:21:59 	util.go:82: 2017-09-07 19:18:00.409892369 +0000 UTC waiting size (3), healthy etcd members: names ([test-etcd-wgb5l-0002])
19:21:59 	util.go:82: 2017-09-07 19:18:10.410668413 +0000 UTC waiting size (3), healthy etcd members: names ([test-etcd-wgb5l-0002])
19:21:59 	util.go:82: 2017-09-07 19:18:20.410634434 +0000 UTC waiting size (3), healthy etcd members: names ([test-etcd-wgb5l-0003 test-etcd-wgb5l-0002])

Test 2: https://jenkins-etcd-public.prod.coreos.systems/job/etcd-operator/2257/console
20:04:03 --- FAIL: TestBackupStatus (90.35s)
20:04:03 	crd_util.go:45: creating etcd cluster: test-etcd-z1hj3
20:04:03 	util.go:82: 2017-09-07 20:01:58.30972811 +0000 UTC waiting size (1), healthy etcd members: names ([])
20:04:03 	util.go:82: 2017-09-07 20:02:08.305941564 +0000 UTC waiting size (1), healthy etcd members: names ([])
20:04:03 	util.go:82: 2017-09-07 20:02:18.305902963 +0000 UTC waiting size (1), healthy etcd members: names ([test-etcd-z1hj3-0000])
20:04:03 	cluster_status_test.go:103: failed to create backup pod: still failing after 6 retries

Test 3: https://jenkins-etcd-public.prod.coreos.systems/job/etcd-operator/2258/console
Successful.

🎉

@ultimateboy have you test this code manually?

Yes. I built the image and pushed to docker hub with:
$ IMAGE=ultimateboy/etcd-operator ./hack/build/operator/build

Then I deployed with helm using:
$ helm install stable/etcd-operator --set image.repository="ultimateboy/etcd-operator" --set image.tag=latest --set image.pullPolicy=Always

Then tested with two different cluster definitions:
$ cat mount.cluster.yaml
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "example-etcd-cluster-mount"
spec:
  size: 1
  version: "3.1.8"

$ cat nomount.cluster.yaml
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "example-etcd-cluster-nomount"
spec:
  size: 1
  version: "3.1.8"
  pod:
    automountServiceAccountToken: false

After creating the above clusters (using kubectl create -f file.yaml), verified with:
$ kubectl get po example-etcd-cluster-mount-0000 -o yaml | grep automount
$ echo $?
1

$ kubectl get po example-etcd-cluster-nomount-0000 -o yaml | grep automount
  automountServiceAccountToken: false

@ultimateboy What's the output with automountServiceAccountToken: false when running
$ kubectl get po example-etcd-cluster-nomount-0000 -o yaml | grep serviceAccount

@fanminshi
$ kubectl get po example-etcd-cluster-nomount-0000 -o yaml | grep serviceAccount
  serviceAccount: default
  serviceAccountName: default

$ kubectl get po example-etcd-cluster-mount-0000 -o yaml | grep serviceAccount
  serviceAccount: default
  serviceAccountName: default

lgtm

@ultimateboy Can you add a line to CHANGELOG? LGTM after that.

CHANGELOG line added and rebased to fix conflict.

I really appreciate the fast turnaround here. Thanks @hongchaodeng and @fanminshi!!

authors: fanminshi hongchaodeng ultimateboy

repo: coreos/etcd-operator


text:
etcd-agent: get base when renaming

Partially related to https://github.com/coreos/etcd/issues/4552.

/cc @heyitsanthony @xiang90 Thanks.

lgtm.

repo: coreos/etcd


text:
functional-tester: decouple stresser from tester

This commit decouples stresser from the tester of
functional-tester. For doing it, this commit adds a new option
--stresser to etcd-tester. The option accepts two types of stresser:
"default" and "nop". If the option is "default", etcd-tester stresses
its etcd cluster with the existing stresser. If the option is "nop",
etcd-tester does nothing for stressing.
Partially fixes https://github.com/coreos/etcd/issues/6446
/cc @heyitsanthony

@mitake Test failed?

@gyuho sorry, this PR has a format error. I'll fix it in the next update.

@gyuho @heyitsanthony updated for fixing the style problem and cleaner decoupling, PTAL

lgtm. Thanks!

authors: gyuho heyitsanthony mitake


text:
CHANGELOG-3.2: update from #7892

CHANGELOG-3.2: update from #7892

Codecov Report

Merging #9948 into master will increase coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #9948      +/-   ##
==========================================
+ Coverage   69.12%   69.15%   +0.03%
==========================================
  Files         386      386
  Lines       35784    35784
==========================================
+ Hits        24735    24746      +11
- Misses       9232     9236       +4
+ Partials     1817     1802      -15

Impacted Files
Coverage Δ

etcdctl/ctlv3/command/lease_command.go
65.34% <0%> (-5.95%)
:arrow_down:

pkg/adt/interval_tree.go
84.98% <0%> (-5.71%)
:arrow_down:

pkg/transport/listener.go
58.67% <0%> (-4.09%)
:arrow_down:

proxy/grpcproxy/watcher.go
85.71% <0%> (-4.09%)
:arrow_down:

proxy/grpcproxy/watch.go
88.19% <0%> (-1.25%)
:arrow_down:

etcdserver/api/v2http/client.go
85.51% <0%> (-1.21%)
:arrow_down:

etcdserver/raft.go
80.09% <0%> (-0.72%)
:arrow_down:

mvcc/watchable_store.go
82.8% <0%> (-0.71%)
:arrow_down:

clientv3/watch.go
91.71% <0%> (-0.43%)
:arrow_down:

clientv3/balancer/grpc1.7-health.go
59.01% <0%> (-0.3%)
:arrow_down:

... and 14 more

Continue to review full report at Codecov.

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

I think we need the same change from https://github.com/coreos/etcd/commit/a47f0a0dbadeb9a775189a1153283e956e8cc7ec for 3.2 changelog?

@wenjiaswe Ping? Once we update this, we are ready for patch release. Thanks.

@gyuho Sorry missed this review. I just updated for line 31, with the correct replacement, please let me know if that's OK or not. For ["the same change from a47f0a0 for 3.2 changelog"](the same change from a47f0a0 for 3.2 changelog), I delivered in #9943 .

@wenjiaswe Can you also help merge https://github.com/coreos/etcd/pull/9950? So we do not do this kind of manual checking? Thanks!

Yes, will do!

authors: codecov-io gyuho wenjiaswe


text:
fleetctl: service uptime for list-units

Allow fleetctl list-units to retrieve per-unit uptime from systemd, for example:
localhost # ./fleet/fleetctl list-units
UNIT MACHINE ACTIVE SUB UPTIME
world.service 06ecd4f7.../192.168.122.30 active running 2015-07-06 07:38:38 AM UTC, Since 11m39s
world2.service 1d3430ef.../192.168.122.31 active running 2015-07-06 07:48:24 AM UTC, Since 1m54s
world_glob.service 06ecd4f7.../192.168.122.30 active running 2015-07-06 07:48:00 AM UTC, Since 2m18s
world_glob.service 1d3430ef.../192.168.122.31 active running 2015-07-06 07:47:59 AM UTC, Since 2m18s

What's changed since #1293:

Avoided unnecessary iteration for each unit when fetching systemd properties. Instead make use of setting internal UnitState, both for the normal loop for systemd (>= 230) and for the fallback loop for systemd (<= 229).
Fixed typos and bugs in registry and schema
Excluded ActiveEnterTimestamp from unit comparison condition.
Added timezone e.g. UTC to the output

Fixes https://github.com/coreos/fleet/issues/1128
Supersedes https://github.com/coreos/fleet/pull/1293
/cc @wuqixuan

I'm not sure about this one - please hold off until I can give it a little more thought

@jonboulle I see.

authors: dongsupark jonboulle

repo: coreos/fleet