Container/pod fails after DB schema is created

Describe the bug
Deployment in docker/k8s fails with PSQL
To Reproduce
Steps to reproduce the behavior:

pull docker image with version 1.7.1
deploy with env:

        - name: DJANGO_DB
          value: default
        - name: POSTGRE_NAME
          value: label_studio
        - name: POSTGRE_USER
          value: postgres
        - name: POSTGRE_PASSWORD
          value: <pass>
        - name: POSTGRE_PORT
          value: "5432"
        - name: POSTGRE_HOST
          value: <ip>

check that tables are created in PSSQL
After that container fails
See error

Expected behavior

label studio is able to connect to PSQL a create tables in DB, but after DB inits, it fails to start with log below

Environment (please complete the following information):

OS: K8s on Ubuntu 20.04 LTS server
Label Studio Version 1.7.1

Additional context
│                                                                                │
│ Traceback (most recent call last):                                                                                │
│   File "/usr/local/bin/label-studio", line 33, in <module>                                                                                │
│     sys.exit(load_entry_point('label-studio', 'console_scripts', 'label-studio')())                                                                                │
│   File "/label-studio/label_studio/server.py", line 291, in main                                                                                │
│     _apply_database_migrations()                                                                                │
│   File "/label-studio/label_studio/server.py", line 67, in _apply_database_migrations                                                                                │
│     call_command('migrate', '--no-color', verbosity=0)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/core/management/__init__.py", line 181, in call_command                                                                                │
│     return command.execute(*args, **defaults)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/core/management/base.py", line 398, in execute                                                                                │
│     output = self.handle(*args, **options)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/core/management/base.py", line 89, in wrapped                                                                                │
│     res = handle_func(*args, **kwargs)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/core/management/commands/migrate.py", line 244, in handle                                                                                │
│     post_migrate_state = executor.migrate(                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/migrations/executor.py", line 117, in migrate                                                                                │
│     state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards                                                                                │
│     state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/migrations/executor.py", line 227, in apply_migration                                                                                │
│     state = migration.apply(state, schema_editor)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/migrations/migration.py", line 126, in apply                                                                                │
│     operation.database_forwards(self.app_label, schema_editor, old_state, project_state)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/contrib/postgres/operations.py", line 25, in database_forwards                                                                                │
│     schema_editor.execute(                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/backends/base/schema.py", line 145, in execute                                                                                │
│     cursor.execute(sql, params)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/sentry_sdk/integrations/django/__init__.py", line 577, in execute                                                                                │
│     return real_execute(self, sql, params)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/backends/utils.py", line 66, in execute                                                                                │
│     return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers                                                                                │
│     return executor(sql, params, many, context)                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/backends/utils.py", line 79, in _execute                                                                                │
│     with self.db.wrap_database_errors:                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/utils.py", line 90, in __exit__                                                                                │
│     raise dj_exc_value.with_traceback(traceback) from exc_value                                                                                │
│   File "/usr/local/lib/python3.10/dist-packages/django/db/backends/utils.py", line 84, in _execute                                                                                │
│     return self.cursor.execute(sql, params)                                                                                │
│ django.db.utils.OperationalError: 2023-01-30T18:18:04.948401345+01:00 could not open extension control file "/usr/pgsql-14/share/extension/pg_trgm.control": No such file or directory

What's the version of PgSQL? It is self-hosted?

It is self hosted VM with PSQL 14, I tried it on PSQL 12 which I have in my lab as well. Same result.

seems like your postgresql doesn't have this extension or postgres user doesn't have rights to create extensions

yes, the problem was, that on Cent os there was missing postgresql14-contrib package. It install the extension that is needed: /usr/pgsql-14/share/extension/pg_trgm.control

thanks for that. However for the project DB has to be on the separate VM and stateful set cannot be used.


Touch controller

Adds touch control support to the dynamic camera controller.

@joseph-kaile can you please merge in main to fix the conflicts?
@j9liu any reservations about shipping this in February's release?

@kring No, this can go in the Feburary release. My only reservation came from whether or not users could infer these mobile controls, or if we had to tell them / use UI somehow. But @joseph-kaile says these are standard controls, so I'll take his word for it.

@joseph-kaile do you mind re-merging with main so CI can pass + I can merge this PR?

Thanks @joseph-kaile !


Add sauceconnect formula

@BrewTestBot test this please.

Closing as outdated, but will happily review a fresh submission adhering to Homebrew's more recent style conventions. My apologies this pretty much went dead on our side 😢.


Add Reports for Changes

Start by adding more search fields.
Then allow Users to Save their Searches
Then allow sending those searches out on a schedule if they contain data

This will allow to do a lot of neat things.
Example: Create a report that will only look at Changes in the last day from our Rocky8 Hardening playbook when it is ran in RUN mode against our PROD inventory.

Tracking this via an issue now #22


Create command async submission on the client side

What changes are proposed in this pull request?
Create command async submission on the client side:
Modify distributedCp and distributedLoad to submit commands instead of running job configs.
Modify AbstactDistributedCommand to support command waiting.
Add APIs on the job master client side.
Please clarify why the changes are needed. For instance,

If you propose a new API, clarify the use case for a new API.
Add APIs to job master client: submit and getStatus.

Does this PR introduce any user facing changes?
User will submit a distributed command instead of running all child jobs in a command. User will get a job control id back once command submission is successful. User can have option to wait for a command or not wait for a command to finish.

@yuzhu @jja725 You can skip reviews for the code change on the server side (need them to compile) since they are covered in the other PR.

How about make changes in DistributedLoadUtils rather than DistributedLoad directly

@luzhang6 can we refactor this so it only includes changes in addition to #15241 ? it is very hard to review otherwise..

and also result in lots of conflicts

alluxio-bot, merge this please

Could you update the description of PR about what the command output looks like right now? @luzhang6

How about make changes in DistributedLoadUtils rather than DistributedLoad directly

@yuzhu & @luzhang6 , I guess you two might miss at @JySongWithZhangCe 's comment.  As Ce reported offline, this pr might skip/break the features we've implemented in the DistributedLoadUtils.  any thoughts?

@JySongWithZhangCe Sorry we missed your comment earlier. Do you mind describing what behavior this might break? We can make changes to ensure it still works after this PR.

@JySongWithZhangCe Sorry we missed your comment earlier. Do you mind describing what behavior this might break? We can make changes to ensure it still works after this PR.

Ok~Thx:)
I have submitted 3 PRs that can make it easier to manage table data for Alluxio table users.

https://github.com/Alluxio/alluxio/pull/12741 Add data operation ability on AbstractTableCommand
https://github.com/Alluxio/alluxio/pull/13288 Packaging distributed load code into DistributedLoadUtils
https://github.com/Alluxio/alluxio/pull/14701 Add LoadTableCommand

DistributedLoadUtils is helpful because Alluxio table load command can sync improvement from filesystem distributedLoadUtils.
Whats more, alluxio table load command has become a good partner in muti-cluster data share, and there will be more features.
I think may be I could re-package the new design again in another PR.

@JySongWithZhangCe Sorry we missed your comment earlier. Do you mind describing what behavior this might break? We can make changes to ensure it still works after this PR.

Ok~Thx:)
I have submitted 3 PRs that can make it easier to manage table data for Alluxio table users.

Add data operation ability on AbstractTableCommand #12741 Add data operation ability on AbstractTableCommand
Fix packaging distributed load code into DistributedLoadUtils #13288 Packaging distributed load code into DistributedLoadUtils
Add LoadTableCommand #14701 Add LoadTableCommand

DistributedLoadUtils is helpful because Alluxio table load command can sync improvement from filesystem distributedLoadUtils.
Whats more, alluxio table load command has become a good partner in muti-cluster data share, and there will be more features.
I think may be I could re-package the new design again in another PR.

@JySongWithZhangCe Thanks for sharing the info. Currently filesystem related operation is moved to be handled by job master side. Please feel free to refactor your new feature for loading table in another PR. We will take a look at the PR once you finish.

@JySongWithZhangCe Sorry we missed your comment earlier. Do you mind describing what behavior this might break? We can make changes to ensure it still works after this PR.

Ok~Thx:)
I have submitted 3 PRs that can make it easier to manage table data for Alluxio table users.

Add data operation ability on AbstractTableCommand #12741 Add data operation ability on AbstractTableCommand
Fix packaging distributed load code into DistributedLoadUtils #13288 Packaging distributed load code into DistributedLoadUtils
Add LoadTableCommand #14701 Add LoadTableCommand

