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
Closed

Add 'package' command #61

Miserlou opened this issue Apr 16, 2016 · 11 comments

Comments

@Miserlou
Copy link
Owner

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

@ubiquitousthey
Copy link

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
Copy link
Owner Author

Miserlou 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
Copy link

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
Copy link
Owner Author

Miserlou 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
Copy link

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
Copy link
Owner Author

Miserlou commented May 3, 2016

Ooo.. excellent find. Cool.

@Miserlou
Copy link
Owner Author

Miserlou commented May 4, 2016

Keep-Warm using CloudWatch Events is now in Master.

@ubiquitousthey
Copy link

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
Copy link
Owner Author

Miserlou commented May 5, 2016

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

@kpx-dev
Copy link
Collaborator

kpx-dev 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
Copy link
Owner Author

Thanks @michi88 for implementing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants