Mixer-driven routing (was: Support for session affinity based routing)

@cosminilie commented on Wed May 17 2017
Hello,
I'm not sure if this is the best place to raise the issue (or feature request) but anyway i wanted to know if you support/or plan supporting routing based on session affinity. Our use case is a bit messy  since we have a big monolith application with some microservices. Basically we're striping out pieces of the application (monolith) into their own micro services but this is a slow process. We're looking into using a service mesh for both the monolith and the decoupled services however we would need support to route traffic though an ingress controller based on session affinity to our monolith while the rest of the services we can use any of the other load balancing methods provided by istio. By session affinity(sticky sessions) we mean something like Nginx http://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_with_ip_hash. Right now we're using the nginx ingress controller configured with https://github.com/kubernetes/ingress/tree/master/examples/affinity/cookie/nginx for the monolith.

@kyessenov commented on Wed May 17 2017
Hi,
Envoy supports consistent hashing for upstreams (see https://lyft.github.io/envoy/docs/intro/arch_overview/load_balancing.html#ring-hash). We'd be interested in exposing this in Istio. The route might provide the header key on which to hash on, and the consistent hash load balancer policy will adapt to changes in the upstream hosts.
Is something like what I described sufficient for your use case?
cc @rshriram

@cosminilie commented on Thu May 18 2017
Yes i think this will work, however by looking at the Envoy page there might also be a scenario where some form of weighting would be needed. For example when scaling down, you will want to not forward any new requests to a particular instance and leave the current sessions to timeout or for the people to log out. After that you can safely remove the instance from the hash ring.

@rshriram commented on Thu May 18 2017
The standard operational model we follow is when a service instance pool is
being resized, the lb pool in all caller envoys will be updated such that
they can no longer see the callee service instances that are being brought
down - hence no new requests will be sent to them. However, requests that
are already in flight will be serviced by the service instances that are
being shutdown.
Now, things brings up a question of how much grace time you are going to
provide to the instances when they are being scaled down (I guess you can
tweak this in k8s).
On Thu, May 18, 2017 at 5:54 AM Cosmin Ilie<EMAIL_ADDRESS>wrote:

Yes i think this will work, however by looking at the Envoy page there
might also be a scenario where some form of weighting would be needed. For
example when scaling down, you will want to not forward any new requests to
a particular instance and leave the current sessions to timeout or for the
people to log out. After that you can safely remove the instance from the
hash ring.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302357803, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qdwsxOpCehJLpDyDfdDmtaa_BvgCZks5r7BVYgaJpZM4NeAsF
.

--
~shriram

@costinm commented on Thu May 18 2017
This is probably a feature request for the mixer - it could provide some stickiness based on authenticated user or cookies, to support stronger stickiness. Ip hash works in many cases, but sometimes requests get routed via different IPs, and mobile devices tend to be behind big NATs that makes balancing harder.

@rshriram commented on Thu May 18 2017
We don't do ip hash. We hash based on headers (cookie is one header). And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy enforcement. The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing plane.
The best that the mixer can do here is validate the session cookies as a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache<EMAIL_ADDRESS>wrote:

This is probably a feature request for the mixer - it could provide some
stickiness based on authenticated user or cookies, to support stronger
stickiness. Ip hash works in many cases, but sometimes requests get routed
via different IPs, and mobile devices tend to be behind big NATs that makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302564280, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF
.

--
~shriram

@costinm commented on Fri May 19 2017
Well, routing is a form of policy :-), and it is usually coupled with
authentication.
We have a limited budget of roundtrips that can be made in the critical
path - in many
cases it is more efficient to make routing policy decision based on info
related/stored
in the auth, and avoid a second RT. For example some users may need to be
served from
specific regions, or be in different tiers (free, paying, etc).
While having clear layers and separation of concerns is good practice,
crossing the
layers is needed in some cases :-)
Of course, the other sides of routing and stickiness are caching locality
and load balancing, making it a very tricky problem. Simple stickiness
based on things like JSESSIONID
are not so complicated, but we need something generic and flexible.
On Thu, May 18, 2017 at 9:49 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We don't do ip hash. We hash based on headers (cookie is one header). And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy enforcement. The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing plane.
The best that the mixer can do here is validate the session cookies as a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache<EMAIL_ADDRESS>
wrote:

This is probably a feature request for the mixer - it could provide some
stickiness based on authenticated user or cookies, to support stronger
stickiness. Ip hash works in many cases, but sometimes requests get
routed
via different IPs, and mobile devices tend to be behind big NATs that
makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302564280,
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302607792, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFI6qIe1mu8xMfSDwLM46llM4TaXDQIks5r7R9wgaJpZM4NeAsF
.

@rshriram commented on Fri May 19 2017
We can certainly solve this problem in our current design.
@louiscryan @geeknoid - care to bring Costin up to sync on our conscious
design choices we made 6 months ago? Or do we revisit all of istio's design
philosophies in lieu of his proposal to start doing traffic management at
mixer ?
On Fri, May 19, 2017 at 9:32 AM Costin Manolache<EMAIL_ADDRESS>wrote:

Well, routing is a form of policy :-), and it is usually coupled with
authentication.
We have a limited budget of roundtrips that can be made in the critical
path - in many
cases it is more efficient to make routing policy decision based on info
related/stored
in the auth, and avoid a second RT. For example some users may need to be
served from
specific regions, or be in different tiers (free, paying, etc).
While having clear layers and separation of concerns is good practice,
crossing the
layers is needed in some cases :-)
Of course, the other sides of routing and stickiness are caching locality
and load balancing, making it a very tricky problem. Simple stickiness
based on things like JSESSIONID
are not so complicated, but we need something generic and flexible.
On Thu, May 18, 2017 at 9:49 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We don't do ip hash. We hash based on headers (cookie is one header). And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy enforcement.
The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing plane.
The best that the mixer can do here is validate the session cookies as a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

This is probably a feature request for the mixer - it could provide
some
stickiness based on authenticated user or cookies, to support stronger
stickiness. Ip hash works in many cases, but sometimes requests get
routed
via different IPs, and mobile devices tend to be behind big NATs that
makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302564280,
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302607792,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAFI6qIe1mu8xMfSDwLM46llM4TaXDQIks5r7R9wgaJpZM4NeAsF
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302703655, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qd8LJ31eoReL3Y4CnaxOzor9Q2TXeks5r7ZnwgaJpZM4NeAsF
.

--
~shriram

@geeknoid commented on Fri May 19 2017
I've been a closeted fan of doing all this work in Mixer for a while now,
but I didn't want to upset the apple cart as we marched towards Alpha.
Envoy calls Mixer's Check API for every incoming request. Mixer has all the
complex policy logic and programmability we need to make routing decisions.
Mixer can then return a series of attributes describing the routing
decision which the proxy will execute. I think the model would work
reasonably well with L7 traffic. For L4, I suppose Envoy would invoke Mixer
only at connection establishment.
I think this would have equivalent efficiency and would simplify the model
for the operator as all policy-related logic would be specified in the
Mixer's domain.
On Fri, May 19, 2017 at 8:05 AM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We can certainly solve this problem in our current design.
@louiscryan @geeknoid - care to bring Costin up to sync on our conscious
design choices we made 6 months ago? Or do we revisit all of istio's design
philosophies in lieu of his proposal to start doing traffic management at
mixer ?
On Fri, May 19, 2017 at 9:32 AM Costin Manolache<EMAIL_ADDRESS>
wrote:

Well, routing is a form of policy :-), and it is usually coupled with
authentication.
We have a limited budget of roundtrips that can be made in the critical
path - in many
cases it is more efficient to make routing policy decision based on info
related/stored
in the auth, and avoid a second RT. For example some users may need to be
served from
specific regions, or be in different tiers (free, paying, etc).
While having clear layers and separation of concerns is good practice,
crossing the
layers is needed in some cases :-)
Of course, the other sides of routing and stickiness are caching locality
and load balancing, making it a very tricky problem. Simple stickiness
based on things like JSESSIONID
are not so complicated, but we need something generic and flexible.
On Thu, May 18, 2017 at 9:49 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We don't do ip hash. We hash based on headers (cookie is one header).
And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy enforcement.
The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing
plane.
The best that the mixer can do here is validate the session cookies as
a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

This is probably a feature request for the mixer - it could provide
some
stickiness based on authenticated user or cookies, to support
stronger
stickiness. Ip hash works in many cases, but sometimes requests get
routed
via different IPs, and mobile devices tend to be behind big NATs that
makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#issuecomment-302564280
,
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302607792,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
AAFI6qIe1mu8xMfSDwLM46llM4TaXDQIks5r7R9wgaJpZM4NeAsF
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302703655,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AH0qd8LJ31eoReL3Y4CnaxOzor9Q2TXeks5r7ZnwgaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302727822, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVucHVsCluzw4vsR-q948x1AYgiyOkB3ks5r7a-ggaJpZM4NeAsF
.

@louiscryan commented on Fri May 19 2017
Whatever we decide to do with Mixer, Envoy will want to support these
scenarios directly to some degree of fidelity anyway. It should also be
possible to use Istio without using the Mixer for Check/Quota at which
point it can't play a role in routing.
I think the Mixer would be a good place to put highly customized routing
decisions that could not be simply expressed in Envoy config. The most I
think would make sense for the Mixer to do is to provide a label that the
routing rules could switch on, it couldn't (and definitely shouldn't)
attempt to identify backend instances as LB pool management is definitely
Envoy's concern.
For those last 9's of reliability we will want Envoy traffic routing to
survive Mixer failures, this may not be possible if the routing is highly
complicated but for many many cases this will not be true.
On Fri, May 19, 2017 at 8:15 AM, Martin Taillefer<EMAIL_ADDRESS>wrote:

I've been a closeted fan of doing all this work in Mixer for a while now,
but I didn't want to upset the apple cart as we marched towards Alpha.
Envoy calls Mixer's Check API for every incoming request. Mixer has all the
complex policy logic and programmability we need to make routing decisions.
Mixer can then return a series of attributes describing the routing
decision which the proxy will execute. I think the model would work
reasonably well with L7 traffic. For L4, I suppose Envoy would invoke Mixer
only at connection establishment.
I think this would have equivalent efficiency and would simplify the model
for the operator as all policy-related logic would be specified in the
Mixer's domain.
On Fri, May 19, 2017 at 8:05 AM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We can certainly solve this problem in our current design.
@louiscryan @geeknoid - care to bring Costin up to sync on our conscious
design choices we made 6 months ago? Or do we revisit all of istio's
design
philosophies in lieu of his proposal to start doing traffic management at
mixer ?
On Fri, May 19, 2017 at 9:32 AM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

Well, routing is a form of policy :-), and it is usually coupled with
authentication.
We have a limited budget of roundtrips that can be made in the critical
path - in many
cases it is more efficient to make routing policy decision based on
info
related/stored
in the auth, and avoid a second RT. For example some users may need to
be
served from
specific regions, or be in different tiers (free, paying, etc).
While having clear layers and separation of concerns is good practice,
crossing the
layers is needed in some cases :-)
Of course, the other sides of routing and stickiness are caching
locality
and load balancing, making it a very tricky problem. Simple stickiness
based on things like JSESSIONID
are not so complicated, but we need something generic and flexible.
On Thu, May 18, 2017 at 9:49 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We don't do ip hash. We hash based on headers (cookie is one header).
And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy
enforcement.
The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing
plane.
The best that the mixer can do here is validate the session cookies
as
a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

This is probably a feature request for the mixer - it could provide
some
stickiness based on authenticated user or cookies, to support
stronger
stickiness. Ip hash works in many cases, but sometimes requests get
routed
via different IPs, and mobile devices tend to be behind big NATs
that
makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#
issuecomment-302564280
,
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#issuecomment-302607792
,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
AAFI6qIe1mu8xMfSDwLM46llM4TaXDQIks5r7R9wgaJpZM4NeAsF
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302703655,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AH0qd8LJ31eoReL3Y4CnaxOzor9Q2TXeks5r7ZnwgaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302727822,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AVucHVsCluzw4vsR-
q948x1AYgiyOkB3ks5r7a-ggaJpZM4NeAsF>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302730785, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIoKPICHarO2c7kWvCnbBklzP-kx2YyWks5r7bIhgaJpZM4NeAsF
.

@costinm commented on Fri May 19 2017
Depending on configuration, "something" will need to pick which of the
tasks
in a cluster will get the request.
It can be envoy directly - by decoding a jsessionid cookie, it could be
mixer
returning an equivalent attribute, or the load balancer, or any other
plugin.
It can even be application code setting a cookie that envoy understands.
My only concern is to avoid multiple roundtrips in the request path. In
cases
where the route is decided based on user, the component that authenticates
and authorizes is a very good place to make (some) routing decision.
I'm not saying it should be only the mixer, or only a dedicated component -
there are many factors and requirements, the trick is to minimize the
overhead
and keep things flexible. I believe in most cases a cookie or explicit (and
cacheable) session ID will cover most requests, and that will be handled
by the proxy directly. TLS sessionID/PSK/ticket (or QUIC session ID)
could also be valuable in some cases.
On Fri, May 19, 2017 at 10:03 AM, Louis Ryan<EMAIL_ADDRESS>wrote:

Whatever we decide to do with Mixer, Envoy will want to support these
scenarios directly to some degree of fidelity anyway. It should also be
possible to use Istio without using the Mixer for Check/Quota at which
point it can't play a role in routing.
I think the Mixer would be a good place to put highly customized routing
decisions that could not be simply expressed in Envoy config. The most I
think would make sense for the Mixer to do is to provide a label that the
routing rules could switch on, it couldn't (and definitely shouldn't)
attempt to identify backend instances as LB pool management is definitely
Envoy's concern.
For those last 9's of reliability we will want Envoy traffic routing to
survive Mixer failures, this may not be possible if the routing is highly
complicated but for many many cases this will not be true.
On Fri, May 19, 2017 at 8:15 AM, Martin Taillefer <
<EMAIL_ADDRESS>wrote:

I've been a closeted fan of doing all this work in Mixer for a while now,
but I didn't want to upset the apple cart as we marched towards Alpha.
Envoy calls Mixer's Check API for every incoming request. Mixer has all
the
complex policy logic and programmability we need to make routing
decisions.
Mixer can then return a series of attributes describing the routing
decision which the proxy will execute. I think the model would work
reasonably well with L7 traffic. For L4, I suppose Envoy would invoke
Mixer
only at connection establishment.
I think this would have equivalent efficiency and would simplify the
model
for the operator as all policy-related logic would be specified in the
Mixer's domain.
On Fri, May 19, 2017 at 8:05 AM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We can certainly solve this problem in our current design.
@louiscryan @geeknoid - care to bring Costin up to sync on our
conscious
design choices we made 6 months ago? Or do we revisit all of istio's
design
philosophies in lieu of his proposal to start doing traffic management
at
mixer ?
On Fri, May 19, 2017 at 9:32 AM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

Well, routing is a form of policy :-), and it is usually coupled with
authentication.
We have a limited budget of roundtrips that can be made in the
critical
path - in many
cases it is more efficient to make routing policy decision based on
info
related/stored
in the auth, and avoid a second RT. For example some users may need
to
be
served from
specific regions, or be in different tiers (free, paying, etc).
While having clear layers and separation of concerns is good
practice,
crossing the
layers is needed in some cases :-)
Of course, the other sides of routing and stickiness are caching
locality
and load balancing, making it a very tricky problem. Simple
stickiness
based on things like JSESSIONID
are not so complicated, but we need something generic and flexible.
On Thu, May 18, 2017 at 9:49 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

We don't do ip hash. We hash based on headers (cookie is one
header).
And
Envoy supports hashing based on headers only (not ip hash).
As a general rule, Routing should not be mixed with policy
enforcement.
The
mixer should be strictly restricted to policy enforcement. Sticky
session/cookie based load balancing should be done in the routing
plane.
The best that the mixer can do here is validate the session cookies
as
a
form of authorization, but that needs to be worked out.
On Thu, May 18, 2017 at 7:00 PM Costin Manolache <
<EMAIL_ADDRESS>
wrote:

This is probably a feature request for the mixer - it could
provide
some
stickiness based on authenticated user or cookies, to support
stronger
stickiness. Ip hash works in many cases, but sometimes requests
get
routed
via different IPs, and mobile devices tend to be behind big NATs
that
makes
balancing harder.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#

issuecomment-302564280

,

or mute

the thread
<https://github.com/notifications/unsubscribe-
auth/AH0qdyABnKaA_yr0QchoTewK_Y5ZgTAyks5r7M15gaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#
issuecomment-302607792
,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
AAFI6qIe1mu8xMfSDwLM46llM4TaXDQIks5r7R9wgaJpZM4NeAsF
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/istio/manager/issues/769#issuecomment-302703655
,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AH0qd8LJ31eoReL3Y4CnaxOzor9Q2TXeks5r7ZnwgaJpZM4NeAsF>
.

--
~shriram
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302727822,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AVucHVsCluzw4vsR-
q948x1AYgiyOkB3ks5r7a-ggaJpZM4NeAsF>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302730785,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AIoKPICHarO2c7kWvCnbBklzP-kx2YyWks5r7bIhgaJpZM4NeAsF>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/manager/issues/769#issuecomment-302757784, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFI6tYab4chlYfOemtBkxEU_QwwLnVbks5r7ctQgaJpZM4NeAsF
.

@rshriram commented on Fri May 19 2017
Can you describe 3 real use cases where every "microservice" [not just the edge service in the business unit] on the request path needs to call out to the authorization component and decide where to route based on the user?

