from:"Karl MacMillan"

Re: [google-appengine] Re: Is there a possible way to have two datastores for the same application?

2016-04-11 Thread Karl MacMillan



> On Apr 11, 2016, at 6:31 PM, Nick  wrote:
> 
> While you could use namespaces to achieve this, you need to consider what it 
> means to have two 'environments' running together, and what are the 
> consequences of mistakes.
> 
> Generally we've found the simplest option is to have extra cloud projects for 
> extra environments, which is usually very cheap/free assuming you aren't 
> simulating real loads constantly. Obviously there are some drawbacks to this, 
> such as ease of code promotion, but if you're using other services in google 
> cloud, they aren't intrinsically namespace aware, so you need to be careful.
> 

We use separate projects as well and it works reasonably well. It makes it much 
less stressful to push builds to the test environment. 

Unfortunately you are likely to need some sort of mechanism to change 
configuration between environments. For example, if you use google cloud 
storage, bucket names must be globally unique so you have to store or derive 
the root bucket names for each environment. 

Karl

>> On Monday, April 11, 2016 at 11:20:34 PM UTC+10, youssef dehbi alaoui wrote:
>> hi everyone i need in my application two types of data (but same entities), 
>> one for testing and the other for production... so i'm wondering if there is 
>> a solution to make a difference between these two types like having two 
>> datastores 
>> Thanks.
> 
> -- 
> 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 https://groups.google.com/group/google-appengine.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/b51ace6a-b8c5-4404-97eb-6793408f4027%40googlegroups.com.
> 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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/3676F8DE-8885-44F3-B467-8997FCFE5979%40strajillion.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] An update on webapp2

2016-04-11 Thread Karl MacMillan


> On Apr 11, 2016, at 1:28 AM, 'Jon Parrott' via Google App Engine 
> <google-appengine@googlegroups.com> wrote:
> 
> Karl, first and foremost: thanks for being the first person to contribute.
> 
> Yes, I just missed the makefile when I was cleaning things up. I'll remove 
> that and update contributing.md to document how to run tests. In the 
> meantime, you can checkout the travis config file. Mostly, you just need to 
> install nox-automation and run nox -s tests. Travis ran for your PR and it 
> passed <https://travis-ci.org/GoogleCloudPlatform/webapp2/builds/122147953>.
> Enabling the CLA bot is standard procedure, and the OSS lawyer that assisted 
> me in moving over this project did not indicate that it should be passed 
> over. I am not lawyer, however, from what I understand t the CLA does not 
> remove any of your rights as a the author, it just grants the project rights 
> to your contribution (this seems to be pretty clearly stated at the beginning 
> of the CLA itself). If concerns over the CLA cause you to not want to 
> contribute further, I'll be happy to get you in contact our open source 
> programs office so that we can potentially address your concerns.
> 

While the CLA does not remove any of my rights, it does grant Google 
significantly more rights than those granted by the Apache 2 license. In 
projects like the Linux kernel that don’t have a CLA process, everyone is on 
equal footing and has the same rights - those granted by the GPL. With a CLA 
like this one it becomes a two tier system. The community at large only has the 
rights granted by Apache 2 (and ownership of any code that they created), while 
Google has effective ownership over all contributed code and a perpetual patent 
license. I think that inequality is ultimately harmful to the community.

For projects that you started I would not object. It just seems . . . 
aggressive . . . for you guys to take over a project and significantly change 
the terms under which contributions are handled. Don’t get me wrong - I 
appreciate that you are investing developer resources into webapp2 and taking 
on the maintenance role. It’s overall a much better situation. And I signed the 
CLA and I’ll contribute if I can despite the CLA.

I’m happy if you want to connect me with the open source programs office.

Karl

> On Sunday, April 10, 2016 at 7:49:07 PM UTC-7, Karl MacMillan wrote:
> 
>> On Apr 8, 2016, at 4:58 PM, 'Jon Parrott' via Google App Engine 
>> <google-a...@googlegroups.com > wrote:
>> 
>> In a previous thread 
>> <https://groups.google.com/forum/#!topic/google-appengine/HazEmXZRpiw>, 
>> several of you pointed out that webapp2 was abandoned and some of you 
>> expressed interesting in helping maintain the project.
>> 
> 
> Jon,
> 
> Thanks for stepping up and making this happen. I’ve submitted a pull request 
> for the bug that I mentioned in that thread.
> 
> Two things:
> 
> 1) Is all of the test infrastructure checked in? I ask because the Makefile 
> (and the test target) are referencing a non-existent run_tests.py in the root 
> of the project. I also didn’t see any documentation on how to run the tests, 
> especially the ones with GAE dependencies.
> 
> 2) Is it intentional that a CLA is being required to submit patches? I’m not 
> a CLA fan in general, but I understand that they may make sense in some 
> contexts. However, in this case it seems unfortunate and potentially 
> pointless to take a community project, pull it in as a Google project, and 
> then require a CLA. It’s not like you have the copyright grant for all of the 
> previous work so that requiring the CLA for new patches actually gets you any 
> sort of licensing freedom or full patent protection. If you really want to go 
> with this approach I’ll sign the CLA for this trivial patch, but it will 
> likely discourage me from any other contribution. (I hate to keep complaining 
> since you’ve done so much to move this forward - it’s just that this seems 
> like a really strange approach to take).
> 
> Thanks - Karl
> 
>> I'm happy to provide an update. The original author has allowed the Google 
>> Cloud Platform Developer Relations team to assume ownership of webapp2. 
>> We've moved the project to github and we're ready to accept pull requests.
>> webapp2 now lives at GoogleCloudPlatform/webapp2 
>> <https://github.com/GoogleCloudPlatform/webapp2>.
>> Tests are running on travis 
>> <https://travis-ci.org/GoogleCloudPlatform/webapp2> and code coverage 
>> reporting 
>> <https://codecov.io/github/GoogleCloudPlatform/webapp2?branch=master>.
>> The documentation is now published to readthedocs 
>> <http://webapp2.readthedocs.org/en/latest/>

Re: [google-appengine] An update on webapp2

2016-04-10 Thread Karl MacMillan

> On Apr 8, 2016, at 4:58 PM, 'Jon Parrott' via Google App Engine 
>  wrote:
> 
> In a previous thread 
> , 
> several of you pointed out that webapp2 was abandoned and some of you 
> expressed interesting in helping maintain the project.
> 

Jon,

Thanks for stepping up and making this happen. I’ve submitted a pull request 
for the bug that I mentioned in that thread.

Two things:

1) Is all of the test infrastructure checked in? I ask because the Makefile 
(and the test target) are referencing a non-existent run_tests.py in the root 
of the project. I also didn’t see any documentation on how to run the tests, 
especially the ones with GAE dependencies.

2) Is it intentional that a CLA is being required to submit patches? I’m not a 
CLA fan in general, but I understand that they may make sense in some contexts. 
However, in this case it seems unfortunate and potentially pointless to take a 
community project, pull it in as a Google project, and then require a CLA. It’s 
not like you have the copyright grant for all of the previous work so that 
requiring the CLA for new patches actually gets you any sort of licensing 
freedom or full patent protection. If you really want to go with this approach 
I’ll sign the CLA for this trivial patch, but it will likely discourage me from 
any other contribution. (I hate to keep complaining since you’ve done so much 
to move this forward - it’s just that this seems like a really strange approach 
to take).

Thanks - Karl

> I'm happy to provide an update. The original author has allowed the Google 
> Cloud Platform Developer Relations team to assume ownership of webapp2. We've 
> moved the project to github and we're ready to accept pull requests.
> webapp2 now lives at GoogleCloudPlatform/webapp2 
> .
> Tests are running on travis 
>  and code coverage 
> reporting 
> .
> The documentation is now published to readthedocs 
> .
> The official website will soon be updated to redirect to readthedocs.
> We could really use the community's help to:
> Test it! We cleaned up a bit of stuff and we want to make sure that 
> everything still works as expected.
> Check the new documentation  for 
> accuracy and report any content errors or bad links.
> Triage the issues 
> 
>  that were transferred over from the original project. If you want to just 
> review them and comment whether or not they are still relevant, that would be 
> super helpful.
> Fix issues. :)
> We'll soon release version 3.0.0 to PyPI. This is to mark the ownership 
> transition. We will look into updating the version included with Google App 
> Engine.
> 
> -- 
> 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 https://groups.google.com/group/google-appengine 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/9a193edb-363d-4ce9-b64f-b0b818f5cd14%40googlegroups.com
>  
> .
> 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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/1FBD6FE8-128F-4723-9C25-478584BF74AF%40strajillion.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] New App Engine Managed VM Docs

2016-03-04 Thread Karl MacMillan


