Ambari website not rendering

Going to the Ambari website gives me this error in the browser once the cluster is running. The hadoop services appear to work otherwise however.
Replacing the certificate and restarting ambari does not help. This is on GCP.

Attackers might be trying to steal your information from ... (for example, passwords, messages, or credit cards). NET::ERR_CERT_INVALID
Subject: gateway
Issuer: gateway
Expires on: Mar 8, 2020
Current date: Mar 24, 2017
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIIDCzCCAfWgAwIBAgIQOpG4NhEKzcmo4x/Ep1GgBzALBgkqhkiG9w0BAQswEjEQ
MA4GA1UEChMHZ2F0ZXdheTAeFw0xNzAzMjQxNTU4MDBaFw0yMDAzMDgxNTU4MDBa
MBIxEDAOBgNVBAoTB2dhdGV3YXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDYZBN3A1wsR83zumuOaNK3HnEkz3Xg7ifMcBKwwS4DsIJ6rBB7OV/cfjRr
I1f/zpJs1ULG4poNyG3/Cfo57l67kNYBZhxGCCXjg/TCy1/oZLR24WwzRJ25pI0X
4B3vb8A90yREl0+9vZRfr7/XYw1f6zfc7VGSVY5XxGc13YxKh3ihe1VIbCFZUj4+
GsLGIvvmJJ+vMkk8JmeNQBkK7aQ9oL65Yd8BBmGs7B7T1jqwncoljtLDkR8xtUF5
KuImYx/uqmiw+6qUGKZIutTOUhFzHEUDTycWTbjOSoBi1nZED6UKpgHcs5KIuHZR
QNZTZVFpbRZI7LcRpYxNd8PHUj05AgMBAAGjYTBfMA4GA1UdDwEB/wQEAwIAoDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAgBgNV
HREEGTAXgglsb2NhbGhvc3SHBH8AAAGHBGibgcowCwYJKoZIhvcNAQELA4IBAQAb
JxH4xPFI+a0R6xMxGKBXrG5jiin0lNlyziH0g781kwg4NQ+O0ICnS8GlRH123D/8
Pin4kPp4/DjnviQL9tHveXEzkO2sB/XU2//SjAjmPx0fpBQK0WXrUipsVC3cCOBJ
tXFriJsx3/7F+Yhd8XrxasCpRfZ1g7RzDsot3j6Hoay1PYiwSbHvy9oG5591NWye
iIGjor3zXBc94cL5Rw92mWFODQLLOR0WwN7Fv7QMCxF1cKzW1GZNxHoYI5Lv+yYh
ZSrncGvZlilbINgkMQKbeTHYSPzLDOMjl6f6QTiCblwK/5nGYwBGYW5Vjm2PCJyn
XtJ9EcW+UyBX92Bon/4O
-----END CERTIFICATE-----

Hi @craftyc0der ,
By default we install a self signed cert for many reason. So It is ok if you get NET::ERR_CERT_INVALID. You have to add cert to the trusted certs. You mentioned you replaced the cert to an other one. What kind of cert? A self signed? Have Ambari nodes valid domain names, and valid cert for that domains?

The cloudbreak deployer cert is also self signed and I do not have issues with making that one work. It is something specifically wrong with the Ambari cert or configuration I believe. I would encourage you to do a vanilla cloudbreak deployment with the march 24th 2017 GCP image and see if you can get Ambari to work. I've tried in multiple browsers, including curl. They all say the certificate is badly formatted.
When I followed the instructions to include my own cert in Ambari, I could never get it be deployed correctly. The commands all claimed to work but my cert never was sent to my browser. This may be a second issue.

This is the rest of the error.
You cannot visit xxx.xxx.xxx.xxx right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

I just redeployed with port 8080 open. Ambari does work without SSL.

I created a cluster with the mentioned version of Cloudbreak. What i got NET::ERR_CERT_AUTHORITY_INVALID on Chrome, and the result below with curl.
curl -I https://<IP_ADDRESS>/ambari/ --insecure
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 27 Mar 2017 16:22:37 GMT
Content-Type: text/html
Content-Length: 2012
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Last-Modified: Tue, 29 Nov 2016 20:13:22 GMT
Accept-Ranges: bytes

I can repeat your curl and get the same response. I cannot get ANY browser to allow me to show the contents. How is the cert Ambari has different from the one that cloudbreak deployer is using which is trivial to turn off security warnings for?
Pretend you where wanting to try out Cloudbreak but the demo doesn't allow you to connect to Ambari with any browser you have. What would you do?

It worked for me out of the box, i don't have to replace any cert on any node. Cloudbreak generates cert for Cloudbreak and for Ambari server too. I don't know what did you mean under Ambari website gives me this and Replacing the certificate and restarting ambari does not help and NET::ERR_CERT_INVALID. That means before replacing you got the same NET::ERR_CERT_INVALID? How did you replace? Did you restart nginx proxy?

I have redeployed at least a dozen times (testing "recipes"). Since you can make it work "out of the box", lets ignore the cert replacement scenario and focus on the "out of box" experience. I have tried running the Ambari website from 3 different PCs (all Windows) and 10 different browsers with no luck. I get a different error than the normal "self-signed" certificate warning. Your error: NET::ERR_CERT_AUTHORITY_INVALID is different from mine: NET::ERR_CERT_INVALID in Chrome. All my computers say the certificate is malformed, not just self signed.
Have you tried from Windows?

Ambari HTTPS error. I cannot figure out how to get around this error.

Cloudbreak HTTPS error. This error is trivial to work around.

The problem appears to be with the not quite self signed certificate on the Ambari server. Look at the error:num=20 on the cert created for Ambari. This is different from the one cloudbreak deployer shows error:num=18. At least on Windows, I can confirm that error 18 means I can use it and error 20 means I cannot. Can you confirm these results in your example deployment? Thanks for your help.
Running the following command on the ambari server yields:
openssl s_client -connect localhost:443

CONNECTED(00000003)
depth=0 O = gateway
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = gateway
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
0 s:/O=gateway
i:/O=gateway

running the same command against my cloudbreak deployer server yields:

CONNECTED(00000003)
depth=0 O = local
verify error:num=18:self signed certificate
verify return:1
depth=0 O = local
verify return:1
Certificate chain
0 s:/O=local
i:/O=local

It appears the x509v3 Basic Constraint: CA must be asserted (true) is Key Usage is present now. See: https://github.com/openssl/openssl/issues/1418
See also: https://tools.ietf.org/html/rfc5280#section-<IP_ADDRESS>:

The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section <IP_ADDRESS>) MUST also be asserted.

The cert Ambari uses does not pass a verify test as shown below.
$ openssl verify -CApath /etc/certs/server.pem /etc/certs/server.pem

/etc/certs/server.pem: O = gateway
error 20 at 0 depth lookup:unable to get local issuer certificate

$ openssl x509 -in /etc/certs/server.pem -text -noout

X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE  <-------------*****************MUST BE TRUE NOW
X509v3 Subject Alternative Name:
DNS:localhost

For me Ambari cert also bad:
CONNECTED(00000003)
depth=0 /O=gateway
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=gateway
verify error:num=21:unable to verify the first certificate
verify return:1

On macos it works as well (Chrome, FF, Safari), but on windows (ie 11) not. Edge accepted Cloudbreak cert but not Ambari.
I mark issue as a bug, and hope someone would pick this up early.
Thanks for the report.

Which version of Cloudbreak do you use? 1.6.3 or 1.14? You can check it with cbd version command.

1.14
gs://sequenceiqimage/cloudbreak-deployer-1140-2017-03-24.tar.gz

This is also occurring for us, Cloudbreak 1.14.
Both Windows and Linux are able to connect to the cloudbreak deployer, however on Windows we are not able to connect to the Ambari servers, while Linux is able to.

Same issue for me from Windows/Chrome with the Cloudbreak Deployer ami-229c2f34 AMI. I have to enable the 8080 port in the AWS Security Group to bypass HTTPS.

@OlivierA I should have been more specific in my post.
You can also get around this by simply using Firefox on Windows, so you don't have to open up 8080


PC-42 Request Trait

https://user-images.githubusercontent.com/3768616/177438960-3e93fa33-b153-4724-b965-5b7479580b53.mp4

I think the pop up could do with some extra styling. That can come in another PR


RegExp.prototype.exec() and test() parameters are optional

TypeScript Version:
3.8.3
Search Terms:
RegExp
Code
import * as assert from 'assert';

let matches = /ab(c)/.exec('abc');
assert.ok(Array.isArray(matches));
assert.equal((matches as RegExpExecArray).length, 2);

matches = /ab(c)/.exec();
assert.equal(matches, null);

Expected behavior:
Compiles.
Actual behavior:
Doesn't compile due to an expected argument for exec in line 8. But the corresponding JavaScript code runs without error.
Playground Link:
http://www.typescriptlang.org/play/?ssl=8&ssc=29&pln=1&pc=1#code/JYWwDg9gTgLgBAKjgQwM4tagprOAzKCEOAcjW1hIG4BYAKHoBst4RkYBjACy3QF44AemQAjABQcAlIIB0WAB5YOYsiI4lJtOuRwwZEANZiAglCjIAnjOCpT5i2LaceqSZvo7YcgI4BXZIxijuzcvBhwAEpYAOYAovJg8Up2lpIyzAB20TBcADRwAEzuDHROofxCohLScorKxZ56WH4Bwc68+Rm+jIyaQA
Related Issues:
Did not find other bugs that looked similar.

It runs without errors but it's certainly a mistake.

