May 2019 - Starlingx-discuss - lists.starlingx.io

[Starlingx-discuss] Minutes: StarlingX Release Meeting - May 9/2019
by Khalil, Ghada 10 May '19

10 May '19

Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases Release meeting agenda / notes May 9 2019 - PTG & TSC Re-cap regarding the next stx release - Consensus is to do time-based releases - twice a year with a 6wk LAG to openstack release - No anchor features moving forward - Optional bug releases were also discussed and agreed that they would be done as needed - Exact process / logistics is TBD - Given this, the next release for stx (stx.3.0) would be first week of December based on the train release - https://releases.openstack.org/train/schedule.html - This would allow us to get back on a cadence aligned with the openstack releases - It also means the time-frame between stx.2.0 & stx.3.0 will be shorter than 6 months and there will be overlap between the two releases - Next step is to define milestones for stx.3.0 - Action: Ghada/Bruce to start spreadsheet on google docs - Location: https://drive.google.com/drive/folders/1PlR4ndrYTF_8-5iJKjr0kiVjkehabZNT - Release Candidate List was reviewed in the Denver PTG: - https://etherpad.openstack.org/p/stx-ptg-agenda - The TSC is looking to push down the decision of release content down to the release team and the larger community - stx.2.0 Release Update Went through items on release plan line-by-line (didn't get a chance to cover the test items) https://docs.google.com/spreadsheets/d/1HUwbsaSerzFRuvXVB_qvoGdI0Chx1YiiA2W…

1 0

[Starlingx-discuss] [Containers] Sanity Test - ISO 20190509
by Alonso, Juan Carlos 09 May '19

09 May '19

Status of the Sanity Test for last CENGN ISO: bootimage.iso from 2019-May-09 (link<http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190509T01…>) Status: RED =========================================== Sanity Test is executed in a Containers - Bare Metal Environment AIO - Simplex Setup 03 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 26 TCs [PASS] | 02 TCs FAIL | 21 TCs BLOCK Sanity Platform 04 TCs [PASS] | 03 TCs FAIL TOTAL: [ 34 TCs PASS | 05 TCs FAIL | 21 TCs BLOCK ] AIO - Duplex Setup 03 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 26 TCs [PASS] | 02 TCs FAIL | 21 TCs BLOCK Sanity Platform 04 TCs [PASS] | 03 TCs FAIL TOTAL: [ 34 TCs PASS | 05 TCs FAIL | 21 TCs BLOCK ] Standard - Local Storage (2+2) Setup 03 TCs [PASS] Provisioning 01 TCs [FAIL] Sanity OpenStack 52 TCs [BLOCK] Sanity Platform 05 TCs [BLOCK] TOTAL: [ 03 TCs PASS | 01 TCs FAIL | 57 TCs BLOCK ] Standard - Dedicated Storage (2+2+2) Setup 03 TCs [PASS] Provisioning 01 TCs [FAIL] Sanity OpenStack 52 TCs [BLOCK] Sanity Platform 05 TCs [BLOCK] TOTAL: [ 03 TCs PASS | 01 TCs FAIL | 57 TCs BLOCK ] =========================================== Sanity Test is executed in a Containers - Virtual Environment No tested =========================================== Virtual environment no tested due to: https://bugs.launchpad.net/starlingx/+bug/1826445 Cinder volume cannot be created: https://bugs.launchpad.net/starlingx/+bug/1828059 For more detail of the tests: https://wiki.openstack.org/wiki/StarlingX/Test/SanityTests#Sanity-OpenStack Regards Maria G.

1 0

[Starlingx-discuss] Usage of the "pike" name in the tools & documentation
by Saul Wold 09 May '19

09 May '19

Folks, I noticed that we are still using 'pike' in the starlingx/tools repo, should we consider trying to change this out at this point and just remove the OpenStack release name completely from here? This seems to mostly be used in the centos-mirror-tools and the build container, I am not sure what other tools community members may have that use that naming. Input Welcome Thanks Sau!

1 0

[Starlingx-discuss] [DOCS] Change compute node to worker node personality
by Sullivan, David 09 May '19

