Comment 9 for bug 1327406

Revision history for this message
Mike Spreitzer (mike-spreitzer) wrote :

I suppose I am not sure where the problem really is.

Let's start with the intent for the installation done by DevStack. Consider that one and only network created by DevStack for nova networking. Is that network:

(1) initially in a strange mode where it is intended for use only by admin users, awaiting dedication to some ordinary project,

or

(2) initially in a state where it is intended for use by every user?

Put another way, this is a Nova question: when network's project_id is null in the database, does this mean the network is hiding or does it mean the network should be visible to all tenants?

I guessed the answer is (2), for a number of reasons. One is that the alternative means DevStack has created an installation that is not ready for use by any but administrative users, which seems bad. Another reason is that (2) is supported by experiment. When I set my OS_ envars to user and project being demo, `nova boot ... --nic net-id=${id of that network}` succeeds in creating a VM. Also the `nova` commands to list and examine networks mostly expose that network; the one exception is `nova net private` (which is an exception even when authenticating as admin/admin).

Finally, and transitionally, (1) would imply that there is a booby trap in DevStack+Heat. Note that I could create both a new-style and an old-style autoscaling group, and can scale up and down the old-style one, and can scale down the new-style one. In none of that did I get any hint that I had done something wrong. But when I tried to scale up the new-style group, it failed. Should that really be the behavior in the nova networking environment produced by DevStack?