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

Switch to region specific runtimes #169

Merged
merged 6 commits into from Aug 26, 2017

Conversation

ericmjonas
Copy link
Collaborator

@ericmjonas ericmjonas commented Aug 23, 2017

This pull request changes:

  1. the defaults that we use for runtimes
  2. The way we lookup runtime information

In particular, we now explicitly get the runtime meta.json instead of having the hack where we assume there is some root .tar.gz. This should have no user-visible impact; the sharded runtime has been default for quite a while.

We now have runtimes and associated buckets in all the major US regions, in public buckets. It's easy to add more, as well.

I am not tying this to the new runtime builder as technically they are independent. Old runtimes should work with this code as well.

Closes issue #164

# NOTE: There is some probability we will hit the base key ?
self.assertNotEqual(future.run_status['runtime_s3_key_used'],
base_runtime_key)
# def test_no_shard(self):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to be clear is this test not going to be applicable from here on or is it that we will add shards to the new region-specific runtimes as well ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I don't quite understand the question; All future runtimes, including those that are region-specific, will be sharded. Thus eliminating these tests.

This seems reasonable because:

  1. if you don't shard the runtime you run into performance issues really quickly
  2. All "sharding" technically is is sticking the runtime at some locations pointed to by the meta.json. So we could in the future support single-tarball sharding if we wanted with no change in code. In fact, for testing, I often don't fully shard and just have the meta.json point to a single tarball.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I was just wondering which way we went in terms of all sharding vs. no sharding.
Do we still want to test the meta.json -> shards being picked up correctly ? If not we can just delete these tests.

@ericmjonas
Copy link
Collaborator Author

Ok @shivaram got rid of that test

Copy link
Collaborator

@shivaram shivaram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ericmjonas - LGTM

@ericmjonas ericmjonas merged commit f57c915 into master Aug 26, 2017
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

Successfully merging this pull request may close these issues.

None yet

2 participants