Documentation Search Feature

Feature Request
Add search capabilities to the TCE documentation site.
Describe alternatives you've considered

Additional context

My notes on getting search working for https://tanzucommunityedition.io/docs/:

Most of the frontend/Hugo templating is already accounted for through a few values in config.yaml. Mainly the docs_search_* properties.
I've opened a support ticket with Algolia DocSearch via https://docsearch.algolia.com/ to create the index and search api_key. Waiting to hear back from them.

I'm not aware of an existing Algolia index/account we could use—happy to use that if one is around!

Preview of how it will look (from a local branch): https://silly-mirzakhani-c505f9.netlify.app/docs/latest/

Note: Results are pointing to the .io domain, and the index was generated manually. There's also a minor update to fix the input font.

I'll make a PR if no one is looking into this!

Looks great. A PR would be great, as far as I know, no one else is looking into this.

Thanks for looking into this @garrying - one other thing of note; it would be great if we could bump to the new alpha of docsearch.js v3. The v2.6 version of docsearch.js that we have declared in the doc/site/themes/template/layouts/_default/baseof.html hasn't had a published release for over 2 years and has a few transient security vulnerabilities.
If we introduce this feature, we should use v3 of docsearch.js


Code examples for a point within a bounds ...

I know this might be a repeat of the previously closed question regarding difference between STContains and STWithin - but I have yet to find an answer.
Please see my StackOverflow post at:
https://stackoverflow.com/questions/61553745/ms-sql-geography-testing-if-a-point-is-within-a-bounds-what-does-stwithin-do
Thanks in advance.

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

ID: 5be221aa-48df-e9ab-fc2d-65d4f7ec56ce
Version Independent ID: b81cfb49-c58a-97bd-5e85-224e567a633e
Content: STContains  (geography Data Type) - SQL Server
Content Source: docs/t-sql/spatial-geography/stcontains-geography-data-type.md
Product: sql
Technology: t-sql
GitHub Login: @MladjoA
Microsoft Alias: mlandzic

@bdcoder2 , STContains and STWithin are analogous spatial relation checks in terms of a.STContains(b) returning always the same result as b.STWithin(a). In fact, only one of them is actually implemented in SQL Spatial - calling the latter one is internally being "swapped" to a call of a former one.

@MladjoA - so it is true: a.STContains(b) == b.STWithin(a)    This should be mentioned in the docs (if not already) -- Thanks!!


Sequoia 15.0.1 desktop switching fails

I'm aware 15.0 is what's listed as supported, I let an auto-upgrade go through with 15.0.1 recently and yabai has started to fail in two specific ways.

I can no longer switch desktops. Via hotkeys
I can not move windows to other desktops. Instead of moving to another desktop the window gets pushed to the background on the same desktop.

Is there any information from a debugging perspective I could provide that would help identify what changed in 15.0.1? Or do I just need to wait for the project to address changes in the new update?

me2, I am experiencing an issue with your issue 2: yabai -m window --space 1; I think this issue emerge after I updated my macbook to 15.0/15.0.1

Thirded. Key commands are recorded and cursor follows the selected desktop, but desktop fails to switch. Started happening on switch to 15.0.1.

Folks on the skhd repo talked about similar issues: https://github.com/koekeishiya/skhd/issues/371
However, I doubt the observed behavior is linked to the change introduced by Sequoia 15.0.1, since even when respecting the new requirements for shortcuts, yabai does not successfully move windows.

I can confirm this as well:

I can not move windows to other desktops. Instead of moving to another desktop the window gets pushed to the background on the same desktop.

with the one exception: I actually can move window to a new space but only if that is another active space on a different display.

Actually you're right, same results here I hadn't tried using a different monitor.

As a workaround you can just run the skhd as a background process:
skhd &

to make it permanent (or till fixed) you can crate a login shell script with the command above to run skhd after login

@martin-tomes can you clarify what you mean this doesn't help for me.
I've:

disabled and uninstalled the skhd service
ran skhd & to run it as a background process

While this asked me to approve my terminal, it didn't fix anything for me.

I can move a window between monintors
I can not move a window to a desktop that is not in focus
I can not change the focused desktop

Are you saying you can move a window to an unfocused desktop and you can change the focus to a new desktop?

Following the instructions on partially disabling SIP fixed the issue for me. However, I feel somewhat uneasy about disabling SIP—are there plans to enable moving windows without having to disable SIP?

Fixed in v7.1.5.
No, you need SIP disabled and scripting addition installed to move windows from Sequoia, because Apple added restrictions to their (private) API.

Great thanks I've got it working again!
For anyone going through this process as well, don't forget if you followed the directions in the wiki you've put a sha256 on your visudo for running yabai --load-sa I had to update that which looked like the scripting addon not being installed, but it was really just failing to get started.

Running:

Yabai: v7.1.5.
skhd: v0.3.9.
MacOS Sequoia 15.1 | M1

I configured the scripting addition and disabled SIP but my shortcut keep putting my window to the background.
Is there a way that you could better explain the solution to this problem?


Istiod may fail to validate xds client cert when using custom CAs

Bug description
In V1.5, the istiod XDS server is verifying client cert if given:
https://github.com/istio/istio/blob/release-1.5/pilot/pkg/bootstrap/server.go#L692
Envoys have the XDS configured to always conduct mTLS to istiod:
https://github.com/istio/istio/blob/release-1.5/tools/packaging/common/envoy_bootstrap_v2.json#L276
If Envoys get key/cert from custom CAs (through istio-agent), istiod doesn't know the root CA. This results in istiod failing to authenticate the client through mTLS.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ X ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
When using custom CA, Envoy should not do mTLS to istiod, instead, it should do TLS.
Steps to reproduce the bug
Configure istio-agent to retrieve certificates from custom CAs, such as Vault.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.5
How was Istio installed?
istioctl
Environment where bug was observed (cloud vendor, OS, etc)

Sounds like the plumbing of customized root cert is not properly done in istiod side. An integration test of using customized CA/root feature can & should help catch this.