Hi Mike,
I have spent at least a day going through the dozen or so causes of the dreaded initializing-busy-stopping loop. Basic diagnostics in this area are critical. At the moment this is a totally blind area. Ironically I have had to use an amazon 64 bit machine to help diagnose some of the issues and I still don't have a web role that will start yet.
A great option would be a console like feature as we see in the dev fabric that could tell us "BadImageFormatException" for xyz.dll, or fil... more
Hi Mike,
I have spent at least a day going through the dozen or so causes of the dreaded initializing-busy-stopping loop. Basic diagnostics in this area are critical. At the moment this is a totally blind area. Ironically I have had to use an amazon 64 bit machine to help diagnose some of the issues and I still don't have a web role that will start yet.
A great option would be a console like feature as we see in the dev fabric that could tell us "BadImageFormatException" for xyz.dll, or filenotfound nesteddependency.dll, incorrect storage connection string etc.
Major issue we face with Azure deployment is no support for partial updates to the package. Any small change made should be redeployed which itself takes 20-30 mins. Image in a web role just adding a link to a page or something such small requires us to deploy everything again :(
sitting here watching another deployment that's got as far as "Up" on a progress bar that says "Upgrading Domain 1 of 2" after an hour.... this is really painful.
please... give us:
(a) more visibility into what's actually going on
(b) an option to cancel
... as it stands I don't even have an option to force the environment to stop / delete the service and recreate it / know when I can actually test that the production deployment worked.
It takes 40-60 minutes to deploy 8 web instances. I don't understand why it takes lineally more time to deploy more instances. Shouldn't each instance start up in parallel?
Specifically when attempting to deploy and an instance fails to load because something is missing or an error in the init code. It can take up to 2 hours (or what seems about 120-150 automatic restarts) before you can reload up again. A way to cancel this would be excellent!
May I suggest you take a look at Cloud Storage Studio especially the subscriptions management component of it. It is implemented using Service Management API. There are few things that I would like to mention here:
1. Because it is a client side utility, you can circumvent the normal "browser timeout" issues you may run into when deploying very large packages (50 MB+).
2. Recently we added a feature where create deployment is a one step process, instead of regular two step process:... more
Hi,
May I suggest you take a look at Cloud Storage Studio especially the subscriptions management component of it. It is implemented using Service Management API. There are few things that I would like to mention here:
1. Because it is a client side utility, you can circumvent the normal "browser timeout" issues you may run into when deploying very large packages (50 MB+).
2. Recently we added a feature where create deployment is a one step process, instead of regular two step process: Deploy and Run. Now while creating a deployment, you can instruct Cloud Storage Studio to automatically start your application after deployment is done.
It's common for us to encounter problems with a deployment "getting stuck" -- which involves the deployed unit being unusable for several hours. Often times this behavior is caused by developer error due to missing libraries or misconfiguration Nonetheless, we upload a new version of our product three to five times a week and our instance becomes 'stuck' at least once a week. I feel it is very important that work is done to improve the consistency and quality of the deployment process.
I would like to expand this request to include an way to cancel a deployment.
I accidentally deployed my application using the configuration for the development environment. Azure took several hours to settle down just to get to the point where I could then stop and delete the instance from running.
I realized my mistake several seconds after I hit the deploy button. However I then had to wait quite a long time until Azure allowed me to correct my mistake. I would like a way to cancel the request ... more
I would like to expand this request to include an way to cancel a deployment.
I accidentally deployed my application using the configuration for the development environment. Azure took several hours to settle down just to get to the point where I could then stop and delete the instance from running.
I realized my mistake several seconds after I hit the deploy button. However I then had to wait quite a long time until Azure allowed me to correct my mistake. I would like a way to cancel the request to deploy a webrole.
To summarize, what is being asked for in this thread:
1) Ability to update individual files (including web config) in a running app
2) One click deploy option to reduce the "babysitting"
3) Notification of when the app is up and running
4) Speed up the time to deploy
5) Instant promotion to production w/o downtime and severing existing connections
Does that cover it? Anything else related to improving deployment?
I would love to see "instant" promotion from staging to live as well ... having a potential 10 minute downtime to move a service live is a pretty poor end user experience if they hit the site at the wrong time... it should be possible to promote staging instances (or new live instances) while keeping the current live instances intact and then either on an instance by instance basis or big bang cut over to the newly spun up versions and spin down the old versions (dashboard should show status in... more
I would love to see "instant" promotion from staging to live as well ... having a potential 10 minute downtime to move a service live is a pretty poor end user experience if they hit the site at the wrong time... it should be possible to promote staging instances (or new live instances) while keeping the current live instances intact and then either on an instance by instance basis or big bang cut over to the newly spun up versions and spin down the old versions (dashboard should show status in real time with no refresh needed of course)
In a previous job we used to deploy changes 2-3 times a day because of the very dynamic nature of the project and to do that easily we stuck with classic ASP and non-compiled ASPX so we could replace individual files and replicate quickly to all front-ends ... while Azure seems to provide the ideal scalable platform (our usage would range from 10k to 6.5 million page impressions on any given day with the peak of traffic often happening in a matter of a couple of hours ... so 10 minutes off-air simply was unaccptable - we considered 5 minutes in any 13 week period to be a failure)
Hey Mike, if you guys are considering this "one-click" deployment, be sure you do as Joannes says and include a checkbox for the option.
We do not want to be forced into a "deployment-and-run" workflow. The option for this would of course be nice, but leave the existing workflow in there for the rest of us. I personally don't want my app to run right after I upload it. I would rather control when it actually starts up. There are some cases where we might know, "ok, in 2 hours ... more
Hey Mike, if you guys are considering this "one-click" deployment, be sure you do as Joannes says and include a checkbox for the option.
We do not want to be forced into a "deployment-and-run" workflow. The option for this would of course be nice, but leave the existing workflow in there for the rest of us. I personally don't want my app to run right after I upload it. I would rather control when it actually starts up. There are some cases where we might know, "ok, in 2 hours we are gonna need to get something up to handle the increased workload for the next 6 hours. Lets get it up on Azure and tested but lets not deploy it until we get to 1 hour before we need it". We have a few requirements that an autostart would violate within our deployment model.
I'm not opposed to having an option for "deploy-and-run", just don't force us to use it. give us the option.
Hi Shaun and Joannes, thanks for speling this out so clearly. I'll get with someone on the team that works on this particular part of Windows Azure and make sure they see your feedback (and I'll come back to you if there is any changes you can expect or if they have any additional questions for you so we can do this better in the future).
Hey Mike -- thank you for creating this public forum for feedback.
I'd like to throw in with Joannes. I find the click and wait and click wait again workflow to be undesirable. I understand the use case for uploading a deployment and not wanting it to go live, but there is a strong case to be made for upload and be done. That the entire process takes several minutes (1-2 min to delete, 1-2 min to deploy, and 10-min to start) raises some interesting questions about what is happening behind the sce... more
Hey Mike -- thank you for creating this public forum for feedback.
I'd like to throw in with Joannes. I find the click and wait and click wait again workflow to be undesirable. I understand the use case for uploading a deployment and not wanting it to go live, but there is a strong case to be made for upload and be done. That the entire process takes several minutes (1-2 min to delete, 1-2 min to deploy, and 10-min to start) raises some interesting questions about what is happening behind the scenes. i.e. Is there truly no optimization possible to expedite provisioning, deployment, and starting? A changed UI may help this experience but the ideal is to expedite the entire process from start to end.
The most annoying aspect of the manual deployment is that it can't be done in 1-clic plus delay. You have to upload (1min), then deploy (2min), then start (10min). Each time, it requires a click.
Typically, it does not match much sense to have to click "run" after uploading a new package. It would be much better if the upload form was a including a check box with "Run immediately after upload"
Eventually, a notification of some kind could be send (taskbar message?) when the app ... more
The most annoying aspect of the manual deployment is that it can't be done in 1-clic plus delay. You have to upload (1min), then deploy (2min), then start (10min). Each time, it requires a click.
Typically, it does not match much sense to have to click "run" after uploading a new package. It would be much better if the upload form was a including a check box with "Run immediately after upload"
Eventually, a notification of some kind could be send (taskbar message?) when the app is up and running.
I would love to see "strict managed .NET" deployment that would actually skip the whole VM deployment phase to deploy instead a limited sandboxed .NET environment. That way, deploy time could be trimmed down from minutes to seconds.
scheinkultur
I totally agree with Simon... This is by far the most important thing to improve... This would save any developer so much time...
Simon Francesco
Hi Mike,
I have spent at least a day going through the dozen or so causes of the dreaded initializing-busy-stopping loop. Basic diagnostics in this area are critical. At the moment this is a totally blind area. Ironically I have had to use an amazon 64 bit machine to help diagnose some of the issues and I still don't have a web role that will start yet.
A great option would be a console like feature as we see in the dev fabric that could tell us "BadImageFormatException" for xyz.dll, or fil... more
Hi Mike,
I have spent at least a day going through the dozen or so causes of the dreaded initializing-busy-stopping loop. Basic diagnostics in this area are critical. At the moment this is a totally blind area. Ironically I have had to use an amazon 64 bit machine to help diagnose some of the issues and I still don't have a web role that will start yet.
A great option would be a console like feature as we see in the dev fabric that could tell us "BadImageFormatException" for xyz.dll, or filenotfound nesteddependency.dll, incorrect storage connection string etc.
cmyworld
Major issue we face with Azure deployment is no support for partial updates to the package. Any small change made should be redeployed which itself takes 20-30 mins. Image in a web role just adding a link to a page or something such small requires us to deploy everything again :(
offbeatmammal
sitting here watching another deployment that's got as far as "Up" on a progress bar that says "Upgrading Domain 1 of 2" after an hour.... this is really painful.
please... give us:
(a) more visibility into what's actually going on
(b) an option to cancel
... as it stands I don't even have an option to force the environment to stop / delete the service and recreate it / know when I can actually test that the production deployment worked.
Rob Volk
It takes 40-60 minutes to deploy 8 web instances. I don't understand why it takes lineally more time to deploy more instances. Shouldn't each instance start up in parallel?
dsmithazure
Specifically when attempting to deploy and an instance fails to load because something is missing or an error in the init code. It can take up to 2 hours (or what seems about 120-150 automatic restarts) before you can reload up again. A way to cancel this would be excellent!
Gaurav Mantri
Hi,
May I suggest you take a look at Cloud Storage Studio especially the subscriptions management component of it. It is implemented using Service Management API. There are few things that I would like to mention here:
1. Because it is a client side utility, you can circumvent the normal "browser timeout" issues you may run into when deploying very large packages (50 MB+).
2. Recently we added a feature where create deployment is a one step process, instead of regular two step process:... more
Hi,
May I suggest you take a look at Cloud Storage Studio especially the subscriptions management component of it. It is implemented using Service Management API. There are few things that I would like to mention here:
1. Because it is a client side utility, you can circumvent the normal "browser timeout" issues you may run into when deploying very large packages (50 MB+).
2. Recently we added a feature where create deployment is a one step process, instead of regular two step process: Deploy and Run. Now while creating a deployment, you can instruct Cloud Storage Studio to automatically start your application after deployment is done.
To get more information and download, please visit our website: http://www.cerebrata.com/Products/CloudStorageStudio
Thanks
Gaurav Mantri
Cerebrata Software
ShaunT
It's common for us to encounter problems with a deployment "getting stuck" -- which involves the deployed unit being unusable for several hours. Often times this behavior is caused by developer error due to missing libraries or misconfiguration Nonetheless, we upload a new version of our product three to five times a week and our instance becomes 'stuck' at least once a week. I feel it is very important that work is done to improve the consistency and quality of the deployment process.
bob
And it is annoying that the UI claims it takes 96 seconds when it really takes 1/2 hour or more...
be789
Why is it currently so slow to deploy?
djaccb
I would like to expand this request to include an way to cancel a deployment.
I accidentally deployed my application using the configuration for the development environment. Azure took several hours to settle down just to get to the point where I could then stop and delete the instance from running.
I realized my mistake several seconds after I hit the deploy button. However I then had to wait quite a long time until Azure allowed me to correct my mistake. I would like a way to cancel the request ... more
I would like to expand this request to include an way to cancel a deployment.
I accidentally deployed my application using the configuration for the development environment. Azure took several hours to settle down just to get to the point where I could then stop and delete the instance from running.
I realized my mistake several seconds after I hit the deploy button. However I then had to wait quite a long time until Azure allowed me to correct my mistake. I would like a way to cancel the request to deploy a webrole.
Thanks,
Dave
Jim Nakashima
To summarize, what is being asked for in this thread:
1) Ability to update individual files (including web config) in a running app
2) One click deploy option to reduce the "babysitting"
3) Notification of when the app is up and running
4) Speed up the time to deploy
5) Instant promotion to production w/o downtime and severing existing connections
Does that cover it? Anything else related to improving deployment?
offbeatmammal
I would love to see "instant" promotion from staging to live as well ... having a potential 10 minute downtime to move a service live is a pretty poor end user experience if they hit the site at the wrong time... it should be possible to promote staging instances (or new live instances) while keeping the current live instances intact and then either on an instance by instance basis or big bang cut over to the newly spun up versions and spin down the old versions (dashboard should show status in... more
I would love to see "instant" promotion from staging to live as well ... having a potential 10 minute downtime to move a service live is a pretty poor end user experience if they hit the site at the wrong time... it should be possible to promote staging instances (or new live instances) while keeping the current live instances intact and then either on an instance by instance basis or big bang cut over to the newly spun up versions and spin down the old versions (dashboard should show status in real time with no refresh needed of course)
In a previous job we used to deploy changes 2-3 times a day because of the very dynamic nature of the project and to do that easily we stuck with classic ASP and non-compiled ASPX so we could replace individual files and replicate quickly to all front-ends ... while Azure seems to provide the ideal scalable platform (our usage would range from 10k to 6.5 million page impressions on any given day with the peak of traffic often happening in a matter of a couple of hours ... so 10 minutes off-air simply was unaccptable - we considered 5 minutes in any 13 week period to be a failure)
Phillip
Hey Mike, if you guys are considering this "one-click" deployment, be sure you do as Joannes says and include a checkbox for the option.
We do not want to be forced into a "deployment-and-run" workflow. The option for this would of course be nice, but leave the existing workflow in there for the rest of us. I personally don't want my app to run right after I upload it. I would rather control when it actually starts up. There are some cases where we might know, "ok, in 2 hours ... more
Hey Mike, if you guys are considering this "one-click" deployment, be sure you do as Joannes says and include a checkbox for the option.
We do not want to be forced into a "deployment-and-run" workflow. The option for this would of course be nice, but leave the existing workflow in there for the rest of us. I personally don't want my app to run right after I upload it. I would rather control when it actually starts up. There are some cases where we might know, "ok, in 2 hours we are gonna need to get something up to handle the increased workload for the next 6 hours. Lets get it up on Azure and tested but lets not deploy it until we get to 1 hour before we need it". We have a few requirements that an autostart would violate within our deployment model.
I'm not opposed to having an option for "deploy-and-run", just don't force us to use it. give us the option.
Mike Wickstrand
Hi Shaun and Joannes, thanks for speling this out so clearly. I'll get with someone on the team that works on this particular part of Windows Azure and make sure they see your feedback (and I'll come back to you if there is any changes you can expect or if they have any additional questions for you so we can do this better in the future).
Thanks again for engaging with us here, Mike
ShaunT
Hey Mike -- thank you for creating this public forum for feedback.
I'd like to throw in with Joannes. I find the click and wait and click wait again workflow to be undesirable. I understand the use case for uploading a deployment and not wanting it to go live, but there is a strong case to be made for upload and be done. That the entire process takes several minutes (1-2 min to delete, 1-2 min to deploy, and 10-min to start) raises some interesting questions about what is happening behind the sce... more
Hey Mike -- thank you for creating this public forum for feedback.
I'd like to throw in with Joannes. I find the click and wait and click wait again workflow to be undesirable. I understand the use case for uploading a deployment and not wanting it to go live, but there is a strong case to be made for upload and be done. That the entire process takes several minutes (1-2 min to delete, 1-2 min to deploy, and 10-min to start) raises some interesting questions about what is happening behind the scenes. i.e. Is there truly no optimization possible to expedite provisioning, deployment, and starting? A changed UI may help this experience but the ideal is to expedite the entire process from start to end.
Joannes Vermorel
The most annoying aspect of the manual deployment is that it can't be done in 1-clic plus delay. You have to upload (1min), then deploy (2min), then start (10min). Each time, it requires a click.
Typically, it does not match much sense to have to click "run" after uploading a new package. It would be much better if the upload form was a including a check box with "Run immediately after upload"
Eventually, a notification of some kind could be send (taskbar message?) when the app ... more
The most annoying aspect of the manual deployment is that it can't be done in 1-clic plus delay. You have to upload (1min), then deploy (2min), then start (10min). Each time, it requires a click.
Typically, it does not match much sense to have to click "run" after uploading a new package. It would be much better if the upload form was a including a check box with "Run immediately after upload"
Eventually, a notification of some kind could be send (taskbar message?) when the app is up and running.
ShaunT
It's like watching paint dry. It's the one aspect of Azure that I hate. Please speed up deployment.
mamby
is it possible to add files(static or code) to a running app? without redeploying the whole project
Joannes Vermorel
I would love to see "strict managed .NET" deployment that would actually skip the whole VM deployment phase to deploy instead a limited sandboxed .NET environment. That way, deploy time could be trimmed down from minutes to seconds.