Resource Group Created in US East

[MicahZoltu]

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]

The following seems incredibly relevant:

slingshot/Slingshot.Api/Controllers/ARMController.cs

Lines 110 to 112 in 5f54e9c

	resourceResult = await client.ResourceGroups.CreateOrUpdateAsync(tempRGName, new BasicResourceGroup { Location = "East US" });
	// For now we just default to East US for the resource group location.

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]

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]

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]

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

[patrickebates]

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]

Right, the json never specifies the resource group.

[MicahZoltu]

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]

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]

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]

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

• if the RG already exists, we should default to that region for additional resources
• if it doesn't exist, then we should create the RG in the same region as what the user selects for the site

[patrickebates]

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]

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]

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]

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]

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.