> On Mar 4, 2016, at 1:57 PM, 'Jon Parrott' via Google App Engine 
> <google-appengine@googlegroups.com> wrote:
> 
> Just a quick update on the webapp2 situation. The original author has 
> graciously allowed us to take ownership. My team is working on getting 
> everything moved to github and making sure that we can properly test and 
> release new versions. I'll make an announcement on this group when the github 
> repository is ready. At that point, we'll be able review and accept pull 
> requests from the community to maintain webapp2.
> 

Thanks for the update - looking forward to some updates.

One of the missing pieces for some of the problems that I encountered is a 
modern, native (i.e., fast) implementation of modern password hashing (e.g., 
PBKDF2, SCrypt, or BCrypt). Am I just missing a python module for this that is 
available for App Engine?

Thanks,

Karl

> On Tuesday, February 23, 2016 at 3:51:56 AM UTC-8, troberti wrote:
> This is encouraging to hear and hope it happens. I like webapp2 just fine as 
> it is: simple, stable, easy to test, *just works*. The fact that it doesn't 
> 'evolve' is imho a good thing. Bug fixes are of course always welcome.
> 
> On Tuesday, February 23, 2016 at 5:21:29 AM UTC+1, Alex Martelli wrote:
> Just a personal input/data point -- writing not as a Googler but as a "Python 
> guru":-)
> 
> Currently writing the 3rd edition of Python in a Nutshell (in my copious 
> personal time), I've recently finished the "serving HTTP" chapter (the book 
> is already available in Early Release form at the O'Reilly website, check it 
> out:-). For the purpose, I thoroughly tested lightweight frameworks (rich 
> frameworks such as django, web2py, and the like, though I mentioned them, 
> aren't really "my thang"). Specifically: falcon, flask, bottle, and webapp2.
> 
> Of the four, webapp2 remains my favorite (admittedly I started out knowing it 
> much better than the others, which may have biased me). Next in order of 
> preference, falcon, bottle, flask -- all good, but the most popular, flask, 
> is accruing so much extras that it barely qualifies as "lightweight" any more.
> 
> If webapp2 becomes easy to offer patches for again, I'll spend personal time 
> (once the Nutshell is finished -- give me a few more months!-) helping there 
> -- indeed I'll volunteer to vet pull requests if gurus to vet them are needed 
> -- to help keep out the kinds of deep integration with unrelated components 
> (such as the admittedly superb templating framework jinjia2) which are 
> fattening up flask:-(.
> 
> I sure hope (very personal preference) that webapp2 isn't put out to 
> pasture... should it be, I might either fork it, or give up and move to 
> falcon for new projects (and maybe volunteer to help out on THAT framework).
> 
> Again, just personal preferences -- but, ones based on almost 20 years' 
> experience with Python (starting with a personal website project using CGI) 
> and on being a Fellow of the PSF and a winner of the Frank Willison Memorial 
> Award for contributions to Python:-).
> 
> 
> Alex
> 
> 
> On Mon, Feb 22, 2016 at 2:34 PM, Karl MacMillan <ka...@strajillion.com <>> 
> wrote:
> 
>> On Feb 22, 2016, at 4:40 PM, 'Jon Parrott' via Google App Engine 
>> <google-a...@googlegroups.com <>> wrote:
>> 
>> > if you ask me, you really should just put webapp2 into maintenance only 
>> > mode and suggest people move on. There are no advantages over more popular 
>> > frameworks and plenty of downsides.
>> 
>> In general we want to align with the Python community. Whether we update our 
>> docs to point to Flask over webapp2 is currently a point of discussion - but 
>> I'm personally for it.
> 
> If you don’t make the change (or maybe until), can I strongly suggest you 
> include some discussion that makes it clear the level of support for webapp2. 
> Like I said - I went with that option on the mistaken impression that it was 
> well supported by Google. That’s the _only_ thing that irritates me about 
> this whole situation. I believe the docs lead me down a path without warning 
> me of the true consequences. Even a basic “webapp2 is community supported 
> framework” description would make it clearer.
> 
>> No matter what we do there, there should be some way for people who are 
>> currently using webapp2 currently to provide patches.
>> 
> 
> I’d certainly appreciate that. Despite my complaints, I’m not itching to port 
> all of my code off of webapp2 because it’s working fine.
> 
> Karl
> 
>> Putting webapp2 in maintenance only mode is not currently our decision as we 
>> do not own the package (it

Re: [google-appengine] New App Engine Managed VM Docs

2016-02-22 Thread Karl MacMillan


> On Feb 22, 2016, at 4:40 PM, 'Jon Parrott' via Google App Engine 
> <google-appengine@googlegroups.com> wrote:
> 
> > if you ask me, you really should just put webapp2 into maintenance only 
> > mode and suggest people move on. There are no advantages over more popular 
> > frameworks and plenty of downsides.
> 
> In general we want to align with the Python community. Whether we update our 
> docs to point to Flask over webapp2 is currently a point of discussion - but 
> I'm personally for it.

If you don’t make the change (or maybe until), can I strongly suggest you 
include some discussion that makes it clear the level of support for webapp2. 
Like I said - I went with that option on the mistaken impression that it was 
well supported by Google. That’s the _only_ thing that irritates me about this 
whole situation. I believe the docs lead me down a path without warning me of 
the true consequences. Even a basic “webapp2 is community supported framework” 
description would make it clearer.

> No matter what we do there, there should be some way for people who are 
> currently using webapp2 currently to provide patches.
> 

I’d certainly appreciate that. Despite my complaints, I’m not itching to port 
all of my code off of webapp2 because it’s working fine.

Karl

> Putting webapp2 in maintenance only mode is not currently our decision as we 
> do not own the package (it's a third-party package). If we do gain ownership 
> of it, we will likely put it into a community-supported model.
> 
> On Mon, Feb 22, 2016 at 1:32 PM Karl MacMillan <k...@strajillion.com 
> <mailto:k...@strajillion.com>> wrote:
>> On Feb 22, 2016, at 4:14 PM, 'Jon Parrott' via Google App Engine 
>> <google-appengine@googlegroups.com 
>> <mailto:google-appengine@googlegroups.com>> wrote:
>> 
>> > Is that new? Last I looked I believe NDB was not supported. If I could 
>> > suggest it would be helpful to use more specific terminology than 
>> > Datastore on that page.
>> 
>> It's not new as far as I know - ndb and db have traditionally be the way to 
>> access datastore in App Engine, so it's somewhat implied. I'll see if I 
>> can't make the docs a bit more clear there.
>> 
> 
> Hmm - maybe I was wanting ndb in a non-compat python runtime. It’s been a 
> while.
> 
>> > So - I’ll call your bluff. Tell me how to submit a patch for the issue I 
>> > pointed to and I’ll happily do so.
>> 
>> You make some excellent points. I will move webapp2 to github, take 
>> ownership of it, and I'll be happy to review and merge your patch as well as 
>> publish a new version of webapp2 to PyPI. This process takes some time, so I 
>> will update this list once that is done.
>> 
> 
> Hah - fair enough. I’ll send you that patch when you’re ready.
> 
> BUT - if you ask me, you really should just put webapp2 into maintenance only 
> mode and suggest people move on. There are no advantages over more popular 
> frameworks and plenty of downsides.
> 
> One note - last I looked much of the session handling code was completely 
> broken (https://webapp-improved.appspot.com/api/webapp2_extras/sessions.html 
> <https://webapp-improved.appspot.com/api/webapp2_extras/sessions.html>). I 
> ended up just rolling my own after my initial bug report was ignored.
> 
> Karl
> 
> 
>> 
>> On Mon, Feb 22, 2016 at 1:01 PM Karl MacMillan <k...@strajillion.com 
>> <mailto:k...@strajillion.com>> wrote:
>>> On Feb 22, 2016, at 3:44 PM, 'Jon Parrott' via Google App Engine 
>>> <google-appengine@googlegroups.com 
>>> <mailto:google-appengine@googlegroups.com>> wrote:
>>> 
>>> Are there plans to port over NDB for datastore access on managed VMs?
>>> 
>>> There is on-going discussion about NDB for Cloud Datastore here 
>>> <https://github.com/GoogleCloudPlatform/gcloud-python/issues/557#issuecomment-106952671>.
>>>  The tl;dr is that basically it's possible, it's planned, but its 
>>> contingent on the next release of the Cloud Datastore API and decoupling 
>>> NDB from the App Engine SDK.
>>> 
>> 
>> Great.
>> 
>>> That being said, you can absolutely continue use NDB in Managed VMs by 
>>> using runtime: python-compat 
>>> <https://cloud.google.com/appengine/docs/managed-vms/python/migrating-an-existing-app>.
>>>  
>>> 
>> 
>> Is that new? Last I looked I believe NDB was not supported. If I could 
>> suggest it would be helpful to use more specific terminology than Datastore 
>> on that page.
>> 
>>> Is webapp2 going to be deprec

Re: [google-appengine] New App Engine Managed VM Docs

2016-02-22 Thread Karl MacMillan


> On Feb 22, 2016, at 4:14 PM, 'Jon Parrott' via Google App Engine 
> <google-appengine@googlegroups.com> wrote:
> 
> > Is that new? Last I looked I believe NDB was not supported. If I could 
> > suggest it would be helpful to use more specific terminology than Datastore 
> > on that page.
> 
> It's not new as far as I know - ndb and db have traditionally be the way to 
> access datastore in App Engine, so it's somewhat implied. I'll see if I can't 
> make the docs a bit more clear there.
> 

Hmm - maybe I was wanting ndb in a non-compat python runtime. It’s been a while.

> > So - I’ll call your bluff. Tell me how to submit a patch for the issue I 
> > pointed to and I’ll happily do so.
> 
> You make some excellent points. I will move webapp2 to github, take ownership 
> of it, and I'll be happy to review and merge your patch as well as publish a 
> new version of webapp2 to PyPI. This process takes some time, so I will 
> update this list once that is done.
> 

Hah - fair enough. I’ll send you that patch when you’re ready.

BUT - if you ask me, you really should just put webapp2 into maintenance only 
mode and suggest people move on. There are no advantages over more popular 
frameworks and plenty of downsides.

One note - last I looked much of the session handling code was completely 
broken (https://webapp-improved.appspot.com/api/webapp2_extras/sessions.html 
<https://webapp-improved.appspot.com/api/webapp2_extras/sessions.html>). I 
ended up just rolling my own after my initial bug report was ignored.

Karl

> 
> On Mon, Feb 22, 2016 at 1:01 PM Karl MacMillan <k...@strajillion.com 
> <mailto:k...@strajillion.com>> wrote:
>> On Feb 22, 2016, at 3:44 PM, 'Jon Parrott' via Google App Engine 
>> <google-appengine@googlegroups.com 
>> <mailto:google-appengine@googlegroups.com>> wrote:
>> 
>> Are there plans to port over NDB for datastore access on managed VMs?
>> 
>> There is on-going discussion about NDB for Cloud Datastore here 
>> <https://github.com/GoogleCloudPlatform/gcloud-python/issues/557#issuecomment-106952671>.
>>  The tl;dr is that basically it's possible, it's planned, but its contingent 
>> on the next release of the Cloud Datastore API and decoupling NDB from the 
>> App Engine SDK.
>> 
> 
> Great.
> 
>> That being said, you can absolutely continue use NDB in Managed VMs by using 
>> runtime: python-compat 
>> <https://cloud.google.com/appengine/docs/managed-vms/python/migrating-an-existing-app>.
>>  
>> 
> 
> Is that new? Last I looked I believe NDB was not supported. If I could 
> suggest it would be helpful to use more specific terminology than Datastore 
> on that page.
> 
>> Is webapp2 going to be deprecated
>> 
>> There are no present plans that I'm aware of to deprecate webapp2. Because 
>> webapp2 is a WSGI-compliant web framework and is not itself tied to App 
>> Engine, you can use it in Standard, Managed VMs, and pretty much anywhere 
>> else. It'll continue to work everywhere WSGI works.
> 
> Sure - I currently use it on GCE as well just to not use two frameworks. But 
> it is abandoned as far as I can tell - there are bugs that have not been 
> addressed in years.
> 
>> It's also an open-source project and patches are always welcome.
>> 
> 
> I’m sorry, but that’s a little disingenuous. As far as I can tell there is 
> _no_ activity on webapp2. I submitted a bug report that pointed to an exact 
> line of code that needed to be changed but there was no response 
> (https://code.google.com/archive/p/webapp-improved/issues/102 
> <https://code.google.com/archive/p/webapp-improved/issues/102>). It’s not 
> clear that there is any process to submit patches (contributing on the 
> website has no information - https://webapp-improved.appspot.com/#contribute 
> <https://webapp-improved.appspot.com/#contribute>), there is no active 
> mailing list / discussion forum, the bug tracker is just an archive on google 
> code, and I can see no evidence that there is anyone other than a Google 
> employee that can commit.
> 
> So - I’ll call your bluff. Tell me how to submit a patch for the issue I 
> pointed to and I’ll happily do so.
> 
> Otherwise, please consider declaring that the project is abandoned and stop 
> pointing people to webapp2 in App Engine documentation since it’s a dead end.
> 
> Karl
> 
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Google App Engine" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/google-appengine/HazEmXZRpiw/unsubscribe 
> <https://groups.

Re: [google-appengine] New App Engine Managed VM Docs

2016-02-22 Thread Karl MacMillan

> On Feb 22, 2016, at 3:44 PM, 'Jon Parrott' via Google App Engine 
>  wrote:
> 
> Are there plans to port over NDB for datastore access on managed VMs?
> 
> There is on-going discussion about NDB for Cloud Datastore here 
> .
>  The tl;dr is that basically it's possible, it's planned, but its contingent 
> on the next release of the Cloud Datastore API and decoupling NDB from the 
> App Engine SDK.
> 

Great.

> That being said, you can absolutely continue use NDB in Managed VMs by using 
> runtime: python-compat 
> .
>  
> 

Is that new? Last I looked I believe NDB was not supported. If I could suggest 
it would be helpful to use more specific terminology than Datastore on that 
page.

> Is webapp2 going to be deprecated
> 
> There are no present plans that I'm aware of to deprecate webapp2. Because 
> webapp2 is a WSGI-compliant web framework and is not itself tied to App 
> Engine, you can use it in Standard, Managed VMs, and pretty much anywhere 
> else. It'll continue to work everywhere WSGI works.

Sure - I currently use it on GCE as well just to not use two frameworks. But it 
is abandoned as far as I can tell - there are bugs that have not been addressed 
in years.

> It's also an open-source project and patches are always welcome.
> 

I’m sorry, but that’s a little disingenuous. As far as I can tell there is _no_ 
activity on webapp2. I submitted a bug report that pointed to an exact line of 
code that needed to be changed but there was no response 
(https://code.google.com/archive/p/webapp-improved/issues/102 
). It’s not clear 
that there is any process to submit patches (contributing on the website has no 
information - https://webapp-improved.appspot.com/#contribute 
), there is no active mailing 
list / discussion forum, the bug tracker is just an archive on google code, and 
I can see no evidence that there is anyone other than a Google employee that 
can commit.

So - I’ll call your bluff. Tell me how to submit a patch for the issue I 
pointed to and I’ll happily do so.

Otherwise, please consider declaring that the project is abandoned and stop 
pointing people to webapp2 in App Engine documentation since it’s a dead end.

Karl

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/AF77E164-0058-455F-9679-87FDB89C1926%40strajillion.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] New App Engine Managed VM Docs

2016-02-22 Thread Karl MacMillan

> On Feb 22, 2016, at 1:18 PM, 'Amir Rouzrokh' via Google App Engine 
>  wrote:
> 
> Hi everyone,
> 
> I’m one of App Engine’s Product Managers and we’ve just pushed out a new 
> iteration of our App Engine Managed VM docs located at 
> 
> https://cloud.google.com/appengine/docs/managed-vms/ 
> 
> 

1. Are there plans to port over NDB for datastore access on managed VMs?
2. Is webapp2 going to be deprecated?

I ask because both of those seem to not be getting much attention with the 
Managed VM transition. It’s particularly concerning to me because I used both 
webapp2 and NDB as those were the defaults presented in the App Engine 
documentation for python (and still are). But now I see no signs of NDB moving 
to Managed VMs and you are using Flask in these examples.

FWIW - I don’t have a preference about about NDB vs. the new datastore API in 
gcloud except that I have lots of NDB code that I don’t really want to port. As 
for webapp2 - I feel really burned by that choice. I only went with it because 
I thought it would be better supported, but it is far from the best option and 
not even maintained as far as I can tell. I absolutely think you should push 
Flask or something similar and just publicly declare that you won’t be 
maintaining webapp2.

Karl

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/15C0945B-A4B5-4336-8F9E-80B6C9E61BAA%40strajillion.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Reading existing entity from DB

2016-01-28 Thread Karl MacMillan


> On Jan 28, 2016, at 7:22 AM, Louise Elmose Hedegaard  
> wrote:
> 
> Hi guys,
> 
> Thank you for your answers.
> I do not think I have explained my problem properly though when I read your 
> answers.
> 
> I have a table "order" where I save different information about an order. The 
> unique id of the order comes from an external system, and I want to save this 
> unique id for the order.
> When an order is updated in the external system, I want to update the GAE 
> datastore accordingly. 
> For this reason I first check whether the order that was updated in the 
> external system already exists in my datastore. If it already exists I update 
> it, if it does not already exist, I create the order in the datastore.
> My problem is that I use this:
> 
> datastore.prepare(query).asSingleEntity();
> 
> which fails, as there are more than one entity with the unique id.
> I do not understand how several entities can be created with the same unique 
> id, when my logic says:
> 

In order for this to work as you expect you need strong consistency, which 
typically means a) have your entities be a part of the same entity group and b) 
do the query inside of a transaction.

As others have pointed out it’s much, much easier to simply use the id as they 
key and fetch by key. Though you still need to do the logic below inside of a 
transaction.

Karl

> Entity entity = getEntity(uniqueId);
> if (entity == null){
>   createEntity();
> }else{
>   updateEntity();
> }
> 
> It is as if the getEntity check does not detect that there already is an 
> entity with the unique id.
> It does seem that this is caused by a timing/concurrency issue - the external 
> system sends two updates approximately at the same time, but shouldn't the 
> datastore be able to handle this?
> 
> My first attempt of getEntity was:
> 
> Query query = new Query(OrderDBFields.ORDER_TABLE_NAME).setFilter(new 
> Query.FilterPredicate(OrderDBFields.ID, Query.FilterOperator.EQUAL, id));
> return datastore.prepare(query).asSingleEntity();
> 
> My second (confused attempt) is:
> 
> 
> Transaction txn = datastore.beginTransaction();
> Key orderKey = KeyFactory.createKey(OrderDBFields.ORDER_TABLE_NAME, 
> id);
> Entity orderEntity = null;
> try {
> orderEntity = datastore.get(orderKey);
> } catch (EntityNotFoundException e) {
> orderEntity = null;
> }
> txn.commit();
> return orderEntity;
> 
> Any input is appreciated,
> Thanks
> -Louise
> 
> Den onsdag den 27. januar 2016 kl. 12.39.54 UTC+1 skrev Louise Elmose 
> Hedegaard:
> 
> Hi,
> 
> I have an issue with too many entities being created in my GAE datastore. 
> 
> I have an unique id on an entity (which is not the key in this case), and 
> there should thus only be one entity in the datastore per unique id.
> When an entity is updated or created by the user, I check whether the entity 
> already exists in the DB, and only create a new entity, if there is not 
> already an existing entity with a matching id. If there is an existing 
> entity, I update the parameters of the entity.
> This logic should ensure that there is only one entry/entity per unique id, 
> but somehow several entities with the same id are created in the DB - I do 
> not understand how/why!
> 
> When I look at this page 
> https://cloud.google.com/appengine/docs/java/datastore/entities#Java_Updating_an_entity
>  
> 
>  is says "You can use a transaction 
>  to test 
> whether an entity with a given key exists before creating one.".
> 
> Do I really need to use transactions to validate whether there is an existing 
> entity with a given id, or does that only apply when you use the key as 
> primary key??
> 
> Thanks,
> -Louise
> 
> -- 
> 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 https://groups.google.com/group/google-appengine 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/c774c62a-98d8-467d-b97a-c5e817644cc5%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Google App

Re: [google-appengine] Re: App Engine admin console redirects to Developers Console

2015-10-08 Thread Karl MacMillan

I’ll just jump in here with my request if you don’t mind. I use the log viewer 
both for monitoring production instances and for testing (on projects that I 
have just for that purpose). Most of my testing happens using the SDK of 
course, but there are those things that can only be tested in the real GAE 
environment.


While testing I really want something that mimics tail -f, but the current log 
viewer is pretty bad for that. The ‘play’ button seems to be for that, but it 
is very flaky in my experience (stops tailing sometimes, sometimes doesn’t get 
the latest updates). The infinite scroll also is not completely reliable - I 
often end up have to hit the refresh button to get new log entries even though 
the scrolling action says there are no newer entries. There is also some pretty 
big latency. The collapsed view is mixed here - especially for deferred tasks. 
Because I’m often just using the default deferred handler I have to open every 
entry to figure out what the actual event was.


Ultimately it all works with a few work arounds, but it can be somewhat 
frustrating.


Karl







> On Oct 8, 2015, at 10:59 AM, Deepak Tiwari  wrote:
> 
> 
> Hi Mark,I am the PM for Cloud Logging.  Thank you for the feedback on the 
> logs viewer.  We are looking at UI design options for proving the best option 
> for viewing the log lines in the collapsed format.  Your feedback is 
> valuable.  On the slowness of the logs viewing - we are actively looking at 
> this as well to fix this issue.  If you can tell me a little more about the 
> query you are running that is taking time that would be very helpful.
> Thanks,
> Deepak
> 
> On Wednesday, October 7, 2015 at 11:42:55 AM UTC-4, Mark Cummins wrote:> The 
> new logs viewer is much less usable. Because it's either totally collapsed or 
> totally expanded, it's much much harder to extract meaningful patterns of 
> events at a glance. I would really like to get back the 
> single-line-per-message view that the old viewer had.Also, it seems slower to 
> display first logs. 
>> 
>> On Wednesday, 7 October 2015 11:01:20 UTC+1, Stewart Fife wrote:> Hello!
>>> 
>>> We are pleased to announce that we redirected the first set of App Engine 
>>> admin console menus to Developers Console today. This begins the final 
>>> stage of consolidating the management of Google Cloud Platform services 
>>> into one consistent experience for customers. 
>>> 
>>> Thanks for all your feedback on this important change. 
>>> 
>>> Stewart on behalf of the GAE team
>> 
>> 
> 
> 
> 
> -- 
> 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
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/e424dcf8-28b1-48d7-bc91-b324f1119364%40googlegroups.com
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/960FF91C-2B6E-4C0F-A561-5CC1BBF2495F%40rakkoon.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Are blob keys guessable?

2015-09-28 Thread Karl MacMillan

Your question made me think that you were worried about security. I would 
suggest that the randomness provided by the ID assignment is not helpful if you 
are thinking of using these like people often use authentication tokens or 
things like shareable urls for Dropbox or Google docs. The most basic question 
in those scenarios is - if a user has one key what is the likelihood that they 
could guess another valid key, potentially for another users data? Depending on 
how you are enforcing user separation, with datastore keys the answer is 
actually it is quite likely that they could guess another valid key.


In general, you probably want to be handing out security tokens created by a 
standard process combined with HTTPS with the key. But unfortunately getting 
this kind of security right means that you have to thoroughly understand what 
security you are trying to enforce (i.e., threat modeling).


Karl







> On Sep 28, 2015, at 10:33 AM, Rob Curtis  wrote:
> 
> 
> Excellent, thanks very much.
> 
> On Mon, Sep 28, 2015 at 4:22 PM Ryan (Cloud Platform Support) 
> > wrote:
> 
>> Salutations Rob
>> 
>> "The Blobstore value is assigned a unique, randomly generated key." [1]
>> 
>> The book was written by a Googler and is a good read.
>> 
>> [1] http://ae-book.appspot.com/chapters/blobstore
>> 
>> 
>> On Sunday, September 27, 2015 at 3:23:50 PM UTC-4, Rob Curtis wrote:> Hi, I 
>> can't find any information on this in the documentation;
>>> Are blob keys guessable? 
>>> Is it safe to expose stringified blob key to a user?
>>> 
>>> Thanks
>>> Rob
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Google App Engine" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/google-appengine/B2H5YeiDqLQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-appengine/f5615b93-9c7d-4494-bf4e-17bc4e72f242%40googlegroups.com
>> .
>> 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
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/CAFk6oqCGp%2BtSSV3vYkOn8GOc%3D1yGkC_3opF2UVyyxE4dXoVmHQ%40mail.gmail.com
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/E2100131-534F-467A-A5F5-15C737DB510D%40rakkoon.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Transaction Failed Exception from a non-transactional .put()

2015-09-28 Thread Karl MacMillan

That error is about write limits on entities within the same entity group - it 
actually doesn’t have anything to do with a transaction.


The old datastore documentation has a better explanation of this: 
https://cloud.google.com/appengine/docs/python/datastore/structuring_for_strong_consistency


You can also read 
https://cloud.google.com/appengine/articles/scaling/contention?hl=en.


I don’t quite know what to say about the cron job every 5 minutes other than 
since the write limitation is per entity group it could be that writes are 
happening in other places in you app that are pushing you over the limit.


For myself - I’ve just structured my data so that almost nothing is within an 
entity group and most of the time I’m fetching by key. For those times when I 
need to query the nature of my app makes it fine for the results to be 
eventually consistent.


Karl



> On Sep 23, 2015, at 8:42 AM, Kartik Domadiya  
> wrote:
> 
> 
> We are facing the same issue thought we have non-transnational. Any ideas ? 
> 
> Here is the stacktrace:
>   File 
> "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/ext/db/__init__.py",
>  line 1077, in put
> return datastore.Put(self._entity, **kwargs)
>   File 
> "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/api/datastore.py",
>  line 605, in Put
> return PutAsync(entities, **kwargs).get_result()
>   File 
> "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/api/apiproxy_stub_map.py",
>  line 613, in get_result
> return self.__get_result_hook(self)
>   File 
> "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>  line 1881, in __put_hook
> self.check_rpc_success(rpc)
>   File 
> "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>  line 1373, in check_rpc_success
> raise _ToDatastoreError(err)
> TransactionFailedError: too much contention on these datastore entities. 
> please try again.
> 
> On Thursday, August 4, 2011 at 7:18:37 PM UTC+5:30, Joshua Smith wrote:> This 
> is a weird one.
>> 
>> I have a cron that rolls up some data every few minutes.  Nothing too 
>> complicated:
>> 
>> 
>> class CollectStatsHandler(webapp.RequestHandler):
>> 
>>   def get(self):
>>     nodes = NodeModel.gql("WHERE online = :1 and procs > :2", True, 
>> 0).fetch(1000)
>>     sum = 0
>>     for n in nodes:
>>       sum = sum + n.procs
>>     now = datetime.datetime.now().timetuple()
>> 
>>     hour = datetime.datetime(now[0], now[1], now[2], now[3])
>>     hourly = HourlyStatsModel.gql("WHERE hour = :1", hour).get()
>>     if not hourly:
>>       hourly = HourlyStatsModel()
>>       hourly.hour = hour
>>       hourly.stats = str(sum)
>>     else:
>>       hourly.stats = hourly.stats + "," + str(sum)
>>     hourly.put()    
>> 
>> 
>> 
>> I'm running on M/S, so every now and then I'll get timeouts or whatever, but 
>> that's OK because this is really just for my internal "app health" dashboard.
>> 
>> 
>> Anyway, yesterday I got this exception:
>> 
>> 
>> google.appengine.api.datastore_errors.TransactionFailedError@/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py:1074
>>  (at least 2 occurrences)
>> 
>> 
>> 
>> 
>> 
>> 
>> Handler:
>> main.py
>> 
>> URL:
>> http://mesonstreaming.appspot.com/admin/collectStats
>> 
>> 
>> 
>> Stacktrace:
>> Traceback (most recent call last):
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py",
>>  line 700, in __call__
>> handler.get(*groups)
>>   File "/base/data/home/apps/mesonstreaming/51.352130110004909428/main.py", 
>> line 1677, in get
>> hourly.put()
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py",
>>  line 1006, in put
>> return datastore.Put(self._entity, config=config)
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py",
>>  line 467, in Put
>> return PutAsync(entities, **kwargs).get_result()
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>>  line 658, in get_result
>> results = self.__rpcs[0].get_result()
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py",
>>  line 592, in get_result
>> return self.__get_result_hook(self)
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>>  line 1385, in __put_hook
>> self.check_rpc_success(rpc)
>>   File 
>> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>>  line 1074, in check_rpc_success
>> raise _ToDatastoreError(err)
>> TransactionFailedError: too much contention on these datastore entities. 
>> please try again.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

Re: [google-appengine] At what point is querying down a hierarchical tree faster than querying through all the end nodes?

2015-08-17 Thread Karl MacMillan

On Sunday, August 16, 2015, Sanket More sanketm...@gmail.com wrote:

Hey Nick!

After I submitted my question, I went through lots of information sources
and gathered some information.
I feel like my question was based on many misconceptions about google app
engine's datastore.

I think I have a strategy for the restaurant problem.
The user will provide me with country, state, city and the restaurant
name, And I will provide the user with location(s).

So all I really need is one specific entity and the response will simply
be the information in that entity.
And, I don't really need to index country, state, city, and restaurant
name with each other independently. I just need one string that holds the
country state city and restaurant.
In fact, I think that string is unique.
So, I am thinking about having a restaurant kind with key string
country_state_city_restaurant

Once the user has finished submitting the form, I can get by
country_state_city_restaurant and return some information to the user.

I wanted a smarter solution than this, because I feel that this solution
won't scale well.
Furthermore, if I am flattening my tree structure like this, wouldn't gql
be faster?

On Sunday, August 16, 2015 at 4:14:33 PM UTC-7, Nick wrote:

The general rule is optimize for your primary use case, denormalise to
support others.
In addition, enforce and support constraints In your code.

If your primary case is restaurant search, embed and index all necessary
data. This will be the fastest solution and easiest to work with

On Appengine extra data doesn't cost you unless it's indexed. There is a
careful balance between optimising for speed, cost and transactional
integrity. My advice is if this is your first go, expect to make mistakes
and to need to reengineer your data a couple of times. Make that process as
easy as possible.

Just a suggestion - have you thought about letting the user query through
the Google maps or similar API to find the restaurants and then based on
those results returning information from your app? These location based
queries are hard - both technically and from matching the users
expectations. Especially as I'm betting that the city that a user thinks a
restaurant is located in often differs from official addresses, especially
in large cities.

This strategy could let you both control the user experience and leverage
the hard work of others.

Karl

--
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
javascript:_e(%7B%7D,'cvml','google-appengine%2bunsubscr...@googlegroups.com');
.
To post to this group, send email to google-appengine@googlegroups.com
javascript:_e(%7B%7D,'cvml','google-appengine@googlegroups.com');.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/04705cc7-3673-4d82-984a-61c64b099fe8%40googlegroups.com
https://groups.google.com/d/msgid/google-appengine/04705cc7-3673-4d82-984a-61c64b099fe8%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Upcoming changes to App Engine support in the Google Cloud SDK

2015-07-08 Thread Karl MacMillan

  Hey Andrew - a few questions.



 On Jul 8, 2015, at 3:16 AM, 'Andrew Jessup' via Google App Engine 
 google-appengine@googlegroups.com wrote:
 
 
 Hi folks,
 
 
 We're making an important change to the Google Cloud SDK to simplify how App 
 Engine developers can access and work with the SDK.
 
 
 As of the next release, 0.9.68, of the Google Cloud SDK - we will no longer 
 be distributing the stand alone App Engine SDKs. 
 
 
 
 

Can you give us a timeframe for this release? Many of us probably have some 
automation around these tools (I certainly do) and it would be nice to be able 
to plan when we need to make the changes. Especially as this kind of work 
provides no benefit for me or my users, so it’s not a high priority.


Also - I just had some interaction with the support team over the urlfetch bug 
and they were discussing which of the next two GAE SDK releases the bug might 
be fixed in. Does that mean that there are going to be at least two more 
releases of the stand-alone SDK? Or does this announcement change that?


Basically - I don’t quite understand how the release schedule of what (to me) 
are two different SDKs interact. Heck - I’m not even quite clear on how these 
two SDKs are intended to interact at all (more on that below).


 The gcloud preview app deploy and gcloud preview app run commands that most 
 developers use within gcloud will continue to work, users should not notice 
 any obvious change.
 
 
 
 

You say that most users use the gcloud commands, but I find that very hard to 
believe. All of your docs point to the old tools (e.g., 
https://cloud.google.com/appengine/docs/python/gettingstartedpython27/uploading 
and https://cloud.google.com/appengine/docs/java/tools/uploadinganapp). Also 
your gcloud docs explicitly state that these tools are beta and not covered by 
“any SLA or deprecation policy and may be subject to backward-incompatible 
changes” (https://cloud.google.com/sdk/gcloud-app).


Call me a fuddy-duddy, but I tend to stick to what you guys document as the 
correct way and avoid things that are in beta and you tell me are not yet 
supported. Needless to say I’m surprised and annoyed for this casual message 
from you to change all of that without any change to the public documentation.


Also, will these continue to be under the preview command (which I understood 
to mean were not yet stable)? If these are going to be the only supported means 
of interacting with GAE it seems surprising that they are going to be in 
preview still. If they are going to change it would be nice to have one release 
where the commands are not in preview but the standalone tools are still 
supported to ease our migration and just in case there are bugs / breaking 
changes. Otherwise there is no period where I can migrate my automation _and_ 
use tools that are officially supported.


 For users who were directly using appcfg.py, appcfg.sh, dev_appserver.py or 
 dev_appserver.sh scripts, or the GUI launchers that were bundled with the 
 Google Cloud SDK, you have two options:
 
 
 You can continue to use the latest versions of these tools used by installing 
 them from the stand-alone App Engine SDKs that can be found here: 
 https://cloud.google.com/appengine/downloads
 .
 
 
 
 

Just to make certain that I understand - are you saying that we can use the 
existing releases and there will be no more releases? Your wording is a little 
confusing to me.


 In the short term, if you need to prevent this from happening, you can pin a 
 version of gcloud SDK with the following commands:
 
 
   gcloud config set --scope=installation component_manager/fixed_sdk_version 
 0.9.67 
   gcloud components update
 
 
 
 

And what happens if I have the standalone SDK installed and don’t do this? Are 
the standalone tools deleted? Again - I’m a little vague about the relationship 
between these. When I first started I installed the standalone App Engine SDK 
but, when I needed google compute, I installed gcloud. Since then I’ve 
installed updates through gcloud, the GUI Google Updater, and manually when I 
had to downgrade because of bugs.


So does gcloud manage the existing App Engine SDK or not? How can I tell for 
other members of my team?


 As part of this change, the gae-java, gae-python, gae-php, and gae-go 
 components no longer exist in the component manager.  The `gcloud preview app 
 run` command will install language specific runtime libraries on demand, as 
 needed by your application.
 
 
 If you have questions or concerns, please let us know.
 
 
 
 

I’d like to go ahead and ask that you reconsider this plan. It does not seem 
well thought out. I’d expect that you at least provide a solid description of 
time frames and deprecation schedule.


Karl


 Thanks,
 
 
 Andrew, on behalf of the Cloud SDK team
 Andrew Jessup | Product Manager, Google Cloud Platform | jes...@google.com
  
 
 
 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Google

Re: [google-appengine] Upcoming changes to App Engine support in the Google Cloud SDK

2015-07-08 Thread Karl MacMillan

The gcloud preview app deploy and gcloud preview app run commands that most
developers use within gcloud will continue to work, users should not notice
any obvious change.

You say that most users use the gcloud commands, but I find that very hard
to believe. All of your docs point to the old tools (e.g.,
https://cloud.google.com/appengine/docs/python/gettingstartedpython27/uploading

and https://cloud.google.com/appengine/docs/java/tools/uploadinganapp

). Also your gcloud docs explicitly state that these tools are beta and not
covered by “any SLA or deprecation policy and may be subject to
backward-incompatible changes” (https://cloud.google.com/sdk/gcloud-app

Ah, there might be some confusion here. I was referring to the fact that most
users of the Google Cloud SDK
to interact with GAE are using gcloud app run/deploy rather than the
appcfg.py/dev_appserver.py commands.

However, you're quite right - most users of App Engine right now are not yet
using the Google Cloud SDK at all, but are using the stand-alone App Engine
SDKs
and are using the appcfg.py/.sh and dev_appserver.py/.sh commands from there.
Fortunately these folks aren't affected by this announcement, this only
applies to those using appcfg.py/.sh and dev_appserver.py/.sh from the Google
Cloud SDK.

Using the stand-alone App Engine SDKs, and the tools therein, is still the
recommended path for interacting with App Engine for anyone not using Managed
VMs.

Ok - this seems to be the core of the confusion then and the handling of this
changes makes a lot more sense to me. Two more questions then:

1. Will everything eventually be moved into gcloud or will gcloud only be the
recommended solution for managed VMs? In other words, will the stand-alone SDK
eventually be replaced by the Google Cloud SDK?

2. I assume that having both SDKs installed will work fine for those that need
a mix of managed VMs and pure App Engine?

Thanks - Karl

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

2015-07-07 Thread Karl MacMillan

I got a confirmation this morning from support of this issue and a suggestion
that it will be fixed in a subsequent release.

Can I just ask some Googlers - how on earth did this issue slip by? This is the
second serious SDK issue I’ve seen in recent months that would have been caught
by the most obvious test in the world (the other was cloud storage being
largely broken in the SDK).

I don’t want to hammer too much, but seriously, do you not have tests at all
for parts of the SDK? This is not a corner case - this is the most basic
functionality being broken. I find it very, very concerning that your QA
procedures are not catching such obvious bugs.

Karl

On Jul 7, 2015, at 2:12 PM, Aaron Madison aaron.madi...@imtapps.com wrote:

Looks like a bug was filed yesterday. I'll update the SO post to reference
this bug so hopefully more people can star it.

https://code.google.com/p/googleappengine/issues/detail?id=12123

On Monday, July 6, 2015 at 9:24:54 PM UTC-5, Karl MacMillan wrote: I’ve seen
this as well and submitted a support ticket. I did not find the debugging
hilarious, but it’s nice to see someone else handle things with better humor
than me.

Karl

On Jul 6, 2015, at 10:09 PM, Josh Whelchel (Loudr) jo...@loudr.fm
wrote:

There is an active issue with urlfetch_stub.py in the SDK where the FULL
URL is being sent to the HTTP server as the path.

Question and patch posted
here:http://stackoverflow.com/questions/31195459/appengine-dev-appserver-urllib2-urlopen-issue-with-localhost-url

Basically, it's connecting like this:

Oh hey, http://localhost
, we're connected, HI!
Now that we're connected, can you give me URI http://localhost

Wait what, that's not right?? ooh.

We found this while working on our elasticsearch integration, which was
hilarious to debug.
Imagine trying to find out why you have a new index named http:

.
To post to this group, send email to google-a...@googlegroups.com

.
Visit this group at http://groups.google.com/group/google-appengine

.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/74688f8c-27f1-42fa-a706-ee83dc5de299%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

2015-07-07 Thread Karl MacMillan

On Jul 7, 2015, at 4:18 PM, Josh Whelchel (Loudr) j...@loudr.fm wrote:

This issue was so hard to find, and related to the outgoing request, I
believe a test-case would have been hard-pressed to find it.

Why? All outgoing http requests are broken as far as I can tell.

That said, the bug is on the stub implementation of the urlfetch API - I'd
expect some request header tests as well.

*shrug*

can't catch 'em all

And I wouldn’t be complaining if this was the first, but it’s not.

Karl

On Tuesday, July 7, 2015 at 12:56:24 PM UTC-7, Karl MacMillan wrote: I got a
confirmation this morning from support of this issue and a suggestion that it
will be fixed in a subsequent release.

Can I just ask some Googlers - how on earth did this issue slip by? This is
the second serious SDK issue I’ve seen in recent months that would have been
caught by the most obvious test in the world (the other was cloud storage
being largely broken in the SDK).

Karl

On Jul 7, 2015, at 2:12 PM, Aaron Madison aaron@imtapps.com
wrote:

Looks like a bug was filed yesterday. I'll update the SO post to reference
this bug so hopefully more people can star it.

https://code.google.com/p/googleappengine/issues/detail?id=12123

On Monday, July 6, 2015 at 9:24:54 PM UTC-5, Karl MacMillan wrote: I’ve
seen this as well and submitted a support ticket. I did not find the
debugging hilarious, but it’s nice to see someone else handle things with
better humor than me.

Karl

On Jul 6, 2015, at 10:09 PM, Josh Whelchel (Loudr) jo...@loudr.fm
wrote:

There is an active issue with urlfetch_stub.py in the SDK where the FULL
URL is being sent to the HTTP server as the path.

Question and patch posted
here:http://stackoverflow.com/questions/31195459/appengine-dev-appserver-urllib2-urlopen-issue-with-localhost-url

Basically, it's connecting like this:

Oh hey, http://localhost
, we're connected, HI!
Now that we're connected, can you give me URI http://localhost

Wait what, that's not right?? ooh.

We found this while working on our elasticsearch integration, which was
hilarious to debug.
Imagine trying to find out why you have a new index named http:

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

2015-07-06 Thread Karl MacMillan

I’ve seen this as well and submitted a support ticket. I did not find the
debugging hilarious, but it’s nice to see someone else handle things with
better humor than me.

Karl

On Jul 6, 2015, at 10:09 PM, Josh Whelchel (Loudr) j...@loudr.fm wrote:

There is an active issue with urlfetch_stub.py in the SDK where the FULL URL
is being sent to the HTTP server as the path.

Question and patch posted
here:http://stackoverflow.com/questions/31195459/appengine-dev-appserver-urllib2-urlopen-issue-with-localhost-url

Basically, it's connecting like this:

Oh hey, http://localhost, we're connected, HI!
Now that we're connected, can you give me URI http://localhost;
Wait what, that's not right?? ooh.

We found this while working on our elasticsearch integration, which was
hilarious to debug.
Imagine trying to find out why you have a new index named http:

Re: [google-appengine] Confuse about which is better solution to pagination using datastore on Python App Engine

2015-07-06 Thread Karl MacMillan

On Jul 6, 2015, at 4:22 AM, Zeck Li hatemegal...@gmail.com wrote:

Here comes my question. What is the advantages of using cursor ?
Both two solutions all need to execute MyModel.gql(...)to get all data, and
the first solution still need to execute with_cursor(...)to retrieve items.
It makes me so confused.

In the most basic terms, when you use a cursor the query can start from where
it left off. With your other solution it will have to execute a new query,
start the beginning of the results, and seek until it gets to the starting
point for that page. If you are deep into a result set that seeking can waste
quite a bit of time.

Karl

If you have better solutions or any suggestions for improving my solution,
please share with me !!

Re: [google-appengine] Building an Android Application with Google App Engine

2015-05-30 Thread Karl MacMillan

On May 30, 2015, at 10:57 AM, Joe Seph joseph.a...@gmail.com wrote:

Hello guys,

so currently, we are building a mobile social network application where
users will be able to upload and view Pictures and Musics files.
we have 2 scenarios in order to implement the GAE with our android
application and backend control panel.
- First scenario is to implement the GAE PHP with our application backend and
let the backend handle all the APIS requests from the mobile side and handle
them with the GAE but for in case i need to upload a certain image to the GAE
I will need to encode the image to base64 and decode it on the server and
then upload it into the GAE and then wait until the upload process finishes
and return the Reference to the backend then update the status on the mobile
side

I’m a little confused about what you mean by GAE and how that might be
different from the PHP backend. I’m getting a sense that you mean something
specific here but are using the terms in a different way than is usually used,
which is making it hard to answer your question.

I also wonder if you are making this harder than it needs to be. A typical
approach that people use for uploading data is to simply expose a HTTP endpoint
that the mobile application can POST to with the image data (perhaps as
multipart form data) and then if they need to return some sort of handle or
metadata they simply do that in the response. It’s only one round-trip then.

If you are running PHP on Google App Engine, the handler for that HTTP endpoint
can then put the data wherever. I would suggest storing it in Google Cloud
Storage and, if helpful, storing some meta-data about the data in the Datastore.

as you can notice this scenario will cost me a lot of time and the quality
of the image will be dropped due to encoding and decoding .

I’m a little confused about the concern over image quality. Base64 encoding
does not impact image quality - it is simply an encoding of binary data and is
lossless (http://en.wikipedia.org/wiki/Base64).

I hope this helps - again, it’s a little hard to understand your question or
concerns. If I could suggest, it might help if you spend a little more time
with the App Engine documentation. That might help you answer your own
questions and it will likely help you ask questions using the terminology from
the documentation, making it easier for others to help you.

Karl

Re: [google-appengine] Hash function

2015-05-27 Thread Karl MacMillan

On May 27, 2015, at 10:50 AM, Saturnino Mateus s.natanie...@gmail.com wrote:

Hello! I need to create a page to tracking orders, each order must have a
key. How can i generate this key? Im thinking use hash, is there any good
hash function without colision? Is there other way to solve it with GAE?

This isn’t exactly GAE specific, but you probably want a UUID:

https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html

https://docs.python.org/2/library/uuid.html

Karl

Regards

Re: [google-appengine] Including my own file as part of a golang GAE deployment

2015-05-15 Thread Karl MacMillan

Can I suggest that it is not really safer to store the encrypted data on the
server if the key is there as well. If your main concern is not storing the
sensitive information in the source code repository you might as well make the
decryption part of the build or a custom deployment script.

Karl

On May 15, 2015, at 2:07 PM, Mobile Web Dev mmarge...@arspremier.com wrote:

Hello, I want to include a binary file the contains come sensitive AES
encrypted info that I do not want included in the go source. The go server
will read it and decrypt it.

How Can I deploy this app and what would the file spec look like to read it
in my go server app? I would assume something ./myfile.dat

Thanks!

Re: [google-appengine] Re: Google Cloud Platform wants to hear from you

2015-04-21 Thread Karl MacMillan

  

 On Apr 21, 2015, at 12:17 PM, Dan Ciruli cir...@google.com wrote:
 
 
 Hi, Karl -
 
 I'm Dan Ciruli, and I recently took over as Product Manager on Endpoints. I 
 really appreciate your feedback. My team is currently looking at improvements 
 that we’d like to make in the next version of Endpoints and your comments 
 jibe with what I’ve been hearing from a lot of our users. We are working on 
 both the developer experience as well as providing some features that help 
 you with managing your API (controlling access, etc).
 
 
 
 

You know - one thing that I would suggest is separating the serialization 
features from the overall endpoints functionality. My hand-rolled solution has 
to dig around in the guts of the ndb.Models (using ndb.Model._properties) and 
I’m afraid you guys will break that since it’s not a publicly documented API.


What I would find useful is an API that gives you the ability to:


1. Introspect ndb.Models (and the equivalent for other runtimes) to find just 
the datastore properties.
2. Convert the property datatypes into JSON / Protobufs / whatever
3. Helpers to selectively serialize entities and entity graphs

4. Callbacks / transforms during serialization to handle API and data model 
changes, friendly name changes, and things like automatically fetching keys 
(which I do).


With that I could easily turn an entity or entity graph into a serialized 
format that I care about. I could then more easily build out my REST APIs using 
whatever I wanted. You could, of course, build the rest of Cloud Enpoints on 
that (and probably already have all of this functionality in the internals), 
but for those of us that don’t find Endpoints to be a great fit this 
functionality would really make life easier.


Some other notes about Endpoints:


1. Discovery is just not that interesting to me for APIs that are completely 
internal (i.e., only accessed by code that I control) and it comes with 
additional complication and a pretty significant startup delay for the default 
clients (from what I remember). Yeah, yeah, I know all of the REST purist 
arguments about discovery, but it just isn’t worth it a lot of times for me and 
I’m guessing others as well. Think about being able to just decorate a single 
URL handler so that it handles serialization / de-serialization, auth, etc. 
without having to muck around with discovery and the client libraries (I would 
in a lot of cases just use a standard HTTP API to call the APIs).


2. It would have helped immensely to document how the URLs would be mapped. I 
had some trouble getting things running initially (can’t quite remember what 
the problem was) and I was trying to just use curl or something to figure out 
where the problem was. But I had to figure out what all of the actual URLs 
were. I remember having trouble even figuring out what the discovery url was, 
but that seems to be a little better documented now 
(https://cloud.google.com/appengine/docs/python/endpoints/access_from_python).


3. Authorization - it would be nice if this wasn’t endpoints specific but fit 
in with the rest of GAE (like the minimal authorizations that are available now 
in app.yaml). And having a fully functional users API would make it much better 
by having a standardized identity (presumably with roles) that you could use in 
authorization statements.


4. Like I mentioned before, having separate types for requests and responses is 
a basic requirement for me.


 I would be interested in a follow-up conversation with you -- send me an 
 email (my last name @google.com) and I’d like to set something up.
 
 
 
 

Great - I’ll drop you an email.


Karl


 Thanks -
 
 
 Dan
 On Monday, April 20, 2015 at 7:38:45 PM UTC-7, Alistair Burrowes wrote: Hi,
 
 I would echo a lot of what Karl said.
 
 
 I would like to see more examples of complex usage of GAE and or managed 
 VMs. These are the kind of usages that more advanced developers might want. 
 Here are a few examples of things that I have figured out or want:
 
 
 - CI/CD set up, with dev/staging environments and one button deployments to 
 production. It was a pretty long process of trial and error to achieve this.
 
 
 - a single page app with separate the web front end and the backend 
 (endpoints) modules. This was also tricky since endpoints live behind /_ah 
 which can't be routed away from the default application. I think separating 
 these out and their build processes is healthy separation of concerns.
 
 
 - integrating gulp build processes into GAE dev servers/build processes. In 
 my case I'm using gradle app engine plugin.
 
 
 - ismorphic javascript app, with server side rendering via something like 
 react (I assume this would be a managed VM running node js) that speaks to 
 endpoints, from both client side and the node js layer.
 
 
 Also I agree that more transparency on the roadmap/discussions on direction 
 would be really useful.
 
 
 For example the lack of java 8 on GAE is a concern of

Re: [google-appengine] Google Cloud Platform wants to hear from you

2015-04-20 Thread Karl MacMillan

Katie,

I feel compelled to point out that how this discussion going is a good example
of some of the things that I - and it seems others - are frustrated about.
You’ve asked for and received concrete feedback. Yet we’ve received no answers
or discussion back from Google engineers. At least a simple acknowledgement of
the _specific_ issues we’ve raised from someone with some knowledge would be
helpful. Otherwise how am I to know that you bringing the “feedback to the
appropriate team members” is anything more than them receiving an email that
they’ll simply delete?

Look at this way - we’ve invested and in many cases bet our businesses on GCP.
And especially with App Engine, this is very much an investment in an ecosystem
that you’ve created that’s largely separate from the rest of the industry. It’s
hard to have confidence in that bet given the almost total lack of public
engagement from Google to help make this a vibrant ecosystem.

Karl

On Apr 16, 2015, at 5:50 PM, Katie Ball (Google Cloud Support)
kmrichard...@google.com wrote:

Hi Karl,

You've taken some extra time and extra care to put this feedback together --
thank you! It's incredibly helpful; this is exactly what we need in order to
better serve our users and the cloud computing community.

I've already taken your feedback to the appropriate team members to start
improving things as suggested in your post.

Is there anything that you are currently struggling with? If there is, we'd
like to offer our help as a thank you.

To our GCP community members: do you have any additional feedback you'd like
to send our way? Any +1's to Karl's points? We'd love to hear from you!

Thanks again,
Katie

Re: [google-appengine] Python 2 End of Life 2020

2015-04-20 Thread Karl MacMillan

On Apr 20, 2015, at 3:51 AM, troberti tij...@firigames.com wrote:

Exactly. Managed VMs are great for some applications, but not a replacement
for the managed runtimes. The idea of App Engine is simplicity
zero-configuration (or at least as close to it as possible). Instead, Managed
VMs seem to throw a lot of that back on the user's lap. I don't want to
'dockerize' my apps and start managing my own runtimes.

I completely agree. I’ve seen many comments suggesting that managed VMs are a
viable alternative to traditional GAE, but this is not the case at all for me.
The docker tooling on OS X (my dev environment) is pretty awful, the same set
of services aren’t available in App Engine and Managed VMs, and basically I
want the zero config of App Engine.

This isn’t a lack of knowledge - I have a lot of experience managing servers -
it’s that I’ve got other more important things to do with my time.

The Python 2 to 3 transitions is great example where a public roadmap would
be very useful. They could state they'll have a Python 3 runtime ready in
2017 and then have a 3 year transition period and stop the Python 2 runtime
in 2020.

Karl

On Saturday, April 18, 2015 at 1:18:48 PM UTC+2, Jay Kyburz wrote: A port to
a managed VM is a whole nother kettle of fish. If I do that I'm managing my
own servers and might as well move anywhere.

The simple fact is that 2.7 is on the way out, and if I want to continue to
work in Python, I need a 5 year plan that has me port my applications to
Python 3.

My question to Google is, will I be working on App Engine, or do I have to
go find another solution.

On Saturday, 18 April 2015 19:19:54 UTC+10, Jeff Schnitzer wrote: You can
run Python3 already with Managed VMs, although the experience today does not
compare favorably to traditional GAE. I suspect the best course of action is
to file usability bugs against managed VMs until they work as well or better
than what you're used to. More specific is better.

Jeff

On Thu, Apr 16, 2015 at 9:19 PM, Jay Kyburz j...@jaykyburz.com
wrote:
Hello Googlers,

There is an interesting discussion today on Hacker News about how Debian
has started moving from P2 to P3 because of the looming EOL deadline in
2020.
https://news.ycombinator.com/item?id=9388502

Does anybody know if there are plans in the works to provide a Python 3
implementation of App Engine I can port my apps to sometime in the next 5
years. I've been searching around but can find nothing.

5 years may sound like a long time to many of you, but the last 5 years of
using App Engine have seemed to fly by for me.

I have a lot of code to port and it might be a biggish job.

If Google is looking for more staff to handle the port I would be happy to
contribute.

Jay.

.
To post to this group, send email to google-a...@googlegroups.com
.
Visit this group at http://groups.google.com/group/google-appengine

.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/a336be6a-f0e3-487f-aa4c-36dd8c1117c5%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout

Re: [google-appengine] Google Cloud Platform wants to hear from you

2015-04-15 Thread Karl MacMillan

  
  Katie,


Thanks for asking the question.


I’ve been using GCP for about 6 months now. I found the tutorial material and 
reference documentation to range from pretty good to good enough - there are a 
few rough points, but nothing that really bothered me. So I didn’t get stuck 
much in the early days.


Some things that could be smoother (this is all python):


1. Default way to handle 3rd party dependencies in an app - there are options 
and they work ok, but this is so common it would be nice to have an officially 
supported method. Especially since the common ones break on managed VMs because 
you don’t support appengine_config.py there.


2. Webapp2 - it’s OK, but definitely not great. From the outside there doesn’t 
seem to be a strong reason to be using something that has not gained broader 
traction when supporting something like Flask shouldn’t be hard. That would 
gain a much broader ecosystem rather than the very narrow, App Engine focused 
ecosystem around webapp2.


3. Cloud Storage - I could not find a quick and nice way to securely expose 
native links from cloud storage to clients via a REST API without having to 
have the clients reauth to cloud storage. So I’m just pulling from cloud 
storage on the backend, doing my own authorization, and serving them via my own 
REST API. A hack that I’ll get rid of eventually, but I didn’t want to fiddle 
anymore. This seems like a common use case to me, but who knows.


4. Cloud Endpoints - the biggest problem I had in early days was cloud 
endpoints. I have what I feel is a really common use case - I just need to do 
some CRUD operations on datastore entities using a REST API. I looked at 
enpoints and it looked like exactly what I needed. But then I saw I needed to 
largely duplicate my data model in NDB and Cloud Endpoints. Except there is 
this open source library that claims to connect them together 
(http://endpoints-proto-datastore.appspot.com), but it’s quirky, has quirky 
docs, and is kinda, sorta supported by Google. And then what’s with the 
assumption that these APIs will accept and return the same data types 
(seriously - who does that by default)? And then there was the tooling to 
generate client libraries that’s - honestly - just not great. Eventually the 
CORBA flashbacks got bad enough that I just completely abandoned cloud 
endpoints in favor of rolling it myself. For me, cloud endpoints definitely 
created _way_ more problems than it solved.



5. User service - when evaluating options things like the User services popped 
out to me. I thought, great, I’ll use a PaaS and things like user auth will be 
sanely handled. Except that it is so limited as to not be viable at all for a 
public product.


Beyond the beginner issues, I think there is a real problem once you move 
towards creating real apps. There is a need for more in-depth documentation of 
designing apps effectively to use the platform. Things like best practices 
around data modeling in the datastore (e.g., when to de-normalize and how to 
handle data updates once you do). There is some of this (e.g., 
https://cloud.google.com/appengine/articles/modeling), but it is typically 
out-of-date and there is not really enough of it. For better or worse, there is 
not a big network of bloggers handling these topics like there are for open 
source tools like rails, postgresq, etc.


The biggest beginner problem I see right now is the architectural options 
around App Engine, Managed VMs, and GCE. On paper you guys have a nice blend of 
offerings that can allow developers to choose the right amount of control that 
they want / need. The reality, though, is that there are some hard choices to 
be made because of inconsistencies around what services are available on the 
different options and how to effectively wire together the components. A 
concrete example for me: I need to use numpy and some other non-pure python 
code in some background processing, so I needed to move off of App Engine for 
that work. I wasted quite a bit of time figuring out how / whether I could use 
the Datastore (via ndb) and task queues on the different options (including 
auth, network architecture, and scaling). None of it is rocket science, but I 
felt like I was inventing things when I knew that others had already come up 
with effective strategies. For me - the ideal situation would be if you just 
supported the same services through the same APIs everywhere, so I hope that is 
where you were headed.


Other random thoughts / complaints:


1. GCP Roadmap - it would be nice to have some nice, clear roadmap on where 
things are headed. Right now, I restrict myself to only what is available and 
supported right now because I have no idea where you guys are headed.


2. Community - there is not a supportive / coherent community around GCP. 
Coming from a largely open source background this gives me a lot of culture 
shock. It would be great if there was at least a set of your engineers out 
engaging

Re: [google-appengine] Re: Is there a possible way to have two datastores for the same application?

Re: [google-appengine] An update on webapp2

Re: [google-appengine] An update on webapp2

Re: [google-appengine] New App Engine Managed VM Docs

Re: [google-appengine] New App Engine Managed VM Docs

Re: [google-appengine] New App Engine Managed VM Docs

Re: [google-appengine] New App Engine Managed VM Docs

Re: [google-appengine] New App Engine Managed VM Docs

Re: [google-appengine] Re: Reading existing entity from DB

Re: [google-appengine] Re: App Engine admin console redirects to Developers Console

Re: [google-appengine] Re: Are blob keys guessable?

Re: [google-appengine] Re: Transaction Failed Exception from a non-transactional .put()

Re: [google-appengine] At what point is querying down a hierarchical tree faster than querying through all the end nodes?

Re: [google-appengine] Upcoming changes to App Engine support in the Google Cloud SDK

Re: [google-appengine] Upcoming changes to App Engine support in the Google Cloud SDK

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]

Re: [google-appengine] Confuse about which is better solution to pagination using datastore on Python App Engine

Re: [google-appengine] Building an Android Application with Google App Engine

Re: [google-appengine] Hash function

Re: [google-appengine] Including my own file as part of a golang GAE deployment

Re: [google-appengine] Re: Google Cloud Platform wants to hear from you

Re: [google-appengine] Google Cloud Platform wants to hear from you

Re: [google-appengine] Python 2 End of Life 2020

Re: [google-appengine] Google Cloud Platform wants to hear from you

26 matches

Site Navigation

Mail list logo

Footer information