[Yahoo-eng-team] [Bug 1867869] [NEW] [OVN] Remove dependency on fip_object

2020-03-17 Thread zhanghao 
Public bug reported:

The 'update_floatingip' and 'delete_floatingip' method currently depend
on ‘fip_object’, which was added to keep things backward compatible.

Currently, the 'fip_id' has been stored in the 'external_ids' of NAT,
original fip can be obtained from 'ovn_fip', so 'fip_object' can be
removed.


https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L1074
https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L1112

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1867869

Title:
  [OVN] Remove dependency on fip_object

Status in neutron:
  New

Bug description:
  The 'update_floatingip' and 'delete_floatingip' method currently
  depend on ‘fip_object’, which was added to keep things backward
  compatible.

  Currently, the 'fip_id' has been stored in the 'external_ids' of NAT,
  original fip can be obtained from 'ovn_fip', so 'fip_object' can be
  removed.

  
  
https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L1074
  
https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L1112

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1867869/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1860164] Re: cloud-init generates a traceback if a default route already exists during ephemeral network setup

2020-03-17 Thread Launchpad Bug Tracker 
[Expired for cloud-init because there has been no activity for 60 days.]

** Changed in: cloud-init
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1860164

Title:
  cloud-init generates a traceback if a default route already exists
  during ephemeral network setup

Status in cloud-init:
  Expired

Bug description:
  If a route already exists when the ephemeral network exists cloud-init
  will generate the following traceback:

  2020-01-16 21:14:22,584 - util.py[DEBUG]: Getting data from  failed
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 
760, in find_source
  if s.update_metadata([EventType.BOOT_NEW_INSTANCE]):
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 
649, in update_metadata
  result = self.get_data()
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 
273, in get_data
  return_value = self._get_data()
File 
"/usr/lib/python2.7/site-packages/cloudinit/sources/DataSourceOracle.py", line 
195, in _get_data
  with dhcp.EphemeralDHCPv4(net.find_fallback_nic()):
File "/usr/lib/python2.7/site-packages/cloudinit/net/dhcp.py", line 57, in 
__enter__
  return self.obtain_lease()
File "/usr/lib/python2.7/site-packages/cloudinit/net/dhcp.py", line 109, in 
obtain_lease
  ephipv4.__enter__()
File "/usr/lib/python2.7/site-packages/cloudinit/net/__init__.py", line 
920, in __enter__
  self._bringup_static_routes()
File "/usr/lib/python2.7/site-packages/cloudinit/net/__init__.py", line 
974, in _bringup_static_routes
  ['dev', self.interface], capture=True)
File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 2083, in 
subp
  cmd=args)
  ProcessExecutionError: Unexpected error while running command.

  This is a regression from 19.1 on SUSE where exiting routes were
  simply skipped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1860164/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1867840] [NEW] os-flavor-access API policy should be admin only

2020-03-17 Thread Ghanshyam Mann 
Public bug reported:

os-flavor-access API policy is default to admin_or_owner[1] but API is
allowed for everyone.

This is because API does not pass the server project_id in policy target
- 
https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/flavor_access.py#L45

and if no target is passed then, policy.py add the default targets which is 
nothing but context.project_id (allow for everyone try to access)
- 
https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191

I do not think there is owner things for flavor as multiple tenant can
be added to access the flavor. I think we should default this policy to
admin only and admin only should be able to list all the tenants who has
access to specific flavor.

[1]
- 
https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/policies/flavor_access.py#L49

** Affects: nova
 Importance: Undecided
 Assignee: Ghanshyam Mann (ghanshyammann)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1867840

Title:
  os-flavor-access  API policy should be admin only

Status in OpenStack Compute (nova):
  New

Bug description:
  os-flavor-access API policy is default to admin_or_owner[1] but API is
  allowed for everyone.

  This is because API does not pass the server project_id in policy target
  - 
https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/flavor_access.py#L45

  and if no target is passed then, policy.py add the default targets which is 
nothing but context.project_id (allow for everyone try to access)
  - 
https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191

  I do not think there is owner things for flavor as multiple tenant can
  be added to access the flavor. I think we should default this policy
  to admin only and admin only should be able to list all the tenants
  who has access to specific flavor.

  [1]
  - 
https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/policies/flavor_access.py#L49

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1867840/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1864225] Re: IP allocation for stateless IPv6 does not filter on segment when fixed-ips contain a subnet_id

