Salt-Cloud not using networks config from provider

34 views
Skip to first unread message

Brian Lanier

unread,
Nov 16, 2021, 1:07:38 PM11/16/21
to Salt-users
I apologize in advance if I just can't see the obvious, but I have poured through documentation, code etc and can't find an answer to this problem. It has bothered me for several years and from time to time I try to fix and then I give up and just continue with work arounds.

I have a provider setup for hosting at Rackspace. I am trying to provision servers and have a private network added to the hosts, but it never works. The config I have now at least does not error out, but doesn't add the hosts.
This wasn't working on my old salt master running 2019.2 nor my current salt master running 3004.
The servers provision fine, minus the network, including the rackspace monitoring setup with default checks. I have to leave the host talking on one of the other networks to get a connection, setup the network manually in the RackSpace control panel, and then run the highstate after to complete the initial build.

I figure it must be how I am defining the config since it hasn't worked across various versions. I have tried using the name as provided by the list_networks command instead of the id. I have tried various formatting but those usually end up with errors about syntax. The syntax seems to match what is shown in the os_client_config module documentation:  https://docs.openstack.org/os-client-config/latest/user/network-config.html. It also seems to match other examples I have seen with people having other issues related to provisioning servers, but not the networks part.

Hoping someone can help me figure out what I am missing.

Current config with sensitive values redacted:
my--rackspace:
  driver: openstack
  profile: rackspace
  ssh_key_name: saltcloud
  ssh_key_file: /root/.ssh/id_rsa_salt

  region_name: ORD
  auth_type: rackspace_apikey

  auth:
    username: some...@example.com
    tenant: 123456
    api_key: 123123123123123

  protocol: ipv4

meta:
    build_config: core,monitoring_defaults

  wait_for_metadata:
    rax_service_level_automation: Complete

  networks:
    - name: 22222222-2222-2222-2222-222222222222 # private net
    - name: 00000000-0000-0000-0000-000000000000 # RS public net
    - name: 11111111-1111-1111-1111-111111111111 # RS service net

Thanks
Brian

Phipps, Thomas

unread,
Nov 16, 2021, 2:31:20 PM11/16/21
to salt-...@googlegroups.com

it is network not networks, also it is just a list of the networks that the minion needs to attach to directly.

my--rackspace:
  driver: openstack
  profile: rackspace
  ssh_key_name: saltcloud
  ssh_key_file: /root/.ssh/id_rsa_salt

  region_name: ORD
  auth_type: rackspace_apikey
  auth:
    username: some...@example.com

    tenant: 123456
    api_key: 123123123123123
  protocol: ipv4
  meta:
      build_config: core,monitoring_defaults
  wait_for_metadata:
      rax_service_level_automation: Complete
  network:
    - 22222222-2222-2222-2222-222222222222 # private net
    - 00000000-0000-0000-0000-000000000000 # RS public net
    - 11111111-1111-1111-1111-111111111111 # RS service net

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/b8d7d482-f63f-41e1-b56a-d2c9c2494c9bn%40googlegroups.com.

Brian Lanier

unread,
Nov 22, 2021, 2:07:23 PM11/22/21
to salt-...@googlegroups.com
Thanks Thomas,
I got it working, but not exactly the way you mentioned. But you did force me to go down the rabbit hole and dig through the code more than I have before. See below for the trail I followed.

That was one of the incarnations I had tried that didn't give a syntax error, but it does give an error. I modified the network block to what you had in your example and get the following output/error:
The following virtual machines are set to be created:
  stage.apps-n5_test

Proceed? [N/y] y
... proceeding
[ERROR   ] Error creating server stage.apps-n5_test: Network ['22222222-2222-2222-2222-222222222222', '00000000-0000-0000-0000-000000000000', '11111111-1111-1111-1111-111111111111'] is not a valid network in defaults:ORD
[ERROR   ] There was a query error: 'NoneType' object is not iterable

I did verify that the actual network id I am using is the network id in the RackSpace control panel. It is a network that has existed for years and I add to every server, but I have had to do that manually since switching to the openstack driver from the old nova driver. I also verified that the id is returned when I run salt-cloud -f list_networks my--rackspace

Where I get confused is when I see in the docs at https://docs.saltproject.io/en/master/ref/clouds/all/salt.cloud.clouds.openstack.html#module-salt.cloud.clouds.openstack to use the network keyword, but then it also says it is using the os-client-config methods which indicate in the examples that my original setup should work... which does not give me syntax errors, but also does not add the network to my provisioned server: https://docs.openstack.org/os-client-config/latest/user/network-config.html

I finally dug deep into the create_server code and saw the following block...

        if network and ('nics' not in kwargs or not kwargs['nics']):
            nics = []
            if not isinstance(network, list):
                network = [network]
            for net_name in network:
                if isinstance(net_name, dict) and 'id' in net_name:
                    network_obj = net_name
                else:
                    network_obj = self.get_network(name_or_id=net_name)
                if not network_obj:
                    raise exc.OpenStackCloudException(
                        'Network {network} is not a valid network in'
                        ' {cloud}:{region}'.format(
                            network=network,
                            cloud=self.name, region=self.region_name))

This is clearly where my error came from, but I noticed that it was looking for a list and then checked to see if each list item was a dict or not. But the important thing is that it was looking for it to be a dict AND have 'id' in the dict. The os_client_config had always said you could use name or id. So I combined the network keyword with the use of 'id' and I was able to provision my server with the network showing up.

Final block looked like:
  network:
    - id: 22222222-2222-2222-2222-222222222222 # private net
    - id: 00000000-0000-0000-0000-000000000000 # RS public net
    - id: 11111111-1111-1111-1111-111111111111 # RS service net

This seems to be working. I appreciate the pointer in the right direction. I don't know why it didn't work as just a regular list. Maybe since the two default networks I have include don't get returned from the list networks command, it errors on doing the get_network.... I don't know... I just know it is working for me now.

Brian
Reply all
Reply to author
Forward
0 new messages