When setting up ONAP on vanilla Openstack, we did not pay too much attention to the project where the stack was created in. Later, in a second environment, I wanted to keep the ONAP stack in a project on its own. This seems to be easy by providing the openstack_tenant_id parameter in the HEAT environment file. Indeed, this brings up the stack in a project called "ONAP" in our case. What did not work was to bring up the vFW instances of the Stack created by VID into ONAP. They insisted to be created in the "admin" project and seemed not to be able to communicate with other ONAP VMs via the ecomp network.
It took a while to understand why the admin project was chosen after we made sure that there was no reference to the admin project in any config file or HEAT template or anywhere else in the ONAP VMs. With one exception, which is in the robot-vm after applying a patch to keystone_get_auth.template as described in https://wiki.onap.org/display/DW/Run+demo.sh+on+vanilla+Openstack. To retrieve the tenantId, the request to keystone needs to contain the tenant name and this was set since the first successful startup of ONAP to "admin".
Re-creating the stack was not an option for us, so we needed to change the template in the robot-vm.
Trying to change the value from "admin" to "ONAP" does not show an immediate result, after as /opt/demo.sh init on robot-vm we were not longer able to select an LCP region when creating a Virtual Network Function in VID.
We assumed that demo.sh has created some inconsistencies between AAI and VID (or in AAI) and deleting and restarting of AAI containers (we still use the one VM version of AAI) solved this issue at the expense of loosing a couple of other items.
After an additional demo.sh init, we could successfully create a vFW stack in the same project as our core VMs of ONAP run.
