Integration tests refactor

This refactors the integration tests to run in-process instead of compiling and executing the binary separately.

Move integration tests to tests/ directory
Integration tests that execute Terraform are now in the top-level directory.

Use functional options pattern
This is a breaking change that introduces the functional options pattern for astro.Project so we don't need to make breaking changes in the future.

Refactor cmd package
The CLI application and state is now part of a struct that can be instantiated. Global variables have been removed. This improves testability as well as understanding of what's going on. Code has been cleaned up to be more readable.

Since this is a breaking API change we'll bump a minor version.

TODO: Need to update changelog.

I always feel confused by the struct/file/directory names in astro. For example,

These are really good comments. Let's file them away in an issue so we can fix this later. Maybe it could be a good task for you to take on? :-)


撤销会导致数据丢失，提示错误

Following files affected by this action have been already changed:

Closed as invalid - please reopen when the following points are addressed:

Issues have to be written in English
The description is incomplete


[vCenter] high nic unitnumber when changing default nic model

Description
If you choose a hardware model for a vCenter NIC different than default, the resulting machine will have high nics unitnumber.
example:
Instead of:
- NIC 1
- NIC 2
- NIC 3
you will have:
- NIC 3
- NIC 4
- NIC 5
The order is the same.
To Reproduce
Steps to reproduce the behavior.
Update a vCenter template with the propery: NIC/MODEL with a non default value.
Details

Affected Component: VMM
Hypervisor: vCenter
Version: development

Additional context
Add any other context about the problem here.

Progress Status

[x] Branch created
[x] Code committed to development branch
[x] Testing - QA
[x] Documentation
[x] Release notes - resolved issues, compatibility, known issues
[x] Code committed to upstream release/hotfix branches
[x] Documentation committed to upstream release/hotfix branches

This feature and #2293 works (5.8)


Use log package for dump instead of fmt

This allows logging when go-auth0 package is called from
terraform-provider-auth0.

This is great! I was looking for a way to debug from terraform and was having a hard time. Do you happen to have a link describing the use?

https://github.com/hashicorp/go-plugin

Built-in Logging. Any plugins that use the log standard library will have log data automatically sent to the host process. The host process will mirror this output prefixed with the path to the plugin binary. This makes debugging with plugins simple.

I'm not an expert in terraform internals btw, but I think this is the only way to log from plugins.

This is excellent, thank you! I'll study this a little more.


TileSourcePolicy.getHttpCacheControlDuration header parse bug

mapbox sometimes returns a Cache-Control http header of "max-age=43200,s-maxage=43200" which TileSourcePolicy.getHttpCacheControlDuration fails to parse.  it gets confused by having both max-age and s-maxage

Hi @steelbytes!
Assuming that the cache control is exactly max-age=43200,s-maxage=43200, the problem is that we expect a space after the comma:
// current code of TileSourcePolicy.getHttpCacheControlDuration
final String[] parts = pHttpCacheControlHeader.split(", "); // here!
final String maxAge = "max-age=";
for (final String part : parts) {
    final int pos = part.indexOf(maxAge);
    if (pos == 0) {
        final String durationString = part.substring(maxAge.length());
        return Long.valueOf(durationString);
    }
}

I couldn't find on the web what is actually expected as the correct separator.
I guess a solution would be to change the code like this:
final String[] parts = pHttpCacheControlHeader.split(","); // removing the space after the comma
final String maxAge = "max-age=";
for (String part : parts) {
    part = part.trim(); // removing the space
    final int pos = part.indexOf(maxAge);
    if (pos == 0) {
        final String durationString = part.substring(maxAge.length());
        return Long.valueOf(durationString);
    }
}

Feel free to test that and to create a PR.

@monsieurtanuki I think durationString should also have a trim

@steelbytes "I HAVE A TRIM" (sorry about that).
Feel free to PR.


New Majestic streamer options in config

How will it be possible to add new audio system control options via GPIO to your wonderful WEB interface
audio:
 .....
 outputEnabled: false
 speakerPin: 32
 speakerPinInvert: false

done.


ScriptBuf debug and pretty debug are ugly

Currently ScriptBuf derives Debug, this results in the array of bytes being printed as integers. Also, pretty debug prints each digit on a newline.
    let unsigned_tx = "0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000";

    let tx_bytes = Vec::from_hex(unsigned_tx).expect("failed to parse unsigned transaction hex");
    let tx: Transaction = deserialize(&tx_bytes).expect("failed to deserialize tx bytes");

    println!("{:?}", tx.output[1].script_pubkey);
    println!("{:#?}", tx.output[1].script_pubkey);

Gives:
ScriptBuf([118, 169, 20, 59, 222, 66, 219, 238, 126, 77, 190, 106, 33, 178, 213, 12, 226, 240, 22, 127, 170, 129, 89, 136, 172])
ScriptBuf(
    [
        118,
        169,
        20,
        59,
        222,
        66,
        219,
        238,
        126,
        77,
        190,
        106,
        33,
        178,
        213,
        12,
        226,
        240,
        22,
        127,
        170,
        129,
        89,
        136,
        172,
    ],
)

Yeah, we need to delegate to Script


[Bug]:  Inconsistent Recognition of Non-Hyphenated Inline Fields

What happened?
So, in various notes, I have this inline field:
[Scientific Name:: ]

In the database view of that group of notes, when I try to add this column, it gives me two options: scientific-name and Scientific Name.
When I choose Scientific Name, nothing shows up in that column; but when I choose scientific-name it shows all of my data. If I go into a note and type in something like, [Scientific Name:: Canis lupis], then Canis lupis shows up in the scientific-name column instead of the Scientific Name column.
But, when I type something into the scientific-name column, it creates a new field in the note, scientific-name:: whatever I typed, instead of putting it in the Scientific Name field, which I thought it was registering as scientific-name. And strangely, it always leaves out the closing bracket at the end.
Now, if I go back to the table and type Canis lupis into the Scientific Name column instead, it will again create a new field in the note: [Scientific_Name:: Canis lupis. And again, it leaves out the closing bracket.
The fields were purely inline as well and  weren't contained in callouts or blockquotes.
What platform were you using?
Desktop
Version of the plugin
3.3.0
Relevant log output
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'forEach')
    at eval (plugin:dbfolder:118:6542)
    at a (plugin:dbfolder:109:304393)
    at h0.eval (plugin:dbfolder:118:6449)
    at Generator.next (<anonymous>)
    at o (plugin:dbfolder:1:748)
app.js:1 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'top')
    at t.coordsAtPos (app.js:1:1316723)
    at t.updatePosition (app.js:1:1666908)
    at t.showSuggestions (app.js:1:1666606)
    at t.showSuggestions (app.js:1:1668824)
    at t.<anonymous> (app.js:1:1666389)
    at app.js:1:235505
    at Object.next (app.js:1:235610)
    at a (app.js:1:234349)
2plugin:dbfolder:118 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'tags')
    at X0.checkIfFileIsInSource (plugin:dbfolder:118:26887)
    at X0.eval (plugin:dbfolder:118:25714)
    at Generator.next (<anonymous>)
    at eval (plugin:dbfolder:1:938)
    at new Promise (<anonymous>)
    at a (plugin:dbfolder:1:697)
    at Object.n.actions.dataviewUpdater (plugin:dbfolder:118:25644)
    at eval (plugin:dbfolder:109:249809)
    at Generator.next (<anonymous>)
    at eval (plugin:dbfolder:1:938)

Are you using the latest version of the plugin in your Obsidian vault?

[X] I have verified that I am on the latest version

Are you check if there is a similar issue?

[X] I have verified that there are not similar issues

We have to check the class with the inline builder then
https://github.com/RafaelGB/obsidian-db-folder/blob/master/src/patterns/builders/NoteContentActionBuilder.ts
Thanks for the report!

https://github.com/RafaelGB/obsidian-db-folder/issues/798 fixed with this other one


improve NFC reading UX on android

Issue Description:
when users scan their passport using NFC on Android, the following steps occur:

they click on the button "Scan with NFC" and a sheet opens at the bottom of the screen.
they hold their passport against their phone, moving it slowly until the NFC reader detects the chip in the passport.
when the NFC reader detects the chip, the phone vibrates, indicating that users should stop moving the phone.
once the passport reading is complete, the sheet closes, and the user is brought to the next screen.

Problem:
the vibration alone is not sufficient to inform users that they need to stop moving the phone and that the phone is currently reading the chip.
Request:
we would like an implementation similar to the one on iOS, with an animation showing the progress of the reading and displaying which datagroup is currently being read.

Hi @remicolin is this issue still available? I'd love to work on it.

hi @Joy-Adah the issue is still available you can work on it

@remicolin thanks! I'll work on it

