Turtlebot4 Raspberry Pi wifi connect fail

Robot Model
Turtlebot4 Standard
ROS distro
Humble
Networking Configuration
I do not know
OS
Ubuntu 22.04
Built from source or installed?
Installed
Package version
sudo apt update && sudo apt install ros-humble-turtlebot4-desktop
Type of issue
Networking
Expected behaviour
1 - turn on turtlebot4
2 - connect to "turtlebot4" wifi on PC
3 - "ssh<EMAIL_ADDRESS>to configure wifi setup on PC
4 - "turtlebot4-setup" & (Access point -> client) & change SSID & change Passward & click save, then click Apply setting
5 - Done
Actual behaviour
1 - turn on turtlebot4
2 - connect to "turtlebot4" wifi on PC
3 - "ssh<EMAIL_ADDRESS>to configure wifi setup on PC
4 - "turtlebot4-setup" & (Access point -> client) & change SSID & change Passward & click save, then click Apply setting
5 (fail point) - return error message "client_loop: send disconnect: Broken pipe" on PC
5.1 - IP: UNKNOWN on Turtlebot

Error messages
client_loop: send disconnect: Broken pipe

To Reproduce
explanated in Actual behaviour
Other notes
No response

Additional:
After the error have been occured, the turtlebot4 wifi is removed, so I need to connect with LAN cable directly or reinstall Raspberry Pi image.

When connecting with LAN cable directly:
Followed the user manual, the error "ssh: connect to host <IP_ADDRESS> port 22: No route to host" is occured when connect to turtlebot4 using ssh.

Reinstall Raspberry Pi image:
The error described above is reproduced.

Hello,
Is the wi-fi network you are connecting to an institutional wi-fi network with additional security or is the security limited to a wpa2 password?
Is this behaviour repeated across all networks or this specific network?
Looking forward to hearing from you soon.
Best Regards,
Saif

I've just replicated the same behavior with the same configuration. Unknown IP as a result of using turtlebot4-setup and loss of wifi broadcast after using person wpa2 home network

Hello @iyeon915 and @DDJared ,
Apologies for the late reply on this. A quick note on the error: client_loop: send disconnect: Broken pipe Seeing this after saving and applying the settings to Turtlebot4 setup is normal, this pops up as a result of the Turtlebot4 Access Point being disabled when you set the Turtlebot 4 from ap mode to client mode.
Regarding the unknown IP address, are you able to SSH into the raspberry pi using an ethernet connection? Double check to ensure that the computer is set to use the 185 subnet. Alternatively you can also disable Wi-Fi on your computer to ensure that the ethernet interface is used to connect to the Pi.
Looking forward to hearing from you soon.
Best Regards,
Saif

Hello @iyeon915 and @DDJared ,
Any updates regarding this? Looking forward to hearing from you soon.
Best Regards,
Saif

Hello,
This issue is being closed due to inactivity. If you are still experiencing the issue, feel free to reopen this ticket when you are ready to continue the troubleshooting process.
Best Regards,
Saif


Sitemap has trailing slash for homepage

I believe the problem is related to this issue, but wasn't quite sure how to implement the fix.
The homepage has a trailing slash for the first page, which is a problem for SEO because Google / other search engines think it's a different page since the default version of the homepage does not have a trailing slash.
Any idea how we fix?

Not sure how to fix this issue for now.
Btw, I noticed the issue also appears on https://astro.build/sitemap-0.xml.

@davidvkimball @saicaca
import { defineConfig } from "astro/config";
import sitemap from "@astrojs/sitemap";

// https://astro.build/config
export default defineConfig({
	site: "https://kb.l4ph.moe",
	trailingSlash: "never",
	integrations: [sitemap()]
});

Doing the above seems to solve the problem, but I think there is a high possibility that this will cause problems with the application itself,
so I will investigate this a bit myself.

@davidvkimball
Could you please tell me what behavior you would like to see?
If you probably want to be strict and set it yourself, using trailingSlash: "never" should solve the problem.
https://docs.astro.build/en/reference/configuration-reference/#trailingslash


Steps to run the website on local server

Please write steps to run the website on local server

Would love to see 'how to' steps, because I have installed the theme, but i'm getting errors.

Same for me, I get the following errors:
Building sites … WARN 2020/07/15 21:56:28 found no layout file for "HTML" for kind "taxonomyTerm": You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2020/07/15 21:56:28 found no layout file for "HTML" for kind "taxonomyTerm": You should create a template file which matches Hugo Layouts Lookup Rules for this combination

Installation steps have been added to the readme.
Thanks for the feedback.


change error.field -> rule.field

Actually when we have to do some i18n process on the error message, we have to inject the proper field name into the message but not the field name in code (such as password VS 密码).
In async-validator developer can assign the correct field name with the fullField rule property, but when the field validation is failed the error return should contain the original field name that we can use it to do some other things what it is not do now.

Coverage remained the same at 88.095% when pulling dfe30bb709c912ef62c9985ae412ed7ef933d490 on iwillwen:master into 3bb694304eda41b24eaa2dcd269e7cd466234e3d on yiminghe:master.

Example:
const validator = new Schema({
  password: { type: 'string', required: true, min: 6, max: 20, fullField: '密码' }
})
validator.validate({ password: 123456 }, (errors, fields) => {
  console.log(fields.password)  //=> undefined
  console.log(fields['密码']) //=> correct, but WTF?
})

No, you can not use fullField, it's not a api, only for internal usage, use message for i18n

@yiminghe
Thanks for your response. Actually I knew the fullField is a private variable, but I did not find any way to define a method or a callback function for transforming the field name into the correct format or correct language I want in the source code.
The messages part in async-validator just only allow me to define a regular string format to receive the original field name.
For example, if thepassword field is required so that I want async-validator feedback the message like 密码必填, but not password 必填.
There are two solution to solve the issue.

message could be a function, so that it could be defined by the developers to make the error message just like they want.

validator.messages({
  required: rule => `${i18n(rule.field)}必填`
})

every single rules of every field could be assigned.

new Schema({
  password: {
    type: 'string',
    required: {
      enabled: true,
      message: '密码必填'
    }
  }
})

Or
new Schema({
  password: {
    type: 'string',
    required: true,
    messages: {
      required: '密码必填'
    }
  }
})

I agree with functional message. Welcome pr.

@yiminghe how about add a LocalizedField to RuleItem? for instance ValidateMessage<[LocalizedField | FullField, ...]> , preserve the default internal validation messages.


Update the donation page

I'm assuming this means replacing the gofundme with a custom form. We can do this using WPForms: https://wpforms.com/how-to-create-a-nonprofit-donation-form/
Do we have a Stripe account set up? If not, can you set one up?


Fix typos in docs

Just fixing some typos.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm


WIP - a start for the Authorization design doc

Closing PR.   Authorization is no longer on the roadmap.

Closing PR.   Authorization is no longer on the roadmap.


Validation icons position problem

I have just updated to v4.3.1 I am importing bootstrap scss in my scss and I noticed the X icon is at the far right corner and the css is wrongly compiled. I see in comment that I am suing 4.3.1 bootstrap but at docs there is this css rule:
background-position: center right calc(.375em + .1875rem);
but my compiled version is: background-position: 100% calc(.375em + .1875rem);

Same problem for me but i can add more context:
Everything is correct when doing development builds with sass, but production builds do have the wrong css rule as outlined by Webotvorba.

Without a demo, can't help. https://getbootstrap.com/docs/4.3/components/forms/#validation shows the icons as intended.

It is known problem with cssnano minifier used in Optimize CSS Assets Webpack Plugin :
https://github.com/cssnano/cssnano/issues/712

@Webotvorba
I too just ran into this on v4.3.1. https://github.com/twbs/bootstrap/pull/28814 fixes for me on<EMAIL_ADDRESS>npm still at 4.3.1 atm.


hyprctl hyprpaper wallpaper requires monitor arg

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit fe7b748eb668136dd0558b7c8279bfcd7ab4d759  (props: bump version to 0.39.1).
Date: Tue Apr 16 16:01:03 2024
Tag: v0.39.1, commits: 4460

flags: (if any)

System Information:
System name: Linux
Node name: Murmaider
Release: 6.6.27-1-lts
Version: #1 SMP PREEMPT_DYNAMIC Sat, 13 Apr 2024 11:50:59 +0000

GPU information:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [Geforce RTX 3070 Ti Laptop GPU] [10de:24a0] (rev a1) (prog-if 00 [VGA controller])
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c7) (prog-if 00 [VGA controller])

os-release: NAME="EndeavourOS"
PRETTY_NAME="EndeavourOS"
ID="endeavouros"
ID_LIKE="arch"
BUILD_ID="2023.11.17"
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://endeavouros.com"
DOCUMENTATION_URL="https://discovery.endeavouros.com"
SUPPORT_URL="https://forum.endeavouros.com"
BUG_REPORT_URL="https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports"
PRIVACY_POLICY_URL="https://endeavouros.com/privacy-policy-2"
LOGO="endeavouros"

plugins:

Hyprpaper Version: 0.6.0-4

Bug or Regression?
Bug
Description
In ~/.config/hypr/hyprpaper.conf I can set this:
wallpaper = , /path/to/image.png

And it will load that image on all monitors. However if I try to use ipc like this:
hyprctl hyprpaper wallpaper ",/path/to/image.png"
or
hyprctl hyprpaper wallpaper ,~/path/to/image.png
Nothing happens.
How to reproduce
hyprctl hyprpaper wallpaper ",/path/to/image.png"
Crash reports, logs, images, videos
No response

Noticed it's a dupe of https://github.com/hyprwm/hyprpaper/issues/157


When DiscoveryComplete fails, the flow is confusing

When an implementation of ITestDiscoveryEventsHandler.HandleDiscoveryComplete fails (no matter if we or user implements it), e.g. because they try to add lastChunk into a collection, but you forget to null check, your handler will throw an exception, which is handled and HandleDiscoveryComplete is triggered again. So you get:
https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.VsTestConsole.TranslationLayer/VsTestConsoleRequestSender.cs#L999-L1017
DiscoverComplete IsAborted: False,
LogMessage: Error,
DiscoveryComplete IsAborted: True
exception is rethrown, because you will fail to handle the message again, but this time you are not in try, catch:

Instead maybe we should throw directly.

True, but not an issue that anyone else reported. Adding to translation layer redesign doc.


docs(adr): Created an ADR for MSW

Hey, I just made a Pull Request!

Here's the ADR that closes this RFC: #1205

:heavy_check_mark: Checklist

[ ] All tests are passing yarn test
[ ] Screenshots attached (for UI changes)
[ ] Relevant documentation updated
[ ] Prettier run on changed files
[ ] Tests added for new functionality
[ ] Regression tests added for bug fixes

@benjaminr please add this to the rest of the docs and nav before merging.

@freben - not sure if it will mock by default, I can investigate. Otherwise a simple handler in the jest setup of server.use('*') should suffice.

Cool. Then maybe we can put that in the setupTests file in the plugin template

Maybe it is important to mention, that MSW doesn't work together with require('jest-fetch-mock').enableMocks(); that is in multiple setupTests.ts files. I had a bit trouble adding tests with MSW to backstage because of mocking twice 😆

Please also add to docs TOC in /docs/README.md

Oh and 👍  to never allowing any unmocked calls through, those should always just make the test explode, maybe segfault and burn the rack too. No manual step should be involved in setting that up either :p

@Rugvip created https://github.com/spotify/backstage/issues/1755 to cover the create-plugin boilerplate


Bump eth2spec to v0.11.2

Issue
It would be great to sync the spec & pypi releases.
Not in urgent but it's better to be done before the next release.
/cc @djrtwo

will do!

done
https://pypi.org/project/eth2spec/0.11.2/


generate a js library

generate a js library

https://github.com/kevinresol/hxgenjs

commons js done.
es module needs to be tested

commonjs fully tested in the tester html file.

done and tested in #17


Scaled login screen

This PR adds a scaling capability to the login screen, so that it is actually readable on high DPI (or 'retina') displays.
The DPI value for the login screen can be obtained from the client when running in a full-screen mode. If the session is
set to less than the full screen size, the DPI value cannot be calculated and behaviour is the same as current behaviour.
An additional font sans-18.fv1 is added to the distribution for higher DPI screens.
Also of note; the Windows utility to build font files has been replaced with two native UNIX utilities:-

xrdp-dumpfv1 : Display contents of an fv1 font file
xrdp-mkfv1 : Create new fv1 font files (only available if xrdp is built with --with-freetype2).

The user is able to generate their own fv1 font files and configure the system to use them, if required.
See discussion #2280 for a history of this PR, and the initial request from @HubKing.
@TOMATO-ONE has provided some excellent testing and feedback during the development of this PR.
Future work could involve using the freetype2 library to load truetype fonts directly. This would allow us to add anti-aliasing and kerning to the login screen.

@matt335672 Can you share some screenshots? The PR itself LGTM.

I'll add something to the wiki - it will help in the future I think.

https://github.com/neutrinolabs/xrdp/wiki/Scaleable-login-screen on the Wiki contains some shots of the login box, and answers some questions users may have.

Thanks!


Help for --audio might be incorrect. Shouldn't it be pactl list sources?

Yes I think it should be pacmd list-sources | grep "name:" like is is in the wiki.

You're right, thanks. Hadn't checked the wiki. I opened a very simple PR just to speed things up.


Connection refused when running tye run

Describe the bug
If you tye run you get SocketException: Connection refused
This is the log after running tye run --docker, using the second step of tutorial.
Console logs:
▶ tye run --docker
Loading Application Details...
Launching Tye Host...

[16:11:34 INF] Executing application from C:\p\rabiscos\tye\trytye\microservice\tye.yaml
[16:11:35 INF] Dashboard running on http://<IP_ADDRESS>:8000
[16:11:35 INF] Publishing project C:\p\rabiscos\tye\trytye\microservice\frontend\frontend.csproj
[16:11:35 INF] Publishing project C:\p\rabiscos\tye\trytye\microservice\backend\backend.csproj
[16:11:40 INF] Docker image mcr.microsoft.com/dotnet/core/sdk:3.1 already installed
[16:11:40 INF] Docker image redis:alpine already installed
[16:11:40 INF] Creating docker network tye_network_d531406b-6
[16:11:40 INF] Running docker command network create --driver bridge tye_network_d531406b-6
[16:11:41 INF] Running image mcr.microsoft.com/dotnet/core/sdk:3.1 for frontend_72f9bbf8-e
[16:11:41 INF] Running image mcr.microsoft.com/dotnet/core/sdk:3.1 for backend_583c1456-2
[16:11:41 INF] Running image redis:alpine for redis_4c783cbf-0
[16:11:41 INF] Running image redis:alpine for redis-cli_51993053-7
[16:11:42 INF] Running container redis_4c783cbf-0 with ID acc58b805a49
[16:11:42 INF] Running docker command network connect tye_network_d531406b-6 redis_4c783cbf-0 --alias redis
[16:11:42 INF] Running container redis-cli_51993053-7 with ID ccf2a3b3b8b4
[16:11:42 INF] Running docker command network connect tye_network_d531406b-6 redis-cli_51993053-7 --alias redis-cli
[16:11:43 INF] Collecting docker logs for redis_4c783cbf-0.
[16:11:43 INF] Collecting docker logs for redis-cli_51993053-7.
[16:11:45 INF] Running container frontend_72f9bbf8-e with ID 7bd5ae7a1e95
[16:11:45 INF] Running docker command network connect tye_network_d531406b-6 frontend_72f9bbf8-e --alias frontend
[16:11:45 INF] Collecting docker logs for frontend_72f9bbf8-e.
[16:11:47 INF] Running container backend_583c1456-2 with ID 405601e41f91
[16:11:47 INF] Running docker command network connect tye_network_d531406b-6 backend_583c1456-2 --alias backend
[16:11:47 INF] Collecting docker logs for backend_583c1456-2.

