September 2018 - Starlingx-discuss

[Starlingx-discuss] [r/2018.10] StarlingX Release 2018.10 RC1 branch is complete
by Dean Troyer 03 Oct '18

03 Oct '18

I have completed branching all 44 repos for release 2018.10. This is tagged as 2018.10.rc1 for release candidate 1. We have not defined a formal release candidate process but I used the name for the branch tag as most people will know what that means: this branch will become the release when final. The final release tag will be 2018.10.0. Release branch: r/2018.10 Current tag: 2018.10.rc1 The usual list of .gitreview updates are the first reviews on the release branch in Gerrit and should be the first things approved on the branch. This list also includes an update for the manifest file. https://review.openstack.org/#/q/topic:create-r/2018.10+status:open All master branches are again open for merging ongoing work. Remember that any fixes to the release branch first get merged to master and then backported. Currently there are two reviews that were not merged before the branching (https://review.openstack.org/#/c/605254 did merge in time). They have topic set to release-backport: https://review.openstack.org/#/q/status:open+branch:master+topic:release-ba… There are currently two reviews on that list (https://review.openstack.org/606123 and https://review.openstack.org/605275) they are stacked and will merge in that order once approved. Thank you for your patience and please let me or anyone on the release team know if you find any problems. dt -- Dean Troyer dtroyer(a)gmail.com

2 2

[Starlingx-discuss] Stories for stx-tools deployment
by Michel Thebeau 03 Oct '18

03 Oct '18

Hi Dean, Abraham, I've been working through the wikis under "https://wiki.openstack.org/wiki/StarlingX/Installation_Guide_Virtual_Enviro…". After I've finished reviewing "standard Controller Storage" and "all-in-one" configurations under virtualization, I'd like consider stories for stx-tools/deployement such as "running multiple clusters on a host" and "testing networking for instances". I do not see anything in storyboard: https://storyboard.openstack.org/#!/project/openstack/stx-tools Do you know if there are plans for those things? M

2 4

[Starlingx-discuss] There are not network interfaces in controller-1
by Alonso, Juan Carlos 02 Oct '18

02 Oct '18

Hi, Was there a change on how to create or provision network interfaces for controllers? When Controller-1 was installed and try to provision it, there is not output for "system host-if-list -a controller-1", for controller-0 there is. So, if controller-1 is not full provisioned it cannot 'unlock' and cannot be used. I followed steps in Wiki for Virtual multinode controller storage. https://wiki.openstack.org/wiki/StarlingX/Installation_Guide_Virtual_Enviro… Execute against ISO: stx-2018-09-28-148.iso Regards. Juan Carlos Alonso

3 4

[Starlingx-discuss] [multi-os] replace "/etc" in config files by a variable "sysconfdir"
by Hu, Yong 01 Oct '18

01 Oct '18

As a part of initiatives, I would like to suggest to replace “/etc”, which is hardcoded in some StarlingX config files, by a variable something like “sysconfdir”, which would be “instantiated” a bit later upon the OS type (CentOS, ClearLinux or Ubuntu). Taking “stx-nfv/nfv/nfv-vim/nfv_vim/config.ini” as an example, “/etc” is coded in this “config.ini” directly to refer other config files: config_file=/etc/nfv/nfv_plugins/alarm_handlers/config.ini config_file=/etc/nfv/nfv_plugins/nfvi_plugins/config.ini My recommendation is to use a variable “sysconfdir” as instead, and to “define” this variable on later stage, like in “nfv.spec” for CentOS, in which “sysconfdir” is “/etc”. The benefit I see here is in other OSs, such as Clear Linux in which we can set different value, for example, “/usr/local/etc” for this variable “sysconfdir”. Should you have any questions or feedback, please let me know. If I don’t see objections with this kind of changes, I will make some patches accordingly afterward.

3 2

[Starlingx-discuss] Containerizing the StarlingX Infrastructure
by Rowsell, Brent 29 Sep '18

29 Sep '18

Folks, Setting up this call to give the community an overview of the StarlingX infrastructure containerization initiative. Hope you can join. Thanks, Brent

1 0

Re: [Starlingx-discuss] build-pkgs cannot complete std build
by Scott Little 29 Sep '18

29 Sep '18

