We have a bunch of applications which depend on Google Cloud Functions - and there is an asynchronosity between when the Cloud functions get updated and the Applications get updated.
Suppose we update the Cloud Function first, then the app breaks. However if we update the application first it won't work with the current version of the cloud functions.
A way to solve this would be by being able to specify which version of the cloud function to execute. Is this possible?
Many thanks!
There is no versioning scheme built into Cloud Functions. When you update a function, it gets rolled out immediately.
If you want such versioning you can of course include it into the naming scheme that you use. So if you have an existing myFunction that you want to update in an incompatible way, deploy myFunction_v2.
You could, over time as the v1 clients disappear, update the versioned v2 function into the default myFunction again.
Alternatively you can include a version number into your code itself, and into the invocation. So have each client pass along the version of the functionality it is expecting to get, and then have the server-side code do a conditional check:
if (context.params.api_version === 1) {
... behavior 1
}
else if (context.params.api_version === 2) {
... behavior 2
}
Related
Is there any version/source update step or action that needs to be done when building GCFs with Cloudbuild. Or is there anyway to make sure that pubsub topic invokes the latest GCF version?
I've got a bunch of GCFs that are built with CloudBuild, and afterwards invoked by a pubsub topic. Weirdly some of them (not all) throw an error from a previous version of the GCF (the last GCF build actually fixes the error).
GCFs source code shows what's expected: the latest version of the code
Yet, GCF throws error that was in the GCF's previous version source code.
That line doesn't even exist in the source code of the currently active GCF's version (GCF > Functions > FUNC_NAME > Source).
In some occasions it's been a few hours since a GCF deployment and the first invocation.
From the best of my understanding, a new code is to be used at a "cold start" of a next "slot/instance" of a cloud function... And if you have some instances being used constantly - when one invocation is finished, the next one uses this (just became available) available "runtime environment slot", so that the environment is not created from scratch. Thus, it may take some time until all those "slots" are substituted with new, which have the new version of code being uploaded when the environment is created.
You might prefer to delete the cloud function, and then recreate it (using the new code), or drain the pubsub, so there is a pause in cloud functions being triggered.
I want to detect current windows 10 update status programmatically.
I tried wuapi and it works well but there are some problems in wuapi.
First, it takes long time to get update information.
Second, it can not be used at offline.
Is there any other method to detect current windows 10 update status?
Is there any registry or system file to detect it?
I tried procmon to analyse but there are too many files and registries linked with windows udpate.
Thank you...
There is no documented way to access the search results that Automatic Updates is using (the results that the Windows Update page in Settings displays).
However, there are two things that might be of use to you:
You can use IAutomaticUpdatesResults::LastInstallationSuccessDate to immediately see the last time the computer installed updates successfully. If all you want to know is "Is this PC processing updates successfully?", then this may be all you need.
You can use a Windows Update API search to see what updates are needed. Here's a script you can use as a starting point. If you use this script as written, it will go online to find newly-released updates, which isn't what you want in your scenario. But you can set your IUpdateSearcher object's Online property to false before calling Search. Doing that will perform an offline scan, in which WU just re-evaluates the updates it already knows about. This will work offline and will also return faster results.
"COM API
The COM API is a good way to directly access Windows Update without having to parse logs. Applications of this API range from finding available updates on the computer to installing and uninstalling updates.
You could use the Microsoft.Update.Session class to run an update search and then count the number of updates available to see if there are any updates for the computer.
PowerShell Example:
$updateObject = New-Object -ComObject Microsoft.Update.Session
$updateObject.ClientApplicationID = "Serverfault Example Script"
$updateSearcher = $updateObject.CreateUpdateSearcher()
$searchResults = $updateSearcher.Search("IsInstalled=0")
Write-Host $searchResults.Updates.Count
If the returned result is more than 0 then there are updates for the computer that need to be installed and/or downloaded. You can easily update the powershell script to fit your application.
Just a heads up, it appears that the search function is not async so it would freeze your application while searching. In that case you will want to make it async."
Registry method
Source:
https://serverfault.com/questions/891188/is-it-possible-to-detect-the-windows-update-status-via-registry-to-see-if-the-s
The MSI installation would call my (native/C++) custom action functions. Since the DLL is freshly loaded, and the MSIEXEC.EXE process is launched separately for each function (the callable actions, as specified in MSI/WiX script), I cannot use any global data in C/C++ program.
How (or Where) can I store some information about the installation going on?
I cannot use named objects (like shared-memory) as the "process" that launches the DLL to call the "action" function would exit, and OS will not keep the named-object.
I may use an external file to store, but then how would I know (in the DLL's function):
When to delete the external file.
When to find that this function call is the first call (Action/function call Before="LaunchConditions" may help, not very sure).
If I cannot delete the file, I cannot know if "information" is current or stale (i.e. belonging to earlier failed/succeeded MSI run).
"Temporary MSI tables" I have heard of, but not sure how to utilize it.
Preserve Settings: I am a little confused what your custom actions do, to be honest. However, it sounds like they preserve settings from an older application and setup version and put them back in place if the MSI fails to install properly?
Migration Suggestion (please seriously consider this option): Could you install your new MSI package and delete all shortcuts and access to the old application whilst leaving it
installed instead? Your new application version installs to a new path
and a new registry hive, and then you migrate all settings on first
launch of the new application and then kick off the uninstall of the
old application - somehow - or just leave it installed if that is
acceptable? Are there COM servers in your old install? Other things that have global registration?
Custom Action Abstinence: The above is just a suggestion to avoid custom actions. There are many reasons to avoid custom actions (propaganda piece against custom actions). If you migrate settings on application launch you avoid all sequencing, conditioning, impersonation issues along with the technical issues you have already faced (there are many more) associated with custom action use. And crucially you are in a familiar debugging context (application launch code) as opposed to the unfamiliar world of setups and their poor debugability.
Preserving Settings & Data: With regards to saving data and settings in a running MSI instance, the built in mechanism is basically to set properties using Session.Property (COM / VBScript) or MsiSetProperty (Win32) calls. This allows you to preserve strings inside the MSI's Session object. Sort of global data.
Note that properties can only be set in immediate mode (custom actions that don't change the system), and sending the data to deferred mode custom actions (that can make system changes) is quite involved centering around the CustomActionData concept (more on deferred mode & CustomActionData).
Essentially you send a string to the deferred mode custom action by means of a SetProperty custom action in immediate mode. Typically a "home grown" delimited string that you construct in immediate mode and chew up into information pieces when receiving it in deferred mode. You could try to use JSON-strings and similar to make transfer easier and more reliable by serializing and de-serializing objects via JSON strings.
Alternatives?: This set property approach is involved. Some people write to and from the registry during installation, or to a temp file (in the temp folder) and then they clean up during the commit phase of MSI, but I don't like this approach for several reasons. For one thing commit custom actions might not run based on policies on target systems (when rollback is disabled, no commit script is created - see "Commit Execution" section), and it isn't best practice. Adding temporary rows is an interesting option that I have never spent much time on. I doubt you would be able to easily use this to achieve what you need, although I don't really know what you need in detail. I haven't used it properly. Quick sample. This RemoveFile example from WiX might be better.
I am trying to migrate a legacy app that is using camel/cxf (offers some web services that include transformations) to Websphere Liberty 16.0.0.03 (IBM JRE 1.8). Tests are failing because the app uses extensions functions. I tried to disable secure processing as described here.
This change has no effect. That's why I try to switch to Saxon Implementation globally by setting System Property "javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl" in jvm.options config file. Again - this does not work.
While debugging I can see, that com.ibm.ws.webcontainer.osgi.mbeans.PluginGenerator$2 is overriding the Property with com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl during Server start. I can see a method "PluginGenerator.revertTransformerFactoryIfNeccessary" in the stack that seems to trigger the change. Afterwards all FactoryFinder.find() will return the non-Saxon implementation.
Can anyone suggest how to either disable secure-processing successfully
or
a way to successfully set a custom TransformerFactory?
BTW: It seems to me like these 2 are bugs - do I report these as regular PMR?
EDIT: possible workaround
As result of the helpful suggestions I added an '#WebListener' that will sets the System Property within the constructor (setting it in contextInitialized is too late as stylesheets seem to be compiled during application start and thus processing fails tests). I bundle this a "patch-jar" with the legacy app.
The Liberty web container plugin generator will only override the xml transformer factory if the IBM JDK is being used.
While the web container performs plugin generation using the IBM JDK, it will swap to an alternate transformer factory, and then reset to the IBM JDK default of which is com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.
I think it is worth opening a PMR here. The PluginGenerator should not assume that it started with the default xml transformer factory, and should instead save off the value of javax.xml.transform.TransformerFactory and then restore it after plugin generation has completed.
Temp workaround:
Since the PluginGenerator only swaps the XML transformer factory if you're running on the IBM JDK, you could change to an alternate JDK until your PMR gets resolved.
I agree that this is a bug. The official route for reporting problems is a PMR, but there is enough here for us to understand the problem and fix it through our beta program. If you want to get an iFix on a released version of the product (rather than waiting for it to come out via the beta program) then you will need to raise a PMR.
Currently i am implementing the Google closure testing possibilities.
It works as a charm.
I Define the TestCase by hand, and add the test by hand. I also create a separate runner for the tests so I can catch all the results and pass them to another function.
This function sends the results through ajax to PHP so the results can be logged in the database (also works as expected).
The problem however is that because I do this, and I load the page in the browser the tests get executed 2 times (one time because of the auto-discovery and once because i defined it in the testcase.
I would like to disable the auto-discovery, but I don't want to disable the flag in the closure library, this because when the library gets updated we need to reset the flag to false again.
So how can i disable auto-discovery without modifying the code in the closure library?
Thanks in advance!
If you look into jsusnit.js, you'll see that goog.testing.jsunit.AUTO_RUN_ONLOAD = true; is hard-coded there and you can override this variable only through closure compiler's define.
If you don't compile your test code (I don't, because of speed of iteration), the only option seems to change this to false, and redo the change on closure library updates.