do you have any updates to share @Joy-Adah ?

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hello, my name is Bernal. I am a software developer from Costa Rica. Currently, I work as a back-end developer. In my previous job, I worked as a full-stack developer. Personally, I enjoy developing both the back end and the front end. I have 4 years of experience in the software development industry. Some technologies I have worked with include: Typescript, React, C#, and Node.
How I plan on tackling this issue
To reach the solution, the first step is to understand how the project works. This involves familiarizing yourself with the project's documentation, structure, and codebase. Next, thoroughly review the issue description to grasp the problem fully. Based on this understanding, brainstorm and propose a viable solution. Once you have a clear plan, implement the solution in the code. After coding, conduct comprehensive tests to ensure the fix resolves the issue without introducing new problems. Finally, review your changes and prepare them for submission, ensuring all aspects of the issue have been addressed effectively.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a UI/UX designer with almost 2 years of experience, including work on Web 3 projects and various hackathons such as StarkNet and MuAccra. My expertise in creating intuitive and visually appealing user interfaces positions me well to address the current issue with the NFC passport scanning feature on Android.
I would like to contribute to this project.
Portfolio: https://www.figma.com/proto/HcFnqYWAab3sA4ws0oL8HL?node-id=16-2290&t=kNV6jRPoeTxuc3Lc-6
How I plan on tackling this issue
I will analyze iOS implementation: I will review the iOS animation and progress indicators to understand the user experience.
And then I will design animation: Create a visually appealing animation that clearly indicates the progress of the NFC reading process.
Lastly, I will integrate feedback indicators: Display real-time updates on which datagroup is being read to keep users informed.
I'll also ensure the implementation works seamlessly across different Android devices and screen sizes.

@BernalHQ can you give me a human written version of how you plan to tackle the issue?

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hello @remicolin,
I have experience as a mobile developer with Dart, Flutter and those technologies and I know how to test, debug and measure all this procceses using Android Studio, considering this is an issue related with Android I think I could have a good backgroud to work on it and I'm part of the Dojo community in Costa Rica.
How I plan on tackling this issue
Approach to Resolve the Issue:

Visual Progress Animation: Implement a visual progress animation to indicate the reading process. This will provide clear feedback to users about the ongoing reading and when to stop moving the phone.

DataGroup Display: Display which datagroup is being read during the NFC process. This enhances user understanding and engagement.

Integration and Testing: Integrate these visual cues into the existing Android NFC scanning workflow. Thoroughly test and debug using Android Studio to ensure smooth functionality across devices.

Variable Investigation: Investigate if there is a value or variable that updates during the reading process to create the animation. Implementing the animation will be straightforward once this detail is identified.

Also I could work on this one together with @BernalHQ, to have discussions, more ideas and done it in a quickly way too.

@BernalHQ sweet, you can start working on it!
if you want i can provide you screen recording of the iOS version which is basically empty dots that turn green.
feel free to dm on tg @colinremi

Hi @remicolin, thanks for the oportunity. I going to start work it on it. And yes, please provide me a example of the IOS version animation.

Is this fixed? I can't scan either of my passports on Android. Using a Pixel 8.


safe local command

safe local runs an initialized Vault on a randomized port, initializes it, authenticates to it, and then waits for a Ctrl-C / SIGTERM.  While it's waiting, the vault can be targeted with a unique name, preferably security-themed.
When the safe command is terminated, it will run a final export to an 0400 file in the users $HOME directory, and then print out a message to that effect.
The goal is to allow people to easily bootstrap a Vault BOSH deployment, and not have to deal with the "uneven edges" of vault server -dev.

This also makes sense as safe --local ... to allow other commands to operate on a transient Vault, most likely with an implicit safe export at the end.


document in-place bindings

I forgot to update the readme before merging #262.

Fixed by https://github.com/getquill/quill/pull/335


Support Test Proxy logging error output into a different log file

Updates the Test Proxy scripts to support outputting error logs into test-proxy-error.log. This should also standardize behaviors between Windows and Linux/macOs where Start-Process doesn't appear to include error output when -RedirectStandardError isn't supplied whereas &> for nohup will redirect all output to the given location.
With this there will be two files that need to be managed for Test Proxy, so publish-proxy-logs.yml is updated appropriately to grab test-proxy-error.log as well.

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow


Missing compiler intrinsics

I think it would be helpful to collect a list of all compiler intrinsics (the extern "platform-intrinsics" ones) that need to be added.

[x] simd_neg
[ ] simd_overflowing_add etc
[x] simd_trunc
[x] simd_round
[ ] simd_lt_packed etc (all other packed intrinsics can be emulated with this one to start)
[ ] simd_sat_shl <-- only supported in recent LLVM
[ ] simd_abs

On one hand, logically there isn't any reason it should yield the same results, as integers are simpler types. On the other hand, https://github.com/rust-lang/stdsimd/issues/97 still gives me the heebie-jeebies about adding simd_abs as an intrinsic.
What would simd_lt_packed be equivalent to?

I think I previously decided (but never updated this issue) that we don't need an intrinsics for operating on packed bit masks.  I think we only need two intrinsics, one for sign extending a packed bit mask to a full width mask, and one for truncating a full width mask to a bit mask.

Actually, looking at the rustc codegen, I think simd_bitmask might be the truncation I'm talking about.


