text:
added arguments for wren

Following #87 I made a small test concept.
Figure it out it was simpler to just accept a string for the user.
The user would be responsible to parse and use this string as needed.
import "dome" for Process

class Game {
    static init() {
      System.print(Process.args)
    }
    static update() {}
    static draw(dt) {
    }
}

internal void
PROCESS_args(WrenVM* vm) {
  ENGINE* engine = (ENGINE*)wrenGetUserData(vm);
  char * args = engine->args;
  if(args) {
    wrenSetSlotString(vm, 0, args);
    return;
  }
  wrenSetSlotNull(vm, 0);
}

I appreciate the idea, but I think we can provide arguments better. DOME
uses skeeto/optparse.h to process arguments. We just need to capture the
ones which aren't used by dome.
Maybe we can use a -- to seperate engine and usercode arguments, and then
provide an array of arguments to the user.
./dome -d --record=data.gif main.wren -- --edit=tracks/1.dat --new
As an example, would then supply to process.args: [ "--edit=tracks/1.dat", "--new" ]
Not a simple implementation, due to memory allocation, but more useful.
On Fri, 2 Oct 2020, 00:39 Camilo, notifications@github.com wrote:

Following #87 https://github.com/avivbeeri/dome/issues/87 I made a
small test concept.
Figure it out it was simpler to just accept a string for the user.
The user would be responsible to parse and use this string as needed.
import "dome" for Process
class Game {
static init() {
System.print(Process.args)
}
static update() {}
static draw(dt) {
}}
[image: imagen]
https://user-images.githubusercontent.com/292738/94873503-bd3b1900-0425-11eb-9bbc-e6fff1376b08.png
internal voidPROCESS_args(WrenVM* vm) {
ENGINE* engine = (ENGINE*)wrenGetUserData(vm);
char * args = engine->args;
if(args) {
wrenSetSlotString(vm, 0, args);
return;
}
wrenSetSlotNull(vm, 0);
}

You can view, comment on, or merge this pull request online at:
https://github.com/avivbeeri/dome/pull/89
Commit Summary

added arguments for wren

File Changes

M src/engine.c
https://github.com/avivbeeri/dome/pull/89/files#diff-74fd25f039c1ffdd770deef3f1e89534
(3)
M src/engine.h
https://github.com/avivbeeri/dome/pull/89/files#diff-b1424d0c555414e667a791cd1faa9f61
(1)
M src/main.c
https://github.com/avivbeeri/dome/pull/89/files#diff-803c5170888b8642f2a97e5e9423d399
(5)
M src/modules/dome.c
https://github.com/avivbeeri/dome/pull/89/files#diff-decf5b5243256be051d79427267c09e2
(11)
M src/modules/dome.wren
https://github.com/avivbeeri/dome/pull/89/files#diff-153c841f4c6ffc3201c2494e4e1da4a7
(2)
M src/vm.c
https://github.com/avivbeeri/dome/pull/89/files#diff-86406329889f2c13524766839f0a96b3
(1)

Patch Links:

https://github.com/avivbeeri/dome/pull/89.patch
https://github.com/avivbeeri/dome/pull/89.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/avivbeeri/dome/pull/89, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALBBLY6LDSZSK652CAAJ7TSIUHKPANCNFSM4SBBYISQ
.

I appreciate the idea, but I think we can provide arguments better. DOME
uses skeeto/optparse.h to process arguments. We just need to capture the
ones which aren't used by dome.
Maybe we can use a -- to seperate engine and usercode arguments, and then
provide an array of arguments to the user.
./dome -d --record=data.gif main.wren -- --edit=tracks/1.dat --new
As an example, would then supply to process.args: [ "--edit=tracks/1.dat", "--new" ]
Not a simple implementation, due to memory allocation, but more useful.

Well for the Process class it can be implemented with a simple string separation.

args: The raw string value
arguments: The string value converted to a list separating by spaces.

class Process {
  foreign static f_exit(n)
  foreign static args

  static arguments {
    if (Process.args) {
      return Process.args.split(" ")
    }
    return []
  }

  static exit(n) {
    f_exit(n)
    Fiber.suspend()
  }

  static exit() {
    exit(0)
  }
}

So my idea is to catch anything that is not recognized by DOME and store it in the engine.args character array and return it to a string.

We could also use some similar strategy to the wren-cli
https://github.com/wren-lang/wren-cli/blob/main/src/module/os.c

There's a data.gif which is part of this PR, and that seems unnecessary to me.

In general, I like the approach here. We just need some documentation and a couple other points I raised and we are good to go:

[ ] Documenting the Process.arguments API
[ ] Add comments about Wren licensing.
[ ] Rename Process.args to Process.f_args
[ ] Remove data.gif
[ ] Remove the -a option in the optparse configuration as it is now unnecessary.

I found out that if you include the filename and omit using -- you can have the functionality
class Process {
  foreign static f_exit(n)
  foreign static f_args

  static arguments {
    var args = Process.f_args
    if (args.count > 1) {
      return args[2..-1]
    }
    return args
  }

  static arguments(needle) {
    var args = Process.arguments
    var result = null
    Fiber.new {
      args.each {|value|
        if ("%(value)".contains(needle)) {
          result = value
          // Skip all other values
          Fiber.abort()
        }
      }
    }.try()
    return result
  }
}

import "graphics" for Canvas, Color
import "dome" for Process

class Game {
    static init() {
      System.print(Process.arguments)
      System.print(Process.arguments("edit"))
    }
    static update() {}
    static draw(dt) {
      Canvas.print("DOME Installed Successfully.", 10, 10, Color.white)
    }
}

[ ]  Documenting the Process.arguments API
[x] Add comments about Wren licensing.
[x] Rename Process.args to Process.f_args
[x] Remove data.gif
[x] Remove the -a option in the optparse configuration as it is now unnecessary.

What's the state of this PR?

It should be defined the proper way of dealing with custom arguments (non dome)
Currently it supports reading all the arguments as is.
I think main.wren should be considered in similar fashion to ./dome
By convention the first argument (that ends with *.wren) should be the filename.

The path given to DOME doesn't explicitly have to be a file, though. You
can point it to a directory, and it will automatically detect a game.egg,
or main.wren file if available.
On Sat, 17 Oct 2020, 20:43 Camilo, notifications@github.com wrote:

It should be defined the proper way of dealing with custom arguments (non
dome)
Currently it supports reading all the arguments as is.
I think main.wren should be considered in similar fashion to ./dome
By convention the first argument (that ends with *.wren) should be the
filename.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/avivbeeri/dome/pull/89#issuecomment-711070333, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AALBBL4LWUGK3TEXP2DQV3LSLHXWFANCNFSM4SBBYISQ
.

So, I'd expect the "usage" to look like this:
Usage:
  dome [-c | --console] [-d | --debug] [-r<gif> | --record=<gif>] [-b<buf> | --buffer=<buf>] [entry path] [--] [non-DOME arguments]
  dome -h | --help
  dome -v | --version

Options:
  -b --buffer=<buf>   Set the audio buffer size (default: 11)
  -c --console        On Windows, this opens a log terminal for debugging.
  -d --debug          Enables debug mode.
  -h --help           Show this screen.
  -v --version        Show version.
  -r --record=<gif>   Record video to <gif>.

Technically the entry path and non-DOME arguments would be grouped together. How can we handle things during the valid case where an entry path isn't provided, but other arguments are?

After some experimenting, I've settled on an approach for handling arguments I am happy with, and have opened a PR for it.
Please can you give it a look? https://github.com/avivbeeri/dome/pull/109

This was successfully implemented in #109 so I am closing this PR.

authors: avivbeeri clsource

repo: avivbeeri/dome


text:
Added optional system property to ShowModelResponse and set proper nullability

As noted in issue #34, several properties were missing from the ShowModelResponse class. I've added them and a unit test to validate them.

Merged, thanks a lot for your contribution!

source: gharchive/pull-request

authors: JerrettDavis awaescher

repo: awaescher/OllamaSharp

license: MIT

license_type: permissive

license_source: github-api


text:
Website content

Awecode Website

Philosophies

[ ] Rapid Application Development
[ ] KISS, YAGNI, SOLID
[ ] Lean
[ ] Free and Open Source

Pages

About Awecode

[ ] History
[ ] Team
[ ] Link to Other Pages

[ ] Case Studies
[ ] Testimonials
[ ] Mobile Applications
[ ] Values, Objectives, Mission
[ ] CSR

[ ] Triple Bottom Line

[ ] Tools of the trade

Expertises

[ ] Nuxt

[ ] Development in Nepal

[ ] Flutter
[ ] Vue
[ ] Quasar
[ ] Python
[ ] Django

Services

[ ] Web Development

[ ] PWA
[ ] SPA
[ ] SSR

[ ] Mobile Application Development
[ ] Enterprise Application Development
[ ] Code Quality Audit
[ ] Software Project Valuation
[ ] Digital Management
[ ] Software Architecture Consulting
[ ] Information System and Automation Consulting

Projects

[ ] Edusanjal
[ ] Awecountant
[ ] Thuprai
[ ] Ticketing at Lumbini DT
[ ] Ticketing in Events
[ ] CMAT
[ ] Digital Audition Apps for Himalayan TV

Products

[ ] E-commerce System
[ ] Accounting System
[ ] Inventory Management System
[ ] CRM

[ ] Colleges

[ ] Content Management System
[ ] Ticketing System
[ ] E-learning System
[ ] Contract Management System
[ ] Robotic Process Automation

Philosophies

[ x ] Rapid Application Development
[ x ] KISS, YAGNI, SOLID
[ x ] Lean
[ x ] Free and Open Source

source: gharchive/issue


text:
Just released djangoSHOP version 0.9.0rc1

Whoever intends to build a webshop in the near future, please check this out:
https://github.com/awesto/django-shop
For me its specially important to ask for help about a topic no interpreter can test for me:
Is the documentation understandable?

Wow, great work @jrief!
Shouldn't there be any links to existing payment providers? If I wouldn't have visited your profile, I would never know about awesto/djangoshop-stripe or awesto/djangoshop-paypal.
The docs mention the use of django CMS, so am I right assuming you can't stick with vanilla django then?

Shouldn't there be any links to existing payment providers?

Yes, thanks for reminding me
Currently we are working with Django-1.8.8 and djangoCMS-3.2.1. Whenever CMS is ready for Django-1.9, we will switch.

Any readme about how to migrate from django-shop 0.2 ?

@Iv: sorry for the late reply, we missed your question. Unfortunately there is no supported migration path from 0.2. Too much has changed. We recommend setting up a completely new project and writing a customized export / import for your existing data.

You can reuse your product models and you probably can reuse your cart modifiers (with some adoption). That would be the a feasible migration path.
Even with 0.2, there often are so many custom made changes to the merchant's implementation, that without seeing the code, its impossible to write a fully working receipt.

authors: Iv jrief mankoell rfleschenberg

repo: awesto/django-shop

license_source: bigquery


text:
Images are no longer loading after I added next-firebase-auth-edge

After I added and implemented next-firebase-auth-edge none of the images are loading, I believe that the middleware matcher is at fault but I don't know for sure, did anyone had issues like this?
NOTES
After I log in images start to work again.
If I add the image in the "PUBLIC_PATHS" list it also works
const PUBLIC_PATHS = ["/", "/logo.svg" ,"/register", "/login", "/reset-password"];
Here is a screenshot of my folder structure:

my images are in the root of the public folder

Hey @rgbskills,
Does your middleware.ts export config object similar to the one below?
export const config = {
  matcher: ["/", "/((?!_next|favicon.ico|api).*)", "/api/login", "/api/logout"],
};

"/((?!_next|favicon.ico|api).*)", entry is the one you need. It will omit middleware processing entirely for files in public dir.

hey @awinogrodzki
here is my middleware export config:
  matcher: ["/", "/((?!_next|favicon.ico|api).*)", "/api/login", "/api/logout"],
};```

Also here is the codebase, env's will be rotated, and the project will be open sourced once I get all the features implemented.
https://github.com/rgbskills/undercover

@rgbskills
You are right. I have tested your project and "/((?!_next|favicon.ico|api).*)" matcher is not working as I expected. It still does allow files to be intercepted by a middleware causing the redirect. I have fixed it by this:
export const config = {
  matcher: ["/", "/((?!_next|favicon.ico|api|.*\\.).*)", "/api/login", "/api/logout"],
};

Let me know how it works for you :-)

Thank you so much 👍

Solved

authors: awinogrodzki rgbskills

repo: awinogrodzki/next-firebase-auth-edge


text:
Run linting as part of tests

Noticed it's not passing.
We're looking into using this module at work, so we might also contribute back. A passing suite then is much preferred 😀

Looks great to me. Thanks for the solid contribution!

authors: SimenB awolden

repo: awolden/brakes

license: mit


text:
Option to disable auto-generated policies when using @auth with IAM provider

Is your feature request related to a problem? Please describe.
I would like to re-address the issue mentioned here: https://github.com/aws-amplify/amplify-cli/issues/2776
When in a project that includes an identity pool, the policy for the auth/unath roles automatically includes permissions for every added "@auth" with "provider: iam".
This is a problem if some fields are meant to be updated only by e.g. a lambda function.
What we want to achieve is exactly the same as what is mentioned in the last example from: https://docs.amplify.aws/cli/graphql-transformer/directives#combining-multiple-authorization-types which states that:
"In the following example the model is protected by Cognito User Pools by default and anyone with a valid JWT token can perform any operation on the Post type, but cannot update the secret field. The secret field can only be modified through the configured IAM policies, from a Lambda function for example."
type Post @model @auth (rules: [{ allow: private }]) {
  id: ID!
  title: String
  owner: String
  secret: String
    @auth (rules: [{ allow: private, provider: iam, operations: [create, update] }])
}
}

When an identity pool is used (which I believe it is in the default configuration for auth - correct me if I'm wrong) this isn't possible, and in fact the above mentioned schema grants every authenticated user the same permissions as they would have had, even if the auth directive wasn't added to the secret field at all.
I'm aware that this behaviour is mentioned briefly at: https://docs.amplify.aws/cli/graphql-transformer/directives#private-authorization, but I believe that the wording in the example above is very misleading, and that we need some way to turn off the auto-generated IAM polices.
Describe the solution you'd like
Some way to add @aws_iam to types in the generated schema, without automatically adding permissions to the auth role.
Without knowing anything about the workings of the amplify cli, I imagine this could be done by adding "lambda", "customIAM" or something similiar to the AuthStrategy enum in the @auth directive. Using this authstrategy would add @aws_iam to the schema, without auto-generating permissions.
Describe alternatives you've considered
Another solution might be to add a toggle when adding IAM as an auth type for the api, asking if permissions should automatically be added to the auth/unath roles.
Additional context
The only workaround that I've been able to find, is adding all users to a generic group, so that they aren't assigned the default auth role. This doesn't seem like a solution though, given that:

Assigning a user to a user group to de-escalate privilege seems counter-intuitive.
If the postConfirmation trigger that assigns each user to a group for some reason fails, the user if left with full IAM permissions
Theoretically there's a small delay between confirming a user, and being added to a group. I don't know if this poses a real security issue, but this could potentially be abused.

Let me know if I am missing something obvious here, or if there's already an open issue regarding this.

Bump. This is huge for us. We have been fighting with the IAM Limit of 'Cannot add more than 20 policies to the Role' because we have too many schema models with IAM configured so that we can use Lambda functions.
What makes this worse is that it looks like we don't even need these policies for the Lambdas, as they are only being generated so that the frontend role can access data using IAM (which we don't even want!)
We have effectively reached the maximum amount of @models that we can have in our Amplify project, and can no longer proceed with development, all because these auto generated policies are killing the build pipeline when it tries to generate the 21st policy for the role.
The IAM and Amplify teams have just told us 'just change your schema to make it smaller' which is not a solution at all for a production application.
Since this issue is 2 years old, it's obvious this may not get fixed any time soon. Does anyone have any suggestions for hacking the CLI tool to prevent it from trying to create these policies?

authors: blazinaj ghost

repo: aws-amplify/amplify-category-api


text:
Amplify push api: Maximum call stack size exceeded

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
I have just updated the amplify and nw I cannot ush any API changes:
Maximum call stack size exceeded
There was an error pushing the API resource
RangeError: Maximum call stack size exceeded

Amplify CLI Version
4.21.3
To Reproduce
Add a new field to any model and run either:

amplify push
amplify push api

Expected behavior
A normal api push
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

MAC OSX 10.15.4

I have ran a fresh amplify pull and also restarted the mac

Hi @oliverandersencox

Does your schema contains 25 or more model?
Can you share the graphql schema which leads this error?

One potential workaround that might help is using amplify push --minify to minify your CFN templates.
Let us know if that works for you.

Yes it contains around 45 - I shall try that now

yes you can try that and let us know if that works.
I am closing this issue as a duplicate of #2584. You can follow updates and comment on this issue.

@akshbhu no luck - same error

@ashika01 same problem @akshbhu This isnt the same as that issue as I have also had that issue before.
I removed 3 tables from my model as they are us-used.
On top of this I have also been adding and removed fields from these models without error for the past month. This popped up today when I tried to add 1 field. Now with the attempt to remove 3 tables it still gives this issue.
I have a total of 32 tables FYI.
Happy to email my schema over

Hi @oliverandersencox
I have reopened this issue. You can upload schema here or if it contains sensitive information you can email it to amplify-cli@amazon.com with this issue in the subject

@akshbhu thanks! Have emailed it across

@akshbhu any update on this? I never got a reply?

@akshbhu ???

Hi @oliverandersencox
I am still working on this and will update you soon regarding this issue. I used your schemas to reproduce the issue and I got same error but not on amplify push but in updating the api.

@akshbhu okay great, thanks for the update

@akshbhu is there any news on this? We're blocked from release at the moment

any update on this guys?? @SwaySway @akshbhu

@akshbhu Being left it the dark now. Is there anything you can tell me?
I've contacted AWS support to increase the limit as advised in the other request - however they have said a limit increase wont affect this.

@SwaySway Hello!!!?

Hello @oliverandersencox
I was able to reproduce the stack size error, I'll update the thread with my findings to see where this differs from i2584.

Thanks so much!

@oliverandersencox
There seems to be a recursive type in one of your schema files.
In the @auth transformer we propagate auth directives to ObjectType nodes that are referenced from @model.
The transformer should be able to add the auth directives and not revisit the type if they have been added.

@SwaySway thanks for looking into it! I'm a bit unclear on what you mean, are you saying the issue will be in auth auth directive of one of the models?

@SwaySway this issues started when I added 1 attribute to a table though?

@oliverandersencox

are you saying the issue will be in auth auth directive of one of the models?
Correct using a similar example of what is causing the problem as noted below.

type Post @model
@auth(rules: [{ allow: owner }, { allow: private, operations: [read], provider: iam }])
{
  id: ID!
  title: String
  tags: [Tag]
}
# the transformer will propagate the auth directives such as @aws_iam @aws_cognito_user_pools
# down to the type tag
type Tag {
  id: ID!
  name: String
  # because of the type references itself it recursively goes through and adds the tags
  childTags: [Tag]
}

Was that change a type that referenced itself like example above? This is what I noticed caused the error from the provided schema.

@SwaySway - the change I made was a simple string attrbiute addition to a model.
After reading you above post, I then removed all @aws_iam @aws_cognito_user_pools that I had one my types and i am still getting them same error - Can I send you the schema to look at?
We really need to update the api for our clients to use a new feature and this is blocking us!

@SwaySway - I removed all local amplify data and ran amplify pull - then added one string attribute after the updated amplify cli - same issue

Thank you for putting this PR up. I pulled it in my own branch and it resolved the Maximum call stack size exceeded for me

Closing this issue as the fix for this is now included in the v4.24.1. Should you still experience issues with this please comment below.

authors: SwaySway akshbhu mdlavin oliverandersencox

repo: aws-amplify/amplify-cli


text:
feat(graphql-connection-transformer): allow null key-based connections

feat(graphql-connection-transformer): allow null key-based connections
Issue #, if available: #5152 #5129 #3275
Description of changes:
Allow connections to @key defined indexes to include nullable connection attributes.
Legacy @connection directive allowed use of nullable fields. When @connection with @key was added, code was put in place to prevent using a nullable scalar as a connection key. I traced the origin of this code and could find no justification for it and removed the check.
Further, when a request is made using attributes which are null, DynamoDB can return errors due to wrong types being provided in key condition values. There is no reason to make a request to DynamoDB when the pk is empty, or a specified field is null. Code is added to early return a null value or an empty list of items.
This PR also fixes an issue found when making a query with an Int type sort field whose value is null. Previously the NONE_INT_VALUE was wrapped in quotes, making it a string. This caused a DynamoDB mismatched type error.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Is there anything blocking review of this pull request?

It'd be lovely to see this working.

@RossWilliams Thank you for the PR. This change does not support the case for composite sort key. If you look at the schema below [snip]

This cause the requestTemplate to throw error. To fix this we could add an default value for fields that are NULL in the transformer and assign it.

@yuth I've failed to replicate or understand the problem you mentioned. Your example includes a missing pk for a connection. The resolver template does not throw an error and correctly returns early with an empty result, as there are no valid connected items.
I've added a commit with tests to match your above described schema. In the test the mutation and subsequent request templates do not throw errors. I also show when a sort key is missing from a composite sort key, and that an item is returned in a mutation when all keys are provided.
Can you try explaining the issue you found in more detail? Which request template do you see throwing an error? Maybe there is a misunderstanding of the expected behaviour? Did you mean to set a null composite sort key value, although this is also handled by the PR?

Any updates on this? I am forced to make some of my fields non-nullable.

@xitanggg  Sorry I’ve been busy. This weekend I’ll rebase this branch to main and see if that gets it a response

Thanks a lot Ross. Would love it see it work, but no worries. It is not an urgent issue, so take your time.

Any progress on this?

@RossWilliams @yuth any progress here? A lot of us are waiting on this functionality.

@RossWilliams @yuth any progress here? A lot of us are waiting on this functionality.

Also waiting for this functionality, has the test case @yuth mentioned been solved? Can i help maybe? (first time contributor)

Also waiting for this functionality, has the test case @yuth mentioned been solved? Can i help maybe? (first time contributor)

Thanks for the approval. Can you share when will this likely be merged and released?
We are currently developing a feature where we are forced to fill a random value to make the connection key field non-nullable. This workaround works but is not perfect because the random value would unnecessarily trigger a connection query whereas the null key wouldn't normally. Would love to know if we might be able to ditch the workaround before rolling this feature to production. Thanks.

Thanks for the approval. Can you share when will this likely be merged and released?
We are currently developing a feature where we are forced to fill a random value to make the connection key field non-nullable. This workaround works but is not perfect because the random value would unnecessarily trigger a connection query whereas the null key wouldn't normally. Would love to know if we might be able to ditch the workaround before rolling this feature to production. Thanks.

@RossWilliams I am excited about this as this fixes #5468 Could you please let me know how I can pull this in my local environment? Also, when will this be released? Thanks in advance

@RossWilliams I am excited about this as this fixes #5468 Could you please let me know how I can pull this in my local environment? Also, when will this be released? Thanks in advance

@arkllc I’m not involved in releases.
You can download the main branch, run ‘yarn dev-build && yarn dev-link’ and your global amplify command will be linked to the main  branch.

@arkllc I’m not involved in releases.
You can download the main branch, run ‘yarn dev-build && yarn dev-link’ and your global amplify command will be linked to the main  branch.

hi guys, I have upgrade to 4.43.0 but i am not sure whether this fix is included or not. I can not find anything related to this fix in the latest release note.
BUT I can successfully generate new graphql file using amplify codegen and amplify api push with null GSI field.
is this release reliable or got published accidentally?

hi guys, I have upgrade to 4.43.0 but i am not sure whether this fix is included or not. I can not find anything related to this fix in the latest release note.
BUT I can successfully generate new graphql file using amplify codegen and amplify api push with null GSI field.
is this release reliable or got published accidentally?

It is part of 4.42.0 release. https://github.com/aws-amplify/amplify-cli/compare/v4.41.1...v4.42.0

hi all -- i'm on 4.43.0 and still facing this issue. any ideas what could be going on if this has been merged in?

For anyone running into this issue (on v4.43.0), here's a workaround (pretty hackey but will suffice for now):
replace all of your API.graphql with the following helper:
const graphqlAPI = async (
   options,
   additionalHeaders?: {
      [key: string]: string;
   }
): Promise<any> => {
   try {
      return await API.graphql(options, additionalHeaders);
   } catch (err) {
      const realErrors = err.errors.filter(
         (e) => !e.message.startsWith('Cannot return null for non-nullable')
      );
      if (realErrors.length > 0) {
         console.log(`THROWING GRAPHQL ERROR`);
         throw err;
      } else {
         const realDataResult = { data: err.data };
         return realDataResult;
      }
   }
};

hi all -- i'm on 4.43.0 and still facing this issue. any ideas what could be going on if this has been merged in?

I don't have any issue with null based connection anymore, it works great in end. Thanks again for the merge.
The purpose of this merge is to let you use @connection with a nullable field (i.e. field without !). Say I have a User type and a School type, some users go to schools would have a schoolID field while others don't go to school wouldn't. Previously, the following schema wouldn't be possible, because schoolID is used in @connection and therefore can't be nullable. And it would have to be non-nullable with ! and developers therefore are forced to assign some schoolID to some users even though they don't go to school (buggy). Now the merge resolves it.
User @model {
   id: String!
   schoolID: String  #Previously, it must be non-nullable using `String!`
   connectSchool: School @connection(fields: ["schoolID"])
}

From your code, it seems that you are trying to ignore the graphQL Cannot return null for non-nullable error.
In graphQL, if you make a field non-nullable by using !, it means you intentionally require data for a certain field, the missing of which would throw an error (it is a feature built in graphQL, because it can be an use case of guaranteeing the retrieval of important data, because partial data can be lost in transmission, and you might want to treat partial loss as error).
If after all, some data fields are not required, you can simply make it nullable by removing the ! in your schema.

@RossWilliams  Is this fix supposed to fix https://github.com/aws-amplify/amplify-cli/issues/5468 too? If yes, I am on 4.50.0 but somehow I still am not able to create data with null secondary keys. appreciate it in advance, if you could please help clarify

authors: RossWilliams arkllc azatoth icecog jimlevett jncheung lostcodingsomewhere mansdahlstrom1 tomhirschfeld xitanggg


text:
Fix Yarn Scripts and Update CONTRIBUTING.md

Issue #6690
Description of changes:

Updated the CONTRIBUTING.md to add lerna and rimraf and pre-requisite to setting up the dev environment.
Added escaped double quotes to the scripts in order to add support for pathnames with spaces in between them.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for improving the docs @gitaalekhyapaul 👍

authors: gitaalekhyapaul princiya


text:
Some pages becomes randomly white useing next.js with ISR.

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
d1bxok73m14yc9
Region
eu-north-1
Amplify Hosting feature
No response
Describe the bug
Randomly did we get white pages on the website which is using next.js. I have been debugging and do see that those pages have 0 bytes in the s3 bucket. Look at the photo. This happens randomly and 1 way to solve it is by removing the HTML file and it will be rebuilt and published.
I think that the invalidation is ok and that next.js revalidates the page successfully but when AWS pushes the file into s3 bucket it fail and I don't see any error logs on this and so on.

Expected behavior
Page to revalidated successfully and pushed into s3 bucket without that the file will be blank and have 0 bytes.
Reproduction steps
It's hard to reproduce. The only way I see is to trigger a lot of revalidations and check for blank pages.
Build Settings
next.js default

Additional information
No response

Hi @emilpriverrc 👋🏽 thanks for raising this issue. Can you provide a code snippet for how you're implementing ISR and also a screenshot of your next.config.js file while we investigate?

Sure!
next.config.js
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});

module.exports = withBundleAnalyzer({
  future: {
    webpack5: true,
  },
  i18n: {
    locales: ["en", "no", "de", "sv"],
    defaultLocale: "en",
  },
  images: {
    domains: [
        "a list of domains. i hide for the screenshot"
    ],
    deviceSizes: [320, 640, 750, 828, 1080, 1200, 1920, 2048, 2560, 3840],
    imageSizes: [16, 32, 48, 64, 96, 128, 256],
  },
  async rewrites() {
    return [
      {
        source: '/sitemap-en.xml',
        destination: '/api/sitemap-en',
      },
      {
        source: '/sitemap-no.xml',
        destination: '/api/sitemap-no',
      },
      {
        source: '/sitemap-de.xml',
        destination: '/api/sitemap-de',
      },
    ]
  },
  async headers() {
    return [
      {
        source: '/.well-known/apple-developer-merchantid-domain-association',
        headers: [
          {
            key: 'Content-Type',
            value: 'text/plain',
          },
        ],
      },
    ];
  },
});

Example of getStaticProps:
export const getStaticProps: GetStaticProps = async ({ params, preview = false, locale }) => {
  const { slug } = params as { slug: string };
  const language = (locale)?.toUpperCase() ?? 'EN';

  const primaryMenu = await getMenu(
    locale === 'en' ? 'PRIMARY' : `PRIMARY___${language}`,
  );
  const secondaryMenu = await getMenu(
    locale === 'en' ? 'SECONDARY' : `SECONDARY___${language}`,
  );
  const saleMenu = await getMenu(
    locale === 'en' ? 'SALE' : `SALE___${language}`,
  );
  const footerMenu1 = await getMenu(
    locale === 'en' ? 'FOOTER1' : `FOOTER1___${language}`,
  );
  const footerMenu2 = await getMenu(
    locale === 'en' ? 'FOOTER2' : `FOOTER2___${language}`,
  );
  const socialMenu = await getMenu(
    locale === 'en' ? 'SOCIAL' : `SOCIAL___${language}`,
  );

  const menu = {
    primary: primaryMenu,
    secondary: secondaryMenu,
    sale: saleMenu,
    footer1: footerMenu1,
    footer2: footerMenu2,
    social: socialMenu,
  };

  let [page] = await getPage(slug, language);
  const posts = await getAllPosts(language);
  const tags = await getAllTags(language);
  const themeSettings = await getThemeSettings();

  if (preview) {
    page = await getPreviewPost(slug) as Page;
  }

  if (!page) {
    return {
      notFound: true,
      revalidate: 60,
    };
  }

  return {
    props: {
      menu,
      page,
      posts,
      tags,
      themeSettings,
      translations: page?.translations?.map((translation) => ({
        uri: translation?.slug ?? null,
        locale: translation?.language?.code ?? null,
      })) ?? [],
    },
    revalidate: 60,
  };
};

Example of getStaticPaths
export const getStaticPaths: GetStaticPaths = async () => {
  const pages = await getAllPages();

  const paths = pages.map((page) => ({
    params: {
      slug: page.slug,
    },
    locale: page.language.slug,
  }));

  return {
    paths,
    fallback: 'blocking',
  };
};

Something good to add to the issue is that we use next version 10.1.2

@emilpriverrc thank you for providing these details, we're taking a look.

Hello. Just wondering. Any update on this?

Hi again ✌ we just got another site with exact same problem. This site is a copy on another page with same code and content just new amplify app.
Should I send you some id for amplify ?

Hi, we were also not able to reproduce this. Can you provide the logs for the ISR lambda function please? You can follow this FAQ guide to locate the logs: Access Lambda Edge Logs

Yes if you can provide that amplify app ID as well that would be helpful. When the app is first built, are the pages accessible? And is it only after the revalidation period that the files are 0kb?

Correct, It works fine after a build. It's first on revalidation this happens.
APP id: d335y2aqqe2ekl
Is it safe to post the logs here? Or can i send it to you in some other way?

I went through all the logs in cloud watch and the only thing I saw was that we loaded .env.production. But 0 errors and so on

Hi, we removed revalidation in getStaticProps and have not had any issues since then. Really looks like revalidation it's the problem

We have the same issue on multiple sites on different AWS accounts.
After build their is 0 byte pages and works after re-build.
Any update on this?

Hi!
We also have the same issue.
How we can get that behavior:

Create a Next.js page with revalidation every X minutes
At getStaticProps of your page, do some call to an external resource that can be unavailable (high traffic, network failure, random crashes) and throw an error.
Next.js fail to generate that page.
For an unknown reason, Amplify assume that the result is a success-generated page and delivers it to S3/Cloudfront.

After months of investigations, we continue to don't understand why AWS Amplify works that way.
We only could "workaround" that issue by making the page return some content (text/string) instead of just throwing the error to Next.js. But it is still useless.
Seems to us that Amplify makes 2 different tries to generate that page: one using the correct SSR and trying to generate a full static page. Other rendering the page/components with default values and relying on Next.js to do the hydration at the client-side with results of getStaticProps.

Is that correct?
Why Amplify doesn't understand a failed revalidation and just discard the result? Keeping to clients the old and correct content.

I've also been experiencing this for months and haven't been able to find a suitable workaround to prevent 'Application Error' pages been shown on production when trying to load these 0kb pages.
At this point I'm considering automating a script to periodically scan the S3 bucket for 0KB static pages and deleting them - however this feels like a horrible band-aid.

Facing same issue with nextjs using SSR. blank page coming sometimes specially when doing fast redirections.

I was able resolve random blank page issue with NextJS 13.4.0. Getting error with latest version. So right now sticking with this

@AnirudhaGohokar  still error exists there I  refresh those pages 500
Internal Server Error.

Hi!
We also have the same issue.
How we can get that behavior:

Create a Next.js page with revalidation every X minutes
At getStaticProps of your page, do some call to an external resource that can be unavailable (high traffic, network failure, random crashes) and throw an error.
Next.js fail to generate that page.
For an unknown reason, Amplify assume that the result is a success-generated page and delivers it to S3/Cloudfront.

After months of investigations, we continue to don't understand why AWS Amplify works that way.
We only could "workaround" that issue by making the page return some content (text/string) instead of just throwing the error to Next.js. But it is still useless.
Seems to us that Amplify makes 2 different tries to generate that page: one using the correct SSR and trying to generate a full static page. Other rendering the page/components with default values and relying on Next.js to do the hydration at the client-side with results of getStaticProps.

Is that correct?
Why Amplify doesn't understand a failed revalidation and just discard the result? Keeping to clients the old and correct content.

Hi.
After this error occurs, does page display content again for new requests in the next revalidation cycle, if successful, without manual intervention?

Hi @andre-mr ,
Yeah, after some revalidation cycles, the page returns without any intervention.
But we never know if it will take 30 minutes, 1 hour, 2 hours or more.

I just got a similar issue, page just white at some point. It somehow got fixed by restarting the dev server. I did not check how much bytes etc. were transferred.

authors: AnirudhaGohokar CauanCabral FreshImmuc andre-mr emilpriverrc hloriana ovdahlberg pranavaccion rhoiyds

repo: aws-amplify/amplify-hosting


text:
Amplify Console managed policy missing permission cognito-idp:UpdateGroup, backend build fails

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
d34opb5305os4y
Region
us-east-1
Amplify Hosting feature
Backend builds
Describe the bug
Deployed an auth update using Amplify Console backend builds. The AWS managed policy AdministratorAccess-Amplify does not include permission to call cognito-idp:UpdateGroup on the existing usersGroup so the cfn deploy fails.

UPDATE_FAILED               usersGroup                                                        AWS::Cognito::UserPoolGroup Mon Jul 25 2022 23:15:41 GMT+0000 (Coordinated Universal Time) User: arn:aws:sts::****:assumed-role/amplifyconsole-backend-role/BuildSession is not authorized to perform: cognito-idp:UpdateGroup on resource: arn:aws:cognito-idp:us-east-1:****:userpool/us-east-1_**** because no identity-based policy allows the cognito-idp:UpdateGroup action (Service: AWSCognitoIdentityProviderService; Status Code: 400; Error Code: AccessDeniedException; Request ID: 53a818fc-950c-47a3-8287-86836b5c126b; Proxy: null)

Expected behavior
Managed policy AdministratorAccess-Amplify should have all permissions necessary for Amplify CLI to work.
The documentation mentions this list of required permissions: https://docs.amplify.aws/cli/reference/iam/
Reproduction steps

Make a change to the auth cfn template, create PR, merge
Amplify CI/CD picks up change, starts deploying backend
Missing permission causes CloudFormation deploy to fail, so Amplify build fails

Build Settings
Amplify CLI version overridden to latest using console 'Build image settings'
Additional information
No response

Hi @adilosa thank you for raising this issue. We are adding this item to our product backlog for prioritization. In the mean time, please feel free to manually update the permissions for your service role so that you are unblocked.

authors: adilosa hloriana


text:
Backend Hosting

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting questions.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
NEW_APP
AWS Region
us-east-1
Amplify Hosting feature
Backend builds, Build settings
Question
I have backend project(Node.js, Express.js, MongoDB)
I'm trying to deploy that but This is not simple for me
So I know everyone is busy but I'm writing now
How to deploy backend project using amplify of aws?

Hi @Techking5287 👋 , thanks for raising this!
Are you utilizing the Amplify CLI to build your backend? Or are you looking to host your existing backend stack with Amplify CLI and Hosting? Can you share your detailed use case?


text:
Next.js 13 serving content from build time only

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have removed any sensitive information from my code snippets and submission.

Amplify Hosting feature
SSR
Is your feature request related to a problem? Please describe:
I have a problem with next.js 13 site using app router
it uses server components to fetch data, however it seems it only serves static content from build time and not fetch data on server side. setting manual revalidate time does not seem to work neither in layout nor in fetch functions.
my build settings:
frontend:
  phases:
    preBuild:
      commands:
        - yarn install
    build:
      commands:
        - yarn run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*
      - .next/cache/**/*

Describe how you'd like this feature to work
i would expect that the content served would be no older than revalidate value

narrowed down to find that this seems to be exactly the same problem as here:
https://github.com/aws-amplify/amplify-hosting/issues/3707


text:
Cfn-lint 0.24.1 fails to parse paths with special characters

*cfn-lint version: *
cfn-lint 0.24.1
Description of issue.
Cfn-lint fails to correctly parse paths with special characters such as [] and throws an unhandled exception while executing. For example (file contents do not matter):
$ cfn-lint error\[package-1.1\]foo/cli-strings.yml
Traceback (most recent call last):
  File "/home/user/.local/bin/cfn-lint", line 10, in <module>
    sys.exit(main())
  File "/home/user/.local/lib/python3.6/site-packages/cfnlint/__main__.py", line 28, in main
    (args, filenames, formatter) = cfnlint.core.get_args_filenames(sys.argv[1:])
  File "/home/user/.local/lib/python3.6/site-packages/cfnlint/core.py", line 146, in get_args_filenames
    if not config.templates:
  File "/home/user/.local/lib/python3.6/site-packages/cfnlint/config.py", line 538, in templates
    add_filenames = glob.glob(filename, recursive=True)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/glob.py", line 20, in glob
    return list(iglob(pathname, recursive=recursive))
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/glob.py", line 71, in _iglob
    for dirname in dirs:
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/glob.py", line 55, in _iglob
    yield from _glob1(dirname, basename, dironly)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/glob.py", line 83, in _glob1
    return fnmatch.filter(names, pattern)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/fnmatch.py", line 52, in filter
    match = _compile_pattern(pat)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/fnmatch.py", line 46, in _compile_pattern
    return re.compile(res).match
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/re.py", line 233, in compile
    return _compile(pattern, flags)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/re.py", line 301, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_compile.py", line 562, in compile
    p = sre_parse.parse(p, flags)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_parse.py", line 855, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_parse.py", line 416, in _parse_sub
    not nested and not items))
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_parse.py", line 765, in _parse
    p = _parse_sub(source, state, sub_verbose, nested + 1)
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_parse.py", line 416, in _parse_sub
    not nested and not items))
  File "/rootdir/env/envImprovement/python3.6/lib/python3.6/sre_parse.py", line 553, in _parse
    raise source.error(msg, len(this) + 1 + len(that))
sre_constants.error: bad character range e-1 at position 16

@GeorgeArgyros I came back around to this.
We use python GLOB to expand paths when looking at directories.  Unfortunately glob also uses [] for that expansion.  To escape you are going to have to do something like this.  Not ideal but it will work.
cfn-lint "error[[]package-1.1[]]foo/cli-strings.yaml"

authors: GeorgeArgyros kddejong

repo: aws-cloudformation/cfn-python-lint


text:
Docker Compose Documentation errors out

In the root Readme file, the instruction to run Docker Compose produces an error:
$ docker-compose MYSQL_PASSWORD='pass@word1' docker compose up -f dist/docker-compose/docker-compose.yml

unknown shorthand flag: 'f' in -f

Closed by #446

authors: niallthomson stevenfollis

repo: aws-containers/retail-store-sample-app


text:
[doc] API Reference rds DBInstance spec vpcSecurityGroupRefs is array

What is the URL of the document?
https://aws-controllers-k8s.github.io/community/reference/rds/v1alpha1/dbinstance/
Which section(s) is the issue in?
DBInstance spec
What needs fixing?
The field vpcSecurityGroupRefs and is missing the - to indicate is an array

I was trying to find where is this content in the doc repo but I was not able to find it, if you let me know I can submit a PR

The documentation is released in: https://github.com/aws-controllers-k8s/community/tree/gh-pages by community-docs-release prow job, that executes at somepoint gen_references.py (which uses a jinja template here https://github.com/aws-controllers-k8s/community/blob/main/docs/scripts/templates/resource.jinja2)

authors: A-Hilaly csantanapr


text:
remove dev preview from olm file in preparation for GA

Issue #, if available:
NA
Description of changes:
Removing the dev preview verbiage from the OLM config file in preparation for this controller to go GA
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Signed-off-by: Adam D. Cornett adc@redhat.com

/ok-to-test
/lgtm

Do you wanna wait till Thursday @acornett21 ?
/lgtm cancel

/lgtm


text:
release artifacts for release v1.0.0

Description of changes:
Release artifacts for v1.0.0
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/lgtm

authors: RedbackThomson jljaco


text:
fix: bundle gui-submit fails loading bundles with saved queue parameter values

What was the problem/requirement? (What/Why)
The bundle submitter GUI will fail to open a job bundle if a parameter has a value in parameter_values but the parameter does not exist in the template.
What was the solution? (How)
The error was caused when trying to generate a GUI component for the parameter. parameter_values does not contain type information for the parameter, only the value. The code that generates a component for a parameter assumes there is type information for all parameters. If type information is not found, we simply skip generating a component for that parameter. Note that we still want to retain these parameter values as they can still be used to populate queue parameter values.
What is the impact of this change?
Job bundles as described above can now be opened in the bundle submission GUI. In particular, job bundles generated by the integrated submitters when queue environment parameters were present will now work with the job bundle submission GUI.
How was this change tested?
I opened a job bundle that was previously not opening.
Was this change documented?
No
Is this a breaking change?
No

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

You mentioned that you can now open bundles with queue parameters, but can you also submit them?

You mentioned that you can now open bundles with queue parameters, but can you also submit them?

Yes

This would be better with a unit test.

This change is in the UI code. This project isn't set up for unit tests involving UI code. I looked into it, but there are some things that would need to be figured out with respect to Qt bindings in order to get that to work. Given that this is a fairly trivial change, I don't think it's worth figuring that out to test this particular change.

authors: crowecawcaw evanspearman-a

repo: aws-deadline/deadline-cloud


text:
feat(uat): added base source code of future mosquitto-based client

Issue #, if available:
Move Mosquitto client sources to auth repo
Description of changes:

Added base structure and some logic of Mosquitto-based MQTT client

Why is this change necessary:
We add one more test client
How was this change tested:
At the moment manually, client not yet added to CI build.
Test results
Control:
[INFO ] 2023-05-04 19:19:59.121 [grpc-default-executor-0] GRPCDiscoveryServer - RegisterAgent: agentId agent_mosquitto
[INFO ] 2023-05-04 19:19:59.137 [grpc-default-executor-0] GRPCDiscoveryServer - DiscoveryClient: agentId agent_mosquitto address 127.0.0.1 port 36511
[INFO ] 2023-05-04 19:19:59.140 [grpc-default-executor-0] EngineControlImpl - Created new agent control for agent_mosquitto on 127.0.0.1:36511
[INFO ] 2023-05-04 19:19:59.183 [grpc-default-executor-0] ExampleControl - Agent agent_mosquitto is connected
[INFO ] 2023-05-04 19:19:59.185 [pool-4-thread-1] AgentTestScenario - Playing test scenario for agent id agent_mosquitto
[INFO ] 2023-05-04 19:20:02.819 [pool-4-thread-1] AgentControlImpl - Created connection with id 1 CONNACK 'sessionPresent: false
reasonCode: 0
receiveMaximum: 100
maximumQoS: 1
retainAvailable: true
maximumPacketSize: 149504
wildcardSubscriptionsAvailable: true
subscriptionIdentifiersAvailable: false
sharedSubscriptionsAvailable: true
serverKeepAlive: 60
'
[INFO ] 2023-05-04 19:20:02.820 [pool-4-thread-1] AgentControlImpl - createMqttConnection: MQTT connectionId 1 created
[INFO ] 2023-05-04 19:20:02.820 [pool-4-thread-1] AgentTestScenario - MQTT connection with id 1 is established
[INFO ] 2023-05-04 19:20:07.832 [pool-4-thread-1] AgentControlImpl - SubscribeMqtt: subscribe on connection 1
[INFO ] 2023-05-04 19:20:07.920 [pool-4-thread-1] AgentTestScenario - Subscribe response: connectionId 1 reason codes [0] reason string ''
[INFO ] 2023-05-04 19:20:12.930 [pool-4-thread-1] AgentControlImpl - PublishMqtt: publishing on connectionId 1 topic test/topic
[INFO ] 2023-05-04 19:20:12.942 [pool-4-thread-1] AgentTestScenario - Published connectionId 1 reasonCode 0 reasonString 0
[INFO ] 2023-05-04 19:20:17.949 [pool-4-thread-1] AgentControlImpl - UnsubscribeMqtt: unsubscribe on connectionId 1
[INFO ] 2023-05-04 19:20:17.958 [pool-4-thread-1] AgentTestScenario - Unsubscribe response: connectionId 1 reason codes [] reason string ''
[INFO ] 2023-05-04 19:20:32.979 [pool-4-thread-1] AgentControlImpl - closeMqttConnection: MQTT connectionId 1 closed
[INFO ] 2023-05-04 19:20:32.994 [pool-4-thread-1] AgentControlImpl - shutdown request sent successfully
[INFO ] 2023-05-04 19:20:33.007 [grpc-default-executor-0] GRPCDiscoveryServer - UnregisterAgent: agentId agent_mosquitto reason Agent shutdown by OTF request 'That's it.'
[INFO ] 2023-05-04 19:20:33.012 [grpc-default-executor-0] ExampleControl - Agent agent_mosquitto is disconnected

Client:
[INFO ] 2023-05-04 19:19:59.121 [grpc-default-executor-0] GRPCDiscoveryServer - RegisterAgent: agentId agent_mosquitto
[INFO ] 2023-05-04 19:19:59.137 [grpc-default-executor-0] GRPCDiscoveryServer - DiscoveryClient: agentId agent_mosquitto address 127.0.0.1 port 36511
[INFO ] 2023-05-04 19:19:59.140 [grpc-default-executor-0] EngineControlImpl - Created new agent control for agent_mosquitto on 127.0.0.1:36511
[INFO ] 2023-05-04 19:19:59.183 [grpc-default-executor-0] ExampleControl - Agent agent_mosquitto is connected
[INFO ] 2023-05-04 19:19:59.185 [pool-4-thread-1] AgentTestScenario - Playing test scenario for agent id agent_mosquitto
[INFO ] 2023-05-04 19:20:02.819 [pool-4-thread-1] AgentControlImpl - Created connection with id 1 CONNACK 'sessionPresent: false
reasonCode: 0
receiveMaximum: 100
maximumQoS: 1
retainAvailable: true
maximumPacketSize: 149504
wildcardSubscriptionsAvailable: true
subscriptionIdentifiersAvailable: false
sharedSubscriptionsAvailable: true
serverKeepAlive: 60
'
[INFO ] 2023-05-04 19:20:02.820 [pool-4-thread-1] AgentControlImpl - createMqttConnection: MQTT connectionId 1 created
[INFO ] 2023-05-04 19:20:02.820 [pool-4-thread-1] AgentTestScenario - MQTT connection with id 1 is established
[INFO ] 2023-05-04 19:20:07.832 [pool-4-thread-1] AgentControlImpl - SubscribeMqtt: subscribe on connection 1
[INFO ] 2023-05-04 19:20:07.920 [pool-4-thread-1] AgentTestScenario - Subscribe response: connectionId 1 reason codes [0] reason string ''
[INFO ] 2023-05-04 19:20:12.930 [pool-4-thread-1] AgentControlImpl - PublishMqtt: publishing on connectionId 1 topic test/topic
[INFO ] 2023-05-04 19:20:12.942 [pool-4-thread-1] AgentTestScenario - Published connectionId 1 reasonCode 0 reasonString 0
[INFO ] 2023-05-04 19:20:17.949 [pool-4-thread-1] AgentControlImpl - UnsubscribeMqtt: unsubscribe on connectionId 1
[INFO ] 2023-05-04 19:20:17.958 [pool-4-thread-1] AgentTestScenario - Unsubscribe response: connectionId 1 reason codes [] reason string ''
[INFO ] 2023-05-04 19:20:32.979 [pool-4-thread-1] AgentControlImpl - closeMqttConnection: MQTT connectionId 1 closed
[INFO ] 2023-05-04 19:20:32.994 [pool-4-thread-1] AgentControlImpl - shutdown request sent successfully
[INFO ] 2023-05-04 19:20:33.007 [grpc-default-executor-0] GRPCDiscoveryServer - UnregisterAgent: agentId agent_mosquitto reason Agent shutdown by OTF request 'That's it.'
[INFO ] 2023-05-04 19:20:33.012 [grpc-default-executor-0] ExampleControl - Agent agent_mosquitto is disconnected

Any additional information or context required to review the change:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I thought we were going to use the command line version of mosquitto to avoid needing to compile?
mosquitto provides couple of  command line tools to publish and subscribe, but that can't meet requirements defined in gRPC due to completely miss handling of protocol details.

Work backwards from the requirement in the test, not the requirement of gRPC.
Does the mosquitto command line implement everything we need from the perspective of the test?

I think not, they are very simplified.

authors: MikeDombo bgklika


text:
fix(tracer): add name sanitization for X-Ray subsegments

Issue number: #3981
Summary
Changes
This pull request addresses the concern raised by @loesak regarding subsegment names generated when using our Tracer utility. While there's currently no loss of tracer or subsegment data, it's crucial to ensure that the generated names comply with the X-Ray specification to prevent any potential issues or warnings.
User experience
By implementing name sanitization, we'll ensure that X-Ray no longer emits warnings due to non-compliant subsegment names. This bug fix will result in customers no longer receiving X-Ray warnings.
Checklist
If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[ ] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?
RFC issue number:
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.30%. Comparing base (e14e768) to head (500c2dc).
Report is 218 commits behind head on develop.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #4005      +/-   ##
===========================================
- Coverage    96.38%   96.30%   -0.08%
===========================================
  Files          214      215       +1
  Lines        10030    10274     +244
  Branches      1846     1914      +68
===========================================
+ Hits          9667     9894     +227
- Misses         259      271      +12
- Partials       104      109       +5

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter leandrodamascena

repo: aws-powertools/powertools-lambda-python


text:
Update the files inside the package with new code, with previous Fixes

Description of changes:
Update the files inside the package (Zip File) with new code, with previous Fixes
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/do-e2e-tests

authors: XeniaP tbulding


text:
Upgrade deprecated runtime nodejs8.10

CloudFormation templates in aws-lambda-edge-workshops have been found to include a deprecated Lambda function runtime (nodejs8.10). The affected templates have been updated to a supported runtime (nodejs10.x).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

the version got updated in a different pull-request

authors: alveko chriscoombs

repo: aws-samples/aws-lambda-edge-workshops


text:
Logger setup: WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.

Hello @maschnetwork
I'm still trying your setup to get some comparisons. I was trying to apply this to one of my apps. Unfortunately I got NoClassDefFoundError: com/amazonaws/services/lambda/runtime/LambdaLogger - apparently it doesn't like my logger setup. It was working properly without the instrumentation, though.
Anyway, I stepped back to the documentation and according to https://docs.aws.amazon.com/lambda/latest/dg/java-logging.html, this is the basic needed setup: https://github.com/awsdocs/aws-lambda-developer-guide/blob/main/sample-apps/java-basic/pom.xml (or here: https://github.com/awsdocs/aws-lambda-developer-guide/blob/main/sample-apps/blank-java/pom.xml) - does it still apply to custom runtimes?
Unfortunately it looks like I still miss some additional setup because with the instrumentation applied and the above setup I get: WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
The app works fine but from the logs I can see it may impact the performance:
2022-05-09T11:29:15.751+02:00 START RequestId:
2022-05-09T11:29:16.284+02:00 WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. | WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
2022-05-09T11:29:19.403+02:00 END RequestId:
2022-05-09T11:29:19.403+02:00 REPORT RequestId: Duration: 3650.94 ms	Billed Duration: 4473 ms Memory Size: 512 MB	Max Memory Used: 141 MB	Init Duration: 821.08 ms	XRAY TraceId: XXX Duration: 3650.94 ms Billed Duration: 4473 ms Memory Size: 512 MB Max Memory Used: 141 MB

Have you encountered this error/warning?
Regards
M

Hi @zerkowsm,
do you have an example repo for reference and to reproduce?
Best,
Max

See this issue for more information: https://github.com/aws/aws-lambda-java-libs/issues/204

authors: jkosternl maschnetwork zerkowsm


text:
PR Test

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

ok


text:
cloudwatch: Found Error: Error: Missing source file for snapshot exiting

i got an error on cloudwatch while running aws2tf
aws_cloudwatch_log_group <redacted> tf files
Found Error: Error: Missing source file for snapshot exiting ....

I think this one is caused by a race condition when doing parallel imports.
Committed a change that turns down the number of parallel imports that are allowed.
It might help avoid this error
You can also rerun with ./aws2tf.sh -c yes - to jump over tf files already imported

i am using -c yes

are you still seeing the error ?

no. cloudwatch files were generated a few days ago

authors: awsandy marafa-sugarcrm


text:
Adding Wave Autoscale to the Partners

Description of changes:
This pull request integrates Wave Autoscale (STCLab) into the AWS EKS testing framework. It includes the following artifacts:

FluxCD configuration
External Secret

It needs two keys in Parameter Store. The keys are included in the self-assessment spreadsheet we sent.

GHRC_TOKEN
WA_LICENSE

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

Thanks for the PR!
I have loaded the secrets you provided into our testing account, however when I went to go test that it was having a little trouble scheduling on our testing environments due to the resource demands. Is the wave-autoscale-autopilot container meant to request 3cpu and 3000Mi memory?

Hi @mikemcd3912
I have identified an issue in the status-check logic within the cronjob.
The logic has been updated to validate the status by checking the response values.
Additionally, I have added a StatefulSet check logic that includes communication with the Kubernetes API.
Please review the changes at your convenience.

Hi @Ari-suhyeon,
On the functional testing what we're looking for a test of the main function of the solution to show that it is up and running properly, so the health check with the K8s API is still not quite what we are looking for. One example of this is a partner Tetrate's solution that creates and the subsequently destroys ingress resources to test the functionality of their product who's function is to manage networking and ingress
Based on my understanding of your solution ideally we'd like to see a test that validates that the intelligent scaling is working as expected, so possibly creating a temporary pod that will be resource constrained from the start then checking whether wave-autoscale performs the necessary autoscaling operation on it before cleaning up the testing resources.
Let me know if you have any questions or if I can provide additional clarification!

Hi @mikemcd3912 ,
I Understood.
To test the auto-scaling functionality, we need to collect metrics, and for this, an agent must be installed as a DaemonSet. I hope this is acceptable to you.
As my schedule does not allow for it this week, I will proceed with the work next week and push the changes accordingly.

Looks like your deployment wa-test-dp is failing.
Specifically, it looks like these pods are failing:

Pod: wa-test-dp-549f5f7f75-2mtcl.
Pod: wa-test-dp-549f5f7f75-6sn6n.
Pod: wa-test-dp-549f5f7f75-6zcw5.
Pod: wa-test-dp-549f5f7f75-c4j8x.
Pod: wa-test-dp-549f5f7f75-cgfn8.
Pod: wa-test-dp-549f5f7f75-f5k85.
Pod: wa-test-dp-549f5f7f75-g78sx.
Pod: wa-test-dp-549f5f7f75-hgmrw.
Pod: wa-test-dp-549f5f7f75-jfrbx.
Pod: wa-test-dp-549f5f7f75-kktgg.
Pod: wa-test-dp-549f5f7f75-ljn4p.
Pod: wa-test-dp-549f5f7f75-mc4dt.
Pod: wa-test-dp-549f5f7f75-mzhf5.
Pod: wa-test-dp-549f5f7f75-prfw6.
Pod: wa-test-dp-549f5f7f75-qrxd9.
Pod: wa-test-dp-549f5f7f75-sswh8.
Pod: wa-test-dp-549f5f7f75-thb79.
Pod: wa-test-dp-549f5f7f75-tzvsc.
Pod: wa-test-dp-549f5f7f75-v4zv6.
Pod: wa-test-dp-549f5f7f75-v7bgn.
Pod: wa-test-dp-549f5f7f75-wsdh2.
Pod: wa-test-dp-549f5f7f75-ww4ld.

Hi @elamaran11
Please let us know what specifically you mean by it failing.
Logs from the cronjob would be great too.
Or are you just saying that the wa-test-dp Deployment failed, not the cronjob?
If so, please provide logs from the pod as well.
Also, did you remove the pv and pvc of the existing wave-autoscale and redeploy it?

@mikemcd3912 Can you report more details on this error.

Hi @Ari-suhyeon,
Thanks for the updates! The message about all those failed pods was part of an automation and appear to have been remedied by the redeployment of the solution/volumes after those updates so I'll keep you updated as I complete the rest of the testing. So far our VMware environment test was successful so I believe the current iteration is looking promising

Looks like your deployment wa-test-dp is failing.
Specifically, it looks like these pods are failing:

Pod: wa-test-dp-8ccbc64df-5rxrf.

repo: aws-samples/eks-anywhere-addons


text:
Changing the network policy structure and including Tigera's Secure Cloud Edition components.

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I've made all the changes that were requested, other than the CloudWatch - while a good idea, I don't have time to do it at this time - sorry.

repo: aws-samples/eks-workshop


text:
Update Dockerfile

Issue #, if available:
Description of changes: Skipping ssl verification for yum repositories on companies that enforces proxys, which can cause SSL certificate problem
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

You can add a flag check instead of directly specifying the changes.

thank you @paulorangeljr and @ashishgupta-in let me review this

authors: JohnChe88 ashishgupta-in paulorangeljr

repo: aws-samples/spark-on-aws-lambda


text:
Incompatible request with urllib3>2

Describe the bug
Custom Resource lambda gets stuck on creation and is unable to run due to an incompatibility between requests and urllib3. For some reason pip is installing urllib3>2 by default, I had to add urllib3<2 on every requirements.txt so WAF deployment would work.
To Reproduce
Deploying the base stack triggers the issue.
Expected behavior
Cloudformation deployment happens without hanging and failing.
Please complete the following information about the solution:

[ ] Version: v3.2.5

[ ] Region: us-east-1

[ ] Was the solution modified from the version published on this repository? Nope

[ ] Were there any errors in the CloudWatch Logs? Yes

[ERROR] Runtime.ImportModuleError: Unable to import module 'helper': urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2k-fips  26 Jan 2017. See: https://github.com/urllib3/urllib3/issues/2168Traceback (most recent call last): | [ERROR] Runtime.ImportModuleError: Unable to import module 'helper': urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2k-fips 26 Jan 2017. See: https://github.com/urllib3/urllib3/issues/2168 Traceback (most recent call last):

Just to follow up for more context: are you deploying out of the box or are you building your own custom solution locally and then deploying? A few suggestions: try upgrading to latest Security Automations for WAF (v4.0.1) and see if that fixes your issue. If you are building locally are you tied to your openssl version? Can you bump it to a compatible version that satisfies the correlating urlib3 version?

authors: NicoForce WillAWS


text:
Remove duplicate Code: key

#4
This PR removes the duplicate Code: CFN Key.

Thanks for the feedback, we will fix this in the next release

Requested update was included in solution via another internal commit.

authors: chris-p-baker tylangesmith wallylv


text:
fix(swb datsets): shorten TTL for 2 min for upload to dataset

Issue #, if available: GALI-2409
Description of changes:
2 minutes TTL for S3 presigned URL for upload files to dataset based on the fact that we need our customers to manually interact with the URL and human interaction requires a reasonable time limit that is feasible to then use this URL. If we automate the interaction with the presigned URL in the future, we can shorten it even more.
I have manually tested that this time limit is reasonable and that it is imposed by this code change.
Checklist:

[x] Have you successfully deployed to an AWS account with your changes?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (81d82d8) 91.22% compared to head (c37bc9f) 91.22%.

Additional details and impacted files
@@                              Coverage Diff                              @@
##           release/4debe38e-5796-47b6-96ec-881a87e0df21    #1036   +/-   ##
=============================================================================
  Coverage                                         91.22%   91.22%
=============================================================================
  Files                                               207      207
  Lines                                              6197     6197
  Branches                                           1136     1136
=============================================================================
  Hits                                               5653     5653
  Misses                                              544      544

Flag
Coverage Δ

root
91.22% <100.00%> (ø)

swb-app
76.30% <ø> (ø)

swb-reference
94.23% <100.00%> (ø)

workbench-core-accounts
93.50% <ø> (ø)

workbench-core-accounts-ui
?

workbench-core-audit
?

workbench-core-authentication
?

workbench-core-authorization
?

workbench-core-base
?

workbench-core-datasets
?

workbench-core-datasets-ui
?

workbench-core-environments
?

workbench-core-environments-ui
?

workbench-core-infrastructure
?

workbench-core-logging
?

workbench-core-swb-common-ui
?

workbench-core-user-management
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...tions/swb-reference/src/services/dataSetService.ts
90.07% <100.00%> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter maghirardelli

repo: aws-solutions/solution-spark-on-aws


text:
Add support for EC2 Multicard

On d1.24xlarge and p4d.24xlarge  the reference to the 4x100 Gigabit networking is because of a feature called EC2 Multicard. It might be easier to just add a column called EC2Multicard Support with the number of multicards supported which in this case for dl1 and p4d is 4. Future instances will support this and this feature will continue to expand.
Instance Type  VCPUs   Mem (GiB)  Hypervisor  Current Gen  Hibernation Support  CPU Arch  Network Performance  ENIs    GPUs    GPU Mem (GiB)  GPU Info             On-Demand Price/Hr
-------------  -----   ---------  ----------  -----------  -------------------  --------  -------------------  ----    ----    -------------  --------             ------------------
dl1.24xlarge   96      768        nitro       true         false                x86_64    4x 100 Gigabit       60      8       256            Habana Gaudi HL-205  -No Price Filter Specified-
p4d.24xlarge   96      1,152      nitro       true         false                x86_64    4x 100 Gigabit       60      8       320            NVIDIA A100          -No Price Filter Specified-

The columns are currently pretty sacred space until we add the feature to specify which columns you want to show. I actually kind of like the minimal way it is formatted here as 4x 100 Gigabit.


text:
CLI setup error on "ecs init"

I recently followed the setup guide by Nathan Peck at https://aws.amazon.com/blogs/containers/announcing-the-amazon-ecs-cli-v2/.  After cloning and running all docker commands I ran chmod & sudo cp on the "ecs-preview" binary as I am running Mac OSX Mojave (10.14.6).  I then attempted to check the version and saw the following error:
2019/12/11 14:28:38 ERROR: unable to resolve endpoint for service "ssm", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "ssm", region: "", known: [us-west-1 eu-central-1 eu-west-1 eu-west-3 us-east-1 ap-northeast-1 ap-south-1 ap-southeast-1 ap-southeast-2 us-east-2 us-west-2 ap-northeast-2 me-south-1 sa-east-1 ap-east-1 ca-central-1 eu-north-1 eu-west-2]
2019/12/11 14:28:38 ERROR: unable to resolve endpoint for service "cloudformation", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "cloudformation", region: "", known: [eu-central-1 eu-west-3 us-east-1 ap-south-1 eu-west-1 me-south-1 sa-east-1 ap-northeast-1 ap-northeast-2 ap-southeast-1 eu-north-1 eu-west-2 us-west-2 ap-east-1 ap-southeast-2 ca-central-1 us-east-2 us-west-1]
2019/12/11 14:28:38 ERROR: unable to resolve endpoint for service "ssm", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "ssm", region: "", known: [us-east-1 ap-northeast-1 ap-south-1 ap-southeast-1 ap-southeast-2 eu-central-1 eu-west-1 eu-west-3 us-east-2 us-west-2 ap-northeast-2 me-south-1 ap-east-1 ca-central-1 eu-north-1 eu-west-2 sa-east-1 us-west-1]
2019/12/11 14:28:38 ERROR: unable to resolve endpoint for service "cloudformation", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "cloudformation", region: "", known: [me-south-1 sa-east-1 ap-south-1 eu-west-1 ap-southeast-1 eu-north-1 eu-west-2 us-west-2 ap-northeast-1 ap-northeast-2 ca-central-1 us-east-2 us-west-1 ap-east-1 ap-southeast-2 us-east-1 eu-central-1 eu-west-3]
ecs-preview version: 9441e11

I then cloned the example nyan-cat repo from https://github.com/nathanpeck/archer-nyan-cat into a sibling directory and attempted to follow the rest of the guide and ran into the following issues:
2019/12/11 14:29:57 ERROR: unable to resolve endpoint for service "ssm", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "ssm", region: "", known: [us-west-2 ca-central-1 eu-west-1 eu-west-3 sa-east-1 us-east-2 us-west-1 us-east-1 ap-east-1 ap-northeast-1 eu-central-1 eu-north-1 eu-west-2 me-south-1 ap-southeast-1 ap-southeast-2 ap-northeast-2 ap-south-1]
2019/12/11 14:29:57 ERROR: unable to resolve endpoint for service "cloudformation", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "cloudformation", region: "", known: [ap-northeast-1 ap-south-1 ap-southeast-1 eu-west-1 eu-west-2 us-west-1 ap-east-1 eu-central-1 eu-north-1 eu-west-3 me-south-1 sa-east-1 us-east-1 us-west-2 ap-northeast-2 ap-southeast-2 ca-central-1 us-east-2]
2019/12/11 14:29:57 ERROR: unable to resolve endpoint for service "ssm", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "ssm", region: "", known: [eu-central-1 eu-north-1 eu-west-2 me-south-1 us-east-1 ap-east-1 ap-northeast-1 ap-southeast-1 ap-southeast-2 ap-northeast-2 ap-south-1 eu-west-3 sa-east-1 us-east-2 us-west-1 us-west-2 ca-central-1 eu-west-1]
2019/12/11 14:29:57 ERROR: unable to resolve endpoint for service "cloudformation", region "", err: UnknownEndpointError: could not resolve endpoint
	partition: "aws", service: "cloudformation", region: "", known: [us-east-1 us-west-2 ap-northeast-2 ap-southeast-2 ca-central-1 us-east-2 ap-northeast-1 ap-south-1 ap-southeast-1 eu-west-1 eu-west-2 us-west-1 ap-east-1 eu-central-1 eu-north-1 eu-west-3 me-south-1 sa-east-1]
Note: It's best to run this command in the root of your Git repository.
Welcome to the ECS CLI! We're going to walk you through some questions
to help you get set up with a project on ECS. A project is a collection of
containerized applications (or micro-services) that operate together.

Looks like you are using a workspace that's registered to project nyan-cat-project. We'll use that as your project.
? Which type of infrastructure pattern best represents your application? [Use arrows to move, type to filter, ? f? Which type of infrastructure pattern best represents your application? Load Balanced Web App
? What do you want to call this Load Balanced Web App? test-nyan-cat
? Which Dockerfile would you like to use for test-nyan-cat app?  [Use arrows to move, type to filter, ? for more h? Which Dockerfile would you like to use for test-nyan-cat app? ./Dockerfile
Ok great, we'll set up a Load Balanced Web App named test-nyan-cat in project nyan-cat-project.
Error: execute project init: get caller identity: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: failed to find credentials in the environment.
SharedCredsLoad: failed to load profile, .
EC2RoleRequestError: no EC2 instance role found
caused by: RequestError: send request failed
caused by: Get http://169.254.169.254/latest/meta-data/iam/security-credentials/: dial tcp 169.254.169.254:80: connect: host is down

It looks like I need to make some changes to the example to test deploying it as the example shows.  I'd appreciate any pointers in that direction.  Also, I'm a bit confused by the "unknown endpoint" errors as that seems like my aws profile credentials are not being detected.
Thanks much,
Matt

Hi @mdstaff !
Thank you for trying the tool :D
This error seems to be similar to https://github.com/kubernetes-incubator/kube-aws/issues/1231#issuecomment-380744233. I wonder if you have the ~/.aws/config and ~/.aws/credentials files available on your device?
Can you run $ aws configure? and enter the credentials for your default profile. (https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)

Closing this as it's been a while since the last comment, feel free to re-open it if it's still an issue!

authors: efekarakus mdstaff


text:
Enable cross-compilation in Dockerfile

Issue #, if available: N/A
Description of changes:
Enable cross-compilation in Dockerfile. We need to add ARG TARGETOS TARGETARCH for them to be populated by buildx.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

authors: chewong nnmin-aws

repo: aws/amazon-eks-pod-identity-webhook