@rshriram commented on Thu Oct 12 2017
While some minimal form of session affinity support is landing in Envoy (https://github.com/envoyproxy/envoy/pull/1766), we need some more functionality, especially the ability of filters to inject http headers and then cause recomputation of routes. A few real and concrete scenarios to drive this use case:

ID based routing: This comes in handy when we have to route based on the identity encoded in the JWT tokens (it requires decoding the token, extracting and validating the identity and then using that identity e.g. user=jason for further routing). This will become especially handy in scenarios where applications use custom token formats (e.g., WebSphere LTPAToken2) - a mixer adapter is needed to decode the token, validate it, and then pass it back to Envoy, which in turn will do the routing based on these tokens.

API operation based routing. Mixer matches an incoming call against OpenAPI spec, injects a set of attributes (such as api.method) available within the proxy. We could potentially then do routing decisions based on these attributes (once again http headers or may be content that is not materialized as headers). [omitting caching details].

I think this is largely boiling down to dynamically derived attribute based routing, where the attributes need not be necessarily present in HTTP headers or the request.
cc @louiscryan @geeknoid

@geeknoid commented on Thu Oct 12 2017
An important consideration is the entropy of the data being sent to Mixer for processing. Highly variable data, such as per-request JWT tokens, will completely neutralize the proxy->Mixer cache, causing each incoming request to have a synchronous round-trip to Mixer.
To support this scenario, we're thinking that some authentication tasks must be done in proxy proper.

@costinm commented on Thu Oct 12 2017
JWT tokes expire in ~1 hour - usually acceptable for cache purpose.
Of course, for RSA/EC-signed tokens validation can be done in proxy proper

however for HMAC tokens it may
be safer to keep the secrets isolated (and not have proxy access or have to
integrate directly with various secret stores).

On Thu, Oct 12, 2017 at 12:37 PM, Martin Taillefer<EMAIL_ADDRESS>
wrote:

An important consideration is the entropy of the data being sent to Mixer
for processing. Highly variable data, such as per-request JWT tokens, will
completely neutralize the proxy->Mixer cache, causing each incoming request
to have a synchronous round-trip to Mixer.
To support this scenario, we're thinking that some authentication tasks
must be done in proxy proper.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/pilot/issues/769#issuecomment-336243420, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFI6jwPd0oB2cXjiIdC8ks7d3CZydayks5srmpygaJpZM4NeAsF
.

Not stale.


Change the designation of Jupyter Accessibility to a Subproject

This is a targeted PR that is the result of a vote; I would propose moving quickly into the voting phase.
Questions to answer ❓
Please answer the following questions along with your proposed change:
Background or context to help others understand the change.
The Jupyter Accessibility group discussed different options for whether to be a Working Group, Standing Committee, or a Subproject. In particular, Tania wrote an issue on this subject which led to some good discussion both during the governance calls and during the accessibility calls.
A brief summary of the change.
This PR changes the designation of Jupyter Accessibility from a Working Group to a Subproject instead.
What is the reason for this change?
The group held a vote and chose the option of changing their designation to a Jupyter Subproject: https://github.com/jupyter/accessibility/issues/81
Alternatives to making this change and other considerations.
cf. this write up mentioned above that considered alternatives
The process ❗
The process for changing the governance pages is as follows:

Open a pull request in draft state. This triggers a discussion and iteration phase for your proposed changes.
When you believe enough discussion has happened, move the pull request to an active state. This triggers a vote.
During the voting phase, no substantive changes may be made to the pull request.
The Steering Council will vote, and at the end of voting the pull request is merged or closed.

The discussion phase is meant to gather input and multiple perspectives from the community.
Make sure that the community has had an opportunity to weigh in on the change before calling a vote.
A good rule of thumb is to ask several steering council members if they believe that it is time for a vote, and to let at least one person review the pull request for structural quality and typos.
CC
@isabela-pf @trallard @fcollonval @ajbozarth @tonyfast @jupyter/steeringcouncil

Thanks for opening this.

👍🏼 to start voting phase

:+1: to start the voting phase too

+1 to move to active.

We have YES=9 and NO=0 and four weeks have elapsed, so this PR passes.


.Net is not a language

In the Currently supported/planned languages table, its marked as .Net being a supported language. .Net isn't a langage > C# is being mainly used in the templates and not F# for example which are both part of .net

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: da63649f-5dd6-83c7-8d42-46b4b1291e47
Version Independent ID: da63649f-5dd6-83c7-8d42-46b4b1291e47
Content: What is the Azure Developer CLI (preview)?
Content Source: articles/azure-developer-cli/overview.md
Service: azure-dev-cli
GitHub Login: @alexwolfmsft
Microsoft Alias: alexwolf

#please-close


feat: go-ipfs 0.11.0

Ref. https://github.com/ipfs/go-ipfs/issues/8343

[x] 0.11.0-rc1
[x] 0.11.0

Merging, so main branch can build release artifacts for the final manual tests before release on Monday.


Create gg.md

Learn Build status updates of commit 6cb6272:
:warning: Validation status: warnings

File
Status
Preview URL
Details

csidevdocs-public/gg.md
:warning:Warning
View
Details

csidevdocs-public/gg.md

Line 1, Column 1: [Warning: author-missing - See documentation] Missing required attribute: 'author'. Add the current author's GitHub ID.
Line 1, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 1, Column 1: [Warning: ms-author-missing - See documentation] Missing required attribute: 'ms.author'. Add the current author's Microsoft alias.
Line 1, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 1, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Learn Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Exclude_path in in_tail plugin does not exclude log file

Fluentd version: fluentd 1.2.6
OS: CentOS 7.4
Configuration
<source>
  @type tail
  path /xxx/log/**/*%Y%m%d.log
  exclude_path ["*feed*", "*Feed*", "*XxxFeed*", "*pricelogger*", "fix_om*2_JLQD*"]
  pos_file /var/log/td-agent/fluentd.log.pos
  tag ems.*
  <parse>
    @type multiline
    format multiline
    format_firstline /\d{8} \d{2}:\d{2}:\d{2}\.\d{9}/
    format1 /^(?<time>\d{8} \d{2}:\d{2}:\d{2}\.\d{9}) (?<level>-[a-zA-Z]-) (?<message>.*)/
  </parse>
</source>

Problem Statement:
I updated our configuration to exclude additional file paths *Feed* and *feed*, and fix_om*2_JLQD, but I still see results in elasticsearch where the files match the path XxxFeed
The files I do not expect to see are:
fix_XxxFeed_xxxx-taker_20181113.log
feed_kraken_trade_20181113.log
I've looked at #681 but that does not address my problem.

You need to specify entire path like /xxx/log/**/*feed*.

Thank you. I converted to using entire paths and the exclude path works as expected.

Adding one related comment here that while the path attribute allows references to ENV variables, exclude_path does not, which bit me this week


Allow custom headers

headers were being overwritten if they were part of the options passed in.
This change uses Object.assign on the inner headers object so headers are only overwritten if they have the same key.

Codecov Report

Merging #209 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #209   +/-   ##
=======================================
  Coverage   99.05%   99.06%
=======================================
  Files          14       14
  Lines         425      426    +1
=======================================
+ Hits          421      422    +1
  Misses          4        4

Impacted Files
Coverage Δ

lib/client.js
98.90% <100.00%> (+0.01%)
: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 7c33707...9321385. Read the comment docs.


Downgrade some dependencies (cookie, openssl) to fix build

Hi Hyper team,
Since master currently won't build due to the IO rewrite, I've downgraded a couple of Hyper's dependencies (namely Cookie, OpenSSL) to get it to build once more.
Obviously this is only a temporary solution, but hopefully it is helpful to some until Hyper can be properly updated.

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

Commit: de050aa3c7ba00865c0332833730325523e21518
Commits must be in the following format: %{type}(%{scope}): %{description}
Invalid type. Valid types are feat, fix, docs, style, refactor, perf, test, chore, revert

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

Commit: de050aa3c7ba00865c0332833730325523e21518
Commits must be in the following format: %{type}(%{scope}): %{description}
Invalid type. Valid types are feat, fix, docs, style, refactor, perf, test, chore, revert

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

There was several same kind of PR:s yesterday. The bottom line: an actual fix will be commited soon, before that, just edit your Cargo.lock privately.

Ah, cool, my mistake. Didn't think to check.


Remove split if first element is empty to create anon volume

Fixes https://github.com/containerd/nerdctl/issues/1378
Signed-off-by: Manu Gupta<EMAIL_ADDRESS>

Would you mind to add extra unit test?

Would you mind to add extra unit test?

Needs an integration test

This would require a while; I did not account for the exit code. I will fix it in a few days.

Ready for review.Ptal


unable to open database file on production

I am having issue accessing the database file on Linux production server. I know the problem is associated with permission given to apache user, however, nothing seems to work. it only works when I run application using sudo. Any ideas what might be the reason ?

Most probably the database file(sqlite in this case) is now owned by the user who also runs the apache server. In other words, the user does not have write permission on it.
When you run it as sudo, the sudoer user will have the write permission. So it will work.
You can give the write permission for your apache user but I suggest using mysql/postgresql or mongodb instead.


openverso/open5gs:2.6.1 images restarting

Hi,
After upgrading openverso/open5gs:2.6.1. most of containers keeps restarting all the time.
I suppose after upgrading to 2.6.1 (Release 17 open5gs) something changed and there is a problem in the images
As I suppose, the docker images versions of dockerhub are aligned to open5gs upgrades. After 2.6.1, Open5gs is in Rel-17, and as I see, the corresponding images with version >2.6.1 show problem.
Could you confirm if you have notice or something I could do?
Tested in ubuntu 22 with docker compose as provided in open5gs-and-ueransim folder, upgrading from 2.3.2 to 2.6.1.
Thanks !

open5gs > 2.6.0 sets tls enabled by default. We don't include tls certificates in our image, so if you don't disable tls in open5gs configuration files, the services don't start.
I updated the openverso/open5gs:2.6.3 dockerhub image to disable tls in its configuration files.
Try with this image version, It should fix the problem.

Hello Carlos,
I have test 2.6.3 and 2.6.4 and the restarting problem is solved. Thanks! Although keeps in a loop with some issue as you can see in the image, the containers keep active . Is it something important the messeges in the picture? They are warnings but just to know.

Thaks for the support!

Yes, they are important.
There are some configuration changes also in version 2.6.4, so please, use 2.6.3.

hello,
Unfortunatelly this problem appear in 2.6.3 too, so with this version the problem appear too.
:(

The problem was with the base image.
We have updated from debian bullseye to debian bookworm, but it seems to be a problem with libcurl or libidn.
We have reverted the 2.6.4 image to debian bullseye in the meanwhile.
Just try with version 2.6.4.
We have also updated the docs/open5gs-and-ueransim files to make it work.
Hope that helps.


Basic Line Data Component Implementation

Following up the design to separate the GUI from the data & logic, for the first prototype of the Charts, a basic Line Data Component should be implemented. For now, everything should be on the Line Data Component (i.e. the abstract class should be kept there for now)
The following should be done initially:

[x] LineData initialization
[x] LineDataSet adding to LineData (just one for now)
[x] Access method for Chart Components
[x] Adding entries via x & y arguments

Basic Line Data component done based on 1-to-N Chart to Data Component design

Basic Line Data component is a good start for future work.


As a volunteer, if I register as a volunteer set my user role to volunteer

This is only the start of this ticket.
Business Goal
The point here is that if someone signs up as a volunteer we should know. This is because as people start to try to take actions on a pipeline of volunteers we need to know not only when a volunteer finds a club but also when they do not. This is so co-ordinators and others can action and reach out to them.
There are a few possible variations of this.
Task Possibilities

Just have a URL modifier ?user=volunteer so that we can link from volunteer pages and webinars etc.
Redo the registration form using the event booking page.
Another option?

We went full loop here.
We already had that before, and the problem was parents were registering as whatever they would (sometimes "champion", sometimes "volunteer", and eventually "parent"). That doesn't solve the problem of a user being a mentor in a Dojo, and a champion in another.
Even if we set a flag to know that the user wants to be a volunteer, what's the goal behind? What are we doing with it?
My proposal here is rather to go through this loop-hole of "registering as a volunteer" would be to offer in the dashboard, post-registration, a potential flow to "volunteer at a Dojo". That's assuming that the user goes through registration first, which is I assume, what we're talking about here.

Updated description. I think it might make sense to go through the volunteer flows in detail. We have needs to basically standardise what we collect and this is a step in building fully coherent volunteer flows down the line.

Is this still valid ?

Nah close it. It might re-rise in a new form down the line but close this.


Support shenango threads in folly

Idea is to replace all occurrences of std::thread in folly with rt::Thread. A successful compilation and a demo would be the aim of this PR.

rt::Thread::Id is implemented completely.
rt::GetId can be called from the current thread to get the id.
Tested:

rt::Thread::HardwareConcurrency() works good too.


[#972 ] fix(tez): Add output mapOutputByteCounter metrics

What changes were proposed in this pull request?
(Please outline the changes and how this PR fixes the issue.)
Why are the changes needed?
Lack of this will affect the number of reduce tasks
Fix: #972
Does this PR introduce any user-facing change?
(Please list the user-facing changes introduced by your change, including

Change in user-facing APIs.
Addition or removal of property keys.)

No.
How was this patch tested?
(Please test your changes, and provide instructions on how to test it:

If you add a feature or fix a bug, add a test to cover your changes.
If you fix a flaky test, repeat it for many times to prove it works.)

Could you polish your pull request description? Could you fill the correct information instead of default information?

Codecov Report

Merging #1016 (d9a6113) into master (4b11370) will increase coverage by 1.13%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #1016      +/-   ##
============================================
+ Coverage     53.65%   54.78%   +1.13%
+ Complexity     2520     2519       -1
============================================
  Files           382      362      -20
  Lines         21647    19289    -2358
  Branches       1798     1798
============================================
- Hits          11614    10568    -1046
+ Misses         9328     8085    -1243
+ Partials        705      636      -69

Impacted Files
Coverage Δ

...ez/runtime/library/common/sort/impl/RssSorter.java
57.95% <ø> (ø)

.../runtime/library/common/sort/impl/RssUnSorter.java
63.63% <ø> (ø)

...library/common/sort/buffer/WriteBufferManager.java
86.85% <100.00%> (+0.12%)
:arrow_up:

... and 22 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

ok 👌
| |
bin_zhang_apply
|
|
@.***
|
---- Replied Message ----
| From | @.> |
| Date | 07/17/2023 22:33 |
| To | apache/incubator-uniffle @.> |
| Cc | bin41215 @.>,
Author @.> |
| Subject | Re: [apache/incubator-uniffle] [#972 ] fix(tez): Add output mapOutputByteCounter metrics (PR #1016) |
Could you polish your pull request description? Could you fill the correct information instead of default information?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@lifeSo @zhengchenyu Could you help review this pr?

I found only mapOutputByteCounter was added. Do you plan to add other counters?
I have no problem about the code. Can we add a unit test to compare the counter generated by RssSorter to the counter generated by DefaultSort?

LGTM +1

You should run the command to format the files
mvn spotless:apply -Pspark3 -Pspark2 -Ptez -Pmr -Phadoop2.8

Could you polish your pull request description? Could you fill the correct information instead of default information?

ok


Ability to play/pause when phone is locked

Hello,
On earlier versions, we were able to play/pause from the notification when the phone was locked, it was really convenient.
The play/pause button was located here:

Any way to bring back this feature?
Thanks!

I am experiencing this as well.
App version: 3.1.6 (via Play Store)
Device: Nexus 5X
Android: 6.0.1 MTC19U

Sorry about that! Fix coming soon.

Fixed in 3.1.7.

Thanks a lot Steven!


oparin-1.1 vmware wrong vm retired

Hi,
I have just installed oparin-1.1 with OVA image
VM Provisionning & Retirement works well from scratch with VMware Provider.
I have created a Self-service Catalog Item and generate a new VM instance.
But there is a problem with the retirement request
The ID used is the ServiceId instead of the VM Id !!!
Screenshot of the Service ID :

ID in log =><PHONE_NUMBER>007

I can't find where is my mistake ?
I've made the same workflow on Najdorf and it's ok
Any ideas ?
Thanks

Hi,
Has anyone else encountered the problem ?

@kbrock Can you take a look at this one?  I wonder if this is why we see report of VM retirements not working or getting "disconnected" elsewhere.

We are having the exact same issue. I tested retiring two different Services.
In both cases a different VM than the VM attached to the service was retired.

The service we have is a service with one or more vms attached to it. There are no nested service.
I ended up opening IBM support case TS012495830 for this issue. Log files for our environment is attached in that support case.
Let me know if you need more details from my end.

https://github.com/ManageIQ/manageiq-ui-classic/pull/8725 should fix this

Fixed by https://github.com/ManageIQ/manageiq-ui-classic/pull/8725.
I'll close this as fixed.  If the above PR doesn't resolve the issue, please comment and we can re-open it. Thank you for reporting this bug.

ugh, the PR hasn't been merged yet.  Sorry.

Hi,
Thank you for fixing the problem.
Is there a new version planned for oparin (oparin-1.2 ?)


Feature(shared-errors): added shared errors package

Description
Added shared errors package with error types that will be used across the platform
Type

[ ] Dependency upgrade
[ ] Bug fix
[x] New feature
[ ] Dev change

Please everyone here feel free to comment/add/remove error types or to suggest alternative implementations


Drop our GIF support and integrate a 3rd party solution

Hi @rs, @mythodeia ,
I think you both know our GIF support is pretty sucky (consumes a lot of memory #548 #538 and also blocks the main thread #933, doesn't work on disk retrieval #916). I've tried a few approaches, but none seems to fix it.
In #733 someone suggested we look at FLAnimatedImage a library developed by Flipboard. I also found YLGIFImage.
Now given those 2 libraries know their way with GIFs (low CPU and memory footprint), since they are already focused on GIF, making patches and maintaining their code, I strongly suggest we remove our GIF code and create a subspec that supports integration with one of them. Basically via CocoaPods, we will be referencing one of those 2 libraries.
Let me know if you agree with me so far.
Now deciding which one:

both work very well on the simulator, I still need to test on a few devices
FLAnimatedImage has the advantage of being maintained by a team which handles working with images a lot (Flipboard), releases often (yesterday was their last release). The big disadvantage is FLAnimatedImage is not an UIImage subclass, but a NSObject subclass, which could make it harder for us to integrate.
YLGIFImage is built by Yong Li, developer at Facebook, so he must also have a good experience with images. The lib was not updated in the past 6 months. The advantage is their YLGIFImage is a UIImage subclass.

If you agree with this, I can play with an integration. I think it's our best option.

When we will integrate a 3rd party solution for Gif? Thx!

I modified the methods in file "UIImage+GIF" to return a "YLGIFImage", and modified the method in file"SDWebImageCompat" to do nothing with 'gif' data.
It looks work well.

@bpoplauschi FLAnimatedImage has an active UIImage subclass branch...
check it out

Thanks @mythodeia, I will look at this again.

@bpoplauschi  i have the same problem here .. did you reach a solution?

No solution yet, I will look at the new FLAnimatedImage variant and take it from there.

Any progress on this?

the solution for https://github.com/liyong03/SDWebImage-YLGIFImage no longer works for current sdwebimage

I modify some SDWebImage's source code. And work with FLAnimatedImage very well.
Here is a demo project

I don't know if this is known but Brewer Herb gives a nice solution of using FLAnimatedImage with SDWebImage using swizzlling
https://gist.github.com/exherb/1257263e350831d6c205

@yuvalDeri  thx for the hint?! - but it actually does not animate the gif, it is loaded but does not run.
any idea how to start the animation?
using the following original sd method to load the image from web
sd_setImageWithURL:placeholderImage:options:SDWebImageCacheMemoryOnly completed:

@hjanuschka
I simply added those 2 files to my project and added a load method under the implementation part like this
@implementation SDImageCache (Swizzle)

(void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzle];
});
}
.....
@end

make sure you are calling
sd_setImageWithURL:placeholderImage:options: completed:
on a FLAnimatedImageView object and not an UIImageView.
It works for me, even the completion block holds a FLAnimatedImage instead of an UIImage when GIFs are involved.
good luck

@yuvalDeri - MANY THX - changing the type from uiimageview to flanimatedimageview did the trick, also nice with the +load() thx - someone should do a POD of this

Take a look at this -> https://gist.github.com/hilen/8ef4a810406051e8f0c1

By merging #1575 into the 4.x branch, I think we can close this thicket. Feel free to test it and let us know if it works.


It should be clear which file is for the 'use' and 'availability' when uploading new (HP) profiles

http://beta.moses.et-model.com/load_profiles/new
This was a database thingy -> fixed.


Update changelog for the upcoming 0.6.0 release

Everything listed under the 0.6.0 release milestone has been done (except this PR itself), so I figure it's time to release a new version. As usual, the April 27 date is just a placeholder; we should substitute in whatever we want to be the actual release date before merging this.
Anything else that should be added?

Can you add a paragraph in the README (under "Development") how to do releases now?

Can you add a paragraph in the README (under "Development") how to do releases now?

Sure thing. In another merge request, if that's okay?

I added that note in !33.

Thanks for the approval @coordt. I want to hold off on merging until @redtoad gets a chance to check #33, and then I'll merge that one, fix the date in this PR, merge this, and then make the release. (If that all sounds good)


Request is sent but the returns error saying canceled.

I am using twilio sms api and sending requests just fine on my Mac. But on ubuntu the request is sent and I receive the sms however the chttp always return an Err saying canceled : unknown error

Thanks for submitting a bug report! Since this is platform dependent, I'm guessing it has to do with a difference in version of libcurl being used under the hood. Could you send me what the output is of the following example program on both your Mac and Ubuntu machines? (Using the same version of chttp your project is using.)
fn main() {
    println!("version: {}", chttp::version());
}

That would be a big help! If it does turn out to be a difference between versions, I can try running against the exact version you are using in order to troubleshoot.
Upstream it is now possible to build a bundled curl always instead of linking to the system curl. I will add a crate feature to enable that and you can try it to see if it fixes the problem once I add it.

failing http version is chttp/0.4.2 libcurl/7.58.0 OpenSSL/1.0.2n zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 l ibrtmp/2.3
and the successful one is chttp/0.4.2 libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1

In addition, it would be a great help to me if you could include the trace logs from chttp when the error occurs. If you don't already have logging set up, you can do so with the env_logger crate and then running your program with the RUST_LOG environment variable set to chttp=trace. Be sure to remove any sensitive details (like auth headers, etc) from the log first!

@NikosEfthias I've just released version 0.4.3 which uses a bundled, tested version of libcurl by default instead of defaulting to whatever version of libcurl is available on the target system. This should workaround the issue until I can find the actual bug between chttp 0.4.2 and libcurl 7.58.0 interacting. Please give it a spin on your Ubuntu machine and let me know if it fixes the problem.

thanks im trying it now

I created a similar environment to yours using Docker, but couldn't reproduce the error. Here's the Dockerfile:
FROM ubuntu:bionic

RUN apt update && \
    apt install -y build-essential curl git libcurl4 libcurl4-openssl-dev libssl-dev pkg-config && \
    curl https://sh.rustup.rs -sSf | sh -s -- -y

ENV PATH="/root/.cargo/bin:${PATH}"

RUN git clone https://github.com/sagebind/chttp.git && \
    cd chttp && \
    git checkout 0.4.2 && \
    echo 'fn main(){println!("version: {}", chttp::version())}' > examples/version.rs && \
    cargo run --example version && \
    cargo run --example simple

This only verified that a simple GET request works using a similar combination of library versions. What kind of HTTP request are you making? The bug might be triggered by certain characteristics of your requests.
Based on the error message, I think what is happening is the agent thread is panicking and then dropping the request (the agent thread is a background thread managed by a Client instance that performs requests on your behalf). Canceled in this case means that the agent thread abandoned your request. Getting those trace logs might help a lot to identify why the agent thread might be panicking.

I had a chance to try on my Ubuntu machine today and I'm still getting cancelled unknown error on Ubuntu

I'm sorry to hear that. Since I haven't been able to reproduce yet, it could be one of two things:

Something unique in your environment or program that chttp doesn't handle well, or
Some characteristic in the requests you are making that triggers a bug in chttp.

To eliminate the first possibility, please run the following program on your Ubuntu machine and post the output here: https://github.com/sagebind/chttp-issue-30/tree/4e02703de29fe7b882db9a1705b90740b82dc8fd

I am trying to test it now. I am on the go for a week already and I dont have a stable connection always. For the last 40 minutes im trying to compile psl for instance :)

Yeah psl is a bit of a nuisance lately, I think a recent release made it worse. I created a separate issue for that here: https://github.com/sagebind/chttp/issues/31

docker run -ti --rm -v (pwd):/app -w /app rust cargo build --release && strip -s target/release/<mybin> this is how I build my code btw

Finaly I could run the program on my ubuntu machine  are the logs

the last line also says the error is cancelled and it should have never happened I guess this is what I am having

Yep, exactly right. This is the log line I was looking for:
[2019-06-13T21:15:36Z ERROR chttp::internal::request] request canceled by agent; this should never happen!

This does help me narrow down where the problem is occurring, I will continue to investigate.

Good news; I've managed to reproduce the error you are seeing! By building in the manner you described, then running inside a container configured to be similar to your environment, I also get a Canceled error. I should be able to find the bug now. I might even get it fixed this evening!

actually for now until its fixed I can just stop handling the response because I really only care about the request being sent at this point of my app and after the fix I can put the response handling back.

It looks like the crash doesn't happen in debug mode; for me anyway at least.

oh that's cool too

so until the fix I guess I can  deploy a debug build

I may have found the issue. I think it is a result of a misuse of debug_assert!, which does not run the statement at all when compiled with release optimizations. This would be fine, except that I made a recent mistake and included a critical piece of code inside the assert, which means it is never run in release mode. :man_facepalming: I sure feel foolish now!
In addition to publishing a fix for this ASAP, I will also start running example programs compiled in release mode as part of automated builds to ensure that this does not happen again.

This should now be fixed in version 0.4.4!

cool first thing i will be testing with the project we used earlier to find the bug. I really appreciate the work you put on this and you were friendly and nice from the beginning


Need option to export the audio files

Great stuff.  Will be good for vlog background music. How to export the audio files?

The audio is synthesized on the fly in the browser, and there is no native way to do this, neither through Tone.js nor the Web Audio API. I'm afraid you'll have to use external software like Audacity to manually record the audio as it is being played. Sorry.

Actually, you can use the Tone.js Recorder: https://tonejs.github.io/docs/14.7.39/Recorder


Configure tuns.sh to support custom domains

Is tuns.sh configured to support custom domains as described here? https://docs.ssi.sh/advanced#custom-domains
I may just be using it incorrectly:
# Verify DNS records exist
$ ssh-keygen -lf ~/.ssh/id_ed25519_homelab | awk '{print $2}'
SHA256:mVuPXXIQ97B5/aJu1GaXbbITZxMgTNeGc7sqN3+ENpo

$ dig +short TXT _sish.mac-test.macchaffee.com
"SHA256:mVuPXXIQ97B5/aJu1GaXbbITZxMgTNeGc7sqN3+ENpo"

$ dig +short CNAME mac-test.macchaffee.com
mac-test.tuns.sh.

# Start an HTTP server
$ python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

# In another terminal, create the tunnel
$ ssh -i ~/.ssh/id_ed25519_homelab -R test:80:localhost:8000 tuns.sh
Enter passphrase for key '/Users/mac/.ssh/id_ed25519_homelab':
Press Ctrl-C to close the session.

Starting SSH Forwarding service for http:80. Forwarded connections can be accessed via the following methods:
Service console can be accessed here: https://mac-test.tuns.sh/_sish/console?x-authorization=PInNajVX5Q8SAT2j3Wk2
HTTP: http://mac-test.tuns.sh
HTTPS: https://mac-test.tuns.sh

# Verify tunnel is working:
$ curl -i https://mac-test.tuns.sh
HTTP/2 200
content-type: text/html; charset=utf-8
date: Wed, 23 Oct 2024 01:31:25 GMT
server: SimpleHTTP/0.6 Python/3.12.5
content-length: 514
...

# But the custom domain doesn't respond
$ curl -vvv https://mac-test.macchaffee.com
* Host mac-test.macchaffee.com:443 was resolved.
* IPv6: 2603:c020:400a:d000:bd71:c59f:720c:484b
* IPv4: <IP_ADDRESS>
*   Trying [2603:c020:400a:d000:bd71:c59f:720c:484b]:443...
* Connected to mac-test.macchaffee.com (2603:c020:400a:d000:bd71:c59f:720c:484b) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error
* Closing connection
curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error

# Try regular HTTP
$ curl -i http://mac-test.macchaffee.com
HTTP/1.1 404 Not Found
Date: Wed, 23 Oct 2024 01:38:13 GMT
Content-Length: 0

Looks like the building blocks for supporting custom domains exist in the pico repo: https://github.com/picosh/pico/commit/f10bd2a175a5cb0e9d30b833270be876e29173ae which makes me think I'm doing something wrong. Any help is appreciated!

Hey @mac-chaffee
It should work. Are you requesting a forward for the domain? You have to explicitly request it in order to get requests forwarded

Ahh so you guys use --bind-hosts instead of --bind-any-host? I see, makes sense. I'll submit a request later, was just kicking the tires. Thanks!

@mac-chaffee sorry, I should've clarified. You don't have to request it with us, you just have to request it from the ssh cli:
For example, I have a subdomain called sish-test.pico.sh and I want it to be served by tuns.

Setup a CNAME record for sish-test.pico.sh to point to tuns.sh
Setup a TXT record for _sish.sish-test.pico.sh to be my ssh key fingerprint
Request a tunnel in tuns with that domain: ssh -R sish-test.pico.sh:80:httpbin.org:80 tuns.sh <- notice the full domain is the request. You might have to wait for the record to sufficiently propogate, but once it has and if everything has worked properly, the tuns output will have your domain printed there.

When you request the tunnel, the check for the dns record to match the connecting fingerprint will be done.
Let me know if you have any issues, also happy to chat it over in IRC.

Worked like a charm! Thanks!
$ ssh -i ~/.ssh/id_ed25519_homelab -R mac-test.macchaffee.com:80:localhost:8000 tuns.sh
Enter passphrase for key '/Users/mac/.ssh/id_ed25519_homelab':
Press Ctrl-C to close the session.

Starting SSH Forwarding service for http:80. Forwarded connections can be accessed via the following methods:
Service console can be accessed here: https://mac-test.macchaffee.com/_sish/console?x-authorization=DxGP83TlbQs5jGn2s3cR
HTTP: http://mac-test.macchaffee.com
HTTPS: https://mac-test.macchaffee.com

$ curl -i https://mac-test.macchaffee.com
HTTP/2 200
content-type: text/html; charset=utf-8
date: Wed, 23 Oct 2024 14:46:35 GMT
server: SimpleHTTP/0.6 Python/3.12.5
content-length: 514
...


fix(afs): Don't filter empty changes (allow for null set), closes #1184

Checklist

Issue number for this PR: #1184
Docs included?: n/a
Test units included?: yes
In a clean directory, npm install, npm run build, and npm test run successfully? yes

Description
Per #1184 AFS is filtering empty sets from valueChanges(), this has been fixed.

@davideast done.


Music Assistant not in Menu Bar

What version of Music Assistant has the issue?
2023.06.1
The problem
Music Assistant is not shown in the menu bar.
How to reproduce
It was fresh installed from HACS and was able to setup the integration. Also the players were found.
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2023.06.1
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Alternative

What menu bar are you referring to?

I mean the Home Assistant menu bar on the left side of the UI.Am 12.06.2023 um 13:06 schrieb OzGav @.***>:
What menu bar are you referring to?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Have you selected that option in the addon INFO page "SHOW IN SIDEBAR"?

 Thanks for the hint. Now it’s working!

I have the same issue - but I have the music assistant docker container running with HA is docker as well. I can connect and assign speakers and connect to music assistant via local port but it';s not showing in the HA sidebar. Obviously i don't have an addon INFO page but i did add SHOW IN SIDEBAR=true to the music assistant docker variables without any joy.

show in sidebar is only available for the add-on install.
if you're running HA+MA as container based install, you'll have to open the MA interface yourself manually

You can use an iframe and point to port 8095

Have you selected that option in the addon INFO page "SHOW IN SIDEBAR"?

where is this page?  i have the integartion added and is shows my devices but i cannot see an info page anywhere. i do no know how to access mass. running on hass


python310Packages.pymysensors: 0.23.0 -> 0.24.0

Description of changes
https://github.com/theolind/pymysensors/releases/tag/0.24.0

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 188063 run on x86_64-linux 1

1 package failed to build:

home-assistant-component-tests.mysensors

2 packages built:

python310Packages.pymysensors
python39Packages.pymysensors

Result of nixpkgs-review pr 188063 run on x86_64-linux 1

1 package failed to build:

home-assistant-component-tests.mysensors

2 packages built:

python310Packages.pymysensors
python39Packages.pymysensors


Update hopper-disassembler (new version + zap stanza)

Zap-delete Hopper's command line tool
Update to the latest version 3.9.16

Thank you for the contribution. It needed some fixes, so they were made in 80ab944c62e4f9673a396772f151407ada4c0248. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.


Failed to create pod after rollback

As described in https://github.com/helm/helm/issues/6036, Do the three steps to reproduce (copied from https://github.com/helm/helm/issues/6036) :
1)Install helm chart version 0.1.0 from attachment. This chart version doesn't have service account. Verify that pods are in running state.
2) Perform helm upgrade with chart version 0.1.4 from attachment. This chart version brings in service account "hello-world-sa". Verify that pods are in running state.
3) Perform a helm rollback to previous version.
The above three steps succeed.
After rollback, do
step 4) Delete one running pod, then it is found that new pod will not be created after the running pod is deleted.
Normally because the replicas is 2, a new pod should be created.
After check the replicaset.app as below:
kubectl -n test describe replicaset.app/hello-world-5d8d55497f
Name:           hello-world-5d8d55497f
...
Events:
Type     Reason        Age                  From                   Message