2020-03-17 Thread OpenStack Infra 
Reviewed:  https://review.opendev.org/709444
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=7e09e72661b0b3a0f898c20d451e204aa7a17194
Submitter: Zuul
Branch:master

commit 7e09e72661b0b3a0f898c20d451e204aa7a17194
Author: Harald Jensås 
Date:   Thu Feb 27 02:38:13 2020 +0100

Filter subnets on fixed_ips segment

For v6_stateless IP addresses for all stateless
subnets within a network are implicitly included.

When using segments implicitly allocating addresses
across subnets on different segments is incorrect.
IPs from subnets on differnt segments was allocated
when no host binding information was available
but a subnet_id in fixed_ips request was present.

This change adds filtering based on segment_id when
fixed_ips are used. If fixed_ips are not all on the
same segment exception FixedIpsSubnetsNotOnSameSegment
is raised.

Related: rhbz#1803989
Related-Bug: #1864333
Related-Bug: #1865138
Closes-Bug: #1864225
Change-Id: I336ae76283f29dd226344fb454aaa0e4aac030ea


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1864225

Title:
  IP allocation for stateless IPv6 does not filter on segment when
  fixed-ips contain a subnet_id

Status in neutron:
  Fix Released

Bug description:
  Network 45b993b2-5224-409e-9756-0be190a19cf5 with two segments and two
  subnets:

  $ openstack network segment list --network provider -f yaml
  - ID: 612f96f0-7682-49f7-bfc2-c52437f6e948
Name: provider-segment1
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Network Type: flat
Segment: null
  - ID: 9632dc77-d8d1-4d2b-afab-23568f1d475f
Name: provider-segment2
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Network Type: flat
Segment: null

  $ openstack subnet list --network provider -f yaml
  - ID: 926269c1-b05e-4b48-bafe-6be8e9cbd12c
Name: provider-subnet1
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Subnet: dead:beef:1::/64
  - ID: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91
Name: provider-subnet2
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Subnet: dead:beef:2::/64

  $ openstack subnet show -c segment_id -c ipv6_address_mode \
  -c ipv6_ra_mode -c address_mode provider-subnet1
  +---+--+
  | Field | Value|
  +---+--+
  | ipv6_address_mode | dhcpv6-stateless |
  | ipv6_ra_mode  | dhcpv6-stateless |
  | segment_id| 612f96f0-7682-49f7-bfc2-c52437f6e948 |
  +---+--+

  $ openstack subnet show -c segment_id -c ipv6_address_mode \
  -c ipv6_ra_mode -c address_mode provider-subnet2
  +---+--+
  | Field | Value|
  +---+--+
  | ipv6_address_mode | dhcpv6-stateless |
  | ipv6_ra_mode  | dhcpv6-stateless |
  | segment_id| 9632dc77-d8d1-4d2b-afab-23568f1d475f |
  +---+--+

  
  The two subnets have stateless address mode and are on different segments.

  When creating port, openstack port create --network provider test-
  port1 ip allocation is deffered because segments are used and no host
  id is provided.

  When creating a port with a subnet specified in fixed-ips the implicit
  address allocation for stateless subnets will allocate an address in
  both subnets.

  $ openstack port create --network provider \
--fixed-ip=subnet=provider-subnet1 test-port1 \
-c fixed_ips -f yaml
  fixed_ips:
  - ip_address: dead:beef:1:0:f816:3eff:fe9f:4907
subnet_id: 926269c1-b05e-4b48-bafe-6be8e9cbd12c
  - ip_address: dead:beef:2:0:f816:3eff:fe9f:4907
subnet_id: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91

  
  Upon trying to bind this port later as part of provisioning with Ironic, this 
fails because fixed_ips included invalid subnet.
  ---
  Failed to provision instance 3340fad9-93a6-4915-a87f-5f79cb647e03: Failed to 
prepare to deploy: Unable to set binding:host_id for neutron port 
c83d24aa-4167-4d37-9d1a-833290d55d83. Error: Invalid input for operation: 
Failed to create port on network 94543fd0-3a89-4d15-ad0c-ee1da99a63a4, because 
fixed_ips included invalid subnet 9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56
  ---

  This happens because all subnets are returned as candidates when fixed_ips is 
specified, despite that host id is not included:
  
https://opendev.org/openstack/neutron/src/branch/master/neutron/objects/subnet.py#L330-L337
  Then addresses for all stateless subnets in the candidates are allocated:

[Yahoo-eng-team] [Bug 1866160] Re: Update security group failed with the same stateful data

