Re: [google-appengine] get_num_instances always raises InvalidVersionError

[Vinny P]

On Sun, Mar 16, 2014 at 9:16 PM, Prateek Malhotra 
 wrote:

> Sorry, I meant if I put in the names of the module I want, 'default', or
> even if I omit all parameters, the error is raised. It was my impression
> that if the parameters were not supplied, it should pick up the current
> module/version and return that information to me.
>



It's strange that an InvalidVersionError is popping up - it means that App
Engine doesn't recognize the modules currently running, or that the module
isn't a basic scaling module.

How many modules are running within the application? If it's only one
module, can you add several modules to the application? Also, are all the
uploaded application versions module-based, or do they have the old
backend-style configurations? If there are old versions present, delete
them off so that only module-based versions exist in the app ID.


-
-Vinny P
Technology & Media Advisor
Chicago, IL

App Engine Code Samples: http://www.learntogoogleit.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Requests and Instances

[Bharath Kumaar]

Thanks Tim. I ll take a look in to that and try to emphasize it based on my 
need. 

On Tuesday, March 18, 2014 6:19:21 AM UTC+5:30, timh wrote:
>
> I agree with Barry.  
>
> instance level caching should really be kept for data that won't change 
> for the life of the instance.  ie static data that will only be changed 
> with a new deployment. due to all the issues
> of cache invalidation.
>
> However there is one other level of cache often overlooked and that is 
> request level caching.  (not sure how that can be performed in java :-)
>
> If you have entities that your code base may refer to multiple times 
> during the life of the request, then caching these entities at the request 
> level can be 
> a big win. the cache layers then look likedatastore -> memcache -> 
> request cache
>
> applicability obviously depends on the use case.
>
> Cheers
>
> Tim
>
>
> On Monday, March 17, 2014 8:56:12 PM UTC+8, barryhunter wrote:
>>
>> You could perhaps do it in a very crude fashion using traffic splitting. 
>>
>> https://developers.google.com/appengine/docs/adminconsole/trafficsplitting
>>
>> ie users can be directed to a consistent(ish) version. And each version 
>> has its own instances. 
>>
>>
>> But you can't stop each version spawning multiple instances, and hence 
>> invalidating and instance cache. 
>>
>>
>> As noted, use Memcache!
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Cloud Datastore manager is broken in new Google Developer Console

[husayt]

For one of my applications , Cloud Datastore manager is broken in new 
Google Developer Console.
Although it works for the other ones.

Is there a workaround, or is this a known issue?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Requests and Instances

[timh]

I agree with Barry.  

instance level caching should really be kept for data that won't change for 
the life of the instance.  ie static data that will only be changed with a 
new deployment. due to all the issues
of cache invalidation.

However there is one other level of cache often overlooked and that is 
request level caching.  (not sure how that can be performed in java :-)

If you have entities that your code base may refer to multiple times during 
the life of the request, then caching these entities at the request level 
can be 
a big win. the cache layers then look likedatastore -> memcache -> 
request cache

applicability obviously depends on the use case.

Cheers

Tim


On Monday, March 17, 2014 8:56:12 PM UTC+8, barryhunter wrote:
>
> You could perhaps do it in a very crude fashion using traffic splitting. 
>
> https://developers.google.com/appengine/docs/adminconsole/trafficsplitting
>
> ie users can be directed to a consistent(ish) version. And each version 
> has its own instances. 
>
>
> But you can't stop each version spawning multiple instances, and hence 
> invalidating and instance cache. 
>
>
> As noted, use Memcache!
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Mobile Chess Game

[Kristopher Giesing]

I've implemented a multiplayer board game using an iOS client and a GAE 
service.  I'd be more than happy to talk about my experiences.  If you 
search for my posts on this forum you'll probably find earlier mentions of 
the overall architecture, or if you want more specific information I can 
follow up in this thread.

- Kris

On Sunday, March 16, 2014 8:34:13 AM UTC-7, Vinny P wrote:
>
>
> On Sat, Mar 15, 2014 at 7:21 AM, José Santos 
> > wrote:
>
>> I'm new in this stuff and I have a question for my future project !
>> Is It possible to use the Google Backend to implement the 
>> conditions/logics of a Chess game (in Java)
>> and then on an Android/IOS play the game with the info stored in the 
>> Backend ?
>>
>
>
> Yes you can. The backend doesn't care about the OS that the request 
> originates on. As long as your client application can speak regular HTTP to 
> the backend, that's all that matters.
>   
>  
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.com
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Can Application Settings anyhow guarantee me exactly 2 instances?

[Andrei Volgin]

Aron,

