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 option to specify output s3 bucket #4

Open
shelbyt opened this issue Oct 11, 2016 · 5 comments
Open

Add option to specify output s3 bucket #4

shelbyt opened this issue Oct 11, 2016 · 5 comments

Comments

@shelbyt
Copy link
Member

shelbyt commented Oct 11, 2016

Output s3 buckets are hardcoded based on the name of the input parameters:
outName = "%s-y4m_%02d" % (ServerInfo.video_name, ServerInfo.num_frames)

ServerInfo should have another option to specify an output s3 bucket, else use the default parameters.

@kwantam
Copy link
Member

kwantam commented Oct 12, 2016

ServerInfo doesn't really have much to do with core mu functionality. libmu/server.py has some convenience functions that, e.g., construct help messages and getopt strings, but probably it's better to break those out from mu rather than try to bake more and more options into them.

In other words, it's probably better to think of ServerInfo as something the user implements, not something mu provides. That we're doing the latter right now is a result of laziness/lack of time while we were pushing toward the submission.

@shelbyt
Copy link
Member Author

shelbyt commented Oct 14, 2016

Looking at the code it looks like there are two classes of configurations:

  1. Options that are needed by Mu to spawn lambdas (i.e. regions, lambda_function, cacert)
  2. Options that the user wants to keep track of for his own convenience (i.e. video_name, in_format?)

Currently both of these types of options are tightly coupled in as a ServerInfo object and used in libmu/server.py but we want to break these out of Mu. Does that sound about correct?

@kwantam
Copy link
Member

kwantam commented Oct 14, 2016

Yup, exactly.

@shelbyt
Copy link
Member Author

shelbyt commented Oct 14, 2016

This is probably just a terminology issue but it's not clear to me what you mean by breaking them out of Mu if Mu needs Class 1 options to function.

My initial thought was to have a matching .cfg file for each server with just Class 1 options that can be validated in a checking stage like you've mentioned in #3.

Then as usual the user can do whatever they want with their Class 2 options.

@kwantam
Copy link
Member

kwantam commented Oct 14, 2016

Sorry, I should have clarified in my previous answer that "breaking out" should only apply to class 2, as you say.

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

2 participants