Fork me on GitHub
#portkey
<
2017-10-24
>
cgrand10:10:23

@qqq ^^ test and report

viesti10:10:58

one small step for man, but giant leap for Boot 🙂

qqq10:10:51

@cgrand: my clojure project does not build at the moment, but the moment it builds I'll switch to boot and test it out

qqq10:10:04

thanks for tracking it down and fixint it

qqq11:10:38

@cgrand confirmed to work for the following function

(defn sh []
     (str "trying again this time with boot function"))

qqq11:10:06

I now have an issue where lambda is updated, api gateway is updated, but cloudfront is stilling calling the old version. This however, is no longer a portkey issue.

qqq11:10:37

oh; I get it's a caching issue, caches probably assume that the return value of a GET request = does not change if URI does not change

viesti12:10:55

probably maps to caching in Cloudfront, which I should actually use myself also

viesti12:10:05

or learn to use that is

qqq12:10:32

@viesti: I called up AWS Business Support and got it resolved. There's three ways to call a lambda: 1. via the lambda endpoint 2. via the API Gateway endpoint that stages the lambda 3. via the CloudFront 'behaviour' that routes to the API Gateway now, when I update a lambda, and call the same URI, there . is potential for caching 1 & 2 do not do caching 3 does do caching (by default, but you can turn caching off)

viesti12:10:23

hmm so I don’t remember explicitly turning off caching

qqq12:10:11

@viesti: are you accessing lambda via API Gateway or CloudFront ? API Gateway has caching off by default.

viesti12:10:03

so I guess API Gateway

viesti12:10:15

I though that API gateway is a facade over Cloudfront 🙂

viesti12:10:23

or thereabouts

qqq12:10:01

Right, so according to the support engineer: If you use API Gateway end point (which uses CloudFront), caching is off by default. If you setup CloudFront separately (and create an origin [ppointing at API Gateway] + setup a Behaviour that points to origin), then Caching is on by default see: https://imgur.com/a/emNVY

qqq12:10:37

The one thing I have not got a good answer on is -- why do I want lambda requests cached at all ?

qqq12:10:31

=== Is there a way to control the name portkey uses?

(defn sh []
  (str "trying again this time with boot function"))

(pk/mount! sh "/")
results in a function of a Lambda name of:
/server_-snip_-aws_Ish
now, is there a way me to control what name is used on Lambda ?

qqq12:10:16

I'm trying to call mount! as

(pk/mount! sh "/"
           :lambeda-function-name "api-live")
but it's not creating a lambda with name api-live

viesti13:10:31

hmm, we don’t pass :lambda-function-name onwards from pk/mount! macro currently

viesti13:10:00

or on line 656 could work

viesti13:10:59

no, (make-lambda-function-name (meta ~var-f)) creates the name

viesti13:10:26

should do grab from arguments of mount!

qqq13:10:30

right, but it's in an (into ... )

qqq13:10:35

so the arguments from mount! goes into opts

qqq13:10:42

which should overwrite it due to the (into ...) on that line

cgrand13:10:47

@qqq you have an extra “e” in your snippet

qqq13:10:49

except it's not working 😞

qqq13:10:04

@cgrand: (pk/mount! h2 "/" :lambda-function-name "live") isn't working either

qqq13:10:15

but yes, valid typo

qqq13:10:37

or rather, vaild point that I made a typo

qqq13:10:27

wtf, it's working now ... somehow my aws console was outdated (despite me clicking on refresh)

qqq13:10:51

for anyone digging through the lotgs, what I ended up using is:

(defn h2 []
  (str "trying again this time with boot function"))

(pk/mount! h2 "/" :lambda-function-name "live")

qqq13:10:53

what is it with AWS limiting me on: * # of lambda I can post per minute * # of apis I can delete per minute (seems ot be set at 1)

viesti13:10:37

have hit on the management limits myself also

qqq14:10:06

They should make these limits "burstable" -- 29 days out of the month, I don't need to modify anything; but when I need to modify it, it's generally 5-10 changes I need to make.