profile
viewpoint
Brandon Philips philips @RedHatOfficial via @CoreOS San Francisco, CA https://coreos.com Formerly: CTO @CoreOS, SUSE Linux, Rackspace Monitoring, and OSU Open Source Lab.

coreos/torus 1793

Torus Distributed Storage

cconf/cconf.github.com 287

The C Conference

merklecounty/rget 199

download URLs and verify the contents against a publicly recorded cryptographic log

philips/ansible-kubernetes-daemonset 33

Hack to run ansible as a Kubernetes daemonset on Container Linux

philips/backplane-kubernetes-ingress 28

prototype Kubernetes Ingress Controller for Backplane.io

issue commentetcd-io/maintainers

jepsen correctness audit

everything is going well, wrapping up. We hope to have results up by end of Feb.

philips

comment created time in 4 days

startedllgcode/draw2d

started time in 11 days

startednornagon/saxi

started time in 12 days

startedbrendandburns/configula

started time in 14 days

startedpython-social-auth/social-app-django

started time in 14 days

starteddosco/super-graph

started time in 16 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.++The most important aspect of the lease mechanism is that TTL is defined as a physical time interval. Both of the server and client measures passing of time with their own clocks, which are not synchronized each other. It allows a situation that the server revokes the lease but the client still claims it owns the lease because of clock drift.++Then how the lease mechanism guarantees mutual exclusion of the locking mechanism? Actually, the lease mechanism itself doesn't guarantee mutual exclusion. Owning a lease cannot guarantee the owner holds a lock of the resource.++In the case of etcd, mutual exclusion is implemented baesd on the mechanism of version number validation (it is sometimes called compare and swap in other systems like Consul). In etcd's RPCs like `Put` or `Txn`, we can specify required conditions about revision number and lease ID for the operations. If the conditions are not satisfied, the operation can be failed. With this mechanism, etcd provides distributed locking for clients. It means that a client knows that it is acquiring a lock of a key when its requests are completed by etcd cluster successfully.++We can find almost same ideas and designs of distributed locking mechanisms in the below literature:+* In [the paper of Chubby][chubby], the concept of *sequencer* is introduced. The authors interpret that sequencer is an almost same to the combination of revision number and lease ID of etcd.+* In [How to do distributed locking][fencing], Martin Kleppmann introduced the idea of *fencing token*. The authors interpret that fencing token is revision number in the case of etcd.+* In [Practical Uses of Synchronized Clocks in Distributed Systems][physicalclock], we can find a description that Thor implements a distributed locking mechanism based on version number validation and lease.++Why do etcd and other systems use lease if they provide mutual exclusion based on version number validation? Lease works as just an optimization mechanism for reducing aborted requests.

"Lease works as just an" -> "Well, leases provide an"

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.++The most important aspect of the lease mechanism is that TTL is defined as a physical time interval. Both of the server and client measures passing of time with their own clocks, which are not synchronized each other. It allows a situation that the server revokes the lease but the client still claims it owns the lease because of clock drift.++Then how the lease mechanism guarantees mutual exclusion of the locking mechanism? Actually, the lease mechanism itself doesn't guarantee mutual exclusion. Owning a lease cannot guarantee the owner holds a lock of the resource.++In the case of etcd, mutual exclusion is implemented baesd on the mechanism of version number validation (it is sometimes called compare and swap in other systems like Consul). In etcd's RPCs like `Put` or `Txn`, we can specify required conditions about revision number and lease ID for the operations. If the conditions are not satisfied, the operation can be failed. With this mechanism, etcd provides distributed locking for clients. It means that a client knows that it is acquiring a lock of a key when its requests are completed by etcd cluster successfully.++We can find almost same ideas and designs of distributed locking mechanisms in the below literature:

"We can find almost same ideas and designs of distributed locking mechanisms in the below literature:" -> "In distributed locking literature similar designs are described:"

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.++The most important aspect of the lease mechanism is that TTL is defined as a physical time interval. Both of the server and client measures passing of time with their own clocks, which are not synchronized each other. It allows a situation that the server revokes the lease but the client still claims it owns the lease because of clock drift.++Then how the lease mechanism guarantees mutual exclusion of the locking mechanism? Actually, the lease mechanism itself doesn't guarantee mutual exclusion. Owning a lease cannot guarantee the owner holds a lock of the resource.++In the case of etcd, mutual exclusion is implemented baesd on the mechanism of version number validation (it is sometimes called compare and swap in other systems like Consul). In etcd's RPCs like `Put` or `Txn`, we can specify required conditions about revision number and lease ID for the operations. If the conditions are not satisfied, the operation can be failed. With this mechanism, etcd provides distributed locking for clients. It means that a client knows that it is acquiring a lock of a key when its requests are completed by etcd cluster successfully.++We can find almost same ideas and designs of distributed locking mechanisms in the below literature:+* In [the paper of Chubby][chubby], the concept of *sequencer* is introduced. The authors interpret that sequencer is an almost same to the combination of revision number and lease ID of etcd.+* In [How to do distributed locking][fencing], Martin Kleppmann introduced the idea of *fencing token*. The authors interpret that fencing token is revision number in the case of etcd.+* In [Practical Uses of Synchronized Clocks in Distributed Systems][physicalclock], we can find a description that Thor implements a distributed locking mechanism based on version number validation and lease.++Why do etcd and other systems use lease if they provide mutual exclusion based on version number validation? Lease works as just an optimization mechanism for reducing aborted requests.

"use lease" -> "provide leases"

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.++The most important aspect of the lease mechanism is that TTL is defined as a physical time interval. Both of the server and client measures passing of time with their own clocks, which are not synchronized each other. It allows a situation that the server revokes the lease but the client still claims it owns the lease because of clock drift.++Then how the lease mechanism guarantees mutual exclusion of the locking mechanism? Actually, the lease mechanism itself doesn't guarantee mutual exclusion. Owning a lease cannot guarantee the owner holds a lock of the resource.++In the case of etcd, mutual exclusion is implemented baesd on the mechanism of version number validation (it is sometimes called compare and swap in other systems like Consul). In etcd's RPCs like `Put` or `Txn`, we can specify required conditions about revision number and lease ID for the operations. If the conditions are not satisfied, the operation can be failed. With this mechanism, etcd provides distributed locking for clients. It means that a client knows that it is acquiring a lock of a key when its requests are completed by etcd cluster successfully.

baesd -> based

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.++The most important aspect of the lease mechanism is that TTL is defined as a physical time interval. Both of the server and client measures passing of time with their own clocks, which are not synchronized each other. It allows a situation that the server revokes the lease but the client still claims it owns the lease because of clock drift.++Then how the lease mechanism guarantees mutual exclusion of the locking mechanism? Actually, the lease mechanism itself doesn't guarantee mutual exclusion. Owning a lease cannot guarantee the owner holds a lock of the resource.++In the case of etcd, mutual exclusion is implemented baesd on the mechanism of version number validation (it is sometimes called compare and swap in other systems like Consul). In etcd's RPCs like `Put` or `Txn`, we can specify required conditions about revision number and lease ID for the operations. If the conditions are not satisfied, the operation can be failed. With this mechanism, etcd provides distributed locking for clients. It means that a client knows that it is acquiring a lock of a key when its requests are completed by etcd cluster successfully.

"can be failed" -> "can fail"

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.  In theory, it’s possible to build these primitives atop any storage systems providing strong consistency. However, the algorithms tend to be subtle; it is easy to develop a locking algorithm that appears to work, only to suddenly break due to  thundering herd and timing skew. Furthermore, other primitives supported by etcd, such as transactional memory depend on etcd’s MVCC data model; simple strong consistency is not enough.  For distributed coordination, choosing etcd can help prevent operational headaches and save engineering effort. +### Notes on the usage of lock and lease+etcd provides [lock APIs][etcd-v3lock] which is based on [the lease mechanism][lease] and [its implementation in etcd][etcdlease]. The basic idea of the lease mechanism is like this: a server grants a token, which is called lease, to a requesting client. When the server grants a lease, it associates TTL with the lease. When the server detects passing of time longer than TTL, it revokes the lease. During the client holds a non revoked lease, it can claim that it owns an access to a resource associated with the lease. In the case of etcd, the resource is a key. etcd provides lock APIs with this scheme.

"which is based" -> "which are based" "is like this:" -> "is:" "the resource is a key" -> "the resource is a key in the etcd keyspace"

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 If an application reasons primarily about metadata or metadata ordering, such as  ## Using etcd for distributed coordination -etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box. These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.+etcd has distributed coordination primitives such as event watches, leases, elections, and distributed shared locks out of the box (Note that in the case of the distributed shared lock, users need to be aware about its non obvious properties. The detail is described below). These primitives are both maintained and supported by the etcd developers; leaving these primitives to external libraries shirks the responsibility of developing foundational distributed software, essentially leaving the system incomplete. NewSQL databases usually expect these distributed coordination primitives to be authored by third parties. Likewise, ZooKeeper famously has a separate and independent [library][curator] of coordination recipes. Consul, which provides a native locking API, goes so far as to apologize that it’s “[not a bulletproof method][consul-bulletproof]”.

"The detail is described below" -> "The details are described below."

mitake

comment created time in 17 days

Pull request review commentetcd-io/etcd

WIP, RFC Documentation: enhance description of lock and lease

 etcd does not ensure linearizability for watch operations. Users are expected to  etcd ensures linearizability for all other operations by default. Linearizability comes with a cost, however, because linearized requests must go through the Raft consensus process. To obtain lower latencies and higher throughput for read requests, clients can configure a request’s consistency mode to `serializable`, which may access stale data with respect to quorum, but removes the performance penalty of linearized accesses' reliance on live consensus. +### Granting, attaching and revoking leases++etcd provides [the lease mechanism][lease]. The primary usage of lease is implementing distributed coordination mechanisms like distributed locks. The lease mechanism itself is simple: a lease can be created with grant API, attached to a key with put API, revoked with revoke API, and expired by passing of time. However, users need to be aware about [the important properties of the APIs and usage][why] for implementing correct distributed coordination mechanisms.

"The primary usage of lease" -> "The primary use case of a lease" "a lease can be created with grant API" -> "a lease can be created with the grant API" "attached to a key with put API" -> "attached to a key with the put API" "revoked with revoke API" -> "revoked with the revoke API" "and expired by passing of time." -> "and will be expired by the wall clock time to live (TTL)."

mitake

comment created time in 17 days

starteddjango/django

started time in 17 days

startedkognise/water.css

started time in 19 days

starteddohliam/dropin-minimal-css

started time in 19 days

startedrfjakob/gocryptfs

started time in 20 days

startedstr4d/rage

started time in 20 days

startedchriskiehl/Gooey

started time in 20 days

startedAorimn/dislocker

started time in 20 days

push eventphilips/etc

Brandon Philips

commit sha 6f74593cf7584e979969a7e9f52c1cde7e2881ac

vimrc: fix q printing in neovim with Prompt 2 sigh... Prompt 2 idents as something neovim doesn't understand triggering some misfeature. Fixed now.

view details

push time in a month

push eventphilips/etc

Brandon Philips

commit sha 520ae036c27ef4df5721596953bb454fb68d2235

bashrc: add journal alias

view details

push time in a month

startedStreisandEffect/streisand

started time in a month

startedsignalapp/ContactDiscoveryService

started time in a month

startedzedeus/nitter

started time in a month

startedpirate/ArchiveBox

started time in a month

startedWorldBrain/storex

