bay-creation return 400 Bad Request with a valid fixed-network in baymodel

Bug #1519748 reported by HouMing Wang on 2015-11-25
This bug affects 3 people
Affects Status Importance Assigned to Milestone
In Progress
HouMing Wang

Bug Description

Reproduce steps:

1. Create a baymodel with a valid fixed network

[houming@bogon devstack]$ magnum baymodel-create --name swarmbaymodel --master-flavor-id m1.small --image-id fedora-21-atomic-5 --keypair-id testkey --fixed-network private --external-network-id public --dns-nameserver --flavor-id m1.small --docker-volume-size 5 --network-driver flannel --coe kubernetes
| Property | Value |
| http_proxy | None |
| updated_at | None |
| master_flavor_id | m1.small |
| ssh_authorized_key | None |
| uuid | a0bee59e-fbc4-4887-ac96-fe7409744cb6 |
| no_proxy | None |
| https_proxy | None |
| tls_disabled | False |
| keypair_id | testkey |
| public | False |
| labels | {} |
| docker_volume_size | 5 |
| server_type | vm |
| external_network_id | public |
| cluster_distro | fedora-atomic |
| image_id | fedora-21-atomic-5 |
| registry_enabled | False |
| apiserver_port | None |
| name | swarmbaymodel |
| created_at | 2015-11-25T09:55:21+00:00 |
| network_driver | flannel |
| fixed_network | private |
| coe | kubernetes |
| flavor_id | m1.small |
| dns_nameserver | |

2. Create a bay with this baymodel, 400 Bad Request returned:

[houming@bogon devstack]$ magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 2
ERROR: Bad Request (HTTP 400)

We can see an "InvalidParameterValue: ERROR: Property error: : : Error validating value 'private': Invalid net cidr invalid IPNetwork private" exception in m-cond.log:

2015-11-25 18:18:19.216 TRACE oslo_messaging.rpc.dispatcher File "/opt/stack/magnum/magnum/conductor/handlers/", line 137, in bay_create
2015-11-25 18:18:19.216 TRACE oslo_messaging.rpc.dispatcher raise exception.InvalidParameterValue(message=str(e))
2015-11-25 18:18:19.216 TRACE oslo_messaging.rpc.dispatcher InvalidParameterValue: ERROR: Property error: : : Error validating value 'private': Invalid net cidr invalid IPNetwork private
2015-11-25 18:18:19.216 TRACE oslo_messaging.rpc.dispatcher
2015-11-25 18:18:19.216 ERROR oslo_messaging._drivers.common [req-d79d79f7-b473-48a8-a97a-77f8b69b5a72 admin demo] Returning exception ERROR: Property error: : : Error validating value 'private': Invalid net cidr invalid IPNetwork private to caller
2015-11-25 18:18:19.216 ERROR oslo_messaging._drivers.common [req-d79d79f7-b473-48a8-a97a-77f8b69b5a72 admin demo] ['Traceback (most recent call last):\n', ' File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/", line 142, in _dispatch_and_reply\n executor_callback))\n', ' File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/", line 186, in _dispatch\n executor_callback)\n', ' File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/", line 129, in _do_dispatch\n result = func(ctxt, **new_args)\n', ' File "/opt/stack/magnum/magnum/conductor/handlers/", line 137, in bay_create\n raise exception.InvalidParameterValue(message=str(e))\n', "InvalidParameterValue: ERROR: Property error: : : Error validating value 'private': Invalid net cidr invalid IPNetwork private \n"]

In magnum.conductor.template_definition.BaseTemplateDefinition.__init__, we can see that bay model's 'fixed_network' is mapped to heat's 'fixed_network_cidr':

we should fix this to avoid bay-creation fails and misunderstanding.

Changed in magnum:
assignee: nobody → Hou Ming Wang (houming-wang)
description: updated
description: updated
HouMing Wang (houming-wang) wrote :

After this change,

The 'fixed_network' actually means 'fixed_network_cidr', or more precisely 'fixed_subnet'. There're 2 possible ways to fix this:

1. Rename the 'fixed_network' to 'fixed_subnet', in Baymodel DB, Baymodel Object and MagnumClient.

2. Leave 'fixed_network' alone, add a new field 'fixed_subnet' to Baymodel, and use the 'fixed_subnet' to take the place of current 'fixed_network'.

HouMing Wang (houming-wang) wrote :

From Kennan in the MailList:
Hi HouMing,
I checked the heat templates again, and check with heat developers.
For heat stack creation now, it can not directly use existed network when create new stack. which means, it need create a new net and subnet.
So for fixed_network, the name is still need. just like when you create network in neutron, you need network and subnet.

I think right now, so for magnum point of view what can be controlled is, 1. network name related properties settting. 2. subnetwork related properties. like CIDR.

So for fixed_network, give it still what role should be.

Add a new fixed_subnet for that.

Of course, this can also be discussed in weekly meeting if needed.

Fix proposed to branch: master

Changed in magnum:
status: New → In Progress

Change abandoned by Adrian Otto (<email address hidden>) on branch: master
Reason: I am marking this as abandoned due to inactivity. Please do un-abandon this patch, and resubmit a new patch set to address the issue with the merge conflict. Please let me know if there is anything I can do to help.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers