February 2019 - Starlingx-discuss

Re: [Starlingx-discuss] Gnocchi Test Cases
by Waheed, Numan 14 Feb '19

14 Feb '19

Hi Juan, I have posted Gnocchi test plan at the following shared drive. I hope you will find it helpful. https://drive.google.com/drive/folders/1nab5AW18HIxpbkjAR6-dwk-kt1rv_8HQ Thanks, Numan. From: Gomez, Juan P <juan.p.gomez(a)intel.com> Sent: February-13-19 12:33 PM To: Waheed, Numan <Numan.Waheed(a)windriver.com> Cc: Cabrales, Ada <ada.cabrales(a)intel.com> Subject: RE: Gnocchi Test Cases Hi Numan, Any update on this? Thanks, JP From: Gomez, Juan P Sent: Monday, February 11, 2019 5:08 PM To: Waheed, Numan <Numan.Waheed(a)windriver.com<mailto:Numan.Waheed@windriver.com>> Cc: Cabrales, Ada <ada.cabrales(a)intel.com<mailto:ada.cabrales@intel.com>> Subject: Gnocchi Test Cases Hi Numan, Could you give me a light for Gnocchi Test Cases? Is there any existing test cases that We can port to cover Gnocchi? Which components integrate Gnocchi? Is there any relation between Ceilometer and Gnocchi? Thanks and Best Regards, JP Juan Pablo Gomez Software Quality Assurance Engineer OTC Edge Computing

1 0

Re: [Starlingx-discuss] Starlingx-discuss Digest, Vol 9, Issue 54
by Kung, John 14 Feb '19

14 Feb '19