2020-03-17 Thread OpenStack Infra 
Reviewed:  https://review.opendev.org/711385
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=2b56e60140dd07f24fd8f1adf08ae8b213cea4ca
Submitter: Zuul
Branch:master

commit 2b56e60140dd07f24fd8f1adf08ae8b213cea4ca
Author: Lina He 
Date:   Thu Mar 5 06:07:29 2020 +

Unblock security group update with same stateful data

Closes-Bug: #1866160
Blueprint: stateless-security-groups

Change-Id: I46d80a2a4f114a6775827ab3caa61dee9f5f1361


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1866160

Title:
  Update security group failed with the same stateful data

Status in neutron:
  Fix Released

Bug description:
  With the merge of the stateless support
  patchset(https://review.opendev.org/#/c/572767/48).

  We found a failing scenario that the stateful configuration can't be
  updated when updating with the same stateful configuration.

  To reproduce:
  - Create a security group with stateful False(True)
  - Add this security group to the port
  - Update the security group to be stateful False(True)

  The update will fail because the security group is used by the port.

  The security groups should be updatable with the same stateful data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1866160/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1866087] Re: [OVN Octavia Provider] Deleting of listener fails

2020-03-17 Thread OpenStack Infra 
Reviewed:  https://review.opendev.org/711244
Committed: 
https://git.openstack.org/cgit/openstack/ovn-octavia-provider/commit/?id=af2b26afe68645e33e2fb7e14e8afe6c7bc2063c
Submitter: Zuul
Branch:master

commit af2b26afe68645e33e2fb7e14e8afe6c7bc2063c
Author: Maciej JJózefczyk 
Date:   Wed Mar 4 15:03:15 2020 +

Do not try to refresh vips on OVN LB that will be deleted

When there are multiple listeners with different protocols
configured on OVN LB, and one of listeners needs to be deleted,
there is no need to refresh vips on given OVN LB.
If there are no listners withing same protocol left the given OVN
LB could be deleted and there is no need to refresh vips then.

Change-Id: If15f817617facade10005878c8dfc7f467ce75a9
Closes-Bug: 1866087


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1866087

Title:
  [OVN Octavia Provider] Deleting of listener fails

Status in neutron:
  Fix Released

Bug description:
  Sometimes, while removing a listener the command fails with log below.

  The problem has been recently found on OVN octavia provider gate.

  
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]: 
DEBUG ovsdbapp.backend.ovs_idl.transaction [-] Running txn n=1 command(idx=0): 
DbRemoveCommand(table=Load_Balancer, 
record=86c3b5dc-5ec7-48c0-9fe7-d67fc78ef084, co
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]: 
DEBUG ovsdbapp.backend.ovs_idl.transaction [-] Running txn n=1 command(idx=1): 
LbDelCommand(lb=86c3b5dc-5ec7-48c0-9fe7-d67fc78ef084, vip=None, 
if_exists=False) {{(
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]: 
DEBUG ovsdbapp.backend.ovs_idl.transaction [-] Running txn n=1 command(idx=2): 
DbClearCommand(table=Load_Balancer, 
record=86c3b5dc-5ec7-48c0-9fe7-d67fc78ef084, col
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]: 
ERROR ovsdbapp.backend.ovs_idl.transaction [-] Traceback (most recent call 
last):
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/connection.py",
 line 122, in run
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  txn.results.put(txn.do_commit())
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/transaction.py",
 line 86, in do_commit
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  command.run_idl(txn)
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/command.py", 
line 182, in run_idl
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  record = self.api.lookup(self.table, self.record)
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/__init__.py", 
line 107, in lookup
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  return self._lookup(table, record)
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/__init__.py", 
line 151, in _lookup
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  row = idlutils.row_by_value(self, rl.table, rl.column, record)
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
File 
"/usr/local/lib/python3.6/dist-packages/ovsdbapp/backend/ovs_idl/idlutils.py", 
line 65, in row_by_value
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]:   
  raise RowNotFound(table=table, col=column, match=match)
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]: 
ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Load_Balancer with 
name=86c3b5dc-5ec7-48c0-9fe7-d67fc78ef084
  Mar 04 14:44:18 mjozefcz-ovn-provider-master devstack@o-api.service[30146]

  
  Looks like in this situation the LB had multiple protocols configured (TCP 
and UDP). While removing fist listener from the LB the one of created OVN LB 
rows needs to be deleted, but then driver wants to update the vip entries on 
it. That is not needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1866087/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp