yahoo-eng-team team mailing list archive

[Frode Nordahl <1946456@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

The 'enable-chassis-as-gw' CMS option allows the operator to influence
where L3 routers and HA Chassis Groups for external ports are scheduled.

When no chassis has the option set all chassis will be eligible for
scheduling of L3 gateways [0].

This is a powerful concept, and it gives operators fine grained control
when needed, and lets the system decide when the fine grained control is
not needed.

However, this logic is not applied for HA Chassis Groups for use with
the external port for servicing of SR-IOV instances.  If no chassis has
the 'enable-chassis-as-gw' option set, no HA Chassis Group for use with
external ports are created, and subsequently SR-IOV instances will not
be serviced for DHCP or Metadata.

While I understand the desire to require the use of the 'enable-chassis-
as-gw' option and the simplification of the code that entails, it does
introduce a unexpected difference in behavior from the scheduling of L3
gateways as documented in [0].  It also removes some of the power of the
option.

For example, when you have a deployment in a L3-only DC fabric and do
not use features such as EVPN, you most likely want to schedule gateways
only to chassis in physical vicinity of your border gateways.  If you
have a deployment in a L3-only DC fabric with EVPN, you would most
likely not care where the gateways are scheduled and would like the
system to schedule the gateways for you.  Other deployment scenarios are
where you have a set of hypervisors you for some reason don't want any
centralized services scheduled to them.

The current behavior of the HA Chassis Group scheduling only caters for
the latter of the above scenarios, and makes it more cumbersome for the
user to support the two former.

Would it be more consistent if Neutron chose among all chassis when no
chassis has the 'enable-chassis-as-gw' option set also for the HA
Chassis Group for external port feature?

0:
https://docs.openstack.org/neutron/latest/admin/ovn/routing.html#l3ha-
support

** 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/1946456

Title:
  Scheduling of HA Chassis Group for external port does not work when no
  chassis has 'enable-chassis-as-gw' option set

Status in neutron:
  New

Bug description:
  The 'enable-chassis-as-gw' CMS option allows the operator to influence
  where L3 routers and HA Chassis Groups for external ports are
  scheduled.

  When no chassis has the option set all chassis will be eligible for
  scheduling of L3 gateways [0].

  This is a powerful concept, and it gives operators fine grained
  control when needed, and lets the system decide when the fine grained
  control is not needed.

  However, this logic is not applied for HA Chassis Groups for use with
  the external port for servicing of SR-IOV instances.  If no chassis
  has the 'enable-chassis-as-gw' option set, no HA Chassis Group for use
  with external ports are created, and subsequently SR-IOV instances
  will not be serviced for DHCP or Metadata.

  While I understand the desire to require the use of the 'enable-
  chassis-as-gw' option and the simplification of the code that entails,
  it does introduce a unexpected difference in behavior from the
  scheduling of L3 gateways as documented in [0].  It also removes some
  of the power of the option.

  For example, when you have a deployment in a L3-only DC fabric and do
  not use features such as EVPN, you most likely want to schedule
  gateways only to chassis in physical vicinity of your border gateways.
  If you have a deployment in a L3-only DC fabric with EVPN, you would
  most likely not care where the gateways are scheduled and would like
  the system to schedule the gateways for you.  Other deployment
  scenarios are where you have a set of hypervisors you for some reason
  don't want any centralized services scheduled to them.

  The current behavior of the HA Chassis Group scheduling only caters
  for the latter of the above scenarios, and makes it more cumbersome
  for the user to support the two former.

  Would it be more consistent if Neutron chose among all chassis when no
  chassis has the 'enable-chassis-as-gw' option set also for the HA
  Chassis Group for external port feature?

  0:
  https://docs.openstack.org/neutron/latest/admin/ovn/routing.html#l3ha-
  support

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