If you need exactly two instances and the cost is of importance, you should 
consider running your application on two Compute Engine instances that cost 
many times less than the App Engine instances. You can still access the 
datastore.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Using Cloud Datastore API in app engine

[Barry Hunter]

On 17 March 2014 18:28, Kinesh Patel  wrote:

>
> We have a need to share a datastore across multiple app engine apps. (e.g.
> we would like to use Flask for our public API, but django for our internal
> Saas Product  with different scaling needs as just one example).
>

That sounds like a perfect use case for modules.



>
> Has anyone used the Cloud Datastore API to do something like this?
>

bare in mind that API actully uses a AppEngine app to perform the proxying.
Possibly in a hidden module or version.




> Will I get the same performance (network latency, etc.) that I do normally
> in my app engine app, or does the HTTP layer route requests differently and
> introduce overhead?
>

Would expect some latency yes. urlfetch to www.googleapis.com > proxies
back to a appengine instance > to real datastore.



>
> Is there some other way to share a single datastore across multiple app
> engine apps? Does the modules functionality provide a separate 'main'
> entrypoint to allow for different python web frameworks?
>

Each module is accessible on its own subdomain. Or can override that and
access multiple via the default domain.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Using Cloud Datastore API in app engine

[Kinesh Patel]

We have a need to share a datastore across multiple app engine apps. (e.g. 
we would like to use Flask for our public API, but django for our internal 
Saas Product  with different scaling needs as just one example). 

Has anyone used the Cloud Datastore API to do something like this? Will I 
get the same performance (network latency, etc.) that I do normally in my 
app engine app, or does the HTTP layer route requests differently and 
introduce overhead?

Is there some other way to share a single datastore across multiple app 
engine apps? Does the modules functionality provide a separate 'main' 
entrypoint to allow for different python web frameworks?


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Can Application Settings anyhow guarantee me exactly 2 instances?

[Jacob Taylor]

One suggestion...I would check out the modules API. If you make everything
a module, you could potentially set it to manual scaling and pick 2
instances. If I am correct, this would mean you always had 2, but never
more.


On Sat, Mar 15, 2014 at 6:15 PM, Barry Hunter wrote:

>
>
>
> On 16 March 2014 00:59, PK  wrote:
>
>> My understanding is that you might see more than 2 but you will not be
>> charged for more than 2 with these settings.
>>
>
> You wont be charged for more than 2 *idle* instances.
>
> But if the scheduler, spins up many instances, and they are serving
> traffic (however small) they are chargeable.
>
> min_idle_instances says appengine should always aim to keep this number of
> *deliberately* idle instances. So it will spin up enough to keep at least
> two idle at any time. (and because of the max_idle_instances, it shouldnt
> grow much *beyond* 2, and if it does wont be charged)
>
>
> (an idle instance, doesnt normally serve traffic, but in the case of a
> sudden spike, it should be able to serve a few, while new instances are
> being spun up. Once they are spun up, idle instances will go back to well,
> being idle)
>
>
> ... there simply isnt a max_instances, setting.
>
>
>
>>
>> PK
>> http://www.gae123.com
>>
>> On March 15, 2014 at 5:28:11 PM, Aron Gombas (aron.gom...@gmail.com)
>> wrote:
>>
>>  Hi!
>>
>> I have an important, low-traffic, internal app. There are typically 0-2
>> concurrent users, the "peak" would be maybe 5-6. Plus, there are some cron
>> jobs and warmup requests that are also needs to be served, but I believe 1
>> or 2 resident instances should be able to handle all traffic easily.
>>
>> As an experiment, what I want to completely eliminate is loading
>> requests, after those 2 instances have been started. This is Java app, and
>> the 10-15s additional response time caused by loading requests totally
>> kills the experience. So, I'm happy to pay for the idle time, but I'd like
>> to be sure that new instances are never started, and I pretty much bypass
>> the heuristics and auto-scaling of the Scheduler.
>>
>> Is this possible at all?
>>
>> These are my current settings:
>>
>>   min_idle_instances: 2
>>   max_idle_instances: 2
>>   min_pending_latency: 10ms
>>   max_pending_latency: 15.0s
>>
>> With these, when I look at the instances I can see 2 resident plus 2
>> dynamic instances, although I'm the only user currently using the app.
>> (There are short cron jobs and occasional warmup requests.)
>>
>> Cheers,
>>
>> Aron
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-appengine+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-appengine+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Requests and Instances

[Bharath Kumaar]

Thanks Barry. Yes i do need to do some validations. So it will leave the 
other instances cache to stay as it is until the instance shutdown. All 
things leading me to kill instance cache for this operation.

So i will better restrict my instance caching with constants and enums. 

Thanks Guys for clearing my doubt.

