This question is related to an issue when running a Python 2 and Python 3 version of an application with split traffic that uses the Task Queue.
Looking at the taskqueue.py module, I've gathered that the target for the Task is set to the DEFAULT_APP_VERSION, however I do not know how this is determined when two versions of the app are considered the default version.
As of the moment, there is no option to determine or select the default version of a service when traffic is split. The only thing I could observe is when traffic is 100% allocated on one version, that would be considered as a default version, since I am unable to delete it.
Before there was an option to just select the default version when you create multiples of it but it was no longer available. Link for the document here.
When I migrate all traffic to another version, it would change to [project-id].[region].r.appspot.com. I would consider this to be the default version as no other versions are being used and no traffic is being split.
You can check out the definition of target wherein:
Push tasks only; specifies the alternate version or backend on which to run this task, or DEFAULT_APP_VERSION to run on the application's default version. You can specify a module or version, a frontend version, or a backend on which to run this task. The string that you specify will be prepended to the domain name of your app. If you specify the target argument, do not specify a Host header in the dictionary for the headers argument.
Link for the taskqueue documentation through this link.
If selecting the default version is badly needed for your project, I would suggest filing for feature request. This is not a guarantee that it would be available in the future but it's worth a shot.
Related
A recent question in the Codename One discussion forum raised a question I often face when I'm waiting for a fix.
Sometimes the Codename One team indicates a fix would be coming in a couple of weeks and other times they indicate that its already fixed. Some of that opacity obviously relates to the update of the cloud servers but its unclear for me whether its just the cloud server & the plugin or is there something that I'm missing. Why isn't there a single update process?
I'd really like a more definitive answer like How does Codename One work?
for this.
Codename One is comprised of several different pieces and an update usually means we update only one of them. At a high level there are really just 2 major types of updates: libraries & servers.
We update libraries once every 3-5 weeks we update servers all the time (sometimes more than once per day sometimes ever 3-4 days).
Here is a slightly more accurate overview of what it means to update Codename One:
Plugin & related tools - the plugin itself provides the project properties, server connectivity and designer/gui builder tools. It updates as part of the native IDE update process once every 3-5 weeks. You need to explicitly accept an update prompt from the IDE in order to get this update. Bugs in the plugin itself or features for the designer/GUI builder need to go thru that process...
Build.xml - this is technically a part of the plugin update but you need to actually accept changes that we make to the build.xml to get some functionality. On occasion a new feature (e.g. the new GUI builder) needs to update the build.xml code but this will only happen if you go into project properties, click OK and accept the prompt to update the build.xml (if such an update exists).
Client libraries - these are the API's you use when writing Codename One code (typically CodenameOne.jar and related ports). We usually issue an update to those once every 3-5 weeks together with the plugin update. The plugin ships with these but they are only applied to new projects... When you send a build we implicitly update your libraries to the latest version using a separate update process, you can also use "Update Client Libs" within the Codename One preference to update these manually without sending a build.
Device libraries - when you send a build to the servers we use the latest version of the client libraries that might be newer than what you see in the client libs but might not be the latest git master. This allows us to rapidly deploy & test device fixes. This also allows you to work with the code and use newer features that weren't pushed to the Client Libraries. The process of updating the servers is a bit adhoc so there is some opacity around that, we are looking at making this more transparent.
VM & builders - The builder code and VM relate to the server side scripts that generate the code. When you have a compilation error on the servers or need an enhancement there we need to deploy it in a process similar to the device libraries deployment.
Certificate wizard update - this tool is updated in a completely separate update process despite shipping in the plugin. We had a lot of concerns about Apple changing things suddenly when initially creating this so we decided to allow this to update instantly.
I am working on Adobe CQ. I created 2-3 versions(1.2,1.2,1.3) for a particular page in my author instance. Now I tried to package my content page and installed it in another instance. I couldn't see the versions of the page which I installed in another instance.
Can anyone help me out doing this?? I want to migrate my content pages along with their versions from one CQ instance to another??
We are in the same situation. You can extract prior version details using the packaging approach, but you will be precluded from reloading them in due to the new Oak security model. The next issue is that you would need to extract and transform the data, and then reinsert due to the node ID's potentially differing, especially if you are using partial data sets to extract.
Where we have gotten to, and are proving now, is to use the new migration tool to move content from instance to instance, which purportedly has a version extract tool. I will update details here when we get our results back.
UPDATE:
We have tested the CRX2OAK migration tool, and it indeed does move versions across. Using the tool, you can specify filters to only migrate a subset of content, which will then drag the version details across as well.
It seems this approach works quite well for both single tenancy and multi tenancy approaches as it used to using a package for content.
Unfortunately, it can't be used as a portable backup system, as it is an instance to instance solution. It does, however, work well for blue/green deployment strategies.
Versions are stored by path '/jcr:system/jcr:versionStorage' in AEM.
To transfer pages with their versions just create a package with filters for content which you want to move and the version storage path as well, download package and install in other AEM.
If anyone comes across this question like me, here is the summarised answer:
You can use crx2oak utility available from link below to migrate pages and page version across instances:
https://repo.adobe.com/nexus/content/groups/public/com/adobe/granite/crx2oak/
This is a powerful utility with multiple uses (especially in upgrades) as documented in links below:
https://docs.adobe.com/docs/en/aem/6-2/deploy/upgrade/using-crx2oak.html
https://jackrabbit.apache.org/oak/docs/migration.html
The source and destination repositories need to be offline while running this utility so best to plan ahead for this type of migration.
HTH
I've slightly "abused" the front-end "version" concept in App Engine (java), to implement modules before they were introduced. I have a configuration consisting of: module1-dot-myapp.appspot.com, module2-dot-myapp.appspot.com, module3-dot-myapp.appspot.com, etc., based on the version concept (more commonly used with numbers: 1-dot-myapp, etc.).
Specifically, the code in all versions is identical, but each is practically used for different purposes. This separation allows different clients to use different api versions, separate deployment schedule, staging versions, logs separation, etc.
My question is, under theses conditions, what is the best way to convert my application to "real" modules? such that "module1" is an actual module (still mapped to the same url - module1-dot-appspot.com)?
Note: my answer comes from a somehow similar exercise but in the python GAE runtime, there is likely aditional Java-specific stuff to look at as well.
First things to look at (possible show stoppers) are the app-level configs - those will need to be merged in from your different old app versions (if they exist) and will be shared by all your modules (or directed to the default module only), so they might not work as before, best to revisit the latest documentation on these configs:
dispatch file
queue
cron
DB indexes
Note: in multi-module python apps these configs might not be updated automatically at app upload, each of them may need to be uploaded explicitly, using the respective app configuration utility options.
The separate deployment schedule is almost free (each module can be deployed independently). But there may be some impact due to the app-level configs (multiple CLI invocations instead of a single one, for example)
The logs separation comes for free.
The staging story might need to be revisited, depending on what exactly you mean by that.
Other than that - you'd bring the different old versions of your app in separate module sub-directories in your new app. Check if your version control system supports this easier. The old app config file(s) would need to be "translated" into the respective module's config file(s) and some of the info would go into the new app's top dir config file.
The module URL routing should allow transparent URL mapping, but note that the URLs will actually be <module>-dot-<appname>.appspot.com and the only way to get exactly the same URLs would be to delete all older app versions before deploying the new one (due to conflicting URLs: <module>-dot-<appname> vs <appversion>-dot-<appname>, not sure if you'll get the old or the new code serving or if it's even possible to deploy the new code without error). You could use a new appname at first, just to get all ducks lined up before the switchover (possibly a new staging story you might consider going forward).
You might find helpful complementing URL routing with a dispatch file if you didn't have one before.
Finally, if you have identical files shared across modules you may consider a single per-app copy of the file, symlinked into the respective modules, if that's easier or makes sense from your source code management prospective.
I want to test my thick client against my RESTful appengine application. I regularly increment the appengine version number so I need to keep updating my test config. Is there the equivalent of http://latest.application.appspot.com that I could point my config too?
Thanks
Skirting around your question, but in my head, I've stopped thinking of the "version" in the typical software release version (which like you, I started out thinking), but rather, it's "a different application using the same datastore".
I found out the software release version (1.0, 1.1, 1.2 etc) doesn't make much sense because 1) I don't tend to use older versions 2) my main usage would be to regression test, but this doesn't work well, because it's quite possible for a change in your model in v1.1 to break the code in v1.0.
The versions feature comes in hand to have different functional versions. For example, maybe the default application.appspot.com runs production level code, but debug.application.appspot.com has more logging enabled. Perhaps a third version has administrator functionality enabled, etc.
No, there's no way to do this. Versions aren't sequenced - they're all entirely distinct deploys, only one of which is set as the default.
What you are likely looking for is the CURRENT_VERSION_ID environment variable. It stores the deployment revision as dot-separated string: version_name.deployment_revision, e.g. staging.12345678910111213141516. You could just use it directly in your config:
import os
API_VERSION = os.environ['CURRENT_VERSION_ID'].split('.')[1]
Can you test an uploaded version of an app, other than the "default" version?
I'm told it can be: WoLpH Google App Engine version numbers?
But I can't find it in the dashboard or the doco.
If the version of app is 2 and your app URL is appname.appspot.com then URL 2.appname.appspot.com will give you access to version 2 of your app.
As Vishal already said correctly (+1), you can prepend the version identifier to your url, so if your version is "version", the URL will be version.appname.appspot.com (app versions are strings, not numbers, although the string "2", is perfectly ok too).
To select another version from the Dashboard, just select the main application first, then use the second dropdown at the top of the page to select the version. This will show you the dashboard of another version, without changing the default (active) version.
Important considerations to keep in mind:
However, the main gotcha that I would like to mention, is that you're using the same Datastore of the live version. This can be a good thing, if you want to browse your application, but is not very recommendable if you want to insert test data that could potentially mess the public view.
You're also using the same task queues and cron, so you've to be careful of unintended consequences, should your application version update them.
If the problems mentioned above are important to you, you may consider to deploy another application to use for testing instead. In this way you'll be completely separated by the live environment.
Note that double wildcards for appspot.com are no longer supported (*.*.appspot.com). To test different version than default use version-dot- prefix.
appname.appspot.com // default
2-dot-appname.appspot.com // version 2
In the menu there is section Main > Versions and there you can choose the version then "Make default". Of course to have more than one version available there you have to change the version before deploying(as far as I remember you can do this in one of xml files).
Or you mean to have default version, but test another one?