Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 'package' command #61

Closed
Miserlou opened this issue Apr 16, 2016 · 11 comments

Comments

Projects
None yet
3 participants
@Miserlou
Copy link
Owner

commented Apr 16, 2016

It could be useful to have Zappa be a more general Lambda utility - for instance, for automatically using lambda-packages and minifying, etc.

@ubiquitousthey

This comment has been minimized.

Copy link

commented Apr 30, 2016

I started a fork to add the package and/or upload functionality. I got stuck where I needed to figure how how to do the settings. The settings file really needs to change so that one can define most of the environment settings on individual functions with an additional handler setting. How do you see this working? I am thinking something like:

{
    "dev": { // The name of your environment
       "app" : {
         "s3_bucket": "lmbda", // The name of your S3 bucket
         ... // Various lambda attributes
         "app_function": "your_module.app" // The python path to your WSGI application function.
       },
       "my_function" : {
         "s3_bucket": "lmbda", // The name of your S3 bucket
        ... //Various Lambda attributes
         "handler": "module.function" // The handler for the lambda function
       }
    }
}

I think it would be pretty easy to handle both the old-style and new-style. If there is an "app" key in the dictionary, load as new-style, if not load as old-style.

Your thoughts?

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented May 3, 2016

Hi ubiquitousthey - thanks for bringing this up.

I think that might be over-engineering it a bit. I don't think an environment would have a both an app_function and a handler - just one or the other, with app_function taking precedent over handler. Does that make sense, or is there a scenario I'm missing?

@ubiquitousthey

This comment has been minimized.

Copy link

commented May 3, 2016

I have an system I am working on that will have a web component that I would develop with zappa/flask. It also will have a few lambda functions that get triggered by SES and a timer. I was thinking it would have a configuration like the one above.

In this case I was thinking one could issue:
zappa dev deploy or
zappa dev deploy app or
zappa dev deploy my_ses_handler

This could also be accomplished with an environment per function or app as well, and that could leave the format pretty much the same and simplify the changes to the code, but it would push toward environments that would result in command like:

zappa app-dev deploy and
zappa my_ses_handler-dev deploy

which would result in some uglier function and apig names.

Maybe the the idea would be to have one settings file per app or function?

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented May 3, 2016

I was thinking that it would be a settings entry for each function.

Although, to be honest, I think my longer term vision would be that non-APIGW lambda functions could simply be wrapped as decorators as a way to replace Celery, etc, so you could do something like

@zappa(event_source="ses:blah")
def mail(event):
    return True

or for scheduled events:

@zappa(timing="0 0 0 * * *")
def defrag(event):
    return True

and have these functions created and configured automatically with deploy/update.

But I've held off on implementing that since lambda scheduling can't be done via API/boto yet. Thoughts?

@ubiquitousthey

This comment has been minimized.

Copy link

commented May 3, 2016

One zapp_settings file per function sounds reasonable.

The decorators sound interesting. I like being able to define the triggers in code. There might need to be a way to configure environment. One might have 2 SNS topics: one for testing and one for production. I suppose the precompile step could be used to load settings from a renamed json or py.

I think the lambda schedule is available now as a cloud watch event.
http://boto3.readthedocs.io/en/latest/reference/services/events.html?highlight=cloud%20watch%20event#CloudWatchEvents.Client.put_rule

You would have to call put_rule and put_target.

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented May 3, 2016

Ooo.. excellent find. Cool.

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented May 4, 2016

Keep-Warm using CloudWatch Events is now in Master.

@ubiquitousthey

This comment has been minimized.

Copy link

commented May 5, 2016

Cool. I'll create a PR for the settings-per-function idea as that moves me forward. I'll look at the decorator idea after that.

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2016

You are actually already be able to specify a different settings file using the '-s' argument.

@kienpham2000

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2016

I think we should model this CLI similar to docker:
zappa build
zappa push
..etc

Each function can have its Zappafile settings

@Miserlou

This comment has been minimized.

Copy link
Owner Author

commented Jan 13, 2017

Thanks @michi88 for implementing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.