Bug 1566527 - DHCP ports don't recreated after deleting them
Summary: DHCP ports don't recreated after deleting them
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Assaf Muller
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-12 13:14 UTC by Eran Kuris
Modified: 2019-09-09 16:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-21 13:58:38 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1764408 0 None None None 2018-04-16 13:25:01 UTC

Description Eran Kuris 2018-04-12 13:14:01 UTC
Description of problem:
When using delete port command to delete DHCP port the expected behavior is those ports will be recreated same as in Neutron ml2/ovs

Version-Release number of selected component (if applicable):
(overcloud) [root@controller-0 ~]# cat /etc/yum.repos.d/latest-installed 
13   -p 2018-04-03.3
(overcloud) [root@controller-0 ~]# rpm -qa | grep ovn 
openvswitch-ovn-central-2.9.0-15.el7fdp.x86_64
openvswitch-ovn-common-2.9.0-15.el7fdp.x86_64
python-networking-ovn-4.0.1-0.20180315174741.a57c70e.el7ost.noarch
openvswitch-ovn-host-2.9.0-15.el7fdp.x86_64
openstack-nova-novncproxy-17.0.2-0.20180323024604.0390d5f.el7ost.noarch
novnc-0.6.1-1.el7ost.noarch
python-networking-ovn-metadata-agent-4.0.1-0.20180315174741.a57c70e.el7ost.noarch
puppet-ovn-12.3.1-0.20180221062110.4b16f7c.el7ost.noarch
(overcloud) [root@controller-0 ~]# rpm -qa | grep openvs
openvswitch-ovn-central-2.9.0-15.el7fdp.x86_64
openvswitch-ovn-common-2.9.0-15.el7fdp.x86_64
openvswitch-2.9.0-15.el7fdp.x86_64
python-openvswitch-2.9.0-15.el7fdp.noarch
openvswitch-ovn-host-2.9.0-15.el7fdp.x86_64
openstack-neutron-openvswitch-12.0.1-0.20180327195360.68b8980.el7ost.noarch


How reproducible:
100%

Steps to Reproduce:
1.create network & subnet
2.boot vm 
3.delete the dhcp port that created for this network
4. check the port list the dhcp port did not create.

Actual results:


Expected results:


Additional info:

Comment 1 Assaf Muller 2018-04-16 12:24:14 UTC
This fails ROI, please open upstream, maybe someone in the community will work on it.

Comment 2 Eran Kuris 2018-04-30 06:00:02 UTC
I am opening this issue because of its effects on Metadata.
When deleting the DHCP port and it doesn't recreate, all instances that we boot would be booted without metadata. 
localhost login: root
Password: 
[root@localhost ~]# curl http://169.254.169.254/openstack
curl: (7) Failed connect to 169.254.169.254:80; No route to host

Comment 4 Eran Kuris 2018-04-30 06:03:12 UTC
step to reproduce 
1.create network & subnet
2.boot vm 
3. check it get metadata: curl http://169.254.169.254/openstack
4.delete the dhcp port that created for this network
5. check the port list the dhcp port did not create.
6.boot vm  the new vm  will not get metadata

Comment 5 Daniel Alvarez Sanchez 2018-04-30 06:51:51 UTC
Yes, this is right. We discussed it some time back and since only admin can do it, we agreed that we should do this work in the sync tool for OVN to cover also the scenario where for example someone has been using config drive and then enable metadata. Then they would run the sync tool and it will create all the necessary metadata ports for the existing networks (this would also recover the DHCP port that the admin deleted).
In the end, why an admin would delete a port that he has not created?
Sounds good?

Comment 6 Eran Kuris 2018-04-30 07:00:28 UTC
(In reply to Daniel Alvarez Sanchez from comment #5)
> Yes, this is right. We discussed it some time back and since only admin can
> do it, we agreed that we should do this work in the sync tool for OVN to
> cover also the scenario where for example someone has been using config
> drive and then enable metadata. Then they would run the sync tool and it
> will create all the necessary metadata ports for the existing networks (this
> would also recover the DHCP port that the admin deleted).
> In the end, why an admin would delete a port that he has not created?
> Sounds good?

I got your explanation. According to your question, why an admin would delete a port that he has not created?
its only by mistake and in that case I think the recreation DHCP port would be necessary here as we have in ml2/ovs.

Comment 7 Daniel Alvarez Sanchez 2018-04-30 07:03:50 UTC
(In reply to Eran Kuris from comment #6)
> (In reply to Daniel Alvarez Sanchez from comment #5)
> > Yes, this is right. We discussed it some time back and since only admin can
> > do it, we agreed that we should do this work in the sync tool for OVN to
> > cover also the scenario where for example someone has been using config
> > drive and then enable metadata. Then they would run the sync tool and it
> > will create all the necessary metadata ports for the existing networks (this
> > would also recover the DHCP port that the admin deleted).
> > In the end, why an admin would delete a port that he has not created?
> > Sounds good?
> 
> I got your explanation. According to your question, why an admin would
> delete a port that he has not created?
> its only by mistake and in that case I think the recreation DHCP port would
> be necessary here as we have in ml2/ovs.

Yes, it could happen my mistake as you said. Then admin could run the sync script to bring those back and also we could run it regularly.
If you feel this is still a concern maybe we can open a bug upstream and track it during the R cycle to see if we can prevent it from being deleted or create it right away.

Comment 8 Miguel Angel Ajo 2018-04-30 07:31:10 UTC
I agree we should track this from upstream, and eventually have a mechanism to re-create the port, may be even without the sync script, just by watching port deletions.

An administrator has an infinite amount of shooting himself on the foot, and we cannot prevent them all, this looks like Low priority at this moment.

We may try to get this handled for rocky:

https://bugs.launchpad.net/bugs/1764408

Comment 9 Miguel Angel Ajo 2018-04-30 07:32:40 UTC
Conscious self inflicted damage is far from "Flags: blocker?" !! IMHO

Comment 10 Daniel Alvarez Sanchez 2018-04-30 07:46:40 UTC
Yes, I think that it's be nice to have but definitely not a blocker and also we have ways to recover. When we first developed this feature we thought that we should have a mechanism to create/recreate the missing metadata ports on the existing networks and it was included in the sync tool.
However, as Miguel said, there's some other scenarios where an admin can make mistakes and we can't prevent (like delete a server, delete a FIP and make it unreachable, ...)

Comment 11 Assaf Muller 2018-05-21 13:58:38 UTC
We'll track this issue upstream, no need to track it as a Bugzilla.


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