Exception log on page;
System.Net.Http.HttpRequestException: Connection refused
 ---> System.Net.Sockets.SocketException (111): Connection refused
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Microsoft.Extensions.Http.Logging.LoggingHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at frontend.WeatherClient.GetWeatherAsync() in C:\p\rabiscos\tye\trytye\microservice\frontend\WeatherClient.cs:line 24
   at frontend.Pages.IndexModel.OnGet(WeatherClient client) in C:\p\rabiscos\tye\trytye\microservice\frontend\Pages\Index.cshtml.cs:line 23
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.ExecutorFactory.NonGenericTaskHandlerMethod.Execute(Object receiver, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeHandlerMethodAsync()
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeNextPageFilterAsync()
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.Rethrow(PageHandlerExecutedContext context)
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeInnerFilterAsync()
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

This is tye.yaml:
name: microservice
registry: giggio
services:
  - name: frontend
    project: frontend/frontend.csproj
  - name: backend
    project: backend/backend.csproj
  - name: redis
    image: redis:alpine
    bindings:
      - port: 6379
        connectionString: "${host}:${port}"
  - name: redis-cli
    image: redis:alpine
    args: "redis-cli -h redis MONITOR"

Further technical details

Include the output of tye --version: 0.1.0-alpha.20209.5+e3fc0045bd1e5913da935241874761929f1e8465
If possible rerun the command with -v debug and include the output: (not available with tye run)
The platform (Linux/macOS/Windows): Windows

I can reproduce this on macOS also

I think I have an understanding of the issue. Some archeology...
The service discovery env-vars point frontend->backend via https://backend:80
Attaching a shell to frontend and seeing if we can talk to the backend:
docker exec -it frontend_c37fa3d9-7 bash
curl http://backend:80/weatherforecast -v

< HTTP/1.1 307 Temporary Redirect
< Date: Fri, 10 Apr 2020 20:40:01 GMT
< Server: Kestrel
< Content-Length: 0
< Location: https://backend:55643/weatherforecast

curl https://backend:55643/weatherforecast -v --insecure

Gets me a connection-refused.
curl https://backend:443/weatherforecast -v --insecure

Gets me the actual data.

In this case the https redirect uses 55643 based on the value passed in by Tye of HTTPS_PORT. However there's a problem with that. The port you want to redirect to is contexutal depending on who's asking.
If the request came from inside the container network then 443 is the right answer, if it came from outside the container network then 55643 is the right answer.

@davidfowl

UGH 😄

The fix here is to revert back to the docker host instead of container names.


Remove imports and instantiation from settings.py

Move reporter and tracer instantiation out of settings.py and into AppConfig.ready
Prefix all settings with WF
Update tracing class to instantiate default tracer automatically

I see this has entered the review process, so I will leave it open and welcome feedback, but as I have worked with this for a couple of days, I think it adds too much complexity. I am going to try a different approach, which will not rely on the AppConfig.
The current instructions for this project suggest adding this to INSTALLED_APPS, but before this pull request I think that is not required, and it would be preferable to keep it that way.  Also note that the opentracing-contrib django implementation also does not require an installed app.


Add a route for easy redirects to the start request flow

Details
This allows for easy URLs that can link straight to the request flows. These are used in promotional messages.
This is intended to only work with web and for people that are using mobile, we expect it to open on mobile web.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/352160
Tests

Go to https://dev.new.expensify.com:8082/start/request/manual
Verify you see the manual request start page
Go to https://dev.new.expensify.com:8082/start/request/scan
Verify you see the scan request start page
Go to https://dev.new.expensify.com:8082/start/request/distance
Verify you see the distance request start page

[ ] Verify that no errors appear in the JS console

Offline tests
None, this doesn't really work offline.
QA Steps
NOTE: You only need to test web and mobile web. This isn't intended to work on other platforms.

Go to https://staging.new.expensify.com:8082/start/request/manual
Verify you see the manual request start page
Go to https://staging.new.expensify.com:8082/start/request/scan
Verify you see the scan request start page
Go to https://staging.new.expensify.com:8082/start/request/distance
Verify you see the distance request start page

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native CANNOT BE TESTED
[x] Android: mWeb Chrome CANNOT BE TESTED
[x] iOS: Native CANNOT BE TESTED
[x] iOS: mWeb Safari CANNOT BE TESTED
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop CANNOT BE TESTED

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Should we add a C+ for review?

I'd be interested if requires C+ review

Sure, go for it.

@situchan do we think you'll have review done today?

yes I'll

@tgolen please merge main

I can, but is it necessary to?

I can, but is it necessary to?

just for safety. as 800 commits behind

I think it's OK. There is nothing wrong with being 800 commits behind if there are no conflicts or changes to the areas being touched.

I think it's OK. There is nothing wrong with being 800 commits behind if there are no conflicts or changes to the areas being touched.

nvm, I am pulling main locally since there was expo image PR merged in between, which requires full android re-build

Please remove :8082 in QA steps

RHP page is opened 2 times
https://github.com/Expensify/App/assets/108292595/9f170a2c-158e-47d0-a878-869c45326cee
And console error:

Thanks for reporting the issue with the RHP opening twice. It doesn't appear like you are following the test steps, where the intention is just to modify the URL to go to those links. I guess I can add a dismissModal() aftering doing the redirect, but do you think it's necessary?

Thanks for reporting the issue with the RHP opening twice. It doesn't appear like you are following the test steps, where the intention is just to modify the URL to go to those links. I guess I can add a dismissModal() aftering doing the redirect, but do you think it's necessary?

I think that should be fixed. We can try either dismissModal or navigation replace

OK, fixed and updated.

Can you also please check console error? I think the logic should be moved to component mount (useEffect with empty array dependency). It's not recommended to directly call function in render.

Oh, sorry I forgot about that. I changed the component so that it doesn't redirect until the component has been mounted and this solves the console error. In order to prevent the "not found" page from briefly showing, I am just having the component return null so that nothing is displayed.

Console error when redirect https://dev.new.expensify.com:8082/start/request/other
Also empty screen shows.
I think the expected behavior is to show not found page
Actual:

Expected:

OK, I added some type checking in order to show the "not found" page when there is an invalid URL param. I tested with these URLs:

https://dev.new.expensify.com:8082/start/bad/manual
https://dev.new.expensify.com:8082/start/request/bad
https://dev.new.expensify.com:8082/start/bad/bad

I think the console prop type error is fine in these cases. The only way to make the error go away would be to relax the propType definition to accept any string, and I'd rather keep it strict.

OK, I've added the screenwrapper. I was not sure which options were necessary, but I think that since the only child is the "not found" page, then none of the settings for padding or max height are needed?

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/108292595/2f386270-a63e-42d1-b5c8-d67f5b05184c

Android: mWeb Chrome
https://github.com/Expensify/App/assets/108292595/bd251157-b69d-47b6-a4a8-2299d75711af

iOS: Native
https://github.com/Expensify/App/assets/108292595/d2791831-f7e0-4311-9bdc-1a14aa1ba25e

iOS: mWeb Safari
https://github.com/Expensify/App/assets/108292595/6cd2e3f2-d2a7-4593-9bc0-25e4866eb388

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/108292595/8b82cfe7-99c4-4267-9528-25ba416db9dd
https://github.com/Expensify/App/assets/108292595/39cb1eef-456c-4a19-9a8b-cc8b3d84651d

MacOS: Desktop

OK, I've added the screenwrapper. I was not sure which options were necessary, but I think that since the only child is the "not found" page, then none of the settings for padding or max height are needed?

I think not needed. Also tested. If something is required even for this simple page, maybe better to update that prop as always required in propType.

If something is required even for this simple page, maybe better to update that prop as always required in propType.

Yes, this is a good call. I was reading the comments for each of the prop types, and a lot of them left me in a very confused state. Such as:

/** Whether to include padding bottom */

Why should it have padding bottom or not??

/** Whether KeyboardAvoidingView should be enabled. Use false for screens where this functionality is not necessary */

How do I know if the functionality is necessary or not if the functionality is not explained?

/** Whether to use the maxHeight (true) or use the 100% of the height (false) */

How would I know which one I should use?

/** Whether to use the minHeight. Use true for screens where the window height are changing because of Virtual Keyboard */

Finally! This one comes pretty close to giving a proper explanation.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/Beamanator in version: 1.4.19-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.19-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


[TIDY FIRST] Type BaseRunner class

Resolves #10606
Problem
The BaseRunner class is largely untyped. Given the prevalence of this class, not having it typed could mean that there are potential edge cases and/or runtime exceptions we are not aware of. By typing this class, we give ourselves a lot more guarantees
Solution
Add typing. Of note, adding this typing uncovered a potential runtime exception in the on_skip method. We address this in 5adce38.
Checklist

[x] I have read the contributing guide and understand what's expected of me.
[x] I have run this code in development, and it appears to resolve the stated issue.
[x] This PR includes tests, or tests are not required or relevant for this PR.
[x] This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
[x] This PR includes type annotations for new and modified functions.

The BaseRunner and it's derivatives unfortunately need to be refactored before we can properly type them 😞


Apply the Kotlin plugin for Kotlin language support

Context

Many users will benefit from this change because it addresses an issue where creating a Kotlin library with gradle init gives the impression that the Kotlin plugin is not applied correctly. By fixing this issue, users will have a smoother experience when setting up Kotlin projects with Gradle, leading to increased productivity and reduced confusion.

Contributor Checklist

✅ Review Contribution Guidelines.
✅ Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
✅ Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
✅ Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
✅ Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
✅ Provide unit tests (under <subproject>/src/test) to verify logic.
✅ Update User Guide, DSL Reference, and Javadoc for public-facing changes.
✅ Ensure that tests pass sanity check: ./gradlew sanityCheck.
✅ Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

Thank you for your interest in Gradle.
Please create an issue first justifying these changes. We cannot accept them otherwise.

Sorry, the change you propose will not solve the issue (however, the issue itself is not clear to us).


Fix Pylint Error on Master

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[ ] The PR has modified HISTORY.rst with an appropriate description of the change (see Modifying change log).

Command Guidelines

[ ] Each command and parameter has a meaningful description.
[ ] Each new command has a test.

(see Authoring Command Modules)

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7ee6730). Click here to learn what that means.
The diff coverage is 75%.

