January 2019 - Starlingx-discuss

[Starlingx-discuss] No MultiOS meeting next week
by Jones, Bruce E 11 Jan '19

11 Jan '19

We will not hold the MultiOS call next week. Many of the attendees will be on airplanes at the time. Amd most other StarlingX calls are also cancelled next week due to the community meetup in Chandler. brucej

1 0

Re: [Starlingx-discuss] What is the function of patches directory in StarlingX source code
by Liu, Changcheng 10 Jan '19

10 Jan '19

Hi AI & Bin, Does sm_patch.py make effect when installing the ISO image or it makes effect to apply all the patches when building the source code? Specifically, what's below patch used for? Could I remove it from source code directly? cgcs-root/stx/stx-ha/service-mgmt/sm-db-1.0.0/patches/sm_db_ceph_install.patch I'm removing ceph-rest-api from source code and replace it with other service. The above patch define some service realted with ceph-rest-api. I don't know whether I need change that patch file. B.R. Changcheng From: Bailey, Henry Albert (Al) [mailto:Al.Bailey@windriver.com] Sent: Monday, January 7, 2019 9:50 PM To: Liu, Changcheng <changcheng.liu(a)intel.com>; starlingx-discuss(a)lists.starlingx.io Cc: Qian, Bin <Bin.Qian(a)windriver.com> Subject: RE: [Starlingx-discuss] What is the function of patches directory in StarlingX source code I believe the contents of that folder are installed into a patches folder, and acted upon by the sm-patch utility https://github.com/openstack/stx-ha/blob/master/service-mgmt-tools/sm-tools… It looks like they populate "V1" tables. Bin should be able to indicate if we still make use of the V1 tables or not. Al From: Liu, Changcheng [mailto:changcheng.liu@intel.com] Sent: Sunday, January 06, 2019 10:57 PM To: starlingx-discuss(a)lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] What is the function of patches directory in StarlingX source code Hi all, What's the function of patches directory in StartlingX source code? For example: cgcs-root/stx/stx-ha/service-mgmt/sm-db-1.0.0/patches/sm_db_ceph_install.patch Regards, Changcheng

3 6

[Starlingx-discuss] Sanity Test - ISO 20190110
by Alonso, Juan Carlos 10 Jan '19

10 Jan '19

Status of the Sanity Test for last CENGN ISO: bootimage.iso from 2019-Jan-10 (link<http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190110T06…>) Sanity Test is executed in a Virtual Environment Status: GREEN Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity 18 TCs [PASS] TOTAL: [ 23 TCs PASS ] Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity 19 TCs [PASS] TOTAL: [ 24 TCs PASS ] Multinode Controller Storage Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity 19 TCs [PASS] TOTAL: [ 24 TCs PASS ] Multinode Dedicated Storage Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity 19 TCs [PASS] TOTAL: [ 24 TCs PASS ] ------------------------------------------------------------------ Regards. Juan Carlos Alonso

1 0

[Starlingx-discuss] Minutes: StarlingX Networking Meeting - 01/10
by Khalil, Ghada 10 Jan '19

10 Jan '19

Meeting minutes/agenda are captured at: https://etherpad.openstack.org/p/stx-networking Team Meeting Agenda/Notes - Jan 10/2019 * Patch upstreaming: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD… * Summary: ? Network Segment Range: 2 patches merged / 6 more to go -- making progress on the rest ? 0077-api-reject-routes-with-invalid-network-val.patch (6ed8fe6) -- merged ? 0040-rpc-removing-timeout-backoff-multiplier.patch (2e4ca00) -- ready to merge ? 0092-l3-add-l2pop-support-for-floatingip-resources.patch (9f926a5) -- Lots of discussion in the community; requiring lots of effort to follow up. Agreed to abandon l2pop RFE since the primary use-case is BGP EVPN which is not a priority for STX at this time. * Containerized OVS * SB: https://storyboard.openstack.org/#!/story/2004649 * Prime: Huifeng and Cheng * Already setup the standard openstack-helm w/ OVS successfully * Next working on setting up the STX containerized environment following the wiki * Then planning to look at the code changes in the STX repo's. * AR: Ghada to give Joseph a heads up regarding questions. * Code changes are expected in the override charts * OVS-DPDK firewall * SB: https://storyboard.openstack.org/#!/story/2002944 * Prime: Kailun * Setup STX environment with 1 controller and 2 computes. Also setup * Matt sent the * OVS Process Monitoring / Alarming * SB: https://storyboard.openstack.org/#!/story/2002947 * Prime: Intel TBD ? Not assigned yet as resources are not available. Will re-visit in 2 weeks. * Configurable vswitch memory - OVS-DPDK Jumbo Frame Support * SB: https://storyboard.openstack.org/#!/story/2004472 * Prime: Steve Webster * Making good progress; expect to have gerrit reviews out this week. Regards, Ghada

1 0

[Starlingx-discuss] [build-report] email-test - Build # 26 - Failure!
by build.starlingx＠gmail.com 10 Jan '19

10 Jan '19

Project: email-test Build #: 26 Status: Failure Timestamp: 20190110T165053Z Check attached log for details. -------------------------------------------------------------------------------- Parameters P1: foo P2: bar

2 7

[Starlingx-discuss] test email, please ignore
by build starlingx 10 Jan '19

10 Jan '19

test2

1 1

Re: [Starlingx-discuss] Need input on patch 4ae5a58 & 88b7bc7 upstreaming
by Peters, Matt 10 Jan '19