While it works in JS, JS also has no problems with null, 123 and {a: 123} (doesn't throw an error), how implicit undefined is better?
Just use .exec('undefined') for same effect but at least it won be confusing when /und/.exec() != null and /und/.test() === true.

See https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

I proposed this because I had an issue when using an optional chain:
/abc/.exec(someObject.someOptionalSubObject?.someValue);
What TypeScript defines as "JS is improper about this" forces me to write
/abc/.exec((someObject.someOptionalSubObject?.someValue as string)).
I'm wondering if that's intended. I could live with it, but I think it's an aspect where TS feels more challenging.

Like @IllusionMH suggested, you might as well write /abc/.exec(someObject.someSubObject?.someValue ?? 'undefined'), which is probably not what you meant, but it's equivalent and more explicit.
That code is wrong and TypeScript is warning you about it. You're using casts to eliminate the warning instead of admitting and correcting the mistake :)
You probably mean something like someObject.someSubObject?.someValue != null ? /abc/.exec(someObject.someSubObject.someValue) : null

I guess you are right.


ASRDataset for download_mode parameters

when you need download data again.

pls refer to https://github.com/modelscope/modelscope/blob/master/docs/source/develop.md#1-code-style to format your code


feat(cli,linter): provide tsconfig path from the cli

closes #891

Current dependencies on/for this PR:

#2526  👈
main

This stack of pull requests is managed by Graphite.

Merge activity

Feb 27, 7:00 AM EST: @Boshen merged this pull request with Graphite.


CI setup to include Windows and wider Python versions.

At the moment, the CI workflow is only testing the code on Mac and Ubuntu under Python 3.9. We definitely want this to cover Windows and more recent versions of Python.

This can't by fixed until after #69 is approved and merged - removing fiona from the requirements and replacing it with the more Windows friendly shapely.
Also - trying 3.11-dev may be a step too far.


Methods to get distance to target and from home

It is useful to be able to perform actions based on distance to target or distance from home. It would also be useful to be able to get a callback when the distance from target/home is a certain value.
While the maths for determining distances is fairly straighforward, this is probably required often enough that providing an API makes sense.

Acutally, more generically would probably be good to be able to shove in any two Location objects and get the distance (maybe both as single number at ground level (ie x, y plane) and as an x, y, z)

More generally, there are a bunch of functions that could be imported from the ardupilot autotest [common.py] (https://github.com/diydrones/ardupilot/blob/master/Tools/autotest/common.py) file as they might be useful... I.e. get_distance(loc1, loc2) and the wait_* ones...

@jmacgithu yes, they look very useful. @mrpollo thoughts - best way to integrate?

#170 adds some documentation for the more useful of these, so they will be in the guide shortly. I propose we close this as sorted when those changes go live.

@mrpollo What do you think (see previous comment). Should we close this, or should we keep it open and plan integration of helper functions into the API?

we should implement

@mrpollo I agree.
My only concern is that most of the algorithms floating around (like those I documented) are only good within certain latitudes, and over certain distances. With the "documentation solution" you can just add a warning and people can try alternatives if they find errors.
If you provide a function then you need to make it far more reliable over larger distances/latitudes or provide some sort of "accuracy" feedback. This is particularly true if we start to rely on it - for example I can see we might want to provide our own "frames of reference code" and that would have to depend on the library for conversions.
Another thought - is there a good 3rd party library we could either use or recommend instead of rolling out our own solution.


closure Promise is incompatible with contextual type '_' --

PromiseKit version: 4

In the process of upgrading app to Swift 3, PromiseKit to 4, app fails to build with error "declared closure result 'Promise' (aka 'Promise<()>') is incompatible with contextual type '_'". The error occurs on the 8th line from the bottom ... line starts with "let observed":
    open func deleteDBIDs(_ dbids : [Int]) -> Promise<Void> {

       guard !dbids.isEmpty else { return Promise.init(value: ()) } // our work here is done

        return Promise<Void> { fulfill, reject in
            do {
                let dbidstr = "(" + (dbids.map { "\($0)" }.joined(separator: ",")) + ")"

                try _ = db.exec("DELETE FROM \(T.tableName()) WHERE ID IN \(dbidstr)")

                for dbid in dbids {
                    workingSet.removeValue(forKey: dbid)
                    index[dbid]?.state = .deleted
                }
                fulfill()
            } catch let err as NSError {
                reject(err)
            }
        }.then { _ -> Promise<Void> in
            let observed = dbids.map { (number : NSNumber) -> Promise<Void> in
                Promise { fulfill, reject in
                    self.notifyObservers(number)
                }
            }
            return when(fulfilled: observed)
        }
    }

Can't see an issue. Please follow our troubleshooting guide, it contains steps to figure out what Swift is finding troublesome.

Try:
}.then { () -> Promise<Void> in
    let observed = ...

Yes, that fixed it.


Get tests running on Windows/Mac for Flask

pytest-flask live server seems to have issues
See: https://github.com/Azure-Samples/azure-flask-postgres-flexible-aca/issues/7

I definitely think we can drop pytest-flask and just manage a local server similar to what we do for FastAPI

https://github.com/Azure-Samples/azure-search-openai-demo/blob/main/.github/workflows/python-test.yaml


Expose getDiagnosticsProducingTypeChecker to avoid duplicate type instantiations

Search Terms
diagnosticsProducingTypeChecker
TypeChecker
getTypeChecker
Suggestion
Expose getDiagnosticsProducingTypeChecker.
Use Cases
A custom compiler adding additional checks must currently call:
// program: typescript.Program
const originalDiagnostics = program.get*Diagnostics(sourceFile);
const typeChecker: typescript.TypeChecker = program.getTypeChecker();
/* Use `typeChecker` to check the source file for additional diagnostics. */

Internally, get*Diagnostics methods use getDiagnosticsProducingTypeChecker, so it is already "warmed" - types are already instantiated. The current implementation requires that a compiler pay the cost to instantiate types twice: once with a diagnosticsProducingTypeChecker, and once with a noDiagnosticsTypeChecker.
This would eliminate the redundant warm-up cost for instantiating types in the TypeChecker. This would be especially effective in code bases with deeply nested type definitions which may take noticeably longer to instantiate.
I do not fully understand the difference between the two TypeCheckers, so I cannot honestly comment on the drawbacks to exposing/using a diagnosticsProducingTypeChecker for custom checks (can someone please explain this, or point me towards documentation?). If it is unfeasible, perhaps there is a way to warm both checkers on the same run, to reduce the repeated type instantiations.
Examples
See Use Cases.
Checklist
My suggestion meets these guidelines:

[X] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. new expression-level syntax)

This comes up in http://tsetse.info/.  cc @alexeagle

Diagnostic producing checker is reserved for reporting errors since it needs to ensure that types were not materialized without checking. And hence usage of this checker for anything else is not advised.

@sheetalkamat can you go into more detail?
Is there any reason not to use this checker after semantic checking has been run?
Can you give a case where using this checker for custom checks would cause adverse effects?
Are the details of the diagnostic checker documented anywhere? Is there any reason that the initialization of the checker can't also initialize the non-diagnostic-producing checker?

@sheetalkamat @weswigham (or anyone really), what would happen if one were to reuse the diagnostic producing checker for other checks? In my own testing I haven't seen any effects (outside of 20-30% performance gains), so I'm still very interested in this.
It seems like the checker does checks when it instantiates types but, if you are not instantiating any new types (i.e. you've already checked your whole program) then it is fine to continue to use the checker to re-check those types. Am I mistaken? I'd really like to understand why two checkers exist.

AFAIK the only real reason there's a distinction is that. supposedly, if you're only using a noDiagnosticsProducingTypeChecker, you saved on doing some work that the diagnostics producing one would otherwise have done (in all fairness, I think at this point most of the things that we check produceDiagnostics for in checker.ts are not high cost in the grand scheme of things). TBQH, I think getTypeChecker should just return the diagnostics producing one if it has already been constructed to fetch diagnostics from. The issue there, though, becomes that then you don't know which checker you may have, and types from different checkers aren't comparable, which is a big problem - which leads to the constraint that the public function to produce a checker must always return the same checker, regardless of when it's called.
We've talked about this internally before, and that's mostly an issue in how the checker is currently structured - there are really two things the checker needs to do; construct and materialize types, and issue diagnostics when those types have errors. Today, the two are interspersed within the same codepaths, which makes it quite difficult to divorce one from the other; in an ideal setting, they'd probably be different walks of the type hierarchy.
Anyways - I think we should probably revisit this at some point; because repeating the same work (like checking the .lib.d.ts) does feel bad.

Is there a compelling reason not to expose it so that use cases that already produce the diagnosticsProducingTypeChecker can just reuse it instead of instantiating a new one? Is there some scenario where users can shoot themselves in the foot by misunderstanding this?

I've opened #28584 with a quick edit of what seems like a decent compromise - if it exists, using the same checker that was made for diagnostics, otherwise making the work-saving one.

Just wanted to mention that at Angular we were investigating the impact some extra diagnostics we run had on build times (https://github.com/angular/angular/issues/27426).
We arrived at the conclusion that most of the time spent in the extra diagnostics was solely due to calling the type checker. Checks that didn't use the type checker maxed out at 102ms while checks that used it maxed at 2012ms. So up to 20x longer.
Moving some stuff around in those rules (https://github.com/bazelbuild/rules_typescript/pull/359) gave us a 18% smaller build time for the compilation unit we were testing.
In our case we were using 5 extra checks, 3 of which used the type checker. I can imagine more involved setups having their build time further impacted.


fix: multi-hop testing feedback

Description
Fixes 2 issues:

completely inaccurate thorchain swapper time estimate (fixed by disabling it for thorchain)
incorrect explorer link for erc20 allowance approvals

Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk
Low risk.
Testing
Test both reported issues are respolved.
Engineering

Operations

Screenshots (if applicable)
Thorchain time estimate extremely off:

The following tx link should have gone to bnb explorer, not viewblock
https://viewblock.io/thorchain/tx/4aa0617186dc9117c0e15f351b1fa5a4b17da29eee48163824555cf4aa2a7106

Current dependencies on/for this PR:

develop

PR #5858

PR #5867

PR #5868   👈

This stack of pull requests is managed by Graphite.

We'll need to update src/features/defi/helpers/utils.test.ts.


triangulate return an empty result

I am using Mesh.triangulate method, but it return an empty result.
My test code is:
from vedo import *

mesh1 = Mesh('mesh1.stl')
mesh2 = Mesh('mesh2.stl').c('r').triangulate()

intersect = mesh1.intersectWith(mesh2)
intersectTri = intersect.clone().triangulate()
show(mesh1, mesh2, 'original data',  at=0, N=3)
show(intersect, 'intersection', at=1)
show(intersectTri, 'triangulate for intersection', at=2, interactive=True)

The used data is:
data.zip
The result is:

The middle figure is the intersection result, and I want to triangulate it. The right figure is the triangulate result, and it is empty.
The environment is:
vtk 9.1.0
vedo 2023.4.3

this happens because the intersections are made of disconnected segments:
[[0, 1], [2, 3], [4, 5], [6, 7], [8, 9], [10, 11], [12, 13], [14, 15], [16, 17], [18, 19], [15, 20], [17, 21], [22, 10], [23, 24], [25, 2], [3, 4], [26, 6], [7, 27], [28, 29], [30, 31], [32, 0], [33, 34], [35, 36], [37, 38], [39, 40], [41, 42], [43, 44], [45, 35], [36, 28], [46, 30], [31, 47], [48, 37], [49, 39], [50, 51], [42, 52], [44, 33], [53, 54], [55, 56], [57, 48], [58, 59], [60, 61], [62, 63], [64, 65], [66, 67], [68, 69], [70, 62], [63, 64], [71, 72], [67, 68], [69, 58], [73, 74], [61, 53], [75, 55], [56, 76], [77, 78], [79, 80], [81, 82], [83, 84], [85, 86], [87, 88], [89, 90], [91, 92], [93, 70], [21, 77], [94, 95], [80, 81], [96, 97], [98, 99], [86, 100], [88, 89], [90, 101], [92, 102]]

to join them manually you can use this small function:
from vedo import *

def manual_join(outline, tol=0.00001):
    pts = outline.points()
    lines = outline.lines()
    k = 0
    joinedpts = [pts[k]]
    for _ in range(len(pts)):
        pk = pts[k]
        for j, line in enumerate(lines):
            id0, id1 = line
            p0, p1 = pts[id0], pts[id1]
            if mag(p0 - pk) < tol:
                joinedpts.append(p1)
                k = id1
                lines.pop(j)
                break
            elif mag(p1 - pk) < tol:
                joinedpts.append(p0)
                k = id0
                lines.pop(j)
                break
    return Line(np.array(joinedpts, dtype=np.float32))

mesh1 = Mesh("mesh1.stl")
mesh2 = Mesh("mesh2.stl").c("red4").triangulate()

intersect = mesh1.intersect_with(mesh2).clean()
joinedline = manual_join(intersect.clone())
triangulated_msh = joinedline.triangulate()
triangulated_msh.c("orange5").bc("purple6").pickable(True)

show(mesh1, mesh2, "original data", at=0, N=3)
show(intersect, "intersection", at=1)
show(triangulated_msh, "triangulated", at=2, interactive=True)

this is infact an interesting enhancement and can be included in something like .join(segments=True).

Thanks for kindly reply. And I understand why the triangulate return an empty result.
But, the manual_join may be not a good solution when there is two intersection result. For example:
from vedo import *

points = []

pi = 3.1415926
for i in range(180):

    x = cos(i/180*pi)
    y = sin(i/180*pi)
    points.append([x, y, 0])

tube = Tube(points, r=0.1).alpha(0.4).triangulate()

def manual_join(outline, tol=0.00001):
    pts = outline.points()
    lines = outline.lines()
    k = 0
    joinedpts = [pts[k]]
    for _ in range(len(pts)):
        pk = pts[k]
        for j, line in enumerate(lines):
            id0, id1 = line
            p0, p1 = pts[id0], pts[id1]
            if mag(p0 - pk) < tol:
                joinedpts.append(p1)
                k = id1
                lines.pop(j)
                break
            elif mag(p1 - pk) < tol:
                joinedpts.append(p0)
                k = id0
                lines.pop(j)
                break
    return Line(np.array(joinedpts, dtype=np.float32))

intersect = tube.intersect_with_plane(origin=[0, 0.5, 0], normal=[0, 1, 0]).c('r')
joinedline = manual_join(intersect.clone())
show(tube, intersect, joinedline.triangulate(), N=3)

In this picture, the intersection result has two contour (the middle figure), however, the manual_join only return one contour (the right figure).
Is it possible to improve the Mesh.intersect_with result?

You can do that with changing the last 2 lines with
joinedlines = [manual_join(ts).triangulate() for ts in intersect.split()]
show(tube, intersect, merge(joinedlines), N=3)

..you should now be able to do
mslice = tube.slice(origin=[0,0.5,0], normal=[0,1,0])
show(tube, mslice, N=2)

See: https://vedo.embl.es/autodocs/content/vedo/vedo/mesh.html#Mesh.join_segments

Thanks~~~~


logo try 2

👷 Deploy Preview for johare-cv processing.

Name
Link

🔨 Latest commit
444ce488082267baabe07b6d57e722b5a616e0df

🔍 Latest deploy log
https://app.netlify.com/sites/johare-cv/deploys/65db99d6fcd5d8000833b0bd


http: add crossposting and channel following

Closes #545
This adds support for following news channels and crossposting messages.
Tested both the following and crossposting and they work fine and return the according types.

When this is merged, be sure to use the new title.


Fix links in glossary.md

The links don't seem to be working.
When I click on the letters, it doesn't send me to the right section on the page.
Please check the formatting of the links

For those looking for a hint check out this stack overflow post: https://stackoverflow.com/a/51226139


CloudSQL controller should skip update during creation

Description of your changes
Skip update if the creation is still ongoing. Also fixes:

Values of ForceSendFields as they have to match exact Go struct field names that you'd like to force send.
LateInitializeBool should not return nil in case the incoming value is false, it causes unnecessary updates. In fact, incoming value shouldn't be considered in the decision of whether the value should be assigned.

Fixes #121

Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[x] Updated any relevant documentation, examples, or release notes.
[x] Updated the dependencies in app.yaml to include any new role permissions.

Hrm, this appears to be failing on a GKE related test somehow. 🤔

@negz It's because of the the last commit that changes late-init function for booleans. I reverted the commit and will address that problem in another PR.


Remove cipher suite for Bottlerocket temporarily

Issue #, if available:
Description of changes:
We don't support the cipher changes for Bottlerocket yet.
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

/close


add daily runs on the HELICS 2.0 branch

Since we effectively have 2 develop branches right now HELICS_2_0 and develop, we should begin running the daily tests on the 2.0 branch as well as develop, until the 2.0 release at which time the 2.0 branch will become develop.

Specifically interested in the sanitizer runs, tsan and undefined behavior sanitizer


feat: add middle mouse button click to close tab

Description
Add the possibility to close tabs with mouse middle button click.
This feature was shared first by Sahilm416 - PR. But the code is like deprecated. This is a amazing feature that will improve UX of all of bruno's users!

Contribution Checklist:

[x] The pull request only addresses one issue or adds one feature.
[x] The pull request does not introduce any breaking changes
[x] I have added screenshots or gifs to help explain the change if applicable.
[x] I have read the contribution guidelines.
[x] Create an issue and link to the pull request.

Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.
Publishing to New Package Managers
Closes 485

I would really appreciate if we merge this PR! This is something small but significant to the UX of Bruno.

Merged!
Thank you @Gabrielcefetzada for taking care of this.


Bluetooth: Classic: Gap: add link mode policy (sniff mode/exit sniff)

sniff mode/exit snif mode/mode change handle code
Add bt_conn_enter_sniff_mode/bt_conn_exit_sniff_mode api control the sniff mode, handle BT_HCI_EVT_MODE_CHANGE event to notify the host that the mode has been changed and, link_mode_changed callback to notify application.

Do you actually have products that need this?


Add error data to messages in turnstone queue

Related Github tickets

a list of github issues that are relevant for this PR

Background
This is needed to change Pigeon behavior.  Currently, when a Pigeon encounters an error relaying a message, the pigeon just attests the message and then won't touch it again.  This means for a bad message, the majority of pigeons must try to relay it in order to achieve enough attestations.
With this new functionality, when an Pigeon encounters an error, it can send that error data back to Paloma.  That way, all other pigeons can attest to the error without having to attempt to relay it themselves.
Testing completed

[x] This was tested on a local private testnet
[x] Tests were added

Breaking changes

[x] I have checked my code for breaking changes
[x] If there are breaking changes, there is a supporting migration.

To reflect: We now get error telemetry attached to messages when pigeons relay and fail.

That is correct


Null-terminator asymmetry in trap message APIs

wasm_trap_message adds an extra null-terminator. Is this intended?
wasm_trap_new already requires buffer to be null-terminated.
https://github.com/bytecodealliance/wasmtime/blob/master/crates/c-api/src/lib.rs#L1026-L1048
pub unsafe extern "C" fn wasm_trap_message(trap: *const wasm_trap_t, out: *mut wasm_message_t) {
    let mut buffer = Vec::new();
    buffer.extend_from_slice((*trap).trap.borrow().message().as_bytes());
    buffer.reserve_exact(1);
    buffer.push(0); // extra null terminator
    (*out).set_buffer(buffer);
}

Normally I consume strings with the buffer size returned (dont care about the actual bytes). But I would need to trim extra chars (ie. null-terminator) if this is allowed to be appended. But annoying to manage in particular if a message/buffer at some point can get manipulated recursively.

I recently fixed wasm_trap_new to remove the null terminator from the string being stored internally since we didn't need it, so this should be putting it back on when giving the message back to C without a duplicate null.
Despite the fact that the byte length is given back with wasm_message_t, this comment in the C API proposal indicates that the message always needs a null terminator.

Ok, thanks. That would do it.
I do switch between the different releases but didnt look for new behvaior on this.

@rene-fonseca thanks for bringing this to our attention though! The C API is pretty important to us for enabling embedding from many different languages, so if there is anything you find that's not what you expect or is behaving badly, we'll try to get addressed.  Can this issue now be closed?

Closed - I can follow up if I there is anything left when testing on latest release.


Update cellxgene links to cziscience website

Update all the cellxgene links for the March 2020 Data Release to reference the visualizations hosted at cellxgene.cziscience.com.

March 2020 release has been abandoned.


chip_io gate-level netlist has incorrect signal connections

The incorrect signal connections related to issue #58 are fixed in the RTL but not in the GL

gl needs to be regenerated.  def view does not match either.


Relation uses bind_address, which can change

https://github.com/canonical/redis-operator/blob/master/src/charm.py#L165
This address can change if the pod is killed and respawned. I think a better solution would be to use either the Service IP, or the app name. The app name is valid DNS in k8s that have DNS running and the lookup moves with the pod.
There may be a more preferred juju method of doing this that I'm not aware of.
https://bugs.launchpad.net/juju/+bug/1911135 looks to be related.

We should avoid using the k8s DNS because that won't be available outside of k8s in the case where we're using cross-model relations, but we should definitely investigate/fix this.

Hey Tom and Tom :smiley: interesting, when writing this I was actually not sure what do to, that is why the code is a bit convoluted in there, falling back self.app.name, because I knew it was valid if bind_address was not available.
@mthaddon do you think just using app.name would be enough here or it is more complicated than that?

I think the charm should be looking at whether its IP has changed as part of hooks that might fire whenever this has happened. If it has changed, it should publish that change on the relation so relating charms can take appropriate action. We may need some help from the juju team to identify which hook(s) would be relevant here, but we've observed the following hooks running on a pod after a restart event that caused an IP change:
$ kubectl logs -n prod-events-k8s redis-broker-0 -c charm | grep ' ran ' | head -20
2023-06-02T04:09:46.486Z [container-agent] 2023-06-02 04:09:46 INFO juju.worker.uniter.operation runhook.go:159 ran "start" hook (via hook dispatching script: dispatch)
2023-06-02T04:09:59.610Z [container-agent] 2023-06-02 04:09:59 INFO juju.worker.uniter.operation runhook.go:159 ran "start" hook (via hook dispatching script: dispatch)
2023-06-02T04:10:15.313Z [container-agent] 2023-06-02 04:10:15 INFO juju.worker.uniter.operation runhook.go:159 ran "sentinel-pebble-ready" hook (via hook dispatching script: dispatch)
2023-06-02T04:10:50.723Z [container-agent] 2023-06-02 04:10:50 INFO juju.worker.uniter.operation runhook.go:159 ran "redis-pebble-ready" hook (via hook dispatching script: dispatch)
2023-06-02T04:11:22.162Z [container-agent] 2023-06-02 04:11:22 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:11:42.011Z [container-agent] 2023-06-02 04:11:41 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:12:37.407Z [container-agent] 2023-06-02 04:12:37 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:13:37.572Z [container-agent] 2023-06-02 04:13:37 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:14:31.409Z [container-agent] 2023-06-02 04:14:31 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:15:39.592Z [container-agent] 2023-06-02 04:15:39 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:15:55.376Z [container-agent] 2023-06-02 04:15:55 INFO juju.worker.uniter.operation runhook.go:159 ran "sentinel-pebble-ready" hook (via hook dispatching script: dispatch)
2023-06-02T04:16:53.755Z [container-agent] 2023-06-02 04:16:53 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:17:57.675Z [container-agent] 2023-06-02 04:17:57 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:18:58.588Z [container-agent] 2023-06-02 04:18:58 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:19:48.832Z [container-agent] 2023-06-02 04:19:48 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:20:50.449Z [container-agent] 2023-06-02 04:20:50 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:21:23.950Z [container-agent] 2023-06-02 04:21:23 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:22:23.503Z [container-agent] 2023-06-02 04:22:23 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:23:15.746Z [container-agent] 2023-06-02 04:23:15 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-06-02T04:24:18.254Z [container-agent] 2023-06-02 04:24:18 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)

Sounds like we'd either need to update the IP on the relation as part of the start hook or the redis-pebble-ready hook.


Rewrite and restyle ways to train page

Iterate the ways to train page to focus more on user considerations.
Maintain some structured data next to route names, but use something other than tables to represent the attributes of each avenue - to keep the focus on user circumstances rather than route names.
We may want to tidy up some elements of the markup.
Attempt one - placing the tags beneath the headings
Here the tags are placed right under the heading. The main drawback of this approach is policy think we should present structured data next to the official route name, i.e. School direct (fee-funded).

Attempt two
This time we reintroduce the policy-approved terms alongside the tags, whilst maintaining the user centred nature of the content. This is the blended approach we think policy are after.

A section covering one option
A section covering multiple options

Added some light dividing lines between the 'rows' of the definition list

Desktop
Mobile

@peteryates  we've got the classic external site tag appearing in a button again 😩

Also there should be space between those tags - which browser are you using? I thought even Safari supported gap now

Ah, this was me reviewing it on my DfE device on Edge...

Also there should be space between those tags - which browser are you using? I thought even Safari supported gap now

@peteryates Ah, this was me reviewing it on my DfE device on Edge...

I think we may need to lose the rounded corners on the tags as well. Usually, design patterns go with one or the other and our branding is straight/non-rounded

I think we may need to lose the rounded corners on the tags as well. Usually, design patterns go with one or the other and our branding is straight/non-rounded )border-radius: 0;
I don't think there is any need to bold these items either, they are prominent enough with the background colours. font-weight: normal

won't this make them look too much like buttons tho @gazcarr ?

I think we may need to lose the rounded corners on the tags as well. Usually, design patterns go with one or the other and our branding is straight/non-rounded )border-radius: 0;
I don't think there is any need to bold these items either, they are prominent enough with the background colours. font-weight: normal

won't this make them look too much like buttons tho @gazcarr ?

I would say that is subjective, I always go back to UR in these scenarios - is a user less likely to try clicking on this because of its corners, probably not... therefore go with the rest of the design. I am happy to be challenged and ultimately its only something like hotjar testing that might tell us over time.
Its also one of the reasons I advised reduce the font-weight, all of our current buttons are using bold .
Happy to be challenged on any of these thoughts though.

I think we may need to lose the rounded corners on the tags as well. Usually, design patterns go with one or the other and our branding is straight/non-rounded )border-radius: 0;
I don't think there is any need to bold these items either, they are prominent enough with the background colours. font-weight: normal

won't this make them look too much like buttons tho @gazcarr ?

I would say that is subjective, I always go back to UR in these scenarios - is a user less likely to try clicking on this because of its corners, probably not... therefore go with the rest of the design. I am happy to be challenged and ultimately its only something like hotjar testing that might tell us over time.
Its also one of the reasons I advised reduce the font-weight, all of our current buttons are using bold .
Happy to be challenged on any of these thoughts though.

your call @gazcarr - feel free to agree on a style with @peteryates


CannotDeleteOrUpdateEnabledEntitlement: Permission (scope or role) cannot be deleted or updated unless disabled first

I followed the manual setup to register both client and server apps. Getting the following error while deploying the app.
Could you please elaborate a little more on the process of enabling authentication and assigning roles and groups please?

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

azd up

Any log messages given by the failure

Checking if authentication should be setup...
Loading azd .env file from current environment...
AZURE_USE_AUTHENTICATION is set, proceeding with authentication setup...
Creating Python virtual environment "scripts/.venv"...
Installing dependencies from "requirements.txt" into virtual environment (in quiet mode)...
Setting up authentication...
Checking if application xxxxx exists
Application already exists, not creating new one
Setting up server application permissions...
Traceback (most recent call last):
File "/Users/xxx/codes/azure-search-openai-demo/./scripts/auth_init.py", line 210, in
asyncio.run(main())
File "/Users/xxx/miniconda3/envs/azure-search-openai-demo/lib/python3.11/asyncio/runners.py", line 190, in run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/Users/xxx/miniconda3/envs/azure-search-openai-demo/lib/python3.11/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/xxx/miniconda3/envs/azure-search-openai-demo/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/Users/xxx/codes/azure-search-openai-demo/./scripts/auth_init.py", line 193, in main
await update_application(auth_headers, object_id=server_object_id, app_payload=server_app_permission_payload)
File "/Users/xxx/codes/azure-search-openai-demo/scripts/auth_common.py", line 32, in update_application
raise Exception(response_json)
Exception: {'error': {'code': 'CannotDeleteOrUpdateEnabledEntitlement', 'message': 'Permission (scope or role) cannot be deleted or updated unless disabled first.', 'innerError': {'date': '2024-05-08T12:47:29', 'request-id': 'xxx', 'client-request-id': 'xxx'}}}
Expected/desired behavior