associations: non-persistent? (see #16)

Associations is used in ReliabilityBasedBootstrapping to conveniently access associations between patterns and entities (an entity is associated with a pattern that extracts it and vice versa). It should IMHO not be persisted.

Then we're all on the same page. Feel free to close, as this is the current behavior.


Ver 7.3.5 issues

Hi,
There are several issues that I would like to know if there's a way to solve them.

From time to time when you are updating the version, after the update all the open files are gone and I have to reopen them. Is is a bug on the installation that is not keeping the open files as they were before the upgrade? Because usually it works fine.
How to change the the default open and save will be a folder that i want and not what is selected on the Workspaces? I couldn't find a way to change it.
I've notice today that when I type Hebrew it's not working properly. Hebrew is a 'Right to Left' language, and when typing a word in Hebrew and then pressing space to type the next word, the editor put the next word to the right of the previous word and not to the left (like it's left to right typing). It used to work fine before.
One more issue with the Hebrew, when saving the file and doing search on the windows for words written in Hebrew in the sql file the windows doesn't recognizing the words (unlike if you save a text file with Hebrew words and search for those words the windows search tool find them).

In general I would like to say that this is an excellent software to work with databases, really amazing!
Keep on the great work.
Many Thanks,
Shally

System information:

Operating system (distribution) and version
DBeaver version
Additional extensions

Connection specification:

Database name and version
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
Steps to reproduce, if exist:
Include any warning/errors/backtraces from the logs

Hi @Shallyz ,

Did you choose Reset UI in the installer during upgrading?
As I can see, the last used folder is used for file saving/opening. Or do you mean some special case?
3-4. #10911 issue is already created.

Hi,

No, I always make sure that the reset won't be checked. I think it happens if I do install and not closing the application, so the installation stopped and waiting for me to close the application and then continue (this is what happened last time when it happens). 2. Every time I open the application, at the first time it goes to C:\Users\shally.zarzar, how can I change that?
Thanks
On Tuesday, February 16, 2021, 06:25:21 PM GMT+2, Dziyana<EMAIL_ADDRESS>wrote:

Hi @Shallyz ,

Did you choose Reset UI in the installer during upgrading?
As I can see, the last used folder is used for file saving/opening. Or do you mean some special case?
3-4. #10911 issue is already created.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Cannot reproduce this against recent version - if the issue reproduces in the future, please open a new ticket related to it.
You can change the default workspace in Main menu: File - Switch workspace - Other


Support multiprocess mode without setting an environment variable

This is essentially a duplicate of issue #701
The main problem for my use case is that it's impossible to separate multiple instances of collectors, even though it has a path field misleading you into thinking that you can
https://github.com/prometheus/client_python/blob/master/prometheus_client/multiprocess.py#L22
I am personally not sure about ways of fixing that, apart from just unifying the implementations and only supporting the multiprocess mode. Because running python as multiple processes is arguably a more popular way of doing things, Web servers, and async processing all pretty much run on multiprocessing and it has to be the largest chunk of software that wants to be instrumented.
And while mmapped files have overhead, it's not super big and python is not used for blazingly fast things in general, so IMO it's a reasonable tradeoff for the simplicity of maintaining a single mode of operation.

Similar to the other issue, I am open to ideas for supporting multiprocess mode without setting an environment variable. There are other drawbacks of multiprocess mode as well, such as not supporting custom collectors which is another common usage of this library.

If I understand the code correctly, there are two environment variables that prometheus_client depends on it: PROMETHEUS_DISABLE_CREATED_SERIES and PROMETHEUS_MULTIPROC_DIR.
Is it a bad idea if we can simply pass and customize use_created and value_class on metric's constructor?
An snippet of my thoughts:
from prometheus_client import multiprocess, values
from prometheus_client import generate_latest, CollectorRegistry, CONTENT_TYPE_LATEST, Counter

PROM_MULTIPROC_DIR1 = '/tmp/prom1/'

single_process_registry = CollectorRegistry()

MY_COUNTER1 = Counter('my_counter', 'Description of my counter', use_created=False, value_class=values.MultiProcessValue(path=PROM_MULTIPROC_DIR1))

MY_COUNTER2 = Counter('my_counter', 'Description of my counter', use_created=True, registry=single_process_registry)

# Expose metrics.
def app(environ, start_response):
    registry = CollectorRegistry()
    multiprocess.MultiProcessCollector(registry, path=PROM_MULTIPROC_DIR1)
    data = generate_latest(registry)
    status = '200 OK'
    response_headers = [
        ('Content-type', CONTENT_TYPE_LATEST),
        ('Content-Length', str(len(data)))
    ]
    start_response(status, response_headers)
    return iter([data])

from prometheus_client import multiprocess

def child_exit(server, worker):
    multiprocess.mark_process_dead(worker.pid, path=PROM_MULTIPROC_DIR1)


Inconsistent (de)selecting behavior when filter is enabled

Selecting and deselecting behave differently when filter is enabled:

Search for something and click deselect -> ALL items get deselected
Search for something and click select -> only the filtered items get selected

I don't know when this came in but some weeks ago case 2 worked for both select and deselect. Also the question what is the correct behavior. Should only the filtered items be selected and deselected or all items.

I think filtering should leave now hidden items in the state they were before filtering and only affect the visible items in the control.


apply PodSecurityPolicy before check for ready nodes

What this PR does / why we need it: possible race condition between PodSecurityPolicy requirement and node Ready requirement
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #2607
Special notes for your reviewer:
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

@pidah @khaldoune if you have a moment to review the change here, and for extra credit: @khaldoune if you could build a cluster using using the configuration that this change is designed to fix.
Thanks!

LGTM but not tested @jackfrancis

@jackfrancis

@jackfrancis @CecileRobertMichon @pidah I had done the same thing but from 0.15.1. Building from master fails.

@jackfrancis @CecileRobertMichon @pidah
k8s cluster is not healthy after 600 seconds on a master2 node => Deployment will never succeed. But after some time, the cluster is healty. I'm investigating.

@jackfrancis @pidah @CecileRobertMichon
What I have observed is not related to this commit. I have opened an new issue (#2645) so we can continue there.
Thanks.


Added identity server's EF Core persistent grant store

Pull Request Test Coverage Report for Build 385718868

13 of 295 (4.41%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-11.0%) to 56.412%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

Fhi.Smittestopp.Verification.Persistence/PersistenceConfigExtentions.cs
6
7
85.71%

Fhi.Smittestopp.Verification.Server/Startup.cs
7
8
87.5%

Fhi.Smittestopp.Verification.Persistence/IdentityServer/Migrations/PersistedGrantDb/20201126172519_InitialIdentityServerPersistedGrantDbMigration.cs
0
66
0.0%

Fhi.Smittestopp.Verification.Persistence/IdentityServer/Migrations/PersistedGrantDb/20201126172519_InitialIdentityServerPersistedGrantDbMigration.Designer.cs
0
107
0.0%

Fhi.Smittestopp.Verification.Persistence/IdentityServer/Migrations/PersistedGrantDb/PersistedGrantDbContextModelSnapshot.cs
0
107
0.0%

Totals

Change from base Build 385481506:
-11.0%

Covered Lines:
865

Relevant Lines:
1512

💛  - Coveralls


Move SpreadsheetExportMixin to wagtail.admin.views.mixins

Fixes #6265. The new django-filter code in wagtail.admin.views.reports is not compatible with loading that module before models have been loaded; this broke the recipe at https://docs.wagtail.io/en/stable/reference/contrib/forms/customisation.html#customise-form-submissions-listing-in-wagtail-admin , as it involved loading wagtail.contrib.forms.views at model loading time, and that was importing SpreadsheetExportMixin from wagtail.admin.views.reports. Moving this out of wagtail.admin.views.reports breaks the deadlock.
Thanks for contributing to Wagtail! 🎉

@gasman  thanks heaps for fixing this, nice solution.


Pull out the Data Collection Task header into subcomponent

Added a new subcomponent view for the Data Collection Task header so it can be reused between different task fragments
Towards #1146
@shobhitagarwal1612 PTAL

Let me know if you have any ideas why the tests are failing now. I ran the app on my device and it seems to be working properly so I don't know why I'm getting these errors:
is displayed on the screen to the user' doesn't match the selected view.
Expected: is displayed on the screen to the user
     Got: "MaterialTextView{id=2131230879, res-name=data_collection_question, visibility=VISIBLE, width=6, height=65, has-focus=false, has-focusable=false, has-window-focus=true, is-clickable=false, is-enabled=true, is-focused=false, is-focusable=false, is-layout-requested=false, is-selected=false, layout-params=androidx.constraintlayout.widget.ConstraintLayout$LayoutParams@5a5f1e45, tag=null, root-is-layout-requested=false, has-input-connection=false, x=0.0, y=41.0, text=task 1, input-type=0, ime-target=false, has-links=false}"

All of the view assertions are failing. I'll try to take a look at it today.

@JSunde so, it's subtle, but a one-line change made it such that the view is not actually visible. Change the constraint on data_collection_question back to app:layout_constraintTop_toBottomOf="@+id/data_collection_task_name" />

Thanks @scolsen! I took a closer look and I think there were actually a couple things wrong with the constraints there, I ended up constraining the top to the bottom of data_collection_step_number and the bottom to the bottom of the parent and now it seems to be passing the test and looks correct on my device.

Codecov Report

Merging #1344 (4280156) into master (2787b2c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1344   +/-   ##
=========================================
  Coverage     31.51%   31.51%
  Complexity      891      891
=========================================
  Files           301      301
  Lines          7184     7184
  Branches        440      440
=========================================
  Hits           2264     2264
  Misses         4775     4775
  Partials        145      145

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Hard to borrow stock

Does this work for shorting hard to borrow stock? Could you give an example if so? Also, is there a way to set a limit order for the sell to open that includes the fees associated with locating the shares? Or do you look up the fees in a different step? Thanks in advance for any help you can provide.

Of course it does, that's one of the main reasons why this exists.
Have a look at the documentation, for locating hard to borrow stocks:
https://shner-elmo.github.io/tradezero-api/tradezero_api/main.html#TradeZero.locate_stock
And for limit orders:
https://shner-elmo.github.io/tradezero-api/tradezero_api/main.html#TradeZero.limit_order

And you have to locate the shares prior to setting the limit order ofc


Persist generated NodeID PrivKey when not supplied

Description
When no --p2p-private-key-file option is supplied Teku generates a random KeyPair for NodeID every launch
It would be more convenient if the private key generated on the first run is persisted and used on subsequent runs when --p2p-private-key-file is not set explicitly.

Confirming this issue. I see the peer ID change and can't use my enr anymore after a restart. Will configure with --p2p-private-key-file for now.

This is a dup of #1961.

I closed #1961, but also see the comments there as they are relevant to implementing this properly (I.e. Seq number handling).

If this is still open because of the complexity with secret key handling, maybe the implementation of seq-number persistence should be prioritized? That would avoid any bugs or unexpected behavior caused by the use of the same p2p private key after a restart (with that cli flag). Or is that already part of the discv5 library? Is the discv5 data persisted anywhere?


Include tags when errors are logged with server.log()

Coverage increased (+0.0004%) to 98.991% when pulling 52374d5abcccb7ecc87cbc2da5380f8912e98dc0 on jonathansamines:feature/server-log-tags into d45fcefd66c6fe1b9c2fc390f4e2f2e0109bcc2b on pinojs:master.


install retries exhausted but the pod is running ok

Used Google translate
hi
I am currently using the flux v1 version and want to change to the v2 version, so I am researching it.
While trying to install and deploy to a kind cluster in my local WSL Ubuntu environment, a strange phenomenon occurred, so I made an inquiry here.
The status of the tomcat Pod resource created through the HelmRelease resource is normal, but why does the status of the HelmRelease resource become an error after waiting for about 5 minutes?
I googled a lot and followed all the steps related to "retries exhausted". But nothing worked.
Shouldn't the contents that are uploaded from Get Started or Installation that you guys have made work at least to build trust in the component?
Below is kind cluster configuration.
---
apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
name: taiga-1026
nodes:
- role: control-plane
  image: kindest/node:v1.24.13@sha256:cea86276e698af043af20143f4bf0509e730ec34ed3b7fa790cc0bea091bc5dd
- role: worker
  image: kindest/node:v1.24.13@sha256:cea86276e698af043af20143f4bf0509e730ec34ed3b7fa790cc0bea091bc5dd

Below is the client version I am using.
flux -v
flux version 2.0.0-rc.5

I registered the Helm chart and wanted to distribute the chart, so I set it up as follows.
flux install \
  --network-policy=false \
  --watch-all-namespaces=true \
  --namespace=flux-system \
  --log-level debug \
  --components=source-controller,helm-controller

And the nginx chart was installed with the HelmRepository setting completed normally.
flux create helmrelease nginx-testing-1 \
  --namespace=$NS \
  --target-namespace=$NS \
  --create-target-namespace \
  --source=HelmRepository/bxcp-system-common.bxcp-system \
  --chart=tomcat \
  --chart-version="10.9.2" \
  --interval=10s \
  --chart-interval=10s
✚ generating HelmRelease
► applying HelmRelease
✔ HelmRelease created
◎ waiting for HelmRelease reconciliation
✗ client rate limiter Wait returned an error: context deadline exceeded

After waiting for about 5 minutes, the nginx-testing-1 HelmRelease resource was found in the following state. The problem is that the Pod resource status is normal, but I don't know why the HelmRelease resource is abnormal.
The following is the result of checking the status with the kubectl command. Some information has been covered with garbage information.
Every 2.0s: kubectl get helmrepo -A; echo;echo; kubectl get hr -A; echo;echo; kubectl get pods -A                                                      NB-21042711: Fri Jun 16 08:41:27 2023

NAMESPACE     NAME                 URL                                                                                AGE   READY   STATUS
bxcp-system   bxcp-system-common   https://xxxxxxxxxx:0000/chartrepo/bxcp-system-common   29m   True    stored artifact: revision
'sha256:ea7575a7761511264744c90f5e0f63c024ca822c4714a73ae5bb003adc1d09c0'

NAMESPACE   NAME              AGE   READY   STATUS
default     nginx-testing-1   25m   False   install retries exhausted

NAMESPACE            NAME                                               READY   STATUS    RESTARTS   AGE
default              default-nginx-testing-1-tomcat-86c9545c98-mhh72    1/1     Running   0          25m
flux-system          helm-controller-b4ffbcbf-hgqfb                     1/1     Running   0          29m
flux-system          source-controller-659b55846c-wk2c6                 1/1     Running   0          29m
kube-system          coredns-57575c5f89-t6rx9                           1/1     Running   0          30m
kube-system          coredns-57575c5f89-xpr78                           1/1     Running   0          30m
kube-system          etcd-taiga-1026-control-plane                      1/1     Running   0          30m
kube-system          kindnet-774lg                                      1/1     Running   0          29m
kube-system          kindnet-jztlr                                      1/1     Running   0          30m
kube-system          kube-apiserver-taiga-1026-control-plane            1/1     Running   0          30m
kube-system          kube-controller-manager-taiga-1026-control-plane   1/1     Running   0          30m
kube-system          kube-proxy-fx6cf                                   1/1     Running   0          29m
kube-system          kube-proxy-gfqxm                                   1/1     Running   0          30m
kube-system          kube-scheduler-taiga-1026-control-plane            1/1     Running   0          30m
local-path-storage   local-path-provisioner-c49b7b56f-jdhgc             1/1     Running   0          30m

Here is the helm controller log:
{"level":"info","ts":"2023-06-15T23:11:58.719Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":":8080"}
{"level":"info","ts":"2023-06-15T23:11:58.720Z","logger":"setup","msg":"starting manager"}
{"level":"info","ts":"2023-06-15T23:11:58.720Z","msg":"Starting server","kind":"health probe","addr":"[::]:9440"}
{"level":"info","ts":"2023-06-15T23:11:58.821Z","msg":"starting server","path":"/metrics","kind":"metrics","addr":"[::]:8080"}
{"level":"info","ts":"2023-06-15T23:11:58.821Z","logger":"runtime","msg":"attempting to acquire leader lease flux-system/helm-controller-leader-election...\n"}
{"level":"info","ts":"2023-06-15T23:11:58.828Z","logger":"runtime","msg":"successfully acquired lease flux-system/helm-controller-leader-election\n"}
{"level":"debug","ts":"2023-06-15T23:11:58.828Z","logger":"events","msg":"helm-controller-b4ffbcbf-hgqfb_e9ac28cd-408e-44a8-ac22-d90f7d62c611 became leader","type":"Normal","object":{"kind":"Lease","namespace":"flux-system","name":"helm-controller-leader-election","uid":"c207f0ff-ab50-4c6f-9028-7bfdf293c7bf","apiVersion":"coordination.k8s.io/v1","resourceVersion":"627"},"reason":"LeaderElection"}
{"level":"info","ts":"2023-06-15T23:11:58.828Z","msg":"Starting EventSource","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","source":"kind source: *v2beta1.HelmRelease"}
{"level":"info","ts":"2023-06-15T23:11:58.828Z","msg":"Starting EventSource","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","source":"kind source: *v1beta2.HelmChart"}
{"level":"info","ts":"2023-06-15T23:11:58.828Z","msg":"Starting Controller","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease"}
{"level":"info","ts":"2023-06-15T23:11:58.930Z","msg":"Starting workers","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","worker count":4}
{"level":"info","ts":"2023-06-15T23:16:27.256Z","msg":"HelmChart 'bxcp-system/default-nginx-testing-1' is not ready","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"0a81762c-f7e4-4157-9cee-6d6ca0498b69"}
{"level":"debug","ts":"2023-06-15T23:16:27.256Z","logger":"events","msg":"HelmChart 'bxcp-system/default-nginx-testing-1' is not ready","type":"Normal","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1104"},"reason":"info"}
{"level":"info","ts":"2023-06-15T23:16:27.268Z","msg":"reconcilation finished in 38.1457ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"0a81762c-f7e4-4157-9cee-6d6ca0498b69"}
{"level":"debug","ts":"2023-06-15T23:16:28.174Z","logger":"events","msg":"Helm install has started","type":"Normal","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1109"},"reason":"info"}
{"level":"debug","ts":"2023-06-15T23:21:28.873Z","logger":"events","msg":"Helm install failed: context deadline exceeded\n\nLast Helm logs:\n\n","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1109"},"reason":"error"}
{"level":"debug","ts":"2023-06-15T23:21:28.873Z","logger":"events","msg":"reconciliation failed: Helm install failed: context deadline exceeded","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1109"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:28.886Z","msg":"reconcilation finished in 5m0.726131s, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"4c28e2ad-2e2d-4e64-8ca5-a46b89086b1d"}
{"level":"error","ts":"2023-06-15T23:21:28.886Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"4c28e2ad-2e2d-4e64-8ca5-a46b89086b1d","error":"Helm install failed: context deadline exceeded","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:21:28.900Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1715"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:28.930Z","msg":"reconcilation finished in 44.1972ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"204fabd9-977b-4be7-8574-4c557b58a4c5"}
{"level":"error","ts":"2023-06-15T23:21:28.930Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"204fabd9-977b-4be7-8574-4c557b58a4c5","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:21:29.644Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1718"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:29.654Z","msg":"reconcilation finished in 17.8927ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"5614902c-69a9-4c42-8c19-7c14b77f1dee"}
{"level":"error","ts":"2023-06-15T23:21:29.654Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"5614902c-69a9-4c42-8c19-7c14b77f1dee","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:21:32.667Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1720"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:32.677Z","msg":"reconcilation finished in 22.4546ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"bc660ef4-1e40-42d4-a7d8-4bf92f371d1f"}
{"level":"error","ts":"2023-06-15T23:21:32.677Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"bc660ef4-1e40-42d4-a7d8-4bf92f371d1f","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:21:38.687Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1723"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:38.698Z","msg":"reconcilation finished in 19.9074ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"7cc001b6-551a-457e-9983-eff6cbfa904e"}
{"level":"error","ts":"2023-06-15T23:21:38.698Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"7cc001b6-551a-457e-9983-eff6cbfa904e","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:21:50.720Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1738"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:21:50.737Z","msg":"reconcilation finished in 36.8876ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"c5092ff0-885c-4e2e-bcad-feee3b3e8b75"}
{"level":"error","ts":"2023-06-15T23:21:50.737Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"c5092ff0-885c-4e2e-bcad-feee3b3e8b75","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:22:14.748Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1760"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:22:14.788Z","msg":"reconcilation finished in 50.2202ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"43785a61-7a45-4466-bb05-d7c569fdb0ff"}
{"level":"error","ts":"2023-06-15T23:22:14.788Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"43785a61-7a45-4466-bb05-d7c569fdb0ff","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}
{"level":"debug","ts":"2023-06-15T23:23:02.803Z","logger":"events","msg":"reconciliation failed: install retries exhausted","type":"Warning","object":{"kind":"HelmRelease","namespace":"default","name":"nginx-testing-1","uid":"ba9618a1-fc7c-4800-ab31-a35489bf5500","apiVersion":"helm.toolkit.fluxcd.io/v2beta1","resourceVersion":"1805"},"reason":"error"}
{"level":"info","ts":"2023-06-15T23:23:02.818Z","msg":"reconcilation finished in 28.1489ms, next run in 10s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"d8b16583-71d8-42ce-9615-f1b3a826fa2a"}
{"level":"error","ts":"2023-06-15T23:23:02.818Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"nginx-testing-1","namespace":"default"},"namespace":"default","name":"nginx-testing-1","reconcileID":"d8b16583-71d8-42ce-9615-f1b3a826fa2a","error":"install retries exhausted","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226"}

Below is the tomcat pod log. You might be confused because nginx is included in the name, but it is tomcat.
kubectl logs -f default-nginx-testing-1-tomcat-86c9545c98-mhh72
tomcat 23:16:54.24
tomcat 23:16:54.24 Welcome to the Bitnami tomcat container
tomcat 23:16:54.24 Subscribe to project updates by watching https://github.com/bitnami/containers
tomcat 23:16:54.24 Submit issues and feature requests at https://github.com/bitnami/containers/issues
tomcat 23:16:54.24
tomcat 23:16:54.24 INFO  ==> ** Starting tomcat setup **
tomcat 23:16:54.26 INFO  ==> Configuring port numbers
tomcat 23:16:54.26 INFO  ==> Creating Tomcat user
tomcat 23:16:54.27 INFO  ==> Ensuring Tomcat directories exist
tomcat 23:16:54.27 INFO  ==> Deploying Tomcat from scratch
tomcat 23:16:54.32 INFO  ==> ** tomcat setup finished! **

tomcat 23:16:54.32 INFO  ==> ** Starting Tomcat **
15-Jun-2023 23:16:54.708 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name:   Apache Tomcat/10.1.9
15-Jun-2023 23:16:54.712 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          May 9 2023 14:30:05 UTC
15-Jun-2023 23:16:54.712 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: <IP_ADDRESS>
15-Jun-2023 23:16:54.712 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Linux
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            5.15.49-linuxkit
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:             /opt/bitnami/java
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version:           17.0.7+7-LTS
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:            BellSoft
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:         /opt/bitnami/tomcat
15-Jun-2023 23:16:54.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:         /opt/bitnami/tomcat
15-Jun-2023 23:16:54.722 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/opt/bitnami/tomcat/conf/logging.properties
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:+UseG1GC
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dfile.encoding=UTF-8
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.net.preferIPv4Stack=true
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.net.preferIPv4Addresses=true
15-Jun-2023 23:16:54.723 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Duser.home=/opt/bitnami/tomcat
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/opt/bitnami/tomcat
15-Jun-2023 23:16:54.724 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/opt/bitnami/tomcat
15-Jun-2023 23:16:54.729 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/opt/bitnami/tomcat/temp
15-Jun-2023 23:16:54.731 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent An older version [1.2.37] of the Apache Tomcat Native library is installed, while Tomcat recommends a minimum version of [2.0.1]
15-Jun-2023 23:16:54.732 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.37] using APR version [1.7.4].
15-Jun-2023 23:16:54.733 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1n  15 Mar 2022]
15-Jun-2023 23:16:54.911 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
15-Jun-2023 23:16:54.927 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [381] milliseconds
15-Jun-2023 23:16:54.953 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
15-Jun-2023 23:16:54.953 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.1.9]
15-Jun-2023 23:16:54.959 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/bitnami/tomcat/webapps/manager]
15-Jun-2023 23:16:55.253 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Jun-2023 23:16:55.294 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/bitnami/tomcat/webapps/manager] has finished in [336] ms
15-Jun-2023 23:16:55.294 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/bitnami/tomcat/webapps/host-manager]
15-Jun-2023 23:16:55.392 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Jun-2023 23:16:55.394 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/bitnami/tomcat/webapps/host-manager] has finished in [100] ms
15-Jun-2023 23:16:55.394 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/bitnami/tomcat/webapps/docs]
15-Jun-2023 23:16:55.471 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Jun-2023 23:16:55.472 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/bitnami/tomcat/webapps/docs] has finished in [78] ms
15-Jun-2023 23:16:55.473 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/bitnami/tomcat/webapps/ROOT]
15-Jun-2023 23:16:55.544 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Jun-2023 23:16:55.545 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/bitnami/tomcat/webapps/ROOT] has finished in [72] ms
15-Jun-2023 23:16:55.545 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/bitnami/tomcat/webapps/examples]
15-Jun-2023 23:16:55.685 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Jun-2023 23:16:55.707 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/bitnami/tomcat/webapps/examples] has finished in [162] ms
15-Jun-2023 23:16:55.709 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
15-Jun-2023 23:16:55.719 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [791] milliseconds

