I have come onto a project that has had an ARM deployment via templates running for a number of months now, and until recently everything was working without issue:
Successful deployments
But then, something changed and most (but not all) deployments began failing:
Unsuccessful deployments
The error reported is:
{
"code": "Conflict",
"message": "Conflicting changes were detected when processing the request. This can happen when there are multiple requests trying to update one profile at the same time. Please retry your request."
}
Yet this is the only deploy running at the time. For now I've managed to stave off the issue by adding a dependsOn to the traffic manager resource:
{
"apiVersion": "2015-11-01",
"type": "Microsoft.Network/trafficManagerProfiles",
"name": "[variables('traffic-manager-name')]",
"location": "global",
"properties": {
"profileStatus": "Enabled",
"trafficRoutingMethod": "Priority",
"dnsConfig": {
"relativeName": "[variables('traffic-manager-name')]",
"ttl": 30
},
"monitorConfig": {
"protocol": "HTTP",
"port": 80,
"path": "/"
},
"endpoints": [
{
"name": "[variables('traffic-manager-endpoint')]",
"type": "Microsoft.Network/trafficManagerProfiles/azureEndpoints",
"properties": {
"endpointStatus": "Enabled",
"targetResourceId": "[resourceId('Microsoft.Web/sites', variables('web-app-name'))]",
"target": "[concat(variables('web-app-name'), '.azurewebsites.net')]",
"weight": 1,
"priority": 1,
"endpointLocation": "[resourceGroup().location]"
}
}
]
},
"dependsOn": [
"[resourceId('Microsoft.Web/Sites', variables('web-app-name'))]"
]
}
But I am concerned that doing so may simply be obfuscating a genuine issue that still needs addressing. If anyone knows any more about that error, or why it might have just started happening out of nowhere, I'd love to know!
When using ARM template to deploy traffic manager, it returns with 409 conflict error "Conflicting changes were detected when processing the request. This can happen when there are multiple requests trying to update one profile at the same time. Please retry your request." because the ARM template deployments are aimed at creating new resources hence it use PUT requests. If the traffic manager profile already exists, it will return when the template makes a change that would alter or affect existing profiles. Before deployment, there was a traffic manager created, thus the template failed with conflict error. To resolve or overcome the issue make sure that no TM profile created before the ARM deployment. Then retest the deployment.
Hope this helps! Cheers!
Related
Created an app in vue-cli and then I build the dist folder for production with a new app version.
The problem occurs when I have to make some changes and I have to redo the deployment. After this,App doesn't work with updated version but if I clear the chrome cache in the site settings of the particular site , the app works fine again.
The app is deployed on Firebase Hosting.
A solution to clear chrome cache when I release a new vue version?
The "smart" caching can be done by the server-side technology. If you have access to this and can manage the type of caching, you can set it to use etag, which I've found is quite reliable.
Vue apps, bundled using webpack, will generate filenames with hashes. So if there is anything different in the app, or chunk(if you're code splitting) the generated file names will be different. The issue though is that the index.html will keep the same name. So if you can set the correct caching options for that file alone, that will solve most of your problems. Alternatively, you can set a really short cache time or no cache at all (since it should be a small file) if you're concerned about the page loading from cache. But the problem still remains that this part of the caching functionality is entirely out of reach of the vue app.
Looks like with firebase you can edit the configuration and set headers per resource ref
so you could set a long max-age for css and js, and short for index.html like so...
"headers": [ {
"source": "**/*.#(eot|otf|ttf|ttc|woff|font.css)",
"headers": [ {
"key": "Access-Control-Allow-Origin",
"value": "*"
} ]
}, {
"source": "**/*.#(jpg|jpeg|gif|png|js|css)",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=7200"
} ]
}, {
"source": "index.html",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=300"
} ]
} ],
I had the same problem when updating my project.solution :the version number in package.json before running the build command fixed it.
package.json file:
{
"name": "project-name",
"version": "0.1.1",
"private": true,
...
}
I am trying to simple meteor application using mupx. In my scenario, I want to bypass docker setup and all docker options because everything is already installed on my destination server.
how can I do that ? I am using mupx 1.5.2 version.
here is my mup.json file.
{
"servers": [
{
"host": "MY_HOSR",
"username": "USER",
"password": "PASSWORD",
"env": {}
}
],
"setupMongo": false,
"setupNode" : false,
"appName": "blank",
"app": "/home/rut2/meteor_workspace/blank",
"env": {
"PORT": 3000,
"ROOT_URL": "http://MY_HOST:3000"
},
"deployCheckWaitTime": 15,
"enableUploadProgressBar": true
}
The reason I want to disable this is, I never could deploy successfully with this options. It always gives me error while starting meteor/ verifying deployment stage. (I will discuss error if anyone wants to help on that one also.)
I had the lower version of mup (1.0.1, which is without docker options), and it was working perfectly.
Please help me guys. I have been stuck here since 3 days. tried every issues, every forum I found related.
Thank you in advance
You can't use mupx without docker. I had these kind of problems too, some solutions that works for me: upgrade server node version, increase deploy wait time, custom image.
This bears a lot of resemblance to ERROR on Azure Web App Deployment of a msdeploy package
I am running msbuild /t:packagepublish to automate deployment using ARM templates. The relevant part of the template:
"resources": [
{
"name": "MSDeploy",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-08-01",
"dependsOn": [
"[concat('Microsoft.Web/sites/', variables('webAppName'))]"
],
"tags": {
"displayName": "webDeploy"
},
"properties": {
"packageUri": "[concat(parameters('_artifactsLocation'), '/', parameters('webDeployPackageFolder'), '/', parameters('webDeployPackageFileName'), parameters('_artifactsLocationSasToken'))]",
"dbType": "None",
"connectionString": "",
"setParameters": {
"IIS Web Application Name": "[variables('webAppName')]"
}
}
}
]
This fails with the error that there is no property called "IIS Web Application Name", and I can see from the generated package file there indeed is no parameters.xml as there would be for an ASP.NET 4 template.
Removing that leaves me with the error:
Unable to perform the operation ("Create Directory") for the
specified directory
("C:\Users\Jim\AppData\Local\Temp\PublishTemp\API78\wwwroot").
so clearly it's trying to replicate the local directory structure. What I'm not sure though is how/where to address this.
I see there's a msdeploy switch -declareParam, but I invoke msbuild, not msdeploy. I'd hope there's a way to do it in the template extension, but I can't find any sort of documentation on what/how to provide values there.
This is leveraging the build templates at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0
Not sure if its completely applicable but I recently blogged about using SetParameters via MSBuild.
https://dotnetcatch.com/2016/04/27/setparameters-via-msbuild-commandline/
Summary: The SetParams are an ItemGroup. The MSBuild.exe command doesn't support providing ItemGroups only Properties. I added some MSBuild script to accept a Property and convert to ItemGroup thus setting the params.
Ideal Situation
Often while working on a Symfony2 project I will spot something I want to change in one of my dependencies. If I could find a way to simply change it in vendor and then easily push the changes as a pull request then I would probably contribute more often (rather than overriding the part with a local child bundle).
The Problem
I can't change a vendor directory without composer freaking out on the next update. If I submit a pull request then it may take quite some time before I can actually use the code in vendors, which is actually a deterrent from contributing my new functionality.
How I do it now
The way I typically contribute to a bundle is to make a fork, put the fork in a barebones symfony standard-edition app, make the change and then submit a pull request.
Put fork in composer.json?
The only solution I can think of, is removing the packagist dependency of the bundle I am editing, and then including my fork with composer (as a package) from github. That way I get my code immediately and can still contribute.
Is this the only solution? How do you do it?
Any tips/advice for contributing to a bundle while working on a different project at the same time would be appreciated!
Nah... this is broken.
I've tried the official way to include a fork, here's an example (original:kitano, fork: jstoeffler) of the composer.json :
(For those who are in a hurry: THIS DOESNT WORK)
"repositories": [
//...
{
"type": "vcs",
"url": "https://github.com/jstoeffler/KitanoConnectionBundle",
},
//...
],
It keeps using the original bundle. Don't know what the problem is, and I don't get how everything works, but here's how I successfully add a fork to a project.
"repositories": [
//...
{
"type": "package",
"package": {
"name": "kitano/connection-bundle",
"version": "dev-master",
"source": {
"url": "https://github.com/jstoeffler/KitanoConnectionBundle.git",
"type": "git",
"reference": "master"
},
"autoload": {
"classmap": [""]
}
}
},
//...
],
[UPDATE: Answer Not Valid Anymore]
As pointed out in one of the comments, this answer is a couple years old and not correct anymore. See answers below for the correct way to proceed.
[Original answer below]
This is the approach recommended by Jordi Boggiano (#Seldaek), creator of composer.
See from his talk at Symfony Live San Francisco earlier this year (at the 2 minutes mark):
http://www.youtube.com/watch?list=PLo7mBDsRHu11ChvScWUE7MN1Qo5QVHQEz&feature=player_detailpage&v=P3NwF8RV1lY#t=120s
As of 2017 the proper way to do it is:
Add your GitHub branch link to the repositories
"repositories": [
{
"type": "vcs",
"url": "https://github.com/crimson-med/yii2-link-preview"
}
],
Add the source to the require of your composer.json
"require": {
"yii2mod/yii2-link-preview": "dev-master"
},
FYI, I just tried the very first option:
"repositories": [{
"type": "vcs",
"url": "https://github.com/thujohn/twitter"
}],
"require": {
"laravel/framework": "4.2.*",
"thujohn/twitter": "dev-master",
"anahkiasen/flickering": "^0.1.2",
"fairholm/elasticquent": "dev-master",
"facebook/php-sdk-v4" : "~5.0"
},
An it worked fine.
vagrant#dev:/var/www$ sudo php composer.phar update
Loading composer repositories with package information Updating dependencies (including require-dev)
- Removing thujohn/twitter (2.0.4)
- Installing thujohn/twitter (dev-master 7a92118)
Downloading: 100%
Writing lock file
Generating autoload files
> php artisan clear-compiled
> php artisan optimize
Generating optimized class loader
I just needed to specify the "master" branch name as "dev-master".
I've been experimenting with resumable.js and I've been very happy with the performance of its built-in node.js server on my laptop. However, it dies on anything over about 1MB when I deploy it to heroku or nodejitsu and get this error:
Poorly formatted HTTP response (heroku)
or
{"bytesParsed":9,"code":"HPE_INVALID_STATUS"} (nodejitsu)
How can I fix this so I can deploy?
Here's my package.json:
{
"name": "uploader-resumable",
"version": "0.0.1",
"dependencies": {
"express": "3.0.x"
},
"engines": {
"node": "0.8.x",
"npm": "1.1.x"
},
"subdomain": "blahblah",
"scripts": {
"start": "app.js"
}
}
I'm replying to this unanswered question because of its high search-rank when you search for the HPE_INVALID_STATUS error, even though it is a little old.
This error may occur when you're passing an invalid status code with the HTTP response from within nodeJS without checking for a valid status code, for instance an object instead of a number. (I've seen a lot of HTTP/1.1 [Object object] responses pass by when i was helping someone to debug this behaviour ...)
Poorly formatted HTTP response
is a specific response code returned from Heroku. Nodejitsu shouldn't be showing that error.
see: https://devcenter.heroku.com/articles/error-codes#h17-poorly-formatted-http-response