On Monday, March 17, 2014 6:40:18 PM UTC+5:30, barryhunter wrote:
>
>
>
>
> On 17 March 2014 12:59, Bharath Kumaar 
> > wrote:
>
>> Thanks Stephan. Memcache is my second level. My level of retrieving data 
>> will be Instance Cache, Mem cache and then Datastore. But from your reply i 
>> guess i have to go with mem cache directly and then DataStore. As mine is 
>> kind of single page application, i thought of adding Instance caching.
>>
>
> You can add instance caching well if you want. 
>
> Just that its (more) optimistic. It might not be in the instance cache 
> (because the user has happened to hit a different instance), in which case 
> can be got from memcache. If not memcache than datastore. 
>
> ie hit ratio will be lower than memcache, but hopefully big enough that 
> worth it. 
>
> ... but it does bring another issue. As there are multiple instances, 
> invalidation doesn't work. You can invalidate (or update!) the local 
> instance cache, but it wont(!) update the other instance caches. 
> Depends on your usecase if need invalidation and/or updating of caches. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Requests and Instances

[Barry Hunter]

On 17 March 2014 12:59, Bharath Kumaar wrote:

> Thanks Stephan. Memcache is my second level. My level of retrieving data
> will be Instance Cache, Mem cache and then Datastore. But from your reply i
> guess i have to go with mem cache directly and then DataStore. As mine is
> kind of single page application, i thought of adding Instance caching.
>

You can add instance caching well if you want.

Just that its (more) optimistic. It might not be in the instance cache
(because the user has happened to hit a different instance), in which case
can be got from memcache. If not memcache than datastore.

ie hit ratio will be lower than memcache, but hopefully big enough that
worth it.

... but it does bring another issue. As there are multiple instances,
invalidation doesn't work. You can invalidate (or update!) the local
instance cache, but it wont(!) update the other instance caches.
Depends on your usecase if need invalidation and/or updating of caches.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Requests and Instances

[Bharath Kumaar]

Thanks Stephan. Memcache is my second level. My level of retrieving data 
will be Instance Cache, Mem cache and then Datastore. But from your reply i 
guess i have to go with mem cache directly and then DataStore. As mine is 
kind of single page application, i thought of adding Instance caching. So 
now i have to afford for that extra 10ms to 100ms for mem cache.

On Monday, March 17, 2014 6:19:04 PM UTC+5:30, hart...@metamesh.de wrote:
>
> You can't expect that requests of one user are always served by the same 
> instance, so you cannot rely on a hash map that is local to a single vm.
> Instead you should use memcache backed by the datastore. There is a nice 
> library that does all the magic:
> http://code.google.com/p/stick-cache/
>
> Best regards,
> Stephan
>
> Am Montag, 17. März 2014 11:35:01 UTC+1 schrieb Bharath Kumaar:
>>
>> Hi guys, I have a doubt regarding Requests and Instances from which it is 
>> served. 
>>
>> My plan is to create instance caching for my project. So i ll be using 
>> hash map where key will be the user key and value is his data.  My doubt 
>> is, is there any way if users log in request serves from one instance and 
>> other requests from some other instances i.e will it fluctuate. 
>>
>> And also, will instance caching of more data leads to any big issues?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Requests and Instances

[Barry Hunter]

You could perhaps do it in a very crude fashion using traffic splitting.

https://developers.google.com/appengine/docs/adminconsole/trafficsplitting

ie users can be directed to a consistent(ish) version. And each version has
its own instances.


But you can't stop each version spawning multiple instances, and hence
invalidating and instance cache.


As noted, use Memcache!

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Requests and Instances

[hartmann]

You can't expect that requests of one user are always served by the same 
instance, so you cannot rely on a hash map that is local to a single vm.
Instead you should use memcache backed by the datastore. There is a nice 
library that does all the magic:
http://code.google.com/p/stick-cache/

Best regards,
Stephan

Am Montag, 17. März 2014 11:35:01 UTC+1 schrieb Bharath Kumaar:
>
> Hi guys, I have a doubt regarding Requests and Instances from which it is 
> served. 
>
> My plan is to create instance caching for my project. So i ll be using 
> hash map where key will be the user key and value is his data.  My doubt 
> is, is there any way if users log in request serves from one instance and 
> other requests from some other instances i.e will it fluctuate. 
>
> And also, will instance caching of more data leads to any big issues?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Strong and eventuall consitency vs performance

[Jon Anders Sollien]

Some data loads in my application are depending on being 
strongly consitent, others are not.

In 
https://developers.google.com/appengine/docs/java/datastore/queries#Java_Ancestor_queries
 
I read: Setting an ancestor 
filter
 allows 
for strongly consistent queries. Queries without an ancestor filter only 
return eventually consistent results.

