Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure virtual network should support resource group #3089

Closed
RichardKnop opened this issue Aug 27, 2015 · 4 comments
Closed

Azure virtual network should support resource group #3089

RichardKnop opened this issue Aug 27, 2015 · 4 comments

Comments

@RichardKnop
Copy link

It should be possible to specify a resource group when defining a network.

For instance:

resource "azure_virtual_network" "bastion" {
  name = "foo-bastion-network"
  address_space = ["${var.virtual_network_cidr}"]
  location = "West Europe"

  subnet {
    name = "foo-bastion-subnet"
    address_prefix = "${var.bastion_cidr}"
  }
}

Should also support parameter resource_group_name just as you are able to do with Azure CLI tool:

azure resource create some_resource_group ...
@keymon
Copy link
Contributor

keymon commented Aug 27, 2015

+1

We need to create the network to use it later by other provisioner (Azure BOSH CPI for cloufoundry).

That provisioner expects the network to be in a specific resource group.

Currently we workaround it by creating the network manually with azure cli.

azure config mode arm
azure resource create \
    ${resource_group_name} \
    ${network_name} \
    Microsoft.Network/virtualNetworks \
    'West Europe' 2015-05-01-preview \
    -p "{\"addressSpace\": {\"addressPrefixes\": [\"${network_cidr}\"]},\"subnets\": [{\"name\": \"${subnet_name}\",\"properties\" : { \"addressPrefix\": \"${subnet_cidr}\"}}]}"

Ofc, if the network is created in a customised resource group, the instances created with azure_instance should be able to find that network. Maybe this requires more changes (we will add other request for that).

One solution could be parametrise the azure provider with the default resource group for all the created objects.

keymon added a commit to alphagov/paas-alpha-cf-terraform that referenced this issue Aug 28, 2015
Terraform does not support create public IPs, so we need to use the
azure client for the time being.

We will need a public IP for microbosh to be able to contact it
meanwhile we create it in a different network than the bastion host [due
the limitations in
terraform](hashicorp/terraform#3089)
keymon added a commit to alphagov/paas-alpha-cf-terraform that referenced this issue Aug 28, 2015
Due having the bastion and microbosh in different networks ([see reported bug in terraform](hashicorp/terraform#3089)) we need to be able to specify a public ip for microbosh.

This commit expects the user to manually create the ip with `azure/azure-create-public-ip.sh` and pass it to terraform as argument: `-var bosh_public_ip=65.52.132.211`
@aznashwan
Copy link
Contributor

@RichardKnop @keymon: the initial implementation of the Azure provider used the bindings for the old ASM-based API's; as those were sadly the only ones available at the time. As a result; a lot of features seem to be missing when in fact they were plain and simply not available in the API used by the go sdk at the time.

The transition to using the new ARM-based sdk has already been set in motion. Please feel free to track/chip into the discussion here: #3212

@tombuildsstuff
Copy link
Contributor

👋 hi @RichardKnop / @keymon / @aznashwan

Taking a look into this issue - from what I can see this issue's actually related to AzureRM, rather than Azure Service Management - as it doesn't appear to be possible to set the resource group for a Virtual Network created via Service Management?

Support for Virtual Networks with a resource group has been included in the Terraform AzureRM Provider for a while now - and as such I think this issue can be closed?

Please feel free to re-open this issue if that's not the case :)

Thanks!

@ghost
Copy link

ghost commented Apr 14, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants