profile
viewpoint

alecthomas/gometalinter 3555

DEPRECATED: Use https://github.com/golangci/golangci-lint

d11wtq/dockerpty 130

Pseudo-tty handler for docker Python client

aanand/compose-file 60

Parser for the Compose file format (version 3)

dnephin/compose-addons 48

Tools to supplement the feature set of docker-compose

dnephin/alpine-package-mirror 22

Dockerfile to run an alpine package mirror or private package repo

dnephin/alpine-s6 12

Minimal example of using s6 in a docker container to handle signals as pid1

aluzzardi/dind 8

Docker in Docker Images

dnephin/cobra 2

A Commander for modern Go CLI interactions

dnephin/compose-swarm-sandbox 2

A sandboxed swarm cluster - using compose

issue openedhashicorp/consul

Node/Service Maintenance at Cluster level

Feature Description

An ability to mark a node or its services as in maintenance while the node is down, so when the node comes back in the cluster, it is still in maintenance.

Use Case(s)

In real hardware systems, we sometimes face downtime on specific servers without having the ability to predict when the node will be back again.

When we know in advance that a given node will need maintenance, we use service or node maintenance to evict the node from the cluster, so when it comes back, the node is not taken into account before some checks/sync are performed.

This is especially important on systems storing data (eg: databases, filers...), where some procedures need to be applied before the node can serve data.

This also could be applied in case of a security issue to avoid a given node to receive traffic by marking it unhealthy (without the ability to connect to the node for instance).

created time in 11 minutes

push eventhashicorp/consul

hashicorp-ci

commit sha 2eedfd57e729ba48fc8abf4dd219ba35dbddda68

auto-updated agent/uiserver/bindata_assetfs.go from commit cf38309f6

view details

push time in 2 hours

pull request commenthashicorp/consul

ui: Add 'Search Across' for finer grained searching

:cherries::x: Cherry pick of commit cf38309f6101b744a72a400046ea102432f1d8a9 onto release/1.9.x failed! Build Log

johncowen

comment created time in 2 hours

pull request commenthashicorp/consul

ui: Add 'Search Across' for finer grained searching

:cherries: If backport labels were added before merging, cherry-picking will start automatically.

To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/290718.

johncowen

comment created time in 2 hours

push eventhashicorp/consul

John Cowen

commit sha cf38309f6101b744a72a400046ea102432f1d8a9

ui: Add 'Search Across' for finer grained searching (#9282)

view details

push time in 2 hours

delete branch hashicorp/consul

delete branch : ui/feature/search-props

delete time in 2 hours

PR merged hashicorp/consul

ui: Add 'Search Across' for finer grained searching backport/1.9 theme/ui

This PR adds 'Search Across' functionality to the majority of our search boxes across the UI which allows you to be a little more specific about what properties you would like to search across.

Screenshot 2020-11-27 at 13 46 06

Again, this PR was getting a little big so I felt it better to PR something now and finish additional work in later PRs.

Notes:

  1. We added a 'DataCollection' component here, which is reused everywhere to deal with filter/search/sorting. In this PR I use this outside of the Consul*List components in order to avoid having to add all the searching related attributes to all the Consul*List components, but the more I think about it the more I'd probably change this and move it inside of the Consul*List components. This feels like one of those decisions where there are equal amounts of pros and cons to either approach, but I think having lists 'just work' and being able to potentially compute items based on a property of items to recalculate sorting etc would be best.
  2. We added ember-set-helper here, which we realized that aswell as replacing mut we can also replace {{ref}} with {{did-insert (set this 'ref')}}. So we'd like to use set instead of mut and ref, and gradually replace where we use the older approaches moving forwards.
+2443 -2085

0 comment

174 changed files

johncowen

pr closed time in 2 hours

issue commenthashicorp/consul

service disappears after agent restart

I was wondering if there is an update on this issue, we are on Consul 1.6.2 now and we still see the same behaviour. thanks

ars05

comment created time in 2 hours

issue commentcontainerd/continuity

Broken build on arm64

Closed by #165

smira

comment created time in 2 hours

issue closedcontainerd/continuity

Broken build on arm64

#162 36.67 /go/pkg/mod/github.com/containerd/continuity@v0.0.0-20201119173150-04c754faca46/fs/du_unix.go:97:25: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32)

closed time in 2 hours

smira

push eventcontainerd/continuity

Shengjing Zhu

commit sha 310e183616c481b7237980a7787a26435d311c0d

gha: fix invalid workflow definition Signed-off-by: Shengjing Zhu <zhsj@debian.org>

view details

Shengjing Zhu

commit sha 25269efb6192a3f31d9ef6a57d8631cd48b5f3b9

Fix building on arm64 github.com/containerd/continuity/fs fs/du_unix.go:66:31: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32) fs/du_unix.go:97:31: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32) Signed-off-by: Shengjing Zhu <zhsj@debian.org>

view details

Phil Estes

commit sha 62ef0fffa6a1bed97d4b034c146bc323b2447b72

Merge pull request #165 from zhsj/fix-arm64 Fix building on arm64

view details

push time in 2 hours

PR merged containerd/continuity

Fix building on arm64

github.com/containerd/continuity/fs fs/du_unix.go:66:31: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32) fs/du_unix.go:97:31: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32)

Caused by #163 @dmcgowan

+5 -3

0 comment

2 changed files

zhsj

pr closed time in 2 hours

issue commentcontainerd/continuity

Broken build on arm64

Looks like there's a PR #165 for it

smira

comment created time in 3 hours

issue commentcontainerd/continuity

Broken build on arm64

Introduced in https://github.com/containerd/continuity/commit/bc5e3edd2b742c38c762d928f267ad82922a1b63

cc @dmcgowan

smira

comment created time in 3 hours

issue openedcontainerd/continuity

Broken build on arm64

#162 36.67 /go/pkg/mod/github.com/containerd/continuity@v0.0.0-20201119173150-04c754faca46/fs/du_unix.go:97:25: invalid operation: stat.Blocks * stat.Blksize (mismatched types int64 and int32)

created time in 3 hours

create barnchhashicorp/consul

branch : ui/chore/tabs-reorg

created branch time in 4 hours

PR opened hashicorp/consul

Reviewers
ui: New overlays backport/1.9 theme/ui

This PR continues on with using tippy.js/popper.js to base tooltip/overlay modifiers on. In this case we replace the previous popovers/overlays in the Metrics view with our new {{with-overlay}} modifier.

Notes:

  1. We've kept iterating on how you instantiate your tooltips/overlays in ember using tippy.js. Here we've used the first argument as the content for the overlay, and added an additional returns named parameter in order to 'return' the tippy instance so we can control it via something that feels more ember-like rather than specifying a 'trigger' (you can use the ember on modifier to control the overlay/tooltip)
  2. with-. We felt that calling the modifier with-overlay was slightly better, we'll probably add this to our tooltip modifier also ({{with-tooltip}}) in a further iteration.

We wanted to replace our previous usage of ember-popover so we could completely remove the ember-tooltips addon here, so this meant quite a bit of change to the metrics popovers, notes:

  1. We made a new InformedAction component, which is a very simple HTML/CSS based 'header, text, action plus a cancel' component. Previously we had a 'ConfirmationAlert' component, but we don't always use it for 'confirming', hence the new component which the ConfirmationAlert in turn now uses.
  2. Theres been an idea for a while to add an 'Action' component, which will be an anchor, label or button depending on whether you pass it a href, for or onclick - mainly for passing this around with contextual components and not having to worry about the element name. This was an opportunity to add this component and use it.

Again, we make use of the {{did-insert (set this 'popover')}} 'trick' in-place of {{ref}}, and the only reason the TopologyMetrics::Popover component now has a JS backing class is so that it has a context to set things on - which makes me wonder whether a Context component is possible to avoid these completely empty backing classes.

Lastly, theres probably another PR coming up pretty soon make both modifiers (tooltip/overlay) consistent and cleaning them up slightly, theres probably a lot of reuse to be done between the two also.

overlay

+562 -351

0 comment

33 changed files

pr created time in 4 hours

push eventhashicorp/consul

John Cowen

commit sha 21e83de005ddf4361f932fca52fa39eb30041936

Use Action component

view details

push time in 4 hours

push eventhashicorp/consul

John Cowen

commit sha e1e6c8df5feee217581c71e3c307380debd30139

Add new layers svg sized the same as the other icons

view details

push time in 4 hours

create barnchhashicorp/consul

branch : ui/feature/overlays

created branch time in 5 hours

starteddnephin/pre-commit-golang

started time in 6 hours

issue openedhashicorp/consul

Consul 1.9 UI creates intention with service ID as source instead of service name

Overview of the Issue

The new Consul 1.9 UI permits to create intentions directly from the service topology overview:

Screenshot from 2020-12-01 10-25-31

This works properly for services registered using only the name filed in the definition.

If the service includes an ID field the intention gets created using the service ID as source instead of the service name.

Screenshot from 2020-12-01 10-28-38

The same is confirmed from the API:

curl http://127.0.0.1:8500/v1/connect/intentions | jq
[
  {
    "SourceNS": "default",
    "SourceName": "api-1",
    "DestinationNS": "default",
    "DestinationName": "db",
    "SourceType": "consul",
    "Action": "allow",
    "Precedence": 9,
    "CreateIndex": 178,
    "ModifyIndex": 178
  },
  ...
]

Reproduction Steps

  1. Create a Consul DC with service mesh enabled
  2. Register an api service using the following definition:
service {
  name = "api"
  id = "api-1"
  port = 9003
  connect {
    sidecar_service {
      proxy {
        upstreams = [
          {
            destination_name = "db"
            local_bind_port = 5000
          }
        ]
      }
    }
  }
  check {
    id = "api-check"
    http = "http://localhost:9003/health"
    method = "GET"
    interval = "1s"
    timeout = "1s"
  }
}
  1. Register a db service using the following definition:
service {
  name = "db"
  id = "db-1"
  port = 9004
  connect {
    sidecar_service {}
  }
  check {
    id = "db-check"
    http = "http://localhost:9004/health"
    method = "GET"
    interval = "1s"
    timeout = "1s"
  }
}
  1. Create an intention using the dropdown in the api topology view.

Expected behavior

  • Intetnion between api and db gets created
  • The red arrow turns grey
  • Intention is showed in the Intentions tab of the service instance (/ui/sandbox/services/api/intentions)

Actual behavior

  • Intention between api-1 and db gets created
  • The arrow stays red
  • Intention is not showed in the Intentions tab of the service instance

Workaround

Create the intention manually using CLI or API OR Create the intention using the intentions tab for the Consul DC (/ui/sandbox/intentions)

created time in 8 hours

startedrollacaster/elcontext

started time in 9 hours

startedrougier/nano-emacs

started time in 11 hours

startedrougier/mu4e-dashboard

started time in 11 hours

startedlandakram/org-z

started time in 11 hours

issue commenthashicorp/consul

consul_autopilot_healthy metric is `NaN`

Thanks. You're right. 1 is only returned from a single instance which is the leader.

image

I went back to 1.8.4 to check and only the leader would return 1 and the rest of the agents would return nothing.

If this is expected, please feel free to close the issue, although this is a change in behaviour that might trip others up.

lawliet89

comment created time in 17 hours

push eventhashicorp/consul

Kyle Havlovitz

commit sha 6e62166f6d13da7b52d5684139bdd1b797711a7c

Merge pull request #9009 from hashicorp/update-secondary-ca connect: Fix an issue with updating CA config in a secondary datacenter

view details

push time in 18 hours

issue openedhashicorp/consul

Prometheus does not like it when metrics with dynamically generated labels don't have the same help string as their definitions

Overview of the Issue

When I was testing out the metric definitions I unfortunately did not test what happens when a metric with a similar name but different labels gets added when a definition already exists. I implicitly expected prometheus would use the already-existing help string, but it appears there's a conflict whether you provide an empty help string or a new one. This issue went unseen for a while because we didn't have definitions for many metrics when this was first shipped, and when I was adding definitions for the hundred+ metrics, I did not check the agent logs on any of the servers in the docker cluster I was running - I just looked at the prometheus page output 😞.

Thankfully, it does not appear that any measurements are lost -- prometheus is just very noisy in warning us that the help strings don't match. If you're a user reading this looking for a workaround without upgrading Consul, the best option I see right now is to add drop filters in your log aggregator to ignore the logs that are prometheus help string warnings.

The two forms this bug seems to be taking now are: issues when the prometheus sink first collects its metrics. We see some recently added definitions like consul.fsm.intention and consul.fsm.summary. We also see issues whenever HTTP requests are handled because the new (as of 1.9.0) consul.api.http metric has new labels for every endpoint.