Ok, we've seen 3 ceph failures in our last 6 builds. The common factor: tpm2-tools builds on 'b0' before ceph builds. Our theory. The buildRequires of tpm2-tools causes autoconf-archive to be installed... which installs a bunch of .m4 files in /usr/share/aclocal ... which causes ceph grief when it calls aclocal. I don't really know automake or aclocal all that well. I'm assuming /usr/share/aclocal is acting something like a cache, but it's a cache whos contents are incompatible with ceph. Do we have any autotools / aclocal / m4 experts in the house? Possible fixes: - ceph: can we tell it to not use the aclocal cache... explicitly (a flag to aclocal?) ... or implicitly (update ceph's m4 files so they look 'newer' than the cache)? - tpm2-tools: Can we remove the dependence on autoconf-archive? No other package we build seems to need it. Scott On 18-09-27 04:45 PM, Saul Wold wrote: > > And of course it worked the third time! > > So, I lost the good logs. > > Sau! > > > On 09/27/2018 12:56 PM, Scott Little wrote: >> On 18-09-27 03:53 PM, Scott Little wrote: >>> Our latest build, based on code synced at 2018-09-27T15:28:00 UTC, >>> built successfully. >>> >>> It took three attempts to get ceph built. The first two passes >>> aborted quickly due to missing packages. The final pass did not >>> exhibit the 'aclocal: too many loops'**issue. >>> >>> The only build I have that exhibited the too many loops error was a >>> snapshot on 2018-09-20T15:50:40 UTC >>> >>> I do have a designer with an older snapshot that seems to hit it >>> regularly, so I'll work with him and see if we can learn more. >>> >>> I think we need more data from the community >>> - Who's build is failing on ceph with *aclocal: too many loops?* >>> - Who is building successfully ? >>> - Who can build only intermittently? >>> >>> >>> >>> Info to collect for failed builds: >> - repo sync timestamp >>> - build command used? >>> - Was it a new workspace, a cleaned workspace, or a previously used >>> workspace? >> - $MY_WORKSPACE/CONTEXT >>> - $MY_WORKSPACE/build-std.log >>> - $MY_WORKSPACE/std/results/*/ceph-*/*.log >>> >>> For successful builds, same info. Rather than full build logs, I can >>> settle for: >>> - grep '$Success building\|iteration\|building ceph$' >>> $MY_WORKSPACE/build-std.log >>> - grep compute_resources: build-std.log >>> >>> >>> >>> >>> >>> On 18-09-27 02:21 PM, Saul Wold wrote: >>>> On 09/26/2018 09:16 AM, Scott Little wrote: >>>>> aclocal 'too many loops' has been popping up sporadically for a >>>>> week or two now. Possibly 7.5 related. >>>>> >>>>> I suspect that there is a build order and/or race condition >>>>> element to this. It often goes away if you just run build-pkgs a >>>>> second time. >>>>> >>>> I am seeing this failure also, but it does not go away after a >>>> second rebuild. I have the lastest stx-root (build-tools) with the >>>> recent patches. >>>> >>>> Is this directly related to the fuzz issue or is there something >>>> else we need to address in CEPH itself. >>>> >>>> This is blocking my local build. >>>> >>>> Sau! >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>

3 2

[Starlingx-discuss] Launchpad / Gerrit integration for multiple commits
by Khalil, Ghada 29 Sep '18

29 Sep '18

Hello all, I have noticed that Launchpad bugs are automatically marked as "Fix Released" even when there are multiple commits specified and not all of them are merged. In those cases, the commit message for each commit uses the "Closes-Bug". I went back to the openstack documentation for reference and found the following: https://wiki.openstack.org/wiki/GitCommitMessages * Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. * Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. * Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. So if a fix requires multiple commits, I suggest you use "Partial-Bug" with only the final commit using "Closes-Bug". I have updated the StarlingX Code Submission Guidelines wiki accordingly: https://wiki.openstack.org/wiki/StarlingX/CodeSubmissionGuidelines Regards, Ghada

1 0

[Starlingx-discuss] stx.2018.10 code freeze status -- Branch creation in progress
by Khalil, Ghada 29 Sep '18

29 Sep '18

Hello all, Dean is in the process of starting the branch creation for the stx.2018.10 release. Please do not W+1 any commits to master until the branches are created. Dean will send an email once merges can resume on master. Note: There are a few documentation updates which did not make it. Those will need to be cherry-picked to the release branches by their respective authors. Once the release branches are created, any commits tagged for stx.2018.10 need to be merged in master first and then cherry-picked to the release branch by the developer. All other commits (tagged for stx.2019.03 or untagged) should be merged in master only. Launch pads tagged for stx.2018.10: https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.2018.10 Stories tagged for stx.2018.10: https://storyboard.openstack.org/#!/story/list?status=active&project_group_… * only the doc story is expected to have additional commits that require cherrypicking. Thank you everyone for working extra hard to get in the required content for the branch creation. Regards, Ghada

2 1

[Starlingx-discuss] May have to consider an lshell replacement
by Saul Wold 28 Sep '18

28 Sep '18

Folks, As I was looking at the upstream patches, I looked into the status of lshell and noticed there was an existing open issue[0] which referenced 2 CVEs: - CVE-2016-6902 - remote authenticated users can break out of a limited shell and execute arbitrary commands. - CVE-2016-6903 - lshell 0.9.16 allows remote authenticated users to break out of a limited shell and execute arbitrary commands. These are related, and there is a potential fix, but issue 150 [3] seems to indicate the patch is not complete. The maintainer has expressed that he not able to do anything about this as of May this year. Additionally lshell is python2 based and would need to be converted to python3. I went so far as proposing a very simple change to their README.md to fix a bad link and it stalled in their travis tox check. Sau! [0] https://github.com/ghantoos/lshell/issues/188 [1] https://nvd.nist.gov/vuln/detail/CVE-2016-6902 [2] https://nvd.nist.gov/vuln/detail/CVE-2016-6903 [0] https://github.com/ghantoos/lshell/issues/150

6 9

[Starlingx-discuss] OpenStack Summit Forum Submission Process Extended
by Jimmy McArthur 28 Sep '18

28 Sep '18

Hello Everyone We are extended the Forum Submission process through September 30, 11:59pm Pacific (6:59am GMT). We've already gotten a ton of great submissions, but we want to leave the door open through the weekend in case we have any stragglers. Please submit your topics here: https://www.openstack.org/summit/berlin-2018/call-for-presentations If you'd like to review the submissions to date, you can go to https://www.openstack.org/summit/berlin-2018/vote-for-speakers. There is no voting period, this is just so Forum attendees can review the submissions to date. Thank you! Jimmy

1 0