Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1654861 - [v2v][osp] OpenStack instance always gets `default` security group
Summary: [v2v][osp] OpenStack instance always gets `default` security group
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: V2V
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: GA
: 5.10.0
Assignee: Brett Thurber
QA Contact: Kedar Kulkarni
Red Hat CloudForms Documentation
URL:
Whiteboard: v2v
Depends On: 1668049 1668791
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-29 20:47 UTC by Kedar Kulkarni
Modified: 2019-02-12 16:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-12 16:49:20 UTC
Category: ---
Cloudforms Team: V2V
Target Upstream Version:


Attachments (Terms of Use)

Description Kedar Kulkarni 2018-11-29 20:47:11 UTC
Description of problem:
When migrating Vmware to OSP, if I have selected a security group different from `default` during migration plan creation, migrated instance still gets the default security group. 

Version-Release number of selected component (if applicable):
5.10.0.27

How reproducible:
Believe 100%

Steps to Reproduce:
1.Configure the OSP and VMware provider for migration
2.Create Infra mapping and Migration plan(select security group different than `default` while creating plan)
3.Execute plan

Actual results:
Migration plan finishes and if you check the security group assigned to OSP instance it is `default` even if I had selected different security group

Expected results:
Security group should be assigned correctly.

Additional info:
Looking at the snippet from wrapper logs below, I can see security group a8ed95a2-ecd1-4790-b98f-481bf472a902(this was the one I selected) was assigned but when checked the instance in Horizon UI I could see it was not assigned, `default` was assigned which has a different uuid. 

2018-11-29 15:30:42,308:DEBUG: Volume at index 1 has id='b5421f99-9d31-47fe-8b8e-de94a92d86cc' (virt-v2v-wrapper:899)
2018-11-29 15:30:57,327:INFO: virt-v2v terminated with return code 0 (virt-v2v-wrapper:1031)
2018-11-29 15:30:57,329:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/
v3', u'--os-project-name=migration', u'--os-password=*****', 'token', 'issue'], environment: {} (virt-v2v-wrapper:1123)
2018-11-29 15:31:03,322:INFO: Transfering volume: b5421f99-9d31-47fe-8b8e-de94a92d86cc (virt-v2v-wrapper:217)
2018-11-29 15:31:03,323:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/
v3', u'--os-project-name=migration', u'--os-password=*****', 'volume', 'transfer', 'request', 'create', '--format', 'json', u'b5421f99-9d31-47fe-8b8e-de94a92d86cc'], environment: {} (virt-v2v-wrapper:1123)
2018-11-29 15:31:10,641:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'volume', 'transfer', 'request', 'accept', '--auth-key', u'3d81a6a0b5d22a3c', u'ca4c6055-7afc-4c09-a565-7bd76d8ee44f'], environment: {} (virt-v2v-wrapper:1123)
2018-11-29 15:31:17,934:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'port', 'create', '--format', 'json', '--network', u'1b39625c-221e-4aad-ace3-a09685ac2634', '--mac-address', u'00:50:56:a5:01:2e', '--enable', u'env-ubuntu16.04-tpl_port_0', '--fixed-ip', u'ip-address=10.19.2.89'], environment: {} (virt-v2v-wrapper:1123)
2018-11-29 15:31:25,511:INFO: Created port id=5a72dab2-312d-40e3-a304-0c8684f7d5aa (virt-v2v-wrapper:255)
2018-11-29 15:31:25,512:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'server', 'create', '--flavor', u'c2fd118e-0cc1-4997-932b-e2f420369335', '--security-group', u'a8ed95a2-ecd1-4790-b98f-481bf472a902', '--volume', u'b5421f99-9d31-47fe-8b8e-de94a92d86cc', '--nic', u'port-id=5a72dab2-312d-40e3-a304-0c8684f7d5aa', u'env-ubuntu16.04-tpl'], environment: {} (virt-v2v-wrapper:1123)
2018-11-29 15:31:36,620:INFO: Removing password files (virt-v2v-wrapper:1350)
2018-11-29 15:31:36,621:INFO: Finished (virt-v2v-wrapper:1372)
(END)

Comment 2 Fabien Dupont 2018-11-30 16:24:14 UTC
In my tests, I also saw that behavior when using the command line. Apparently, when you create an instance with a pre-created port, the security groups are those of the network port, even though you specify another one. So, the fix would probably be to set the security group on the port.

Comment 6 Nenad Peric 2018-12-03 17:02:53 UTC
Yes the security groups are tied to the network which is connected to the host. 
So it makes sense that the port which gets attached to the instance overrides the security groups before it. 
I will try and do some lab tests around this as well though.

Comment 10 Kedar Kulkarni 2019-01-24 16:52:34 UTC
With 
CFME 5.10.0.32
ovirt-ansible-v2v-conversion-host-1.9.1-1.el7ev.noarch
virt-v2v-1.38.2-12.28.lp.el7ev.x86_64
# Wrapper version
VERSION = "12"


I was able to successfully migrate an Instance and assign it other than `default` security group, during migration plan wizard, which then was correctly assigned to migrated instance.


Note You need to log in before you can comment on or make changes to this bug.