Warning  FailedCreate  74s (x17 over 115s)  replicaset-controller  Error creating: pods "hello-world-5d8d55497f-" is forbidden: error looking up service account test/hello-world-sa: serviceaccount "hello-world-sa" not found
The failure of pod creation is caused by the serviceAccount.
Check the deployment after rollback,
kubectl -n test get deployment  hello-world -o yaml
...
serviceAccount: hello-world-sa
serviceAccountName: hello-world-sa
...
The serviceACcount exists in the K8S resource depoyment hello-world, but it does not defined in the hello-world-0.1.0 helm tgz package.
Output of helm version:
version.BuildInfo{Version:"v3.7.1", GitCommit:"23c99f11754e1b4ac585e2f1d2d1be59a611a2d2", GitTreeState:"clean", GoVersion:"go1.16"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4", GitCommit:"49499222b0eb0349359881bea01d8d5bd78bf444", GitTreeState:"clean", BuildDate:"2021-12-14T12:50:25Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4", GitCommit:"49499222b0eb0349359881bea01d8d5bd78bf444", GitTreeState:"clean", BuildDate:"2021-12-14T12:41:40Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
cncf

@victorguosh https://github.com/kubernetes/kubernetes/issues/108208 please see.

@victorguosh kubernetes/kubernetes#108208 please see.

Thanks for your information. It is mostly the cause of this issue.


Environment variables

Hello, I'm looking at this to try to understand how to handle stack references and it's pretty clear except when we're dealing from references to Environment Variables.
I cloned the project and did the deploy following the order, but the lambdas from notes and users was not getting the correct environment values.
  environment:
    tableName:
      ${file(../database/serverless.yml):custom.tableName}

I ended up with two changes, on the stack I'am creating the dynamo, I added a new Output:
Outputs:
    TableName:
      Value:
        Ref:
          Table
      Export:
        Name: TableName

And when I need to reference the dynamo I can use:
environment:
    TABLE:
      'Fn::ImportValue': 'TableName'

Do you know why this behaviour has changed? Or I'm missing some declaration on the database definition? Thers is no tableName on the custom declaration there.
Thanks for the project, it's was really easy to follow and getting to understand better the stack references.

Ah thanks. I see what the issue is. I forgot to make the change to the repo. I had changed it in the chapter - https://serverless-stack.com/chapters/dynamodb-as-a-serverless-service.html
I just made an update now to add the reference to tableName - https://github.com/AnomalyInnovations/serverless-stack-demo-mono-api/commit/d2b6b9c067a13f9fa1e65e3965b8426e2bf9a6a8
Let me know if that makes sense.

Ah nice, thanks for the response! It's all connected now.


Remove Serval engine

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 69.62%. Comparing base (d666e69) to head (08efecd).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #219      +/-   ##
==========================================
+ Coverage   67.04%   69.62%   +2.57%
==========================================
  Files         455      374      -81
  Lines       35925    31292    -4633
  Branches     4762     4382     -380
==========================================
- Hits        24087    21786    -2301
+ Misses      10745     8488    -2257
+ Partials     1093     1018      -75

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[wit-component] Extend the WIT printer for use in syntax highlighting

Introduce Output trait as a visitor for collecting syntax tokens.
This trait enables syntax highlighting and supports advanced use cases, such as filtering tokens by package, interface, or function.

Thanks for this! Are you planning on integrating this externally into an IDE or similar perhaps?

Thanks for the quick review! I am building an HTML highlighter as part of a larger project - not just for displaying colors, but also for deeper integration, such as showing icons next to certain functions and filtering out parts of a WIT document.
This is also why some higher-level functions are marked as pub in the PR.
Here is how it looks now:


Not able to connect to SQL server without enabling SQL server browser service.

While it is able to connect to local database with "TCP\IP enabled and SQL server browser service" enabled it is not able to connect to DB server hosted in remote machine. Is there a way around to connect to DB server which doesn't has this service enabled?

You need to connect directly to the IP address instead of using an instance name.


Revert "Fix non-square profile pictures being squished"

Reverts Fallenbagel/jellyseerr#104. The changes were implemented upstream: https://github.com/sct/overseerr/pull/2782

@all-contributors please add @sambartik for code


make position label, add closed styling

fixes https://github.com/AugurProject/augur/issues/1287

This pull request introduces 3 alerts when merging f7e71fccaa1c4681ca37d08ff3de54f906a7e45d into 7a6e0a1093a46c5fbd0f174545df2e26daac8000 - view on LGTM.com
new alerts:

3 for Unused variable, import, function or class

Comment posted by LGTM.com


PR for v0.9.0 release

Fixed #49 .
This PR bumps dependencies, update comment and bump the version of the crate to v0.9.0.

This change is

@jonhoo Pinging as this PR has opened for a week and it is really trivial to merge in.

Sorry, time has gotten the better of me! I'd like to not bump the version number yet, since we still don't know that there won't be an rc4. Happy to do all the dependency bumps though :+1:

Also, why all the minor dependency bumps? That shouldn't be necessary. The major bumps (like io-lifetimes) make sense though.

Sorry, time has gotten the better of me! I'd like to not bump the version number yet, since we still don't know that there won't be an rc4.

OK, I have reverted the change, however I think we are pretty close to 0.9.0 release.

Also, why all the minor dependency bumps? That shouldn't be necessary. The major bumps (like io-lifetimes) make sense though.

I indeed got too aggressive with dependency bumping and they are now reverted.


ModuleNotFoundError: No module named 'nnunet.network_architecture.torch_nn'

I didn't find this on nnunet。
ModuleNotFoundError: No module named 'nnunet.network_architecture.torch_nn'

Thank you for your interest in our project. I am pleased to inform you that we have uploaded the necessary files, including torch_nn.py, torch_edge.py, and pos_embed.py, to network_architecture, as well as nnUNetTrainerV2_nextou_bti_synapse.py and other files to network_training.

I didn't find this on nnunet。 ModuleNotFoundError: No module named 'nnunet.network_architecture.torch_nn'
Thank you for your interest in our project. I am pleased to inform you that we have uploaded the necessary files, including torch_nn.py, torch_edge.py, and pos_embed.py, to network_architecture, as well as nnUNetTrainerV2_nextou_bti_synapse.py and other files to network_training.


Pls update it to Swift 3.0...

Would love it, if you could update it to Swift 3.0. I try it myself but I'am new in coding and I get many errors.
Wish you a nice day.

I realize this is pretty late, but I've just done this - version 0.2 is swift 3 compatible. Thanks for filing!


Run aws-nuke against testing-test account on a regular basis

User Story
As a Modernisation Platform Engineer
I want to run aws-nuke regularly against the testing-test account
So that lingering resources are regularly cleaned up
Value / Purpose
The testing-test account is used for the creation of short-lived resources during unit tests. However, when tests do not exit cleanly resources can be left behind which impact future test runs. We should clean the resources in this account on a regular basis.
Useful Contacts
No response
Additional Information
https://github.com/ministryofjustice/modernisation-platform-environments/actions/workflows/awsnuke.yml
Proposal / Unknowns
Hypothesis If we... [do a thing] Then... [this will happ]
Proposal A proposal that is something testable, don't worry whether it works or not, it's a place for ideas.
Unknowns Potential pitfalls that could cause the story to expand beyond its original scope. Ideally this section will remain blank.
Definition of Done

[ ] testing-test included in AWS Nuke job
[ ] Another team member has reviewed
[ ] Tests are green

Both Edd and I have tried to remove this account but have failed. Maybe a real nuke will do it

We do
https://github.com/ministryofjustice/modernisation-platform-environments/actions/runs/6840515258/job/18599869893
Nuke complete: 0 failed, 10 skipped, 59 finished.


Add Mute Indicator to Participant Views

Purpose

Implement: User can see who is muted
Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code
Join a call, make remote participant to mute/unmute and observe

Testing:
Sometime the portion of last character near mute is covered.

Thanks for checking!
Fixed:

Yes, I have tested with up to 5 remote participants.

tested


Complete/Update Documentation

Update documentation to look like university 4th years, (Report and Synopsys).

Updation Done!!


Optical eye buying sharing thread

Meter
CP2102 USB 2.0 to OPTICAL INTERFACE IRDA Near Infrared IR Magnetic Adapter Transparent Transmission Communication Cable for Electricity Gas Water Meter Reading Data
More info
Wanted to let you know that this sensor from AliExpress works and is easily to order (unlike the sensors I found on ebay.de).
https://www.aliexpress.com/item/1005003509520122.html?spm=a2g0o.order_list.0.0.8c821802V6UHMy

Thanks for sharing.
I've recently removed a link to a reader from the README.md as I didn't feel like maintaining that

I bought this one https://nl.aliexpress.com/item/1005004351799379.html

I can confirm that the north and south of the magnet does matter. If it is in the wrong direction you have to turn the magnet 180 degree. The place of the magnet has to be just above the screen.
Her a pictures and a new housing for the https://wiki.hal9k.dk/projects/kamstrup IR reader sensor:
https://www.thingiverse.com/thing:5179312

Just curious, when I look at the shape of the device in in ticket https://github.com/golles/ha-kamstrup_403/issues/38 then the clip provided in the readme, eg
https://www.aliexpress.com/item/1005003509520122.html
https://www.thingiverse.com/thing:5615493
The sensor looks like it isn't the same shape. Does it fit in the clip?
If not, how did you attach yours?
Appreciate any guidance!

In my case I did not attach the sensor (which is positioned at a slight angle). The sensor rests on two points so that it does not slip off.

@HAEdwin  Never noticed those little studs till now.
I think Ill grab a sensor try strap it on with velcro or rubber bands.
Thanks for the images and feedback!

Im trying to get some readings from my kamstrup 603 but it won’t work.
I made a small bracket which fits on the two small pins.

@HoekRoel: Don't you get any reading at all? Did you press the play buttun? You have to press it once to enable the IR leds.
Is the reader exactly above the IR leds?

@HoekRoel Does the bracket cause the focal point between the IR-TX and RX LEDs to change? In other words, is the head now further away from the meter? Have you tried to just place the head without the bracket the way I did (picture earlier in this thread)? Did you set the correct serial parameters?

@PrutzerNL & @HAEdwin
no readings at all..  Pressed all the buttons i could find.. and as far as i know it is exactly above the IR Leds..
The bracket i made is only a ring which fits tight around te sensor but still keeps te sensor flat against the meter.  tried a lot of positions with the sensor..
With the serial parameters you mean de /dev/,...... ?
Will check the inside of the sensor next.. see if something is wrong there..

With the serial parameters you mean de /dev/,...... ?

Yes, but read page 74 "heartbeat and status indication" you might have to activate the IR-circuit. I'm not sure, not owning one but reading the manuals can help you out hopefully.

page 74 of what document? I have the same problem with my Kamstrup 403 and the same Ali express optical eye. The usb port is configured, but no data.
I pressed the buttons. With the camera of my phone I see no IR light coming from the optical eye by the way

page 74 of what document? I have the same problem with my Kamstrup 403 and the same Ali express optical eye. The usb port is configured, but no data. I pressed the buttons. With the camera of my phone I see no IR light coming from the optical eye by the way

I bought a new optical eye and after that it works fine. I

The IR sensor I used at the MC66 doesn't work on the 603.
@HoekRoel
Which sensor did you use?

The IR sensor I used at the MC66 doesn't work on the 603.
@HoekRoel Which sensor did you use?

This one
https://a.aliexpress.com/_EuPQJap

Er staat bij "In De Buurt Van" maar daarmee wordt bedoeld "near infrared".

Installed the new sensor, with the same result. Noreads from the Kamstrup 603.
@HoekRoel
Did you changed anything specific in the golles software?

Installed the new sensor, with the same result. Noreads from the Kamstrup 603. @HoekRoel Did you changed anything specific in the golles software?

No. I didn’t change a thing. It just started working with the new sensor.

Ask Johannes, he claims it should work with the 603 https://github.com/golles/ha-kamstrup_403/issues/18


Add status.version to list of fields to ignore for update

Issue #, if available:
Description of changes:
Corresponding PR to mrajashree/cluster-api repo: https://github.com/mrajashree/cluster-api/pull/9
When KubeadmControlPlane was upgraded to v1beta1, the status.version field was added which was called out here: https://github.com/kubernetes-sigs/cluster-api/blob/main/controlplane/kubeadm/api/v1alpha3/conversion.go#L98
Because of this, with the Update function we are taking advantage of in our controller, the validation webhook for KubeadmControlPlane is failing saying that changes to this field is forbidden. By adding it to the list of paths to ignore, we can get past this error which is specific to this field.
When making the commit to upstream, either we go with this approach or edit the conversion logic somehow to be able to understand how to get the value of the version from the spec potentially when converting from v1alpha3 to v1beta1. For now though, we can go with this approach and figure out what upstream maintainers prefer as the approach.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/hold
Testing

/unhold


BUG!!!!!GPU MEMORY LEAK MAY EXIST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

CUDA OOM exception was raised in tier 90/374, and this 12GB 3080TI GPU is only used by myself. Therefore it's very possible that memory  leak exists.

I tune up the downsample option to 4, and it does not raise exception anymore, so I guess maybe the 90th picture is bigger than others, and it caused the OOM, MEMORY LEAK may not exist.


MESOS: Set the cpu+mem default limit in the SchedulerServer

The default was 0 for both limits such that no container without defined limits came up. Probably these two lines were lost during a rebase.

/cc @tsenart for internal review.

LGTM

@sttts ... worth a unit test to prevent future regressions?

@alex-mohr: added a test case.

LGTM was before last commit, removing LGTM [contrib/submit-queue: auto remove LGTM]

Thanks for the test!
[Sorry for submit-queue removal of LGTM.  Bug.  Re-applied LGTM and ok-to-merge.]

[Shippable reporting broken, but appears unrelated.  Re-running.]


fix override mbstring.internal_encoding

Test case:
mbstring.internal_encoding = UTF-8
mbstring.func_overload = 2 (or 4 or 7)

If i use @import
// main file contains:
@import "00-variables"; // in this file contains cyrillic text
@import "01-mixins";
@import "02-grid";

For clarity, the screenshots of what I found out during the long process of digging in the code.
Numbers indicate the anticipated order of outputting debug text.
Parse.php:

Output:

Thus, only the first (main) file is processed correctly encoded, and the other is encoded, the default on the server

@oyejorge  I'm sorry, but don't quite understand why Scrutinizer gives an error

Looks like the configuration had an invalid setting that was no longer tolerated. Fixed it, but Scrutinizer give's this:

The property $mb_internal_encoding was declared of type boolean, but
ini_get('mbstring.internal_encoding') is of type string. Maybe add a type cast?

@oyejorge I hope I did the right thing to repair. All the same, I have very little experience in programming :baby_symbol:

Thanks!


istio operator cannot delete iop

Bug description
[ ] Docs
[*] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
kubectl delete istiooperators.install.istio.io -n istio-system op

should delete all resource related to this iop.
Steps to reproduce the bug
But istio-operator hang on
Deleting IstioOperator
Reconciling IstioOperator
Deleting IstioOperator
Reconciling IstioOperator
Deleting IstioOperator
Reconciling IstioOperator
...

Change the istio-operator's log level, and see this logs:
2020-09-24T08:23:09.595464Z	info	Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \"istiod-1-7-2-5d6f6f65d7-2rr7m:8080\" is forbidden: User \"system:serviceaccount:istio-operator:istio-operator-1-7-2\" cannot get resource \"pods/proxy\" in API group \"\" in the namespace \"istio-system\"","reason":"Forbidden","details":{"name":"istiod-1-7-2-5d6f6f65d7-2rr7m:8080","kind":"pods"},"code":403}

So try to edit the clusterrole:
kubectl edit clusterrole -n istio-operator istio-operator-1-7-2

change the clusterrole:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - events
  - namespaces
  - pods
  - pods/proxy
  - persistentvolumeclaims
  - secrets
  - services
  - serviceaccounts
  verbs:
  - '*'

Then the istio operator works!
It seems like that the clusterrole generated miss  pods/proxy permission.
Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
istio 1.7.2 k8s v1.16.8.
How was Istio installed?
istio operator.
Environment where bug was observed (cloud vendor, OS, etc)
k8s v1.16.8.

Looks like this only happens with explicit revision.


Dataview inline annotations act like Pandoc citations

look at the first task - it only has one inline metadata key, which is green. the second task has two inline metadata keys, and one is blue, and the other is grey. is there anything you could do with this? just nice-to-have.

that's unfortunately not something I can change, since the underlying issue is that Obsidian recognizes the first are as bare link (which I repurpose to color pandoc citations) and the second as link (because you used the square brackets to times).
The only thing you could do is to simply disable the coloring of of Pandoc citations in the style settings, which would also stop the coloring of inline-dataview fields in square brackets.


[Bug] tiledbsoma_stats_dump() produces empty ouput

Describe the bug
tiledbsoma_stats_dump() produces empty ouput
To Reproduce
def test_stats(tmp_path, capsys: pytest.CaptureFixture[str]):
    """Make sure these exist, don't throw, and write correctly."""
    soma.tiledbsoma_stats_enable()
    soma.tiledbsoma_stats_reset()

    schema = pa.schema([("soma_joinid", pa.int64())])
    with soma.DataFrame.create(
        tmp_path.as_posix(),
        schema=schema,
        index_column_names=["soma_joinid"],
    ) as sidf:
        data = {
            "soma_joinid": [0],
        }
        sidf.write(pa.Table.from_pydict(data))

    with soma.DataFrame.open(tmp_path.as_posix()) as sidf:
        sidf.read().concat()

    **soma.tiledbsoma_stats_dump()**
    soma.tiledbsoma_stats_disable()
    stdout, stderr = capsys.readouterr()
    assert stdout != ""
    assert stderr == ""
    print(f"tiledbsoma_stats_dump() = {stdout}")

This code produces:
tiledbsoma_stats_dump() = libtiledb=2.15.2
[

]

Where as this code produces expected output:
   tmp = sys.stdout
   my_result = StringIO()
   sys.stdout = my_result
   **sidf._handle.context.tiledb_ctx.get_stats()**
   sys.stdout = tmp
   print(f"tiledb_ctx.get_stats() = {my_result.getvalue()}")

Output:
tiledbsoma_stats_dump() = None
tiledb_ctx.get_stats() = {
  "timers": {
    "Context.StorageManager.write_store_frag_meta.sum": 0.00225229,
    "Context.StorageManager.write_store_frag_meta.avg": 0.00225229,
...

Versions (please complete the following information):
Language and language version: Python 3.9
OS: MacOS
tiledbsoma.version        1.2.1.post11.dev179155028
TileDB-Py tiledb.version()    (0, 21, 1)
TileDB core version           2.15.0
libtiledbsoma version()       libtiledb=2.15.2
python version                3.9.16.final.0
OS version                    Darwin 22.4.0

@beroy please retry with a current tiledbsoma version (currently 1.2.4 is available via pip install tiledbsoma).
Using a current version, I get non-empty stats output (from the read): see for example
https://gist.github.com/johnkerl/eb72e61b697dc69c7f8f46ce717e8e5f

Also note that at this transitional point in time (see also #1240, which is an area of active development) we do creates and writes through tiledb-py whereas libtiledbsoma handles bulk reads but not all metadata reads etc.
This means that we get the read stats from the path tiledbsoma-py -> libtiledbsoma -> core, but the stats for the create and write from the path tiledbsoma-py -> tiledb-py -> core. In happiest dynamic-loader situations those two are the same copies of core, but, we found out some time ago that there are situations in which the two can be distinct. This is one of several reasons for #1240.

I checked one more time my setup and looks like I have the right version:
(venv-m1) brobatmili in ~/projects/TileDB-SOMA on main% pip list | grep tiledb
tiledb                   0.21.3
tiledbsoma               1.2.4

@beroy please try again tiledbsoma.show_package_versions() as in your original bug report.

For the record: we are 1-1'ing in Slack (quicker that way) and will update with information

Switching from
oma.tiledbsoma_stats_enable()
soma.tiledbsoma_stats_dump()

to
tiledb.stats_enable()
tiledb.stats_dump()

Resolved the issue for me.
Quoting @johnkerl:

soma.tiledbsoma_stats_dump()gets the tiledbsoma-py (Python) -> libtiledbsoma (C++) -> libtiledb/core (C++)
tiledb.stats_dump() gets the tiledbsoma-py (Python) -> tiledb-py (Python) -> libtiledb/core (C++)
Normally only a single copy of libtiledb gets loaded into memory by the dynamic loader, but, there are situations where there can be two (loooong saga -- I'm omitting details)
By querying both you get both

Closing this issue

Reminder work here is tracked on #1240
Another issue (for posterity):

@beroy was seeing 1.2.1 from his pytest
pip install -U tiledbsoma gave 1.2.4
He kept seeing 1.2.1 from his pytest

Issue we debugged down to:
$ which python
/Users/brobatmili/projects/venv-m1/bin/python

$ which pip
/Users/brobatmili/projects/venv-m1/bin/pip

$ which pytest
/opt/homebrew/bin/pytest

Solution: invoke python -m pytest in place of pytest when working within virtualenv


No component found for view with name "RNSVGRect" : latest version used, no peer dependency errors

I've searched and have found similar issues that have been closed in the recent past, but I cannot figure out why I'm getting this issue. Also, there seems to be similar ones, but I get this error with out any peer dependency errors.
When attempting to render the SVG by calling the class, the error gets thrown. Dismissing the error in my iOS simulator will show the SVG viewing area (a box with a red border) but not the filled Rectangle.
ERROR:
`No component found for view with name "RNSVGRect"
-[RCTUIManager createView:viewName:rootTag:props:]
RCTUIManager.m:1007
invoking_
-[NSInvocation invoke]
-[NSInvocation invokeWithTarget:]
-[RCTModuleMethod invokeWithBridge:module:arguments:]
facebook::react::RCTNativeModule::invokeInner(unsigned int, folly::dynamic const&&)
facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&)::$_0::operator()() const
invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&)
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_queue_serial_drain
_dispatch_queue_invoke
_dispatch_root_queue_drain
_dispatch_worker_thread3
_pthread_wqthread
start_wqthread`
Code to follow:
package.json
{ "name": "geEnglishApp", "version": "0.0.1", "private": true, "scripts": { "start": "node node_modules/react-native/local-cli/cli.js start", "test": "jest" }, "dependencies": { "react": "16.0.0-alpha.12", "react-native": "0.45.1" }, "devDependencies": { "babel-jest": "20.0.3", "babel-preset-react-native": "2.0.0", "jest": "20.0.4", "react-test-renderer": "16.0.0-alpha.12" }, "jest": { "preset": "react-native" } }
sample code with SVG put in for testing purposes. index.ios.js
`/**
Sample React Native App
https://github.com/facebook/react-native
@flow
*/
import React, { Component } from 'react';
import {
AppRegistry,
StyleSheet,
Text,
View
} from 'react-native';
import Svg,{
Circle,
Ellipse,
G,
LinearGradient,
RadialGradient,
Line,
Path,
Polygon,
Polyline,
Rect,
Symbol,
Use,
Defs,
Stop
} from 'react-native-svg';
export default class geEnglishApp extends Component {
render() {
return (
Welcome to React Native!
To get started, edit index.ios.js
Press Cmd+R to reload,{'\n'}
Cmd+D or shake for dev menu
);
}
}
class SvgExample extends Component {
render() {
return (
<Svg
width="200"
height="60"

); } }
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
welcome: {
fontSize: 20,
textAlign: 'center',
margin: 10,
},
instructions: {
textAlign: 'center',
color: '#333333',
marginBottom: 5,
},
});
AppRegistry.registerComponent('geEnglishApp', () => geEnglishApp);

This is related to Issue #279
I tried following the steps that elainen wrote down, however this did not solve the problem.
Then, I attempted to follow the steps Andregreen wrote. This worked halfway: I didn't get the error, but instead of a circle on a square that is provided in the example code, I got two squares that were the size of the viewing area.
Until this issue is fixed, I am reverting to PNGs for my projects.

For me this solves the problem #387 . Remove “libRNSVG-tvOS.a” in xcode and restart the project. Svg will work just fine.

I solved this problem by adding RNSVG.xcodeproj(from node_modules/react-native-svg/ios/) into my rn project.
Then it works on IOS.
I didn't meet any errors following the readme, including react-native link react-native-svg. But it seems that the link failed?
react-native 0.46.0
react-native-svg 5.3.0
react 16.0.0-alpha.12

Seems like a linking error. Instructions available in readme now.

The same problem can be solved by:

manually add the libRNSVG.a if linking not work.
remove the libRNSVG-tvOS.a
don't use react-native run-ios, use xcode's build and run instead.

version using:
react-native 0.52.0
react-native-svg 6.3.1


Spec: Describe security requirements of the JAX-RS endpoint generated by the Proxy participant.

When the methods annotated with @Complete or @Compensate are not defined as JAX-RS resources, the implementation (this is implementation specific as not all implementations will use REST communication between participant and coordinator) can provide JAX-RS endpoints by the Proxy participant which is generated automatically.
These endpoints needs to be protected by default in such a way that they can't be exploited by hackers. They should ideally only be called by the coordinator and not by any other party.

relates to #35. @rdebusscher since there is no interoperability requirement for 1.0 shouldn't this be left to individual implemetations? If the implemetation knows what endpoints it exposes and how it does that, it should be up to it to secure them and also provide means to call these secured endpoints when LRA is ended.

I saw https://github.com/eclipse/microprofile-lra/issues/130 before this one :) My comment there applies here too I think in that you could use networking and some HTTP security API to protect then endpoints?

FYI We did discuss this in a previous hangout and we decided that:

security is specifically not defined in the specification and that it is up to implementers to define the security elements of their approach

@rdebusscher so if we stay with that decision we should add a section to the specification which says that. Otherwise, let's continue the discussion here.

@mmusgrov ok for adding the text into the spec.

I will take this