Marcel, controller-0 should be unlocked successfully for the first time before attempting to provision/configure controller-1 As noted, the presence of 'Error' logs on controller-0 (under directory /var/log/puppet ) would indicate the reason for the configuration failure (200.011). In regards to the OAM interface configured, please check 'system host-if-list -a controller-0' and 'system host-ethernet-port-list controller-0' to determine the current interface configuration. Furthermore, after the 'host-unlock controller-0', the configured OAM interface IP should be reachable from your OAM network 'system host-addr-list controller-0' to see the addresses allocated for that host. John ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Feb 2019 17:31:21 +0000 From: "Penney, Don" <Don.Penney(a)windriver.com> To: Marcel Schaible <marcel(a)schaible-consulting.de>, "starlingx-discuss(a)lists.starlingx.io" <starlingx-discuss(a)lists.starlingx.io> Subject: Re: [Starlingx-discuss] Duplex Configuration: Unlock of controller-0 causes reboot Message-ID: <6703202FD9FDFF4A8DA9ACF104AE129FBA43D2C9(a)ALA-MBD.corp.ad.wrs.com> Content-Type: text/plain; charset="utf-8" You'd need to look at the puppet log from the first reboot to see if some failure occurred there, or whether the reboot was triggered by a config change. I don't know if the configuration failure alarm is related to puppet or not. Given the OAM port alarm, you should double-check your OAM interface and configuration. Maybe John Kung has better advice on what to check... John? -----Original Message----- From: Marcel Schaible [mailto:marcel@schaible-consulting.de] Sent: Wednesday, February 13, 2019 12:27 PM To: Penney, Don; starlingx-discuss(a)lists.starlingx.io Subject: RE: [Starlingx-discuss] Duplex Configuration: Unlock of controller-0 causes reboot Ok. The latest puppet logs from controller-0 do not contain any errors. Should I try to install a newer image? > "Penney, Don" <Don.Penney(a)windriver.com> hat am 13. Februar 2019 um 18:20 geschrieben: > > > I would suggest checking the puppet logs for a failure.... grep for Error. The redundancy alarms are because you don't have controller-1 yet, and can be ignored. The port failure alarm is concerning, I think... maybe that's related to the configuration error. > > -----Original Message----- > From: Marcel Schaible [mailto:marcel@schaible-consulting.de] > Sent: Wednesday, February 13, 2019 12:18 PM > To: Penney, Don; starlingx-discuss(a)lists.starlingx.io > Subject: RE: [Starlingx-discuss] Duplex Configuration: Unlock of controller-0 causes reboot > > At the moment the system seems to stablize after 2 reboots. I'll keep an eye on that. > > Is the alarm list looking reasonable after the controller-0 is unlocked and rebooted? > If yes, I would start to configure the controller-1. > > > root@controller-0 ~(keystone_admin)]# fm alarm-list > +----------+-------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------+----------+----------------------------+ > | Alarm ID | Reason Text | Entity ID | Severity | Time Stamp | > +----------+-------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------+----------+----------------------------+ > | 200.011 | controller-0 experienced a configuration failure. | host=controller-0 | critical | 2019-02-13T18:57:13.772108 | > | 400.002 | Service group controller-services loss of redundancy; expected 1 standby member but no standby members available | service_domain=controller.service_group=controller-services | major | 2019-02-13T18:56:15.215083 | > | 400.002 | Service group vim-services loss of redundancy; expected 1 standby member but no standby members available | service_domain=controller.service_group=vim-services | major | 2019-02-13T18:56:15.174083 | > | 400.002 | Service group cloud-services loss of redundancy; expected 1 standby member but no standby members available | service_domain=controller.service_group=cloud-services | major | 2019-02-13T18:56:12.213065 | > | 400.002 | Service group oam-services loss of redundancy; expected 1 standby member but no standby members available | service_domain=controller.service_group=oam-services | major | 2019-02-13T18:56:05.330099 | > | 400.002 | Service group patching-services loss of redundancy; expected 1 standby member but no standby members available | service_domain=controller.service_group=patching-services | major | 2019-02-13T18:56:04.276424 | > | 400.002 | Service group directory-services loss of redundancy; expected 2 active members but only 1 active member available | service_domain=controller.service_group=directory-services | major | 2019-02-13T18:56:04.195081 | > | 400.002 | Service group web-services loss of redundancy; expected 2 active members but only 1 active member available | service_domain=controller.service_group=web-services | major | 2019-02-13T18:56:04.114064 | > | 400.005 | Communication failure detected with peer over port enp9s20f7 on host controller-0 | host=controller-0.network=mgmt | major | 2019-02-13T18:56:03.790070 | > | 100.106 | 'OAM' Port failed. | host=controller-0.port=cd202069-f5a0-43bb-a445-d3b9b58ce631 | major | 2019-02-13T18:56:00.563067 | > | 100.107 | 'OAM' Interface degraded. | host=controller-0.interface=oam | major | 2019-02-13T18:56:00.515836 | > | 300.004 | No enabled compute host with connectivity to provider network. | service=networking.providernet=e9eef26b-d266-4b3f-b1b7-6d9c2cd3a86b | major | 2019-02-13T17:20:21.110405 | > +----------+-------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------+----------+----------------------------+ > [root@controller-0 ~(keystone_admin)]# > > > > > "Penney, Don" <Don.Penney(a)windriver.com> hat am 13. Februar 2019 um 18:02 geschrieben: > > > > > > Ok, my updates related to the DRBD state change failures merged Feb 8th. > > > > I wouldn't expect to see an additional reboot. So what you're seeing, just to confirm, is: > > * install node, run config_controller, do config steps > > * system host-unlock controller-0 > > * system reboots > > * system reboots a second time? > > Yes, exactly. > > > > > At what point is it rebooting a second time? Maybe a reboot is being triggered due to config changes made when the puppet manifests apply, which I think we could confirm from the puppet logs. > > The second reboot starts in about 1 minute after the login prompt is shown. > > > > > > -----Original Message----- > > From: Marcel Schaible [mailto:marcel@schaible-consulting.de] > > Sent: Wednesday, February 13, 2019 11:48 AM > > To: Penney, Don; starlingx-discuss(a)lists.starlingx.io > > Subject: Re: [Starlingx-discuss] Duplex Configuration: Unlock of controller-0 causes reboot > > > > I am using the build centos-20190206T060000Z. > > > > The main problem, beside of the noise is, that the system comes up and reboots immediately again. > > > > > > > > > "Penney, Don" <Don.Penney(a)windriver.com> hat am 13. Februar 2019 um 17:41 geschrieben: > > > > > > > > > Yes, this is the correct behavior. > > > > > > As for the drbd warnings, there are some state change failures that occur as the system shuts down, but aren't a problem (aside from the noise). I've managed to clean up most of these in a recent update. What build are you using? > > > > > > -----Original Message----- > > > From: Marcel Schaible [mailto:marcel@schaible-consulting.de] > > > Sent: Wednesday, February 13, 2019 11:28 AM > > > To: starlingx-discuss(a)lists.starlingx.io > > > Subject: [Starlingx-discuss] Duplex Configuration: Unlock of controller-0 causes reboot > > > > > > Hi, > > > > > > when I unlock the controller-0 after installation following this tutorial > > > > > > https://docs.starlingx.io/installation_guide/duplex.html#duplex > > > > > > the system is rebooting automatically with a lot of errors from drdb. > > > > > > Controller-1 is not configured at this point in time. > > > > > > Must I configure the secondary controller before unlocking controller-0? > > > > > > Thanks > > > > > > Marcel > > > > > > _______________________________________________ > > > Starlingx-discuss mailing list > > > Starlingx-discuss(a)lists.starlingx.io > > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > > > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss(a)lists.starlingx.io > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

2 1

[Starlingx-discuss] STX ovs containerization
by Li, Cheng1 14 Feb '19

14 Feb '19

Hi Matt, Joseph, I have updated the patch per your comments. https://review.openstack.org/633924 Regarding per-host overrides of network information( network -> auto_bridge_add), seems openstack-helm doesn't support it. I prefer to leave auto_bridge_add scope as it is until openstack-helm support per-host overrides of network info. If that, we need add nic to bridge by hand, instead of initContainer. I believe Joseph is trying to find an approach for auto_bridge_add, let's waiting for the result. Thanks, Cheng

1 0

[Starlingx-discuss] [docs][meetings] docs team meeting minutes 2/13/2019
by Tullis, Michael L 13 Feb '19

13 Feb '19

For notes and new action items from our docs team meeting today, see our etherpad: https://etherpad.openstack.org/p/stx-documentation Join us if you have interest in StarlingX docs! We meet Wednesdays, and call logistics are here: https://wiki.openstack.org/wiki/Starlingx/Meetings. -- Mike

1 0

[Starlingx-discuss] [build-report] STX_build_master_pike - Build # 138 - Failure!
by build.starlingx＠gmail.com 13 Feb '19

13 Feb '19

Project: STX_build_master_pike Build #: 138 Status: Failure Timestamp: 20190213T213623Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190213T21… -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS: true

1 0

[Starlingx-discuss] [build-report] STX_build_docker_images - Build # 46 - Failure!
by build.starlingx＠gmail.com 13 Feb '19

13 Feb '19

Project: STX_build_docker_images Build #: 46 Status: Failure Timestamp: 20190214T000721Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190213T21… -------------------------------------------------------------------------------- Parameters BRANCH: master MY_WORKSPACE: /localdisk/loadbuild/jenkins/master/20190213T213623Z OS: centos MUNGED_BRANCH: master MY_REPO: /localdisk/designer/jenkins/master/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190213T21… PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/20190213T213623Z/logs MY_REPO_ROOT: /localdisk/designer/jenkins/master PUBLISH_DISTRO_BASE: /export/mirror/starlingx/master/centos PUBLISH_TIMESTAMP: 20190213T213623Z DOCKER_BUILD_ID: jenkins-master-20190213T213623Z-builder OPENSTACK_RELEASE: pike TIMESTAMP: 20190213T213623Z OS_VERSION: 7.5.1804 PUBLISH_INPUTS_BASE: /export/mirror/starlingx/master/centos/20190213T213623Z/inputs PUBLISH_OUTPUTS_BASE: /export/mirror/starlingx/master/centos/20190213T213623Z/outputs

1 0

[Starlingx-discuss] [build-report] STX_build_wheels - Build # 46 - Failure!
by build.starlingx＠gmail.com 13 Feb '19

13 Feb '19

Project: STX_build_wheels Build #: 46 Status: Failure Timestamp: 20190214T000905Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190213T21… -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master/20190213T213623Z OS: centos MY_REPO: /localdisk/designer/jenkins/master/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190213T21… OPENSTACK_RELEASE: pike OS_VERSION: 7.5.1804 PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/20190213T213623Z/logs

1 0

[Starlingx-discuss] [build][meetings] Build team meeting agenda 2/14/2019
by Lara, Cesar 13 Feb '19

13 Feb '19

Build team meeting Agenda for 2/14/2019 - Cengn update - CVE scan integration - Opens Regards Cesar Lara Software Engineering Manager OpenSource Technology Center

1 0

[Starlingx-discuss] Open Infrastructure Summit and PTG planning
by Ildiko Vancsa 13 Feb '19

13 Feb '19

Hi StarlingX Community, As we are getting closer to the Open Infrastructure Summit it is time to start to think about planning for the working sessions such as the Forum and PTG. The first priority at this point is the Forum as the session proposal phase opens on February 22. You can find the full timeline here: https://wiki.openstack.org/wiki/Forum I created an etherpad to brainstorm about topics to cover so we don’t have duplications when we submit session ideas: https://etherpad.openstack.org/p/stx-forum-preparation-denver-2019 Our team is currently working on scheduling for the PTG which will happen right after the Summit. You can see in a previous email the teams who applied for space which information we can use when we plan cross-project sessions: http://lists.starlingx.io/pipermail/starlingx-discuss/2019-February/003057.… I created another etherpad to plan PTG topics as we get closer to the event: https://etherpad.openstack.org/p/stx-ptg-preparation-denver-2019 Please let me know if you have any questions. Thanks and Best Regards, Ildikó

2 1

[Starlingx-discuss] build-pkgs behavior: packages always compile
by Ruiz Garcia, Felipe De Jesus 13 Feb '19

13 Feb '19

Hi Scott I am working on the bug 1804687<https://bugs.launchpad.net/starlingx/+bug/1804687>, and I have realized that some packages are rebuilt when "build-pkgs" is executed even if the package does not have new changes. The packages mentioned are: sm-common-debuginfo-1.0.0-20.tis.x86_64.rpm sm-common-dev-1.0.0-20.tis.x86_64.rpm sm-common-libs-1.0.0-20.tis.x86_64.rpm sm-eru-1.0.0-20.tis.x86_64.rpm sm-common-1.0.0-20.tis.src.rpm sm-common-1.0.0-20.tis.x86_64.rpm build-info-1.0-4.tis.src.rpm build-info-1.0-4.tis.x86_64.rpm build-info-dev-1.0-4.tis.x86_64.rpm Is this behavior a bug? otherwise why are those packages built every time if they have the same version? Note: The fix for the bug is ready for review https://review.openstack.org/#/c/634513/ Regards Felipe Ruiz / Pipo / Tranzemc Before anything else, preparation is the key to success. ( Alexander Graham Bell )

3 2