DistributedLoadUtils is helpful because Alluxio table load command can sync improvement from filesystem distributedLoadUtils.
Whats more, alluxio table load command has become a good partner in muti-cluster data share, and there will be more features.
I think may be I could re-package the new design again in another PR.

@JySongWithZhangCe Thanks for sharing the info. Currently filesystem related operation is moved to be handled by job master side. Please feel free to refactor your new feature for loading table in another PR. We will take a look at the PR once you finish.

Thx:)


pipx run userpath fails with "userpath not found in package userpath. Available binaries: userpath"

I installed pipx with pipsi install pipx because I'm currently using pipsi and I was investigating alternatives that are actually maintained.
It looks like pipx doesn't like being installed with pipsi:
$ pipx run cowsay hello
  WARNING: The script cowsay is installed in '/home/mg/.local/venvs/pipx/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
cowsay not found in package cowsay. Available binaries: cowsay

BTW this warning never appears again, but pipx continues to fail to work
$ pipx run userpath --help
userpath not found in package userpath. Available binaries: userpath

$ pipx run cowsay hi
cowsay not found in package cowsay. Available binaries: cowsay

For the record, my $PATH includes /home/mg/.local/bin, and this directory contains a pipx symlink, created by pipsi, pointing to ~/.local/venvs/pipx/bin/pipx.
The annoying thing is the error message: pipx claims that it both found and failed to find the binary I'm trying to run!

It looks like what's happening here is

pipsi creates a virtualenv ~/.local/venvs/pipx
pipx runs ~/.local/venvs/pipx/bin/python -m venv to create new venvs like ~/.local/pipx/.cache/25ccfc96b4889e7
pipx runs ~/.local/pipx/cache/25ccfc96b4889e7/bin/python -m pip install --upgrade pip, which upgrades pip in the parent virtualenv, ~/.local/venvs/pipx/lib/python3.7/site-packages
pipx runs ~/.local/pipx/cache/25ccfc96b4889e7/bin/python -m pip install cowsay, which installs cowsay in the parent virtualenv, ~/.local/venvs/pipx/lib/python3.7/site-packages

Is this a bug in venv?  A bug in virtualenv?  Is there anything pipx could do to detect this kind of situation?  I don't know!
:fire: Python packaging is fine :fire:

Apologies: I assumed that pipsi uses virtualenv, but it looks like it uses venv on Python 3.
So far I've been unable to reproduce this using python3 -m venv and trying to construct stacks of nested venvs...

I'm going to close this, since I couldn't come up with a clear way to reproduce.


.eps export for figures

I know that matplotlib allows exporting to .eps files, which is used a lot by people working with LaTeX since it is one of the few vector graphics formats that are reasonably well supported via standard packages.
Since I assume you are using matplotlib's interface to export to png/svg in the background, would it be difficult to add the .eps option?
Is there a workaround for accessing the generated matplotlib figure and save it directly using the backend?
Of course, it would be great if this also worked for the other backends, but I am unsure about their support.

I'll have to check whether eps is supported for saving out files by the matplotlib renderer (it should be). The general issue with .eps for rendering for interactive work is that web browsers don't render eps properly afaik which is why we tend to use PNG for raster output and SVG for vector output. We tried PDF output at once point but that didn't integrate well with web browsers either so we dropped that iirc.
So in short, I'll check if EPS can be output to file using the explicit renderer API but I don't see .eps being a valid output in the browser for interactive work.

Is there a workaround for accessing the generated matplotlib figure and save it directly using the backend?

Yes there is using, e.g.:
obj = hv.Curve(range(10))
fig = hv.renderer('bokeh').get_plot(obj).state

Ah, convenient! Thanks for the tips. Will using get_plot also apply the %%opts of the cell or should options be applied using the class methods instead?
Apparently there is a package I did not know of that allows one to include svg in LaTeX, but I am guessing a broader range of output formats might still be helpful to me and others.

Ah, convenient! Thanks for the tips. Will using get_plot also apply the %%opts of the cell or should options be applied using the class methods instead?

I won't, but since %%opts persists you could display the plot with the magic applied in one cell and then save the plot in a subsequent cell.


How to "authenticate and have a bearer token" ?

when I call the code "  var members = await connector.Conversations.GetConversationMembersAsync(activity.Conversation.Id); "
and get the error "Microsoft.Bot.Connector.MicrosoftAppCredentials+OAuthException: Unauthorized ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized)."
Is it that I don't have permission to access it? looking forward to reply, Thanks!

@XimenaWang - Are you trying to fetch the team roster? Could you please confirm if your App Id and App Secret are correct? Please share the code snippet of how you are creating ConnectorClient.

@Wajeed-msft Hi,  App Id and App Secret means Bot Id and Bot Password? ok, my code below:

Yes, Bot Id and Bot Password.
Is your bot responding back with when you don't fetch conversation members? If yes, then could you please fetch members right after your replies?

Are you trying to fetch conversation members from Message Extension?

NO, I just want to create one Proactive message by Bot. Actually, any operation I did using the ConnectorClient all report the "Unauthorized" error. so I tried the code "Message Extension", " fetch the team roster" and "proactive message".

I have confirmed that I do not have permission to use the ConnectorClient to do anything, my full code follows. Where should I use Bot Id and Bot password?

@XimenaWang - Could you please uncomment [BotAuthentication] attribute and try again?

Same issue, I comment it as this issue, but this issue still exists after I commented on it.

@Wajeed-msft Hi, I added the credential in ConnectorClient, and the App Id and App Secret are correct, but it still reported 401. Can  you help take a look? Any insight you have would be greatly appreciated.  Thanks in advance for your help.

@XimenaWang - Could you please try adding MicrosoftAppCredentials.TrustServiceUrl(serviceUrl, DateTime.MaxValue); to your code as given in sample code snippet?

@Wajeed-msft - No, I have studied this sample before, but  it needs the parameter: context. I'm not sure where this parameter comes from?  My code references this GitHub: https://github.com/microsoft/botframework-sdk/issues/2258


unitr convert onnx

Hello, I would like to ask why the unitr onnx conversion process only converted the uintr block part, not the whole network conversion. thank you.

Similar to DSVT, what we designed is a deployable multi-modal backbone, so we only provide the deployment code for the backbone. Relying on this deployment code to deploy all the modules should not be a difficult task.


Cache tooling check

Description:
For more information see the link below.
https://github.com/ballerina-platform/ballerina-standard-library/blob/main/docs/library-development-process.md#tooling-check

Closing this issue as tested cache tooling in the VS code with SL Beta4.


feat(alert): adds inline modifier

Based on design doc at https://docs.google.com/document/d/1HTkvK8_zFJAX-rhBw1aNrmZYzywixik31DzaiKCUbW4/edit#
Fixes #1390
Note: The icon padding should be broken into parts but is a breaking change so there is an issue for this in #1773

Deploy preview for pf-next ready!
Built with commit 67d4ef9cd072422fc0f40bb618585d7ccead7f46
https://deploy-preview-1775--pf-next.netlify.com

Looks good to me @srambach - thanks!

The latest changes look great, @srambach - thank you!

The icon size in the doc vs what you have in the PR, looks different. Could you check with design and see what exact size they want?

I think it would also be worth showing an example of an inline notification with a close button

Good catch, @christiemolloy - it's my bad for not pointing out that icon size tweak to @srambach when we went over the design. I brought the size down when we dropped the BG behind the icon because visually, it feels more like an inline icon next to the title, so having the larger size felt a little too big to me without that BG visually separating it from the text.

:tada: This PR is included in version 2.7.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add parity check conditions

WHAT YOU DID
Added parity checker conditional and re-added tests that were failing temporarily.

@hjvoid @alexbishop1 Is this PR still required?

Yes I believe so. PP-13241
https://github.com/alphagov/pay-connector/pull/5643 should be done
shortly which will make that one redundant:
On Tue, 26 Nov 2024 at 09:46, Kat @.***> wrote:

@hjvoid https://github.com/hjvoid @alexbishop1
https://github.com/alexbishop1 Is this PR still required?
—
Reply to this email directly, view it on GitHub
https://github.com/alphagov/pay-connector/pull/5640#issuecomment-2500142763,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWB7MW7R6RACRL3B6G3KPUD2CQ7QLAVCNFSM6AAAAABSAEZPZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBQGE2DENZWGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


Graphic missing from bar (top right)

After installing this both on Arch and Ubuntu I have found that there are no graphics in the bar above the tasks. The screenshots that I have seen show a camper van, cityscape, &c. Am I missing some dependency? This can be seen in a screenshot uploaded by another user who has shown to have a differing graphical composition for the app: https://github.com/klauscfhq/ao/issues/37