OS and Version?

macOS

azd version?

run azd version and copy paste here.

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

Hello, same issue here. @amirj did you make some progress ?

@amirj It works after changing access_user scope state parameter to "Disabled" in Entra ID server App

Yes, you just need to disable the scope via azure portal first.On 13 Jun 2024, at 16:30, tlievre @.***> wrote:
@amirj It works after changing access_user scope state parameter to "Disabled" in Entra ID server App
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

i'm also getting the above issue


[TECHDEBT] Tackle TODOs in shared/modules Issue #232

Description

[ ] Tackle / recategorize all non-blocked TODOs in shared/modules

Techdebt week emphasizes code health. Particularly, removing all placeholder and hacky code.
The past few months, shared/modules have built up quite a few TODOs.
The PR should remove all non-blocked TODOs

Reduce cognitive load
Increase code health

Issue
Fixes #232
Type of change
Please mark the relevant option(s):

[ ] New feature, functionality or library
[ ] Bug fix
[x] Code health or cleanup
[ ] Major breaking change
[ ] Documentation
[ ] Other

List of changes

Deprecated persMod.ResetContext() for -> persRWContext.ResetContext() for more appropriate encapsulation
Added ticks to CHANGELOG.md
Removed reference to Utility Mod's BigIntToString() and used internal BigIntToString()
Used proper TODO/INVESTIGATE/DISCUSS convention across package
Moved TxIndexer Package to Utility to properly encapsulate

Testing

[ ] make develop_test
[ ] LocalNet w/ all of the steps outlined in the README

Required Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have tested my changes using the available tooling
[x] I have updated the corresponding CHANGELOG

If Applicable Checklist

[x] I have updated the corresponding README(s); local and/or global
[x] I have added tests that prove my fix is effective or that my feature works

Changes LGTM but I'd like to get #282 in first since it might catch unit test failures that may or may not have been introduced.

@Olshansk all tests pass for me after merge with main


Mono/Android - Networking does not work

Godot version:
3.2 Beta 2 (Mono)
OS/device including version:
Android 10, Build QP1A.191105.003
Google Pixel 3a
Issue description:
Networking does not work on Android... Prints errors
Code:
NetworkedMultiplayerENet server = new NetworkedMultiplayerENet();
server.CreateServer(8200);
GetTree().NetworkPeer = server;
RpcId(1, "Test"); // There is a function in this class named Test that prints "Success"

Errors:
11-23 19:40:27.267  6159  6243 E godot   : **ERROR**: Condition ' _sock == -1 ' is true. returned: FAILED
11-23 19:40:27.267  6159  6243 E godot   :    At: drivers/unix/net_socket_posix.cpp:328:open() - Condition ' _sock == -1 ' is true. returned: FAILED
11-23 19:40:27.267  6159  6243 E godot   : **ERROR**: Condition ' !is_open() ' is true. returned: ERR_UNCONFIGURED
11-23 19:40:27.267  6159  6243 E godot   :    At: drivers/unix/net_socket_posix.cpp:382:bind() - Condition ' !is_open() ' is true. returned: ERR_UNCONFIGURED
11-23 19:40:27.268  6159  6243 E godot   : **ERROR**: Condition ' !host ' is true. returned: ERR_CANT_CREATE
11-23 19:40:27.268  6159  6243 E godot   :    At: modules/enet/networked_multiplayer_enet.cpp:107:create_server() - Condition ' !host ' is true. returned: ERR_CANT_CREATE
11-23 19:40:27.269  6159  6243 E godot   : **ERROR**: Supplied NetworkedNetworkPeer must be connecting or connected.
11-23 19:40:27.270  6159  6243 E godot   :    At: core/io/multiplayer_api.cpp:153:set_network_peer() - Condition ' p_peer.is_valid() && p_peer->get_connection_status() == NetworkedMultiplayerPeer::CONNECTION_DISCONNECTED ' is true.
11-23 19:40:27.270  6159  6243 E godot   : **ERROR**: Trying to call an RPC via a network peer which is not connected.
11-23 19:40:27.270  6159  6243 E godot   :    At: core/io/multiplayer_api.cpp:637:rpcp() - Condition ' network_peer->get_connection_status() != NetworkedMultiplayerPeer::CONNECTION_CONNECTED ' is true.

Steps to reproduce:

Place the code in a project
Run on Android

Minimal reproduction project:
Test.zip
Related to #33851
Seperate issue because this is a Godot class that is not working, the other has a DLLNotFoundException

Does the equivalent GDScript code work?

Thank you for the response, the bug still occurs in GDScript and therefore I should edit my issue to reflect that.

Wild guess, could it be permissions? Have you exported with permissions to do networking? (I only say this because it is a common gotcha on Android)

@lawnjelly Thanks! This was the problem (Missing "Internet" permission)
Is there a discussion issue about preventing this in the future? I think there should be a warning when exporting to Android if any classes being used may require a permission not given

@nathanwfranke add control mechanism to check which permissions need to be exported can maybe too complicated. Because there are so many code in mobile devices side and there can be so many code in godot side(I refer mobile and godot side because this check could be for 2 sides.)But for this case internet permission can be added default. For a long time google do not ask permission request for Internet.


Config.annotationTemplate option

Is your feature related to a specific framework or general for this extension
General (I believe).
Is your feature request related to a problem? Please describe.
No, It is functionality
Describe the solution you'd like
I would like to have the ability to not just provide a prefix or delimiter for the annotation, but to be able to control how the entire annotation is rendered.
Current Annotation

Additional context
using i18n-ally with ngx-translate inside a nx-workspace mono-repo

Okey dokey


Update documenter to v1

Looking good to me with only the issue of the relaxed link checking, for which an issue will be created.


Correct token calculation for streaming in case of using functions

Currently we don't calculate tokens for functions and tools

Consider enabling stream_options.include_usage=True
Keep in mind that to this day we don't how to count tokens for tools/functions presicely

Just in case: there is an unofficial function tokenizer, which assumes that OpenAI converts functions to TypeScript definitions: https://github.com/rubenselander/openai-function-tokens

https://github.com/epam/ai-dial-adapter-openai/pull/170 estimates token count of function by tokenizing tools config serialized to a string. It's obviously not an exact match to the OpenAI tokenization, and it may overestimate as well as underestimate the token count, but it's still better than returning 0 completion tokens on a function call.
Use fix caution. The recommended way is still using stream_options.include_usage=True that provides the precise token count coming from Azure OpenAI.


Connecting via gateway with two-factor auth works only some times

The gateway I connect to is setup to send a challenge to my phone for 2FA (two factor authentication) after the credentials (user name and password) are validated. I assume the rdp client has no knowledge about it and just waits for the gateway to reply with the authentication result.
The weird thing is that more often than not, when trying to establish a connection, I don't get the phone challenge, so I need to kill the client and try to connect again, until one of the tries will get me a challenge on the phone.
I noticed I get different traces on the client when the gateway sends me a challenge vs. when it doesn't.
When no challenge is sent, this is the trace the client logs:
[22:34:23:818] [11344:11345] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[22:34:23:818] [11344:11345] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[22:34:23:818] [11344:11345] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[22:34:23:818] [11344:11345] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[22:34:23:818] [11344:11345] [DEBUG][com.freerdp.channels.drdynvc.client] - VirtualChannelEntryEx
[22:34:23:818] [11344:11345] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[22:34:23:820] [11344:11345] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[22:34:23:008] [11344:11345] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:34:23:008] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:34:23:027] [11344:11345] [DEBUG][com.freerdp.core.gateway.rdg] - Out Channel authorization required
[22:34:23:027] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:34:23:328] [11344:11345] [DEBUG][com.freerdp.core.gateway.rdg] - Out Channel authorization complete
[22:34:23:608] [11344:11345] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:34:23:608] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:34:23:677] [11344:11345] [DEBUG][com.freerdp.core.gateway.rdg] - In Channel authorization required
[22:34:23:677] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:34:24:820] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_INITIAL
[22:34:24:025] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_CONNECTED
[22:34:24:025] [11344:11345] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:34:24:025] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:34:24:025] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_SECURITY
[22:34:24:134] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_CONNECTED
[22:34:24:134] [11344:11345] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:34:24:134] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:34:24:134] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_SECURITY
[22:34:24:135] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:34:24:135] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_NEGOTIATED
[22:34:24:135] [11344:11345] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/B1 RTS PDU
[22:34:24:135] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_OPENED
[22:34:24:148] [11344:11345] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:34:24:148] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_NEGOTIATED
[22:34:24:148] [11344:11345] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/A1 RTS PDU
[22:34:24:148] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_OPENED
[22:34:24:149] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_OUT_CHANNEL_WAIT
[22:34:24:232] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_A3W
[22:34:24:233] [11344:11345] [DEBUG][com.freerdp.core.gateway.rts] - Receiving CONN/A3 RTS PDU: ConnectionTimeout: 120000
[22:34:24:233] [11344:11345] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_C2

It will say there for 2 minutes and fail due to time out.
Now, below is the trace I get when I do get a challenge on the phone:
[22:33:46:380] [11327:11328] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[22:33:46:381] [11327:11328] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[22:33:46:381] [11327:11328] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[22:33:46:381] [11327:11328] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[22:33:46:381] [11327:11328] [DEBUG][com.freerdp.channels.drdynvc.client] - VirtualChannelEntryEx
[22:33:46:381] [11327:11328] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[22:33:46:382] [11327:11328] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[22:33:46:643] [11327:11328] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:33:46:643] [11327:11328] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:33:47:727] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - Out Channel authorization required
[22:33:47:727] [11327:11328] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:33:47:909] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - Out Channel authorization complete
[22:33:47:252] [11327:11328] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[22:33:47:252] [11327:11328] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[22:33:47:322] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - In Channel authorization required
[22:33:47:322] [11327:11328] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[22:33:47:455] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - In Channel authorization complete
[22:33:47:527] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - Handshake response received
[22:33:47:604] [11327:11328] [DEBUG][com.freerdp.core.gateway.rdg] - Tunnel response received

Do you have any suggestion what I could try to debug this issue further?
Thank you!

Gateway is quite a beast with some known issues. Probably requires debugging the response (dumping the data and comparing that)

So I did some debugging here.
It seems it has nothing to do with the second factor authentication that is set up on the server.
It turns out that the gateway server is (very likely) not a single server, behind the same domain name. At least when I lookup the IPs associated with the gateway name, I got 3 different IPs.
The client when connecting to the gateway will open two channels (in and out), which it does in rdg_connect. Each channel connection is done by calling rdg_tls_in_connect which will resolve the hostname independently, it seems.
The result ends up being that, more often than not, one channel gets opened against one IP (one server) and the other against a different one. That's when things start failing.
Changing my command line arguments to pick a specific IP for the gateway seems to have solved the problem. I am getting pretty consistent success when connecting to the gateway. The drawback is that now I need to manually acknowledge a certificate validation failure.
I am guessing that the IPs are mapped to different servers and it is simply impossible to split the channels across servers. I am guessing the fix here would be somehow pinning the IP resolved for the first channel and using it for the second.
I am happy to send a PR to address this - I just need some guidance on how would you guys suggest this to be fixed, as I don't want to start changing core functions like freerdp_tcp_connect - maybe I can somehow resolve the IP first (please suggest how) and use it as the peerHostname for both IN and OUT channel connections?

That's some nice debugging, @andreesteve :+1:
freerdp_tcp_connect() resolves all the addresses (and gets them in some random order), then tries to connect to each in turn until the connection succeeds. Then it returns the resulting connected socket, but before that the peer address of the socket is stored in settings->ClientAddress as a numeric address string.
I believe, a good way to fix this issue would be to have rdg_tls_in_connect() check the settings->ClientAddress, and if it is non-NULL then use it as the target hostname. Similar to how it already checks for the proxy hostname. This should force the address resolver to return the previously resolved IP address which will be reused for all new connections.

Hi @ilammy, thanks for the suggestion!
It seems that the ClientAddress stores the local address bound to the socket. It is resolved by freerdp_tcp_get_ip_address which uses getsocketname - returning the local address.
I am guessing either this wasn't what you were expecting or I am looking at the wrong place.
I am thinking if my investigation on ClientAddress is correct, perhaps I could try getting the peer from the out channel socket in  rdg_tls_in_connect() . What do you think?

You're onto the issue it seems. Just had a look myself, looks like the error is that the dns to ip resolve is done multiple times.
The code resolver code in freerdp_cp_connect and the rdg* functions should most likely be moved out of these functions before the whole connection sequence.

@troelsgk not quite sure this is the same problem, from the logs in your issue.
Can you add /log-level:debug /gt:http to your command line and send the logs over?
Also, in your .rdp file there should be the name/address of the gateway, if it is a name, check if it is associated to multiple ips (you check it here).

@andreesteve, yeah, my bad, I was not paying enough attention.
You will need the address returned by getpeername() (the address of the remote host on the socket), not the one from getsockname() (the address used by the local host, the one running the FreeRDP client). If rdg_tls_in_connect() calls getpeername() for the sockfd returned by freerdp_tcp_connect() then you should get the right address. You could then print it into a string like freerdp_tcp_get_ip_address() does and save the address for later somewhere in the rdg context so that the next call to rdg_tls_in_connect() uses that address as peer hostname.

@andreesteve here are the logs you requested. With those options, the command fails without prompting for GatewayUsername. The gateway is associated to only one ip address. Hope that's what you were looking for! All the best
command: xfreerdp launch3af2bfc7.rdp /log-level:debug /gt:http
[11:31:47:944] [3399:3400] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[11:31:47:944] [3399:3400] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[11:31:47:945] [3399:3400] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[11:31:47:945] [3399:3400] [DEBUG][com.freerdp.client.x11] - Pointer device: 11
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[11:31:47:947] [3399:3400] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[11:31:47:111] [3399:3400] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[11:31:47:111] [3399:3400] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[11:31:47:111] [3399:3400] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Closing as resolved. Thanks @andreesteve for his nice pull #4547


Move environment document serialization out of engine to Core API

Currently a lot of the serialization for environment documents lives in the django engine. This should be moved to the Core API to make testing / optimisations easier.

The refactoring steps will be as follows:
1. Breaking flag_engine release
Draft PR here: https://github.com/Flagsmith/flagsmith-engine/pull/167

Remove flag_engine.api module
Move dataclasses to Pydantic, export them to library's __init__/__all__
Remove marshmallow schemas and document

2. Core API release

Bump flag_engine
Add logic from flag_engine.api module to map_environment_to_document interface


fix(helm chart): Fix ImagePullSecret indentation

Why is this PR required? What issue does it fix?:
This PR fixes a bug in helm chart where the chart cannot be installed if imagePullSecret is specified.
What this PR does?:
Fixes indentation of imagePullSecret in helm chart.
Does this PR require any upgrade changes?:
No
If the changes in this PR are manually verified, list down the scenarios covered::
$ helm upgrade --install --values values.yaml --debug --wait --dry-run openebs .
values.yaml:
---
imagePullSecrets:
- name: my-image-pull-secret

Output:
history.go:56: [debug] getting history for release openebs
Release "openebs" does not exist. Installing it now.
install.go:178: [debug] Original chart version: ""
install.go:195: [debug] CHART PATH: <REDACTED>/lvm-localpv/deploy/helm/charts

install.go:210: [debug] WARNING: This chart or one of its subcharts contains CRDs. Rendering may fail or contain inaccuracies.
Error: YAML parse error on lvm-localpv/templates/lvm-controller.yaml: error converting YAML to JSON: yaml: line 137: did not find expected key
helm.go:84: [debug] error converting YAML to JSON: yaml: line 137: did not find expected key
YAML parse error on lvm-localpv/templates/lvm-controller.yaml
helm.sh/helm/v3/pkg/releaseutil.(*manifestFile).sort
	helm.sh/helm/v3/pkg/releaseutil/manifest_sorter.go:146
helm.sh/helm/v3/pkg/releaseutil.SortManifests
	helm.sh/helm/v3/pkg/releaseutil/manifest_sorter.go:106
helm.sh/helm/v3/pkg/action.(*Configuration).renderResources
	helm.sh/helm/v3/pkg/action/action.go:165
helm.sh/helm/v3/pkg/action.(*Install).RunWithContext
	helm.sh/helm/v3/pkg/action/install.go:259
main.runInstall
	helm.sh/helm/v3/cmd/helm/install.go:264
main.newUpgradeCmd.func2
	helm.sh/helm/v3/cmd/helm/upgrade.go:121
github.com/spf13/cobra.(*Command).execute
	github.com/spf13/cobra@v1.4.0/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
	github.com/spf13/cobra@v1.4.0/command.go:974
github.com/spf13/cobra.(*Command).Execute
	github.com/spf13/cobra@v1.4.0/command.go:902
main.main
	helm.sh/helm/v3/cmd/helm/helm.go:83
runtime.main
	runtime/proc.go:255
runtime.goexit
	runtime/asm_amd64.s:1581

Any additional information for your reviewer? :
No
Checklist:

[x] Fixes #
[x] PR Title follows the convention of  <type>(<scope>): <subject>
[x] Has the change log section been updated? -- No - nothing required
[x] Commit has unit tests
[x] Commit has integration tests
[x] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
[x] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:

Signed-off-by: Ondrej Vasko<EMAIL_ADDRESS>

Hello,
This PR will also require update of dependency inside openebs umbrella chart.
I am not sure if appVersion should be bumped in Chart.yaml here. Please let me know.

Thank you


LBFGS with constraints on x

First of all I want to say thanks to all the contributors of this crate, you've done an amazing job.
I'm getting started with argmin running some basic examples. I wanted to run a simple constrained optimization problem finding the minimum of a halfine (y=x with x>=0) starting from the origin using LBFGS as solver. Of course the solution to this problem is x=0 and the minimum is zero. I've implemented the CostFunction and Gradient traits as follows:
    #[derive(Clone)]
    struct Problem{
        x: Arc<Mutex<Floating>>
    }
    impl Problem {
        fn new() -> Self {
            Self {
                x: Arc::new(Mutex::new(5.0))
            }
        }
        fn f(&self, x: Floating) -> Floating {
            let mut changeable_x = self.x.lock().unwrap();
            *changeable_x = x.clone();
            println!("x:{:?}",x);
            if x<self.x_lower_bound() {
                return self.sup()
            }
            return x
        }
        fn grad_f(&self, x: Floating) -> Vec<Floating> {
            // vec![2.0 * x]
            // vec![2.0*(x-4.0)]
            if x<=self.x_lower_bound() {
                return vec![0.0]
            }
            return vec![1.0]
        }
        fn x_lower_bound(&self) -> Floating {
            0.0
        }

        fn sup (&self) -> Floating {
            100.0
        }
    }

    impl CostFunction for Problem {
        type Param = Vec<Floating>;
        type Output = Floating;
        fn cost(&self, x: &Self::Param) -> Result<Self::Output, Error> {
            let output = self.f(x[0]);
            println!("image: {:?}",output);
            Ok(output)
            // Ok(output)
        }
    }

    impl Gradient for Problem {
        type Param = Vec<Floating>;
        type Gradient = Vec<Floating>;

        fn gradient(&self, x: &Self::Param) -> Result<Self::Gradient, Error> {
            let output = self.grad_f(x[0]);
            println!("gradient: {:?}",output);
            Ok(output)
        }
    }

