I've been playing with IBM Bluemix (liking it a lot so far) and we are considering to use it for production. What I'm not totally clear on is what happens when runtime environments or services get updated. I assume this happens quite frequently.
Will the new version be always backward compatible? If so, is this guaranteed somewhere in the terms of service?
What I am trying to avoid is to put production code on the platform and then having to update it constantly (or having it break) due to runtime or service updates.
Does anyone have any experience? Have past updates always been backward compatible?
Mark
While I don't believe there is a guarantee that the buildpacks will always be backwards compatible, you will always be able to select the previous buildpack version.
Try running a 'cf buildpacks' command and have a look at the buildpack names and version info encoded therein and think you'll see what I mean.
When buildpacks are updated they won't be used for your application until you restage it, so you have some control over when to pick up the updates as well. This gives you a chance to test it on non-production versions of the app.
Related
Would it be possible to upgrade from MediaWiki from 1.15 to the latest stable version without losing data? I believe I will have a problem with database tables and extensions.
Thank you in advance
From personal experience I would recommend to take it easy and upgrade one major version at a time, especially when you do not have much experience with the process. This bite size approach will take longer but in return you will:
have to deal with fewer issues every time something is not right,
gradually update the LocalSettings.php as you go along every time moving it from the current to new release,
familiarise yourself with the Release Notes for each version - they contain notes on the configuration and breaking changes among other things, and finally
get comfortable with the process.
This approach helped me when I was upgrading from 1.27.3 to 1.31.8 first time in years. I came across problems at least twice and could not find relevant information on how to deal with them. The most annoying was no feedback from the update.php script or blank page when trying the new installation.
Below I include notes from my experience with updating MediaWiki in case that's of any help to anyone facing a big upgrade. These are just main points, so read the official Upgrading page too.
Installation
Don't extract a MediaWiki release archive into the existing wiki installation directory. Move the old instance to some backup directory and start afresh. Also make a back-up of the database.
Create a copy of LocalSettings.php from the original installation and comment out all custom extensions and skins as they will no longer be present.
Now as you bump the versions up:
Copy LocalSettings.php from the previous instance to the directory created while extracting a release archive. There does not seem to be a way to generate a fresh default LocalSettings.php during an upgrade, which would prevent some of the problems.
Run update script in the maintenance directory. There should be some output:
$ php update.php
MediaWiki 1.31.8 Updater
...
If there is no output at all that means there is likely a problem somewhere in the LocalSettings.php configuration. See the Debugging section below.
You should be able to access the wiki now.
Get a release archive of the next major version, read the Release Notes and repeat the steps.
Once you reached the target version you can gradually copy over all the custom changes from the old wiki (extensions, modifications, images, skins etc.) remembering to enable them in LocalSettings.php.
Keeping MediaWiki under version control makes it much easier to keep track of any customisations. Just make sure you keep the repository inaccessible to the world.
Debugging
In order to debug enable the following settings in LocalSettings.php:
$wgShowExceptionDetails = true;
$wgShowDBErrorBacktrace = true;
$wgShowSQLErrors = true;
Now go to the installation page https://.../mw-config/ (adjust the URL to match your set-up) and you should see some errors that might indicate what is wrong. For example, some skins or extensions from the older version may not supported any longer and you have to disable them in LocalSettings.php.
Once the configuration has been updated try again until you get to the web installer.
Once you managed to get to the web installer page stop there and try again with update.php script. It should work now. Close the web installer, there won't be any need to run it now.
Once update.php has finished you should be able to access the wiki. Disable the debug settings in LocalSettings.php.
In theory, yes - the update mechanism is a big array of database migration scripts, which gets expanded when you upgrade the code, so the number of versions doesn't really matter. In practice, that's a long way to go, so it's very unlikely anyone else has tested that specific upgrade path. Make sure to backup first.
One notable exception is HitCounter data, which does get dropped, as that functionality was removed from MediaWiki. See that page for workarounds.
I'd written my own over-air-update for previous version of iot-core (with or without iot-hub). The recent auto-update of iot-core (10.0.14393.67) broke it. Now, looking once again for clarity on this crucial (out-of-box feature on debian) capability, I am more confused than ever. Who can answer:
This post talks about updating firmware via the iot-hub. Is firmware my (uwp) iot-core app (e.g. background task) or not?
This post talks about oem deals from microsoft for iot-core commercialization (https://www.windowsforiotdevices.com/) which provide update capabilities. However, it is unclear about:
Is "option one" free? If not, what is the catch?
Are the update capabilities available in this "option one"
At best, we'd need a trade-off-set juxtaposition of the iot-hub vs. oem app-package-update scenarios since once a developer decides for one or the other paths, it is a major investment.
Update
What really matters here is clarity to companies/developers on the options and limitations regarding "over air updates" of:
Our Apps (Appx, headless, in our case. C#.) built in Visual Studio 2015.
The iot-core OS (automatic or scheduled...).
Ths iot-core OS WITH (or in conjunction with) our Apps.
These options, and their costs, are not clear. We are currently using the azure iot-hub (et. al.) and would like to leverage it as much as possible.
What happened, and what I am urgently trying to fix, is "3" above: I had an appx in the field and was using the /System32/oemcustomization.bat option to install new versions of my app via C:/windows/appinstall/...
This was working fine at all my remote sites for months. I was confident that all was stable. All of the sudden, my sites all wend offline. In my local laboratory, I could connect to my test systems where I noticed that Microsoft had done an automatic OS update of iot-core. There were breaking changes... and these changes are now of the nature that my previous over-air-update scheme no longer works even if I modify it -- there are security "fixes" that break my current approach and I see now way to salvage it yet.
Thus, what we really need from the PM is clarity on the above (1-3) items, and, at best, an complete, minimal example in C# for items 1-3.
Looking forward!
There appear to be two current solution streams here, both highly volatile/preview as far as I can see:
windows-store oem track: https://developer.microsoft.com/en-us/windows/iot/docs/store
iot-hub device management track: https://azure.microsoft.com/en-gb/documentation/articles/iot-hub-device-management-device-jobs/
After publishing a new version of our extension to production, we sometimes see a weird behavior:
The extension on the browsers seems to be only partly updated (after given some time).
Our internal version number (part of our code) shows in such cases a previous version number, although some features and resources from the newer version already exist.
We have seen this occasionally in all browsers and on different operating systems.
Any idea why is that and what can be done?
Note: our extention.js and popup.html files are about 380kb (I don't know if that makes any difference).
Whilst I don't know the specifics of your scenario, in general, updates are automatically checked for and pulled if required by the extension several times a day. If there is anything that interrupts the process such as connectivity problems, then a partial update may occur though there are mechanisms in place to try and protect against this. Also, note that resources update if there are changes to one of the core files (extension.js or background.js).
[Disclosure: I am a Crossrider employee]
I'm developing a Chrome App (as a packaged app/extension) which purpose is to act as the base platform for several fullscreen apps to be build on top of. Chrome will be running on Ubuntu Linux.
And no trouble so far. But then I was told, that an intended app it is to be the platform for requires the source code to be updated with very short notice, as it probably is to be deployed for large scale use before the system has been tested through (even though it's a bad idea to deploy software that's not completely stable, but we're on a tight schedule). The problem is, that the "a few hours" interval for the autoupdating mechanism just isn't good enough.
So I somehow need to have the updating interval changed. I know this can be done with the --extensions-update-frequency command line switch, but as apps cannot access the command line (for obvious security reasons), and I'd prefer that the intended background page was to handle all the "administration", I don't think that switch is possible to use.
Is it somehow possible to update at a higher frequency? Or at times when it's ordered to?
There is now a method chrome.runtime.requestUpdateCheck():
Requests an update check for this app/extension.
It will return a status, which can be either "no_update", "update_available" or "throttled".
Unfortunately, the docs do not specify the limits for frequency that will trigger "throttled".
Your best option will be to have the extension manually check with your servers for an updated version. If there is an updated version show the user a desktop notification to manually update.
Potentially you could write a NPAPI plugin to modify the update frequency.
This may cause issues with CSP but you can try to live load JavaScript from your server that executes in the extension. In this case to "update" your extension you would simply update the JS hosted on your servers and the extension would automatically start using it on next load.
Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.
It seems quite complicated and difficult to configure for anybody who isn't Google. What is the experience using Omaha in projects? Can it be recommended?
We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.
There are no regrets with ditching our old client update solution and going with Omaha.
Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.
You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.
More information on how Courgette works can be found here and the official blog post about it here.
It works like this:
server:
hint = make_hint(original, update)
guess = make_guess(original, hint)
diff = bsdiff(concat(original, guess), update)
transmit hint, diff
client
receive hint, diff
guess = make_guess(original, hint)
update = bspatch(concat(original, guess), diff)
When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:
Usage:
courgette -dis <executable_file> <binary_assembly_file>
courgette -asm <binary_assembly_file> <executable_file>
courgette -disadj <executable_file> <reference> <binary_assembly_file>
courgette -gen <v1> <v2> <patch>
courgette -apply <v1> <patch> <v2>
Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.
I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.
Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).
While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.
To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.
UPDATE
Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
Updates aren't published that frequently
crystalnix/omaha is managed by the community and they try to merge the main repo into their's; additional features are implemented and basic things are fixed
google/omaha is more active and changes from google are added but not frequently
To implement manual updates in any language you can use the com classes
Resume
google omaha is still alive but in a lazy way
bugs are fixed but do not expect hotfixes
google omaha fits for windows client apps supported from windows vista and upwards
the server side I'm using supports also sparkle for crossplatform support
feedbacks and crashes are also supported on the server
feedbacks are sent with the google protocol buffers
crash handling is done with breakpad
I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.
In the .NET world you might want to take a look at ClickOnce deployment.
An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.