text:
ANSIENG-4174

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] Any variable/code changes have been validated to be backwards compatible (doesn't break upgrade)
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If required, I have ensured the changes can be discovered by cp-ansible discovery codebase
[ ] My code follows the style guidelines of this project
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules

Can you please add the link of semaphore test runs for these scenarios

Closing this PR and opening again.


text:
Fix nil MsgBase caused panic in GetMetrics call

/kind bug
Signed-off-by: Congqi Xia congqi.xia@zilliz.com

/lgtm

source: gharchive/pull-request

repo: congqixia/birdwatcher

license_type: permissive

license_source: github-api


text:
Updating arabic translation.

Updating arabic translation.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

No spam, please I'm human !

Closed with #728

authors: BoFFire CLAassistant kruton

repo: connectbot/connectbot

license_source: bigquery


text:
Use USD pricing in explorer for Alchemy assets

These should be updated to use pricing oracle across Explorer
ETH: https://connextscan.io/tx/0x06d5c338d3ec8b5e53de8570ccb79c00135668d7e7903045660d5e36c8142427
USDC: https://connextscan.io/tx/0xee2f1bdaf103624ad5f9c2d4d9f002c1bded89b0175282c7ae07bcca5cae4928

note we should figure out for all new xTokens as we scale

Could you add the field that indicates the USD value of each transfer data?

source: gharchive/issue

authors: alexwhte pjenviri

repo: connext/monorepo

license: MIT


text:
Add DeFiEra Token

团队背景：DeFi Era（DeFi时代）是DF.R小组耗时两年时间创的去中心化智能互助系统，通过智能合约技术运行于以太坊网络，具有公开、透明、安全和全自动运行的特征。位于全球任意位置的玩家均可无障碍自由参与，一切操作链上自动完成，任何机构都不能操控系统运行或掌控系统内资金。
DF.R小组：Decentralized Financial Reform Team译为：去中心化金融改革小组。DF.R小组致力于钻研区块链核心技术打造应用落地价值。
小组多年沉淀研究发现，把金融规则构建于区块链之上，可达到高效、透明、不可篡改、不可暗箱操控等特征；附加良好运行机制，可在弱中心化的管理下，可消除投资人与平台创建者之间天然的利益矛盾，高效解决信任痛点，从而打破原有金融市场的限制壁垒，为建立公平的金融秩序垫定可行性基础。肩负使命，众望所归DeFi Era智能互助系统由此诞生！
在DeFi Era系统, 所有运行规则都通过智能合约集成到以太坊区块链网络，人类不再负责管理系统，每个参与者都必须遵守其游戏规则，只有触发相应的条款，合约才会执行相应操作，系统开发者也不能盗取资金或者掌控系统运行。
项目基本情况：DeFi Era智能合约系统的游戏令牌+权益的通证+消耗燃料。DT在幸运夺宝中作为游戏令牌可参与竞赛，幸运者可获得百倍以上的巨额收益；DT是权益基金派发相应收益的权益证明；DT是所有玩家在获得帮助的时候都需要消耗的燃料，DT是DeFi Era链接系统内外桥梁，所以，DT的娱乐性、稀缺性和通缩增值特性使其极其巨大的收藏价值。
更多关于 DeFi Era 的信息
DeFi Era 官网 http://defiera.io/
DeFi Era-宣传片：http://suo.im/5EMlyF
Telegram: https://0.plus/DeFi_Era
媒体报道
DeFi Era-共识财经报导：http://suo.im/6nXSWu
DeFi Era-金色评级报导：http://suo.im/5xgfOa
DeFi Era-创世周刊报导：http://suo.im/69BsK6
建议 gas limit：40

PR不完整，请参考教程重新提交

能给个提示是哪里不完整吗
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
在 2020年8月14日星期五下午2点32分，sfsy520 notifications@github.com 寫道：

Closed #6020.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

repo: consenlabs/token-profile


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

In edb4f64, 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 bade93c.

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

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

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

repo: constructions-incongrues/status


text:
🛑 constructions-incongrues.net is down

In 73c9b63, constructions-incongrues.net (https://constructions-incongrues.net) was down:

HTTP code: 521
Response time: 176 ms

Resolved: constructions-incongrues.net is back up in 6ddf10b.


text:
🛑 artcomptantpourrien.constructions-incongrues.net is down

In c81b815, artcomptantpourrien.constructions-incongrues.net (https://artcomptantpourrien.constructions-incongrues.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: artcomptantpourrien.constructions-incongrues.net is back up in 711aabc.


text:
🛑 thisisradioclash.org is down

In e83ef34, thisisradioclash.org (https://thisisradioclash.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: thisisradioclash.org is back up in b454999.


text:
🛑 lagrandepurge.resterdigne.net is down

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

HTTP code: 0
Response time: 0 ms

Resolved: lagrandepurge.resterdigne.net is back up in 95284db.


text:
🛑 divag.parishq.net is down

In 951ec2f, divag.parishq.net (https://divag.parishq.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: divag.parishq.net is back up in 1d74c71.


text:
Test flakes related to content store

Recently CI often fails with  failed to get reader from content store: content digest sha256:...: not found occurred error.
e.g. https://travis-ci.org/containerd/containerd/jobs/633175052
• Failure in Spec Setup (BeforeEach) [4.347 seconds]
[k8s.io] Multiple Containers [Conformance]
/home/travis/gopath/src/github.com/kubernetes-incubator/cri-tools/pkg/framework/framework.go:72
  when running multiple containers in a pod
  /home/travis/gopath/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/multi_container_linux.go:50
    should support network [BeforeEach]
    /home/travis/gopath/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/multi_container_linux.go:78
    failed to create container: rpc error: code = NotFound desc = failed to create containerd container: error unpacking image: failed to extract layer sha256:8032b0dc1204e295232523d54b02c3b0540d2a4d7d94f0024a355a4a8f71d751: failed to get reader from content store: content digest sha256:27298e4c749a2e37d2842e5200bb388402405c04e2de9fb97a05c868c4df9f7b: not found
    Unexpected error:
        <*status.statusError | 0xc000244a50>: {
            Code: 5,
            Message: "failed to create containerd container: error unpacking image: failed to extract layer sha256:8032b0dc1204e295232523d54b02c3b0540d2a4d7d94f0024a355a4a8f71d751: failed to get reader from content store: content digest sha256:27298e4c749a2e37d2842e5200bb388402405c04e2de9fb97a05c868c4df9f7b: not found",
            Details: nil,
            XXX_NoUnkeyedLiteral: {},
            XXX_unrecognized: nil,
            XXX_sizecache: 0,
        }
        rpc error: code = NotFound desc = failed to create containerd container: error unpacking image: failed to extract layer sha256:8032b0dc1204e295232523d54b02c3b0540d2a4d7d94f0024a355a4a8f71d751: failed to get reader from content store: content digest sha256:27298e4c749a2e37d2842e5200bb388402405c04e2de9fb97a05c868c4df9f7b: not found
    occurred
    /home/travis/gopath/src/github.com/kubernetes-incubator/cri-tools/pkg/framework/util.go:276

https://github.com/containerd/containerd/commit/8c7e6be290003a354fcf163dbd4c7f21f97a709f (#3870) might be related?

repo: containerd/containerd


text:
Allow specifying media type for a converted schema1 manifest for compatibility with distribution

I want to utilize containerd's schema1.Converter to migrate a registry's schema1 manifests to schema2 manifests in the storage backend (not only for pull conversion). I've written a POC that does just that, except that registry doesn't accept manifest mediatype for application/vnd.oci.image.manifest.v1+json.
I added an optional ConvertOpt as an argument to (*Converter).Convert to specify the manifest and manifest config media types. If not provided, it will default to the OCI media types.

LGTM

authors: hinshun stevvooe


text:
Prepare 1.1.5 release notes

Feel free to comment if the anything is missing or there is any mistake.
Signed-off-by: Lantao Liu lantaol@google.com

Codecov Report

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

@@             Coverage Diff              @@
##           release/1.1    #2787   +/-   ##
============================================
  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 7cc1302...4b9cc35. Read the comment docs.

LGTM

heads up; I opened https://github.com/containerd/containerd/pull/2802, which should probably be added if that gets merged before 1.1.5 is released

heads up; I opened #2802, which should probably be added if that gets merged before 1.1.5 is released

ACK. I'll update the release note correspondingly.

Merged one more fix in, update and do the release today?

SG, I'll send the cherrypick, and we can let the test run for 2~3 hours, and then cut the release?

Here is the cherrypick https://github.com/containerd/containerd/pull/2818

Updated the release note with "Update runc".

LGTM

authors: Random-Liu codecov-io crosbymichael dmcgowan thaJeztah


text:
[release/1.3] Don't clash with GH Actions runner's containerd

backport #4380 to release/1.3

Looks like I will get caught in the same spiral as #4361 needing several other backports to pass integration (the sync delete -> TestImageUsage problems)

Should I just include this cherry-pick in my PR?

yup, looks good. I'll close this.

authors: estesp joejulian


text:
replace deprecated function with Domain and Path

replace deprecated function SplitHostname
Signed-off-by: Zou Nengren zouyee1989@gmail.com

/cc @mikebrow

/retest

/ok-to-test
IIRC /retest only works against the tests that are managed by @k8s-ci-robot.

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

authors: kzys zouyee


text:
fix incorrect namespace of event when create/update namespace

Signed-off-by: Ye Sijun junnplus@gmail.com
Keep same with delete namespace
https://github.com/containerd/containerd/blob/main/services/namespaces/local.go#L201-L211

@Random-Liu PTAL
@containerd/committers What do other maintainers think?


text:
Support --ipc=(shareable|container:<container>) flag

#1293
(Late reviews are also okay. Please review carefully.)

Add ipcutil:

To support --ipc=shareable, a container mounts a path on host as an intermediary for /dev/shm.
For its persistency, the ipc info is saved in the containers label.
For backward compatibility, if ipcLabel is empty, ipc mode will be private.

When to remove container and stoping container, call ipcutil.CleanUp() to clean mounted /dev/shm.

Looks good, but please squash commits

authors: AkihiroSuda minuk-dev

repo: containerd/nerdctl


text:
support configure nydusd with use_http

relates to https://github.com/dragonflyoss/image-service/pull/759

Codecov Report
Base: 30.60% // Head: 30.60% // No change to project coverage :thumbsup:

Coverage data is based on head (cac3b5a) compared to base (d2e5338).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #191   +/-   ##
=======================================
  Coverage   30.60%   30.60%
=======================================
  Files          22       22
  Lines        2029     2029
=======================================
  Hits          621      621
- Misses       1319     1320    +1
+ Partials       89       88    -1

Impacted Files
Coverage Δ

config/daemonconfig.go
0.00% <ø> (ø)

pkg/filesystem/fs/blob_manager.go
44.44% <0.00%> (-11.12%)
:arrow_down:

pkg/auth/kubesecret.go
34.02% <0.00%> (+3.09%)
:arrow_up:

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: changweige codecov-commenter

repo: containerd/nydus-snapshotter


text:
Bootc with credential helper fails without /etc/ostree/auth.json

A bit of a strange one, and I'm not too sure where to file this.
I am trying to deploy a bootc image to AWS, with the image hosted in ECR.  To pull from ECR, it's best to use the docker-credential-ecr-login helper.  I don't know if any of this information about the credential helpers is actually relevant, but I do not currently have an environment to test without.
So I added the credential helper binary to my $PATH, along with the following /etc/containers/registries.conf.d/001-ecr-login.conf config:
credential-helpers = ["ecr-login"]

A bootc upgrade failed with "authentication required".
Now comes the weird part.  If I create an empty /etc/ostree/auth.json file, an upgrade works...
If this is a required file, I suggest a relevant error message be thrown when not present.  Or specifying this somewhere in the docs would also be good.
Thank you
Rob

PR in https://github.com/containers/bootc/pull/563 for docs, sorry it's going to be hard for us to do better in a short term.

Updating the docs is great, thanks!  Just don't want others to get stuck on this for as long as I did :laughing:
I don't mind whether you close this as complete, or leave it in the hope it will be fixed further down the line.

repo: containers/bootc


text:
cache: store creation time of pod and containers cache objects

Enable sorting containers based on the time when they and their pods have been added to the cache.

On a related note, I can extend NRI and add the CreatedAt timestamp to the protocol. That would allow us to sort existing containers also during synchronization at will.

I'm all for it.
Before implementing it this way, I was first wondering if the whole thing should be based on actual creation time of containers in the system. However, for this particular use case (PR #273), the order in which the policy became aware of containers is even more important than their creation times in the system, so I thought that storing cache object creation times is useful anyway.
That said, there can be use cases for real create and start timestamps, too.

On a related note, I can extend NRI and add the CreatedAt timestamp to the protocol. That would allow us to sort existing containers also during synchronization at will.

I'm all for it.
Before implementing it this way, I was first wondering if the whole thing should be based on actual creation time of containers in the system. However, for this particular use case (PR #273), the order in which the policy became aware of containers is even more important than their creation times in the system, so I thought that storing cache object creation times is useful anyway.
That said, there can be use cases for real create and start timestamps, too.

Referring to our chat in the weekly sync, as a temporary approximation with pod-level granularity you often might be able to tell which of two containers is older by looking at their pods UID, extracting the their Version() and if they are both among {1, 2, 6, 7}, then extracting the Time() fields and comparing them. These fields are then in 100s of nanoseconds since 15th Oct 1582 (according to RFC4122). If the pods have not been scheduled roughly at the same time, this should provide plenty of precision to tell them apart age wise. Probably not a Turing-award winner, but can act as a bridge gap solution if sorting by age is really needed.

authors: askervin klihub

repo: containers/nri-plugins


text:
Use pnet_datalink instead of pnet.

xref: https://github.com/containers/youki/pull/955

Codecov Report

Merging #963 (908a2e5) into main (1051f45) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 908a2e5 differs from pull request most recent head dc89f6b. Consider uploading reports for the commit dc89f6b to get more accurate results

@@           Coverage Diff           @@
##             main     #963   +/-   ##
=======================================
  Coverage   69.11%   69.11%
=======================================
  Files         118      118
  Lines       12460    12460
=======================================
  Hits         8612     8612
  Misses       3848     3848

repo: containers/youki


text:
[Feature Request] Support for blue/green deployment

Hi all,
I am requesting a feature to support blue/green deployment when using Docker swarm mode as its backend configuration.
The idea is to support a label for source IP address(es), IP address range or subnet (or geolocation perhaps) and forward the users' traffic to a backend server intended for the green deployment. Let's say serviceA is running version 1.0.0 in the blue environment (active) at overlay network A then another serviceA is also running but this time it is on version 1.0.1 in the green environment attached to both overlay networks A and B but for selected users only whose IP addresses matches to the label.
Thank you in advance.
Kind regards,
Marvin

Seems to be a duplicate of #914

Closing. @bintut, feel free to amend #914 if you think it's missing some of your proposal details.

authors: bintut ldez timoreimann

repo: containous/traefik


text:
Enabling compression doesn't work

Do you want to request a feature or report a bug?
Bug
What did you do?
Step 1: Started a new traefik instance using docker with enabled compression for a single http endpoint with the following config:
logLevel = "DEBUG"
debug = true
defaultEntryPoints = ["http"]
[entryPoints]
  [entryPoints.http]
  address = ":80"
  compress = true

[docker]
  endpoint = "unix:///var/run/docker.sock"

Step 2: started simple web service inside docker that returned plain text content behind traefik
Step 3: used httpie / curl to get following headers:
HTTP/1.1 200 OK
Content-Length: 391
Content-Type: text/plain
Date: Thu, 28 Sep 2017 11:57:37 GMT
Vary: Accept-Encoding

Changing config to compress = false doesn't affect response in any way.
What did you expect to see?
Expected to see gzip header and smaller content size
What did you see instead?
No gzip header and original content size
Output of traefik version: (What version of Traefik are you using?)
Version:      v1.3.8
Codename:     raclette
Go version:   go1.8.3
Built:        2017-09-07_08:46:19PM
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
{
 "GraceTimeOut": 10000000000,
 "Debug": true,
 "CheckNewVersion": true,
 "AccessLogsFile": "",
 "TraefikLogsFile": "",
 "LogLevel": "DEBUG",
 "EntryPoints": {
  "http": {
   "Network": "",
   "Address": ":80",
   "TLS": null,
   "Redirect": null,
   "Auth": null,
   "Compress": true
  }
 },
 "Cluster": null,
 "Constraints": [],
 "ACME": null,
 "DefaultEntryPoints": [
  "http"
 ],
 "ProvidersThrottleDuration": 2000000000,
 "MaxIdleConnsPerHost": 200,
 "IdleTimeout": 180000000000,
 "InsecureSkipVerify": false,
 "Retry": null,
 "HealthCheck": {
  "Interval": 30000000000
 },
 "Docker": {
  "Watch": true,
  "Filename": "",
  "Constraints": null,
  "Endpoint": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "Domain": "",
  "TLS": null,
  "ExposedByDefault": true,
  "UseBindPortIP": false,
  "SwarmMode": false
 },
 "File": null,
 "Web": null,
 "Marathon": null,
 "Consul": null,
 "ConsulCatalog": null,
 "Etcd": null,
 "Zookeeper": null,
 "Boltdb": null,
 "Kubernetes": null,
 "Mesos": null,
 "Eureka": null,
 "ECS": null,
 "Rancher": null,
 "DynamoDB": null,
 "ConfigFile": "//traefik.toml"
}

If applicable, please paste the log output in debug mode (--debug switch)
INFO[2017-09-28T11:51:36Z] Traefik version v1.3.8 built on 2017-09-07_08:46:19PM
INFO[2017-09-28T11:51:36Z] Using TOML configuration file //traefik.toml
DEBU[2017-09-28T11:51:36Z] Global configuration loaded {"GraceTimeOut":10000000000,"Debug":true,"CheckNewVersion":true,"AccessLogsFile":"","TraefikLogsFile":"","LogLevel":"DEBUG","EntryPoints":{"http":{"Network":"","Address":":80","TLS":null,"Redirect":null,"Auth":null,"Compress":true}},"Cluster":null,"Constraints":[],"ACME":null,"DefaultEntryPoints":["http"],"ProvidersThrottleDuration":2000000000,"MaxIdleConnsPerHost":200,"IdleTimeout":180000000000,"InsecureSkipVerify":false,"Retry":null,"HealthCheck":{"Interval":30000000000},"Docker":{"Watch":true,"Filename":"","Constraints":null,"Endpoint":"unix:///var/run/docker.sock","Domain":"","TLS":null,"ExposedByDefault":true,"UseBindPortIP":false,"SwarmMode":false},"File":null,"Web":null,"Marathon":null,"Consul":null,"ConsulCatalog":null,"Etcd":null,"Zookeeper":null,"Boltdb":null,"Kubernetes":null,"Mesos":null,"Eureka":null,"ECS":null,"Rancher":null,"DynamoDB":null}
INFO[2017-09-28T11:51:36Z] Preparing server http &{Network: Address::80 TLS:<nil> Redirect:<nil> Auth:<nil> Compress:true}
INFO[2017-09-28T11:51:36Z] Starting server on :80
INFO[2017-09-28T11:51:36Z] Starting provider *docker.Provider {"Watch":true,"Filename":"","Constraints":null,"Endpoint":"unix:///var/run/docker.sock","Domain":"","TLS":null,"ExposedByDefault":true,"UseBindPortIP":false,"SwarmMode":false}
DEBU[2017-09-28T11:51:36Z] Provider connection established with docker 17.06.2-ce (API 1.30)
DEBU[2017-09-28T11:51:36Z] Filtering container with empty frontend rule /hungry_lalande
DEBU[2017-09-28T11:51:36Z] Validation of load balancer method for backend backend-exo-yamalight-test-node-deploy failed: invalid load-balancing method ''. Using default method wrr.
DEBU[2017-09-28T11:51:36Z] Configuration received from provider docker: {"backends":{"backend-exo-yamalight-test-node-deploy":{"servers":{"server-exo-yamalight-test-node-deploy-0b54e7c0":{"url":"http://172.18.0.3:80","weight":0}},"loadBalancer":{"method":"wrr"}}},"frontends":{"frontend-Host-html-dev":{"entryPoints":["http"],"backend":"backend-exo-yamalight-test-node-deploy","routes":{"route-frontend-Host-html-dev":{"rule":"Host:html.dev"}},"passHostHeader":true,"priority":0,"basicAuth":[]}}}
DEBU[2017-09-28T11:51:36Z] Last docker config received more than 2s, OK
DEBU[2017-09-28T11:51:36Z] Creating frontend frontend-Host-html-dev
DEBU[2017-09-28T11:51:36Z] Wiring frontend frontend-Host-html-dev to entryPoint http
DEBU[2017-09-28T11:51:36Z] Creating route route-frontend-Host-html-dev Host:html.dev
DEBU[2017-09-28T11:51:36Z] Creating backend backend-exo-yamalight-test-node-deploy
DEBU[2017-09-28T11:51:36Z] Creating load-balancer wrr
DEBU[2017-09-28T11:51:36Z] Creating server server-exo-yamalight-test-node-deploy-0b54e7c0 at http://172.18.0.3:80 with weight 0
INFO[2017-09-28T11:51:36Z] Server configuration reloaded on :80
DEBU[2017-09-28T11:51:38Z] Round trip: http://172.18.0.3:80, code: 200, duration: 942.671µs

The Compress middleware doesn't do anything until the Content-Length > 512 bytes, this is expected behaviour, @yamalight could you try with a larger response and confirm

@errm yup, that works. thanks!
would be great to mention this in the docs IMO.

Closed by #2184.

authors: errm traefiker yamalight


text:
Update README.md

This PR updates the readme regarding the changeFieldControl function, to include missing details about two optional settings: showCreateEntityAction  and showLinkEntityAction

Summary
Adds details of additional options to changeFieldControl function in the readme.
Description
The following options are now documented:
showCreateEntityAction
showLinkEntityAction
Motivation and Context

It took me quite a while to find what these options were called so I could use them as they are currently missing from the docs, even though they work when used in migration scripts.

@georgemillard thanks for your contribution 🎉

authors: georgemillard marcolink

repo: contentful/contentful-migration


text:
Feat/migrate v3

added v3 updates
removed superenum dependency
updated existing dependencies

The current version of Dart is 3.5.4, released on October 18, 2024. So dart support should be accordingly

With the introduction of Enums in Dart v3.0 and above.
We should remove .g support. Consequently.
Please remove the super_enum: ^0.5.0 dependency.

@dudeman9801 @reeshika-h @nadeem-cs @netrajpatel

repo: contentstack/contentstack-dart


text:
feat: Add num_treads to ollama along with docs

I found that when running with ollama my computer would freeze up while doing inference. Exposing num_thread should help leave some threads to the GUI to handle user input.

@RangerMauve very nice, and thank you for adding the documentation!

Sweet, thanks for the merge. :) Gonna test it out in my workflow this week.

authors: RangerMauve sestinj

repo: continuedev/continue


text:
Create a ssh-forward image for supporting local/remote port forwarding and …

…SOCKS proxy
This is multi-purpose for example to solve:

Seeing behat tests running in a local browser
Using PHP XDebug remote debugging in an IDE
SOCKS proxying into Docker for Mac for direct browsing unexposed http/https

Do we need fail2ban in here as well?

I would suggest the port is never exposed publicly

authors: andytson-inviqa kierenevans

repo: continuouspipe/dockerfiles


text:
🛑 MPS - TESTPROCESS is down

In 94671c2, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MPS - TESTPROCESS is back up in 6d16fbe after 5 minutes.

repo: conuti-das/status-lfrcs


text:
🛑 MPS - TESTPROCESS is down

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

HTTP code: 200
Response time: 617 ms

Resolved: MPS - TESTPROCESS is back up in 879088c after 2 hours, 36 minutes.


text:
🛑 MPS - TESTPROCESS is down

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

HTTP code: 200
Response time: 781 ms

Resolved: MPS - TESTPROCESS is back up in 46c9779 after 56 minutes.


text:
🛑 MPS - TESTPROCESS is down

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

HTTP code: 200
Response time: 631 ms

Resolved: MPS - TESTPROCESS is back up in 5725fa0 after 7 minutes.


text:
Export as module

This exports the package as an ES module as an addition to CommonJS :bowtie:

After npm install i got:
[!] (plugin typescript) Error: @rollup/plugin-typescript: Could not find module 'tslib', which is required by this plugin. Is it installed?

After the build I replaced index.js and index.mjs in my project.
I ran build and node bootstrap/ssr/ssr.mjs
Got an error
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object.
    at Bard (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Hero.43bbc8c1.mjs:3202:3)
    at About (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/About.a363f67a.mjs:16:3)
    at Page (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Default.95c5fe0e.mjs:545:3)
    at main
    at div
    at Base (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Default.95c5fe0e.mjs:164:3)
    at s (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:653)
    at div
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
    at ReactDOMServerRenderer.render (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:4053:17)
    at ReactDOMServerRenderer.read (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:3690:29)
    at renderToString (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:4298:27)
    at /Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:5483
    at /Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:5590
    at async Server.<anonymous> (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/ssr.mjs:79:37)
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object.
    at Bard (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Hero.43bbc8c1.mjs:3202:3)
    at About (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/About.a363f67a.mjs:16:3)
    at Page (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Default.95c5fe0e.mjs:545:3)
    at main
    at div
    at Base (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/assets/Default.95c5fe0e.mjs:164:3)
    at s (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:653)
    at div
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
    at ReactDOMServerRenderer.render (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:4053:17)
    at ReactDOMServerRenderer.read (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:3690:29)
    at renderToString (/Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/react-dom/cjs/react-dom-server.node.development.js:4298:27)
    at /Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:5483
    at /Users/dussel/Sites/hapag-lloyd-stiftung/node_modules/@inertiajs/inertia-react/dist/index.js:1:5590
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Server.<anonymous> (file:///Users/dussel/Sites/hapag-lloyd-stiftung/bootstrap/ssr/ssr.mjs:79:37)

authors: SebastianDeuss tobiasthaden

repo: convoyinteractive/react-bard


text:
Fix bug STDOUT isn't captured

Problem
In my environment, rrrspec doesn't capture stdout in second and subsequent.
example
Focus on one slave.
First time

Second time

STDOUT is empty.
version

RRRSpec 0.4.3

LGTM.

cc @cookpad/rrrspec
@pocke if possible please explain background and your analysis at here, too.

Analysis
First, I've debugged the problem by debug printing.
# In spec_helper
RSpec.configure |config|
  config.before do
    $stdout.puts "======================== StdOut Before Each ========================"
  end

  config.after do
    $stdout.puts "======================== StdOut After Each ========================"
  end
end

I added the above code, and run RRRSpec. Then RRRSpec captures StdOut Before Each and StdOut After Each but rspec's output is not captured.

So, I guess problem is in output_stream.
Second, I try outputting object_id of $stdout and RSpec.configuration.output_stream.
Then I've confirmed they are same object.

Cause (guess)
I guess this cause is difference between add_formatter and default_formatter.

https://github.com/rspec/rspec-core/blob/master/lib/rspec/core/configuration.rb#L850-L852
https://github.com/rspec/rspec-core/blob/master/lib/rspec/core/configuration.rb#L831-L834

In add_formatter, a formatter is received an output_stream. However, in default_formatter, a formatter is not received an output_stream.
It's a problem of output_stream, so, I guess the cause is the difference.

authors: pocke sorah

repo: cookpad/rrrspec

license: mit


text:
[Bug]: Supabase servide doesn't allow to change kong port or run in localhost

Description
While trying to test coolify with Supabase, installing on the same localhost (I know it's not recommended but it should be doable), if yu try to edit the Kong port 8000, Coolify won't allow you to do it, the host changes all right after saving, but the port will always be reverted to port 8000 which conflics with Coolify.
This works fine with the Appwrite service for example
Minimal Reproduction (if possible, example repository)

Setup a brand new server (in my case ubuntu server 24.04 LTS)
Install docker
Get Coolify up and running following the instructions in the website
Setup coolify to install in localhost (no other settings)
Create a new project
Add a new resource, of type Supabase Service
Change KONG port to 9000

If I manually edit the compose file to get the KONG_HTTP_PORT and configure the environment variables manually to set the KONG_HTTP_PORT=9000and some other settings like the external urls, then I can manage to make it work in localhost
Exception or Error
No error, port gets reverted back to 8000 after saving
Version
v4.0.0-beta.294

Where do you add the KONG_HTTP_PORT? I'm getting
 Kong Error Invalid authentication credentials.

If you click "Edit  Compose File", I add it for the supabase-kong service, adding a "ports section":
services:
  supabase-kong:
    image: 'kong:2.8.1'
      .....
    ports:
      - '${KONG_HTTP_PORT}:8000/tcp'
    environment:
      .....

authors: DiegoBM ray-bun

repo: coollabsio/coolify


text:
[Bug]: Installation script does EUID check after trying to create rootfs directories

Error Message and Logs
$ curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
curl: (23) Failed writing body (952 != 10156)

Steps to Reproduce

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Example Repository URL
No response
Coolify Version
Doesn't even install lol
Are you using Coolify Cloud?
No (self-hosted)
Operating System and Version (self-hosted)
Ubuntu 20.04.3 LTS
Additional Information
The script actually does a EUID check later on, after it has already tried doing operations that require being root (namely: mkdir), which is pretty dumb.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied
mkdir: cannot create directory ‘/data’: Permission denied

having the same issue, fresh ubuntu 22.04 install mkdir: cannot create directory ‘/data’: Permission denied

You have to run curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash.

i think we have to run it as a sudo user

authors: Bilge itunza


text:
No camera stream for Roborock S8 Pro Ultra

When I try to open the streams from the corresponding datapoint, no stream is started.
I am using version 0.4.4 of the plugin with a Roborock S8 Pro Ultra.
Best regards,
Alex

S8 does not support camera streaming. It does not work in the app. Can't work with the adapter.

authors: MeierAlex copystring


text:
Not able to find intended people on 'Add List'

I tried to add people that I follow to a list, but their names did not show up.

For example, here I am looking for '@NVK', a user I follow. His name is now displayed.

In this case, I was searching for '@rablle' who I also follow. I could not find him.

Why would you follow @nvk?

Thanks for the report, I'm not currently able to get to this, but hopefully will in a few weeks.

Fixed this last week. Current solution is search will show people you follow first. This is just a first pass, much more should be done to improve robustness and recognizability of search.

authors: nvk paulosacramento staab

repo: coracle-social/coracle


text:
Anchor build error No such file or Directory

Can you share some more details here plz

Hey @SamuelDapte, this seems to be a Solana-specific issue.
Basically, when you run the bpf build-chain for the first time, it silently builds the toolchain. This seems like a hanged build at the user and sometimes the user may Ctrl+C out of it or the build might it general fail due to several reasons.But when using the same toolchain again, it doesn't try to rebuild the toolchain as it should but only use it. As the toolchain was never built successfully the first time, this fails and shows not a directory where the built toolchain should have been.
The only way to solve this currently that I know of is to uninstall and re-install Solana and not Ctrl+C this time during initial build process even if it seems to hang

Yes, as @tanmaymunjal said this is dependent on your Solana installation.
I'll note that you can usually fix this error by changing your Solana version with:
solana-install init <VERSION>

and rebuilding again.

authors: SamuelDapte acheroncrypto realbuffalojoe tanmaymunjal

repo: coral-xyz/anchor


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

Updates

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

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

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

labels: library-update, semver-patch

Superseded by #187.


text:
istio configures coraza wasm but does not see wasm log output

I set the Wasm EnvoyFilter as follows, and the config_dump is also effective, but I used sqlmap zaproxy to simulate the attack, and I did not see the log output of wasm denial of the attack, even if SecDebugLogLevel is set to 9,
I checked http_filters and confirmed that the inbound configuration on port 15006 has loaded the type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm rule
Why can't I see the wasm denial attack log? Is it because envoy.filters.http.wasm has not taken effect? Because the system also has a default istio.metadata_exchange wasm configuration? But my customized envoy.filters.http.wasm is INSERT_BEFORE priority
istio version 1.17.2
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpconnectionmanager
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.wasm
        typed_config:
            '@type': type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
            config:
              configuration:
                '@type': type.googleapis.com/google.protobuf.StringValue
                value: |
                  {
                            "directives_map": {
                                "default": [
                                    "SecDebugLogLevel 9",
                                    "SecRuleEngine On",
                                    "SecAuditEngine RelevantOnly",
                                    "SecAuditLogParts ABIJDEFHZ",
                                    "SecAuditLogType Concurrent",
                                    "SecAuditLogRelevantStatus ^(1[0-9]{2}|2[0-9]{2}|3[0-8][0-9]|39[0-9]|40[0-3]|405|5[0-9]{2})$",
                                    "Include @crs-setup-demo-conf",
                                    "Include @owasp_crs/*.conf"
                                ]
                            },
                            "default_directives": "default"
                          }
              root_id: my-wasm-root-id
              vm_config:
                code:
                  local:
                    filename: /data/coraza/main.wasm
                runtime: envoy.wasm.runtime.v8
                vm_id: my-wasm-vm-id

         {
           "name": "envoy.filters.network.http_connection_manager",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
            "stat_prefix": "InboundPassthroughClusterIpv4",
            "route_config": {
             "name": "InboundPassthroughClusterIpv4",
             "virtual_hosts": [
              {
               "name": "inbound|http|0",
               "domains": [
                "*"
               ],
               "routes": [
                {
                 "match": {
                  "prefix": "/"
                 },
                 "route": {
                  "cluster": "InboundPassthroughClusterIpv4",
                  "timeout": "0s",
                  "max_stream_duration": {
                   "max_stream_duration": "0s",
                   "grpc_timeout_header_max": "0s"
                  }
                 },
                 "decorator": {
                  "operation": ":0/*"
                 },
                 "name": "default"
                }
               ]
              }
             ],
             "validate_clusters": false
            },
            "http_filters": [
             {
              "name": "envoy.filters.http.wasm",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
               "config": {
                "root_id": "my-wasm-root-id",
                "vm_config": {
                 "vm_id": "my-wasm-vm-id",
                 "runtime": "envoy.wasm.runtime.v8",
                 "code": {
                  "local": {
                   "filename": "/data/coraza/main.wasm"
                  }
                 }
                },
                "configuration": {
                 "@type": "type.googleapis.com/google.protobuf.StringValue",
                 "value": "{\n          \"directives_map\": {\n              \"default\": [\n                  \"SecDebugLogLevel 9\",\n                  \"SecRuleEngine On\",\n                  \"SecAuditEngine RelevantOnly\",\n                  \"SecAuditLogParts ABIJDEFHZ\",\n                  \"SecAuditLogType Concurrent\", \n                  \"SecAuditLogRelevantStatus ^(1[0-9]{2}|2[0-9]{2}|3[0-8][0-9]|39[0-9]|40[0-3]|405|5[0-9]{2})$\",\n                  \"Include @crs-setup-demo-conf\",\n                  \"Include @owasp_crs/*.conf\"\n              ]\n          },\n          \"default_directives\": \"default\"\n        }\n"
                }
               }
              }
             },
             {
              "name": "istio.metadata_exchange",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
               "config": {
                "vm_config": {
                 "runtime": "envoy.wasm.runtime.null",
                 "code": {
                  "local": {
                   "inline_string": "envoy.wasm.metadata_exchange"
                  }
                 }
                },
                "configuration": {
                 "@type": "type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange"
                }
               }
              }
             },

What is the log you configured in envoy?
On Tue, 20 Jun 2023, 11:02 Erictang, @.***> wrote:

I set the Wasm EnvoyFilter as follows, and the config_dump is also
effective, but I used sqlmap zaproxy to simulate the attack, and I did not
see the log output of wasm denial of the attack, even if SecDebugLogLevel
is set to 9,
I checked http_filters and confirmed that the inbound configuration on
port 15006 has loaded the
type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm rule
Why can't I see the wasm denial attack log? Is it because
envoy.filters.http.wasm has not taken effect? Because the system also has a
default istio.metadata_exchange wasm configuration? But my customized
envoy.filters.http.wasm is INSERT_BEFORE priority
istio version 1.17.2
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: httpconnectionmanager
spec:
configPatches:

applyTo: HTTP_FILTER
match:
listener:
filterChain:
filter:
name: envoy.filters.network.http_connection_manager
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.wasm
typed_config:
@.': type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
config:
configuration:
@.': type.googleapis.com/google.protobuf.StringValue
value: |
{
"directives_map": {
"default": [
"SecDebugLogLevel 9",
"SecRuleEngine On",
"SecAuditEngine RelevantOnly",
"SecAuditLogParts ABIJDEFHZ",
"SecAuditLogType Concurrent",
"SecAuditLogRelevantStatus ^(1[0-9]{2}|2[0-9]{2}|3[0-8][0-9]|39[0-9]|40[0-3]|405|5[0-9]{2})$",
"Include @crs-setup-demo-conf",
"Include @owasp_crs/*.conf"
]
},
"default_directives": "default"
}
root_id: my-wasm-root-id
vm_config:
code:
local:
filename: /data/coraza/main.wasm
runtime: envoy.wasm.runtime.v8
vm_id: my-wasm-vm-id
 {
   "name": "envoy.filters.network.http_connection_manager",
   "typed_config": {
    ***@***.***": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
    "stat_prefix": "InboundPassthroughClusterIpv4",
    "route_config": {
     "name": "InboundPassthroughClusterIpv4",
     "virtual_hosts": [
      {
       "name": "inbound|http|0",
       "domains": [
        "*"
       ],
       "routes": [
        {
         "match": {
          "prefix": "/"
         },
         "route": {
          "cluster": "InboundPassthroughClusterIpv4",
          "timeout": "0s",
          "max_stream_duration": {
           "max_stream_duration": "0s",
           "grpc_timeout_header_max": "0s"
          }
         },
         "decorator": {
          "operation": ":0/*"
         },
         "name": "default"
        }
       ]
      }
     ],
     "validate_clusters": false
    },
    "http_filters": [
     {
      "name": "envoy.filters.http.wasm",
      "typed_config": {
       ***@***.***": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
       "config": {
        "root_id": "my-wasm-root-id",
        "vm_config": {
         "vm_id": "my-wasm-vm-id",
         "runtime": "envoy.wasm.runtime.v8",
         "code": {
          "local": {
           "filename": "/data/coraza/main.wasm"
          }
         }
        },
        "configuration": {
         ***@***.***": "type.googleapis.com/google.protobuf.StringValue",
         "value": "{\n          \"directives_map\": {\n              \"default\": [\n                  \"SecDebugLogLevel 9\",\n                  \"SecRuleEngine On\",\n                  \"SecAuditEngine RelevantOnly\",\n                  \"SecAuditLogParts ABIJDEFHZ\",\n                  \"SecAuditLogType Concurrent\", \n                  \"SecAuditLogRelevantStatus ^(1[0-9]{2}|2[0-9]{2}|3[0-8][0-9]|39[0-9]|40[0-3]|405|5[0-9]{2})$\",\n                  \"Include @crs-setup-demo-conf\",\n                  \"Include @owasp_crs/*.conf\"\n              ]\n          },\n          \"default_directives\": \"default\"\n        }\n"
        }
       }
      }
     },
     {
      "name": "istio.metadata_exchange",
      "typed_config": {
       ***@***.***": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
       "config": {
        "vm_config": {
         "runtime": "envoy.wasm.runtime.null",
         "code": {
          "local": {
           "inline_string": "envoy.wasm.metadata_exchange"
          }
         }
        },
        "configuration": {
         ***@***.***": "type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange"
        }
       }
      }
     },

—
Reply to this email directly, view it on GitHub
https://github.com/corazawaf/coraza-proxy-wasm/issues/208, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYAXRIAHYYJYCURG3ECTXMFRITANCNFSM6AAAAAAZM6UGSA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

istio configmap log configuration
# kubectl -n istio-system get cm istio -o yaml | more
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    accessLogFormat: '{"start_time": "%START_TIME%","req_method": "%REQ(:METHOD)%","x_envoy_original_path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","protocol": "%PROTOCOL%","response_code": "%RESPONSE_CODE%
","response_flags": "%RESPONSE_FLAGS%","bytes_received": "%BYTES_RECEIVED%","bytes_send": "%BYTES_SENT%","duration": "%DURATION%","resp_x_envoy_upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIM
E)%","x_forwarded_for": "%REQ(X-FORWARDED-FOR)%","user_agent": "%REQ(USER-AGENT)%","x_request_id": "%REQ(X-REQUEST-ID)%","authority": "%REQ(:AUTHORITY)%","upstream_host": "%UPSTREAM_HOST%","upstream_clus
ter": "%UPSTREAM_CLUSTER%","upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%","downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%","downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%","resp_x
_foo_fault_flag": "%RESP(X-FOO-FAULT-FLAG)%"}'
    defaultConfig:
      discoveryAddress: istiod.istio-system.svc:15012
      proxyMetadata: {}
      tracing:
        zipkin:
          address: zipkin.istio-system:9411
    enablePrometheusMerge: true

HttpConnectionManager MERGE policy configuration, but viewing envoy config_dump does not take effect
# cat http-merge.yaml
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpconnectionmanager
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.http_connection_manager,
        typed_config: {
           '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager,
            "access_log": [
             {
              "name": "envoy.access_loggers.file",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog",
               "path": "/dev/stdout",
               "log_format": {
                "text_format_source": {
                 "inline_string": "{\"start_time\": \"%START_TIME%\",\"req_method\": \"%REQ(:METHOD)%\",\"x_envoy_original_path\": \"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%\",\"protocol\": \"%PROTOCOL%\",\"response_code\": \"%RESPONSE_CODE%\",\"response_flags\": \"%RESPONSE_FLAGS%\",\"bytes_received\": \"%BYTES_RECEIVED%\",\"bytes_send\": \"%BYTES_SENT%\",\"duration\": \"%DURATION%\",\"resp_x_envoy_upstream_service_time\": \"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%\",\"x_forwarded_for\": \"%REQ(X-FORWARDED-FOR)%\",\"user_agent\": \"%REQ(USER-AGENT)%\",\"x_request_id\": \"%REQ(X-REQUEST-ID)%\",\"authority\": \"%REQ(:AUTHORITY)%\",\"upstream_host\": \"%UPSTREAM_HOST%\",\"upstream_cluster\": \"%UPSTREAM_CLUSTER%\",\"upstream_local_address\": \"%UPSTREAM_LOCAL_ADDRESS%\",\"downstream_local_address\": \"%DOWNSTREAM_LOCAL_ADDRESS%\",\"downstream_remote_address\": \"%DOWNSTREAM_REMOTE_ADDRESS%\",\"resp_x_foo_fault_flag\": \"%RESP(X-FOO-FAULT-FLAG)%\"}\n"
                }
               }
              }
             }
            ]
           }

envoy config_dump did not see HttpConnectionManager FileAccessLog related configuration
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
            "stat_prefix": "inbound_0.0.0.0_9080",
            "route_config": {
             "name": "inbound|9080||",
             "virtual_hosts": [
              {
               "name": "inbound|http|9080",
               "domains": [
                "*"
               ],
               "routes": [
                {
                 "match": {
                  "prefix": "/"
                 },
                 "route": {
                  "cluster": "inbound|9080||",
                  "timeout": "0s",
                  "max_stream_duration": {
                   "max_stream_duration": "0s",
                   "grpc_timeout_header_max": "0s"
                  }
                 },
                 "decorator": {
                  "operation": "productpage.default.svc.cluster.local:9080/*"
                 },
                 "name": "default"
                }
               ]
              }
             ],
             "validate_clusters": false
            },

The log configuration seen by envoy config_dump is in the following two areas, the type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager paragraph cannot see the FileAccessLog configuration
         {
           "name": "envoy.filters.network.tcp_proxy",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy",
            "stat_prefix": "InboundPassthroughClusterIpv4",
            "cluster": "InboundPassthroughClusterIpv4",
            "access_log": [
             {
              "name": "envoy.access_loggers.file",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog",
               "path": "/dev/stdout",
               "log_format": {
                "text_format_source": {
                 "inline_string": "{\"start_time\": \"%START_TIME%\",\"req_method\": \"%REQ(:METHOD)%\",\"x_envoy_original_path\": \"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%\",\"protocol\": \"%PROTOCOL%\",\"response_code\": \"%RESPONSE_CODE%\",\"response_flags\": \"%RESPONSE_FLAGS%\",\"bytes_received\": \"%BYTES_RECEIVED%\",\"bytes_send\": \"%BYTES_SENT%\",\"duration\": \"%DURATION%\",\"resp_x_envoy_upstream_service_time\": \"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%\",\"x_forwarded_for\": \"%REQ(X-FORWARDED-FOR)%\",\"user_agent\": \"%REQ(USER-AGENT)%\",\"x_request_id\": \"%REQ(X-REQUEST-ID)%\",\"authority\": \"%REQ(:AUTHORITY)%\",\"upstream_host\": \"%UPSTREAM_HOST%\",\"upstream_cluster\": \"%UPSTREAM_CLUSTER%\",\"upstream_local_address\": \"%UPSTREAM_LOCAL_ADDRESS%\",\"downstream_local_address\": \"%DOWNSTREAM_LOCAL_ADDRESS%\",\"downstream_remote_address\": \"%DOWNSTREAM_REMOTE_ADDRESS%\",\"resp_x_foo_fault_flag\": \"%RESP(X-FOO-FAULT-FLAG)%\"}\n"
                }
               }
              }
             }
            ]
           }
          }
         ],
         "name": "virtualInbound"
        },

            "server_name": "istio-envoy",
            "access_log": [
             {
              "name": "envoy.access_loggers.file",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog",
               "path": "/dev/stdout",
               "log_format": {
                "text_format_source": {
                 "inline_string": "{\"start_time\": \"%START_TIME%\",\"req_method\": \"%REQ(:METHOD)%\",\"x_envoy_original_path\": \"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%\",\"protocol\": \"%PROTOCOL%\",\"response_code\": \"%RESPONSE_CODE%\",\"response_flags\": \"%RESPONSE_FLAGS%\",\"bytes_received\": \"%BYTES_RECEIVED%\",\"bytes_send\": \"%BYTES_SENT%\",\"duration\": \"%DURATION%\",\"resp_x_envoy_upstream_service_time\": \"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%\",\"x_forwarded_for\": \"%REQ(X-FORWARDED-FOR)%\",\"user_agent\": \"%REQ(USER-AGENT)%\",\"x_request_id\": \"%REQ(X-REQUEST-ID)%\",\"authority\": \"%REQ(:AUTHORITY)%\",\"upstream_host\": \"%UPSTREAM_HOST%\",\"upstream_cluster\": \"%UPSTREAM_CLUSTER%\",\"upstream_local_address\": \"%UPSTREAM_LOCAL_ADDRESS%\",\"downstream_local_address\": \"%DOWNSTREAM_LOCAL_ADDRESS%\",\"downstream_remote_address\": \"%DOWNSTREAM_REMOTE_ADDRESS%\",\"resp_x_foo_fault_flag\": \"%RESP(X-FOO-FAULT-FLAG)%\"}\n"
                }
               }
              }
             },

@jcchavezs
After upgrading to the latest coraza-proxy-wasm 3.0, the following wasm logs appeared. Are these logs related to SecDebugLogLevel?
2023-06-21T10:01:48.560350Z	warning	envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151	wasm log my-wasm-root-id my-wasm-vm-id: [client "10.110.32.80"] Coraza: Access denied (phase 1). Host header is a numeric IP address [file "@owasp_crs/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "2243"] [id "920350"] [rev ""] [msg "Host header is a numeric IP address"] [data "10.110.32.70:80"] [severity "warning"] [ver "OWASP_CRS/4.0.0-rc1"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/6.5.10"] [hostname "10.110.32.70"] [uri "/metrics"] [unique_id "htZAHnJIMYAWIlwqbeu"]
	thread=26
2023-06-21T10:01:48.574701Z	critical	envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1157	wasm log my-wasm-root-id my-wasm-vm-id: [client "10.110.32.80"] Coraza: Access denied (phase 5). Anomaly Scores: (Inbound Scores: blocking=3, detection=3, per_pl=3-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=0, RCE=0,  [file "@owasp_crs/RESPONSE-980-CORRELATION.conf"] [line "12628"] [id "980170"] [rev ""] [msg "Anomaly Scores: (Inbound Scores: blocking=3, detection=3, per_pl=3-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=0, RCE=0, "] [data ""] [severity "emergency"] [ver "OWASP_CRS/4.0.0-rc1"] [maturity "0"] [accuracy "0"] [tag "reporting"] [hostname "10.110.32.70"] [uri "/metrics"] [unique_id "htZAHnJIMYAWIlwqbeu"]
	thread=26
2023-06-21T10:01:48.574794Z	info	envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1148	wasm log my-wasm-root-id my-wasm-vm-id: Finished tx_id="htZAHnJIMYAWIlwqbeu" context_id=15	thread=26
{"start_time": "2023-06-21T10:01:48.557Z","req_method": "GET","x_envoy_original_path": "/metrics","protocol": "HTTP/1.1","response_code": "503","response_flags": "UF","bytes_received": "0","bytes_send": "145","duration": "16","resp_x_envoy_upstream_service_time": "-","x_forwarded_for": "-","user_agent": "Prometheus/2.38.0","x_request_id": "cc68b39b-17b0-97d0-ac24-582829f25ab3","authority": "10.110.32.70:80","upstream_host": "10.110.32.70:80","upstream_cluster": "InboundPassthroughClusterIpv4","upstream_local_address": "-","downstream_local_address": "10.110.32.70:80","downstream_remote_address": "10.110.32.80:51658","resp_x_foo_fault_flag": "-"}

envoy.yaml EnvoyFilter configuration file is as follows:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpconnectionmanager
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.wasm
        typed_config:
            '@type': type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
            config:
              configuration:
                '@type': type.googleapis.com/google.protobuf.StringValue
                value: |
                  {
                            "directives_map": {
                                "default": [
                                    "SecDebugLogLevel 9",
                                    "SecRuleEngine On",
                                    "SecAuditEngine RelevantOnly",
                                    "SecAuditLogParts ABIJDEFHZ",
                                    "SecAuditLogType Concurrent",
                                    "SecDefaultAction \"phase:3,log,auditlog,pass\"",
                                    "SecDefaultAction \"phase:4,log,auditlog,pass\"",
                                    "SecDefaultAction \"phase:5,log,auditlog,pass\"",
                                    "SecAuditLog \"/dev/stdout\"",
                                    "SecAuditLogRelevantStatus ^(1[0-9]{2}|2[0-9]{2}|3[0-8][0-9]|39[0-9]|40[0-3]|405|5[0-9]{2})$",
                                    "Include @crs-setup-demo-conf",
                                    "Include @owasp_crs/*.conf"
                                ]
                            },
                            "default_directives": "default"
                          }
              root_id: my-wasm-root-id
              vm_config:
                code:
                  local:
                    filename: /data/coraza/main.wasm
                runtime: envoy.wasm.runtime.v8
                vm_id: my-wasm-vm-id

authors: ericinfra jcchavezs

repo: corazawaf/coraza-proxy-wasm


text:
Exposing some of the hidden packages behind internal folder.

I think that this internal folder that hides most of exported modules is an unfortunate situation.
Consider a use-case when someone wants to make a rules parser to help migrate off libmodsecurity, in current state this can only be done by actually launching waf via NewWAF function, this works but is a bit uncomfortable.
Furthermore, considering the case above, when broken rule is encountered, in some cases, error message is so obscured with error wrapping and lacks the actual information that can help to find the actual broken rule as opposed to how libmodsecurity reports parse errors (with partial rule and file:linenumber).
By exposing so of the internal packages to public it will allow to reuse them more comfortably and will help improve error messaging, at least there will be no multiple/useless error wrapping for parser code.

Hey! The reason behind this is long-time maintenance; if you want a specific API or set of APIs, please mention them on this issue so we can review this. We don't have any problem with exposing additional APIs as long as it's safe, it doesn't break compatibility, and there is a clear use case

In my case described above I guess I would want access to:

corazawaf.NewWAF()
seclang.NewParser()
parser.FromString()

Do you want to create a new parser, or just add some directives?

No, some utility that checks rules validity and has a bit more verbose error messages in records to where the actual broken rule is (file:linenumber).

Thanks for raising this @s3rj1k. There are a few reasons why we don't
expose the parser and one of them is the API. The parser being internal
allows us to accommodate the API aiming the best for the WAF, exporting it
means we need to maintain compatibility and settle an API. I propose you
the following: We can export the parser through the experimental API and
then you can consume it and propose improvements when it comes to erroring
and UX.
On Fri, Jul 12, 2024 at 11:02 PM s3rj1k @.***> wrote:

No, some utility that checks rules validity and has a bit more verbose
error messages in records to where the actual broken rule is
(file:linenumber).
—
Reply to this email directly, view it on GitHub
https://github.com/corazawaf/coraza/issues/1094#issuecomment-2226348793,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYAWZRT66I3BDRQ2257LZMA76RAVCNFSM6AAAAABKWX5VGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWGM2DQNZZGM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@jptosso Another solution maybe just standalone CLI utility in repository that just loads ruleset and reports error if any, I am fine with doing PRs as long as there is some kind of simplified entry point for rule testing that is.
Also this will be similar to what has libmodsecurity, the also ship standalone CLI to just do rule verification.
This way there is no need to wraparound into experimental API.

This way there is no need to wraparound into experimental API.

experimental API isn't a workaround, it is the official way for us to
expose APIs we don't currently expose. Providing a CLI is not something we
are inclined to for a couple of reasons: 1. you are the first person asking
for it and 2. It is a maintenance burden for us (volunteering project). How
about we expose the parser through an experimental API which we reshape if
needed and you maintain the CLI and if the CLI becomes stable enough we
could think to foster it under coraza? Does that make sense?
On Mon, Jul 15, 2024 at 11:50 PM s3rj1k @.***> wrote:

@jptosso https://github.com/jptosso Another solution maybe just
standalone CLI utility in repository that just loads ruleset and reports
error if any, I am fine with doing PRs as long as there is some kind of
simplified entry point for rule testing that is.
Also this will be similar to what has libmodsecurity, the also ship
standalone CLI to just do rule verification.
This way there is no need to wraparound into experimental API.
—
Reply to this email directly, view it on GitHub
https://github.com/corazawaf/coraza/issues/1094#issuecomment-2229498546,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYAWQAZVWNRV7L47VGTDZMQ7ZBAVCNFSM6AAAAABKWX5VGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRZGQ4TQNJUGY
.
You are receiving this because you commented.Message ID:
@.***>

@jptosso Yea, sound also good

Check https://github.com/corazawaf/coraza/pull/1101/files

authors: fzipi jcchavezs jptosso s3rj1k

repo: corazawaf/coraza


text:
ADCIO-4636) fix: fix color value

🔗 Jira Ticket Number
:recycle: Current situation

:bulb: Proposed solution

grey color값이 피그마와 반대로 들어가 있습니다.
(ex. grey.10이 피그마 grey 80 값으로 잘못 들어가 있음)
:heavy_plus_sign: Additional Information

:test_tube: Testing

:technologist: Reviewer Nudging

:white_check_mark: Checklist

[x] 수정 사항에 대한 테스트를 마쳤습니다.
[ ] 관련 노션 문서를 업데이트하였습니다.
[ ] 디자인 시스템 컴포넌트의 경우 rmp PR 번호 첨부 및 CDS 라벨을 추가하였습니다.

제가 내일 휴가라서...
내일 디자인시스템 작업하셔야 한다면, 해당 pr 머지 부탁드립니다 🙇

repo: corca-ai/cds


text:
remove wildcard query functionality

Like the kubernetes plugin we remove wildcard queries support.

I converted this to draft since it contains commit from #17, this is ready but #17 should be reviewed/merged first

repo: coredns/multicluster


text:
AsyncRequest event missing argument ... when it should not be fired at all

I am trying to set the value of a text field that is being used as typeahead. Because I don't want to trigger a query from Bloodhound, I'm using this line
element.data('ttTypeahead').input.setQuery(newValue, true);

However, Bloodhound is still trying to fetch some data, even though the silent option is being passed. In fact, typeahead:asyncrequest is still being fired, but with a single argument. I tried debugging, and it seems that the event is being called with dataset = undefined, which cause this behavior.
The point is, how to set the value of the input field without triggering the suggestion menu to open, or even Bloodhound from performing an async request?
All and all, there is a problem at the moment and things are not working as expected.

I noticed this too. Only first parameter is available in the next function and the others are undefined. Document says they should be available.
bind('typeahead:asyncrequest', function(a, b, c) {  //b and c are undefined });

@jisotalo Which version of typeahead are you using? The latest release includes #65, which sounds related to this issue.

I am using bundle file typeahead.js 1.0.1 that I downloaded from https://raw.githubusercontent.com/corejavascript/typeahead.js/master/dist/typeahead.bundle.min.js.

authors: jisotalo jlbooker yanickrochon


text:
glide.yaml: vendor ignition v0.17.2

We'd like to update ct within matchbox since it hasn't been updated in a while https://github.com/coreos/matchbox/issues/606. Using Ignition v0.17.2 seems like a good place to make the cut.

Yeah, that would be a problem if it did. Matchbox calls ct.Parse(bytes) and the docs don't quite specify.  Inspecting, it looks like ConvertAs2_0 is available and tests do equality testing against v2.0 still. https://github.com/coreos/container-linux-config-transpiler/blob/master/config/config_test.go#L560 But I may be wrong @dgonyeo
This may be a bit of a chicken and egg problem, because the ct package won't get usage by Tectonic, except through matchbox vendoring it

ct imports the v2_0/types package from Ignition, so the returned ignTypes.Config will be a 2.0.0 config, not a 2.1.0 config. I just checked out this PR and built it to double check, and ct still produces 2.0.0 configs with this change.

Rebased per "updated branch" requirement.

authors: dghubble dgonyeo


text:
travis: build on minimum and current toolchains

This checks that master and further PRs won't break on current
toolchains, nor on older ones used by downstream distributions
(pinning to 1.26 for historical ContainerLinux compatibility).

I enabled a travis weekly job for this repo so that it'll catch if master breaks with newer toolchains.

Digging into this more, it looks like the nightly build failed. I'm okay merging it anyway (since we allow failures on that one) but I thought the error was strange and I couldn't figure out where it was coming from.

@sdemos it failed because of https://github.com/rust-lang/rust/issues/51699. Which is (one of) the reason why nightly is allowed to fail :)

ha I love getting hitting things and discovering that it was literally introduced yesterday. that happened to me with the new panic_implementation macro replacing lang(panic) too. I was surprised by it and discovered it was merged earlier that day when I hit it.
anyway, thanks!

authors: lucab sdemos

repo: coreos/coreos-metadata


text:
Cluster architecture needs to use IP variables

In os/cluster-architectures.md the cloud-configs are hardcoded with IPs they should instead use the private or public IP variables.

Not all platforms support these variables (but most do), which is why they aren't used.
Can you think of a better arrangement we can use to support both use-cases?

We could add a note that the IP 10.0.0.101 should be replaced with the
correct IP.
On Sun, Aug 9, 2015 at 11:40 AM Rob Szumski notifications@github.com
wrote:

Not all platforms support these variables (but most do), which is why they
aren't used.
Can you think of a better arrangement we can use to support both use-cases?
—
Reply to this email directly or view it on GitHub
https://github.com/coreos/docs/issues/557#issuecomment-129221314.

Fixed in https://github.com/coreos/docs/commit/bd7f3d3e1fd0cdd3573f593a29a1c206d8e0304f. Let me know if you can think of any other improvements we can make.

authors: jdloft robszumski

repo: coreos/docs


text:
Error: "invalid memory address or nil pointer dereference" when trying to add new node to existing cluster

Hi,
I'm currently experiencing an issue when trying to add a new node to an existing cluster. I'm running 2.0.3 from within a Docker container. My log looks somewhat like the following:
Feb 27 14:52:58 ip-10-21-1-94.ec2.internal systemd[1]: Starting etcd container...
Feb 27 14:52:58 ip-10-21-1-94.ec2.internal writer_process[4938]: etcd
Feb 27 14:52:58 ip-10-21-1-94.ec2.internal writer_process[4945]: etcd
Feb 27 14:52:58 ip-10-21-1-94.ec2.internal writer_process[4953]: Pulling repository quay.io/coreos/etcd
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal writer_process[4953]: Status: Image is up to date for quay.io/coreos/etcd:v2.0.3
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal systemd[1]: Started etcd container.
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:52:59 etcd: listening for peers on http://0.0.0.0:2380
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:52:59 etcd: listening for peers on http://0.0.0.0:7001
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:52:59 etcd: listening for client requests on http://0.0.0.0:2379
Feb 27 14:52:59 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:52:59 etcd: listening for client requests on http://0.0.0.0:4001
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: could not get cluster response from http://10.21.1.43:2380: Get http://10.21.1.43:2380/members: net/http: request canceled while waiting for connection
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: name = ip-10-21-1-94.ec2.internal
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: data dir = /opt/etcd
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: member dir = /opt/etcd/member
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: heartbeat = 100ms
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: election = 1000ms
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: snapshot count = 10000
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: 2015/02/27 14:53:00 etcdserver: advertise client URLs = http://10.21.1.94:2379,http://10.21.1.94:4001
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: panic: runtime error: invalid memory address or nil pointer dereference
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: [signal 0xb code=0x1 addr=0x0 pc=0x4a5b5d]
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 16 [running]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: runtime.panic(0x7dc1e0, 0xa63493)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/etcdserver.startNode(0xc20803a580, 0x0, 0x0, 0x0, 0xc208044f80, 0x0, 0x0, 0x10, 0x10)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/etcdserver/raft.go:78 +0xdd
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/etcdserver.NewServer(0xc20803a580, 0xc20803a580, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/etcdserver/server.go:171 +0x6bc
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/etcdmain.startEtcd(0xc20807c000, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/etcdmain/etcd.go:162 +0x1013
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/etcdmain.Main()
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/etcdmain/etcd.go:58 +0x1c5
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: main.main()
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/main.go:48 +0x1ab
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 19 [finalizer wait]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: runtime.park(0x4131d0, 0xa67fd8, 0xa66209)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/proc.c:1369 +0x89
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: runtime.parkunlock(0xa67fd8, 0xa66209)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/proc.c:1385 +0x3b
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: runfinq()
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/mgc0.c:2644 +0xcf
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: runtime.goexit()
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/proc.c:1445
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 20 [syscall]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: os/signal.loop()
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/os/signal/signal_unix.go:21 +0x1e
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: created by os/signal.init·1
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/os/signal/signal_unix.go:27 +0x32
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 28 [IO wait]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net.runtime_pollWait(0x7fbec1e58938, 0x72, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/runtime/netpoll.goc:146 +0x66
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net.(*pollDesc).Wait(0xc20807efb0, 0x72, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/fd_poll_runtime.go:84 +0x46
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net.(*pollDesc).WaitRead(0xc20807efb0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/fd_poll_runtime.go:89 +0x42
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net.(*netFD).Read(0xc20807ef50, 0xc208074000, 0x1000, 0x1000, 0x0, 0x7fbec1e573f0, 0xb)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/fd_unix.go:242 +0x34c
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net.(*conn).Read(0xc2080380a0, 0xc208074000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/net.go:122 +0xe7
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/pkg/transport.timeoutConn.Read(0x7fbec1e58f30, 0xc2080380a0, 0x12a05f200, 0x12a05f200, 0xc208074000, 0x1000, 0x1000, 0x7fbec1e590b8, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /Users/unihorn/gopath/src/github.com/coreos/etcd/scripts/release/etcd/gopath/src/github.com/coreos/etcd/pkg/transport/timeout_conn.go:43 +0x16f
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: github.com/coreos/etcd/pkg/transport.(*timeoutConn).Read(0xc2080405e0, 0xc208074000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: :21 +0xcc
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.noteEOFReader.Read(0x7fbec1e59068, 0xc2080405e0, 0xc20803a738, 0xc208074000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:1203 +0x72
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.(*noteEOFReader).Read(0xc208040600, 0xc208074000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: :124 +0xca
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: bufio.(*Reader).fill(0xc2080049c0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/bufio/bufio.go:97 +0x1b3
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: bufio.(*Reader).Peek(0xc2080049c0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/bufio/bufio.go:132 +0x101
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.(*persistConn).readLoop(0xc20803a6e0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:782 +0x95
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: created by net/http.(*Transport).dialConn
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:600 +0x93f
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 26 [runnable]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.(*persistConn).readLoop(0xc20803a2c0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:868 +0x829
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: created by net/http.(*Transport).dialConn
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:600 +0x93f
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 27 [select]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.(*persistConn).writeLoop(0xc20803a2c0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:885 +0x38f
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: created by net/http.(*Transport).dialConn
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:601 +0x957
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: goroutine 29 [select]:
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: net/http.(*persistConn).writeLoop(0xc20803a6e0)
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:885 +0x38f
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: created by net/http.(*Transport).dialConn
Feb 27 14:53:00 ip-10-21-1-94.ec2.internal writer_process[4961]: /usr/local/go/src/pkg/net/http/transport.go:601 +0x957
Feb 27 14:53:01 ip-10-21-1-94.ec2.internal systemd[1]: etcd.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 27 14:53:01 ip-10-21-1-94.ec2.internal writer_process[5026]: etcd
Feb 27 14:53:01 ip-10-21-1-94.ec2.internal systemd[1]: Unit etcd.service entered failed state.
The existing cluster consists of 2 nodes, my etcd.service looks like this:
[Service]
EnvironmentFile=/etc/environment
TimeoutStartSec=0
SyslogIdentifier=writer_process
ExecStartPre=-/usr/bin/docker kill etcd
ExecStartPre=-/usr/bin/docker rm etcd
ExecStartPre=/usr/bin/docker pull quay.io/coreos/etcd:v2.0.3
ExecStart=/bin/bash -c "/usr/bin/docker run
-p 2379:2379
-p 2380:2380
-p 4001:4001
-p 7001:7001
--name etcd
-v /opt/etcd:/opt/etcd
-v /usr/share/ca-certificates/:/etc/ssl/certs
quay.io/coreos/etcd:v2.0.3
-data-dir /opt/etcd
-name %H
-listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001
-advertise-client-urls http://10.21.1.94:2379,http://10.21.1.94:4001
-listen-peer-urls http://0.0.0.0:2380,http://0.0.0.0:7001
-initial-advertise-peer-urls http://10.21.1.94:2380,http://10.21.1.94:7001
-initial-cluster-state existing
-initial-cluster ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001"
ExecStop=/usr/bin/docker kill etcd
I thought at first it might be related to the "could not get cluster response", but a quick check from .94 works:
core@ip-10-21-1-94 /etc/systemd/system $ curl -L http://10.21.1.43:2380/members
[{"id":12394471189341718283,"peerURLs":["http://10.21.2.166:2380","http://10.21.2.166:7001"],"name":"ip-10-21-2-166.ec2.internal","clientURLs":["http://10.21.2.166:2379","http://10.21.2.166:4001"]},{"id":13661735980988760828,"peerURLs":["http://10.21.1.43:2380","http://10.21.1.43:7001"],"name":"ip-10-21-1-43.ec2.internal","clientURLs":["http://10.21.1.43:2379","http://10.21.1.43:4001"]}]
Any help would be hugely appreciated.

@wsimmonds At a quick glance it seems you have a configuration issue with the -initial-cluster flag. Notice that ip-10-21-1-43.ec2.internal is listed twice. I suspect this will not work even though you're using a different port for the peer address. My current understanding is that each member of the cluster requires a unique name. If you want to run two etcd servers on a single machine (not recommend for production), you need to give each etcd instance it's own name. In this case using the hostname is not the best option.
To help me troubleshoot this I need all three etcd services files. Please include the complete service file for each node. For example:
ip-10-21-1-43.ec2.internal
[Service]
EnvironmentFile=/etc/environment
TimeoutStartSec=0
SyslogIdentifier=writer_process
ExecStartPre=-/usr/bin/docker kill etcd
ExecStartPre=-/usr/bin/docker rm etcd
ExecStartPre=/usr/bin/docker pull quay.io/coreos/etcd:v2.0.3
ExecStart=/bin/bash -c "/usr/bin/docker run \
-p 2379:2379 \
-p 2380:2380 \
-p 4001:4001 \
-p 7001:7001 \
--name etcd \
-v /opt/etcd:/opt/etcd \
-v /usr/share/ca-certificates/:/etc/ssl/certs \
quay.io/coreos/etcd:v2.0.3 \
-data-dir /opt/etcd \
-name %H \
-listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 \
-advertise-client-urls http://10.21.1.94:2379,http://10.21.1.94:4001 \
-listen-peer-urls http://0.0.0.0:2380,http://0.0.0.0:7001 \
-initial-advertise-peer-urls http://10.21.1.94:2380,http://10.21.1.94:7001 \
-initial-cluster-state existing \
-initial-cluster ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001"
ExecStop=/usr/bin/docker kill etcd

We also need to investigate why etcd is blowing up here. /cc @yichengq

Thanks kelseyhightower. Case of not seeing the wood for the trees - been modifying so many different configurations lately that I missed that and suspect you are correct. Will let you know outcome shortly.

@wsimmonds
It doesn't work because the name of the node ip-10-21-1-94.ec2.internal doesn't appear on the initial-cluster-list ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001"
etcd doesn't check this beforehand, so it panics here. gonna fix it.
If a member wants to claim multiple peer urls, it appears in initial-cluster several times, e.g., https://github.com/coreos/etcd/blob/master/etcdmain/config.go#L156
And different members should have different names.

@yichengq
Thanks for your response. Indeed the issue wasn't having multiple entries in initial-cluster for the same server with multiple endpoints.
However, it seems adding the node per your suggestion isn't working? (note: I have changed instance to .1.66 and got rid of .1.94 in case wondering about IP address change):
-initial-cluster ip-10-21-1-66.ec2.internal=http://10.21.1.66:2380,ip-10-21-1-66.ec2.internal=http://10.21.1.66:7001,ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001
It results in:
Feb 27 16:42:23 ip-10-21-1-66.ec2.internal writer_process[2506]: 2015/02/27 16:42:23 etcd: error validating peerURLs ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001: member count is unequal
Just to give some background, originally I was trying to bootstrap (via public discovery) a 3-node cluster but experienced the issue detailed #2325. This was due to the nodes starting-up with a gap of over 60 seconds and resulting in only two nodes successfully joining. However, my behaviour was slightly different in that one of the nodes was elected leader:
Feb 27 10:09:44 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:44 discovery: found peer 9151b8e40b023e27 in the cluster
Feb 27 10:09:44 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:44 discovery: found peer bd983c7de20202fc in the cluster
Feb 27 10:09:44 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:44 discovery: found self ac0201e0c386c70b in the cluster
Feb 27 10:09:44 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:44 discovery: found 3 needed peer(s)
...
Feb 27 10:09:45 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:45 raft: ac0201e0c386c70b [q:2] has received 2 votes and 0 vote rejections
Feb 27 10:09:45 ip-10-21-2-166.ec2.internal writer_process[772]: 2015/02/27 10:09:45 raft: ac0201e0c386c70b became leader at term 2
If I try to start an etcd instance via public discovery, it starts in proxy mode (which is expected behaviour because it thinks there are 3 instances). Trying to change cluster using etcdctl member add for that doesn't work - #2380 perhaps? Although it said it had successfully added the instance it remained in an unhealthy state.

@wsimmonds We expect the peer urls to join the cluster is exactly the advertise-peer-urls of the new bootstrapped member. This is mostly for safety, ensures everything behaves correctly, and errors as early as possible. You should add the correct peer urls into the cluster.
This case is interesting. Could you reproduce it? I'd like to dig more into it in a new issue.

@yichengq I will attempt to create a reliable complete set of steps to reproduce the issue and post it here when done.
I understand an expectation of matching the initial-advertise-peer-urls, and in my instance they do match? Here is some config extract from .1.66:
-advertise-client-urls http://10.21.1.66:2379,http://10.21.1.66:4001
-listen-peer-urls http://0.0.0.0:2380,http://0.0.0.0:7001
-initial-advertise-peer-urls http://10.21.1.66:2380,http://10.21.1.66:7001
-initial-cluster-state existing
-initial-cluster ip-10-21-1-66.ec2.internal=http://10.21.1.66:2380,ip-10-21-1-66.ec2.internal=http://10.21.1.66:7001,ip-10-21-1-43.ec2.internal=http://10.21.1.43:2380,ip-10-21-1-43.ec2.internal=http://10.21.1.43:7001,ip-10-21-2-166.ec2.internal=http://10.21.2.166:2380,ip-10-21-2-166.ec2.internal=http://10.21.2.166:7001

@wsimmonds Please open a new issue because it is another problem.
It maintains a cluster info in etcd cluster too. Please check
https://github.com/coreos/etcd/blob/master/Documentation/other_apis.md#list-members or etcdctl member list to see whether they are match.

Hi
I'm having the same problem when using -initial-cluster-state existing.
Double checked and no duplicates.
2015/03/02 16:33:03 no data-dir provided, using default data-dir ./mojo5.etcd
2015/03/02 16:33:03 etcd: listening for peers on http://0.0.0.0:2380
2015/03/02 16:33:03 etcd: listening for client requests on http://0.0.0.0:2379
2015/03/02 16:33:03 etcd: listening for client requests on http://0.0.0.0:4001
2015/03/02 16:33:03 etcdserver: name = mojo5
2015/03/02 16:33:03 etcdserver: data dir = mojo5.etcd
2015/03/02 16:33:03 etcdserver: member dir = mojo5.etcd/member
2015/03/02 16:33:03 etcdserver: heartbeat = 100ms
2015/03/02 16:33:03 etcdserver: election = 1000ms
2015/03/02 16:33:03 etcdserver: snapshot count = 10000
2015/03/02 16:33:03 etcdserver: advertise client URLs = http://192.168.222.3:2379,http://192.168.222.3:4001
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x4bf782]
goroutine 1 [running]:
github.com/coreos/etcd/etcdserver.startNode(0xc208046210, 0x0, 0x0, 0x0, 0xc208038820, 0x0, 0x0, 0x508760, 0xc208031750)
/home/core/share/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/etcdserver/raft.go:78 +0xd2
github.com/coreos/etcd/etcdserver.NewServer(0xc208046210, 0xc2080703f0, 0x0, 0x0)
/home/core/share/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/etcdserver/server.go:171 +0x7cc
github.com/coreos/etcd/etcdmain.startEtcd(0xc208088000, 0x0, 0x0, 0x0)
/home/core/share/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/etcdmain/etcd.go:162 +0x15ee
github.com/coreos/etcd/etcdmain.Main()
/home/core/share/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/etcdmain/etcd.go:58 +0x1fc
main.main()
/home/core/share/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/main.go:48 +0x1de
goroutine 5 [syscall]:
os/signal.loop()
/home/core/go/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
/home/core/go/src/os/signal/signal_unix.go:27 +0x35
goroutine 12 [runnable]:
net/http.(*persistConn).readLoop(0xc208046420)
/home/core/go/src/net/http/transport.go:928 +0x9ce
created by net/http.(*Transport).dialConn
/home/core/go/src/net/http/transport.go:660 +0xc9f
goroutine 13 [select]:
net/http.(*persistConn).writeLoop(0xc208046420)
/home/core/go/src/net/http/transport.go:945 +0x41d
created by net/http.(*Transport).dialConn
/home/core/go/src/net/http/transport.go:661 +0xcbc
goroutine 11 [sleep]:
net.func·019()
/home/core/go/src/net/dnsclient_unix.go:240 +0x5a
created by net.loadConfig
/home/core/go/src/net/dnsclient_unix.go:269 +0x20c

@timhaak - I have got mine working now, but only by listening on a single peer port and calling etcdctl member add prior to starting the node (which I hadn't read/understood previously). My issue seems to have been a combination of several others which are already on the issues list and I'll post more details later or tomorrow.
Prior to starting your instance, have you done etcdctl member add  http://:2380?

Yes think I'm doing something wrong. Was more that I assume it should say x wrong not give run time error.
Sorted out what I needed on my side so not critical to me :)
I should have been using proxy not existing. Was a misunderstanding of the model on my side. I assumed you bootstrapped then added all the servers and they decide between themselves which were active and which slave (proxy).

@timhaak This correct. Everything in etcd 2.0.0 is explicit now. @yichengq Is there a new ticket for the nil pointer issue?

@kelseyhightower This one is the issue to track the panic error. Will fix it later.

@yichengq I've now had time to create a new cluster and work out the exact steps necessary to reliably (at least in my case!) reproduce the panic seen above:

Start up a new 3-node cluster (in my case, I used Public Discovery but I doubt that matters) with etcd v2.0.3
Remove 1 node (etcdctl member remove & take it offline)
Create new node but don't start etcd yet. Configure/start as follows:

initial-cluster-state should be existing
initial-cluster should contain the other peers but NOT this one

Start the new node without having called etcd member add and it should panic

In my case it's listening on 2739/4001 and 2380/7001, not sure if that makes a difference.
Hopefully that will be enough for you to re-create the scenario, otherwise let me know and happy to help more.

authors: kelseyhightower timhaak wsimmonds yichengq

repo: coreos/etcd


text:
doc the relationship between RTT, heartbeat interval and election timeout

Some overview:
0 < heartbeat < 1.5RTT
RTT << election timeout
We should instruct the way for users to set most appropriate timeout, and doc the potential problems when they are set wrong.

I would say around 0.5RTT < heartbeat < 1.5RTT would be a good option. 0.5RTT is about the ping result.

Or we can simply suggest 1 rtt, which is 2 * ping result.

@xiang90 nit: the ping time is a round trip time. It sends out ICMP ECHO_REQUEST with local time, receives ECHO_RESPONSE, and calculate the passed time.

@yichengq You are right.


text:
hack/benchmark: set readall flag true to reuse TCP connections

readall flags ensures that client reads until response is complete.
This helps reuse the same TCP connections, therefore decreasing
TIME_WAIT states in benchmark.
Related to https://github.com/coreos/etcd/issues/4172.

Closing this, because we won't use this script to evaluate the performance. And it's not directly related to etcd.


text:
rafthttp: bump up timeout in pipeline test

Fix https://github.com/coreos/etcd/issues/6283.
The timeout is too short. It could take more than 10ms
to send when the buffer gets full after pipelineBufSize of
requests.

lgtm

authors: gyuho heyitsanthony


text:
The file kube-flannel-rbac.yml is not available in the repository  but is still referenced

Expected Behavior

The documentation on the page troubleshooting should be updated to reflect the absence of said files.
Current Behavior

The documentation currently references the non-existent kube-flannel-rbac.yml file, which was removed in version 0.9.0.
Possible Solution

Update the documentation on the troubleshooting page to reflect the absence of the aforementioned file.
Steps to Reproduce (for bugs)

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Context

An installation which was automated with ansible started failing, since the file was no more available.
Your Environment

Flannel version: Using the master branch
Backend used (e.g. vxlan or udp): ?
Etcd version: ?
Kubernetes version (if used): v1.7.3
Operating System and version: Ubuntu xenial
Link to your project (optional):

we hit the same error kubernetes 1.8.4. can some one provide the RBAC flannel file.

i found this location but this only creates role-bindings not t flannel pod or overlay network
https://gist.github.com/joejulian/a5f308f73bfee7444810870313cec251
check the URL and download 2 files , try  executing one by one see if this helps. i tried but my cluster FLANNEL PODS still craching .
https://gist.github.com/joejulian/
[7:52]
however our flannel pod is crashing

The main kube-flannel.yml was updated to include RBAC resources. Would that work for you?
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

authors: osoriano rawroland rushins

repo: coreos/flannel