@@            Coverage Diff            @@
##             master    #3459   +/-   ##
=========================================
  Coverage          ?   70.94%
=========================================
  Files             ?      396
  Lines             ?    25805
  Branches          ?     3908
=========================================
  Hits              ?    18308
  Misses            ?     6358
  Partials          ?     1139

Impacted Files
Coverage Δ

src/azure-cli-core/azure/cli/core/azlogging.py
71.26% <ø> (ø)

...azure-cli-core/azure/cli/core/commands/progress.py
85.85% <75%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7ee6730...bcfee98. Read the comment docs.


[#1344] 1.7.3-hotfix-feature-res-warning-popup

This pr is a hotfix for issue #1344.

@pkdash could you review this hotfix? thanks

@pkdash could you review this hotfix

The error can be ignored as it's the test_sax_parsing


KeyCeremony when trustees are not trusted

if the trustees are not trusted, we could do other verification tests in keyCeremonyExchange.
//  are the public keys valid?
//  are the encrypted shares valid?
//  are the unencrypted shares valid?

// TODO KeyShare should include ξi,ℓ

Out implementation doesnt use nonce ξi,ℓ . Not sure if thats a problem.
// spec 2.0.0, p 24 "Share verification"
// If the recipient guardian Gℓ reports not receiving a suitable value Pi (ℓ), it becomes incumbent on the
// sending guardian Gi to publish this Pi (ℓ) together with the nonce ξi,ℓ it used to encrypt Pi (ℓ)
// under the public key Kℓ of recipient guardian Gℓ . If guardian Gi fails to produce a suitable Pi (ℓ)
// and nonce ξi,ℓ that match both the published encryption and the above equation, it should be
// excluded from the election and the key generation process should be restarted with an alternate
// guardian. If, however, the published Pi (ℓ) and ξi,ℓ satisfy both the published encryption and the
// equation above, the claim of malfeasance is dismissed, and the key generation process continues undeterred.
// footnote 28 It is also permissible to dismiss any guardian that makes a false claim of malfeasance. However, this is not
// required as the sensitive information that is released as a result of the claim could have been released by the claimant
// in any case.


WIP AC-121 support 22.04 build

I haven't tested it yet, but that is my intent. Still working on just getting a host to come up and start a VM in my home lab.

Decided not to do this work, this will not need to progress further. We are staying CentOS for now.


Search is case sensitive for Cyrillic letters

Version 0.2.1
I just noticed, that I can't find some items using search bar. And, as my testing show, if I mane item with uppercase letter in Cyrillic, I have to search the same way.
That is not the case with Latin letters
https://youtu.be/XJRTfYEDWDU

What database backend (e.g. mysql / postgresql / etc) are you using?

I don't remember. How to check this?

I think it is sqlite3

If you're using sqlite, this is a known limitation (although I only just found out about it).
https://docs.djangoproject.com/en/dev/ref/databases/#substring-matching-and-case-sensitivity
You might need to migrate to either MySQL or postgresql database

@Acvarium I've added a note about this to the docs.


[SPARK-48900] Add reason field for cancelJobGroup and cancelJobsWithTag

What changes were proposed in this pull request?

This PR introduces the optional reason field for cancelJobGroup and cancelJobsWithTag in SparkContext.scala, while keeping the old APIs without the reason, similar to how cancelJob is implemented currently.
Why are the changes needed?

Today it is difficult to determine why a job, stage, or job group was canceled. We should leverage existing Spark functionality to provide a reason string explaining the cancellation cause, and should add new APIs to let us provide this reason when canceling job groups.
Details:
Since SPARK-19549 Allow providing reasons for stage/job cancelling - ASF JIRA (Spark 2.20), Spark’s cancelJob and cancelStage methods accept an optional reason: String that is added to logging output and user-facing error messages when jobs or stages are canceled. In our internal calls to these methods, we should always supply a reason. For example, we should set an appropriate reason when the “kill” links are clicked in the Spark UI (see code).
Other APIs currently lack a reason field. For example, cancelJobGroup and cancelJobsWithTag don’t provide any way to specify a reason, so we only see generic logs like “asked to cancel job group ”. We should add an ability to pass in a group cancellation reason and thread that through into the scheduler’s logging and job failure reasons.
This feature can be implemented in two PRs:

Modify the current SparkContext and its downstream APIs to add the reason string, such as cancelJobGroup and cancelJobsWithTag

Add reasons for all internal calls to these methods.

Note: This is the first of the two PRs to implement this new feature
Does this PR introduce any user-facing change?

Yes, it modifies the SparkContext API, allowing users to add an optional reason: String to cancelJobsWithTags and cancelJobGroup, while the old methods without the reason are also kept. This creates a more uniform interface where the user can supply an optional reason for all job/stage cancellation calls.
How was this patch tested?

New tests are added to JobCancellationSuite to test the reason fields for these calls.
For the API changes in R and PySpark, tests are added to these files:

R/pkg/tests/fulltests/test_context.R
python/pyspark/tests/test_pin_thread.py

Was this patch authored or co-authored using generative AI tooling?

No

@cloud-fan Hi Wenchen, since last time you reviewed it, I addressed the comments and also synced the changes to R, Python, and Java SparkContext API, making it consistent with the Scala API. The additional changes are in:

org/apache/spark/api/java/JavaSparkContext.scala
python/pyspark/core/context.py
R/pkg/R/sparkR.R

and additional tests are added here:

R/pkg/tests/fulltests/test_context.R
python/pyspark/tests/test_pin_thread.py

Would appreciate it if you could also take a look at these changes!

thanks, merging to master!


Confirm password development warning

Summary | Résumé
Fixes warning where the password confirmation field was changing from uncontrolled component into a controlled component.

Test instructions | Instructions pour tester la modification

Test registration page
Note the uncontrolled  warning is now gone.

Pull Request Checklist
Please complete the following items in the checklist before you request a review:

[x] Have you completely tested the functionality of change introduced in this PR? Is the PR solving the problem it's meant to solve within the scope of the related issue?
[x] The PR does not introduce any new issues such as failed tests, console warnings or new bugs.
[ ] If this PR adds a package have you ensured its licensed correctly and does not add additional security issues?
[ ] Is the code clean, readable and maintainable? Is it easy to understand and comprehend.
[ ] Does your code have adequate comprehensible comments? Do new functions have docstrings?
[ ] Have you modified the change log and updated any relevant documentation?
[ ] Is there adequate test coverage? Both unit tests and end-to-end tests where applicable?
[ ] If your PR is touching any UI is it accessible? Have you tested it with a screen reader? Have you tested it with automated testing tools such as axe?

Looks like the login_page.cy.ts test is failing but that issue is already in the branch so going to merge this.


Error during EKS Creation:  Post "http://localhost/api/v1/namespaces/kube-system/configmaps": dial tcp <IP_ADDRESS>:80: connect: connection refused

Description
When creating an EKS Cluster using terraform, we get the following error:
Error: Post "http://localhost/api/v1/namespaces/kube-system/configmaps": dial tcp <IP_ADDRESS>:80: connect: connection refused

  on .terraform/modules/deployment.eks/aws_auth.tf line 65, in resource "kubernetes_config_map" "aws_auth":
  65: resource "kubernetes_config_map" "aws_auth" {

To fix this, we have to manually run:
aws eks update-kubeconfig --name ${var.context.app_name} --region ${var.context.region}

and then:
terraform apply -auto-approve

Versions

Terraform: 0.12.21
Provider(s):

aws - 3.22.0
terraform-aws-modules/eks/aws - 14.0.0
terraform-aws-modules/vpc/aws - 2.61.0

AWS CLI: 2.0.30
Helm: 3.3.4
Kubectl:  1.19.0

Reproduction

Run the terraform code in the Code Snippet to Reproduce section
Run terraform init && terraform apply -auto-approve
You will get the error in the description.

To fix, manually run:

aws eks update-kubeconfig --name ${var.context.app_name} --region ${var.context.region}
terraform apply -auto-approve

Code Snippet to Reproduce
terraform {
  required_version = ">= 0.12.21"
}

provider "aws" {
  version = "~> 3.22.0"
  region  = "${var.context.region}"
}

data "aws_availability_zones" "available" {}

resource "random_string" "suffix" {
  length  = 8
  special = false
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "2.61.0"

  name                 = "${var.context.app_name}"
  cidr                 = "<IP_ADDRESS>/16"
  azs                  = data.aws_availability_zones.available.names
  private_subnets      = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
  public_subnets       = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
  enable_nat_gateway   = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  tags = {
    "kubernetes.io/cluster/${var.context.app_name}" = "shared"
  }

  public_subnet_tags = {
    "kubernetes.io/cluster/${var.context.app_name}" = "shared"
    "kubernetes.io/role/elb"                      = "1"
  }

  private_subnet_tags = {
    "kubernetes.io/cluster/${var.context.app_name}" = "shared"
    "kubernetes.io/role/internal-elb"             = "1"
  }
}

resource "aws_security_group" "all_worker_mgmt" {
  name_prefix = "${var.context.app_name}-all_worker_management"
  vpc_id      = "${module.vpc.vpc_id}"

  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"

    cidr_blocks = [
      "<IP_ADDRESS>/8",
      "<IP_ADDRESS>/12",
      "<IP_ADDRESS>/16",
    ]
  }
}

module "eks" {
  source                               = "terraform-aws-modules/eks/aws"
  version                              = "14.0.0"
  cluster_name                         = "${var.context.app_name}"
  cluster_version                      = "1.19"
  subnets                              = "${module.vpc.private_subnets}"
  vpc_id                               = "${module.vpc.vpc_id}"
  cluster_create_timeout               = "30m"
  worker_groups = [
    {
      instance_type = "${var.context.kubernetes.aws.machine_type}"
      asg_desired_capacity = "${var.context.replica_count}"
      asg_min_size = "${var.context.replica_count}"
      asg_max_size  = "${var.context.replica_count}"
      root_volume_type = "gp2"
    }
  ]
  worker_additional_security_group_ids = ["${aws_security_group.all_worker_mgmt.id}"]
  map_users = var.context.iam.aws.map_users
  map_roles = var.context.iam.aws.map_roles
}

Expected behavior
The cluster gets created successfully
Actual behavior
We get this output:
Error: Post "http://localhost/api/v1/namespaces/kube-system/configmaps": dial tcp <IP_ADDRESS>:80: connect: connection refused

  on .terraform/modules/deployment.eks/aws_auth.tf line 65, in resource "kubernetes_config_map" "aws_auth":
  65: resource "kubernetes_config_map" "aws_auth" {

It looks like the Kubernetes provider isn't receiving a configuration. Here's how I configure mine, which is similar to the EKS module README except it's for the newer version of the Kubernetes provider. (My team recently released version 2.0 of the Kubernetes provider and it requires a slightly different config than shown in this module's README).
data "aws_eks_cluster" "default" {
  name = module.cluster.cluster_id
}

data "aws_eks_cluster_auth" "default" {
  name = module.cluster.cluster_id
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.default.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.default.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.default.token
}

@dak1n1  - The code example I provided does NOT instantiate the kubernetes provider (at least not directly).  The error happens during creation of the EKS module - not before or after.  So - the problem happens in the EKS module itself - not outside of the module.

Right, but the EKS module uses the Kubernetes provider under the hood, so it needs a provider configuration. Otherwise, it will assume a default/empty config. You can skip using the Kubernetes provider within the EKS module by specifying manage_aws_auth  = false in your EKS module config. That will skip the section that relies on the Kubernetes provider.
module "cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "14.0.0"
...
  manage_aws_auth  = false
...
}

I have the same issue on a newly created cluster everything is fine and then I'm changing the module tag and get this error, the weird thing is that if I put everything back just like in the state everything work as expected

@dark1n1 How am I supposed to instantiate the Kubernetes provider using output from this module, but before I instantiate this module?

it probably won't apply to many people, but in case that can help: I had this config:
provider "kubernetes" {
  host                   = data.aws_eks_cluster.this.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.this.certificate_authority[0].data)
  config_context         = data.aws_eks_cluster.this.arn
  token                  = data.aws_eks_cluster_auth.this.token
}

Somehow, removing the "config_context" line made this error disappear ...

I have never set manage_aws_auth yet I experienced the variant where I had changed the name of the eks module and tried all kinds of cache invalidation to no avail. Issue was resolved by changing the name of the module back to what it had been in the state.

@dak1n1 this issue is being caused by https://github.com/hashicorp/terraform/issues/24886 (which is also a pretty large pain point in implementing a Hashicorp native credential flow e.g. OIDC -> Vault STS -> AWS provider). Without this being solved what is the logic for a aws_eks_cluster_auth not to be created until something else has been configured? The current "best practice" pattern errors when you plan and don't apply for over 15 mins; it also errors when you've layered other code on top of this module and a control plane or managed worker change take over 15 mins to complete.
TL;DR - Is there a hack to make a aws_eks_cluster_auth resource wait for something else before being calculated so we can target these to be ready when they're not going to expire?

@stevehipwell Do you think this might be related to the issue you mentioned above ?

@ArchiFleKs I suspect that it's related and I meant to add a comment to that effect. We're having to delete the aws_auth config map from state when we destroy a cluster, see https://github.com/terraform-aws-modules/terraform-aws-eks/issues/1280#issuecomment-810533105.

@stevehipwell Yes my workaround is:

remove aws_auth from state
apply with `manage_aws_auth=false
import configmap `aws_auth to state
apply with manage_aws_auth=true

@ArchiFleKs have you tried reverting the Kubernetes provider version?

@ArchiFleKs have you tried reverting the Kubernetes provider version?

To which version ? before v2.0 ?

That'd be my first suggestion, and if it works see is any of the v2 versions also work.

I am also looking into best practices, although currently I use a single terraform run to deploy some dependencies, this eks module, and a bunch of helm charts and kubernetes yaml files.
Currently, using kubernetes provider version = "~> 1.11.1" and terraform 0.14.11 (and also manage_aws_auth=true) I am not experiencing big issues. ( I do need to refresh before destroy, but I feel that is expected). My provider blocks look like this:
provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
}

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
    token                  = data.aws_eks_cluster_auth.cluster.token
  }
}

provider "kubectl" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
}

I though of sharing my versions and blocks in case someone finds it useful.
Still, will keep around the discussion, in case I get an issue in the future and we can come up with workarounds.

We encountered this trouble too and @grandria find another workaround : set a good value to KUBE_CONFIG_PATH export KUBE_CONFIG_PATH=$KUBECONFIG according the official doc: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/guides/v2-upgrade-guide

I experience this issue too and alike @jaimehrubiks I am as well using eks as a submodule and install a good amount of helm charts and other stuff into the cluster. I have had huge problems with token lifetimes in the past and always had to spin up clusters in two steps. 1st create the cluster, then error because there is no token, replan and apply with a token now.
I configured my providers like this in the submodule to overcome these problems:
data "aws_eks_cluster" "this" {
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster]
}

data "aws_eks_cluster_auth" "this" {
  count      = module.eks_control_plane.cluster != null ? 1 : 0
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster]
}

provider "kubernetes" {
  alias                  = "initial"
  host                   = data.aws_eks_cluster.this.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.this.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.this[0].token
}

data "aws_eks_cluster" "iam" {
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster, module.aws_auth]
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.iam.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.iam.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.iam.id, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
    command     = "aws"
  }
}

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.iam.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.iam.certificate_authority[0].data)
    exec {
      api_version = "client.authentication.k8s.io/v1alpha1"
      args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.iam.id, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
      command     = "aws"
    }
  }
}

With this I can spin up a cluster and install helm charts and other stuff in a single plan/apply.
Using the aws eks get-token command it is easy to get a long living token for helm but I need to add the configuration for Atlantis to the cluster first, so that I can actually get such a token. This is done by the "initial" provider. It installs the aws-auth configmap, which is managed in a seperate module apart from the eks cluster itself.
Yet I experience this error:
Error: Get "http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth": dial tcp [::1]:80: connect: connection refused

The data blocks to configure the provider are empty somehow and I cannot just reference a kube config since I want to be able to still use Atlantis and it's easy iam assumeables for authentification.
If I get said error I go into the local terraform file cache under .terraform/modules/$module-name and edit the provider files for the clusters into this:
data "aws_eks_cluster" "this" {
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster]
}

data "aws_eks_cluster_auth" "this" {
  count      = module.eks_control_plane.cluster != null ? 1 : 0
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster]
}

