projectkudu / slingshot

This project implements the Deploy To Azure button
http://azure.microsoft.com/blog/2014/11/13/deploy-to-azure-button-for-azure-websites-2/
51 stars 20 forks source link

Resource Group Created in US East #36

Open MicahZoltu opened 9 years ago

MicahZoltu commented 9 years ago

In an attempt to deploy to an existing resource group, I entered the name of a resource group I have in US West. I set the website to deploy to US West and when I tried to deploy (step 3) I received the following error:

Invalid resource group location 'East US'. The Resource group already exists in location 'westus'.

I'm uncertain whether it is possible to deploy to an existing resource group or not, but it definitely seems like a bug that it tried to create the resource group in East US when I specifically told it to put the website in US West.

MicahZoltu commented 9 years ago

The following seems incredibly relevant: https://github.com/projectkudu/slingshot/blob/5f54e9c9aba92051c4b4b55c0334b9cc074e6ea0/Slingshot.Api/Controllers/ARMController.cs#L110-L112

resourceResult = await client.ResourceGroups.CreateOrUpdateAsync(tempRGName, new BasicResourceGroup { Location = "East US" });

// For now we just default to East US for the resource group location.
davidebbo commented 9 years ago

It probably should first check if the RG exists, and just use it if it does. If it doesn't, ideally we'd use site location, but defaulting to East US is not a big deal. In the end, the location of the RG is not that relevant, as it can contain a mix of resources in other regions anyway.

patrickebates commented 9 years ago

Had a user of ours reach out to me in the last 24 hours reporting this exact same issue, though he claims that the RG being in a different datacenter eventually caused him problems to the point that he had to abandon the deployment and start over without using our Deploy To Azure button. (Is it possible that it became this serious?)

davidebbo commented 9 years ago

Are these cases where you are deliberately using the existing RG name, or is this accidental?

patrickebates commented 9 years ago

Must be accidental in our case. I'm not aware that we can specify anything in our JSON file to control the RG being created.

For reference... https://github.com/ProjectNami/projectnami/blob/master/azuredeploy.json

davidebbo commented 9 years ago

Right, the json never specifies the resource group.

MicahZoltu commented 9 years ago

In my case, I was intentionally trying to deploy to an existing resource group. I am paying for a Basic WebSites instance in a US-West Resource Group and I wanted to add this site to that resource group by default so it could hopefully go into my existing Basic WebSites instance.

It is possible that I could have deployed to a resource group in US-East, then just transferred the WebSite to the Basic instance (and therefore the Resource Group) but I didn't get far enough to find out due to the above error (gave up after hitting error).

Also, I like keeping my Azure portal nice and clean, which means not a ton of random resource groups everywhere.

davidebbo commented 9 years ago

Understood. Maybe it would make sense to offer a dropdown of existing RGs as an option for those who don't want to create a new one.

patrickebates commented 9 years ago

Heard back from our user. He claims that the Azure portal would not let him add additional services (such as Storage) to the RG created in East US if it was in a different datacenter.

Having some trouble working with the controller. Does that "parameters" object have the datacenter for the deployment available at the time the RG is created? If so, could that be used to set up the RG?

davidebbo commented 9 years ago

Sorry, I'm not sure I quite understand that last question. As I see it, we should do two things:

patrickebates commented 9 years ago

Your second point is what I was getting at. I was just trying to fix it myself in a fork, but having trouble with the controller and couldn't verify if the selected datacenter value was available at the time the RG is created.

Is there a setting we can include in our JSON file to allow selecting an existing RG as you describe in the first point? I've not seen any examples of working with the RG at all.

davidebbo commented 9 years ago

Oh, I didn't realize you were working in changes on a fork.

No, at this time selecting an existing RG is not supported, that's another thins we'd need to code up.

patrickebates commented 9 years ago

I gave up, as MVC is not part of my skillset. Plus I couldn't get the project to start up properly using the instructions in the ReadMe. Kept getting redirected to what appeared to be the live, production instance after logging in.

I'll wait for your solutions to this. Thanks for your work on this project, it's made deployments very simple for those just wanting to kick the tires on our offering, as well as those looking to go to production.

davidebbo commented 9 years ago

So @Tuesdaysgreen and I just played around with the Preview Portal, and we're not seeing the restriction you mentioned above. i.e. we were able to create a RG containing two sites in different regions, as well as a storage account in yet a third region. And that's how it's supposed to work. RGs are general containers for many resources that can be all over the place.

patrickebates commented 9 years ago

I've asked the end user to confirm once again exactly what he was seeing. I'll let you know what feedback I get. But I was able to duplicate what you describe just now.