10 Jan '19

Hi Chenjie, Thanks for sending this email. See my responses inline. I have also added the starlingx-discuss mailing list to this reply so that the community can add additional comments or considerations. The reply to the RFE’s can be something like the following: This RFE is specific to the Neutron BGP-EVPN use-case which is currently not being pursued for upstreaming from the corresponding starlingx-staging projects (stx-neutron-dynamic-routing and stx-networking-bgpvpn). Therefore, until this feature is required, and an attempt is made to have it accepted by the OpenStack community, this feature cannot be used as a justification for this RFE. This RFE is being abandoned and can be revived if the BGP-EVPN feature becomes a priority. From: "Xu, Chenjie" <chenjie.xu(a)intel.com> Date: Thursday, January 10, 2019 at 11:54 AM To: "Peters, Matt" <Matt.Peters(a)windriver.com> Cc: Ghada Khalil <Ghada.Khalil(a)windriver.com>, "Zhao, Forrest" <forrest.zhao(a)intel.com> Subject: Need input on patch 4ae5a58 & 88b7bc7 upstreaming Hi Matt, There are 3 RFEs related to BGPVPN and one of them has been abandoned by today’s meeting. The abandoned RFE’s (9f926a5) link is below (we can call it RFE floatingIP): https://bugs.launchpad.net/neutron/+bug/1803494 MP> As discussed, we should abandon this RFE. We also need to ensure that we respond to the launchpad with the reasoning for the abandonment. Another RFE (4ae5a58) https://bugs.launchpad.net/neutron/+bug/1793653 we can call it RFE l2pop. RFE l2pop has been discussed on Neutron Driver Meeting for several times, and they think RFE l2pop lacks approved use cases. There are two potential use cases: BGPVPN and RFE floatingIP. The community of BGPVPN is not active and RFE l2pop has been pending on Thomas Morin’s input for a long time (Thomas leads the networking-bgpvpn project). Because RFE floatingIP has been abandoned and BGPVPN got no input, could you please provide another use case in Neutron to help the community accept this RFE? What’s more, another concern of community is that it’s hard to test the feature related to BGPVPN and I don’t have a BGPVPN environment to test this RFE either. MP> I agree that this is related and is only valid within the BGP-EVPN use-case. It should be abandoned also with the same justification. The RFE (88b7bc7) https://bugs.launchpad.net/neutron/+bug/1806316 we can call it RFE BgpDrAgent. Though RFE BgpDrAgent has not been triaged by Neutron team, I think it will face the same problem as RFE l2pop. Neutron team may think this RFE lacks approved use case. This RFE only has one use case which is neutron-dynamic-routing. I asked Ryan Tidwell who leads the neutron-dynamic-routing project to review this RFE and for now pending on his input. Could you please provide another use case in Neutron to help the community accept this RFE? MP> At the moment we do not have an alternate use-case for this change. It should be abandoned also with the same justification. Best Regards, Xu, Chenjie

1 0

[Starlingx-discuss] test e-mail, please ignore
by Scott Little 10 Jan '19

10 Jan '19

test

1 0

Re: [Starlingx-discuss] CENGN Mirror Robustness
by Young, Ken 10 Jan '19

10 Jan '19

Team, We are still working through some integration issues with moving the mirror to the kubernetes cluster. We will not be switching over on Monday, Jan 14th. We are working on revising our timelines. I will update the community when I have better visibility. Regards, Ken Y From: Ken Young <Ken.Young(a)windriver.com> Date: Friday, January 4, 2019 at 1:49 PM To: starlingx <starlingx-discuss(a)lists.starlingx.io> Cc: Raymond Maika <raymond.maika(a)cengn.ca> Subject: [Starlingx-discuss] CENGN Mirror Robustness All, We are working on a plan to make the Mirror more robust for the community as a whole. In co-operation with CENGN, we are moving the mirror from the current bare metal server to a kubernetes container with a CEPH backend. From a community perspective, we are expecting to have the transition to be seamless. We are sending the email from an awareness perspective. The current timeline we are targeting is: * Have the environment ready by Jan 8th * Perform testing in parallel with the existing and the new environment until Jan 11th * Transition to the new implementation of the mirror on Jan 14th. We are planning to maintain the current environment in case we need to switch back to the existing implementation. We will keep you in the loop as we progress towards this transition. Regards, Ken Y

1 0

[Starlingx-discuss] Questions about patch fd6cfc upstreaming
by Qin, Kailun 10 Jan '19

10 Jan '19

Hi Matt, I'm working on the patch fd6cfc upstreaming, which tries to address the stale RPC message issue when DHCP agent restarting up. The patch was in good shape https://review.openstack.org/609463/ whereas the neutron community was questioning about the exact failure modes of this issue. The DHCP agent will have a full sync after the agent restarting up (https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.p…) what kind of corner cases and negative behaviors could happen even w/ this full sync? Based on the commit message, I tried to reproduce this issue w/ the following steps: 1. schedule network1 to agent1. 2. turn down agent1 at almost the same time. 3. network1 is rescheduled to agent2 after finding that agent1 is dead. 4. turn up agent1, expecting stale RPC messages to be received by agent1 so that both agent1 and agent2 are servicing network1. However, I can only meet the described failure mode by sending another scheduling operation (network1->agent1) after step 2) is done. For the others, they seem to work as expected. Would you please kindly help provide more details about the failure pattern of this issue and/or the reproduction steps? Thanks a lot. BR, Kailun

2 11