I'm looking into a few ways to fix this. Ideally we're able to provide the same help string when we dynamically generate labels. This will require some changes to the go-metrics prometheus sink to store the definitions on the sink so we can look up if a help string exists when we encounter a metric we haven't written before. If this for some reason isn't possible, then squashing or filtering the error messages before the agent logs them might be a practical, albeit undesirable, way of fixing this for users.

Reproduction Steps

  • Enable prometheus metrics
  • Start up consul with prometheus enabled
  • View post-startup agent logs for first-collection errors
  • Create an http request and view agent logs

Consul info for both Client and Server

telemetry = { prometheus_retention_time = "10s" }

Operating system and Environment details

Debians

Log Fragments

Example one, with issues immediately following agent start on the first prometheus collection:

* collected metric consul_consul_fsm_ca label:<name:"op" value:"set-config" > summary:<sample_count:1 sample_sum:0.12478599697351456 quantile:<quantile:0.5 value:0.12478599697351456 > quantile:<quantile:0.9 value:0.12478599697351456 > quantile:<quantile:0.99 value:0.12478599697351456 > >  has help "" but should have "Deprecated - use fsm_ca instead"
* collected metric consul_fsm_ca summary:<sample_count:1 sample_sum:nan quantile:<quantile:0.5 value:nan > quantile:<quantile:0.9 value:nan > quantile:<quantile:0.99 value:nan > >  has help "Measures the time it takes to apply CA configuration operations to the FSM." but should have ""
* collected metric consul_consul_fsm_ca label:<name:"op" value:"set-roots" > summary:<sample_count:1 sample_sum:0.04682699963450432 quantile:<quantile:0.5 value:0.04682699963450432 > quantile:<quantile:0.9 value:0.04682699963450432 > quantile:<quantile:0.99 value:0.04682699963450432 > >  has help "" but should have "Deprecated - use fsm_ca instead"
* collected metric consul_fsm_intention summary:<sample_count:1 sample_sum:nan quantile:<quantile:0.5 value:nan > quantile:<quantile:0.9 value:nan > quantile:<quantile:0.99 value:nan > >  has help "Measures the time it takes to apply an intention operation to the FSM." but should have ""
* collected metric consul_consul_fsm_ca label:<name:"op" value:"set-provider-state" > summary:<sample_count:2 sample_sum:0.1443130038678646 quantile:<quantile:0.5 value:0.048705000430345535 > quantile:<quantile:0.9 value:0.09560800343751907 > quantile:<quantile:0.99 value:0.09560800343751907 > >  has help "" but should have "Deprecated - use fsm_ca instead"
* collected metric consul_consul_fsm_intention label:<name:"op" value:"delete-all" > summary:<sample_count:1 sample_sum:0.15876099467277527 quantile:<quantile:0.5 value:0.15876099467277527 > quantile:<quantile:0.9 value:0.15876099467277527 > quantile:<quantile:0.99 value:0.15876099467277527 > >  has help "" but should have "Deprecated - use fsm_intention instead"
* collected metric consul_consul_fsm_ca label:<name:"op" value:"increment-provider-serial" > summary:<sample_count:1 sample_sum:0.10190799832344055 quantile:<quantile:0.5 value:0.10190799832344055 > quantile:<quantile:0.9 value:0.10190799832344055 > quantile:<quantile:0.99 value:0.10190799832344055 > >  has help "" but should have "Deprecated - use fsm_ca instead"

Example two, with consul.api.http occurring during runtime:

    2020-11-30T14:56:02.889-0800 [INFO]  agent: error gathering metrics: collected metric consul_api_http summary:<sample_count:3 sample_sum:nan quantile:<quantile:0.5 value:nan > quantile:<quantile:0.9 value:nan > quantile:<quantile:0.99 value:nan > >  has help "Samples how long it takes to service the given HTTP request for the given verb and path." but should have "consul_api_http"

created time in 18 hours

Pull request review commenthashicorp/consul

Backport #9009 to 1.8.x

 type Server struct { 	// autopilot is the Autopilot instance for this server. 	autopilot *autopilot.Autopilot -	// autopilotWaitGroup is used to block until Autopilot shuts down.-	autopilotWaitGroup sync.WaitGroup

It wasn't referenced by anything else, so I thought it had already been removed

kyhavlov

comment created time in 18 hours

more