Seems the new interface broke everything: #43 #37
Anyone got news on a fix? AO just told me there would be an update, but no new release here?
Am i missing something? I have not much knowledge on how Github works, maybe i am missing something?

Ao does not alter the original app UI, exept for the main colors which are modified through theming.  Apparently, the graphics have been dropped by the Microsoft To-Do development team itself.
The new 6.0.0 release, supporting the updated Microsoft To-Do interface, is now out. Full changelog & binaries are available on the GitHub Releases page.


Add: Return value for replaceWith, element that replaced original node.

This PR intends to create a return value for the replaceWith helper located in Node.js. The current implementation returns no value, meaning that no reference is available to the node that was inserted. This fix returns that value, allowing for the new element to be referenced and manipulated.
This will not affect any current implementations of replaceWith as there is no value currently being returned and any current calls to replaceWith are not expecting a value to be returned.
The current implementation:
 replaceWith(currentElement, newElement) // => no value returned
The preposed implementation:
element = replaceWith(currentElement, newElement) // => reference to newElement

Umm, I don't think this code does what you think it does. It returns the original node (currentElement), not newElement. Also, if the currentElement doesn't currently have a parent, this will return undefined, as opposed to a node. Is that difference going to catch some code out later down the line? Might be worth thinking about what the return value should be in this case (I haven't thought about it yet; maybe null is fine).
Not opposed to this change in general (once fixed), but just to clarify: since this function is within the Squire closure, it's only available for internal use. But you haven't changed any code to use the new return value. Do you plan to use this to cleanup some code? Should that be part of this pull request as well?


Karpenter spontaneously replaces all nodes across all our clusters at exactly Friday 11:30pm (GMT+8) for no reason.

Description
Observed Behavior:
We were experiencing weird behavior where karpenter replaces all good nodes happened exactly the same time around Friday, 11:30PM (GMT+8) across all our clusters in ap-southeast-1. We observed this behavior consistent across different aws accounts, even the ones recently deployed with latest eks version. We could not find what's the cause of this spontaneous replacement.
Logs doesn't give much help as to why this happens, except only this particular message gave a clue:
disrupting via drift replace, terminating 1 nodes (5 pods) ip-10-0-13-168.ap-southeast-1.compute.internal/t3a.xlarge/on-demand and replacing with on-demand node from types t3a.xlarge, t3.xlarge, m6a.xlarge

Full logs
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:29:59.597Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"provisioner","NodePool":{"name":"default"},"NodeClaim":{"name":"default-mq7zw"},"requests":{"cpu":"530m","memory":"720Mi","pods":"5"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.medium, t3.small and 5 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:01.983Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mq7zw"},"namespace":"","name":"default-mq7zw","reconcileID":"54b0842c-cc6d-4496-b5a3-a0f0aec2a401","provider-id":"aws:///ap-southeast-1c/i-08ad3ece9c9e61ec0","instance-type":"t3a.small","zone":"ap-southeast-1c","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"1451Mi","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:06.423Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"monitoring-vh4q8"},"namespace":"","name":"monitoring-vh4q8","reconcileID":"6b5c99a4-c29b-4bbb-83d9-1e25befa214e","provider-id":"aws:///ap-southeast-1a/i-0502a7ae1b7980105","Node":{"name":"ip-10-0-11-175.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"3920m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"31458712Ki","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:07.106Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"82e63427-8ca3-4618-a7dd-8e1eebcb0557"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:07.148Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-155.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-155.ap-southeast-1.compute.internal","reconcileID":"a084f6c4-e556-4c4a-86fb-d1addc23c5b5"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:12.602Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-155.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-155.ap-southeast-1.compute.internal","reconcileID":"2d6c10d6-8c93-4079-9f48-221301d71de2"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:12.967Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"monitoring-lq8ks"},"namespace":"","name":"monitoring-lq8ks","reconcileID":"1d3b695a-1ea3-4582-9609-76bfced68190","Node":{"name":"ip-10-0-15-155.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1b/i-0e93e8ceeeb77b598"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:22.824Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cfwb9"},"namespace":"","name":"default-cfwb9","reconcileID":"3d036df1-e488-4c8a-b3e2-2deab368ef97","provider-id":"aws:///ap-southeast-1b/i-00a6244999fb26461","Node":{"name":"ip-10-0-18-142.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:24.749Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-41.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-41.ap-southeast-1.compute.internal","reconcileID":"ab486516-655f-45ab-b93b-c6c657f0537d"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:25.069Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-hxzjq"},"namespace":"","name":"default-hxzjq","reconcileID":"203e98b4-79e9-4827-906d-21e16e649b14","Node":{"name":"ip-10-0-15-41.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1b/i-0e4c75f65a965e4ee"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:27.876Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mq7zw"},"namespace":"","name":"default-mq7zw","reconcileID":"39b0f2ef-f06f-430e-821e-5d6c35b92411","provider-id":"aws:///ap-southeast-1c/i-08ad3ece9c9e61ec0","Node":{"name":"ip-10-0-16-137.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-mnh8l {"level":"INFO","time":"2024-07-24T04:22:48.095Z","logger":"controller.controller-runtime.metrics","message":"Starting metrics server","commit":"490ef94"}
karpenter-6866897bd7-mnh8l {"level":"INFO","time":"2024-07-24T04:22:48.096Z","logger":"controller.controller-runtime.metrics","message":"Serving metrics server","commit":"490ef94","bindAddress":":8000","secure":false}
karpenter-6866897bd7-mnh8l {"level":"INFO","time":"2024-07-24T04:22:48.097Z","logger":"controller","message":"starting server","commit":"490ef94","name":"health probe","addr":":8081"}
karpenter-6866897bd7-mnh8l {"level":"INFO","time":"2024-07-24T04:22:48.095Z","logger":"controller","message":"webhook disabled","commit":"490ef94"}
karpenter-6866897bd7-mnh8l {"level":"INFO","time":"2024-07-24T04:22:48.200Z","logger":"controller","message":"attempting to acquire leader lease karpenter/karpenter-leader-election...","commit":"490ef94"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:41.123Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cfwb9"},"namespace":"","name":"default-cfwb9","reconcileID":"fbaa9ef2-ebb0-44d5-9e6a-22e084e8ca15","provider-id":"aws:///ap-southeast-1b/i-00a6244999fb26461","Node":{"name":"ip-10-0-18-142.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"3920m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"15209888Ki","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:46.027Z","logger":"controller","message":"disrupting via drift replace, terminating 1 nodes (5 pods) ip-10-0-13-168.ap-southeast-1.compute.internal/t3a.xlarge/on-demand and replacing with on-demand node from types t3a.xlarge, t3.xlarge, m6a.xlarge","commit":"490ef94","controller":"disruption","command-id":"8385f948-28e0-4794-9cfd-a74755def27f"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:46.065Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-rkj87"},"requests":{"cpu":"2580m","memory":"6920Mi","pods":"6"},"instance-types":"m6a.xlarge, t3.xlarge, t3a.xlarge"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:46.763Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mq7zw"},"namespace":"","name":"default-mq7zw","reconcileID":"e4b9acf6-54aa-4c79-a90f-c64dc9304f85","provider-id":"aws:///ap-southeast-1c/i-08ad3ece9c9e61ec0","Node":{"name":"ip-10-0-16-137.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"1522968Ki","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:47.558Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-rkj87"},"namespace":"","name":"default-rkj87","reconcileID":"564a151a-7d14-4605-9dd7-cb4dd20e1990","provider-id":"aws:///ap-southeast-1c/i-081b3f118f188313f","instance-type":"t3a.xlarge","zone":"ap-southeast-1c","capacity-type":"on-demand","allocatable":{"cpu":"3920m","ephemeral-storage":"44Gi","memory":"14162Mi","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:49.167Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"482f735f-4afd-4713-b737-96b74d327ab9"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:30:49.229Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-19-65.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-19-65.ap-southeast-1.compute.internal","reconcileID":"75d00c0b-fd5e-49b8-834b-997ab758c8a5"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:02.767Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-19-65.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-19-65.ap-southeast-1.compute.internal","reconcileID":"d960f786-099c-4b6a-a2bb-ff90e7931f5d"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:03.116Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-l2n88"},"namespace":"","name":"default-l2n88","reconcileID":"56fd3981-3080-4031-9a58-4bb5c1800095","Node":{"name":"ip-10-0-19-65.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1c/i-0dac83692bb179927"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:17.328Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-rkj87"},"namespace":"","name":"default-rkj87","reconcileID":"0fb68cfc-4eef-4ca1-9885-17ef8dacfb5a","provider-id":"aws:///ap-southeast-1c/i-081b3f118f188313f","Node":{"name":"ip-10-0-16-250.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:19.690Z","logger":"controller","message":"disrupting via drift delete, terminating 1 nodes (4 pods) ip-10-0-15-246.ap-southeast-1.compute.internal/t3a.small/on-demand","commit":"490ef94","controller":"disruption","command-id":"2497c50a-c484-4939-b48a-51d765774cea"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:20.234Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"2497c50a-c484-4939-b48a-51d765774cea"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:20.267Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-246.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-246.ap-southeast-1.compute.internal","reconcileID":"ba8f3034-3090-48c7-8382-4eada43bdc80"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:33.647Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-rkj87"},"namespace":"","name":"default-rkj87","reconcileID":"c26ee026-a85d-45fb-84e3-d46332628a29","provider-id":"aws:///ap-southeast-1c/i-081b3f118f188313f","Node":{"name":"ip-10-0-16-250.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"3920m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"15209888Ki","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:33.710Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-246.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-246.ap-southeast-1.compute.internal","reconcileID":"8ba053ca-d251-45ad-b2a4-64f4c7550a8b"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:34.024Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-48whc"},"namespace":"","name":"default-48whc","reconcileID":"c832057f-8dc5-4480-aaee-d6b5ced21181","Node":{"name":"ip-10-0-15-246.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1b/i-066595767eeb529ee"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:40.094Z","logger":"controller","message":"disrupting via drift replace, terminating 1 nodes (4 pods) ip-10-0-19-49.ap-southeast-1.compute.internal/t3a.large/on-demand and replacing with on-demand node from types t3a.large, t3.large, m6a.large, t3a.xlarge, t3.xlarge and 1 other(s)","commit":"490ef94","controller":"disruption","command-id":"eb911ba0-db94-437c-a8ce-89037036d831"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:40.127Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-mpn9j"},"requests":{"cpu":"1580m","memory":"4070Mi","pods":"6"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.xlarge, t3a.large and 1 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:41.651Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mpn9j"},"namespace":"","name":"default-mpn9j","reconcileID":"fe3869a6-fb41-4b12-b969-a8fe41c514e7","provider-id":"aws:///ap-southeast-1c/i-0d8716d3ed2be43e1","instance-type":"t3a.large","zone":"ap-southeast-1c","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"6837Mi","pods":"35"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:43.286Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"8385f948-28e0-4794-9cfd-a74755def27f"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:43.318Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-13-168.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-13-168.ap-southeast-1.compute.internal","reconcileID":"7cbe2aa1-0e26-45e0-8b4f-24743c1aa106"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:51.762Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-13-168.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-13-168.ap-southeast-1.compute.internal","reconcileID":"91427ef0-b066-4c8b-99bd-c0adb8103d02"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:31:52.089Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-f5lwb"},"namespace":"","name":"default-f5lwb","reconcileID":"a3c46dc9-83a4-4cf3-889f-4c0b9f6f37c4","Node":{"name":"ip-10-0-13-168.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1c/i-05f0100f8bdf7bb3f"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:16.328Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mpn9j"},"namespace":"","name":"default-mpn9j","reconcileID":"575bb0e0-6d7f-426f-b3ca-fdaf0e728ec1","provider-id":"aws:///ap-southeast-1c/i-0d8716d3ed2be43e1","Node":{"name":"ip-10-0-13-99.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:40.579Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-mpn9j"},"namespace":"","name":"default-mpn9j","reconcileID":"5f68bbc1-c200-4324-9c1c-36b660acf7a0","provider-id":"aws:///ap-southeast-1c/i-0d8716d3ed2be43e1","Node":{"name":"ip-10-0-13-99.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"7287700Ki","pods":"35"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:43.676Z","logger":"controller","message":"disrupting via drift replace, terminating 1 nodes (8 pods) ip-10-0-12-167.ap-southeast-1.compute.internal/t3a.xlarge/on-demand and replacing with on-demand node from types t3a.xlarge, t3.xlarge, m6a.xlarge","commit":"490ef94","controller":"disruption","command-id":"0770d75d-c625-4dbc-a9ce-e3903d92c49d"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:43.709Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-n2z4r"},"requests":{"cpu":"3480m","memory":"6530Mi","pods":"10"},"instance-types":"m6a.xlarge, t3.xlarge, t3a.xlarge"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:45.209Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-n2z4r"},"namespace":"","name":"default-n2z4r","reconcileID":"afc90645-fa69-488c-b268-0b97077f81e3","provider-id":"aws:///ap-southeast-1b/i-0a02d95a2459e0549","instance-type":"t3a.xlarge","zone":"ap-southeast-1b","capacity-type":"on-demand","allocatable":{"cpu":"3920m","ephemeral-storage":"44Gi","memory":"14162Mi","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:46.356Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"eb911ba0-db94-437c-a8ce-89037036d831"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:46.394Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-19-49.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-19-49.ap-southeast-1.compute.internal","reconcileID":"e91976c9-cfb2-4bc4-b237-3f72634b25f7"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:49.828Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-19-49.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-19-49.ap-southeast-1.compute.internal","reconcileID":"2ea61a3b-c341-4597-a5f2-b86755c576c1"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:32:50.168Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-nm5mm"},"namespace":"","name":"default-nm5mm","reconcileID":"cb0d5d3a-2f5f-4c35-917c-dfb77ab814f4","Node":{"name":"ip-10-0-19-49.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1c/i-0e5de89000c6756c2"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:07.867Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-n2z4r"},"namespace":"","name":"default-n2z4r","reconcileID":"f045a7f8-4296-4bc1-8bbd-6feca349d6de","provider-id":"aws:///ap-southeast-1b/i-0a02d95a2459e0549","Node":{"name":"ip-10-0-15-148.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:23.790Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-n2z4r"},"namespace":"","name":"default-n2z4r","reconcileID":"d4c0ba31-04c6-4f46-beec-ca99c51d7e4b","provider-id":"aws:///ap-southeast-1b/i-0a02d95a2459e0549","Node":{"name":"ip-10-0-15-148.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"3920m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"15209888Ki","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:26.581Z","logger":"controller","message":"disrupting via drift replace, terminating 1 nodes (14 pods) ip-10-0-17-230.ap-southeast-1.compute.internal/t3a.xlarge/on-demand and replacing with 0 spot and 2 on-demand, from types t3a.xlarge, t3.xlarge, m6a.xlarge","commit":"490ef94","controller":"disruption","command-id":"5bc5fb4f-69e6-495e-9e2a-6e7b89e350ea"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:26.615Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-cx2tw"},"requests":{"cpu":"3230m","memory":"3246Mi","pods":"14"},"instance-types":"m6a.xlarge, t3.xlarge, t3a.xlarge"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:26.623Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-7nz8t"},"requests":{"cpu":"280m","memory":"150Mi","pods":"5"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.medium, t3.small and 5 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:28.751Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cx2tw"},"namespace":"","name":"default-cx2tw","reconcileID":"4e082525-a082-4443-bb68-36a2f1c95584","provider-id":"aws:///ap-southeast-1b/i-0dca6405ce2f56e7b","instance-type":"t3a.xlarge","zone":"ap-southeast-1b","capacity-type":"on-demand","allocatable":{"cpu":"3920m","ephemeral-storage":"44Gi","memory":"14162Mi","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:28.898Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-7nz8t"},"namespace":"","name":"default-7nz8t","reconcileID":"98d6ed3e-943a-497e-9bd6-2b28221365b9","provider-id":"aws:///ap-southeast-1a/i-0678fa58ec3326897","instance-type":"t3a.small","zone":"ap-southeast-1a","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"1451Mi","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:29.405Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"0770d75d-c625-4dbc-a9ce-e3903d92c49d"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:29.438Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-12-167.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-12-167.ap-southeast-1.compute.internal","reconcileID":"13ce5439-978e-4cd5-9524-43c6ee3690cf"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:42.902Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-12-167.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-12-167.ap-southeast-1.compute.internal","reconcileID":"7126ad11-b2da-4508-bbd9-ab0e41c20b87"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:43.226Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-pjm6n"},"namespace":"","name":"default-pjm6n","reconcileID":"6038515a-503a-4a32-a4fb-269ec8520b50","Node":{"name":"ip-10-0-12-167.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1b/i-00895d239fc6785e2"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:52.465Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cx2tw"},"namespace":"","name":"default-cx2tw","reconcileID":"0261db9c-4f12-4842-969a-38f78fefe514","provider-id":"aws:///ap-southeast-1b/i-0dca6405ce2f56e7b","Node":{"name":"ip-10-0-18-240.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:55.578Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-7nz8t"},"namespace":"","name":"default-7nz8t","reconcileID":"59e51fe1-56ee-4204-9434-92614877f9c6","provider-id":"aws:///ap-southeast-1a/i-0678fa58ec3326897","Node":{"name":"ip-10-0-11-215.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:57.762Z","logger":"controller","message":"found provisionable pod(s)","commit":"490ef94","controller":"provisioner","Pods":"default/local-qm-localserver-api-5b5f96767-88wk9, default/local-qm-tool-module-7c4b87f4d8-zqlv2, default/frontend-web-7c6d7c9f89-mtfwd, default/local-qm-merchant-api-567c96fb9b-cjrlt, argocd/argocd-application-controller-0 and 9 other(s)","duration":"156.729529ms"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:57.763Z","logger":"controller","message":"computed new nodeclaim(s) to fit pod(s)","commit":"490ef94","controller":"provisioner","nodeclaims":1,"pods":1}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:57.763Z","logger":"controller","message":"computed 7 unready node(s) will fit 13 pod(s)","commit":"490ef94","controller":"provisioner"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:57.777Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"provisioner","NodePool":{"name":"default"},"NodeClaim":{"name":"default-t72wd"},"requests":{"cpu":"280m","memory":"150Mi","pods":"5"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.medium, t3.small and 5 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:33:59.249Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-t72wd"},"namespace":"","name":"default-t72wd","reconcileID":"025f3ae4-5039-44cc-9c82-d99be5ea401f","provider-id":"aws:///ap-southeast-1a/i-07fc3496e6fc4f2eb","instance-type":"t3a.small","zone":"ap-southeast-1a","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"1451Mi","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:08.991Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cx2tw"},"namespace":"","name":"default-cx2tw","reconcileID":"9d78df6b-ef93-4cfc-a3f7-b2b8c249027f","provider-id":"aws:///ap-southeast-1b/i-0dca6405ce2f56e7b","Node":{"name":"ip-10-0-18-240.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"3920m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"15209880Ki","pods":"58"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:13.287Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-7nz8t"},"namespace":"","name":"default-7nz8t","reconcileID":"aedcb093-b508-4892-abab-d1e808c35d5e","provider-id":"aws:///ap-southeast-1a/i-0678fa58ec3326897","Node":{"name":"ip-10-0-11-215.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"1522968Ki","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:13.480Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"5bc5fb4f-69e6-495e-9e2a-6e7b89e350ea"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:13.513Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-17-230.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-17-230.ap-southeast-1.compute.internal","reconcileID":"3ea6cf77-ab15-44ac-8fa6-0e885390ddc4"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:35.291Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-t72wd"},"namespace":"","name":"default-t72wd","reconcileID":"3363f289-f9e7-42d3-bec5-02cb8ce001db","provider-id":"aws:///ap-southeast-1a/i-07fc3496e6fc4f2eb","Node":{"name":"ip-10-0-14-151.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:49.082Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-17-230.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-17-230.ap-southeast-1.compute.internal","reconcileID":"ea088da2-0f2b-4d8d-a5ab-ad1e215506e1"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:49.412Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-cxscw"},"namespace":"","name":"default-cxscw","reconcileID":"548ae7ba-79b1-4473-a1fe-94e8e1482bd0","Node":{"name":"ip-10-0-17-230.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1a/i-07772362342065840"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:51.236Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-t72wd"},"namespace":"","name":"default-t72wd","reconcileID":"b9eaad11-ec66-4ba6-b9c9-5ab1c6ca970d","provider-id":"aws:///ap-southeast-1a/i-07fc3496e6fc4f2eb","Node":{"name":"ip-10-0-14-151.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"1522968Ki","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:52.694Z","logger":"controller","message":"disrupting via drift delete, terminating 1 nodes (3 pods) ip-10-0-16-237.ap-southeast-1.compute.internal/t3a.small/on-demand","commit":"490ef94","controller":"disruption","command-id":"ffe00c92-2c2c-478f-b877-ec7b01f1d572"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:53.058Z","logger":"controller","message":"disrupting via drift replace, terminating 1 nodes (4 pods) ip-10-0-13-227.ap-southeast-1.compute.internal/t3a.small/on-demand and replacing with on-demand node from types t3a.small, t3.small, t3a.medium, t3.medium, t3a.large and 5 other(s)","commit":"490ef94","controller":"disruption","command-id":"25eba935-d2ad-44fd-ab93-743ea9150cb2"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:53.142Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"disruption","NodePool":{"name":"default"},"NodeClaim":{"name":"default-5zvdj"},"requests":{"cpu":"1280m","memory":"1270Mi","pods":"5"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.medium, t3.small and 5 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:53.559Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"ffe00c92-2c2c-478f-b877-ec7b01f1d572"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:53.596Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-16-237.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-16-237.ap-southeast-1.compute.internal","reconcileID":"d54eab01-4f0e-4cc2-96d8-7438e6fe4937"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:34:54.597Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5zvdj"},"namespace":"","name":"default-5zvdj","reconcileID":"7980ae1e-2039-42f9-ac2a-c44c1ee58997","provider-id":"aws:///ap-southeast-1b/i-0d3267465cf2169d8","instance-type":"t3a.small","zone":"ap-southeast-1b","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"1451Mi","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:07.151Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-16-237.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-16-237.ap-southeast-1.compute.internal","reconcileID":"db561eab-8d60-4558-925d-162b9002f439"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:07.517Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-hcmcm"},"namespace":"","name":"default-hcmcm","reconcileID":"e43be966-0a4e-4081-bf2f-ae7282143077","Node":{"name":"ip-10-0-16-237.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1c/i-017cff6ec494100b9"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:20.722Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5zvdj"},"namespace":"","name":"default-5zvdj","reconcileID":"4763f9c9-8452-4d7c-a2e3-d75b916e2014","provider-id":"aws:///ap-southeast-1b/i-0d3267465cf2169d8","Node":{"name":"ip-10-0-15-14.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:31.722Z","logger":"controller","message":"disrupting via consolidation delete, terminating 1 nodes (4 pods) ip-10-0-11-215.ap-southeast-1.compute.internal/t3a.small/on-demand","commit":"490ef94","controller":"disruption","command-id":"9611d1a2-4cff-4a80-8599-7a1e074bfc5c"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:32.620Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"9611d1a2-4cff-4a80-8599-7a1e074bfc5c"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:32.709Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-11-215.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-11-215.ap-southeast-1.compute.internal","reconcileID":"faa57209-e995-436d-b230-e209b5494eea"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:33.946Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5zvdj"},"namespace":"","name":"default-5zvdj","reconcileID":"1e43596e-f7c3-4b1c-b6e7-526e7bd4238f","provider-id":"aws:///ap-southeast-1b/i-0d3267465cf2169d8","Node":{"name":"ip-10-0-15-14.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"1522968Ki","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:34.208Z","logger":"controller","message":"found provisionable pod(s)","commit":"490ef94","controller":"provisioner","Pods":"default/local-qm-localserver-api-5b5f96767-dh99l, kube-system/metrics-server-86764c6db6-hgm4z, argocd/argocd-server-7f969b4ddb-7n89h, kube-system/coredns-557bbdb899-dhbgd, traefik/traefik-5ffc5c77cb-txch7 and 1 other(s)","duration":"80.404809ms"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:34.209Z","logger":"controller","message":"computed new nodeclaim(s) to fit pod(s)","commit":"490ef94","controller":"provisioner","nodeclaims":1,"pods":1}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:34.209Z","logger":"controller","message":"computed 3 unready node(s) will fit 5 pod(s)","commit":"490ef94","controller":"provisioner"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:34.220Z","logger":"controller","message":"created nodeclaim","commit":"490ef94","controller":"provisioner","NodePool":{"name":"default"},"NodeClaim":{"name":"default-5rk9b"},"requests":{"cpu":"1580m","memory":"1270Mi","pods":"5"},"instance-types":"m6a.large, m6a.xlarge, t3.large, t3.medium, t3.small and 5 other(s)"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:35.782Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5rk9b"},"namespace":"","name":"default-5rk9b","reconcileID":"af05d812-7dab-433c-bcac-472bc72cad87","provider-id":"aws:///ap-southeast-1c/i-0d930cbc042c5a7e3","instance-type":"t3a.small","zone":"ap-southeast-1c","capacity-type":"on-demand","allocatable":{"cpu":"1930m","ephemeral-storage":"44Gi","memory":"1451Mi","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:39.656Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"25eba935-d2ad-44fd-ab93-743ea9150cb2"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:39.694Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-13-227.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-13-227.ap-southeast-1.compute.internal","reconcileID":"0c673b4c-88a6-4577-b7a5-d408e542a825"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:41.151Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-11-215.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-11-215.ap-southeast-1.compute.internal","reconcileID":"e7e16841-8035-4431-9d90-8e724976273f"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:41.622Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-7nz8t"},"namespace":"","name":"default-7nz8t","reconcileID":"de649472-17f5-42c5-8741-9a7ff2979d6c","Node":{"name":"ip-10-0-11-215.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1a/i-0678fa58ec3326897"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:44.153Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-13-227.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-13-227.ap-southeast-1.compute.internal","reconcileID":"bea87ebb-d9fb-437b-b02f-70c08123127d"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:35:44.498Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-nsmqc"},"namespace":"","name":"default-nsmqc","reconcileID":"1874c94b-36ea-40c3-b910-05626b57e52b","Node":{"name":"ip-10-0-13-227.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1c/i-0d4a0170d61955196"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:36:01.089Z","logger":"controller","message":"registered nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5rk9b"},"namespace":"","name":"default-5rk9b","reconcileID":"870efbad-1488-4a78-b031-2b15a4ed7f0d","provider-id":"aws:///ap-southeast-1c/i-0d930cbc042c5a7e3","Node":{"name":"ip-10-0-19-68.ap-southeast-1.compute.internal"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:36:20.035Z","logger":"controller","message":"initialized nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5rk9b"},"namespace":"","name":"default-5rk9b","reconcileID":"a32e3f21-aeaa-42e5-bad5-1d3bd704c374","provider-id":"aws:///ap-southeast-1c/i-0d930cbc042c5a7e3","Node":{"name":"ip-10-0-19-68.ap-southeast-1.compute.internal"},"allocatable":{"cpu":"1930m","ephemeral-storage":"47233297124","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"1522968Ki","pods":"8"}}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:41:51.028Z","logger":"controller","message":"disrupting via consolidation delete, terminating 1 nodes (4 pods) ip-10-0-15-14.ap-southeast-1.compute.internal/t3a.small/on-demand","commit":"490ef94","controller":"disruption","command-id":"73d2a18f-0804-4062-8c06-fa30b1d156f4"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:41:52.053Z","logger":"controller","message":"command succeeded","commit":"490ef94","controller":"disruption.queue","command-id":"73d2a18f-0804-4062-8c06-fa30b1d156f4"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:41:52.084Z","logger":"controller","message":"tainted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-14.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-14.ap-southeast-1.compute.internal","reconcileID":"00c7aacc-157f-4c3e-8f68-0d8aa45c31e5"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:42:00.576Z","logger":"controller","message":"deleted node","commit":"490ef94","controller":"node.termination","controllerGroup":"","controllerKind":"Node","Node":{"name":"ip-10-0-15-14.ap-southeast-1.compute.internal"},"namespace":"","name":"ip-10-0-15-14.ap-southeast-1.compute.internal","reconcileID":"826d2077-8e43-4523-b9d2-4f8c0d70d0ac"}
karpenter-6866897bd7-jnm9q {"level":"INFO","time":"2024-09-06T15:42:00.894Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"default-5zvdj"},"namespace":"","name":"default-5zvdj","reconcileID":"80c4cec3-19bd-403e-9aac-e009151f303f","Node":{"name":"ip-10-0-15-14.ap-southeast-1.compute.internal"},"provider-id":"aws:///ap-southeast-1b/i-0d3267465cf2169d8"}

Expected Behavior:
It should not replace good nodes for no reason.
Reproduction Steps (Please include YAML):
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  limits:
    cpu: "500"
    memory: 2000Gi
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - ap-southeast-1a
        - ap-southeast-1b
        - ap-southeast-1c
      - key: karpenter.k8s.aws/instance-family
        operator: In
        values:
        - t3
        - t3a
        - m6a
      - key: karpenter.k8s.aws/instance-size
        operator: In
        values:
        - small
        - medium
        - large
        - xlarge
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64

apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  blockDeviceMappings:
  - deviceName: /dev/xvda
    ebs:
      deleteOnTermination: true
      volumeSize: 50Gi
      volumeType: gp2
  instanceProfile: ${module.karpenter.instance_profile_name}
  securityGroupSelectorTerms:
  - tags:
      karpenter.sh/discovery/${module.eks.cluster_id}: ${module.eks.cluster_id}
  subnetSelectorTerms:
  - tags:
      karpenter.sh/discovery/${module.eks.cluster_id}: ${module.eks.cluster_id}
  tags:
    karpenter.sh/discovery/${module.eks.cluster_id}: ${module.eks.cluster_id}
    provisioned-by: karpenter

Versions:

Chart Version: 18.31.0 (0.37.0)
Kubernetes Version (kubectl version): v1.28.12-eks-2f46c53 (do note that it also affects our other clusters on v1.30.3-eks-2f46c53)

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

These log lines don't say what kind of drift caused the replacement. There should be log that indicate the drift as described below:
{"level":"DEBUG","time":"2024-09-02T10:22:25.036Z","logger":"controller","caller":"disruption/controller.go:91","message":"marking drifted","commit":"62a726c","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"al2-9x6cm"},"namespace":"","name":"al2-9x6cm","reconcileID":"ef9fbbda-8a18-4ebc-8378-e1455235597a","reason":"SecurityGroupDrift"}

Can you share a bigger chunk of logs? and include once that indicate marking drifted

To investigate, we enabled logLevel:debug and We were fortunate some nodes failed the drift due to some critical application preventing disruption, we are able to capture this.

{"level":"DEBUG","time":"2024-09-06T17:25:04.039Z","logger":"controller","message":"discovered amis","commit":"490ef94","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","EC2NodeClass":{"name":"default"},"namespace":"","name":"default","reconcileID":"3f603551-1ddd-4c9a-8371-9cb206cb4d37","ids":["ami-05e98588f28646469","ami-075fdaa4bc68dcc34","ami-0a0004f2412eb6547"]}

Karpenter drifts on ami change now?

Yes, Karpenter will drift on AMI updates: https://karpenter.sh/docs/concepts/disruption/#drift. When doing AMI discovery, Karpenter will discover the latest AMIs and update nodes. Here is an outline of the best ways to configure AMIs with Karpenter https://karpenter.sh/docs/tasks/managing-amis/


[KYUUBI #3510] Reading an uninitialized log should return empty rowSet

Why are the changes needed?

Fix https://github.com/apache/incubator-kyuubi/issues/3510
Reading an uninitialized log should return empty rowSet , So we can set EmptyRowSet for TFetchResultsResp to avoid client side NPE if FetchResults fail on server side.
For example: Configure log4j for ERROR level, causing the engine side no log file output, so server side throw java.nio.file. NoSuchFileException, at this time the client get engine log, throws the NPE.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #3511 (454f168) into master (dce40c3) will decrease coverage by 0.00%.
The diff coverage is 80.00%.

@@             Coverage Diff              @@
##             master    #3511      +/-   ##
============================================
- Coverage     51.67%   51.66%   -0.01%
  Complexity       13       13
============================================
  Files           482      482
  Lines         26933    26938       +5
  Branches       3760     3761       +1
============================================
  Hits          13918    13918
  Misses        11663    11663
- Partials       1352     1357       +5

Impacted Files
Coverage Δ

...org/apache/kyuubi/operation/log/OperationLog.scala
91.11% <80.00%> (-0.66%)
:arrow_down:

...pache/kyuubi/engine/YarnApplicationOperation.scala
62.96% <0.00%> (-1.86%)
:arrow_down:

...mon/src/main/scala/org/apache/kyuubi/Logging.scala
52.63% <0.00%> (-1.32%)
:arrow_down:

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
72.26% <0.00%> (-0.85%)
:arrow_down:

...n/scala/org/apache/kyuubi/engine/ProcBuilder.scala
80.74% <0.00%> (-0.63%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Concept for history of Digital Twins >> Alignment with IDTA on AAS-APIs

Alignment with IDTA on AAS-APIs

Obsolete for now


⚠ Mobitopup has degraded performance

In 8aba2eb, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 9035 ms

Resolved: Mobitopup performance has improved in 95aa7a4.


sideloadly.sideloadly version 0.25.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.1 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Does this program not show up in Add or Remove Programs?

Last time I checked it doesn't.
Also this should be moved to https://github.com/microsoft/winget-pkgs/tree/master/manifests/i/iOSGods/Sideloady.

The above mentioned version is unofficial to my knowledge.

@ItzLevvie What's the reason that package is called Sideloady instead of Sideloadly? Might want to rename that.

Unexpected typo because of no ARP entries 👀


[Enhancement]: Repackage AWS SDK  in localstack

Module
LocalStack
Proposal
Repackage the AWS SDK in the testcontainers localstack module, such as add a testcontainers prefix, in a previous experience, there are some API conflict in the project, due to the different version issues.

Hi @hantsy , can you explain a little bit more? Recent versions of LocalStack module doesn't provide transitive dependencies for AWS SDK.

Like wiremock, there is a standalone version to repackage all deps with a wiremock prefix in the new package, esp, the Jaskson module, to avoid the deps conflicts in my Spring project when running tests.
I will try the new version later, to check if the issue is still there.

I'm closing this issue because AWS SDK is not provided anymore in LocalStack.


Attention Grabber is giving attention to every 'a' randomly

Describe the bug
Sometimes the prompt will be littered with (a:1.1) or (a:1.9), where every single letter a has been given attention in the prompt.
To Reproduce
Steps to reproduce the behaviour, include the prompt you used if applicable:

Turn on attention grabber
Generate

Also mention which checkboxes have been set.
Attention Grabber
Expected behaviour
Every 'a' should not be given attention
Additional context
This is random and doesn't happen with every prompt.

I'm closing this issue - please re-open if it is still an issue.


Upgrade devtools

Upgrading devtools to 0.1.2. Most notable difference is that this reenabled reek. I also made a few modifications to address the things that reek flagged when it was reenabled

@dkubb ready for review

@backus thanks!


Check item.payload.docs is iterable before iterating

Fixes #39

@phillmac Looks good. Please confirm that the orbitdb/orbit-db tests pass successfully with this and I'll approve.


swarm/controller: allow cancellation to propagate

Ensure that cancellation of a pull propagates rather than continuing to
container creation. This ensures that the Prepare method is properly
re-entrant.
Signed-off-by: Stephen J Day<EMAIL_ADDRESS>cc @aluzzardi @aaronlehmann
Addresses aspects of #24447.

Failure is unrelated. This change doesn't touch build.

If the cancellation comes from a desired state change, would we retry preparing immediately?
Couldn't DeadlineExceeded be caused by a registry being down?
@aaronlehmann Are you able to repro the issue with and without this patch?

This seems to really mess things up.
A pull request is initiated and then cancelled (too much debug output from the pull to actually grab that info), and the image is never fully pulled, task reports "No such image".
If I run update again (like to change the image to something else) unfortunately it takes down a perfectly good task and starts trying to pull, it gets cancelled, and stuck again.
If I manually go and pull the image (this is a single host swarm), service ls lists all replicas as running (4/4 in this case), however 3 out of 4 containers are actually updated, with one still sitting on the original image. Swarm is no longer trying to bring the straggler up to date.... a subsequent update does seem to resolve the matter.

@aluzzardi Yes, this will retry immediately. The deadline errors don't propagate.

@cpuguy83 Instability fixed. fallbackError was hiding the context cancellation.
Just tested and confirmed this addresses the problem. I'll give it one more go on master to make sure we are actually reproducing.

Just did another round trip with master vs this PR and the results look good.  We still see the master errors but now the upgrade proceeds.
I also did a build with a log message, showing an interruption in the pull. This does converge but it is non-ideal.
This PR needs to be merged since it makes the system correct.
I am going to follow up with another PR that deals with the cancellation.

Yep, positive results here.
LGTM

LGTM


New Enterprise page on the website

Hi @vcoisne,
Here is the Enterprise page referred to the issue #1404 on the backlog: Website revamp on communication & structure w/ new pages. It adds a new page for the Enterprise section. It can be checked at http://localhost:8081/enterprise/
Notice that the header navigation and the footer will be changed in a separate PR. It also will need some work on the form to make it work. Maybe @dpordomingo can help.
Here is a screenshot of the full page:

Please let me know if everything is ok.
Thank you!

Thank you @znegrin.
Some minor edits:

Please remove "access in minutes. No credit card required". We're still figuring out how the trial will work.

Update title "Retrieval & Dependency Mapping" to "Automated Retrieval & Technology Mapping" and update the text under to "Automatically discover where your code is and map out your tech stacks both upstream and downstream so that you can asses, plan, execute and monitor your IT projects more effectively."

Updated description for "Flexible deployment options" to "The simplicity of one-click deployment or the flexibility of managed on-premise, choose who takes care of running the platform while keeping full control of your data."

Updated description for "Advanced queries and UDFs" to "The extensibility of the platform allows user to write custom user defined functions to extend their analysis beyond SQL queries."

One last thing sorry! The 4 use case title are as follow:

IT Modernization & Application Portfolio Management

DevOps & Cloud Native adoption

Engineering effectiveness & efficiency

Talent Assessment and Management

@vcoisne I updated the page. I guess it's only missing the proper form once it is prepared to be integrated. Thanks

Thank you @znegrin
We're not able to edit the styles on the form itself, unfortunately. Either you can find a quick workaround to customize the look & feel of the form on the page or we remove that section altogether, for now, so that we can ship the page faster.

Thank you @znegrin
We're not able to edit the styles on the form itself, unfortunately. Either you can find a quick workaround to customize the look & feel of the form on the page or we remove that section altogether, for now, so that we can ship the page faster.

Hi @vcoisne,
It seems that it actually can be styled if it is a pardot form:
https://help.salesforce.com/articleView?id=pardot_forms_add_css_classes_to_fields.htm&type=5
If I can get access to that, I could fix it so quickly and finish the integration.
Thank you!

@znegrin sent you credentials via DM.

Hi @vcoisne,
I just pushed a commit with the form integrated on the enterprise page.
I think it is now ready too.

Changing the target branch to be ee-candidate instead of master


Typeahead: OnSelectedItemChanged gets triggered twice

OnSelectedItemChanged get's triggered twice when clicking an item with the mouse or using the Enter button:
    <TypeaheadInput id="in1" class="form-control bg-dark" placeholder="@("Add Item ...")"
                @ref="refAddItemInput"
                Data="DataProvider.Items"
                LabelPropertySelector="x => x.Name"
                @bind-Value="@AddItemInput"
                SelectOnBlur="false"
                OnInput="@(text => {SelectedItemToAdd = null; typeaheadInputValue = text;})"
                TItem="Item"
                OnSelectedItemChanged="OnAddItem">
        <ItemTemplate>
            <div>
<EMAIL_ADDRESS>            </div>
        </ItemTemplate>
    </TypeaheadInput>
  ...
    private void OnAddItem(Item item)
    {
        Model.AddItemToActiveStash(item);
    }

Hi @AncientGrief, sorry for the late answer I was sick.
Yes checked it and it looks there is a double event triggering for OnSelectedItemChanged. Will resolve this in next release. Thanks.


Deleting a function project using file system leaves implicitDependency in firebase app

Generate a firebase function linked to a firebase app in the workspace
Delete that firebase function's directory from the workspace using just the filesystem
Try to run the sync generator
Note that Nx is unhappy because the deleted firebase function remains an implicitDependency of the project, so sync cannot do its work to cleanup because it cant read the projectGraph

It would be handy to be able to just delete a function project folder, rather than using nx g rm
   Node   : 18.13.0
   OS     : darwin-arm64
   pnpm   : 8.15.5

   nx                 : 16.8.1
   @nx/js             : 16.8.1
   @nx/jest           : 16.8.1
   @nx/linter         : 16.8.1
   @nx/workspace      : 16.8.1
   @nx/angular        : 16.8.1
   @nx/cypress        : 16.8.1
   @nx/devkit         : 16.8.1
   @nx/esbuild        : 16.8.1
   @nx/eslint-plugin  : 16.8.1
   @nx/node           : 16.8.1
   @nx/rollup         : 16.8.1
   @nrwl/tao          : 16.8.1
   @nx/web            : 16.8.1
   @nx/webpack        : 16.8.1
   typescript         : 4.8.4
   ---------------------------------------
   Community plugins:
   @ionic/angular         : 6.7.5
   @ionic/angular-toolkit : 8.1.0
   @ngrx/effects          : 14.0.2
   @ngrx/router-store     : 14.0.2
   @ngrx/store            : 14.0.2
   @ngrx/store-devtools   : 14.0.2
   @simondotm/nx-firebase : 2.3.0
   angular-calendar       : 0.28.28
   ng2-charts             : 3.1.2

One possibility is to not even use implicitDependencies in the firebase app project, just have the build step run-many with the firebase app project tag, but it is quite nice that the nx graph shows this relationship between firebase apps and firebase functions.


Improved form errors i18n

Features implemented in this PR:

Customized errors for specific fields by collection
Translated field label
Error context

1. Customized errors for specific fields by collection
I sometimes find the need to set a more concrete message for a particular field in a given collection. After thinking about this, the simplest solution it seemed to pass a collection property along the error when formatting the message, so from there errors can be filtered by collection and path.
For example, to set different messages for different fields:
'errors.required': `{name, select,
  image {Please add an image}
  other {Field "{name}" is required}
}`

And setting them by collections:
'errors.required': `{collection, select,
  users {{name, select,
    image {You must provide an image so others can see you!}
    other {Field "{name}" is required.}
  }}
  other {Field "{name}" is required.}
}`

As I've stated, this is the simplest solution from the standpoint of the codebase, and it delegates the problem to the strings definition/translation.
IMPORTANT: note that this feature will only work as described in the examples when using react-intl
2. Translated field label
Pass as property the translated label of the field to format message. This is done in the new FormError component, that uses the Form.getLabel method -received by context- to retrieve the field label.
So now when defining the message the translated label can be retrieved:
'errors.required': `Field "{label}" is required.`

Note that name property is kept so it can be used to construct strings based on the field name (as explained in the previous feature).
3. Error context
A context property is passed to format message. That way a different error message could be shown for inline errors -field context, named after the FieldErrors component- or the ones group for the entire form -form context, named after FormErrors.
Then the error string can be registered as:
'errors.required': `{context, select,
  field {Required}
  other {Field "{name}" is required.}
}`

IMPORTANT: note that this feature will only work as described in the example when using react-intl

@SachaG as noted, to really take advantage of 2 of the features the developer would have to use the entire react-intl package. Do you think it would be worth that Vulcan provides all the features of formatMessage by default?
If so, I could try to add it to the PR (using IntlMessageFormat and intl-format-cache).

This looks great, thanks!

Do you think it would be worth that Vulcan provides all the features of formatMessage by default?

What additional feature of react-intl would we need to support exactly?

Right now in Vulcan a simplified formatMessage function is defined on the vulcan:i18n provider, so in order to have the fully featured formatMessage we would have to directly use IntlMessageFormat.
I've seen that react-intl uses intl-format-cache, and it seems that it is to speed up the formatting (you can read more about this on the package readme).
I understand that the decision of not including any i18n package was to keep the bundle size low, and I'm not sure of how much will it increase by adding this 2 packages... IMHO having all the features is really worth it, but I also like approach of keeping Vulcan limited in i18n by default.

So the main feature we're missing is handling plurals/ordinals? I'm just not clear on what part of the PR exactly requires these extra features?

With Vulcan's default formatMessage you could not do the examples in points 1 and 3, because the missing {select} feature. That is why I was wondering whether to try to include the full formatMessage on Vulcan by default, but other than that this PR is fine.
Maybe I should have opened an issue to have that discussion, sorry.

btw: https://github.com/aldeed/simple-schema-js#custom-field-validation


Fast Compiles issue with debugging in IDE

Bevy version
Bevy 0.7.0
[Optional] Relevant system information
macOS Monterey 12.5
Intel Core i5
Intel Iris Plus Graphics 655 1536 MB
What you did
Exactly as https://bevyengine.org/learn/book/getting-started/setup/ "Enable Fast Compiles"
What went wrong
Test in VSCode and CLion, while cargo run --features=bevy/dynamics runs well, Debug mode in IDE can't properly work.
Terminal Report:
dyld[11362]: Library not loaded<EMAIL_ADDRESS>  Referenced from: '/path_to_proj/bevy_playground/target/debug/bevy_playground'
  Reason: tried: '/usr/local/lib/libstd-2b42fd6bb1400760.dylib' (no such file), '/usr/lib/libstd-2b42fd6bb1400760.dylib' (no such file)
Signal: SIGABRT (signal SIGABRT)
Terminated due to signal 6

Same report in VSCode and CLion.
Additional information
The launch.json for VSCode:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cargo launch",
            "type": "lldb",
            "request": "launch",
            "cargo": {
                "args": [
                    "build",
                    "--features=bevy/dynamic"
                ],
            },
            "cwd": "${workspaceFolder}",
            "args": []
        },
    ]
}

The project is quite easy (In fact it's just a hello world):
use bevy::prelude::*;

fn main() {
    println!("Hello, world!");
    App::new().run();
}

This issue block me from using breakpoint... which really hurts me.

This is almost certainly an upstream issue, but I'm not entirely sure where to point you.

You need to add the output of rustc --print target-libdir and target/debug/deps to the DYLD_LIBRARY_PATH (LD_LIBRARY_PATH on unixes other than macOS and PATH on Windows) env var (separated by a colon (:), or a semicolon (;) on windows). Rustup and cargo do this for you if you use cargo run, but when VSCode directly invokes the executable without setting this env var.

You need to add the output of rustc --print target-libdir and target/debug/deps to the DYLD_LIBRARY_PATH (LD_LIBRARY_PATH on unixes other than macOS and PATH on Windows) env var (separated by a colon (:), or a semicolon (;) on windows). Rustup and cargo do this for you if you use cargo run, but when VSCode directly invokes the executable without setting this env var.

Problem solved, thx!
Note that target/debug/deps is in the project directory.


Email config: Visualize what the different possible replacement possibilities are

{{invoiceNr}} etc...
Tooltip? Popover?
For email body, email title and invoice filename

and also the new replacements: {consultantName}

This is in: invoiceReplacements (download-helpers.ts)


Cumulative-packages

Lmk if this looks good to you

You can also just rebase: I removed the packageManager entry.

LGTM. Much cleaner now :heart_eyes:

Feel free to self merge after running pnpm run format.

FYI my thinking for resolving conflicts:
{
  value: Function
  // A "magic number" can be used for determining ordering
  order?: 'pre' | 'post' | number
  // The value always get's overridden (i.e. the value is non-cumulative)
  default?: true
  // Override all inherited values. Set to 'all' to also override values set by Vike extensions.
  clear?: true | 'all'
}

For the magic number: https://github.com/magne4000/universal-handler/discussions/4.
This can (eventually) already be implemented by vike-vue, no need for Vike core changes. But let's see if/when the need arises.
I think, as we progressively move towards the Stem vision, we'll eventually need this, let's see :eyes:


World space translation

Hello there,
Thanks for your amazing work and it really helps me a lot. But I have some questions about the output of ROMP.

I notice there are two camera related output, "cam" and "cam_trans" respectively and they are both of dimension 3. What is the difference between these two?
With the purpose of getting person's translation in world coordinate, how can I make use of the output of ROMP?
Any help will be appreciate!!

Thanks for the quick reply.
I found the code on how to convert "cam" to "cam_trans" using convert_cam_to_3d_trans function. I also notice another conversion here with the code:
trans = [cam_tx, cam_ty, 2FOCAL_LENGTH/(CROP_SIZEcam_s + 1e-9)]
I am wondering the difference between these two.
Also, I am able to get a reasonable world translation to UE5 using "cam_trans" but things don't go right way when I try the conversion code above. Can you explain a little bit?


Release azure-cli-monitor 0.0.5

Reviewers, please verify the following for this PR:

[ ] The PR title has format Release <component-name> <version>.
[ ] setup.py has been modified with the same version as in the PR title.
[ ] HISTORY.rst has been modified with appropriate release notes.
[ ] If releasing azure-cli or azure-cli-core, __version__ defined in __init__.py should also be modified to match.

Started releasing azure-cli-monitor 0.0.5...

Release of 'azure-cli-monitor' with version '0.0.5' successful. View at https://pypi.python.org/pypi/azure-cli-monitor/0.0.5.

GitHub release created. https://github.com/Azure/azure-cli/releases.


Http, login/logout, emitters

I tweaked this and it seems to be in good shape.  I did a lot of modifications including moving Group class over to its own file.  I had thought to access the class directly to use in other scripts, but it turned out setting up an emiiter with robot.on was easier to use in other scripts.  The Group class probably could be put back into the main script if desired.
I've updated the Readme with the main updates.
Not sure how package.json should look now, I copied this repo over from a hubot i had been working onfor it so it may have added extra stuff.  I did put the version up to 1.9.0 there, or attempted to.
I think this is my first public merge request so go easy on me :)

@anishathalye any news?
will this PR be merged?

This is a lot of new functionality, and it's definitely cool, but I don't want to add all these features to hubot-group. Thank you for taking the time to submit the PR. Perhaps it's best if you maintain this as a parallel fork. Happy to link to it from the hubot-group readme, if you would like.


table record height wrong

Current table shows wrong record height:

Should look like this:

Maybe because of #173 PoC with row height?

this should be fixed now by adding a feature flag disabling this behaviour by default -> #173