09 May '19

As part of this story there are number of changes that can impact documentation. I've described the changes below. Let me know if you require any further details. -David --- This story encompasses the move from openstack compute nodes to docker/kubernetes worker nodes. The changes involved renaming compute nodes to worker nodes, renaming VM functions to Application and making vswitch and nova-local optional. Changed functionality: Compute personality/subfunction renamed to 'worker' CLI changes: host-add, host-bulk-add, host-update, host-show, host-list, dcmanager patch Horizon Changes: Host Inventory, Host personality, edit host, host overview, patch orchestration, dcmanager patch The pxeboot console has also been updated to use worker CPU VM function renamed to 'Application' CLI changes: host-cpu-* Horizon changes: host processor VM huge pages renamed to 'Application huge pages' CLI changes: host-memory-* Horizon changes: host memory, host update memory, force-host-lock vswitch changes * If vswitch_type is 'None' - newly installed worker hosts will start with 0 vswitch cpus - vswitch cpus can only be set to 0 through 'system host-cpu-modify' or platform horizon - vswitch cpus must be 0 when a worker node is unlocked * If vswitch_type is 'ovs-dpdk' - newly installed worker hosts will start with 2 vswitch cpus (this behavior is unchanged) - vswitch cpus must be at least 1 when a worker node is unlocked nova-local changes * The nova-local volume group is now optional. It is only required if the worker node has the openstack-compute-node=enabled label present. huge page changes * vswitch huge pages will only be allocated if vswitch_type is not 'None' Stories: https://storyboard.openstack.org/#!/story/2004022 https://storyboard.openstack.org/#!/story/2004763 https://storyboard.openstack.org/#!/story/2004649 Reviews: https://review.opendev.org/#/c/656586/ https://review.opendev.org/#/c/656583/ https://review.opendev.org/#/c/651889/ https://review.opendev.org/#/c/631541/ https://review.opendev.org/#/c/646038/ https://review.opendev.org/#/c/633924/ https://review.opendev.org/#/c/624452/ https://review.opendev.org/#/c/624564/ https://review.opendev.org/#/c/624715/ https://review.opendev.org/#/c/624718/ https://review.opendev.org/#/c/624512/ https://review.opendev.org/#/c/624513/ https://review.opendev.org/#/c/624727/ https://review.opendev.org/#/c/624517/ https://review.opendev.org/#/c/626366/

2 1

[Starlingx-discuss] mlx support on data interfaces now available
by Khalil, Ghada 09 May '19

09 May '19

FYI. The ovs-dpdk upversion required to enable mellanox NIC support for data ports was merged in stx master on May 2. https://review.opendev.org/#/c/642673/ https://review.opendev.org/#/c/642672/ Thanks to Shuicheng Lin, Chenjie Xu, Elio Martinez and team for getting the new version integrated and tested in StarlingX. Regards, Ghada From: Khalil, Ghada Sent: Tuesday, March 12, 2019 5:46 PM To: starlingx-discuss(a)lists.starlingx.io Subject: Reminder: No mlx support on data interfaces w/ CentOS 7.6 I just wanted to send a reminder that there will be no mellanox NIC support on data interfaces in loads starting today due to the merge of the CentOS 7.6 feature branch. The support will be re-introduced by: https://storyboard.openstack.org/#!/story/2004743 Until this story merges, please do not use systems w/ mellanox data interfaces. Thanks, Ghada

1 0

[Starlingx-discuss] Transitioning to Ansible bootstrap
by Ngo, Tee 09 May '19

09 May '19