Where Floating is a type alias for f64.
I've tried to incorporate the constraint x>=0 returning 100.0 in case x>0 (I tried returning f64::INFINITY but the code used to panic with error MoreThuenteLineSearch: NaN or Inf encountered during iteration).
This is the code for solving the problem:
    #[test]
    fn test_min() {
        let linesearch: MoreThuenteLineSearch<Vec<f64>, Vec<f64>, f64> = MoreThuenteLineSearch::new();
        let initial_guess: Vec<f64> = vec![10.0; 1];
        let lbfgs: LBFGS<MoreThuenteLineSearch<Vec<f64>, Vec<f64>, f64>, Vec<f64>, Vec<f64>, f64>= LBFGS::new(linesearch, 10);

        let cost = Problem::new();

        let res = Executor::new(cost.clone(), lbfgs)
            .configure(|state| state.param(initial_guess).max_iters(100))
            .add_observer(SlogLogger::term(), ObserverMode::Always)
            .run()
            .unwrap();

        println!("Solution: {:?}", res.state);
    }

By setting  a number of iterations equal to 1, it solves the problem as follows:
running 1 test
x:10.0
image: 10.0
gradient: [1.0]
x:9.0
image: 9.0
May 14 17:55:34.046gradient: [1.0]
x:5.0
 image: 5.0
gradient: [1.0]
INFOx:-11.0
 image: 100.0
gradient: [0.0]
L-BFGSx:-5.5600000000000005
image: 100.0
gradient: [0.0]
, x:4.814681808522201
image: 4.814681808522201
max_itersgradient: [1.0]
:x:-2.0326081851024504
image: 100.0
 gradient: [0.0]
x:0.29547041272993013
1image: 0.29547041272993013
gradient: [1.0]

x:0.29547041272993013
image: 0.29547041272993013
gradient: [1.0]
gradient: [1.0]
May 14 17:55:34.057 INFO iter: 0, cost: 0.29547041272993013, best_cost: 0.29547041272993013, gradient_count: 10, cost_count: 9, time: 0.0106955, gamma: 1
Solution: IterState { param: Some([0.29547041272993013]), prev_param: None, best_param: Some([0.29547041272993013]), prev_best_param: Some([10.0]), cost: 0.29547041272993013, prev_cost: 10.0, best_cost: 0.29547041272993013, prev_best_cost: 10.0, target_cost: -inf, grad: Some([1.0]), prev_grad: None, hessian: None, prev_hessian: None, inv_hessian: None, prev_inv_hessian: None, jacobian: None, prev_jacobian: None, iter: 1, last_best_iter: 0, max_iters: 1, counts: {"cost_count": 9, "gradient_count": 10}, time: Some(12.3175ms), termination_status: Terminated(MaxItersReached) }

And of course the solution is close to zero if not exactly zero. However, by setting a number of iterations >1, the code loops endlessly reamaining stuck at x=NaN, objective=NaN and gradient=1
x:NaN
image: NaN
gradient: [1.0]

Any thoughts?

Apologies for the very very late reply! I have been very busy over the last couple of months and my access to the internet is currently limited (#360).
Thanks for this detailed and helpful report. Unfortunately I wasn't able to test this myself yet. As a first guess I think that the problem is that you set the gradient 0 whenever the solver it outside of the feasible range. Could you try to change your setup such that the gradient increases the further away it is from the feasible range?


OperandRequests with Finalizers block namespace deletion

/kind bug
What steps did you take and what happened:

Create a namespace (named ptest in my test)
Create an OperandRequest in the namespace (for an licensing service in my test)
Wait for the OperandRequest to result in the creation of a configmap and secret in the namespace (provides service url and token for the service requested)
Delete the namespace
The namespace is stuck in 'terminating' state because the OperandRequest cannot be deleted.  The OperandRequest cannot be deleted because it still has the finalizer.request.ibm.com finalizer.

What did you expect to happen:
The Finalizer should be automatically removed from the OperandRequest and the namespace able to be deleted cleanly.
Anything else you would like to add:
The log from the operand-deployment-lifecycle-manager-[id] pod has many messages like this upon deleting the namespace:
I0408 22:45:21.631673       1 operandbindinfo_controller.go:88] Reconciling OperandBindInfo: ibm-common-services/ibm-licensing-bindinfo
E0408 22:45:22.048797       1 operandbindinfo_controller.go:200] failed to reconcile the OperandBindinfo ibm-common-services/ibm-licensing-bindinfo: the following errors occurred:
  - failed to create secret ptest/ibm-licensing-bindinfo-ibm-licensing-token: secrets is forbidden: User "system:serviceaccount:ibm-common-services:operand-deployment-lifecycle-manager" cannot create resource "secrets" in API group "" in the namespace "ptest"
  - failed to create secret ptest/dummyenv-metering-lssecret: secrets is forbidden: User "system:serviceaccount:ibm-common-services:operand-deployment-lifecycle-manager" cannot create resource "secrets" in API group "" in the namespace "ptest"
I0408 22:45:22.682684       1 request.go:621] Throttling request took 1.043243216s, request: GET:https://<IP_ADDRESS>:443/apis/config.openshift.io/v1?timeout=32s
I0408 22:45:23.060068       1 operandbindinfo_controller.go:88] Reconciling OperandBindInfo: ibm-common-services/ibm-licensing-bindinfo
E0408 22:45:23.385037       1 operandbindinfo_controller.go:200] failed to reconcile the OperandBindinfo ibm-common-services/ibm-licensing-bindinfo: the following errors occurred:
  - failed to create secret ptest/ibm-licensing-bindinfo-ibm-licensing-token: secrets is forbidden: User "system:serviceaccount:ibm-common-services:operand-deployment-lifecycle-manager" cannot create resource "secrets" in API group "" in the namespace "ptest"
  - failed to create secret ptest/dummyenv-metering-lssecret: secrets is forbidden: User "system:serviceaccount:ibm-common-services:operand-deployment-lifecycle-manager" cannot create resource "secrets" in API group "" in the namespace "ptest"
W0408 22:45:24.140279       1 operandrequest_controller.go:98] No permission to update OperandRequest

To my eyes it is trying to reconcile the OperandRequest because the Secret was deleted during (attempted) namespace deletion.  But it cannot recreate the secret because the namespace is being deleted.  I assume it needs some logic to check the namespace when reconciling.  If the namespace.metadata.deletionTimestamp is not nil, the namespace is being deleted.  If the namespace is being deleted then instead of trying to create/update the operands, the reconcile loop should just remove the finalizer from the OperandRequest.
Environment:

ODLM version: operand-deployment-lifecycle-manager.v1.5.0
Minikube/KIND/OCP version: OCP 4.3.40
Kubernetes version: (use kubectl version): v1.16.2+853223d
OS (e.g. from /etc/os-release): n/a

@carrolp
It is because ODLM doesn't have cluster permission in the cluster. It leverages the namespacescope operator to project its namespace scope permission into the target namespace. So when you deleting the target namespace, the projected roles and rolebindings are deleted, which causes ODLM to lose the permission in the terminating namespace and it can't remove the finalized from the OperandRequest

@horis233 I think that makes sense why it's having trouble.  Thinking aloud... the "projected roles and rolebindings" perhaps should also have finalizers on them so that they aren't deleted till ODLM has finished finalizing the OperandRequest?


[Feature Request - Extra] Point of interest indicator

It would be cool to have point in a video slider that were clickable (jumps to that section) to detonate points of interest. Perhaps even with a tooltip on hover.
Maybe something like this?

I know Youtube does something sort of similar with segments of a video. That would also be cool to add.
But I'm really not sure if this type of thing falls into this framework or not. Would be nice to hear some thoughts.

Hi, thanks for the idea/request. Can you say any more about what you want to use it for? I think I know what you're looking for but it would be good to know. In general I'd call these chapter markers, but what you're describing doesn't sound like chapters, and youtube shows chapters a little differently now.

Hi Heff,
Thanks for the reply. I think chapter indicators would be a cool feature.
However, what I was imagining was more similar to how Loom does POI in a video:

Thanks @nwparker -- First stab at what this could look like: maybe Media Chrome could bake this into the existing <media-time-range> component?:
<media-controller>
  <media-time-range>
    <media-time-indicator time="20">
       <svg slot="icon"><!-- thumbs up icon --></svg>
    </media-time-indicator>
    <media-time-indicator time="30">
       <svg slot="icon"><!-- smile icon --></svg>
    </media-time-indicator>
    <media-time-indicator time="40">
       <svg slot="icon"><!-- heart icon --></svg>
    </media-time-indicator>
  </media-time-range>
</media-controller>

What I'm thinking is that there's a new <media-time-indicator> component that specifies the time in seconds, is expected to be used as a child of <media-time-range>, and has an optional slot for the icon.
I like this idea, I'm going to convert this issue to a discussion to get more feedback from the community.


some questions about the experiment in real world