Additionally, if I use the helm command to install the chart in the same repository, the status looks correct. Some information has been covered with garbage information.
The storage under the harbor name is the same storage used above.
$ helm repo list
NAME                    URL
prometheus-community    https://prometheus-community.github.io/helm-charts
stable                  https://charts.helm.sh/stable
ingress-nginx           https://kubernetes.github.io/ingress-nginx
harbor                  https://xxxxxxxxxx:0000/chartrepo/bxcp-system-common
argo                    https://argoproj.github.io/argo-helm
member-harbor           https://yyyyyyyyyy:0000/chartrepo/bxcp-system-common
$ helm install taiga-1026 harbor/tomcat
NAME: taiga-1026
LAST DEPLOYED: Fri Jun 16 09:50:14 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: tomcat
CHART VERSION: 10.9.2
APP VERSION: 10.1.9

** Please be patient while the chart is being deployed **

1. Get the Tomcat URL by running:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w taiga-1026-tomcat'

  export SERVICE_IP=$(kubectl get svc --namespace default taiga-1026-tomcat --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
  echo "Tomcat URL:            http://$SERVICE_IP/"
  echo "Tomcat Management URL: http://$SERVICE_IP/manager"

2. Login with the following credentials

  echo Username: user
  echo Password: $(kubectl get secret --namespace default taiga-1026-tomcat -o jsonpath="{.data.tomcat-password}" | base64 -d)
$ helm history taiga-1026
REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri Jun 16 09:50:14 2023        deployed        tomcat-10.9.2   10.1.9          Install complete

Can you please try increasing the timeout configuration on the HelmChart? 5 minutes matches the default time-out.

Would you be able to share the chart with me?

Would you be able to share the chart with me? Can be via email<EMAIL_ADDRESS>
OK
I sent email, Subject is "[tomcat chart] hi this is my chart"

I tested the chart you provided, and I suspect it times out because the LoadBalancer does not get an external IP assigned.
$ kubectl get service
NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-testing-1-tomcat    LoadBalancer   <IP_ADDRESS>    <pending>     80:31829/TCP   13m

This is confirmed by changing the .spec of the HelmRelease to include:
spec:
  install:
    disableWait: true
  upgrade:
    disableWait: true

which yields a successful install.

nice to see the answer I also avoided the problem once through the settings you showed.
However, what I'm curious about is that the result of installing with the install subcommand with the helm binary command and the result of installing with the HelmRelease resource are different.
If you install both with the same values.yaml spec, they should be in the same state, but they are not
Is the reason for this result because the application of helmrelease resources is still in the development stage?

Helm would have given you the same behavior if you run helm install with the --wait flag. Which is the default the controller runs with, as we want to be sure the resources are successfully deployed by default.

Helm would have given you the same behavior if you run helm install with the --wait flag. Which is the default the controller runs with, as we want to be sure the resources are successfully deployed by default.

I didn't explore the options in detail
I misunderstood. sorry
Thank you so much for your sincere answer


add docs for new property no_editor

followup for #674

@halzy I find it unfortunate that people can not search the docs for property to find this documentation :(

@halzy I find it unfortunate that people can not search the docs for property to find this documentation :(

@extrawurst I often feel lost in the documentation. I think the book does a good job filling in, perhaps the book needs more for the macros.

@extrawurst I often feel lost in the documentation. I think the book does a good job filling in, perhaps the book needs more for the macros.


text-input: Don't reject enable requests when unfocused

The prevoius implementation would always raise an error in the following sequence:

→ enter
→ leave
← enable

The text-input type is not equipped to manage the validity of clents' requests, which should be handled in the compositor, as rootston does.
There is one scenario where this error should stay; namely immediately after creating the text input, but handling it introduces additional state and complexity, so I decided against it.
This should also make terminals work again, fixing https://gitlab.gnome.org/GNOME/gtk/merge_requests/369 from the other side.

Thanks!

Thanks for the quick merge!


use of min(int, size_t) causes ambiguity with clang

at https://github.com/ROCm/hipBLASLt/blob/develop/library/src/amd_detail/rocblaslt/src/tensile_host.cpp#L2923
and https://github.com/ROCm/hipBLASLt/blob/develop/library/src/amd_detail/rocblaslt/src/tensile_host.cpp#L2898
there is code
auto algoCount       = min(requestedAlgoCount, solutions.size());

requestedAlgoCount is int type, solutions.size() is size_t (unsigned long) type. This causes compilation error for clang trunk due to recent PR (https://github.com/llvm/llvm-project/pull/82956) and is blocking the fix gets into amd-staging branch.
To fix this, change  https://github.com/ROCm/hipBLASLt/blob/develop/library/src/amd_detail/rocblaslt/src/tensile_host.cpp#L2923
and https://github.com/ROCm/hipBLASLt/blob/develop/library/src/amd_detail/rocblaslt/src/tensile_host.cpp#L2898 to be
auto algoCount       = min(static_cast<size_t>(requestedAlgoCount), solutions.size());

Hi @yxsamliu,
Thanks for the suggestion, this has been changed as you suggested here. Thanks!


Session history doesn't strip spaces from entries

When commands are added to the session history - leading, trailing and duplicate spaces are not removed.
This causes too problems:

The suggestions drop-down displays duplicate entries (with redundant spaces removed). See example screenshot attached.
If you select/click on a suggestion entry with redundant spaces the command is displayed with redundant spaces.

See suggest fix submitted in PR #264.


[Redis] refactoring and improvements

What's being changed:

Refactors client code into client.py
Clarifies code and improve README
Testing around Bearer authentication scenarios.
Testing around /search endpoint scenarios.
Testing search client methods are called correctly on success/fail
Conftest file for all the mocking. Includes unauthenticated and authenticated clients and mocking several client methods.

How did you test this change (include any code snippets, API requests, screenshots, or gifs):
Tested locally

@EugeneLightsOn looks like there are some formatting issues blocking this PR

Thank you @walterbm-cohere. Those issues are not related to this PR. I believe it's related to the black version. Please take a look at this PR: https://github.com/cohere-ai/quick-start-connectors/pull/130


STORM-1735: Nimbus should log that replication succeeded when min rep…

…licas was reached exactly

+1 Nice finding.
@srdo I could cherry-pick into 1.x-branch since changeset is really small but then merging should wait to release 1.0.1. Could you craft pull request against 1.x-branch if you really don't mind?

@HeartSaVioR Sure, please do :)


Devcontainer support

I am working on adding support for the Restore and Restore 2 if possible, and as part of that I set up my local version of the repository to allow me to easily develop and debug it using vscode and devcontainers.
Rather than deleting those files when I'm done, I thought it might be better to submit them as a PR so that you can consider whether or not you'd like to include it in the main repo.
These changes are developer-facing quality-of-life improvements and wouldn't affect the actual custom component in any way.
Using these changes, simply starting the devcontainer (which vscode should offer to do automatically) will install homeassistant in a Docker container and give it access to the custom component. Then, running the "Run Home Assistant on port 8123" task in vscode starts HA and opens a port from the devcontainer so that you can visit http://localhost:8123 to test the custom component.
Feel free to change how I've set this up, or just reject it entirely if you're not interested in supporting devcontainer-based development.
Thanks for considering these changes!

what benefit does the devcontainer provide? do you get debuggable break points?

Yes, you can debug with breakpoints, and it provides a very quick way to get a consistent environment and toolset for anyone using vscode. It actually opens the folder inside the container automatically, and the entire IDE runs inside the container so you have full access to the Linux environment and installed toolset. More info here.
It could potentially be easy for someone to use the same docker container even with an IDE that doesn't support devcontainers themselves. In my PR I'm referencing a standard prebuilt docker image, but a Dockerfile or docker-compose file could be included either instead of that standard image, or in addition to it as another option.
I believe JetBrains said they were working on adding support for devcontainer files to the IntellIJ platform, but I don't know what their timeline is.

I'll check it out this weekend, but break points would be great 👍

I couldn't get the debugger to attach, but got the container working with ha and the custom component. When I have more time I'll try again, but I don't mind the clutter if it helps others.

Thank you!


Add more documentation and examples for customizing the config

Adding examples for config customizations such as:

Scrape a new metric source
Scrape a new log source
Scrape using a ServiceMonitor

This is now done.


[#94939334] Create dedicated gandalf playbook

Manage all Ansible dependencies from Ansible Galaxy
What
This PR is to split out the gandalf playbook from our tsuru-ansible repository into it's own dedicated Github repository.
How to review this PR
This PR should be reviewed in the following context:

I want to move the existing gandalf playbook from out of the role-static directory,
I no longer want the other playbooks so I am deleting the roles-static directory,
I want to inform interested parties of the license this software and the terms of it's re-use,
I want to be able to insert this playbook into ansible galaxy at a future date.

Who should review this PR

Anyone in the core team.
I paired with @dhilton with this one so he can't merge it :tongue:

We talked about using git filter-branch to split the repo where this came from so we don't lose all the history of what we've previously done to this module. Is there a reason you decided not to do that?

I did use git-filter-branch have you checked master ?

You're absolutely right, I did not look at master :) That'll teach me for looking quickly on my way into work. Sorry!
In that case, this is great. One tiny comment.


Custom Dashboards: Variables and Filtering

https://www.notion.so/rilldata/Passing-arguments-in-Custom-Dashboard-88a274c7c48c44dc8980c00e24d64ad7

Here is a POC branch: https://github.com/rilldata/rill/tree/feat/dynamicfilters
I would expect that we need new runtime endpoints. The POC takes a fairly naive approach to resolving a resource based on some input params.
The things that were outstanding in POC were wiring up the custom dash to dispatch only required params to components as well as setting up some store to manage it client side.

Variables closed via #5301
Filtering being tracked in #5448


False down report on ipv4 tcp-ping

Description
False down report on ipv4 tcp-ping
Below is a part of the Action log.
2023-12-14T02:16:56.1664336Z Checking <IP_ADDRESS>
2023-12-14T02:16:56.1702316Z Current status main-server down 2023-06-01T23:15:18.000Z
2023-12-14T02:16:56.1704665Z Using tcp-ping instead of curl
2023-12-14T02:16:56.2540081Z ERROR Got pinging error Error: queryA ENOTFOUND <IP_ADDRESS>
2023-12-14T02:16:56.2542043Z     at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/promises:240:17) {
2023-12-14T02:16:56.2543431Z   errno: undefined,
2023-12-14T02:16:56.2544679Z   code: 'ENOTFOUND',
2023-12-14T02:16:56.2545431Z   syscall: 'queryA',
2023-12-14T02:16:56.2546109Z   hostname: '<IP_ADDRESS>'
2023-12-14T02:16:56.2546868Z }

To Reproduce
Monitor an endpoint using tcp-ping and ipv4.
This does not happen when using an actual url so that dns.promises.resolve4(url) has to run.
Additional context
My Upptime Instance is public. You can check it out to see the current config.
I'm no expert but I suspect that the check isIP(url) (https://github.com/upptime/uptime-monitor/blob/cf6ed7bbc149a58e9d1146a975f43b07d326576e/src/update.ts#L160) may always return false, in which case even an ipv4 would be fed into dns.resolve4(...) which would obviously lead to a lookup error.
I just can't explain why isIP(...) should fail, unless url isn't provided correctly.

I'm encountering the same issue. The server is online however tcp-ping reports it as offline
Link to my instance repo

We just pushed an update, hopefully this should fix it!

Updating Upptime to v1.34.1 solved the issue. Thanks!
Do you know if there is any way to make this not count towards the uptime percentage on the status webpage? Thanks again

Can confirm that 1.34.1 fixed that issue.
Thx for the quick fix :)

Do you know if there is any way to make this not count towards the uptime percentage on the status webpage?

I think the easiest would be to manually delete the issue.

I think the easiest would be to manually delete the issue.

Thank you for your reply.
Deleting the issues does remove them from the past incidents on the status web page, however the uptime percentage is still impacted (it should be 100%). Any way to fix that? Thanks again

Hmm you're right. Since it's in the git commit history, I can't think of any easy way to fix the uptime number except for deleting the .yml files, adding the slug property for the sites so that new, renamed .yml files are created, and running "Update CI" manually, which will restart the commit history from the beginning. I know this is not great :(


Health check for sidekicks having networkFrom primary service

We should add support for defining health check for the sidekicks using network from main container.

Tested with rancher server version - v1.6.8-rc1 with rancher/healthcheck:v0.3.2.
Deployed services having health check enabled for sidekick containers (with networkFrom primary service).
When the sidekick containers become unhealthy (In my case , I made the health check url become unavailable so that the health check url gets "404" ) , they continue to be in "healthy" state.
Sidekick containers are being monitored for health by only 1 host , when the primary container is monitored by 2 hosts.
The host that was monitoring the container's health has reported the container as being "DOWN". But container continues to be in "healthy" state.

mysql> select * from service_event where instance_id = 204;
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
| id   | name | account_id | kind         | uuid                                 | description | state   | created             | removed | remove_time | data | host_id | healthcheck_uuid                                                            | instance_id | healthcheck_instance_id | reported_health | external_timestamp |
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
| 1898 | NULL |          5 | serviceEvent | 62086294-ddfe-4f96-ba55-a01436f8a8c6 | NULL        | created | 2017-08-14 20:27:43 | NULL    | NULL        | {}   |       1 | 2c874d5b-d7de-46b5-bb27-a004c9bb6e9f_1d41aec2-2df1-4fae-a2ab-38c5b1c209c9_1 |         204 |                      97 | INIT            |<PHONE_NUMBER> |
| 1899 | NULL |          5 | serviceEvent | a1063ed2-2be2-42f2-bd7c-63e6cb959ea9 | NULL        | created | 2017-08-14 20:27:45 | NULL    | NULL        | {}   |       1 | 2c874d5b-d7de-46b5-bb27-a004c9bb6e9f_1d41aec2-2df1-4fae-a2ab-38c5b1c209c9_1 |         204 |                      97 | UP              |<PHONE_NUMBER> |
| 1900 | NULL |          5 | serviceEvent | a2e547ad-fae9-4a5a-86a9-7e1a78478251 | NULL        | created | 2017-08-14 20:41:44 | NULL    | NULL        | {}   |       1 | 2c874d5b-d7de-46b5-bb27-a004c9bb6e9f_1d41aec2-2df1-4fae-a2ab-38c5b1c209c9_1 |         204 |                      97 | DOWN            |<PHONE_NUMBER> |
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
3 rows in set (0.00 sec)

mysql> select * from service_event where instance_id = 203;
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
| id   | name | account_id | kind         | uuid                                 | description | state   | created             | removed | remove_time | data | host_id | healthcheck_uuid                                                            | instance_id | healthcheck_instance_id | reported_health | external_timestamp |
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
| 1892 | NULL |          5 | serviceEvent | 1c8de67d-e305-482b-afa0-f5be1654932c | NULL        | created | 2017-08-14 20:27:38 | NULL    | NULL        | {}   |       3 | ba3d2403-e729-49c9-bc2a-59ed8b4c11d2_cb4b4fa2-9018-4a1e-8062-d93840a07c59_1 |         203 |                      96 | INIT            |<PHONE_NUMBER> |
| 1893 | NULL |          5 | serviceEvent | c1a43c8d-54c5-402e-be5a-74e0557077a9 | NULL        | created | 2017-08-14 20:27:39 | NULL    | NULL        | {}   |       1 | 2c874d5b-d7de-46b5-bb27-a004c9bb6e9f_cb4b4fa2-9018-4a1e-8062-d93840a07c59_1 |         203 |                      96 | INIT            |<PHONE_NUMBER> |
| 1895 | NULL |          5 | serviceEvent | ac1b55bb-eca5-4fde-9011-6008bc311cd3 | NULL        | created | 2017-08-14 20:27:40 | NULL    | NULL        | {}   |       3 | ba3d2403-e729-49c9-bc2a-59ed8b4c11d2_cb4b4fa2-9018-4a1e-8062-d93840a07c59_1 |         203 |                      96 | UP              |<PHONE_NUMBER> |
| 1897 | NULL |          5 | serviceEvent | c19d525b-e6b0-4884-8037-f9a6b91a1030 | NULL        | created | 2017-08-14 20:27:41 | NULL    | NULL        | {}   |       1 | 2c874d5b-d7de-46b5-bb27-a004c9bb6e9f_cb4b4fa2-9018-4a1e-8062-d93840a07c59_1 |         203 |                      96 | UP              |<PHONE_NUMBER> |
+------+------+------------+--------------+--------------------------------------+-------------+---------+---------------------+---------+-------------+------+---------+-----------------------------------------------------------------------------+-------------+-------------------------+-----------------+--------------------+
4 rows in set (0.00 sec)

When health check is enabled only in sidekick containers , then sidekick containers are stuck in "Initializing" state forever.
version: '2'
services:
  test2:
    image: sangeetha/testclient
    stdin_open: true
    tty: true
    labels:
      io.rancher.container.pull_image: always
      io.rancher.sidekicks: test3
  test3:
    image: sangeetha/testnewhostrouting
    stdin_open: true
    network_mode: container:test2
    tty: true

version: '2'
services:
  test2:
    scale: 1
    start_on_create: true
  test3:
    scale: 1
    start_on_create: true
    health_check:
      healthy_threshold: 2
      response_timeout: 2000
      port: 81
      unhealthy_threshold: 3
      initializing_timeout: 60000
      interval: 2000
      strategy: recreate
      request_line: GET "/service3.html" "HTTP/1.0"
      reinitializing_timeout: 60000

No hosts monitor the health of the sidekick containers in this case.

Tested with rancher server version - v1.6.8-rc4 with rancher/healthcheck:v0.3.3.

Deployed services having health check enabled for sidekick containers (with networkFrom primary service). sidekick containers get to "healthy" state as expected.

When the sidekick containers become unhealthy (In my case , brought down the host in which instance was running ) , they get recreated successfully on different hosts and get to "healthy" state.

Deployed services having health check enabled for primary and sidekick containers (with networkFrom primary service). Both primary and sidekick containers get to "healthy" state as expected.

When the sidekick containers become unhealthy (In my case , brought down the host in which instance was running ) , they get recreated successfully on different hosts and get to "healthy" state.

Deployed services having health check enabled for multiple sidekick containers (with networkFrom primary service). All health check enabled sidekick containers get to "healthy" state as expected.

When the sidekick containers become unhealthy (In my case , brought down the host in which instance was running ) , they get recreated successfully on different hosts and get to "healthy" state.


DiscordJS 11.5 Update

DiscordJS was recently updated to 11.5, which you can read more about here: https://github.com/discordjs/discord.js/releases/tag/11.5.0

Bumped DiscordJS to 11.5 in commit 6e7200cd3ea08b26f1ff6ebea6357b484c079f12.


[t-mr1] vendor: Add SEpolicy for AIDL QTI camera provider

New QTI camera provider is used by k5.15+ devices.
Add vendor.qti.camera.provider-service_64 to file_contexts.
Also add permissions for AON and PostProc camera services.

@jerpelea after merging this change, a rebuild of ODM is required to apply label to new service


Change: remove token expiration

Because, we decided to invalidate the token at the end of the festival,
instead of token expiration.

THIS ISN'T TESTED YET.
I can't test because I have to merge the #10 before test it.
So, Please fix #10 first, then let's talk about this.


Not compatible with the current version (242.*)

Plugin 'Moonlight Dark Theme' (version '1.7') is not compatible with the current version of the IDE,
because it requires build 241.* or older but the current build is WS-242.20224.342

looks like the code on main already supports 2024.2:  https://github.com/franmc01/jetbrains-moonlight-theme/commit/877b82646fecbf7d30292227cf6d97aa2cbc7a81
could you release a new version, please @franmc01 Thanks!

The code looks compatible and we need a release. It is broken on my IDEs.

@franmc01 :+1: for a 1.8 release!

For those - like me - who are waiting for a plugin update: In the meantime you can use abdelhalimjean's 1.8 release and install it from the .jar file: https://github.com/abdelhalimjean/jetbrains-moonlight-theme/releases/tag/v1.8


Update ssh_pub_keys.yml

needs a rebase now. sorry

You are currently not in the Github group SUSE-Cloud, should that be changed?

Can you rebase your single commit instead of adding the merge commit please?


k8s conformance fails with istio deployed due to istio-ca-root-cert configMap

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
Clusters with Istio deployed fail to run k8s conformance tests, the following test fails:
ResourceQuota should create a ResourceQuota and capture the life of a configMap
example run:
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirtci/536/check-provision-k8s-1.20/1367782808793124864
/workspace/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/framework/framework.go:629
Mar  5 11:07:41.670: Unexpected error:
    <*errors.StatusError | 0xc001452500>: {
        ErrStatus: {
            TypeMeta: {Kind: "", APIVersion: ""},
            ListMeta: {
                SelfLink: "",
                ResourceVersion: "",
                Continue: "",
                RemainingItemCount: nil,
            },
            Status: "Failure",
            Message: "configmaps \"test-configmap\" is forbidden: exceeded quota: test-quota, requested: configmaps=1, used: configmaps=2, limited: configmaps=2",
            Reason: "Forbidden",
            Details: {
                Name: "test-configmap",
                Group: "",
                Kind: "configmaps",
                UID: "",
                Causes: nil,
                RetryAfterSeconds: 0,
            },
            Code: 403,
        },
    }
    configmaps "test-configmap" is forbidden: exceeded quota: test-quota, requested: configmaps=1, used: configmaps=2, limited: configmaps=2
occurred
/workspace/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/apimachinery/resource_quota.go:336

[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
Steps to reproduce the bug
conformance.json:
{
  "Description": "DEFAULT",
  "UUID": "c3bc7d76-6ce8-4c8a-8bcb-5c7ae5fb22a3",
  "Version": "v0.20.0",
  "ResultsDir": "/tmp/sonobuoy",
  "Resources": [
    "apiservices",
    "certificatesigningrequests",
    "clusterrolebindings",
    "clusterroles",
    "componentstatuses",
    "configmaps",
    "controllerrevisions",
    "cronjobs",
    "customresourcedefinitions",
    "daemonsets",
    "deployments",
    "endpoints",
    "ingresses",
    "jobs",
    "leases",
    "limitranges",
    "mutatingwebhookconfigurations",
    "namespaces",
    "networkpolicies",
    "nodes",
    "persistentvolumeclaims",
    "persistentvolumes",
    "poddisruptionbudgets",
    "pods",
    "podlogs",
    "podsecuritypolicies",
    "podtemplates",
    "priorityclasses",
    "replicasets",
    "replicationcontrollers",
    "resourcequotas",
    "rolebindings",
    "roles",
    "servergroups",
    "serverversion",
    "serviceaccounts",
    "services",
    "statefulsets",
    "storageclasses",
    "validatingwebhookconfigurations",
    "volumeattachments"
  ],
  "Filters": {
    "Namespaces": ".*",
    "LabelSelector": ""
  },
  "Limits": {
    "PodLogs": {
      "Namespaces": "",
      "SonobuoyNamespace": true,
      "FieldSelectors": [],
      "LabelSelector": "",
      "Previous": false,
      "SinceSeconds": null,
      "SinceTime": null,
      "Timestamps": false,
      "TailLines": null,
      "LimitBytes": null,
      "LimitSize": "",
      "LimitTime": ""
    }
  },
  "QPS": 30,
  "Burst": 50,
  "Server": {
    "bindaddress": "<IP_ADDRESS>",
    "bindport": 8080,
    "advertiseaddress": "",
    "timeoutseconds": 10800
  },
  "Plugins": [
    {
      "name": "e2e"
    },
    {
      "name": "systemd-logs"
    }
  ],
  "PluginSearchPath": [
    "./plugins.d",
    "/etc/sonobuoy/plugins.d",
    "~/sonobuoy/plugins.d"
  ],
  "Namespace": "sonobuoy",
  "WorkerImage": "sonobuoy/sonobuoy:v0.20.0",
  "ImagePullPolicy": "IfNotPresent",
  "ImagePullSecrets": "",
  "ProgressUpdatesPort": "8099"
}

curl -L "https://github.com/vmware-tanzu/sonobuoy/releases/download/v0.20.0/sonobuoy_0.20.0_linux_amd64.tar.gz" | tar -xz
./sonobuoy run --wait --e2e-focus ResourceQuota --config conformance.json

# check logs of sonobuoy-e2e pod
kubectl logs sonobuoy-e2e-job -n sonobuoy -c e2e

Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
istioctl version --remote
client version: 1.9.0
control plane version: 1.9.0
data plane version: 1.9.0 (2 proxies)

kubectl version --short
Client Version: v1.20.2
Server Version: v1.20.2

How was Istio installed?
istioctl install --set profile=demo \
  --set components.cni.enabled=true \
  --set values.cni.chained=true \
  --set values.cni.cniBinDir=/opt/cni/bin \
  --set values.cni.cniConfDir=/etc/cni/net.d \
  --set values.global.jwtPolicy=first-party-jwt

Environment where the bug was observed (cloud vendor, OS, etc)
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Kubernetes ships with a controller doing the ~exact same thing (kube-root-ca.crt) now. I wonder how that passes but ours doesn't?

Oh I guess they allow 2 configmaps so probably that allows for theirs?

I am not sure what we can do here. It seems like the test should change. Its perfectly valid for us to write a configmap


get_predictor only find the first satellite in the TLE file

Hiya,
I'm trying to write some code to see what satellites are overhead. So the idea is to have a large TLE file with multiple spacecraft in. Then get the next aos and los of each one, checking to see if the current time is within the aos and los. However, I seem to have an issue when trying to look at anything other than the first spacecraft in the TLE file.
Example code:
from orbit_predictor.sources import EtcTLESource
from orbit_predictor.locations import ARG
from datetime import datetime

TLE_file = "/home/abc/tle.txt"
source = EtcTLESource(filename=TLE_file)

spacecraft_names = []
line_count = 0
with open(TLE_file) as tle:
  for line in tle:
    if line.rstrip():
      if line_count==0:
        spacecraft_names.append(line.rstrip())
      elif line_count==2:
        line_count=-1
      line_count += 1

for spacecraft in spacecraft_names:
  print (spacecraft)
  predictor = source.get_predictor(spacecraft)

  predicted_pass = predictor.get_next_pass(ARG)
  print (predicted_pass)

  now = datetime.utcnow()
  if now < predicted_pass.aos:
    print ('not yet')
  elif predicted_pass.aos < now < predicted_pass.los:
    print (spacecraft, ' currently overhead')

Any ideas if this is something I'm doing wrong or an issue?
Thanks
(Edit: Code formatting)

Hi @robbo4, thanks for your interest in orbit-predictor? Could you please tell us what's the issue you're finding?

The issue is that EtcTLESource just reads the first 3 lines for a TLE, as it is meant to be used on board to know what the current TLE is. To support mutltiple satellites in one file please use NoradTLESource.
I will close the issue now, re open it if it does not work.

Ahh yes. You are correct. Thank you.
Can anyone give me an example of how NoradTLESource can be used? I'm currently not sure what 'content' is.
Thanks

Try using one of the two constructor class methods:
NoradTLESource.from_url(url) or NoradTLESource.from_file(filename)
You can see from the code that content is a list of lines(strings) of a norad like tle file.

Ahhh. Perfect, thanks.


Readme improvements

Orient the readme a bit more for someone that doesn't know what
Foodcritic does or how to use it.
Signed-off-by: Tim Smith<EMAIL_ADDRESS>

👍


Seperate "auto-regeneration" code from site

If we pulled the data we're feeding into the site away from all the logic, we could maintain "pisoc.net data" and the wierd-cms like thing we've created as seperate projects

Done, finally


Add option to disable rendering of problems in scrollbar

Issue Type: Feature Request
The "problems" generated by the language extension are rendered as green/orange/red rectangles in the scrollbar on relevan files.  I'd like the option to disable this.  In my case, I'm editing code that already has many "problems" and they polute the scrollbar and make it hard to see the other contributions in the scrollbar, e.g., the file diff.  This is the case even though they are in different "columns" of the scrollbar.
VS Code version: Code 1.21.1 (79b44aa704ce542d8ca4a3cc44cfca566e7720f1, 2018-03-14T14:39:09.335Z)
OS version: Darwin x64 17.4.0

"editor.scrollbar.verticalScrollbarSize": 30,
"workbench.colorCustomizations": {
    "editorOverviewRuler.errorForeground": "#0000",
    "editorOverviewRuler.warningForeground": "#0000",
}

Oh, clever.  Still there should probably be a setting for this

+1
Rendering of problems / errors should be optional, especially since most (all?) spellcheck extensions produce large amounts of nonsensical warnings when editing complex files (say Latex documents).

The solution is the one proposed by @usernamehw -- https://github.com/microsoft/vscode/issues/46201#issuecomment-374720926

"editor.scrollbar.verticalScrollbarSize": 30,
"workbench.colorCustomizations": {
    "editorOverviewRuler.errorForeground": "#0000",
    "editorOverviewRuler.warningForeground": "#0000",
}

None of these work for me, I still have spelling mistakes ("infos" type problems) decorated in the ruler:
Version: 1.39.2 (user setup)
Commit: 6ab598523be7a800d7f3eb4d92d7ab9a66069390
Date: 2019-10-15T15:35:18.241Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

Cannot there simply be an option to disable them?


add support to disable the transition style for special UINavigationController or UIViewController

and also fix the transition navigation bar ui style bug when set multiple Controllers


[release/1.4] Update Go to 1.16.14

Update Go to 1.16.14
Includes security fixes for crypto/elliptic (CVE-2022-23806), math/big (CVE-2022-23772),
and cmd/go (CVE-2022-23773).
go1.16.14 (released 2022-02-10) includes security fixes to the crypto/elliptic,
math/big packages and to the go command, as well as bug fixes to the compiler,
linker, runtime, the go command, and the debug/macho, debug/pe, net/http/httptest,
and testing packages. See the Go 1.16.14 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.14+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.16.13...go1.16.14
Update Go to 1.16.13
go1.16.13 (released 2022-01-06) includes fixes to the compiler, linker, runtime,
and the net/http package. See the Go 1.16.13 milestone on our issue tracker for
details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.13+label%3ACherryPickApproved

Not sure if there's gonna be more 1.4.x release, but if so, we may as well have the branch up to date

Just FYI, something has gotten stale on release/1.4 where the ginko/CRI tests no longer work. I tried to dig into it a bit last week and dead ended after finding the same commits are being used elsewhere. Might need someone more versed in the critest project to help figure it out.

Ah, I see it indeed;
ginkgo run failed
    default:   flag provided but not defined: -skipMeasurements

It guess it goes wrong here (as no version is specified); https://github.com/containerd/containerd/blob/18a2715092b9553f5675112da96458be58fd55ff/script/setup/install-critools#L23

Pushed a commit, roughly based on https://github.com/containerd/containerd/commit/6b0e2414c8326554b4c0a1e959d498b7202e17fc (https://github.com/containerd/containerd/pull/6328); let's see if that fixes it.
Did a quick check, and ginkgo 1.16.5 looks to still have that flag;
go install<EMAIL_ADDRESS>#...

ginkgo --help | grep skipMeasurements
  -skipMeasurements

Hmm... now it looks to be failing in vagrant provisioning
==> default: Running provisioner: install-cri-tools (shell)...
    default: Running: inline script
    default: + /root/go/src/github.com/containerd/containerd/script/setup/install-critools
    default: go: modules disabled by GO111MODULE=off; see 'go help modules'
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what

Arf.. by bad; I used GO111MODULES (plural) instead of singular 🤦 - fixed

nice work; I had looked at that commit too; not sure how I decided that wasn't the source of the issue! :) I did see that recent ginko no longer has that flag but probably got distracted with other work before trying to resolve what version we were using!