profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/fxposter/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

fxposter/carrierwave-processing 87

Additional processing support for MiniMagick and RMagick

fxposter/encoding_checker 6

This gem will helps you identify lines and characters of the text which are invalid for particular encoding

antonversal/typography 4

Simple rails plugin to make text more readable by applying some typographic rules to string.

fxposter/contacts 4

Ruby library for consuming Google, Yahoo!, Flickr and Windows Live contact APIs

fxposter/em-websocket 4

EventMachine based WebSocket server

fxposter/calendar_helper 3

Calendar-generating plugin for Ruby

fxposter/autotest-fsevent 2

Use FSEvent (Mac OS X 10.5 or higher) instead of filesystem polling.

fxposter/bin_packing 2

One-dimensional bin packing algorithm, solved with hill climbing, tabu search and GA.

fxposter/bootstrap-sass 2

bootstrap-sass is bootstrap for Rails, ready to roll

fxposter/ckeditor 2

Ckeditor integration gem for rails

issue commentlima-vm/lima

chown/chmod on mounted directory: Permission denied

Is there any way forward here? I get similar "permission denied" errors and it's not clear whether it can be fixed in current setup at all.

I am using lima with docker and regardless on whether I use rootless docker or rootful docker + sudo - I still get permission denied errors. Is it an sshfs limitation? or can we expect it to work in the future (ignoring 9p work).

solarkraft

comment created time in 13 hours

create barnchfxposter/go-control-plane

branch : simple-cache-ordering

created branch time in 3 months

push eventfxposter/go-control-plane

Pavel Forkert

commit sha 240249736317ad9060dcfd7e9ae99d3ad8d850f6

Add 3 separate sotw.Server#process implementations to allow for clients to chose whether they need ordered on unordered ADS servers Signed-off-by: Pavel Forkert <fxposter@gmail.com>

view details

push time in 3 months

pull request commentenvoyproxy/go-control-plane

SOTW variants

@snowp @alecholmez @kyessenov @jessicayuen

fxposter

comment created time in 3 months

PR opened envoyproxy/go-control-plane

SOTW variants

This is basically a continuation of https://github.com/envoyproxy/go-control-plane/pull/357, which instead of replacing current sotw.Server#process implementation - adds 3 more implementations and ability to switch between them.

After https://github.com/envoyproxy/go-control-plane/pull/443 is merged - go-control-plane can support my original goals of being able not to have traffic drops when you have multiple resource types changed in a single "step", ie: if you change both CDS and EDS resource at the same time the only correct way to send these resources down the line is to send CDS first and EDS second (https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#eventual-consistency-considerations).

Currently the user of this library cannot do this at all, cause if they pushe both CDS and EDS responses into their channels on the cache side in order - the select loop here (https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/sotw/v3/server.go#L195) does not guarantee that CDS will be selected first and EDS next.

Now, to actual implementations:

  1. server_default.go - it is a copy of original sotw.Server#process implementation, to be able to "fall back to good state"
  2. server_xds.go - works in the same way as the default one (responses channel is recreated on every valid incoming request), but only supports single resource type, which covers non-ADS protocol part. it is simpler than default one and (probably) a bit faster, given the fact that it just removes a bunch of stuff that non-ADS requests do not need.
  3. server_ordered_ads.go - completely different implementation for ADS, that instead of creating a separate channel for each incoming request and abandoning the old one - uses (and reuses) single channel for all request types. the main benefit is that you no longer have a select that breaks ordering, so that if cache pushes CDS first and EDS second - this implementation guarantees that server will actually send updates to the wire in this order. Downside (as was discussed in previous PRs) - you no longer have backpressure per resource. ie: in default implementation if cache decides to send 2 CDS updates - the second one will be blocked, cause the channel has buffer of size 1 and second push to the channel will be blocked, but pushes to channels of other type urls can succeed as long as corresponding channels are empty. This implementation due to channel reuse and the fact that the channel is shared between type urls - if your cache implementation sends many EDS updates, for example - it might be blocked on channel push when there is a CDS update.
  4. server_unordered_ads.go - reimplementation of the default behaviour, but based on reflect.Select, which eliminates duplication in original implementation and allows having any number of type urls supported without the need to fall back to either shared channel for non-LDS/RDS/CDS/EDS and does not require any additional goroutines if there is a need for same "backpressure semantics" for these non-main type urls.
+847 -324

0 comment

6 changed files

pr created time in 3 months

create barnchfxposter/go-control-plane

branch : sotw-variants

created branch time in 3 months