Jump to: navigation, search

Difference between revisions of "StarlingX/Packet SIG"

m (Problem Tracking)
m (Problem Tracking)
Line 37: Line 37:
  
 
==== Problem Tracking ====
 
==== Problem Tracking ====
 
+
<br />
 
'''Problems Found with Packet.com:''' <br />
 
'''Problems Found with Packet.com:''' <br />
 
* Multi-cast Packets appear to be dropped by Packet.com switches
 
* Multi-cast Packets appear to be dropped by Packet.com switches

Revision as of 16:49, 5 July 2019

Packet SIG

Packet.com is a baremetal public cloud, and they have donated some resources to the StarlingX project. The resources are available under the STX-PROJECT-01 project on Packet.com.


StarlingX Distributed Cloud on Packet.Com

As a demonstration of the OpenStack Edge Computing Group's Distributed Control Plane MVP Architecture, StarlingX Distributed Cloud has been deployed on Packet.com.

STX R1 : http://mirror.starlingx.cengn.ca/mirror/starlingx/release/2018.10/centos/2018.10.0/outputs/iso/

Horizon for Central Cloud: http://147.75.105.202
SSH to Central Cloud: ssh wrsroot@147.75.105.202


Packet.com Servers deployed

Packet-servers.png

Networking

Networking.png

Installing the Central Cloud

Blah, blah, blah.

Installing the Sub Clouds

Blah, blah, blah.

Problem Tracking


Problems Found with Packet.com:

  • Multi-cast Packets appear to be dropped by Packet.com switches
    • Results in StartingX Maintenance reporting a false alarm that it has lost connectivity with other nodes in the StarlingX Cloud. E.g. In Central Cloud, cc-controller-0 claims that it has a heartbeat audit failure with cc-controller-1.
    • WORKAROUND: Change maintenance's heartbeat failure behaviour to simply raise an alarm ... rather than declare the node as failed and reset the node.
system service-parameter-list
system service-parameter-modify platform maintenance heartbeat_failure_action=alarm
system service-parameter-apply platform
  • On some interfaces, packets between 1400 and 1500 bytes were dropped by packet.com switch, even though MTU of Interface was 1500 bytes.
    • WORKAROUND: set all MTUs to 1400 bytes


Problems Found with StarlingX R1.0:

  • config_subcloud would fail if prior to running the command on controller-0 of the subcloud, the mgmt interface was already configured and there were any unreachable DNS servers configured in /etc/resolv.conf
    • WORKAROUND: ifdown <mgmt-if-dev> and vi /etc/resolv.conf and remove all DNS Server entries
  • HORIZON subcloud 'managed' would fail with some error about JSON
    • WORKAROUND: Use CLI to set subcloud to managed