started time in a month

startedWorldBrain/storex-sync

started time in a month

starteddogsheep/github-to-sqlite

started time in a month

startedWorldBrain/Memex

started time in a month

startedmitchellh/gon

started time in a month

startedNetflix/zuul

started time in a month

startedaquasecurity/kube-hunter

started time in a month

pull request commentetcd-io/etcd

Restructure documentation source files

Sorry @lucperkins just to be clear I am not saying that we shouldn't remove v2 docs. But, some analysis should be ran to see how many links exist to the v2 docs and which docs they are so we can make an informed decision on which ones to port vs drop.

lucperkins

comment created time in a month

pull request commentetcd-io/etcd

Restructure documentation source files

The trouble with getting rid of v2 entirely is there are links back to v2 docs. e.g. Documentation/metrics.md links to v2/metrics.md https://github.com/etcd-io/etcd/pull/11412/files#diff-4e0502c268b93a783e61e10d1ac1cb99L117

lucperkins

comment created time in a month

pull request commentetcd-io/website

Welcome blog post

Formatting looks weird to me. Screen Shot 2019-12-17 at 2 43 06 PM

cc @jberkus

lucperkins

comment created time in a month

push eventphilips/etc

Brandon Philips

commit sha 447adb0248024d2e90f55d5a202e62cb85d338cc

config: enable nvim compat add this symlink so stuff roughly works between vim and nvim

view details

push time in a month

push eventphilips/etc

Brandon Philips

commit sha 51192df84b01e0a525cdc73f93e4a0860c624057

pass-exportify-backup: stupid alias to put exportify into pass

view details

push time in a month

startedpavelkomarov/exportify

started time in a month

startedwatsonbox/exportify

started time in a month

startedsecuvera/SpotMyBackup

started time in a month

startedkickscondor/fraidycat

started time in a month

push eventphilips/gce-shell

Brandon Philips

commit sha 118ab5aabea078d3bd4ec16361d8156c99f1b7be

wip

view details

Brandon Philips

commit sha 52cf9f1eecd438fbb790c81437b34264b93808d1

wip

view details

Brandon Philips

commit sha 0e0c1ebe6c255836004a90029fccca0a1b2f58cf

wip

view details

Brandon Philips

commit sha d50176f3def0839289a121b11f44b5015da4f0b6

hack: use debug container to get busybox

view details

push time in 2 months

startedfirmai/awesome-google-colab

started time in 2 months

push eventphilips/gce-shell

Brandon Philips

commit sha 44d87ad9c5f02aab516c24546c3d6834b160efd0

wip

view details

push time in 2 months

push eventphilips/gce-shell

Brandon Philips

commit sha 844ac5f80a07f25dcf1b0d22949a39f237e5d980

wip

view details

push time in 2 months

create barnchphilips/gce-shell

branch : master

created branch time in 2 months

created repositoryphilips/gce-shell

created time in 2 months

startedrust-lang/mdBook

started time in 2 months

startedFiloSottile/age

started time in 2 months

issue commentkubernetes/release

Add Cryptographic Digests to GitHub Releases Body

This can be closed. rget is going to execute on a design to support arbitrary URLs https://github.com/merklecounty/rget/issues/10#issuecomment-555630002

/close

justaugustus

comment created time in 2 months

issue commentmerklecounty/rget

design: run our own transparency log

Wrote a design doc on this. I think it is clear there is utility for rget but supporting arbitrary URLs is a critical feature and to do that we have to get rid of the SHA256SUMS + Let’s Encrypt cert hack.

philips

comment created time in 2 months

startedvitessio/vitess

started time in 2 months

startedgoodclass/scipy_arm64

started time in 2 months

startedholzschu/Carnets

started time in 2 months

issue commentblinksh/blink

[Feature] Support Toggling "Mirror" vs "Extended" modes for external displays

+1 to mirroring. I tried to do a demo and was so confused by the default behavior.

petermbenjamin

comment created time in 2 months

pull request commentkubernetes/security

Include distributors-announce in public security announcements

Yes, last time I looked into all of this when I set it up @googlegroups.com can't nest.

On Fri, Nov 15, 2019 at 4:08 PM Tim Allclair (St. Clair) < notifications@github.com> wrote:

I was under the impression that groups outside an apps domain couldn't be nested, but I'm no expert on the matter...

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/kubernetes/security/pull/59?email_source=notifications&email_token=AAAIGCERLNUXQRWXACZL7STQT42WLA5CNFSM4JN65PM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHC6EY#issuecomment-554577683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCHTNY7O7AXWBYPFYB3QT42WLANCNFSM4JN65PMQ .

tallclair

comment created time in 2 months

startedquay/quay

started time in 2 months

startedfogleman/axi

started time in 2 months

startedautomerge/automerge

started time in 3 months

pull request commentkubernetes/security

OWNER_ALIASES: add Luke Hinds

/lgtm

philips

comment created time in 3 months

issue commentetcd-io/maintainers

jepsen correctness audit

The audit is now underway with @mitake @gyuho involved and all etcd maintainers subscribed to updates.

philips

comment created time in 3 months

startedywangd/stash

started time in 3 months

issue commentetcd-io/maintainers

Third-party security audit

I think Mitake should be involved since he worked on some of the auth stuff originally.

On Fri, Nov 1, 2019 at 7:01 AM Sahdev Zala notifications@github.com wrote:

@caniszczyk https://github.com/caniszczyk thanks! Please consider @xiang90 https://github.com/xiang90 @gyuho https://github.com/gyuho and myself for now. Also please keep @philips https://github.com/philips in the loop. I believe we can change one or two individuals here if needed due to schedule conflict/travel etc? /cc @xiang90 https://github.com/xiang90 @gyuho https://github.com/gyuho @philips https://github.com/philips - hope this is fine per earlier discussion. Should we ask Mitake as well? Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/maintainers/issues/18?email_source=notifications&email_token=AAAIGCCSMA4XNT4TLYEQUA3QRQZC7A5CNFSM4IYOJE22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC276YY#issuecomment-548798307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCBAHUNIIO3FDCWB4GTQRQZC7ANCNFSM4IYOJE2Q .

philips

comment created time in 3 months

push eventcoreos/flannel

Brandon Philips

commit sha 960b3243b9a7faccdfe7b3c09097105e68030ea7

MAINTAINERS: remove @philips

view details

push time in 3 months

pull request commentetcd-io/discovery.etcd.io

Move discovery server source code to discovery.etcd.io repo

Done.

On Wed, Oct 30, 2019 at 2:56 PM Victor Trac notifications@github.com wrote:

@philips https://github.com/philips I spoke with @idvoretskyi https://github.com/idvoretskyi about this over the weekend, and we both think it may be better to put the go code for discoveryserver into its own repo, leaving the infra/meta stuff in this repo.

I don't have access to do this. Can you make a new discoveryserver repo and add me and @eduartua https://github.com/eduartua as a writer? I'll work with @eduartua https://github.com/eduartua to commit this code there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/pull/15?email_source=notifications&email_token=AAAIGCHPLR6JRTGVLCALIBDQRH7J5A5CNFSM4JE6V7D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECV4YRY#issuecomment-548129863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCEE3JVWZZQNHYABSN3QRH7J5ANCNFSM4JE6V7DQ .

eduartua

comment created time in 3 months

created repositoryetcd-io/discoveryserver

created time in 3 months

startedbelak/go-gitdir

started time in 3 months

startedEventStore/EventStore

started time in 3 months

pull request commentkubernetes/community

sigs.yaml: Add Luke Hinds to security committee

@cblecker rebased PTAL and approve

philips

comment created time in 3 months

push eventphilips/community

Devan Carpenter

commit sha 76f7827eda330c06ac09191af7a244d3203e2ff5

Contributor Testing Guide: Add section on smooth PR review process

view details

Devan Carpenter

commit sha af108e4f6e1c819992843e4c8dde06ffb52d5e70

Contributor Testing Guide: Update punctuation and grammar

view details

Tim Pepper

commit sha 454fdf6caa10aefaca6c4b131e498a14d02fc95d

cherry-picks: bump up guidance on criteria, add table of contents We see a relatively high volume of cherry picks that aren't clearly meeting the criteria for cherry-picking, but that criteria has only recently started to be in written, shared form and it is not super discoverable. To make it more clear let's make that its own section (linkable), move it earlier in the document, and add a table of contents to the cherry-picks.md for navigation. Signed-off-by: Tim Pepper <tpepper@vmware.com>

view details

Nikhita Raghunath

commit sha 9cabf2b15a45eb1b5461af58b658aee8f79d11a3

Add public steering-committee slack channel

view details

Omar Mehilba

commit sha b525a1230aef0d633db66542da57f8978b03aa8d

Add meetup-egypt channel

view details

Kubernetes Prow Robot

commit sha c80c4128c64f6e62d5829340bd49dd74721f44ef

Merge pull request #4189 from mehilba/master Add meetup-egypt channel

view details

Walter Fender

commit sha 72406fa286e5bee0533344b9d37616e601c4975f

Adding slack channels and owners for the cloud provider SIG. Fixed restrictions for sig-cloud-provider channels. Remove old ref to channel and set id on new one.

view details

Kubernetes Prow Robot

commit sha e0c2c155d9eb1cb462d458706f1adeb0fdc14bfa

Merge pull request #4186 from tpepper/prt-cherry-pick-review cherry-picks: bump up guidance on criteria, add table of contents

view details

Kubernetes Prow Robot

commit sha 9c204cc22321217f88f88a01d10ecd8f171c2d13

Merge pull request #4187 from nikhita/steering-slack Add public steering-committee slack channel

view details

Nikhita Raghunath

commit sha 761d8209bb97f1514aa9336a002f9a3725bafb51

sigs.yaml: add steering-committee slack channel

view details

Kubernetes Prow Robot

commit sha 529626ec3b3f23bb7ea3f219a73dff548d0db63c

Merge pull request #4191 from nikhita/steering-slack-sigs-yaml sigs.yaml: add steering-committee slack channel

view details

Kubernetes Prow Robot

commit sha 118268546888ec281526bb12e8fa8816c3dc0483

Merge pull request #4170 from ii/testing-guide-pr-update Contributor Testing Guide: Add section on smooth PR review process

view details

Kubernetes Prow Robot

commit sha 9e3689677b59cfcdebd83a9955ba90dda591c9b1

Merge pull request #4178 from cheftako/network-proxy Adding slack channels and owners for the cloud provider SIG.

view details

Christoph Blecker

commit sha 355c906a68b8f719d6ab8834b8579e5ff0f73962

Update Code of Conduct Committee membership

view details

Walter Fender

commit sha 3453e7240b9557df07c717ae2ed45acffcdf5158

Moving all provider slack channels under sig-cloud-provider. Follow up from discussion on pull 4178. alpha sort.

view details

Kubernetes Prow Robot

commit sha b8c516c8500b9f3aca997342c63ba1b0c5affbca

Merge pull request #4195 from cblecker/coc Update Code of Conduct Committee membership

view details

Kubernetes Prow Robot

commit sha d17825d918f725063ec48d53a1b4a57abf3e8d5c

Merge pull request #4193 from cheftako/network-proxy Moving all provider slack channels under sig-cloud-provider.

view details

Brandon Philips

commit sha aab90dc1b3c9f0b2c4a69505a3335e9d756fd9b0

sigs.yaml: Add Luke Hinds to security committee Add via https://github.com/kubernetes/security/pull/51

view details

push time in 3 months