Hi, In transition to Ansible bootstrap deployment, tomorrow the following commit https://review.opendev.org/#/c/657693, which disables config_controller, will be merged. StarlingX test team has been notified and is making updates to their lab installer, configuration files and automation tools. StarlingX doc team has also been notified to make updates to the installation wikis. To ease the transition, once the commit is merged, config_controller can still be used to bootstrap the 1st controller for a limited time (~1wk) using --force option. After which time, relevant code in config_controller will be removed. In the event the doc team is not done with all of their updates by Friday. Please refer to the One node installation wiki<https://wiki.openstack.org/wiki/StarlingX/Containers/Installation> for the instructions on how to run bootstrap playbook and to overwrite the default settings. The extra step that needs to be done following Ansible bootstrap (vs config_controller) is to provision the oam, management and k8s cluster interfaces prior to unlocking controller-0. For AIOSX: # management and cluster interfaces default to loopback for AIOSX OAM_IF=enp0s3 system host-if-modify controller-0 $OAM_IF -c platform --networks oam For AIO-DX, Standard non-storage, Standard storage: system host-if-modify controller-0 lo -c none OAM_IF=enp0s3 system host-if-modify controller-0 $OAM_IF -c platform --networks oam MGMT_IF=enp0s8 system host-if-modify controller-0 $MGMT_IF -c platform --networks mgmt system host-if-modify controller-0 $MGMT_IF -c platform --networks cluster-host Note: enp0s3 is a typical oam interface and enp0s8 is a typical mgmt interface in vbox. You can replace these with the values specific to your test system. In return, you get the benefits of the bootstrap playbook: * Use Ansible which is an industry well-recognized tool * Can bootstrap target host both locally and remotely * Can bootstrap multiple target hosts simultaneously * Can reconfigure without having to resinstall * Require minimal configuration input upfront * Is simpler to understand * Is simpler to identify issues Tee

1 0

[Starlingx-discuss] DUPLEX: applying stx-openstack fails with timeout for mariadb
by Marcel Schaible 09 May '19

09 May '19

Hi, we have got the image from 20190429 up and running in a duplex configuration. When I'll try to bring up the application Services with: system application-apply stx-openstack I am getting the error and log file is below. # system application-list stx-openstack | armada-manifest | manifest.yaml | apply-failed | operation aborted, check logs for detail | I am using this stx-application: stx-openstack-1.0-11-centos-stable-latest.tgz Thanks Marcel 2019-05-06 09:13:34.447 11348 INFO armada.handlers.test [-] [chart=ceph-pools-audit]: PASSED: osh-openstack-ceph-pools-audit 2019-05-06 09:13:34.447 11348 INFO armada.handlers.armada [-] All Charts applied in ChartGroup provisioner. 2019-05-06 09:13:34.447 11348 INFO armada.handlers.armada [-] Processing ChartGroup: openstack-mariadb (Mariadb), sequenced=True 2019-05-06 09:13:34.447 11348 INFO armada.handlers.chart_deploy [-] [chart=mariadb]: Processing Chart, release=osh-openstack-mariadb 2019-05-06 09:13:34.447 11348 INFO armada.handlers.chart_deploy [-] [chart=mariadb]: known: [], release_name: osh-openstack-mariadb 2019-05-06 09:13:34.448 11348 INFO armada.handlers.chartbuilder [-] [chart=mariadb]: Building dependency chart helm-toolkit for release openstack-mariadb. 2019-05-06 09:13:34.463 11348 INFO armada.handlers.chart_deploy [-] [chart=mariadb]: Installing release osh-openstack-mariadb in namespace openstack, wait=True, timeout=1800s 2019-05-06 09:13:34.466 11348 INFO armada.handlers.tiller [-] [chart=mariadb]: Helm install release: wait=True, timeout=1800 2019-05-06 09:13:59.605 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:14:59.668 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:15:59.730 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:16:59.792 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:17:59.852 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:18:59.906 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:19:59.967 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:21:00.031 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:22:00.094 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:23:00.154 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:24:00.216 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:25:00.279 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:26:00.341 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:27:00.405 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:28:00.468 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:29:00.530 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:30:00.595 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:31:00.651 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:32:00.712 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:33:00.769 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:34:00.826 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:35:00.890 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:36:00.949 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:37:01.009 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:38:01.069 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:39:01.130 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:40:01.194 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:41:01.257 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:42:01.320 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:43:01.385 11348 DEBUG armada.handlers.lock [-] Updating lock update_lock /usr/local/lib/python3.6/dist-packages/armada/handlers/lock.py:155 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller [-] [chart=mariadb]: Error while installing release osh-openstack-mariadb: grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: status = StatusCode.UNKNOWN details = "release osh-openstack-mariadb failed: timed out waiting for the condition" debug_error_string = "{"created":"@1557135814.815037033","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-openstack-mariadb failed: timed out waiting for the condition","grpc_status":2}" > 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller Traceback (most recent call last): 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 462, in install_release 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller metadata=self.metadata) 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller return _end_unary_response_blocking(state, call, False, None) 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller raise _Rendezvous(state, None, None, deadline) 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller status = StatusCode.UNKNOWN 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller details = "release osh-openstack-mariadb failed: timed out waiting for the condition" 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller debug_error_string = "{"created":"@1557135814.815037033","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-openstack-mariadb failed: timed out waiting for the condition","grpc_status":2}" 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller > 2019-05-06 09:43:34.815 11348 ERROR armada.handlers.tiller 2019-05-06 09:43:34.816 11348 DEBUG armada.handlers.tiller [-] [chart=mariadb]: Helm getting release status for release=osh-openstack-mariadb, version=0 get_release_status /usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py:528 2019-05-06 09:43:34.995 11348 DEBUG armada.handlers.tiller [-] [chart=mariadb]: GetReleaseStatus= name: "osh-openstack-mariadb" info { status { code: FAILED } first_deployed { seconds: 1557134014 nanos: 472287926 } last_deployed { seconds: 1557134014 nanos: 472287926 } Description: "Release \"osh-openstack-mariadb\" failed: timed out waiting for the condition" } namespace: "openstack" get_release_status /usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py:536 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada [-] Chart deploy [mariadb] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-openstack-mariadb - Tiller Message: b'Release "osh-openstack-mariadb" failed: timed out waiting for the condition' 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada Traceback (most recent call last): 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 462, in install_release 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada metadata=self.metadata) 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada status = StatusCode.UNKNOWN 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada details = "release osh-openstack-mariadb failed: timed out waiting for the condition" 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada debug_error_string = "{"created":"@1557135814.815037033","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-openstack-mariadb failed: timed out waiting for the condition","grpc_status":2}" 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada > 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada During handling of the above exception, another exception occurred: 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada 2019-05-06 09:43:34.995 11348 ERROR armada.handlers.armada Traceback (most recent call last):