provider "kubernetes" {
  alias                  = "initial"
  host                   = module.eks_control_plane.cluster.endpoint
  cluster_ca_certificate = base64decode(module.eks_control_plane.cluster.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", module.eks_control_plane.cluster.name, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
    command     = "aws"
  }
}

data "aws_eks_cluster" "iam" {
  name       = module.eks_control_plane.cluster.name
  depends_on = [module.eks_control_plane.cluster, module.aws_auth]
}

provider "kubernetes" {
  host                   = module.eks_control_plane.cluster.endpoint
  cluster_ca_certificate = base64decode(module.eks_control_plane.cluster.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", module.eks_control_plane.cluster.name, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
    command     = "aws"
  }
}

provider "helm" {
  kubernetes {
    host                   = module.eks_control_plane.cluster.endpoint
    cluster_ca_certificate = base64decode(module.eks_control_plane.cluster.certificate_authority[0].data)
    exec {
      api_version = "client.authentication.k8s.io/v1alpha1"
      args        = ["eks", "get-token", "--cluster-name", module.eks_control_plane.cluster.name, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
      command     = "aws"
    }
  }
}

This works everytime once the cluster is already spun up. But I cant just use it like that, since I cannot spin up cluster in a single plan/apply fashion any more. I don't understand tho why the datablocks become stale and empty, even refreshing them doesn't help at all

We encountered this trouble too and @grandria find another workaround : set a good value to KUBE_CONFIG_PATH export KUBE_CONFIG_PATH=$KUBECONFIG according the official doc: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/guides/v2-upgrade-guide

Actually this technique is working, but it is a bit hard to set when running in a CI for example and kubeconfig is not present

okay, I think I somehow solved the problem at least for me.
I just moved the data blocks into the eks module and set an output with a depends on like this:
resource "time_sleep" "wait_a_second" {
  depends_on = [aws_eks_cluster.this[0]]

  create_duration = "30s"
}

data "aws_eks_cluster" "this" {
  count      = var.enabled ? 1 : 0
  name       = aws_eks_cluster.this[0].name
  depends_on = [aws_eks_cluster.this[0], time_sleep.wait_a_second]
}

data "aws_eks_cluster_auth" "this" {
  count      = var.enabled ? 1 : 0
  name       = aws_eks_cluster.this[0].name
  depends_on = [aws_eks_cluster.this[0], time_sleep.wait_a_second]
}

output "aws_eks_cluster" {
  value      = var.enabled ? data.aws_eks_cluster.this[0] : null
  depends_on = [aws_eks_cluster.this[0], time_sleep.wait_a_second]
}

output "aws_eks_cluster_auth" {
  value      = var.enabled ? data.aws_eks_cluster_auth.this[0] : null
  depends_on = [aws_eks_cluster.this[0], time_sleep.wait_a_second]
}

(I know putting the depends_on twice is actually redundant, but I just like to make really sure)
Anyway, I then refer to that in my parent module inside the providers:
provider "kubernetes" {
  alias                  = "initial"
  host                   = module.eks_control_plane.aws_eks_cluster.endpoint
  cluster_ca_certificate = base64decode(module.eks_control_plane.aws_eks_cluster.certificate_authority[0].data)
  token                  = module.eks_control_plane.aws_eks_cluster_auth.token
}

provider "kubernetes" {
  host                   = module.eks_control_plane.aws_eks_cluster.endpoint
  cluster_ca_certificate = base64decode(module.eks_control_plane.aws_eks_cluster.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", module.eks_control_plane.aws_eks_cluster.id, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
    command     = "aws"
  }
}

provider "helm" {
  kubernetes {
    host                   = module.eks_control_plane.aws_eks_cluster.endpoint
    cluster_ca_certificate = base64decode(module.eks_control_plane.aws_eks_cluster.certificate_authority[0].data)
    exec {
      api_version = "client.authentication.k8s.io/v1alpha1"
      args        = ["eks", "get-token", "--cluster-name", module.eks_control_plane.aws_eks_cluster.id, "--role-arn", "arn:aws:iam::${var.aws_account_id}:role/Atlantis"]
      command     = "aws"
    }
  }
}

That module gets sourced multiple times in a single aws account to spin up a load of clusters and this somehow gave me the least problems. The sleep makes the api more resilient to timing problems ( so I feel at least )

I'm facing the same issue after trying to change the tags of the cluster

Okay, I found out what is the problem. Spent the entire day to fix it :)
TL;DR

Move k8s provider to aws_auth.
Set correct configuration for k8s provider as shown below.
Configure aws cli before running terraform.

It's a bad idea to set manage_aws_auth to false like someone offered before. There's a block in EKS module that is dependent on it. So, just keep default for manage_aws_auth that is set to "true".
First of all, I put k8s provider configuration inside aws_auth.tf:
provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", var.cluster_name]
    command     = "aws"
  }
}

This is the only one correct configuration for eks that is also pointed out in official doc.
U can also use pre-generated kubeconfig file from aws eks update-kubeconfig, but it also uses same aws eks get-token under the hood. So you don't have hardcoded token anyway. It will be always dynamically generated from aws command.
Back to the main point: since there's an aws command to get token - u need to pre-configure it before running terraform:
aws configure set aws_access_key_id ${AWS_ACCESS_KEY_ID} --profile ${AWS_PROFILE}
aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile ${AWS_PROFILE}
aws configure set region $AWS_DEFAULT_REGION --profile ${AWS_PROFILE}

And Voila, it works!

We've been told by Hashicorp to always use the exec plugin for Kubernetes providers to stop this issue or ones like it. FYI Azure AKS has an even bigger problem with this than AWS EKS.

@huguesalary
The way to get around the issue - configure kubernetes provider like I posted above. Generating configmap instead of installing it - will break the process of joining cluster from worker nodes. So what is the point then?

Has anyone managed to work this out yet? I'm hitting this issue constantly. I have a similar setup to that described by @huguesalary
The dependency chain looks like this:

terraform-aws-eks <-- my-private-eks-implementation <-- my-private-cluster

I am using the exec block in the provider like so;
data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

provider "kubernetes" {
  alias                  = "eks_cluster"
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.cluster.name]
    command     = "aws"
  }
}

I am also passing this provider to the base eks module (I've tried without doing this too - same issue);
  providers = {
    # Reference to kuberntes provider, see below
    kubernetes = kubernetes.eks_cluster
  }

I've tried putting provider in the top level module, but it can't access the EKS cluster details (creates a cyclic dependency).
The cluster creates fine in the first execution - but subsequent runs of terraform plan fail with this problem, every time;
......kubernetes_config_map.aws_auth[0]: Refreshing state... [id=kube-system/aws-auth]
Error: Get "http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth": dial tcp <IP_ADDRESS>:80: connect: connection refused

I'm really hoping someone has found a way around this?

@pauldtill
Do you have aws cli installed in enviro where you run terraform? Is it configured properly (AWS creds, AWS region is configured for profile) and terraform exec plugin knows which aws profile to use?

@ikarlashov yes - aws cli is present, the pipeline passes in AWS credentials and region, immediately before running any terraform commands the pipeline runs ;
aws sts get-caller-identity < the output is printed to the log, this is working fine, the same pipeline is used to deploy in the first place, which uses that setup too - the cluster creates OK, it is on running a plan after creation it hits this issue.

@pauldtill
Sounds ok. For troubleshooting try to put plain values for endpoint and cluster CA and even token. If you do so, based on my experience, at least you'll get meaningful error output. Attempt to connect to <IP_ADDRESS> is a fallback connection when k8s provider couldn't establish connection with your exec plugin .

@ikarlashov thanks, I'm just concerned about the mentions of using multiple modules to achieve this.
I have;
Top Private Module (declares tfvars) -> 2nd Private Module (creates all resources and calls open source EKS module to create cluster) -> Open Source EKS module
The 2nd module is where the provider is declared with the exec to connect - from what I'm reading this might be an issue due to the way Terraform handles providers? I just couldn't see how I could get this into the top level module, as it needs to reference data this is created in the bottom level.
Hope this makes some sense.
I'll try with some plain text values too see if that reveals anything else too.

@ikarlashov ran with plain text values for endpoint and CA - also added "--debug" to the aws command, hasn't revealed anything - same error. I'm not providing as the recommendation is to use exec to get this right ?

@pauldtill try to comment out exec block completely and pass token from aws eks command as a plain text. K8s provider can't handle aws cli errors and fallback to localhost connection. So it's very important to see what's wrong with your connection to the cluster.

@ikarlashov just tried this, same error. I obtained a token from aws cli get-token command, then hard coded it as below, commenting the exec block - is this what you meant?
provider "kubernetes" {
  alias                  = "eks_cluster"
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = "k8s-aws-v1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  # exec {
  #   api_version = "client.authentication.k8s.io/v1alpha1"
  #   args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.cluster.name]
  #   command     = "aws"
  # }
}

Error is still as below from the plan command;
Error: Get "http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth": dial tcp <IP_ADDRESS>:80: connect: connection refused

@pauldtill try to comment out alias as well. Also put plain host and cluster_ca_certificate, don't rely on datasource content.

So hard coding it all has worked - the plan command is successful. Not sure what else I can do now?

@pauldtill Very weird. It might be something wrong with aws cli (path to isn't in PATH variable maybe?).
I think you also tried with exec plugin but without alias, right?

@pauldtill @huguesalary the exec plugin might have issues using data.aws_eks_cluster.cluster.name in the command, I'd strongly suggest using the raw variable/locals you're passing in to the module to create the cluster.

@stevehipwell - tried using a string for the cluster name, same error.
@ikarlashov - the aws cli is definitely working fine in the pipeline, it is being used for other aspects, plus the initial creation of the cluster works fine, it is only when we make a change and try to run a plan that it fails. Surely this would fail if there were a fundamental issue with the aws cli?
I'm completely stuck with this now - I can successfully create the cluster over and over (and destroy) with the same pipeline, any attempt to update it post creation, fails with this error on the plan step every time.

@pauldtill have you tried using the module outputs instead of a data resource for host and cluster_ca_certificate (see below)?
provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", local.cluster_name]
  }
}