Lets say I have a class 
MyClass.class {
@Parent Key parent;
@Index Key anotherParent;
@Index String firstName;
}

Question 1: Does this mean that queries with both ancestor limiter and 
filters are strongly consistent? Example: 
ofy().load().type(MyClass.class).ancestor(parentKey).filter("firstName = 
",firstName);

Question 2: In some other data loads, performance is more important. Assume 
example "A" and "B". Will "A" have the same performance as "B"?

A. 
ofy().consistency(Consistency.EVENTUAL).load().type(MyClass.class).ancestor(parentKey).filter("firstName
 
= ",firstName) 
B. 
ofy().load().type(MyClass.class).filter(anotherParentKey).filter("firstName 
= ",firstName)

Thank you in advance

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Requests and Instances

[Bharath Kumaar]

Hi guys, I have a doubt regarding Requests and Instances from which it is 
served. 

My plan is to create instance caching for my project. So i ll be using hash 
map where key will be the user key and value is his data.  My doubt is, is 
there any way if users log in request serves from one instance and other 
requests from some other instances i.e will it fluctuate. 

And also, will instance caching of more data leads to any big issues?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Can Application Settings guarantee that I have exactly(!) N instances running all the time (i.e. no loading requests after the initial start)?

[Aron Gombas]

Thanks, Barry! Modules with "Manual" (or "Basic") scaling seems exactly 
what I need. 

Aron

On Sunday, March 16, 2014 1:59:35 AM UTC+1, barryhunter wrote:
>
> You should be able to do it via modules
> https://developers.google.com/appengine/docs/java/modules/
>
> Can choose the 'scaling' class to use. Even when just having one 'default' 
> module. 
>
> (the main drawback of this, is you only get free 8 'hours' quota, rather 
> than 28 if leave it on the original automatic scaling - ie would use B4's 
> rather than F4's) 
>
> ... its the same (in effect) as as running your 'app' via a backend 
> instance of yesteryear.  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] default bucket name in GCS

[Stefano Ciccarelli]

Amy,

I think I have another problem:

first of all on "Application Settings" tab I have a default Google Cloud
Storage Bucket named cloudmotive.appspot.com (as my app is named);

the default bucket now holds
$ gsutil du -achs gs://cloudmotive.appspot.com
14.32 GBgs://cloudmotive.appspot.com
14.32 GBtotal

On the App Engine dashboard I read
 Cloud Storage Standard Storage 0.00 GBytes 0.00$0.0027/ GByte-day $0.00

So I think that all that data is billed by the Cloud Console project and I
don't know what happened to the free quota.

Can you help me to understand?

Stefano





2014-03-14 3:46 GMT+01:00 Amy Unruh :

> There is indeed a default auto-created bucket, with bucket name "
> your-app.appspot.com", that is getting rolled out and backfilled to
> existing apps and their associated projects.  Not all projects may have it
> yet.  If the 5GB quota is sufficient for your needs, you ought to be able
> to just start using it as you would any bucket.
>
> Go to the Application Settings page for the app engine app you want to use
> that bucket with, and grab the app's service account address.
> Then go to the cloud console (cloud.google.com/console) and make sure
> that service account is listed in the Permissions page of the project that
> includes this default bucket, with 'edit' permissions.
>
>
>
> On 13 March 2014 08:05, Stefano Ciccarelli  wrote:
>
>> I have the same problem, the default bucket I created is billed by the
>> Cloud Platform Console and seems to not belong to GAE.
>>
>> Il mercoledì 12 marzo 2014, GAEfan  ha scritto:
>>
>> I migrated an older legacy app from blobstore to GCS, using these
>>> instructions:
>>>
>>> https://developers.google.com/appengine/docs/python/googlestorage/
>>>
>>> So, I added a bucket using the GCS Developer Console.  What was not
>>> properly explained is that, by following these instructions, you are not
>>> using the free (5GB quota) default bucket, but a billable bucket.
>>>
>>> Is there a way to make the new bucket I created the default bucket, to
>>> fall within the free quota?
>>>
>>> Or, must I now go through the App Engine > Application Settings console
>>> to "Create a Google Cloud project as well as a Google Cloud Storage
>>> bucket for this application.", thereby getting the free default bucket, and
>>> then migrate everything over (again)?
>>>
>>> Thank you.
>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Google App Engine" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-appengine+unsubscr...@googlegroups.com.
>>> To post to this group, send email to google-appengine@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/google-appengine.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Nel mondo esistono 10 categorie di persone, quelle che capiscono il
>> binario e quelle che non lo capiscono.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-appengine+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Nel mondo esistono 10 categorie di persone, quelle che capiscono il binario
e quelle che non lo capiscono.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.