4 14

Re: [Starlingx-discuss] 2nd node stuck at pxe installation
by Marcel Schaible 09 May '19

09 May '19

Hi, we have the same problem with the image from 20190411. It Looks like that controller-1 is not finding the pxe boot image. Kind regards Marcel > Message: 1 > Date: Tue, 30 Apr 2019 13:54:17 +0000 > From: "Penney, Don" <Don.Penney(a)windriver.com> > To: "Lin, Shuicheng" <shuicheng.lin(a)intel.com>, > "starlingx-discuss(a)lists.starlingx.io" > <starlingx-discuss(a)lists.starlingx.io> > Subject: Re: [Starlingx-discuss] 2nd node stuck at pxe installation > Message-ID: > <6703202FD9FDFF4A8DA9ACF104AE129FBA48BB86(a)ALA-MBD.corp.ad.wrs.com> > Content-Type: text/plain; charset="utf-8" > > You can set the console either via the web browser in the installation parameters, or at command-line, such as: > system host-update 2 personality=controller console= > > The default is the serial console, "ttyS0,115200". If you're using a graphical console, you can set it blank, or console=tty0, for example. This should allow you to see if there are some errors occurring trying to load the installer. > > > From: Lin, Shuicheng [mailto:shuicheng.lin@intel.com] > Sent: Tuesday, April 30, 2019 1:03 AM > To: starlingx-discuss(a)lists.starlingx.io > Subject: [Starlingx-discuss] 2nd node stuck at pxe installation > > Hi all, > I try to do duplex deploy, and find controller-1 stuck at pxe installation step. > The screen stuck at "Loading rel-19.01/installer-initrd...........ready". But package installation is not started as host-show command shown in controller-0. > I meet this issue with latest code. Do you know what cause the issue, or how to debug it? > Thanks. > > [wrsroot@controller-0 ~(keystone_admin)]$ system host-list > +----+--------------+-------------+----------------+-------------+--------------+ > | id | hostname | personality | administrative | operational | availability | > +----+--------------+-------------+----------------+-------------+--------------+ > | 1 | controller-0 | controller | unlocked | enabled | available | > | 2 | controller-1 | controller | locked | disabled | offline | > +----+--------------+-------------+----------------+-------------+--------------+ > [wrsroot@controller-0 ~(keystone_admin)]$ system host-show controller-1 | grep install > | install_output | text | > | install_state | None | > | install_state_info | None | > | subfunction_avail | not-installed > > Best Regards > Shuicheng >

5 14

[Starlingx-discuss] [Containers] Sanity Test - ISO 20190508
by Perez Ibarra, Maria G 08 May '19

08 May '19

Status of the Sanity Test for last CENGN ISO: bootimage.iso from 2019-May-8 (link<http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190508T01…>) Status: RED =========================================== Sanity Test is executed in a Containers - Bare Metal Environment AIO - Duplex Setup Manual [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [FAIL] | 23 TCs FAIL Sanity Platform 05 TCs [PASS] TOTAL: 57 TCS PASS Standard - Local Storage (2+2) Setup Manual [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [FAIL] | 23 TCs FAIL Sanity Platform 07 TCs [PASS] TOTAL: 57 TCS PASS Standard - Dedicated Storage (2+2+2) Setup Manual [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [FAIL] | 24 TCs FAIL Sanity Platform 05 TCs [PASS] TOTAL: 57 TCS PASS ---------------------------------------------------------- cinder volume create failed https://bugs.launchpad.net/starlingx/+bug/1828059 Due to an issue in our automation environment virtual, only the execution for BM was completed. We are working on fixing the issue to deliver results as soon possible. For more detail of the tests: https://wiki.openstack.org/wiki/StarlingX/Test/SanityTests#Sanity-OpenStack Regards Maria G.

1 0

[Starlingx-discuss] FYI: Linking commits/reviews to Launchpad bugs
by Penney, Don 08 May '19

08 May '19

Hi all, I've learned a bit more this afternoon about how Gerrit updates Launchpad bugs based on the commit messages in reviews and thought I should share and clarify some things for folks. As noted on the wiki: https://wiki.openstack.org/wiki/StarlingX/CodeSubmissionGuidelines if you're working on a Launchpad bug, you need to specify one or more tags in the commit message for Closes-Bug, Partial-Bug, or Related-Bug with the Launchpad bug number, such as: Closes-Bug: 123456 We've also seen that it appears this tag must be in the final section of your commit message, ie. no blank lines following it... so the following is good: This commit fixes the typos. Change-Id: If46f03a5d042f949db9359d6ddd7f69790ccaf4f Closes-Bug: 1827326 Signed-off-by: Don Penney <don.penney(a)windriver.com> whereas the following would appear to be ignored (I'm not sure why, yet): This commit fixes the typos. Closes-Bug: 1827326 Change-Id: If46f03a5d042f949db9359d6ddd7f69790ccaf4f Signed-off-by: Don Penney <don.penney(a)windriver.com> Two things will happen when the tag is processed correctly: 1. Gerrit will mark the Launchpad bug as "In Progress" (or different status for merged or abandoned, of course) 2. Gerrit will add a comment to the bug indicating "Fix proposed" ... BUT ONLY ON THE INITIAL PATCHSET The note on that second point is important... If you do not set the tag correctly on the initial review creation, Gerrit WILL NOT add a comment linking back to your review. In which case, you should probably do this manually yourself. (I suspect this is intended to avoid adding a comment every time the review is updated.) When you create your review, you can click on the bug link in Gerrit and should see the state change and comment in Launchpad. If you don't see that, Gerrit did not process your tag correctly. Cheers, Don. Don Penney, Developer, Wind River

2 1