Here is what I have now - this is still failing with the same error;
provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    args        = ["eks", "get-token", "--cluster-name", local.eks_cluster_name]
    command     = "aws"
  }
}

I know my aws CLI isn't the issue, I've just successfully deployed a helm chart which uses this syntax to for the provider, from the same pipeline platform, of course this is embedded in the helm provider, but it still uses the exec command successfully, and it is using "data" for the host and cert too;
provider "helm" {
  kubernetes {
    host = data.aws_eks_cluster.eks.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks.certificate_authority[0].data)
    exec {
      api_version = "client.authentication.k8s.io/v1alpha1"
      args        = ["eks", "get-token", "--cluster-name", local.eks_cluster_name]
      command     = "aws"
    }
  }
}

@pauldtill what are your versions for TF and the module?

Terraform - v0.14.11
Module - 17.23

@pauldtill could you try with the latest v1 version?

@stevehipwell - we are using a docker image for the build pipeline, it's only got up to v14 on. I'll have to run through some changes to pick it up, let me try it out and come back to you. Thanks for the quick responses on this by the way.

@pauldtill kind of unrelated but I'd suggest looking at tfenv (see below for how we add it to our runners).
RUN set -eu; \
  tfenv_version="2.2.2"; \
  curl -sfL -o /tmp/tfenv.tar.gz "https://codeload.github.com/tfutils/tfenv/tar.gz/refs/tags/v${tfenv_version}"; \
  tar -xzf /tmp/tfenv.tar.gz -C /tmp; \
  mv "/tmp/tfenv-${tfenv_version}" ~/.tfenv; \
  rm -rf /tmp/*; \
  ln -s ~/.tfenv/bin/* /usr/local/bin; \
  echo "latest" > ~/.tfenv/version; \
  tfenv install "latest:^0\.12\.[0-9]\+$"; \
  tfenv install "latest:^0\.13\.[0-9]\+$"; \
  tfenv install "latest:^0\.14\.[0-9]\+$"; \
  tfenv install "latest:^0\.15\.[0-9]\+$"; \
  tfenv install "latest:^1\.[0-9]\+\.[0-9]\+$"; \
  tfenv install "latest"; \
  tfenv list;

@stevehipwell - for info, going to TF v1.0.11 seems to have resolved this issue! Thanks for your input.
Thanks for the info on tfenv, I'll get that implemented too.

same here.
$ terraform plan
╷
│ Error: Get "http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth": dial tcp <IP_ADDRESS>:80: connect: connection refused
│
│   with module.eks.kubernetes_config_map.aws_auth[0],
│   on .terraform/modules/eks/aws_auth.tf line 63, in resource "kubernetes_config_map" "aws_auth":
│   63: resource "kubernetes_config_map" "aws_auth" {
$ terraform version
Terraform v1.1.0
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v3.63.0
+ provider registry.terraform.io/hashicorp/cloudinit v2.2.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.6.1
+ provider registry.terraform.io/hashicorp/local v2.1.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/template v2.2.0
+ provider registry.terraform.io/terraform-aws-modules/http v2.4.1

$ cat <pre>kubernetes.tf
provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  token                  = data.aws_eks_cluster_auth.cluster.token
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
}

> We met same error when we try to add extra subnets to the VPC and EKS, removed the extra subnets, the error disappeared

I was able to solve my problem in the same way, I have a module to manage network resources and another module to manage the EKS cluster.
First I created the cluster with two subnets but then we had the requirement to create another subnet, after applying these changes I had problems with my EKS module, I had to specify only my two old subnets to avoid the problem (private_subnet_id[0], private_subnet_id[1])

> We met same error when we try to add extra subnets to the VPC and EKS, removed the extra subnets, the error disappeared
I was able to solve my problem in the same way, I have a module to manage network resources and another module to manage the EKS cluster. First I created the cluster with two subnets but then we had the requirement to create another subnet, after applying these changes I had problems with my EKS module, I had to specify only my two old subnets to avoid the problem (private_subnet_id[0], private_subnet_id[1])

This happened to us, as well; we wanted to expand our cluster into additional subnets (specifically, the worker node ASGs, not so much the control plane); of course, by default the ASGs use the same set of subnets as the cluster control plan, and, apparently, you can't change the subnets of the cluster control plane. That said, it's a bit wild to me that this causes the planning phase to fall back to querying localhost. It's not easy to tell from Terraform's default logging what step is going wrong, but maybe setting TF_LOG to TRACE would reveal more.

This issue has been resolved in version 18.0.0 :tada:

@antonbabenko we're still seeing this issue using v18.0.5 of this module. I see in the upgrade doc that:

Support for managing aws-auth configmap has been removed. This change also removes the dependency on the Kubernetes Terraform provider, the local dependency on aws-iam-authenticator for users, as well as the reliance on the forked http provider to wait and poll on cluster creation. To aid users in this change, an output variable aws_auth_configmap_yaml has been provided which renders the aws-auth configmap necessary to support at least the IAM roles used by the module (additional mapRoles/mapUsers definitions to be provided by users)

...and we have shifted to using the new aws_auth_configmap_yaml module output as suggested, and are now using what I believe is the recommended kubernetes provider config:
################################################################################
# Kubernetes provider configuration: How terraform auth{n,z} to a cluster
################################################################################
data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.cluster.token
}

...but don't understand what about the release fixed this issue, or what other config this fix is dependent on. Any advice would be appreciated. We could raise another issue, but I feel this is likely a misunderstanding on our part.

The issue was marked as resolved by release v18 because we removed the management of the aws-auth confit map from the module (what the issue was created for)

Thanks @bryantbiggs. So, does this mean that it would be expected that this issue would still occur in a terraform project which uses v18+ of this eks module, and still uses the kubernetes provider? That's us. We're still managing our aws_auth config map in the same project which of course requires the kubernetes provider. I understand this was moved out of the eks module.

It's possible; it's highly dependent on how your resources are configured, network connectivity, and what actions you are taking

OK, thanks for the info. We're first going to try using the exec plugin to handle kubernetes provider authentication, as some others have recommended above.

@timblaktu the tl;dr here is use the exec plugin for all Kubernetes based providers.
The long answer is that if you ask HashiCorp how to do this you will get many different, usually incorrect, answers. Of these two actually work; the "official" one is that you can't use Kubernetes in the workspace where it was created, the "engineering" one is to use the exec plugin and make sure you plan out your dependencies correctly.

@stevehipwell thanks so much for those insights. I'm trying your "engineering" answer and want to dive a bit into the "make sure you plan out your dependencies correctly" part. I've changed my kubernetes provider config (which used to specify a token) to use the exec plugin for auth, like this:
provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", module.eks.cluster_id]
  }
}

and am still getting the "localhost connection refused" error, presumably the first time the kubernetes provider tries to reach out to the cluster. In my case this is at the declaration of a "kubernetes_role" "configmap_update" resource, which causes it to try to Get "http://localhost/apis/rbac.authorization.k8s.io/v1/namespaces/kube-system/roles/configmap-update".
So,

How do I know my exec plugin is working?
What can I do to ensure the dependencies in my eks/k8s project are "planned out correctly" to avoid this issue?

@timblaktu I've used the following pattern when layering on top of an EKS cluster created by this module for a number of major releases. I think the important point here is to use the module outputs for host and cluster_ca_certificate rather than a data object due to the way Terraform manages it's data collection. I also use the local.cluster_name input variable that I pass into the module rather than module.eks.cluster_id but I suspect that it might not make any difference.
provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", local.cluster_name]
  }
}

Thanks again, @stevehipwell! This appears to be the final (and quite obscured!) wisdom that completely solves this issue. Using v18 of the module doesn't fix it by itself. Using an exec plugin in your kubernetes provider config doesn't fix it by itself. Your last point is also essential to the solution: you can't workaround this bug completely if you are referring to eks cluster data sources in your kubernetes provider config.
It's too bad that more issues aren't followed up on after being closed with the resulting essential tribal wisdom like we (mostly you) did here. But I guess that's the way of open source, no? If we (the tribe) doesn't do it, who will? Thanks again!

@lrstanley Probably it would make the most sense for this info to go prominently into the eks module documentation, since ultimately this is a bug in the module implementation, as noted here, and is the reason why all of these "all planets in alignment" work arounds are necessary.

@timblaktu this isn't an issue with this module, it's a general Terraform defect disguised as a design choice. I agree that the docs here could be updated with some "suggestions" on use, but HashiCorp should be the ones documenting how their providers work (as noted above don't hold your breath). Remember the maintainers have removed the nested provider in the module so provider logic belongs to the workspace consuming the module; HashiCorp own supporting this now.

@dak1n1  Hi Dak1n1 , I run into the same issue and fix this issue by your method , glad to to see you

I am not sure if I understand the solution correctly: Is it to use exec instead of data source for token and have the host and cluster_certificate initialised from the module outputs instead of the data object as suggested above?
That is what I have done (hopefully no silly mistakes there):
provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", var.cluster_name]
  }
}

But I am still getting the original error:
╷
│ Error: configmaps "aws-auth" already exists
│
│   with module.eks.kubernetes_config_map.aws_auth[0],
│   on .terraform/modules/eks/main.tf line 453, in resource "kubernetes_config_map" "aws_auth":
│  453: resource "kubernetes_config_map" "aws_auth" {
│
╵

All I am doing is spinning up an emtpy cluster with eks_managed_node_groups.
This workaround does help, but is kind of ugly:
$ terraform apply
   ..error..
$ terraform import module.eks.kubernetes_config_map.aws_auth kube-system/aws-auth`
$ terraform apply

It is probably possible to avoid the error by saying -target=module.eks in the first apply, but what I am really up to is to avoid whole this dance altogether. Is that somehow possible or have I misunderstood the thread above and this IS the solution, at least for now?

It looks like the Kubernetes provider isn't receiving a configuration. Here's how I configure mine, which is similar to the EKS module README except it's for the newer version of the Kubernetes provider. (My team recently released version 2.0 of the Kubernetes provider and it requires a slightly different config than shown in this module's README).
data "aws_eks_cluster" "default" {
  name = module.cluster.cluster_id
}

data "aws_eks_cluster_auth" "default" {
  name = module.cluster.cluster_id
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.default.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.default.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.default.token
}

This worked for me.

You can declare an env variable in your GitHub YAML like that and this will work:
env:
KUBE_CONFIG_PATH: /home/runner/.kube/config


refine/document error handling

What is best practice for error logs - always create one and empty means no errors or no log if no errors?
We need to have some "debugging" section in doc explaining how we handle errors and logs

Best practice imho is to provide a runtime report that can cover both simple statistics and errors or warnings when applicable. The purpose is to give a user concrete feedback.
For a run without errors, the output can be very simple statistics like the total run-time (in seconds?) and the number of records processed which would vary per process.  One approach for number of records would be to count the number of .ABOUT files created for genabout, and the number reported for about or genattrib.
would be to count the number of .ABOUT files created for genabout, and the number reported for about, updated

I think we can close this.
The tool has already provided simple stats such as number of ABOUT files created and error (if any)
I don't think the run-time is needed as it runs pretty fast, and it doesn't give any useful information.


spec bug when looking up vtable from a ptr not pointing to a vtable

The following test panics the interpreter:
#[test]
fn ub_method_lookup() {
    let mut p = ProgramBuilder::new();

    let mut t_builder = p.declare_trait();
    let meth1 = t_builder.declare_method();
    let _trait_name = p.finish_trait(t_builder);

    let main = {
        let mut f = p.declare_function();
        let x = f.declare_local::<i32>();
        let y = f.declare_local_with_ty(Type::Ptr(PtrType::FnPtr));
        f.storage_live(x);
        f.storage_live(y);
        f.assign(y, vtable_lookup(addr_of(x, Type::Ptr(PtrType::VTablePtr)), meth1));
        f.exit();
        p.finish_function(f)
    };

    let p = p.finish_program(main);
    assert_ub::<BasicMem>(p, "invalid pointer for vtable lookup");
}

The problem is that a pointer of type VTablePtr doesn't necessarily point to a vtable. This is fine; the bug is in the part of the code that assumes all pointers of this type must point to vtables.
Cc @Indeximal

This is easily fixed by using vtable_from_ptr in the interpretation of vtable_lookup. However, it's still non-obvious that the unwrap in vtable_lookup() can never fail. Also having two functions, vtable_lookup and vtable_from_ptr, that do similar but different things with different signatures, is quite confusing.


Restart Documentation

Codecov Report

Merging #71 (2e4cbfe) into main (ea66015) will increase coverage by 1.34%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #71      +/-   ##
==========================================
+ Coverage   60.96%   62.30%   +1.34%
==========================================
  Files           2        2
  Lines         187      191       +4
==========================================
+ Hits          114      119       +5
+ Misses         73       72       -1

Impacted Files
Coverage Δ

src/Molecule.py
51.04% <ø> (+0.69%)
:arrow_up:

tests/test_molecule.py
95.83% <100.00%> (+0.37%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea66015...2e4cbfe. Read the comment docs.


Mini player controls are not centered.

OS: macOS Sierra v10.12.6
Issue Descriptions: When enabling the mini player, the controls area should be centred, which is not the case. See screenshot below.
Steps to Reproduce: Enable mini player.

Merging into #2269 (mini player zoom issues)


Generate crud controllers with explicit fields and columns, not setFromDb

This PR replaces the setFromDb() statements in the CrudController stub with actual columns or fields. When someone generates a CrudController, here's how what they're getting is different:
    protected function setupListOperation()
    {
-        $this->crud->setFromDb();
+        CRUD::column('category_id');
+        CRUD::column('title');
+        CRUD::column('slug');
+        CRUD::column('content');
+        CRUD::column('image');
+        CRUD::column('status');
+        CRUD::column('date');
+        CRUD::column('featured');
+        CRUD::column('deleted_at');
+        CRUD::column('created_at');
+        CRUD::column('updated_at');
    }

    protected function setupCreateOperation()
    {
        $this->crud->setValidation(ArticleRequest::class);

-        $this->crud->setFromDb();
+        CRUD::field('category_id');
+        CRUD::field('title');
+        CRUD::field('slug');
+        CRUD::field('content');
+        CRUD::field('image');
+        CRUD::field('status');
+        CRUD::field('date');
+        CRUD::field('featured');
    }

By having explicit fields and columns, it will be MUCH easier for the developers to do what they normally do:

change the type of a field/column
change the label of a field/column
remove a field/column
add a new field/column

In 99% of all use cases, I expect this to be better than the old setFromDb() thing we generated before.
We use the new fluent syntax that came with 4.1, since that's the one that is easiest to use for this type of changes.

Note:

this will create fields & columns for 1-n relationships (because there's a category_id column);
this will NOT create fields & columns for n-n relationships (because there's no column and no good way to fetch all relationships from an Eloquent Model);

To also support n-n relationships, in the future, we could:

fetch all methods on the Model;
parse the model file and see if the method calls a relationship method (belongsTo, hasOne, etc);
if so, add that relationship as a field and column;

But that might not be foolproof. Until then I think it's WAY better to have explicit fields and columns, lacking n-n, than the previous setFromDb().
OMG we're finally getting rid of setFromDb() 😄 This is exciting.


Add an example of type Modifiers on Import Names

Hi there,
This pr is a possible solution for #2429. Please share your thoughts.

Hi @orta would you please say if I need to get another approval to merge this change?