Hi~ I've read your paper in detail , and I would like to ask that how you used the onboard sensors to perceive the position and speed state of the pedestrians(i.e obstacles ) around segway robot in the real world  experiment.  I plan to do similar experiments but I'm not sure how to design  perception module to get pedestrians' state in real world.

Hi there, in the paper, we assumed the crowd navigation is in an open space, i.e., there is not obstacle around pedestrains. This setup makes tracking humans much easier. We projected the depth image onto the ground and clustered projected points into clusters. The center of each cluster is a human and the speed of humans are calculated by subtracting humans' current positions from their previous positions.
This is a really simplified way of calculating human position and speed. If you have specialized sensor like Lidar or use more advanced detection technique, I believe the result should be more accurate.

@ChanganVR   Hi, changan~ Thanks for your patient answer!   Actually I still have several doubts:
(1) the segway robot also has motion, will this ego-motion have a distortion effect on the state estimation of the pedestrains?  P.S. according to your answer and the explanation in your paper, I guess what you estimate is the position and speed of the pedestrians relative to the ego-robot's local coordinate system at each moment ,and at the same time, the robot need to positioning itself in the global coordinate frame to get the distance relative to terminal point, is this guess correct?:-)
(2)  How do you position the segway robot in the global coordinate frame? Is it through SLAM module? And do you need to manually specify the end point coordinates for the robot in your real world experiment?
Actually, I plan to run my turtlebot2 robot in the complex pedestrian environment, such as library corridor,  i.e. there are both static obstacles and  various dynamic pedestrains ,  I think I can try to get their position and velocity state by lidar points semantic segmentation(which can helps to distinguish static obstacles from people body), maybe the result can be more accurate and roboust.
In short, your group's research gives me interesting inspiration about human-robot interction modeling, thanks for your paper and open source code~~ :-)

Hi @EcustBoy,
I'm really sorry that I missed your reply earlier.
This project was done quite a while ago and some of the details became blurry to me. I just checked the code and the inputs to the robots should be the global coordinate frame and the policy transforms the inputs to be relative its current pose. So yes, the human positions should be calculated in a global coordinate frame.
I think we didn't need to handle localization by ourselves since there was some module on Segway robot that has implemented that function and we basically just needed to call the API to get its current pose. And yes, the end point in my real world experiment was alway 10 meters in front the robot w.r.t its starting pose.
I haven't dealt with scenarios with both static obstacles and dynamic pedestrians. I wish you a good luck with your proejct!


[Improvement] Traversal type as option

At the moment trees are always traversed in level order (Breadth-first search). I propose to add an option to change the default tree traversal type.

The *nodes iterator should be treated as unordered, even though that's not exactly true. It really is the only performance bottleneck in the whole library. If we gave the impression that *nodes iterates in a predictable manner, we'd lose the possibility to further optimize or completely replace the algorithm without breaking client expectations.
I did quite some benchmarking on this one and the current implementation simply represents the fastest way of iterating over all nodes (that I was able to come up with at least).
If you're simply looking for depth-first traversal, take a look at methods right and [left](https://github.com/lukasbuenger/immutable-treeutils#method-left].


Simplify endpoint

The existing environment variables used in the spec to describe an endpoint:

OTEL_EXPORTER_OTLP_PROTOCOL
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_INSECURE

are the result of incremental design, due to history.
The current design for config.yaml derives from this existing specification, and currently is:
otlp:
  # http/protobuf, http/json, or grpc
  protocol:

  # http endpoint, https endpoint, or no scheme
  endpoint:

  # true or false, only used for grpc protocol with no scheme endpoint
  insecure:

Exposing the same fields to match the existing environment variables has some merits, but also carries over existing issues.
Existing configuration

Protocol

The protocol to use should be in the endpoint URL.
Instead, when using grpc, the "protocol" is set to "grpc", while the endpoint may contain "http" or "https".
This makes no sense.

Message format

The message format, "protobuf" or "json", is mixed with the protocol.
I don't think it belongs there.

Security

The "insecure" field is a last resort configuration parameter for grpc when not used with http/https.
This is too convoluted.

Lack or orthogonality

With the existing configuration, if someone changes the protocol between http and grpc, then the following fields must be adjusted as well:

endpoint needs to be fixed for the port number
endpoint needs to be fixed to add or remove the /v1/{signal} path
the endpoint http/https scheme might be missing when coming from grpc, and needs to be fixed
the insecure field may be used or not, adding general confusion. insecure=false may still be insecure.

Proposed configuration
otlp:
  # Valid values are "protobuf" or "json".
  content_type: protobuf

  # Full URL with:
  # - a scheme ("http", "https", "grpc", "grpcs")
  # - a host name
  # - a port number
  # - an optional path, for http
  endpoint:

Examples of configuration:
otlp:
  content_type: protobuf
  endpoint: "http://localhost:4318/v1/traces"

otlp:
  content_type: json
  endpoint: "https://localhost:4318/v1/traces"

otlp:
  content_type: protobuf
  endpoint: "grpc://localhost:4317"

otlp:
  content_type: protobuf
  endpoint: "grpcs://localhost:4317"

Note how this simplifies things, as the endpoint URL specifies:

the protocol to use, HTTP versus gRPC
if TLS is used, with http / grpc versus https / grpcs

all this in the same field.
It then becomes much easier to change from:
  endpoint: "grpc://localhost:4317"

to
  endpoint: "https://localhost:4318/v1/traces"

when editing a config file, or when providing substitution variables.
General considerations
Note that I am NOT asking to change existing environment variables in the specs, as this will have some global impact on all SIG and all existing deployments.
This ship has sailed.
What I am asking to consider, is to have a different design for config.yaml only, which I think makes more sense and will be more practical to work with in the long term.
Given that there are no existing deployments using config.yaml, there is no impact if done at this stage.
The migration to config.yaml will not be any more complex, mapping to the new content_type and endpoint fields is trivial.
I think we should take this opportunity to simplify.

Filed separately from comments on #76, so this can be discussed without affecting the merge of that PR.

Couple of thoughts:

This would appear to add to the list of env vars which are unmapped defined in #76, as OTEL_EXPORTER_OTLP_{SIGNAL}_PROTOCOL would join the others. This might not be a deal breaker, but should be considered.
This adds interpretation requirements (something discussed in this convo), since code has to detect the grpc / grpcs protocols and strip the protocol and configure the corresponding gRPC exporter according to the host and TLS from the endpoint.
Not sure, but are grpc / grpcs official values for scheme?

Couple of thoughts:
* This would appear to add to the list of env vars which are unmapped defined in [Add sdk-config.yaml starter template w/ references to env vars #76](https://github.com/open-telemetry/opentelemetry-configuration/pull/76), as `OTEL_EXPORTER_OTLP_{SIGNAL}_PROTOCOL` would join the others. This might not be a deal breaker, but should be considered.

These two:

OTEL_EXPORTER_OTLP_{SIGNAL}_PROTOCOL
OTEL_EXPORTER_OTLP_{SIGNAL}_INSECURE

will no longer be used.

* This adds interpretation requirements (something discussed in this [convo](https://github.com/open-telemetry/opentelemetry-configuration/pull/76#discussion_r1529221311)), since code has to detect the `grpc` / `grpcs` protocols and strip the protocol and configure the corresponding gRPC exporter according to the host and TLS from the endpoint.

Nothing changed from today. When the protocol is grpc, the code has to parse a hostname and port number from the endpoint http://host:port, while taking the http or https scheme, if present, as an indication for INSECURE.

* Not sure, but are `grpc` / `grpcs` official values for scheme?

I have seen some references to both in the wild, for example:
https://github.com/postmanlabs/postman-app-support/issues/11489
However, grpc is not even in the iana registry:
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
The point is, whatever bit dialect an exporter sends on a socket on the wire, there should be a scheme to name that dialect, and the scheme with / without TLS should have a different name, since the bits are really different.

I don't think grpc:// should be used.

Discussed in the 8/19/24 SIG.

I think we should take this opportunity to simplify.

This takes further away from compatibility with the environment variable scheme. We could solve this by having two sets of properties: one for interop with existing environment variable scheme, a second for improved use experience. But this adds confusion and the question is whether the current scheme had bad enough ergonomics to justify the additional cognitive load.
Didn't reach an answer, but we need to address this with a yes or no before stability.

I was thinking about this more and came up with a slightly different direction we could go: What if we followed the the collector, and introduced separate exporters for [grpc](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlphttpexporter] and HTTP. We could then eliminate the protocol property, and instead have an encoding property for the http variant.
The result would be something like:
tracer_provider
  processors:
    - batch:
         exporter:
           otlphttp:
             endpoint: http://localhost:4318/v1/traces
             encoding: proto # or json
    - batch:
         exporter:
           otlpgrpc:
             endpoint: http://localhost:4317

One issue I see is that the collector uses otlp to refer to the gRPC variant, and otlphttp to refer to the HTTP variant. The fact that the HTTP variant has a *http suffix while the gRPC variant does not implies a high level of priority to the gRPC variant. If I had to guess, I'd say that this naming decision pre-dated otel's shift to prefer http/protobuf as the default over grpc.
So if we went in this direction, we'd need to decide whether to follow the now suboptimal naming of the collector, or introduce more explicit names like otlphttp and otlpgrpc as I've shown above.
I think this solves the problems you outline while avoiding inventing anything new (i.e. leaning on prior art in the collector).

Using otlphttp and otlpgrpc sounds a viable option, and makes more sense with also otlpfile.


3 task: create image builder

TO DO: add zippable option as with pre-processing

TO DO:

Add zippable option as with pre-processing

Add documentation

LGTM.
Zippable option will be added in next PR