issue commentetcd-io/discovery.etcd.io

Implement Cloud Build for CI/CD

Cloudbuild is probably fine. Quay was working fine too.

On Tue, Oct 22, 2019 at 8:18 AM Eduar Tua notifications@github.com wrote:

@philips https://github.com/philips I'm going to explore the repository and see how we can isolate the discovery server go code. Do you think this is a good approach to implement the cloudbuild pipeline?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/issues/12?email_source=notifications&email_token=AAAIGCFMSOGUG5TIGD5UIE3QP4KSNA5CNFSM4IUEU2KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6D6VQ#issuecomment-545013590, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCBIDNLRBEQFL4UCM43QP4KSNANCNFSM4IUEU2KA .

victortrac

comment created time in 3 months

issue commentkubernetes/org

REQUEST: New membership for lukehinds

+1 /lgtm

lukehinds

comment created time in 3 months

pull request commentetcd-io/discovery.etcd.io

Backport VPC and GKE to terraform

Yes, sounds good.

On Mon, Oct 21, 2019 at 3:58 PM Victor Trac notifications@github.com wrote:

@philips https://github.com/philips You're right about these two issues.

  1. There's a 10 min TTL on the A record for discovery.etcd.io at the moment. We can reduce to to 60s prior to the migration to reduce the likelihood of this happening, but it's not going to completely eliminate the issue. Also, my intuition says that cluster members will be using the same DNS server (since they'll likely be in the same datacenter), so it seems exceedingly unlikely that a member will resolve an IP address prior to TTL expiration (with the old IP) and then another member will grab the new IP after expiration.
  2. I can see this happening for a very slow to bootstrap cluster. If a member starts and resolves the old discovery service and then subsequent members don't bootstrap until after the TTL refreshes to the new discovery service, then this will happen. Again, this seems exceedingly unlikely if end-users are using automated processes to bootstrap the cluster, since the cluster members will likely come up fairly simultaneously.

The traffic is fairly low, and we'll do the DNS swap during low-traffic periods. We'll also notify the dev mailing list. There are (time) expensive technical ways to possibly mitigate these concerns further, but they don't seem worth it to me. Does this address your concerns?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/pull/14?email_source=notifications&email_token=AAAIGCDUVRYB6OC4WKR2FZ3QPYXY5A5CNFSM4JCMSWUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4B32I#issuecomment-544742889, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCDTILHXBGUDRCGGV2LQPYXY5ANCNFSM4JCMSWUA .

eduartua

comment created time in 3 months

pull request commentkubernetes/security

OWNER_ALIASES: add Luke Hinds

xref https://github.com/kubernetes/community/pull/4188#issuecomment-544728369

philips

comment created time in 3 months

pull request commentkubernetes/security

OWNER_ALIASES: add Luke Hinds

@lukehinds you need to file this issue: https://github.com/kubernetes/org/issues/new?assignees=&labels=area%2Fgithub-membership&template=membership.md&title=REQUEST%3A+New+membership+for+<your-GH-handle>

See this doc: https://github.com/kubernetes/community/blob/master/community-membership.md#member

philips

comment created time in 3 months

PR opened kubernetes/community

sigs.yaml: Add Luke Hinds to security committee

Add via https://github.com/kubernetes/security/pull/51

<!-- Thanks for sending a pull request! Here are some tips for you:

  • If this is your first contribution, read our Getting Started guide https://github.com/kubernetes/community/blob/master/contributors/guide/README.md
  • If you are editing SIG information, please follow these instructions: https://git.k8s.io/community/generator You will need to follow these steps:
    1. Edit sigs.yaml with your change
    2. Generate docs with make generate. To build docs for one sig, run make WHAT=sig-apps generate -->
+6 -1

0 comment

4 changed files

pr created time in 3 months

create barnchphilips/community

branch : add-luke-hinds

created branch time in 3 months

pull request commentkubernetes/security

OWNER_ALIASES: add Luke Hinds

/approve

philips

comment created time in 3 months

PR opened kubernetes/security

OWNER_ALIASES: add Luke Hinds

Via 18e94b8c9a50502a1b4db8aefe98538a9e850d69

+1 -0

0 comment

1 changed file

pr created time in 3 months

push eventphilips/security

Kubernetes Prow Robot

commit sha 77e26c6794ce8f7dee08722dace13736c16c5213

Merge pull request #51 from philips/add-luke-hinds README: add Luke Hinds to Security Committee

view details

Brandon Philips

commit sha 1b076a10648895f3eb09de754bcbf85d1dbd9db8

OWNER_ALIASES: add Luke Hinds Via 18e94b8c9a50502a1b4db8aefe98538a9e850d69

view details

push time in 3 months

push eventphilips/community

Brandon Philips

commit sha 4aa59cb3c689dced079cc7ac54df8158a8b79615

sigs.yaml: Add Luke Hinds to security committee Add via https://github.com/kubernetes/security/pull/51

view details

push time in 3 months

pull request commentetcd-io/discovery.etcd.io

Backport VPC and GKE to terraform

@victortrac How are you going to migrate the data? There are two issues with migrating to a new cluster:

  1. DNS split horizon for the length of the domain TTL will cause boot strapping to fail
  2. All of the data will be lost so any cluster mid-bootstrap will fail

If doing this migration is the only option please do send an email to etcd-dev@googlegroups.com to give everyone a heads up.

I can't review the terraform code however, I don't know it well enough anymore.

eduartua

comment created time in 3 months

push eventmerklecounty/rget

Brandon Philips

commit sha b52ab3bc93e713353c62fccf89a245ff8d2daccd

README: update to new etcd Certificate renewal doesn't seem to be working... update to a new etcd anyways.

view details

push time in 3 months

startedaaronpenne/generative_art

started time in 3 months

pull request commentkubernetes/security

README: add Luke Hinds to Security Committee

/lgtm /approve

philips

comment created time in 3 months

startedfogleman/primitive

started time in 3 months

startedfogleman/ln

started time in 3 months

startednoobaa/noobaa-core

started time in 3 months

issue commentetcd-io/maintainers

Third-party security audit

thanks xiang. It would be great to get a few dates together that would work for people to start so the CNCF can start the contract drafts.

On Thu, Oct 17, 2019 at 10:59 AM Xiang Li notifications@github.com wrote:

assigned to Guyho and myself.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/etcd-io/maintainers/issues/18?email_source=notifications&email_token=AAAIGCEXXOJURPV3S3AWBELQPCRXPA5CNFSM4IYOJE22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQ7RBY#issuecomment-543291527, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCGBEQVMETEMOP4UK63QPCRXPANCNFSM4IYOJE2Q .

philips

comment created time in 3 months

push eventphilips/pg-go-queue

Brandon Philips

commit sha 419501b4e3683ddcf5b0716865ddbaed8cf89a3f

queue: add docs Write a simple doc package and fill out some of the methods.

view details

push time in 3 months

push eventphilips/etc

Brandon Philips

commit sha 29645977177844f8be5c968c6fb0fe98be6af825

bashrc: add location of new $GOPATH/bin I used to set GOPATH to home which would put stuff into $HOME/bin but that is no longer reasonable with all of the GOPATH changes. So, just add go/bin to my path.

view details

push time in 3 months

push eventphilips/pg-go-queue

Brandon Philips

commit sha 10c91261e19d0a3aef3c6ae6c1292cc0968d112e

queue: add tests Cover the major operations in a simple test.

view details

push time in 3 months

startedpublicsuffix/list

started time in 3 months

issue commentetcd-io/maintainers

jepsen correctness audit

Pingd @gyuho about this today.

philips

comment created time in 3 months

startedcretz/bine

started time in 3 months

startedsharkdp/hyperfine

started time in 3 months

more