Azure Template spec caching - azure

I have a Azure template spec, version "ado", which has been working great. I recently changed a parameter name (ie. "location" to "aslocation") and updated the template spec using Powershell's Set-AzTemplateSpec command with the same version name "ado"
But when I call the template spec using the new parameter name, "aslocation", it throws:
Error BCP037: The property "aslocation" is not allowed on objects of type "params". Permissible properties include "location"
Even if I try using the old parameter name, "location", it throws:
New-AzResourceGroupDeployment: Cannot retrieve the dynamic parameters for the cmdlet. D:\git\IaC\Azure\main.bicep(4,5) : Error BCP035: The specified "object" declaration is missing the following required properties: "location". D:\git\IaC\Azure\main.bicep(5,7) : Error BCP089: The property "aslocation" is not allowed on objects of type "params". Did you mean "location"?
So it seems something is being cached. Any ideas on how to resolve or avoid this problem?
I have confirmed:
Occurs using Azure CLI or Powershell commands
Occurs using VS Code's integrated terminal or standalone powershell/CMD terminals
Template spec is indeed updated (verified via portal)
Issue persists through multiple days/reboots

I managed to resolve the issue. Leaving this here in case anyone else runs into this problem.
Bicep maintains a local cache for template specs at %USERPROFILE%.bicep
This is NOT automatically updated when template spec versions are updated. You must use Bicep CLI's restore command with the --force flag to refresh it (or remove your cache).
This seems counterintuitive IMHO but I digress..
Reference: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-cli#restore

Related

Can I use Referencing functions and UI controls such as 'Microsoft.Solutions.ArmApiControl' in the uiFormDefinition of an Azure Template Spec?

I'm creating a Template Spec using Bicep, which works fine. Adding a custom UI to the Template Spec using a uiFormDefinition file also works. However, when I try to use the control 'Microsoft.Solutions.ArmApiControl' in the UI definition, it fails with the error Failed to create element of type: 'Microsoft.Solutions.ArmApiControl' named 'sqlCapabilities'. I found that I can get rid of the error by removing all referencing functions from the path property, like this:
{
"name": "sqlCapabilities",
"type": "Microsoft.Solutions.ArmApiControl",
"request": {
"method": "GET",
"path": "/subscriptions/34d76722-9b63-464d-b742-11bf072d1fc1/providers/Microsoft.Sql/locations/westeurope/capabilities?api-version=2021-11-01"
}
}
... but that doesn't actually seems to do anything. (And even if this would work the element wouldn't be very useful without referencing functions.)
While reading the documentation, I noticed there are two sandboxes in the Azure Portal for developing uiFormDefinition files:
https://portal.azure.com/#view/Microsoft_Azure_CreateUIDef/FormSandboxBlade (titled "Form view Sandbox"), which is linked to from the Create portal form page of the ARM template documentation using the shortlink https://aka.ms/form/sandbox.
https://portal.azure.com/#view/Microsoft_Azure_CreateUIDef/SandboxBlade (titled "Create UI Definition Sandbox"), which is linked to from the Create portal interface page of the Azure Managed Applications Documentation.
They look similar, but they use different schemas: the UI Definition sandbox uses https://schema.management.azure.com/schemas/0.1.2-preview/CreateUIDefinition.MultiVm.json# and the Form sandbox uses https://schema.management.azure.com/schemas/2021-09-09/uiFormDefinition.schema.json. The Form sandbox also has a few additional options such as the ability to specify the "Package Type" and "CUID".
Both sandboxes have a list documenting UI elements, which both point to the same destination: the Azure Managed Applications documentation.
The thing is: when I use the "Create UI Definition Sandbox" the 'Microsoft.Solutions.ArmApiControl' UI element works fine, even when using referencing functions like location(). However, I can't use the resulting file with the Template Spec: it attaches OK but when trying to deploy the Template Spec in the Portal I get this error: Invalid UIFormDefinition Schema. Click here to fallback to default experience.
Using referencing functions and/or 'Microsoft.Solutions.ArmApiControl' in the "Form view Sandbox" results in the problems mentioned at the beginning of this question.
Experimenting further, it looks like all functions work in both sandboxes, with the exception of referencing functions like location(), resourceGroup() orsubscription(): those only appear to work in the UI definition sandbox. The same applies to some UI elements.
Perhaps I missed it, but I wasn't able to find where this behavior is documented.
Is there a way to use the referencing functions and Microsoft.Solutions.ArmApiControl in a form definition for a Template Spec? If so, how can I do that?
TL;DR - you can do what you want, take a look at this: https://techcommunity.microsoft.com/t5/azure-governance-and-management/using-azure-templatespecs-with-a-custom-ui/ba-p/3586173
Long version, there are 2 schemas/formats for portal ui (as you discovered), there is an "old" version CreateUIDefinition.MultiVm.json and a newer version uiFormDefinition.schema.json - the newer version is largely a superset of the old version... i.e. it supports all the old stuff and has some new stuff. This distinction is not well documented yet.
templateSpecs only support the "newer" schema.
That help?

Access secret environment properties in IBM cloud deploy - NodeJS

I'm having some problem with accessing my secret environments properties I've set in my build stage. In the build environment properties I got two secret fields called "w_username" and "w_password", however, I can not access these properties inside of my NodeJS runtime. I've tried with process.env['w_username'] but it seems like it can't find it. How is it possible to access them?
Using NodeJS 6.x, npm 6.x with SDK for NodeJS on IBM cloud.
You can directly access the build environment properties in the next stage in the toolchain with their names like w_username and w_password.
You can examine the environment properties for a pipeline job by
running the env command in the job's script.
You can also define your own environment properties. For example, you might define an API_KEY property that passes an API key that is used to access IBM Cloud resources by all scripts in the pipeline.
You can add the following types of properties:
Text: A property key with a single-line value.
Text Area: A property key with a multi-line value.
Secure: A property key with a single-line value that is secured with AES-128 encryption. The value is displayed as asterisks.
Properties: A file in the project's
repository. This file can contain multiple properties. Each property
must be on its own line. To separate key-value pairs, use the equals
sign (=). Enclose all string values in quotation marks. For example,
MY_STRING="SOME STRING VALUE".
For more information, refer here
Hope this helps

Azure function published but not running, "no data available"

I can publish a Azure function from Visual Studio without an error.
This funtion is set to run every 4 seconds ("*/4 * * * * *") but it is not running at all. Even if I try to run it manually it do not run and show the following error:
Status: 404 Not FoundThe resource you are looking for has been
removed, had its name changed, or is temporarily unavailable.
Under monitoring it do not shows data, under success or error count it says no data available :(
Nothing is working please help
This is a pretty old thread but in case anyone is facing the same issue after migrating their Function App to .NET Core 3.1, check that you have also updated the Function Runtime Version to 3. Update the Function App SDK and in Azure portal check that the function runtime settings is 3. Without updating this setting the same 404 error appears whenever you try to call your function app.
For changing the Function Runtime Version open the Function App in Azure Portal then go to Configuration -> Function runtime settings. From the Runtime version dropdown choose ~3.
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
According to your 404 error message, it means your function source couldn’t be found. Such as wrong resource path , function name has been changed, wrong function name or the function has been deleted.You could check whether your class name and FunctionName attribute name are consistant. If you have changed code, remeber to rebuild the project.
And please make sure you could run the Azure function successfully in Visual studio before published to Azure. In debug mode, check whether output logs are correct.
Under monitoring it do not shows data, under success or error count it says no data available
This info usually means function has never been triggered before. If you create a new function in Azure and click Monitor directly, you could also see this info. To solve this problem, unless you could trigger this Azure function successfully.
In my case I was deploying the azure function using the Azure Resource Manager (ARM) template. I created it manually and was missing some of the properties for the storage account:
For anyone deploying an Azure Function using an ARM template, I would highly recommend taking a template from the GitHub quickstart ARM templates: https://github.com/Azure/azure-quickstart-templates
It provides the minimum template to get your function (and other resource) up and running.
The issue with your function was that GetFTPData.cs is not a valid function name. VS build doesn't validate the function name and the portal isn't displaying these errors.
This issue is tracking the portal error display https://github.com/Azure/azure-functions-ux/issues/2316
and this is for VS build to validate functionName attribute https://github.com/Azure/azure-functions-vs-build-sdk/issues/174

What is the Azure API version

I'm trying to access the result of a GET request provided by Azure, as shown in the example : https://msdn.microsoft.com/sv-se/library/azure/dn820159.aspx
My problem is that the api-version is a mandatory argument, but I have no idea about what to write inside. I'm a bit lost with the Azure Batch documentation, it doesn't seem to be complete.
I found something in an Azure webpage : https://azure.microsoft.com/en-us/documentation/articles/search-api-versions/ and the api-version was api-version=2015-02-28. However, if I try it in my browser, I have this answer : "key":"Reason","value":"The specified api version string is invalid".
Any idea of what I can put inside the api-version parameter ?
Have a look here
As the time of this writing
The version of the Batch API described here is '2016-07-01.3.1', and
using that version is recommended where possible.
Earlier versions include '2016-02-01.3.0', '2015-12-01.2.1',
'2015-11-01.2.1', '2015-06-01.2.0', '2015-03-01.1.1', and
'2014-10-01.1.0'.
So try specifying '2016-07-01.3.1'

How can I access the parameters of a service on a Carbon server in plain txt

What I've done is broken the default 'Version' service on my WSO2 DSS, I tried to set the Scopes variable for WS-Discovery and didn't put a closing tag/element when creating the parameter.
Now when I try to access the parameters screen I get an xml Parse error
TID: [0] [WSO2 Data Services Server] [2012-08-22 12:38:04,404] ERROR {org.wso2.carbon.service.mgt.ServiceAdmin} - Error occured while getting parameters of service : Version
{org.wso2.carbon.service.mgt.ServiceAdmin}org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '<' (code 60) in end tag Expected '>'. at [row,col {unknown-source}]: [2,58] at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296) at
I'm assuming this is stored in the H2 database, I've tried looking for the parameter in the .db file using notepad but I can't find it.
Is there another way to connect/browse the H2 db?
I've scanned through the repository, database and conf directories for clues without success.
UPDATE:
Yes you can connect to the H2 db using the included database Explorer under the Tools menu.
Use the connection details found in the repository/conf/registry.xml file
Then you can do SQL queries on it - (I haven't found the answer yet though)
UPDATE 2:
I don't think the parameters are held in the H2 db, but I managed to fix my problem by:
downloading the Version.aar file using the link on the list services page
deleting the Version service
Copying the Version.aar file into the repository/deployment/server/axis2services dir
I guess deleting the service removed any records/references to my broken parameter
I believe you've tried setting service parameters via the UI? Usually the service parameters you specify via the UI do not get saved in the services.xml of the original axis2 service archive. Instead, they get saved in the registry that is shipped with DSS and get applied to the service at runtime. But if you specify a malformed parameter then wouldn't be saved in the registry instead, throwing an exception while trying to engage that parameter. So there'll be no record saved corresponding to that kind of malformed parameters.
Hope this helps!
Cheers,
Prabath

Resources