From bruce.e.jones at intel.com Wed Jun 6 21:20:38 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 6 Jun 2018 21:20:38 +0000 Subject: [Starlingx-discuss] Upstream Tracking Process Message-ID: <9A85D2917C58154C960D95352B22818BAB543C05@fmsmsx117.amr.corp.intel.com> This is the start of a discussion for how we manage and track the process of pushing the StarlingX carried patches to their respective upstream communities. At a high level, we want to make it easy for: * Contributors to have a clear picture of the upstream status of each carried patch * Contributors and broader community members to be able to see our progress over time * Plus we want to be able to track progress and the level of effort needed ourselves The process should follow standard Open Stack conventions unless there is a very good reason not to. It should be documented. At a start, I'll make the Simple Stupid and Obvious proposal: * Store a list of each carried patch in stx-docs or etherpad, with patches listed per upstream repo and grouped into buckets where needed * Each item on the list contains a description of the patch(es), status (e.g. "accepted in Rocky") and (for Open Stack patches) a link to a Storyboard. Patches outside the Open Stack community should have a link to the upstream's bugzilla/etc... * The Storyboard entry (or equivalent) contains the details of the work, with links to tasks, specs and etc... Thoughts / feedback? brucej From bruce.e.jones at intel.com Wed Jun 6 22:42:10 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 6 Jun 2018 22:42:10 +0000 Subject: [Starlingx-discuss] Culture? Message-ID: <9A85D2917C58154C960D95352B22818BAB543CD1@fmsmsx117.amr.corp.intel.com> What do we want the culture of this project to be? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Tue Jun 12 21:22:14 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Tue, 12 Jun 2018 16:22:14 -0500 Subject: [Starlingx-discuss] [dev] Cleaning up the workspace directory structure Message-ID: The split of the former repo structure into the stx-* pieces has left us with some legacy directory structures in the build tree. I think we want to make any changes here sooner rather than later where it will affect a smaller number of people with working builds. Has anyone started looking at this? dt -- Dean Troyer dtroyer at gmail.com From dtroyer at gmail.com Wed Jun 13 14:34:22 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 13 Jun 2018 09:34:22 -0500 Subject: [Starlingx-discuss] [Gerrit] How to watch a Gerrit project for changes Message-ID: Part of our new segment "Send Me More Email" In the Gerrit Web UI select -> Settings -> Watched Projects. Add the list of projects you want to receive notifications for. Project names are in the form 'openstack/stx-root'. For each project added to the list you can select the type of notifications to receive, that is best explained by the Gerrit docs[0]. In your email client, set up a filter to route these to a folder or your inbox will eventually be flooded. In GMail a filter selection like: list:"gerrit-openstack-stx-root" will let you apply the desired action to notifications for the stx-root project. A filter like: list:"gerrit-openstack-stx-" will match notifications for all StarlingX projects. My practice is to label these like "StarlingX/Gerrit" and skip the Inbox. When I want to see what has happened recently I can select that label and browse. Those of you not new to Gerrit or OpenStack, what workflow has worked well for you? dt [0] https://gerrit-review.googlesource.com/Documentation/user-notify.html#user -- Dean Troyer dtroyer at gmail.com From dtroyer at gmail.com Wed Jun 13 15:08:03 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 13 Jun 2018 10:08:03 -0500 Subject: [Starlingx-discuss] [Gerrit] How to watch a Gerrit project for changes In-Reply-To: References: Message-ID: [Following up with another approach] Rather than getting notifications via email, Gerrit also has a 'Dashboard' concept that is way-cool. [0] However, it is fraught with trial-and-error and editing nasty long URLs isn't much fun. Way back in the stone age (2014?) Sean Dague created a nifty little tool called gerrit-dash-creator[1] to translate an easy-to-read-and-edit INI-format file into a Gerrit Dashbaord URL. I have created a basic StarlingX dashboard [2] that lists open reviews based on some attributes like "Needs a final +2 (or +W) to merge", "Passes Zuul and has No Negative Feedback", "Things I am listed as a review but have not reviewd the current patchset" and so on. I'm including the monster URL[3] that is created by [2] here so you can try it directly without having to install the whole package. dt [0] https://gerrit-review.googlesource.com/Documentation/user-dashboards.html [1] https://git.openstack.org/cgit/openstack/gerrit-dash-creator/ [2] https://review.openstack.org/575142 [3] https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Fstx%2Dclients+OR+project%3Aopenstack%2Fstx%2Dconfig+OR+project%3Aopenstack%2Fstx%2Dfault+OR+project%3Aopenstack%2Fstx%2Dgplv2+OR+project%3Aopenstack%2Fstx%2Dgplv3+OR+project%3Aopenstack%2Fstx%2Dgui+OR+project%3Aopenstack%2Fstx%2Dha+OR+project%3Aopenstack%2Fstx%2Dinteg+OR+project%3Aopenstack%2Fstx%2Dmanifest+OR+project%3Aopenstack%2Fstx%2Dmetal+OR+project%3Aopenstack%2Fstx%2Dnfv+OR+project%3Aopenstack%2Fstx%2Droot+OR+project%3Aopenstack%2Fstx%2Dtis%2Drepo+OR+project%3Aopenstack%2Fstx%2Dtools+OR+project%3Aopenstack%2Fstx%2Dupdate+OR+project%3Aopenstack%2Fstx%2Dupstream+OR+project%3Aopenstack%2Fstx%2Dutils%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself&title=StarlingX+Review+Inbox&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50+NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself&Passed+Zuul%2C+No+Negative+Feedback+%28Small+Fixes%29=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1%2Cstarlingx%2Dcore+delta%3A%3C%3D10&Passed+Zuul%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1%2Cstarlingx%2Dcore+delta%3A%3E10&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+is%3Areviewed+age%3A2d -- Dean Troyer dtroyer at gmail.com From dtroyer at gmail.com Wed Jun 13 15:24:14 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 13 Jun 2018 10:24:14 -0500 Subject: [Starlingx-discuss] [dev] StarlingX CI Tests Message-ID: I have an extremely basic Zuul configuration set up in the STX-* repos that runs some subset of style checkers (pep8, bashate and yamllint). Getting some actual testing up and running is a high priority. There are a couple of questions here: a) Only one of the 'linters' jobs is currently passing, the existing code base was not written with this specific set of style guidelines in place. All of the jobs are non-voting because of this. The question of _what_ style guidelines should be used needs to be answered. As with most things I am defaulting to common OpenStack practices here. b) Real tests are required. At a bare minimum I think we need to also have unit testing configured. Since none of the existing Python services are published to PyPI we will need to do a bit of extra work for service dependencies. As I mentioned above, I am defaulting things that have not been specifically decided otherwise to use current OpenStack practices/documentation as a strong guideline. For testing the starting point is in the Project Testing Interface[0]. At some point we will need something language-specific for our C code. dt [0] https://governance.openstack.org/tc/reference/project-testing-interface.html -- Dean Troyer dtroyer at gmail.com From chris.friesen at windriver.com Wed Jun 13 17:18:17 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 13 Jun 2018 11:18:17 -0600 Subject: [Starlingx-discuss] test, please ignore Message-ID: <5B2151D9.9070801@windriver.com> this is a test to see if things are working From Brent.Rowsell at windriver.com Wed Jun 13 17:22:18 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Wed, 13 Jun 2018 17:22:18 +0000 Subject: [Starlingx-discuss] Repo consolidation Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> I would like to propose that the following repo's be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Wed Jun 13 17:28:45 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 13 Jun 2018 17:28:45 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo's be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brent.Rowsell at windriver.com Wed Jun 13 17:47:52 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Wed, 13 Jun 2018 17:47:52 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> I don't understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent ; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo's be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brent.Rowsell at windriver.com Wed Jun 13 17:54:43 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Wed, 13 Jun 2018 17:54:43 +0000 Subject: [Starlingx-discuss] [dev] Cleaning up the workspace directory structure References: Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0AD9DF@ALA-MBD.corp.ad.wrs.com> No, but this is something our team will take on Brent -----Original Message----- From: Dean Troyer [mailto:dtroyer at gmail.com] Sent: Tuesday, June 12, 2018 5:22 PM To: starlingx-discuss at lists.openstack.org Subject: [Starlingx-discuss] [dev] Cleaning up the workspace directory structure The split of the former repo structure into the stx-* pieces has left us with some legacy directory structures in the build tree. I think we want to make any changes here sooner rather than later where it will affect a smaller number of people with working builds. Has anyone started looking at this? dt -- Dean Troyer dtroyer at gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From erich.cordoba.malibran at intel.com Wed Jun 13 18:42:38 2018 From: erich.cordoba.malibran at intel.com (Cordoba Malibran, Erich) Date: Wed, 13 Jun 2018 18:42:38 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> Message-ID: This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" , "starlingx-discuss at lists.starlingx.io" Cc: "Ambardekar, Pranjal" Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent ; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brent.Rowsell at windriver.com Wed Jun 13 18:59:48 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Wed, 13 Jun 2018 18:59:48 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> The objective over time is to eliminate the changes to these open source packages by upstreaming the changes. Given that, I don’t think we want the overhead of creating/managing 250 repos. This project already has 50 repos. Currently we have these packages spread over 4 repos with no real functional division. I am proposing it would make more sense to consolidate into one. One repo to manage, making it easier to track the retirement of customizations over time. Brent From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] Sent: Wednesday, June 13, 2018 2:43 PM To: Rowsell, Brent ; JONES, BRUCE ; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL Subject: Re: [Starlingx-discuss] Repo consolidation This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" > Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" >, "starlingx-discuss at lists.starlingx.io" > Cc: "Ambardekar, Pranjal" > Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From pranjal.ambardekar at intel.com Wed Jun 13 19:05:29 2018 From: pranjal.ambardekar at intel.com (Ambardekar, Pranjal) Date: Wed, 13 Jun 2018 19:05:29 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> Message-ID: I do not think the license checking tool will allow us to consolidate, but we will re-check this Thanks, Pranjal From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 12:00 PM To: Cordoba Malibran, Erich ; Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Cc: Ambardekar, Pranjal Subject: RE: [Starlingx-discuss] Repo consolidation The objective over time is to eliminate the changes to these open source packages by upstreaming the changes. Given that, I don’t think we want the overhead of creating/managing 250 repos. This project already has 50 repos. Currently we have these packages spread over 4 repos with no real functional division. I am proposing it would make more sense to consolidate into one. One repo to manage, making it easier to track the retirement of customizations over time. Brent From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] Sent: Wednesday, June 13, 2018 2:43 PM To: Rowsell, Brent >; JONES, BRUCE >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: Re: [Starlingx-discuss] Repo consolidation This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" > Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" >, "starlingx-discuss at lists.starlingx.io" > Cc: "Ambardekar, Pranjal" > Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Wed Jun 13 21:46:57 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Wed, 13 Jun 2018 21:46:57 +0000 Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs Message-ID: During a recent compilation of StarlingX build failures happened for package bash-4.2.46-29 [0] 2 ways to fix: - in a workstation with 8 CPUs, it is fixed by cleaning the component and running a second time via build-pkgs - in a server with 88 CPUs, the failure is fixed by removing the -j option from patch [1] Any advice is highly appreciated. Abraham [0] https://github.com/starlingx-staging/stx-gplv2/tree/master/bash [1] https://github.com/starlingx-staging/stx-gplv2/blob/master/bash/centos/meta_patches/0001-Further-parallelize-bash-build.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Wed Jun 13 22:30:54 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Wed, 13 Jun 2018 22:30:54 +0000 Subject: [Starlingx-discuss] Tar Compressed Files: Integrity Verification Message-ID: One of the inputs for StarlingX build process besides RPMs, comes in the form of Tar Compressed files which gives us the task to verify the package integrity by locating its GPG key file, another layer of security. We have 2 types of Tar Compressed file sources: - From official repositories - From Github repositories In the case of official repositories, most of packages do not come with asc/dsc GPG key file [0], pushing us to search for a secondary one, just in a few cases so far, that GPG key file is found [1]. Is this a "search" only process? is there any other way to facilitate the search? Is it ok to rely on md5 checksum where no GPG key is found? In the case of Github repositories, being in a package coming from a Github repository [2] gives us the integrity verification? Lupita, Abraham [0] https://fast.dpdk.org/rel/ [1] http://http.debian.net/debian/pool/main/d/dpkg/ [2] https://github.com/voxpupuli/puppet-boolean/tarball/22b726dd78b0a60a224cc7054aebbf28e9306f62 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Wed Jun 13 22:53:39 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 13 Jun 2018 17:53:39 -0500 Subject: [Starlingx-discuss] Removing staging repos that were imported into Gerrit Message-ID: In the next couple of days I will be removing the following repos from the github.com/starlingx-staging project. These have all been imported into Gerrit and development has ensued. stx-clients stx-config stx-fault stx-gplv2 stx-gplv3 stx-gui stx-ha stx-integ stx-manifest stx-metal stx-nfv stx-root stx-tools stx-update stx-upstream stx-utils stx-tis-repo dt -- Dean Troyer dtroyer at gmail.com From bruce.e.jones at intel.com Wed Jun 13 23:19:03 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 13 Jun 2018 23:19:03 +0000 Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs In-Reply-To: References: Message-ID: <9A85D2917C58154C960D95352B22818BAB547351@fmsmsx117.amr.corp.intel.com> Neither seems good. It sounds like there is a race condition in the build. Can we fix that? Has this been fixed in newer versions of bash? brucej From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Wednesday, June 13, 2018 2:47 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs During a recent compilation of StarlingX build failures happened for package bash-4.2.46-29 [0] 2 ways to fix: - in a workstation with 8 CPUs, it is fixed by cleaning the component and running a second time via build-pkgs - in a server with 88 CPUs, the failure is fixed by removing the -j option from patch [1] Any advice is highly appreciated. Abraham [0] https://github.com/starlingx-staging/stx-gplv2/tree/master/bash [1] https://github.com/starlingx-staging/stx-gplv2/blob/master/bash/centos/meta_patches/0001-Further-parallelize-bash-build.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.friesen at windriver.com Wed Jun 13 23:31:53 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 13 Jun 2018 17:31:53 -0600 Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs In-Reply-To: References: Message-ID: <5B21A969.6000901@windriver.com> On 06/13/2018 03:46 PM, Arce Moreno, Abraham wrote: > During a recent compilation of StarlingX build failures happened for package > bash-4.2.46-29 [0] > 2 ways to fix: > - in a workstation with 8 CPUs, it is fixed by cleaning the component and > running a second time via build-pkgs > - in a server with 88 CPUs, the failure is fixed by removing the -j option from > patch [1] > Any advice is highly appreciated. The patch in question added -j"%(nprocs)" to the "make" line as part of an attempt to speed up the overall build on machines with many CPUs. The fact that it's failing points to a flaw in the upstream package. I see two options, either track down and fix the problem with parallel builds or else remove the "-j" option until the upstream package fixes parallel builds. Chris From abraham.arce.moreno at intel.com Thu Jun 14 13:59:27 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 14 Jun 2018 13:59:27 +0000 Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs In-Reply-To: <9A85D2917C58154C960D95352B22818BAB547351@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB547351@fmsmsx117.amr.corp.intel.com> Message-ID: > Neither seems good. It sounds like there is a race condition in the build. Can > we fix that? Has this been fixed in newer versions of bash? Thanks Bruce! Let me annotate the following options and I will complement with Chris' options: 1. Fix the problem 2. Update Bash package Abraham From abraham.arce.moreno at intel.com Thu Jun 14 14:13:22 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 14 Jun 2018 14:13:22 +0000 Subject: [Starlingx-discuss] Build Packages: Fail to Build BASH with Simultaneous Jobs In-Reply-To: <5B21A969.6000901@windriver.com> References: <5B21A969.6000901@windriver.com> Message-ID: > > During a recent compilation of StarlingX build failures happened for > > package > > bash-4.2.46-29 [0] > > 2 ways to fix: > > - in a workstation with 8 CPUs, it is fixed by cleaning the component > > and running a second time via build-pkgs > > - in a server with 88 CPUs, the failure is fixed by removing the -j > > option from patch [1] Any advice is highly appreciated. > > The patch in question added -j"%(nprocs)" to the "make" line as part of an > attempt to speed up the overall build on machines with many CPUs. > The fact that it's failing points to a flaw in the upstream package. Yes, we have had no other package has failed due to this option. > I see two options, either track down and fix the problem with parallel builds or else > remove the "-j" option until the upstream package fixes parallel builds. Now complementing with Bruce's options: 1. Update Bash package 2. Fix the problem 3. Remove patch I will work as they are listed, assuming no other package is tightly coupled to bash version 4.2.46. Would this upgrade be a good first exercise to allow StarlingX have latest package versions? Abraham From bruce.e.jones at intel.com Thu Jun 14 17:03:57 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 14 Jun 2018 17:03:57 +0000 Subject: [Starlingx-discuss] documents with tables? Message-ID: <9A85D2917C58154C960D95352B22818BAB547826@fmsmsx117.amr.corp.intel.com> I would like to post documents containing tables for keeping track of things for the project. Etherpad doesn't support them. What is the best way / format / tool to use to do that? brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Thu Jun 14 21:35:11 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 14 Jun 2018 21:35:11 +0000 Subject: [Starlingx-discuss] Bug handling Message-ID: <9A85D2917C58154C960D95352B22818BAB547B35@fmsmsx117.amr.corp.intel.com> This is also posted to the TOC document https://etherpad.openstack.org/p/starlingx Bugs * StarlingX Bug List: https://storyboard.openstack.org/#!/worklist/354 * Please create bugs for any issues found in Storyboard, against one of the stx-* projects. If you can't find the right project, use stx-integ * After you create the bug, please add it to the Bug Worklist (link above) -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Thu Jun 14 22:31:14 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 14 Jun 2018 22:31:14 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools Message-ID: Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a "software dev methodology and tools (repo, bug tracking, feature tracking, etc" How it should look like? Should be it a webpage? a document? Is our OpenStack Developer's Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Fri Jun 15 11:20:43 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 15 Jun 2018 11:20:43 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools Message-ID: <7B13D746-96A3-4739-9F23-E7D1B56877F7@windriver.com> What are the plans for · https://wiki.openstack.org/wiki/starlingx · and · https://docs.openstack.org/starlingx/latest/ Greg. From: "Arce Moreno, Abraham" Date: Thursday, June 14, 2018 at 6:31 PM To: "starlingx-discuss at lists.starlingx.io" Subject: [Starlingx-discuss] Software Development Methodologies and Tools Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a “software dev methodology and tools (repo, bug tracking, feature tracking, etc” How it should look like? Should be it a webpage? a document? Is our OpenStack Developer’s Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Fri Jun 15 15:42:43 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 15 Jun 2018 15:42:43 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools In-Reply-To: <7B13D746-96A3-4739-9F23-E7D1B56877F7@windriver.com> References: <7B13D746-96A3-4739-9F23-E7D1B56877F7@windriver.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB548024@fmsmsx117.amr.corp.intel.com> For the wiki, I believe we have to file a request to the OpenStack infra team to enable it. @Dean, is that right? Once we have it, I assume the content on the Etherpad would move to the wiki. Believe it’s similar for the docs, which would be published from source docs we write and keep in the source code – assuming in stx-docs which may also need to be created. Dean will likely also have to help us get that set up or tell someone how to do it. On our side we plan to assign engineers and tech writers to work on documentation and follow all the OpenStack conventions. brucej From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 15, 2018 4:21 AM To: Arce Moreno, Abraham ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Software Development Methodologies and Tools What are the plans for · https://wiki.openstack.org/wiki/starlingx · and · https://docs.openstack.org/starlingx/latest/ Greg. From: "Arce Moreno, Abraham" > Date: Thursday, June 14, 2018 at 6:31 PM To: "starlingx-discuss at lists.starlingx.io" > Subject: [Starlingx-discuss] Software Development Methodologies and Tools Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a “software dev methodology and tools (repo, bug tracking, feature tracking, etc” How it should look like? Should be it a webpage? a document? Is our OpenStack Developer’s Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Fri Jun 15 18:13:02 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 15 Jun 2018 18:13:02 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools In-Reply-To: References: Message-ID: <9A85D2917C58154C960D95352B22818BAB5481C1@fmsmsx117.amr.corp.intel.com> We should follow the OpenStack documentation process and methodology, which I believe means that we can have documents that get published as web pages. The OpenStack Dev Guide is a great example to follow. I don't think we need to re-produce all of that content. Instead, we should point at that, and our document should cover where we are different. For instance, how to clone the repos and do builds and tests. How we use Storyboard. I believe the steps are something like: 1) Get the stx-docs repo created 2) Ramp on the steps needed to write documents and publish documents using OpenStack infra. See [1] 3) Create a landing page (replacing our Etherpad) and go from there and build out the docs. Abraham, please keep things more on the developer facing side. I want to work myself on the "how do we plan this project" side. Makes sense? [1] https://docs.openstack.org/doc-contrib-guide/index.html From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Thursday, June 14, 2018 3:31 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Software Development Methodologies and Tools Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a "software dev methodology and tools (repo, bug tracking, feature tracking, etc" How it should look like? Should be it a webpage? a document? Is our OpenStack Developer's Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Fri Jun 15 19:32:46 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 15 Jun 2018 19:32:46 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules Message-ID: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> I would like to propose the following basic development process for StarlingX. Instead of writing a long document, I will just propose a set of guidelines. Comments and feedback will be graciously accepted. Rule 1: We will follow all the usual open source and OpenStack conventions Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. Rule 3: Code submissions should be reviewable (e.g. not thousands of lines). Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement. Rule 5: All code submissions shall have a Storyboard Story or Task associated with them and linked to in the commit message. Use the stx-* project that makes sense, or stx-upstream for upstream changes Rule 6: Code submissions for bug fixes can be posted to gerrit when ready Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code. brucej From erich.cordoba.malibran at intel.com Sun Jun 17 14:13:36 2018 From: erich.cordoba.malibran at intel.com (Cordoba Malibran, Erich) Date: Sun, 17 Jun 2018 14:13:36 +0000 Subject: [Starlingx-discuss] Updating SHA pointers in build system. Message-ID: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> Hi all, In preparation to open source, some components of StarlingX were squashed, this causes that the git history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components as now points to missing commits, causing a broken build. My question is what to do with these variables, should we: - Update to a valid commit - Set the variable value to HEAD - Remove those variables, not sure if that's possible. What do you think is the best course of action. -Erich From dtroyer at gmail.com Mon Jun 18 14:12:44 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Mon, 18 Jun 2018 09:12:44 -0500 Subject: [Starlingx-discuss] Updating SHA pointers in build system. In-Reply-To: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> References: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> Message-ID: On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich wrote: > In preparation to open source, some components of StarlingX were squashed, this causes that the git > history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components > as now points to missing commits, causing a broken build. Erich, do you know why they were pointing directly at a commit and not using a tag or branch? It sounds like that is a per-package variable? If it was a global this could be fun to fix with the now-split repos. > My question is what to do with these variables, should we: > > - Update to a valid commit > - Set the variable value to HEAD > - Remove those variables, not sure if that's possible. > > What do you think is the best course of action. We'll have to let WRS weigh in here as to the purpose and solution. dt -- Dean Troyer dtroyer at gmail.com From scott.little at windriver.com Mon Jun 18 14:36:39 2018 From: scott.little at windriver.com (Scott Little) Date: Mon, 18 Jun 2018 10:36:39 -0400 Subject: [Starlingx-discuss] Updating SHA pointers in build system. In-Reply-To: References: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> Message-ID: <3a6ebf98-8b13-a141-a9aa-554337a3cf98@windriver.com> For patching purposes, it's required that either the package version, or the release number increment with every commit. TIS_BASE_SRCREV is part of a mechanism to automatically set the release number by counting commits from a reference commit. TIS_BASE_SRCREV is the reference commit. It should point to a valid sha on the current branch. A tag would also be acceptable, although I don't know if we've ever tested with a tag. TIS_SRC_REV should be reset every time the openstack component declares a new version. Scott Little On 18-06-18 10:12 AM, Dean Troyer wrote: > On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich > wrote: >> In preparation to open source, some components of StarlingX were squashed, this causes that the git >> history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components >> as now points to missing commits, causing a broken build. > Erich, do you know why they were pointing directly at a commit and not > using a tag or branch? It sounds like that is a per-package variable? > If it was a global this could be fun to fix with the now-split repos. > >> My question is what to do with these variables, should we: >> >> - Update to a valid commit >> - Set the variable value to HEAD >> - Remove those variables, not sure if that's possible. >> >> What do you think is the best course of action. > We'll have to let WRS weigh in here as to the purpose and solution. > > dt > From erich.cordoba.malibran at intel.com Mon Jun 18 16:09:11 2018 From: erich.cordoba.malibran at intel.com (Cordoba Malibran, Erich) Date: Mon, 18 Jun 2018 16:09:11 +0000 Subject: [Starlingx-discuss] Updating SHA pointers in build system. In-Reply-To: <3a6ebf98-8b13-a141-a9aa-554337a3cf98@windriver.com> References: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> <3a6ebf98-8b13-a141-a9aa-554337a3cf98@windriver.com> Message-ID: <80E3C733-E12C-4B60-8DE6-5211F1F4D5C9@intel.com> Ok, I'll update the missing references on these components. ceph/centos/build_srpm.data devtools/qemu/centos/build_srpm.data openstack/openstack-ras/centos/build_srpm.data openstack/python-ceilometerclient/centos/build_srpm.data openstack/python-openstacksdk/centos/build_srpms.data Thanks. Erich On 6/18/18, 9:40 AM, "Scott Little" wrote: For patching purposes, it's required that either the package version, or the release number increment with every commit. TIS_BASE_SRCREV is part of a mechanism to automatically set the release number by counting commits from a reference commit. TIS_BASE_SRCREV is the reference commit. It should point to a valid sha on the current branch. A tag would also be acceptable, although I don't know if we've ever tested with a tag. TIS_SRC_REV should be reset every time the openstack component declares a new version. Scott Little On 18-06-18 10:12 AM, Dean Troyer wrote: > On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich > wrote: >> In preparation to open source, some components of StarlingX were squashed, this causes that the git >> history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components >> as now points to missing commits, causing a broken build. > Erich, do you know why they were pointing directly at a commit and not > using a tag or branch? It sounds like that is a per-package variable? > If it was a global this could be fun to fix with the now-split repos. > >> My question is what to do with these variables, should we: >> >> - Update to a valid commit >> - Set the variable value to HEAD >> - Remove those variables, not sure if that's possible. >> >> What do you think is the best course of action. > We'll have to let WRS weigh in here as to the purpose and solution. > > dt > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From dtroyer at gmail.com Mon Jun 18 17:29:29 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Mon, 18 Jun 2018 12:29:29 -0500 Subject: [Starlingx-discuss] Updating SHA pointers in build system. In-Reply-To: <80E3C733-E12C-4B60-8DE6-5211F1F4D5C9@intel.com> References: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> <3a6ebf98-8b13-a141-a9aa-554337a3cf98@windriver.com> <80E3C733-E12C-4B60-8DE6-5211F1F4D5C9@intel.com> Message-ID: On Mon, Jun 18, 2018 at 11:09 AM, Cordoba Malibran, Erich wrote: > Ok, I'll update the missing references on these components. > > ceph/centos/build_srpm.data > devtools/qemu/centos/build_srpm.data > openstack/openstack-ras/centos/build_srpm.data > openstack/python-ceilometerclient/centos/build_srpm.data > openstack/python-openstacksdk/centos/build_srpms.data Ah, they are all upstream repos on github. We could tag the squash commit as a starting point (there is one for the upstream parent to the squash commit, stx-r1-upstream) if that would be helpful. dt -- Dean Troyer dtroyer at gmail.com From bruce.e.jones at intel.com Mon Jun 18 21:39:13 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Mon, 18 Jun 2018 21:39:13 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> I met with Pranjal and Abraham today to discuss this. The problem is that we separated that code out for a reason. We have an internal requirement to run a license scanning tool, and the tool assumes that all of the code within a single git repo is covered by the same license. If you have files covered under multiple licenses, it reports errors. It’s rather silly that we’re letting a tool dictate something like this. We are setting up a process to run that tool on a regular basis, so when it comes time to do a release, we don’t run into issues that we didn’t already know about. It would not be the end of the world if someone submitted and approved a PR to merge those repos. It would make mine, Abraham’s and Pranjal’s lives easier if we did not. If you think that this would make things better for everyone else, I would withdraw my objection. Meanwhile, our goal is to get rid of those repos, long term. Brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 12:00 PM To: Cordoba Malibran, Erich ; Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Cc: Ambardekar, Pranjal Subject: RE: [Starlingx-discuss] Repo consolidation The objective over time is to eliminate the changes to these open source packages by upstreaming the changes. Given that, I don’t think we want the overhead of creating/managing 250 repos. This project already has 50 repos. Currently we have these packages spread over 4 repos with no real functional division. I am proposing it would make more sense to consolidate into one. One repo to manage, making it easier to track the retirement of customizations over time. Brent From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] Sent: Wednesday, June 13, 2018 2:43 PM To: Rowsell, Brent >; JONES, BRUCE >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: Re: [Starlingx-discuss] Repo consolidation This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" > Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" >, "starlingx-discuss at lists.starlingx.io" > Cc: "Ambardekar, Pranjal" > Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Jolliffe at windriver.com Tue Jun 19 14:04:00 2018 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Tue, 19 Jun 2018 14:04:00 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> Message-ID: <91BAF06A-4AA6-434B-B569-554957924315@windriver.com> Hi Bruce; Thanks for your flexibility – we will proceed with consolidation. The fewer repos the better, it will be one place to monitor and retire these changes. Maybe there are some ways to make the tool work for us – instead of the other way around. Let’s discuss on IRC. Regards; Ian From: "Jones, Bruce E" Date: Monday, June 18, 2018 at 5:40 PM To: Brent Rowsell , "CORDOBA MALIBRAN, ERICH" , "starlingx-discuss at lists.starlingx.io" Cc: "AMBARDEKAR, PRANJAL" Subject: Re: [Starlingx-discuss] Repo consolidation I met with Pranjal and Abraham today to discuss this. The problem is that we separated that code out for a reason. We have an internal requirement to run a license scanning tool, and the tool assumes that all of the code within a single git repo is covered by the same license. If you have files covered under multiple licenses, it reports errors. It’s rather silly that we’re letting a tool dictate something like this. We are setting up a process to run that tool on a regular basis, so when it comes time to do a release, we don’t run into issues that we didn’t already know about. It would not be the end of the world if someone submitted and approved a PR to merge those repos. It would make mine, Abraham’s and Pranjal’s lives easier if we did not. If you think that this would make things better for everyone else, I would withdraw my objection. Meanwhile, our goal is to get rid of those repos, long term. Brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 12:00 PM To: Cordoba Malibran, Erich ; Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Cc: Ambardekar, Pranjal Subject: RE: [Starlingx-discuss] Repo consolidation The objective over time is to eliminate the changes to these open source packages by upstreaming the changes. Given that, I don’t think we want the overhead of creating/managing 250 repos. This project already has 50 repos. Currently we have these packages spread over 4 repos with no real functional division. I am proposing it would make more sense to consolidate into one. One repo to manage, making it easier to track the retirement of customizations over time. Brent From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] Sent: Wednesday, June 13, 2018 2:43 PM To: Rowsell, Brent >; JONES, BRUCE >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: Re: [Starlingx-discuss] Repo consolidation This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" > Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" >, "starlingx-discuss at lists.starlingx.io" > Cc: "Ambardekar, Pranjal" > Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Tue Jun 19 14:40:01 2018 From: scott.little at windriver.com (Scott Little) Date: Tue, 19 Jun 2018 10:40:01 -0400 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <91BAF06A-4AA6-434B-B569-554957924315@windriver.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> <91BAF06A-4AA6-434B-B569-554957924315@windriver.com> Message-ID: <2c45cfbd-0fcb-ae1a-e46e-d1958cd6b377@windriver.com> Ok, I'll proceed with the reorg per Brent's  'Starlingx_setup_v3.xlxs' document. I'll do the work piecewise, and leave relocating stx-gplv2/3 content till last.  So there is still some time for discussion. Scott On 18-06-19 10:04 AM, Jolliffe, Ian wrote: > > Hi Bruce; > > Thanks for your flexibility – we will proceed with consolidation.  The > fewer repos the better, it will be one place to monitor and retire > these changes.  Maybe there are some ways to make the tool work for us > – instead of the other way around.  Let’s discuss on IRC. > > Regards; > > Ian > > *From: *"Jones, Bruce E" > *Date: *Monday, June 18, 2018 at 5:40 PM > *To: *Brent Rowsell , "CORDOBA MALIBRAN, > ERICH" , > "starlingx-discuss at lists.starlingx.io" > > *Cc: *"AMBARDEKAR, PRANJAL" > *Subject: *Re: [Starlingx-discuss] Repo consolidation > > I met with Pranjal and Abraham today to discuss this. > > The problem is that we separated that code out for a reason.  We have > an internal requirement to run a license scanning tool, and the tool > assumes that all of the code within a single git repo is covered by > the same license.  If you have files covered under multiple licenses, > it reports errors. > > It’s rather silly that we’re letting a tool dictate something like this. > > We are setting up a process to run that tool on a regular basis, so > when it comes time to do a release, we don’t run into issues that we > didn’t already know about. > > It would not be the end of the world if someone submitted and approved > a PR to merge those repos.    It would make mine, Abraham’s and > Pranjal’s lives easier if we did not.  If you think that this would > make things better for everyone else, I would withdraw my objection. > > Meanwhile, our goal is to get rid of those repos, long term. > >      Brucej > > *From:* Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] > *Sent:* Wednesday, June 13, 2018 12:00 PM > *To:* Cordoba Malibran, Erich ; > Jones, Bruce E ; > starlingx-discuss at lists.starlingx.io > *Cc:* Ambardekar, Pranjal > *Subject:* RE: [Starlingx-discuss] Repo consolidation > > The objective over time is to eliminate the changes to these open > source packages by upstreaming the changes. > > Given that, I don’t think we want the overhead of creating/managing > 250 repos. This project already has 50 repos. > > Currently we have these packages spread over 4 repos with no real > functional division. > > I am proposing it would make more sense to consolidate into one.  One > repo to manage, making it easier to track the retirement of > customizations over time. > > Brent > > *From:* Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] > *Sent:* Wednesday, June 13, 2018 2:43 PM > *To:* Rowsell, Brent > >; > JONES, BRUCE > >; > starlingx-discuss at lists.starlingx.io > *Cc:* AMBARDEKAR, PRANJAL > > > *Subject:* Re: [Starlingx-discuss] Repo consolidation > > This was a convenience separation. The license checking tool expects > to have a repository per project and a main license defined for the > entire repository. In this case, we wanted to release the project as > Apache License 2.0 and the tool assumes that all the code inside the > repository should has friendly licenses. However, the tool found some > conflicting components and to solve the issue we move out those into > the gplv2/3 repositories. > > This doesn’t mean that were actual license conflicts, it means that > this use case was outside of the scope of the tool. > > I would like to discuss the advantage of consolidation vs split, I’m > wondering if a model like CentOS has could help us, they have a > repository for each component. This will lead us to have around 250 > repositories (CentOS manages around 600) but I think that managing > each of them would be more easy. > > -Erich > > *From: *"Rowsell, Brent" > > > *Date: *Wednesday, June 13, 2018 at 12:48 PM > *To: *"Jones, Bruce E" > >, > "starlingx-discuss at lists.starlingx.io" > > > *Cc: *"Ambardekar, Pranjal" > > > *Subject: *Re: [Starlingx-discuss] Repo consolidation > > I don’t understand the distinction. There is already gpl code in > stx_integ. > > Brent > > *From:* Jones, Bruce E [mailto:bruce.e.jones at intel.com] > *Sent:* Wednesday, June 13, 2018 1:29 PM > *To:* Rowsell, Brent > >; > starlingx-discuss at lists.starlingx.io > *Cc:* AMBARDEKAR, PRANJAL > > > *Subject:* RE: [Starlingx-discuss] Repo consolidation > > Objection.  We separated those out to comply with software license > checking tools that we will still need to run. > > Pranjal and Abraham are the subject matter experts here.  If there is > a way to pass the code scanning tools and still combine these, I would > not object at all. > >       brucej > > *From:* Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] > *Sent:* Wednesday, June 13, 2018 10:22 AM > *To:* > starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] Repo consolidation > > I would like to propose that the following repo’s be consolidated > under stx-integ. > > * stx-gplv2 > * stx-gplv3 > * stx-upstream > > Any objections/comments ? > > Brent > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Jolliffe at windriver.com Tue Jun 19 14:47:04 2018 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Tue, 19 Jun 2018 14:47:04 +0000 Subject: [Starlingx-discuss] FW: Culture? Message-ID: What do we want the culture of this project to be? Hi Bruce; Here are some thoughts, words/values to describe the culture we would aspire to create around StarlingX: Open Inclusive Diverse Innovative Friendly Welcoming Decisive Flexible Regards; Ian   -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From cesar.lara at intel.com Tue Jun 19 17:27:00 2018 From: cesar.lara at intel.com (Lara, Cesar) Date: Tue, 19 Jun 2018 17:27:00 +0000 Subject: [Starlingx-discuss] FW: Culture? In-Reply-To: References: Message-ID: <0B566C62EC792145B40E29EFEBF1AB4710491989@fmsmsx104.amr.corp.intel.com> LGTM Regards Cesar Lara -----Original Message----- From: Jolliffe, Ian [mailto:Ian.Jolliffe at windriver.com] Sent: Tuesday, June 19, 2018 9:47 AM To: starlingx-discuss at lists.starlingx.io; Jones, Bruce E Subject: [Starlingx-discuss] FW: Culture? What do we want the culture of this project to be? Hi Bruce; Here are some thoughts, words/values to describe the culture we would aspire to create around StarlingX: Open Inclusive Diverse Innovative Friendly Welcoming Decisive Flexible Regards; Ian   From bruce.e.jones at intel.com Tue Jun 19 18:22:46 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Tue, 19 Jun 2018 18:22:46 +0000 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <2c45cfbd-0fcb-ae1a-e46e-d1958cd6b377@windriver.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> <91BAF06A-4AA6-434B-B569-554957924315@windriver.com> <2c45cfbd-0fcb-ae1a-e46e-d1958cd6b377@windriver.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54A367@fmsmsx117.amr.corp.intel.com> Cool. Can we see the document? Best way would be to create a Story and enter the contents into the Story so we can all see it. brucej From: Scott Little [mailto:scott.little at windriver.com] Sent: Tuesday, June 19, 2018 7:40 AM To: Jolliffe, Ian (Wind River) ; Jones, Bruce E ; Rowsell, Brent (Wind River) ; Cordoba Malibran, Erich ; starlingx-discuss at lists.starlingx.io Cc: Ambardekar, Pranjal Subject: Re: [Starlingx-discuss] Repo consolidation Ok, I'll proceed with the reorg per Brent's 'Starlingx_setup_v3.xlxs' document. I'll do the work piecewise, and leave relocating stx-gplv2/3 content till last. So there is still some time for discussion. Scott On 18-06-19 10:04 AM, Jolliffe, Ian wrote: Hi Bruce; Thanks for your flexibility – we will proceed with consolidation. The fewer repos the better, it will be one place to monitor and retire these changes. Maybe there are some ways to make the tool work for us – instead of the other way around. Let’s discuss on IRC. Regards; Ian From: "Jones, Bruce E" Date: Monday, June 18, 2018 at 5:40 PM To: Brent Rowsell , "CORDOBA MALIBRAN, ERICH" , "starlingx-discuss at lists.starlingx.io" Cc: "AMBARDEKAR, PRANJAL" Subject: Re: [Starlingx-discuss] Repo consolidation I met with Pranjal and Abraham today to discuss this. The problem is that we separated that code out for a reason. We have an internal requirement to run a license scanning tool, and the tool assumes that all of the code within a single git repo is covered by the same license. If you have files covered under multiple licenses, it reports errors. It’s rather silly that we’re letting a tool dictate something like this. We are setting up a process to run that tool on a regular basis, so when it comes time to do a release, we don’t run into issues that we didn’t already know about. It would not be the end of the world if someone submitted and approved a PR to merge those repos. It would make mine, Abraham’s and Pranjal’s lives easier if we did not. If you think that this would make things better for everyone else, I would withdraw my objection. Meanwhile, our goal is to get rid of those repos, long term. Brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 12:00 PM To: Cordoba Malibran, Erich ; Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Cc: Ambardekar, Pranjal Subject: RE: [Starlingx-discuss] Repo consolidation The objective over time is to eliminate the changes to these open source packages by upstreaming the changes. Given that, I don’t think we want the overhead of creating/managing 250 repos. This project already has 50 repos. Currently we have these packages spread over 4 repos with no real functional division. I am proposing it would make more sense to consolidate into one. One repo to manage, making it easier to track the retirement of customizations over time. Brent From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran at intel.com] Sent: Wednesday, June 13, 2018 2:43 PM To: Rowsell, Brent >; JONES, BRUCE >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: Re: [Starlingx-discuss] Repo consolidation This was a convenience separation. The license checking tool expects to have a repository per project and a main license defined for the entire repository. In this case, we wanted to release the project as Apache License 2.0 and the tool assumes that all the code inside the repository should has friendly licenses. However, the tool found some conflicting components and to solve the issue we move out those into the gplv2/3 repositories. This doesn’t mean that were actual license conflicts, it means that this use case was outside of the scope of the tool. I would like to discuss the advantage of consolidation vs split, I’m wondering if a model like CentOS has could help us, they have a repository for each component. This will lead us to have around 250 repositories (CentOS manages around 600) but I think that managing each of them would be more easy. -Erich From: "Rowsell, Brent" > Date: Wednesday, June 13, 2018 at 12:48 PM To: "Jones, Bruce E" >, "starlingx-discuss at lists.starlingx.io" > Cc: "Ambardekar, Pranjal" > Subject: Re: [Starlingx-discuss] Repo consolidation I don’t understand the distinction. There is already gpl code in stx_integ. Brent From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 13, 2018 1:29 PM To: Rowsell, Brent >; starlingx-discuss at lists.starlingx.io Cc: AMBARDEKAR, PRANJAL > Subject: RE: [Starlingx-discuss] Repo consolidation Objection. We separated those out to comply with software license checking tools that we will still need to run. Pranjal and Abraham are the subject matter experts here. If there is a way to pass the code scanning tools and still combine these, I would not object at all. brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Wednesday, June 13, 2018 10:22 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Repo consolidation I would like to propose that the following repo’s be consolidated under stx-integ. * stx-gplv2 * stx-gplv3 * stx-upstream Any objections/comments ? Brent _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Jolliffe at windriver.com Tue Jun 19 18:33:05 2018 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Tue, 19 Jun 2018 18:33:05 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules Message-ID: Hi Bruce; I think this is a good start. I have a few comments and suggestions. Eventually, we should add this to the StarlingX wiki. The title is guidelines, but, you call out rules. We should change the line items to guidelines or guidelines/rules. Also, the guidelines/rules come across without context - what is the "why" for us to want to implement/follow these guidelines. We should add the following introductory paragraph or some variant: The following guidelines are offered to help us maintain an active, collaborative, innovative and inclusive project. The guidelines are here to help us maintain focus and we understand in some case there will be exceptions, but, lets discuss the exceptions openly and while understanding the benefits and consequences. On 2018-06-15, 3:32 PM, "Jones, Bruce E" wrote: I would like to propose the following basic development process for StarlingX. Instead of writing a long document, I will just propose a set of guidelines. Comments and feedback will be graciously accepted. Rule 1: We will follow all the usual open source and OpenStack conventions IJ >> I would recommend we add some references. Did you have some in mind? Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line. Rule 3: Code submissions should be reviewable (e.g. not thousands of lines). Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement. IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message? Rule 5: All code submissions shall have a Storyboard Story or Task associated with them and linked to in the commit message. Use the stx-* project that makes sense, or stx-upstream for upstream changes Rule 6: Code submissions for bug fixes can be posted to gerrit when ready IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard. Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code. IJ >> this is a good practice and will help us work efficiently. brucej _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From scott.little at windriver.com Tue Jun 19 18:42:11 2018 From: scott.little at windriver.com (Scott Little) Date: Tue, 19 Jun 2018 14:42:11 -0400 Subject: [Starlingx-discuss] Repo consolidation In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54A367@fmsmsx117.amr.corp.intel.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0AD5F0@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB5470FF@fmsmsx117.amr.corp.intel.com> <2588653EBDFFA34B982FAF00F1B4844EBB0AD885@ALA-MBD.corp.ad.wrs.com> <2588653EBDFFA34B982FAF00F1B4844EBB0ADF6F@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB549971@fmsmsx117.amr.corp.intel.com> <91BAF06A-4AA6-434B-B569-554957924315@windriver.com> <2c45cfbd-0fcb-ae1a-e46e-d1958cd6b377@windriver.com> <9A85D2917C58154C960D95352B22818BAB54A367@fmsmsx117.amr.corp.intel.com> Message-ID: I'd like to leave it to Brent to share any documents.  What I have is a draft and might not reflect the final intent.  Likewise for creating a story, I'd prefer that to our architect team. On 18-06-19 02:22 PM, Jones, Bruce E wrote: > > Cool.  Can we see the document?  Best way would be to create a Story > and enter the contents into the Story so we can all see it. > >      brucej > > *From:*Scott Little [mailto:scott.little at windriver.com] > *Sent:* Tuesday, June 19, 2018 7:40 AM > *To:* Jolliffe, Ian (Wind River) ; Jones, > Bruce E ; Rowsell, Brent (Wind River) > ; Cordoba Malibran, Erich > ; starlingx-discuss at lists.starlingx.io > *Cc:* Ambardekar, Pranjal > *Subject:* Re: [Starlingx-discuss] Repo consolidation > > Ok, I'll proceed with the reorg per Brent's  'Starlingx_setup_v3.xlxs' > document. > > I'll do the work piecewise, and leave relocating stx-gplv2/3 content > till last.  So there is still some time for discussion. > > Scott > > > On 18-06-19 10:04 AM, Jolliffe, Ian wrote: > > Hi Bruce; > > Thanks for your flexibility – we will proceed with consolidation. >  The fewer repos the better, it will be one place to monitor and > retire these changes. Maybe there are some ways to make the tool > work for us – instead of the other way around.  Let’s discuss on IRC. > > Regards; > > Ian > > *From: *"Jones, Bruce E" > > *Date: *Monday, June 18, 2018 at 5:40 PM > *To: *Brent Rowsell > , "CORDOBA MALIBRAN, ERICH" > > , > "starlingx-discuss at lists.starlingx.io" > > > > *Cc: *"AMBARDEKAR, PRANJAL" > > *Subject: *Re: [Starlingx-discuss] Repo consolidation > > I met with Pranjal and Abraham today to discuss this. > > The problem is that we separated that code out for a reason.  We > have an internal requirement to run a license scanning tool, and > the tool assumes that all of the code within a single git repo is > covered by the same license.  If you have files covered under > multiple licenses, it reports errors. > > It’s rather silly that we’re letting a tool dictate something like > this. > > We are setting up a process to run that tool on a regular basis, > so when it comes time to do a release, we don’t run into issues > that we didn’t already know about. > > It would not be the end of the world if someone submitted and > approved a PR to merge those repos.    It would make mine, > Abraham’s and Pranjal’s lives easier if we did not.  If you think > that this would make things better for everyone else, I would > withdraw my objection. > > Meanwhile, our goal is to get rid of those repos, long term. > >      Brucej > > *From:* Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] > *Sent:* Wednesday, June 13, 2018 12:00 PM > *To:* Cordoba Malibran, Erich > ; Jones, Bruce E > ; > starlingx-discuss at lists.starlingx.io > > *Cc:* Ambardekar, Pranjal > > *Subject:* RE: [Starlingx-discuss] Repo consolidation > > The objective over time is to eliminate the changes to these open > source packages by upstreaming the changes. > > Given that, I don’t think we want the overhead of > creating/managing 250 repos. This project already has 50 repos. > > Currently we have these packages spread over 4 repos with no real > functional division. > > I am proposing it would make more sense to consolidate into one. >  One repo to manage, making it easier to track the retirement of > customizations over time. > > Brent > > *From:* Cordoba Malibran, Erich > [mailto:erich.cordoba.malibran at intel.com] > *Sent:* Wednesday, June 13, 2018 2:43 PM > *To:* Rowsell, Brent >; JONES, BRUCE > >; > starlingx-discuss at lists.starlingx.io > > *Cc:* AMBARDEKAR, PRANJAL > > *Subject:* Re: [Starlingx-discuss] Repo consolidation > > This was a convenience separation. The license checking tool > expects to have a repository per project and a main license > defined for the entire repository. In this case, we wanted to > release the project as Apache License 2.0 and the tool assumes > that all the code inside the repository should has friendly > licenses. However, the tool found some conflicting components and > to solve the issue we move out those into the gplv2/3 repositories. > > This doesn’t mean that were actual license conflicts, it means > that this use case was outside of the scope of the tool. > > I would like to discuss the advantage of consolidation vs split, > I’m wondering if a model like CentOS has could help us, they have > a repository for each component. This will lead us to have around > 250 repositories (CentOS manages around 600) but I think that > managing each of them would be more easy. > > -Erich > > *From: *"Rowsell, Brent" > > *Date: *Wednesday, June 13, 2018 at 12:48 PM > *To: *"Jones, Bruce E" >, > "starlingx-discuss at lists.starlingx.io > " > > > *Cc: *"Ambardekar, Pranjal" > > *Subject: *Re: [Starlingx-discuss] Repo consolidation > > I don’t understand the distinction. There is already gpl code in > stx_integ. > > Brent > > *From:* Jones, Bruce E [mailto:bruce.e.jones at intel.com] > *Sent:* Wednesday, June 13, 2018 1:29 PM > *To:* Rowsell, Brent >; > starlingx-discuss at lists.starlingx.io > > *Cc:* AMBARDEKAR, PRANJAL > > *Subject:* RE: [Starlingx-discuss] Repo consolidation > > Objection. We separated those out to comply with software license > checking tools that we will still need to run. > > Pranjal and Abraham are the subject matter experts here.  If there > is a way to pass the code scanning tools and still combine these, > I would not object at all. > > brucej > > *From:* Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] > *Sent:* Wednesday, June 13, 2018 10:22 AM > *To:* starlingx-discuss at lists.starlingx.io > > *Subject:* [Starlingx-discuss] Repo consolidation > > I would like to propose that the following repo’s be consolidated > under stx-integ. > > * stx-gplv2 > * stx-gplv3 > * stx-upstream > > Any objections/comments ? > > Brent > > > > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io > > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue Jun 19 19:30:22 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 19 Jun 2018 21:30:22 +0200 Subject: [Starlingx-discuss] Culture? In-Reply-To: <0B566C62EC792145B40E29EFEBF1AB4710491989@fmsmsx104.amr.corp.intel.com> References: <0B566C62EC792145B40E29EFEBF1AB4710491989@fmsmsx104.amr.corp.intel.com> Message-ID: <6713C8F9-49B9-4574-A109-7753C81CEC47@gmail.com> Hi, On this topic I would like to point to the Community Code of Conduct[1] that the OpenStack Foundation has. We are using this for the OpenStack Community as well as referencing it on the StarlingX website already. The document is intended to ensure we are having an open and inclusive community in all our projects and is providing guidance to achieve that. Beyond this I would also like to point to the Four Opens[2] that are embraced by the OpenStack Foundation and serves as pillars for all the projects under the OpenStack Foundation umbrella. As the StarlingX project and community is forming the Foundation team will be sharing additional resources in the coming weeks. Thanks and Best Regards, Ildikó Váncsa Ecosystem Technical Lead, OpenStack Foundation [1] https://www.openstack.org/legal/community-code-of-conduct/ [2] https://governance.openstack.org/tc/reference/opens.html > On 2018. Jun 19., at 19:27, Lara, Cesar wrote: > > LGTM > > Regards > Cesar Lara > > -----Original Message----- > From: Jolliffe, Ian [mailto:Ian.Jolliffe at windriver.com] > Sent: Tuesday, June 19, 2018 9:47 AM > To: starlingx-discuss at lists.starlingx.io; Jones, Bruce E > Subject: [Starlingx-discuss] FW: Culture? > > > What do we want the culture of this project to be? > > Hi Bruce; > > Here are some thoughts, words/values to describe the culture we would aspire to create around StarlingX: > > Open > Inclusive > Diverse > Innovative > Friendly > Welcoming > Decisive > Flexible > > Regards; > > Ian > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From dtroyer at gmail.com Tue Jun 19 20:27:40 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Tue, 19 Jun 2018 15:27:40 -0500 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: Message-ID: On Tue, Jun 19, 2018 at 1:33 PM, Jolliffe, Ian wrote: > On 2018-06-15, 3:32 PM, "Jones, Bruce E" wrote: > Rule 1: We will follow all the usual open source and OpenStack conventions > > IJ >> I would recommend we add some references. Did you have some in mind? I've been saying we would fall back to OpenStack as a default in the absence of anything overriding. As we build our doc set adding references for things that both override or confirm those defaults would be useful. > Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. > > IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line. I think this is a distinct idea. A short review that does two things should be split. In the case of the upstream repos I will probably be noisy about this because of having to upstream things individually anyway. > Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement. > > IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message? "git commit -s" is sufficient. This requirement comes from the OpenStack project's intent to drop the CLA requirement in favor of DCO, and it seems like a simple thing to do from the start even if we don't have the same legal restrictions (I don't know if we do or not). LF was going to require it and enforce in Gerrit, we have that option if we want to use it. > Rule 6: Code submissions for bug fixes can be posted to gerrit when ready > > IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard. We are using only Storyboard where there is no intrinsic distinction between bugs and features. > Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code. > > IJ >> this is a good practice and will help us work efficiently. The one thing I might wiggle on this one is for posting WIP in order to do the 'review early' bit. If that is already inferred here for others great, I didn't read it that way. dt -- Dean Troyer dtroyer at gmail.com From yong.hu at intel.com Wed Jun 20 08:17:44 2018 From: yong.hu at intel.com (Hu, Yong) Date: Wed, 20 Jun 2018 08:17:44 +0000 Subject: [Starlingx-discuss] make StarlingX keep up with CentOS 7.5.1804? Message-ID: <18389F51-50C6-42C7-A921-0C7B34AA9D16@intel.com> Hey folks, Do we have incentive or plan to make StarlingX work with the recent CentOS 7.5.1804? Currently we see RPMs in the mirror are having relatively old versions. Regards, Yong From bruce.e.jones at intel.com Wed Jun 20 22:18:20 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 20 Jun 2018 22:18:20 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: Message-ID: <9A85D2917C58154C960D95352B22818BAB54AE97@fmsmsx117.amr.corp.intel.com> Thank you for the review and feedback. This is now on the wiki at https://wiki.openstack.org/wiki/StarlingX/Contribution_Guidelines Feedback/comments/edits encouraged and welcome! brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer at gmail.com] Sent: Tuesday, June 19, 2018 1:28 PM To: Jolliffe, Ian (Wind River) Cc: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules On Tue, Jun 19, 2018 at 1:33 PM, Jolliffe, Ian wrote: > On 2018-06-15, 3:32 PM, "Jones, Bruce E" wrote: > Rule 1: We will follow all the usual open source and OpenStack > conventions > > IJ >> I would recommend we add some references. Did you have some in mind? I've been saying we would fall back to OpenStack as a default in the absence of anything overriding. As we build our doc set adding references for things that both override or confirm those defaults would be useful. > Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. > > IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line. I think this is a distinct idea. A short review that does two things should be split. In the case of the upstream repos I will probably be noisy about this because of having to upstream things individually anyway. > Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement. > > IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message? "git commit -s" is sufficient. This requirement comes from the OpenStack project's intent to drop the CLA requirement in favor of DCO, and it seems like a simple thing to do from the start even if we don't have the same legal restrictions (I don't know if we do or not). LF was going to require it and enforce in Gerrit, we have that option if we want to use it. > Rule 6: Code submissions for bug fixes can be posted to gerrit > when ready > > IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard. We are using only Storyboard where there is no intrinsic distinction between bugs and features. > Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code. > > IJ >> this is a good practice and will help us work efficiently. The one thing I might wiggle on this one is for posting WIP in order to do the 'review early' bit. If that is already inferred here for others great, I didn't read it that way. dt -- Dean Troyer dtroyer at gmail.com From abraham.arce.moreno at intel.com Thu Jun 21 03:07:00 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 21 Jun 2018 03:07:00 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools In-Reply-To: <9A85D2917C58154C960D95352B22818BAB5481C1@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB5481C1@fmsmsx117.amr.corp.intel.com> Message-ID: It makes sense Bruce, thanks for your inputs! From: Jones, Bruce E Sent: Friday, June 15, 2018 1:13 PM To: Arce Moreno, Abraham ; starlingx-discuss at lists.starlingx.io Subject: RE: Software Development Methodologies and Tools We should follow the OpenStack documentation process and methodology, which I believe means that we can have documents that get published as web pages. The OpenStack Dev Guide is a great example to follow. I don't think we need to re-produce all of that content. Instead, we should point at that, and our document should cover where we are different. For instance, how to clone the repos and do builds and tests. How we use Storyboard. I believe the steps are something like: 1) Get the stx-docs repo created 2) Ramp on the steps needed to write documents and publish documents using OpenStack infra. See [1] 3) Create a landing page (replacing our Etherpad) and go from there and build out the docs. Abraham, please keep things more on the developer facing side. I want to work myself on the "how do we plan this project" side. Makes sense? [1] https://docs.openstack.org/doc-contrib-guide/index.html From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Thursday, June 14, 2018 3:31 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Software Development Methodologies and Tools Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a "software dev methodology and tools (repo, bug tracking, feature tracking, etc" How it should look like? Should be it a webpage? a document? Is our OpenStack Developer's Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Thu Jun 21 03:14:13 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 21 Jun 2018 03:14:13 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> Message-ID: > Rule 7: Code submissions for larger development tasks shall be discussed on > the mailing list _prior_ to code submission, to allow for community review > and feedback. Post early and often. Please review (and test!) each other's > code. What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance! From bruce.e.jones at intel.com Thu Jun 21 04:23:32 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 21 Jun 2018 04:23:32 +0000 Subject: [Starlingx-discuss] Software Development Methodologies and Tools In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB5481C1@fmsmsx117.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54AFA2@fmsmsx117.amr.corp.intel.com> Thank you Abraham! One change to the below - now that we have a wiki, we don't need 3) below. We can just link to the docs from the wiki, which now has a link to it from starlingx.io. brucej From: Arce Moreno, Abraham Sent: Wednesday, June 20, 2018 8:07 PM To: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: RE: Software Development Methodologies and Tools It makes sense Bruce, thanks for your inputs! From: Jones, Bruce E Sent: Friday, June 15, 2018 1:13 PM To: Arce Moreno, Abraham >; starlingx-discuss at lists.starlingx.io Subject: RE: Software Development Methodologies and Tools We should follow the OpenStack documentation process and methodology, which I believe means that we can have documents that get published as web pages. The OpenStack Dev Guide is a great example to follow. I don't think we need to re-produce all of that content. Instead, we should point at that, and our document should cover where we are different. For instance, how to clone the repos and do builds and tests. How we use Storyboard. I believe the steps are something like: 1) Get the stx-docs repo created 2) Ramp on the steps needed to write documents and publish documents using OpenStack infra. See [1] 3) Create a landing page (replacing our Etherpad) and go from there and build out the docs. Abraham, please keep things more on the developer facing side. I want to work myself on the "how do we plan this project" side. Makes sense? [1] https://docs.openstack.org/doc-contrib-guide/index.html From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Thursday, June 14, 2018 3:31 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Software Development Methodologies and Tools Our actual StarlingX Etherpad Main Page give us a great overview of the resources to get involved in our community [0] As a next step, in your experience, how would you suggest to approach the creation of a "software dev methodology and tools (repo, bug tracking, feature tracking, etc" How it should look like? Should be it a webpage? a document? Is our OpenStack Developer's Guide [1] a good example of how this could be implemented and tracked [2]? Any recommendation is highly valuable to allow us to propose a strong set resources for our community. Thanks in advance. [0] https://etherpad.openstack.org/p/starlingx [1] https://docs.openstack.org/infra/manual/developers.html [2] https://storyboard.openstack.org/#!/project/721 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cindy.xie at intel.com Thu Jun 21 06:19:18 2018 From: cindy.xie at intel.com (Xie, Cindy) Date: Thu, 21 Jun 2018 06:19:18 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> Message-ID: <2FD5DDB5A04D264C80D42CA35194914F2B2AD460@SHSMSX104.ccr.corp.intel.com> I am not quite sure if I understand below: Code submissions for bug fixes do not need to be reviewed before pushing to gerrit. Bug reports should be posted to Storyboard. Are you saying that patches for bug fixing do not required code-review + 1, +2 before it merged? Or you just are saying no [RFC] requests in mailing list shall be reviewed before bug-fixing patch got submitted? Thx. - cindy -----Original Message----- From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Thursday, June 21, 2018 11:14 AM To: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules > Rule 7: Code submissions for larger development tasks shall be > discussed on the mailing list _prior_ to code submission, to allow for > community review and feedback. Post early and often. Please review > (and test!) each other's code. What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ildiko.vancsa at gmail.com Thu Jun 21 07:15:08 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Thu, 21 Jun 2018 09:15:08 +0200 Subject: [Starlingx-discuss] StarlingX meeting at PTG Denver 2018 Message-ID: Hi, The PTG (https://www.openstack.org/ptg/) is a 5 days long meeting series to provide face to face time to project teams under the OpenStack Foundation umbrella. It is a great opportunity to discuss both project specific items and schedule cross-project collaborative sessions with other participating teams. StarlingX will have a scheduled meeting at the PTG, the exact schedule will be announced later. Below please find some information from my colleague Kendall on participating teams and administrative info on the PTG. Please make sure you register to the event early and have your hotel booked so you don’t miss the discounted rate if you’re planning to attend. Please add your name to the following etherpad if you plan on attending: https://etherpad.openstack.org/p/StarlingXPTG4 Feel free to ping me if you have any questions to the information below or about the PTG itself. Thanks and Best Regards, Ildikó (IRC: ildikov) ----------------------------------------------- Hello Everyone! Wanted to give you some updates on PTG4 planning. We have finalized the list of SIGs/ Groups/WGs/Teams that are attending. They are as follows: * Airship * API SIG * Barbican/Security SIG * Blazar * Chef OpenStack * Cinder * Cyborg * Designate * Documentation * Edge Computing Group * First Contact SIG * Glance * Heat * Horizon * Infrastructure * Interop WG * Ironic * Kata * Keystone * Kolla * LOCI * Manila * Masakari * Mistral * Monasca * Neutron * Nova * Octavia * OpenStack Ansible * OpenStack Charms * OpenStack Helm * OpenStackClient * Operator Meetup * Puppet OpenStack * QA * Oslo * Public Cloud WG * Release Management * Requirements * Sahara * Scientific SIG * Self-Healing SIG * SIG-K8s * StarlingX * Swift * OpenStack TC * TripleO * Upgrades SIG * Watcher * Zuul (pending confirmation) Thierry and I are working on placing them into a strawman schedule to reduce conflicts between related or overlapping groups. We should have more on what that will look like and a draft for you all to review in the next few weeks. We also wanted to remind you all of the Travel Support Program. We are again doing a two phase selection. The first deadline is approaching: July 1st. At this point we have less than a dozen applicants so if you need it or even think you need it, I urge you to apply here[1]. Also! Reminder that we have a finite number of rooms in the hotel block so please book early to make sure you get the discounted rate before they run out. You can book those rooms here[2] (pardon the ugly URL). Can't wait to see you all there! -Kendall Nelson (diablo_rojo) P.S. Gonna try to do a game night again since you all seemed to enjoy it so much last time :) [1] https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 [2] https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18&app=resvlink&stop_mobi=yes From scott.little at windriver.com Thu Jun 21 14:27:57 2018 From: scott.little at windriver.com (Scott Little) Date: Thu, 21 Jun 2018 10:27:57 -0400 Subject: [Starlingx-discuss] Directory restructuring Message-ID: <543bf93f-e31e-8f7b-17c2-622837ac74e5@windriver.com> The current directory structure leaves a lot to be desired. References to mwa and cgcs should be removed and the directory structure can be flattened a bit to reduce path lengths.  I propose to ... 1) Rename the mwa-* subdirectories, making the directory name match the git name.  e.g. mwa-sparta will be replaced by stx-integ. 2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with 'stx-utils' is not very attractive.  I'm thinking something more like 'packages' or 'src'.  Other options welcome. Can we agree this is a positive step?  Is it the right time to undertake this change?  Both changes in the same set of updates, or split them? It will require both a manifest change, and a number of updates to hard coded paths within various scripts. Grep is my friend, but I might need a little help identifying scripts not originating from Wind Rivers original code drop. I'm a little worried about out of tree or side branch copies of the manifests.  Thought on how to handle this? Scott Little From dtroyer at gmail.com Thu Jun 21 15:17:19 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 21 Jun 2018 10:17:19 -0500 Subject: [Starlingx-discuss] Directory restructuring In-Reply-To: <543bf93f-e31e-8f7b-17c2-622837ac74e5@windriver.com> References: <543bf93f-e31e-8f7b-17c2-622837ac74e5@windriver.com> Message-ID: On Thu, Jun 21, 2018 at 9:27 AM, Scott Little wrote: > The current directory structure leaves a lot to be desired. References to > mwa and cgcs should be removed and the directory structure can be flattened > a bit to reduce path lengths. I propose to ... > > 1) Rename the mwa-* subdirectories, making the directory name match the git > name. e.g. mwa-sparta will be replaced by stx-integ. ++ I naming the directories after the repo makes the most sense, thats fine, that's what we are all used to and where the mwa-* names came from before the Great Pivot. repo gives us the flexibility to do what makes the most sense here. > 2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with > 'stx-utils' is not very attractive. I'm thinking something more like > 'packages' or 'src'. Other options welcome. ++ I'm fine with a different name, not sure I have a better idea of what though. > Can we agree this is a positive step? Is it the right time to undertake > this change? Both changes in the same set of updates, or split them? Totally positive! My experiences say that this is the sort of thing that will be painful no matter when we do it, waiting for X usually means when X comes Y has appeared to wait on. I favor doing it as soon as we know what we want to do. I would split them into two sets of reviews though, I think that will make debugging a bit simpler with only one type of thing changing at a time. > It will require both a manifest change, and a number of updates to hard > coded paths within various scripts. Grep is my friend, but I might need a > little help identifying scripts not originating from Wind Rivers original > code drop. We'll be able to help there, I think most of those are concerned with things outside or next to the build tree, like the mirror creation. > I'm a little worried about out of tree or side branch copies of the > manifests. Thought on how to handle this? We can use Zulu/Gerrit's Depends-On capability to co-ordinate the merge of these reviews so we do not spend a significant amount of time with repos in a inconsistent state. Maybe make all of the (other) reviews depend on the manifest review, then we +W the manifest review last and Zulu will merge them all at roughly the same time. Right now there is only one manifest file in stx-manifest. The pain here will be all in-flight work affected, which is likely to be a lot of it. Ian has mentioned about 70 reviews queued up since R5 release, I suspect much of that would need to be rebased. This is the 'X' I mention above. If we hold the restructure to merge all of that first something else may come up in the mean time. I would like to hear from someone closer to those affected here about how to weigh this tradeoff. Thanks for kicking this off Scott dt -- Dean Troyer dtroyer at gmail.com From dtroyer at gmail.com Thu Jun 21 15:21:27 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 21 Jun 2018 10:21:27 -0500 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> Message-ID: On Wed, Jun 20, 2018 at 10:14 PM, Arce Moreno, Abraham wrote: > What is the usual way in OpenStack to review a proposal of a change? You push it to Gerrit. Often times people will put [WIP] at the beginning of the commit message to indicate it is not ready to be merged but you want comments or want to run the test jobs against it. There is also the "Workflow -1" (aka -W) that you can put on your own review that has the same effect. And comments are always helpful to clarify intent. Except for the -W part we can do exactly the same thing in the github repos. dt -- Dean Troyer dtroyer at gmail.com From bruce.e.jones at intel.com Thu Jun 21 15:23:06 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 21 Jun 2018 15:23:06 +0000 Subject: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 Message-ID: <9A85D2917C58154C960D95352B22818BAB54B528@fmsmsx117.amr.corp.intel.com> This bug is an issue that many of us have encountered - since the DPDK integration (the one Intel did internally), we are no longer able to bring the system up on a desktop within Virtual Box. It could be a bug in VB, in DPDK or somewhere else. Many of our devs use VB so this is a fairly high priority issue. This is currently assigned to Forrest but there might be folks on this list who can help. So I'm asking for help. :) bucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Thu Jun 21 15:26:06 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 21 Jun 2018 15:26:06 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54B556@fmsmsx117.amr.corp.intel.com> Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done? brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer at gmail.com] Sent: Thursday, June 21, 2018 8:21 AM To: Arce Moreno, Abraham Cc: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules On Wed, Jun 20, 2018 at 10:14 PM, Arce Moreno, Abraham wrote: > What is the usual way in OpenStack to review a proposal of a change? You push it to Gerrit. Often times people will put [WIP] at the beginning of the commit message to indicate it is not ready to be merged but you want comments or want to run the test jobs against it. There is also the "Workflow -1" (aka -W) that you can put on your own review that has the same effect. And comments are always helpful to clarify intent. Except for the -W part we can do exactly the same thing in the github repos. dt -- Dean Troyer dtroyer at gmail.com From Matt.Peters at windriver.com Thu Jun 21 15:31:35 2018 From: Matt.Peters at windriver.com (Peters, Matt) Date: Thu, 21 Jun 2018 15:31:35 +0000 Subject: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54B528@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54B528@fmsmsx117.amr.corp.intel.com> Message-ID: Several people are using the latest StarlingX build in VirtualBox with success. The recent update that integrates ovs-dpdk into the system configuration framework and an upgraded version of OVS has been tested with VirtualBox. Are people still having issue with the latest code base? I don't see any details of the actual issue encountered in the bug report. If this is still an issue, can we get additional details describing the problem added? Regards, Matt From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Thursday, June 21, 2018 11:23 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 This bug is an issue that many of us have encountered - since the DPDK integration (the one Intel did internally), we are no longer able to bring the system up on a desktop within Virtual Box. It could be a bug in VB, in DPDK or somewhere else. Many of our devs use VB so this is a fairly high priority issue. This is currently assigned to Forrest but there might be folks on this list who can help. So I'm asking for help. :) bucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Thu Jun 21 16:05:55 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 21 Jun 2018 16:05:55 +0000 Subject: [Starlingx-discuss] Proposal: Release Plan Message-ID: <9A85D2917C58154C960D95352B22818BAB54B5BD@fmsmsx117.amr.corp.intel.com> I would like to propose the following dates and milestones for the first StarlingX release. All of this is documented at https://etherpad.openstack.org/p/stx-planning. Please review and provide feedback. Going forward I'd like to figure out how to align with the overall OpenStack release cadence. That topic will be discussed at the September PTG - you can find the draft agenda at https://etherpad.openstack.org/p/stx-PTG-agenda. Please feel free to add any topics you'd like to see discussed there. brucej Release Planning We would like to complete our first release in time to have it available (and be able to talk about how cool it is!) at the OpenStack Summit in Berlin on November 13, 2018. Proposed schedule RC1: August 29th RC2: September 26th - Feature Freeze RC3: October 24th - Bug freeze - only absolutely critical bug fixes after this RC4: November 7th - Final release candidate Theme: Deliver a release of StarlingX that supports containers and meets our KPI targets while creating the basic project infrastructure, building the community and pushing carried patches to their upstream communities Our goals for this release are: * Create, define and document all of the basic project infrastructure * Recruit, attract and retain a community of developers and operators * Begin the process of pushing carried patches upstream and reducing technical debt * Add support for containerized Openstack Services and containerized workloads (stretch goal!) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Thu Jun 21 16:42:39 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 21 Jun 2018 16:42:39 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: <2FD5DDB5A04D264C80D42CA35194914F2B2AD460@SHSMSX104.ccr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> <2FD5DDB5A04D264C80D42CA35194914F2B2AD460@SHSMSX104.ccr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54B602@fmsmsx117.amr.corp.intel.com> Cindy, thanks. What I was trying to say is that since bugs should already be posted to Storyboard by the person who found them, they don't need any additional specs or discussion. Which isn't always the case, of course, since sometimes fixing a bug can require a big change. I've updated https://wiki.openstack.org/wiki/StarlingX/Contribution_Guidelines with the feedback from this thread. brucej -----Original Message----- From: Xie, Cindy Sent: Wednesday, June 20, 2018 11:19 PM To: Arce Moreno, Abraham ; Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Proposal: Basic development guidelines / rules I am not quite sure if I understand below: Code submissions for bug fixes do not need to be reviewed before pushing to gerrit. Bug reports should be posted to Storyboard. Are you saying that patches for bug fixing do not required code-review + 1, +2 before it merged? Or you just are saying no [RFC] requests in mailing list shall be reviewed before bug-fixing patch got submitted? Thx. - cindy -----Original Message----- From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com] Sent: Thursday, June 21, 2018 11:14 AM To: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules > Rule 7: Code submissions for larger development tasks shall be > discussed on the mailing list _prior_ to code submission, to allow for > community review and feedback. Post early and often. Please review > (and test!) each other's code. What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From dtroyer at gmail.com Thu Jun 21 17:27:02 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 21 Jun 2018 12:27:02 -0500 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54B556@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54B556@fmsmsx117.amr.corp.intel.com> Message-ID: On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E wrote: > Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done? We need to do something to review design and implementation. 'blueprint' is a launchpad term that is now overloaded in akraino so let's not use it. Some Openstack projects added a spec process, including a specs repo, to iterate on the design and implementation and worked that in Gerrit. That is not the best forum for some kinds of discussions so those often got held in Irc or the -dev mailing list. And some projects used both specs and blueprints. This is one area that I think we need to suss out what we actually want and not just fall back because there is no clear single precedent to borrow. At this point a single collection of documents and review process seems sufficient, we could manage them via Storyboard or follow the specs repo format. I don't have a strong opinion there. dt -- Dean Troyer dtroyer at gmail.com From chris.friesen at windriver.com Thu Jun 21 17:58:49 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Thu, 21 Jun 2018 11:58:49 -0600 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54B556@fmsmsx117.amr.corp.intel.com> Message-ID: <5B2BE759.7080901@windriver.com> On 06/21/2018 11:27 AM, Dean Troyer wrote: > On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E > wrote: >> Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done? > > We need to do something to review design and implementation. > 'blueprint' is a launchpad term that is now overloaded in akraino so > let's not use it. > > Some Openstack projects added a spec process, including a specs repo, > to iterate on the design and implementation and worked that in > Gerrit. That is not the best forum for some kinds of discussions so > those often got held in Irc or the -dev mailing list. And some > projects used both specs and blueprints. > > This is one area that I think we need to suss out what we actually > want and not just fall back because there is no clear single precedent > to borrow. At this point a single collection of documents and review > process seems sufficient, we could manage them via Storyboard or > follow the specs repo format. I don't have a strong opinion there. As I see it, the main benefit of an OpenStack spec is that it goes through Gerrit and thus lets people review and comment on the iterations of the design. It also lets you go back years later and maybe figure out why things were done the way they were. I think that it's valuable to allow people to comment on in-progress designs, so as long as there's some way to do that I don't care about the exact mechanism. Chris From ildiko.vancsa at gmail.com Thu Jun 21 18:29:23 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Thu, 21 Jun 2018 20:29:23 +0200 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: <5B2BE759.7080901@windriver.com> References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54B556@fmsmsx117.amr.corp.intel.com> <5B2BE759.7080901@windriver.com> Message-ID: <0D69B00D-94DF-4F11-9162-695AAE7149C1@gmail.com> Hi, To chime in a little, I would suggest to keep the processes as simple as possible to start with. StoryBoard gives opportunities to add a description and also comments to a story so it can be a good forum to start with. You can always define a template to follow and/or use Gerrit for new specs later. Starting with simpler processes will help new comers to join your community easier which is extremely important in this phase. You can evolve the processes as the community grows and you identify bottlenecks or some missing steps. Thanks and Best Regards, Ildikó Váncsa Ecosystem Technical Lead, OpenStack Foundation (IRC: ildikov) > On 2018. Jun 21., at 19:58, Chris Friesen wrote: > > On 06/21/2018 11:27 AM, Dean Troyer wrote: >> On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E >> wrote: >>> Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done? >> >> We need to do something to review design and implementation. >> 'blueprint' is a launchpad term that is now overloaded in akraino so >> let's not use it. >> >> Some Openstack projects added a spec process, including a specs repo, >> to iterate on the design and implementation and worked that in >> Gerrit. That is not the best forum for some kinds of discussions so >> those often got held in Irc or the -dev mailing list. And some >> projects used both specs and blueprints. >> >> This is one area that I think we need to suss out what we actually >> want and not just fall back because there is no clear single precedent >> to borrow. At this point a single collection of documents and review >> process seems sufficient, we could manage them via Storyboard or >> follow the specs repo format. I don't have a strong opinion there. > > As I see it, the main benefit of an OpenStack spec is that it goes through Gerrit and thus lets people review and comment on the iterations of the design. It also lets you go back years later and maybe figure out why things were done the way they were. > > I think that it's valuable to allow people to comment on in-progress designs, so as long as there's some way to do that I don't care about the exact mechanism. > > Chris > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From abraham.arce.moreno at intel.com Thu Jun 21 20:53:38 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Thu, 21 Jun 2018 20:53:38 +0000 Subject: [Starlingx-discuss] Proposal: Basic development guidelines / rules In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB548235@fmsmsx117.amr.corp.intel.com> Message-ID: > > What is the usual way in OpenStack to review a proposal of a change? > > You push it to Gerrit. Often times people will put [WIP] at the beginning of > the commit message to indicate it is not ready to be merged but you want > comments or want to run the test jobs against it. > There is also the "Workflow -1" (aka -W) that you can put on your own review > that has the same effect. And comments are always helpful to clarify intent. > > Except for the -W part we can do exactly the same thing in the github repos. Understood Dean! Thanks! From thierry at openstack.org Fri Jun 22 12:18:24 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 22 Jun 2018 14:18:24 +0200 Subject: [Starlingx-discuss] Proposal: Release Plan In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54B5BD@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54B5BD@fmsmsx117.amr.corp.intel.com> Message-ID: Jones, Bruce E wrote: > [...] > Going forward I’d like to figure out how to align with the overall > OpenStack release cadence.  That topic will be discussed at the > September PTG – you can find the draft agenda at > https://etherpad.openstack.org/p/stx-PTG-agenda.  Please feel free to > add any topics you’d like to see discussed there. I'll try to join on that discussion ! > [...] > *Proposed schedule* > > RC1: August 29th > > RC2: September 26th - Feature Freeze > > RC3: October 24th - Bug freeze - only absolutely critical bug fixes > after this > > RC4: November 7th - Final release candidate If that is something you can change, I'd recommend that you keep the "RC" term for real release candidates -- things that could, at least in theory, be used as final releases. At the very least, RCs should be feature complete. Otherwise if you use them as basic development milestones, you dilute their meaning, which makes it harder to encourage people outside of your core group to actually test them. So I'd recommend using "beta1", "beta2"... for feature-incomplete milestones, and switch to "rc1" once you reach bug freeze :) Regards, -- Thierry Carrez (ttx) OpenStack Release Management team From scott.little at windriver.com Mon Jun 25 17:16:56 2018 From: scott.little at windriver.com (Scott Little) Date: Mon, 25 Jun 2018 13:16:56 -0400 Subject: [Starlingx-discuss] Updating SHA pointers in build system. In-Reply-To: References: <908219E2-D0E0-4DE2-8589-3BA570C7EBC4@intel.com> <3a6ebf98-8b13-a141-a9aa-554337a3cf98@windriver.com> <80E3C733-E12C-4B60-8DE6-5211F1F4D5C9@intel.com> Message-ID: <38a179a3-6497-4c27-010a-76bcdc63aaf1@windriver.com> I had a look at the tools. A tag should work. stx-r1-upstream is our tag for the upstream PARENT of the first STX commit? That's good to know, and yes we should be consistent across all upstream gits. On 18-06-18 01:29 PM, Dean Troyer wrote: > On Mon, Jun 18, 2018 at 11:09 AM, Cordoba Malibran, Erich > wrote: >> Ok, I'll update the missing references on these components. >> >> ceph/centos/build_srpm.data >> devtools/qemu/centos/build_srpm.data >> openstack/openstack-ras/centos/build_srpm.data >> openstack/python-ceilometerclient/centos/build_srpm.data >> openstack/python-openstacksdk/centos/build_srpms.data > Ah, they are all upstream repos on github. We could tag the squash > commit as a starting point (there is one for the upstream parent to > the squash commit, stx-r1-upstream) if that would be helpful. > > dt > From bruce.e.jones at intel.com Mon Jun 25 23:02:52 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Mon, 25 Jun 2018 23:02:52 +0000 Subject: [Starlingx-discuss] Proposal: Release Plan In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB54B5BD@fmsmsx117.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54D04E@fmsmsx117.amr.corp.intel.com> Thierry, thank you for the feedback! You're recommending something like this, right? Beta1: August 29th Beta2: September 26th - Feature Freeze RC1, 2, 3...: October 24th - Bug freeze - only absolutely critical bug fixes RCx: November 7th - Final release candidate Brucej -----Original Message----- From: Thierry Carrez [mailto:thierry at openstack.org] Sent: Friday, June 22, 2018 5:18 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Release Plan Jones, Bruce E wrote: > [...] > Going forward I’d like to figure out how to align with the overall > OpenStack release cadence.  That topic will be discussed at the > September PTG – you can find the draft agenda at > https://etherpad.openstack.org/p/stx-PTG-agenda.  Please feel free to > add any topics you’d like to see discussed there. I'll try to join on that discussion ! > [...] > *Proposed schedule* > > RC1: August 29th > > RC2: September 26th - Feature Freeze > > RC3: October 24th - Bug freeze - only absolutely critical bug fixes > after this > > RC4: November 7th - Final release candidate If that is something you can change, I'd recommend that you keep the "RC" term for real release candidates -- things that could, at least in theory, be used as final releases. At the very least, RCs should be feature complete. Otherwise if you use them as basic development milestones, you dilute their meaning, which makes it harder to encourage people outside of your core group to actually test them. So I'd recommend using "beta1", "beta2"... for feature-incomplete milestones, and switch to "rc1" once you reach bug freeze :) Regards, -- Thierry Carrez (ttx) OpenStack Release Management team _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From thierry at openstack.org Tue Jun 26 07:34:32 2018 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 26 Jun 2018 09:34:32 +0200 Subject: [Starlingx-discuss] Proposal: Release Plan In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54D04E@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54B5BD@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54D04E@fmsmsx117.amr.corp.intel.com> Message-ID: <14a5a9b5-e8af-0127-40c4-05e6c99b55bf@openstack.org> Jones, Bruce E wrote: > Thierry, thank you for the feedback! > > You're recommending something like this, right? > Beta1: August 29th > Beta2: September 26th - Feature Freeze > RC1, 2, 3...: October 24th - Bug freeze - only absolutely critical bug fixes > RCx: November 7th - Final release candidate Yes, that would be my recommendation. Regards, -- Thierry Carrez (ttx) From humberto.i.perez.rodriguez at intel.com Tue Jun 26 13:59:28 2018 From: humberto.i.perez.rodriguez at intel.com (Perez Rodriguez, Humberto I) Date: Tue, 26 Jun 2018 13:59:28 +0000 Subject: [Starlingx-discuss] Questions regarding WR text Message-ID: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> Hi: I am wondering if this kind of text from WR should be there: https://github.intel.com/Madawaska/mwa-beas/blob/intel_r1/kickstart/centos/platform-kickstarts.spec#L6 Cheers [cid:image001.png at 01CF8BAC.3B4C5DD0] Humberto Perez OTC Linux Graphics OpenSource Technology Center Project: 01.org Intel Open Source Intel(r) Graphics for Linux iNet 8-645-2968 Before printing this email, consider your Environmental Responsibility! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4914 bytes Desc: image001.png URL: From dtroyer at gmail.com Tue Jun 26 21:08:56 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Tue, 26 Jun 2018 16:08:56 -0500 Subject: [Starlingx-discuss] Questions regarding WR text In-Reply-To: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> References: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> Message-ID: On Tue, Jun 26, 2018 at 8:59 AM, Perez Rodriguez, Humberto I < humberto.i.perez.rodriguez at intel.com> wrote: > I am wondering if this kind of text from WR should be there: > > https://github.intel.com/Madawaska/mwa-beas/blob/intel_ > r1/kickstart/centos/platform-kickstarts.spec#L6 > Why not? That accurately reflects the source of that package. Note that the link you used is internal-only and nobody outside Intel can see it. The link to the public repo is https://git.openstack.org/cgit/openstack/stx-metal/tree/kickstart/centos/platform-kickstarts.spec#n6 dt -- Dean Troyer dtroyer at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Tue Jun 26 21:42:41 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Tue, 26 Jun 2018 21:42:41 +0000 Subject: [Starlingx-discuss] Questions regarding WR text In-Reply-To: References: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54D7C0@fmsmsx117.amr.corp.intel.com> Should the source of that package be shown as StarlingX? From: Dean Troyer [mailto:dtroyer at gmail.com] Sent: Tuesday, June 26, 2018 2:09 PM To: Perez Rodriguez, Humberto I Cc: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Questions regarding WR text On Tue, Jun 26, 2018 at 8:59 AM, Perez Rodriguez, Humberto I > wrote: I am wondering if this kind of text from WR should be there: https://github.intel.com/Madawaska/mwa-beas/blob/intel_r1/kickstart/centos/platform-kickstarts.spec#L6 Why not? That accurately reflects the source of that package. Note that the link you used is internal-only and nobody outside Intel can see it. The link to the public repo is https://git.openstack.org/cgit/openstack/stx-metal/tree/kickstart/centos/platform-kickstarts.spec#n6 dt -- Dean Troyer dtroyer at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Tue Jun 26 22:10:31 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Tue, 26 Jun 2018 17:10:31 -0500 Subject: [Starlingx-discuss] Questions regarding WR text In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54D7C0@fmsmsx117.amr.corp.intel.com> References: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54D7C0@fmsmsx117.amr.corp.intel.com> Message-ID: On Tue, Jun 26, 2018 at 4:42 PM, Jones, Bruce E wrote: > Should the source of that package be shown as StarlingX? I'm going to stick with my original answer and say no, it is fine to leave it saying Wind River, they wrote it. They retain the copyright on the things they wrote just as any other company retains copyright on the things they write and contribute. dt -- Dean Troyer dtroyer at gmail.com From bruce.e.jones at intel.com Tue Jun 26 22:12:04 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Tue, 26 Jun 2018 22:12:04 +0000 Subject: [Starlingx-discuss] Questions regarding WR text In-Reply-To: References: <2059E488B16E7849A605514C80A887EDB9B86E95@FMSMSX108.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54D7C0@fmsmsx117.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54D807@fmsmsx117.amr.corp.intel.com> Makes sense, thanks! -----Original Message----- From: Dean Troyer [mailto:dtroyer at gmail.com] Sent: Tuesday, June 26, 2018 3:11 PM To: Jones, Bruce E Cc: Perez Rodriguez, Humberto I ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Questions regarding WR text On Tue, Jun 26, 2018 at 4:42 PM, Jones, Bruce E wrote: > Should the source of that package be shown as StarlingX? I'm going to stick with my original answer and say no, it is fine to leave it saying Wind River, they wrote it. They retain the copyright on the things they wrote just as any other company retains copyright on the things they write and contribute. dt -- Dean Troyer dtroyer at gmail.com From chris.friesen at windriver.com Wed Jun 27 18:43:12 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 27 Jun 2018 12:43:12 -0600 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies Message-ID: <5B33DAC0.3080802@windriver.com> Hi all, Recently we had an issue where https://review.openstack.org/#/c/578414/ was given +W before https://review.openstack.org/#/c/578413/ (which it was dependent on and was in another project) was merged. This caused https://review.openstack.org/#/c/578414/ to get "stuck" requiring a core to remove the workflow approval and re-add it, which "woke up" the process and got it merged. Talking with the folks on #openstack-infra, they said that the problem was that the two projects don't share a gate queue. In that case you can't approve a change with "depends-on" until the depended-on change has merged. The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. Chris From dtroyer at gmail.com Wed Jun 27 19:12:16 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 27 Jun 2018 14:12:16 -0500 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: <5B33DAC0.3080802@windriver.com> References: <5B33DAC0.3080802@windriver.com> Message-ID: On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen wrote: > The automated way to handle this is to have all the potentially > interdependent projects share a queue by specifying a common queue name. > The example given was the "integrated" queue for nova and friends, as > specified at > https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532 > This does potentially introduce merge delays since it will serialize merges > across all the projects that share a queue, but for tightly-coupled projects > it might make sense. It think totally makes sense here... dt -- Dean Troyer dtroyer at gmail.com From chris.friesen at windriver.com Wed Jun 27 19:23:12 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 27 Jun 2018 13:23:12 -0600 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: References: <5B33DAC0.3080802@windriver.com> Message-ID: <5B33E420.302@windriver.com> On 06/27/2018 01:12 PM, Dean Troyer wrote: > On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen > wrote: >> The automated way to handle this is to have all the potentially >> interdependent projects share a queue by specifying a common queue name. >> The example given was the "integrated" queue for nova and friends, as >> specified at >> https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 > > Dang, I forgot this bit when setting up the jobs, so something like > this? https://review.openstack.org/578532 Looks reasonable, but I'm no expert here. Chris From scott.little at windriver.com Wed Jun 27 19:31:59 2018 From: scott.little at windriver.com (Scott Little) Date: Wed, 27 Jun 2018 15:31:59 -0400 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: References: <5B33DAC0.3080802@windriver.com> Message-ID: <6196520f-0373-9dd5-decf-98e96c81a634@windriver.com> Agreed, I don't think we can function without it. Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention? If the depended on review is failed or abandoned, can the blocked review by automatically dequeued?  Demoted to W0?  Ideally with a notification? Scott On 18-06-27 03:12 PM, Dean Troyer wrote: > On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen > wrote: >> The automated way to handle this is to have all the potentially >> interdependent projects share a queue by specifying a common queue name. >> The example given was the "integrated" queue for nova and friends, as >> specified at >> https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 > Dang, I forgot this bit when setting up the jobs, so something like > this? https://review.openstack.org/578532 > >> This does potentially introduce merge delays since it will serialize merges >> across all the projects that share a queue, but for tightly-coupled projects >> it might make sense. > It think totally makes sense here... > > dt > From Ian.Jolliffe at windriver.com Wed Jun 27 19:57:34 2018 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Wed, 27 Jun 2018 19:57:34 +0000 Subject: [Starlingx-discuss] Proposal: Release Plan Message-ID: <1E3BD7B5-DE02-4A0A-88D0-A74378D8BF33@windriver.com> Hi Bruce; Thanks for the proposal, we need to get more clarity around it. If we define the key terms this will help ensure common understanding across the community. A repeatable CI/CD pipeline in place is critical, I have added an objective to the release goals. I have put some comments on the etherpad. Regards; Ian From: "Jones, Bruce E" Date: Thursday, June 21, 2018 at 12:05 PM To: "starlingx-discuss at lists.starlingx.io" Subject: [Starlingx-discuss] Proposal: Release Plan I would like to propose the following dates and milestones for the first StarlingX release. All of this is documented at https://etherpad.openstack.org/p/stx-planning. Please review and provide feedback. Going forward I’d like to figure out how to align with the overall OpenStack release cadence. That topic will be discussed at the September PTG – you can find the draft agenda at https://etherpad.openstack.org/p/stx-PTG-agenda. Please feel free to add any topics you’d like to see discussed there. brucej Release Planning We would like to complete our first release in time to have it available (and be able to talk about how cool it is!) at the OpenStack Summit in Berlin on November 13, 2018. Proposed schedule RC1: August 29th RC2: September 26th - Feature Freeze RC3: October 24th - Bug freeze - only absolutely critical bug fixes after this RC4: November 7th - Final release candidate Theme: Deliver a release of StarlingX that supports containers and meets our KPI targets while creating the basic project infrastructure, building the community and pushing carried patches to their upstream communities Our goals for this release are: · Create, define and document all of the basic project infrastructure · Recruit, attract and retain a community of developers and operators · Begin the process of pushing carried patches upstream and reducing technical debt · Add support for containerized Openstack Services and containerized workloads (stretch goal!) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Wed Jun 27 23:48:03 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 27 Jun 2018 23:48:03 +0000 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal Message-ID: <9A85D2917C58154C960D95352B22818BAB54E25A@fmsmsx117.amr.corp.intel.com> At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we'd like to follow the "bus stop" model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned "Release 2" should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that "our current November release is the first quarterly release", I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be "stx.2018.07". The version number of that build would be "stx.2018.07.0x", where "0x" is a patch number. Yes, that's a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a "latest known to be good" build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter's quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month's (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling "Release 2" will need to change. If this proposal is accepted, we won't have a "release 2" anymore, just a "release stx.2018.08.x" released in September and "release stx 2018.11.x" released in December. This changes the content we'd have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it's inevitable that the StarlingX project has separate / different version numbers from TC, but I don't know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yong.hu at intel.com Thu Jun 28 00:51:46 2018 From: yong.hu at intel.com (Hu, Yong) Date: Thu, 28 Jun 2018 00:51:46 +0000 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal Message-ID: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release? Could it be acceptable if we break down a big story into several small items which come out in following multiple months, or even quarters? Regards Yong From: "Jones, Bruce E" Date: Thursday, 28 June 2018 at 7:48 AM To: "starlingx-discuss at lists.starlingx.io" Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we’d like to follow the “bus stop” model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned “Release 2” should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that “our current November release is the first quarterly release”, I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be “stx.2018.07”. The version number of that build would be “stx.2018.07.0x”, where “0x” is a patch number. Yes, that’s a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a “latest known to be good” build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter’s quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month’s (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling “Release 2” will need to change. If this proposal is accepted, we won’t have a “release 2” anymore, just a “release stx.2018.08.x” released in September and “release stx 2018.11.x” released in December. This changes the content we’d have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it’s inevitable that the StarlingX project has separate / different version numbers from TC, but I don’t know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erich.cordoba.malibran at intel.com Thu Jun 28 04:18:07 2018 From: erich.cordoba.malibran at intel.com (Cordoba Malibran, Erich) Date: Thu, 28 Jun 2018 04:18:07 +0000 Subject: [Starlingx-discuss] Cannot build due to missing memcached dependencies Message-ID: <901E3663-5DED-454D-A578-20D8DD190041@intel.com> Hi all, Some days ago the memcached package was added into StarlingX[0], as the new packages weren't included in the mirror downloader tool I sent a review to add them[1]. However I'm having problems to build memcached due to these missing dependencies: - perl-generators - perl-Test-Harness - perl-Test-More I can get the first two, but I'm unable to find perl-Test-More. Do you know from where I can get that package? Thanks -Erich [0] https://review.openstack.org/#/c/577485/ [1] https://review.openstack.org/#/c/578176/ From bruce.e.jones at intel.com Thu Jun 28 04:28:00 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 28 Jun 2018 04:28:00 +0000 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal In-Reply-To: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> References: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54E35C@fmsmsx117.amr.corp.intel.com> Yong, the proposal is for time based releases. When the features are ready, they get released. In terms of what gets released when, I’d like to see us do bottoms up planning, and yes it’s OK to break large efforts up into multiple items. Please feel free to do so. brucej From: Hu, Yong Sent: Wednesday, June 27, 2018 5:52 PM To: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] RFC: StarlingX release cadence proposal Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release? Could it be acceptable if we break down a big story into several small items which come out in following multiple months, or even quarters? Regards Yong From: "Jones, Bruce E" > Date: Thursday, 28 June 2018 at 7:48 AM To: "starlingx-discuss at lists.starlingx.io" > Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we’d like to follow the “bus stop” model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned “Release 2” should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that “our current November release is the first quarterly release”, I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be “stx.2018.07”. The version number of that build would be “stx.2018.07.0x”, where “0x” is a patch number. Yes, that’s a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a “latest known to be good” build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter’s quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month’s (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling “Release 2” will need to change. If this proposal is accepted, we won’t have a “release 2” anymore, just a “release stx.2018.08.x” released in September and “release stx 2018.11.x” released in December. This changes the content we’d have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it’s inevitable that the StarlingX project has separate / different version numbers from TC, but I don’t know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Thu Jun 28 13:25:44 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 28 Jun 2018 08:25:44 -0500 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal In-Reply-To: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> References: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> Message-ID: On Wed, Jun 27, 2018 at 7:51 PM, Hu, Yong wrote: > Given we have a planning board, what would be the mechanism to vote the > contents (stories) as the targets of monthly release or quarterly release? To be clear, we don't really have a planning board. There is no official governance yet. What we do have is consensus among the two primary groups (Wind River and Intel) involved in the project before the public release to continue our work openly in basically our current fashion until we do have governance. My brain parses that as our mechanism is now to have the discussions here (on the mailing list) and in IRC to find the consensus for the questions that come up, like the topic Bruce is raising in this thread. dt P.S. We still have "the weekly meeting problem" (this is the call on Wednesday evening UTC that Bruce refers to) that has yet to be solved. The transition from the current practice to a new one is not going to be instant and I think we can learn a lot from the experiences of other communities (contrast current OpenStack and Kubernetes practices for example) but in the end I fear we will have to learn these lessons the long way around. -- Dean Troyer dtroyer at gmail.com From yong.hu at intel.com Thu Jun 28 13:57:12 2018 From: yong.hu at intel.com (Hu, Yong) Date: Thu, 28 Jun 2018 13:57:12 +0000 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal In-Reply-To: References: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> Message-ID: <64533F74-9BB6-481C-9246-9D50D28E2219@intel.com> Okay, understood. We would get consensus by mailing list and IRC. I am thinking how we make the discussion efficient. For example, probably before kicking off the discussion, we need to create a "story" in which we at least describe what the requirement is about and why we need it. Regards, Yong On 28/06/2018, 9:26 PM, "Dean Troyer" wrote: On Wed, Jun 27, 2018 at 7:51 PM, Hu, Yong wrote: > Given we have a planning board, what would be the mechanism to vote the > contents (stories) as the targets of monthly release or quarterly release? To be clear, we don't really have a planning board. There is no official governance yet. What we do have is consensus among the two primary groups (Wind River and Intel) involved in the project before the public release to continue our work openly in basically our current fashion until we do have governance. My brain parses that as our mechanism is now to have the discussions here (on the mailing list) and in IRC to find the consensus for the questions that come up, like the topic Bruce is raising in this thread. dt P.S. We still have "the weekly meeting problem" (this is the call on Wednesday evening UTC that Bruce refers to) that has yet to be solved. The transition from the current practice to a new one is not going to be instant and I think we can learn a lot from the experiences of other communities (contrast current OpenStack and Kubernetes practices for example) but in the end I fear we will have to learn these lessons the long way around. -- Dean Troyer dtroyer at gmail.com From chris.friesen at windriver.com Thu Jun 28 15:18:04 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Thu, 28 Jun 2018 09:18:04 -0600 Subject: [Starlingx-discuss] Cannot build due to missing memcached dependencies In-Reply-To: <901E3663-5DED-454D-A578-20D8DD190041@intel.com> References: <901E3663-5DED-454D-A578-20D8DD190041@intel.com> Message-ID: <5B34FC2C.5010205@windriver.com> On 06/27/2018 10:18 PM, Cordoba Malibran, Erich wrote: > However I'm having problems to build memcached due to these missing dependencies: > > - perl-generators > - perl-Test-Harness > - perl-Test-More > > I can get the first two, but I'm unable to find perl-Test-More. Do you know from where I can get that package? This says it provides it: https://rpmfind.net/linux/RPM/centos/7.5.1804/x86_64/Packages/perl-Test-Simple-0.98-243.el7.noarch.html I think this is the official link: https://centos.pkgs.org/7/centos-x86_64/perl-Test-Simple-0.98-243.el7.noarch.rpm.html Chris From hazzim.i.anaya.casas at intel.com Thu Jun 28 15:50:45 2018 From: hazzim.i.anaya.casas at intel.com (Anaya casas, Hazzim I) Date: Thu, 28 Jun 2018 15:50:45 +0000 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: <6196520f-0373-9dd5-decf-98e96c81a634@windriver.com> References: <5B33DAC0.3080802@windriver.com> <6196520f-0373-9dd5-decf-98e96c81a634@windriver.com> Message-ID: I believe the concern is related to this config in Zuul and we need to take advantage of this feature. Cross Project Testing When your projects are closely coupled together, you want to make sure changes entering the gate are going to be tested with the version of other projects currently enqueued in the gate (since they will eventually be merged and might introduce breaking features). Such relationships can be defined in Zuul configuration by placing projects in a shared queue within a dependent pipeline. Whenever changes for any project enter a pipeline with such a shared queue, they are tested together, such that the commits for the changes ahead in the queue are automatically present in the jobs for the changes behind them. https://zuul-ci.org/docs/zuul/user/gating.html On Jun 27, 2018, at 14:31, Scott Little > wrote: Agreed, I don't think we can function without it. Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention? If the depended on review is failed or abandoned, can the blocked review by automatically dequeued? Demoted to W0? Ideally with a notification? Scott On 18-06-27 03:12 PM, Dean Troyer wrote: On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen > wrote: The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532 This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. It think totally makes sense here... dt _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Thu Jun 28 16:39:33 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 28 Jun 2018 11:39:33 -0500 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal In-Reply-To: <64533F74-9BB6-481C-9246-9D50D28E2219@intel.com> References: <45A6E967-52B1-48BF-B7E1-AE675DC739ED@intel.com> <64533F74-9BB6-481C-9246-9D50D28E2219@intel.com> Message-ID: On Thu, Jun 28, 2018 at 8:57 AM, Hu, Yong wrote: > For example, probably before kicking off the discussion, we need to create a "story" in which we at least describe what the requirement is about and why we need it. That is a good idea particularly if it is a large feature. Storyboard, ether pad, wiki are all possibilities to put these, each with advantages and disadvantages.[0] Just posting here is also valid, this list is logged and links to a specific message are easy to get.[1] I personally think etherpad is a great way to start out for brainstorming or notes from an in-person or IRC discussion, particularly when working in near-real-time (design summit/forum sessions are a great example here). Once an idea has solidified moving it to a more permanent and discoverable location is good (wiki, SB, review). Even though etherpad is backed up and they exist "forever" they are intentionally not indexed or discoverable and the history isn't the easiest thing to dig through. There are other ways that suit other people or situations better. dt [0] I've found by experience that large features generate a small-to-modest amount of discussion while we (developers) are capable of bike shedding a small thing to death. [1] start here: http://lists.starlingx.io/pipermail/starlingx-discuss/ -- Dean Troyer dtroyer at gmail.com From Jack.Ding at windriver.com Thu Jun 28 17:12:03 2018 From: Jack.Ding at windriver.com (Ding, Jack) Date: Thu, 28 Jun 2018 17:12:03 +0000 Subject: [Starlingx-discuss] Zuul is not automatically added to reviewer list Message-ID: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> Was there any config changes related to Zuul done lately? I pushed a few reviews in stx-config but Zuul was not added to the Reviewers list. It was added automatically a few days ago when I push to same repo. Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Thu Jun 28 17:26:23 2018 From: claire at openstack.org (Claire Massey) Date: Thu, 28 Jun 2018 12:26:23 -0500 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: References: <5B33DAC0.3080802@windriver.com> <6196520f-0373-9dd5-decf-98e96c81a634@windriver.com> Message-ID: <63257AAD-B4AB-4C7D-84C1-EA9450669984@openstack.org> Hi there, The best way to reach the Zuul team directly to share these types of requests is to ping their ML at zuul-discuss at lists.zuul-ci.org . You can subscribe to it here: http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss . You can also ping them in Freenode IRC at #zuul. Thanks, Claire > On Jun 28, 2018, at 10:50 AM, Anaya casas, Hazzim I wrote: > > I believe the concern is related to this config in Zuul and we need to take advantage of this feature. > > Cross Project Testing > When your projects are closely coupled together, you want to make sure changes entering the gate are going to be tested with the version of other projects currently enqueued in the gate (since they will eventually be merged and might introduce breaking features). > > Such relationships can be defined in Zuul configuration by placing projects in a shared queue within a dependent pipeline. Whenever changes for any project enter a pipeline with such a shared queue, they are tested together, such that the commits for the changes ahead in the queue are automatically present in the jobs for the changes behind them. > > https://zuul-ci.org/docs/zuul/user/gating.html > > > > >> On Jun 27, 2018, at 14:31, Scott Little > wrote: >> >> Agreed, I don't think we can function without it. >> >> Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention? >> >> If the depended on review is failed or abandoned, can the blocked review by automatically dequeued? Demoted to W0? Ideally with a notification? >> >> Scott >> >> >> On 18-06-27 03:12 PM, Dean Troyer wrote: >>> On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen >>> > wrote: >>>> The automated way to handle this is to have all the potentially >>>> interdependent projects share a queue by specifying a common queue name. >>>> The example given was the "integrated" queue for nova and friends, as >>>> specified at >>>> https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108 >>> Dang, I forgot this bit when setting up the jobs, so something like >>> this? https://review.openstack.org/578532 >>> >>>> This does potentially introduce merge delays since it will serialize merges >>>> across all the projects that share a queue, but for tightly-coupled projects >>>> it might make sense. >>> It think totally makes sense here... >>> >>> dt >>> >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Thu Jun 28 17:30:18 2018 From: claire at openstack.org (Claire Massey) Date: Thu, 28 Jun 2018 12:30:18 -0500 Subject: [Starlingx-discuss] Zuul is not automatically added to reviewer list In-Reply-To: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> Message-ID: <8CA7C914-7B23-4DA8-BBE5-F718E956A5EA@openstack.org> Hi there, Feel free to reach out to the Infra team directly for questions like this one. You can find them in Freenode IRC at #openstack-infra or their mailing list at openstack-infra at lists.openstack.org . Also, if you want to add some of these StarlingX specific items to the next Infra team meeting agenda, they meet on Tuesdays at 1900 UTC in IRC at #openstack-meeting. Cheers, Claire > On Jun 28, 2018, at 12:12 PM, Ding, Jack wrote: > > Was there any config changes related to Zuul done lately? I pushed a few reviews in stx-config but Zuul was not added to the Reviewers list. It was added automatically a few days ago when I push to same repo. > Thanks, > Jack > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Thu Jun 28 17:41:39 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 28 Jun 2018 12:41:39 -0500 Subject: [Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies In-Reply-To: <63257AAD-B4AB-4C7D-84C1-EA9450669984@openstack.org> References: <5B33DAC0.3080802@windriver.com> <6196520f-0373-9dd5-decf-98e96c81a634@windriver.com> <63257AAD-B4AB-4C7D-84C1-EA9450669984@openstack.org> Message-ID: On Thu, Jun 28, 2018 at 12:26 PM, Claire Massey wrote: > The best way to reach the Zuul team directly to share these types of > requests is to ping their ML at zuul-discuss at lists.zuul-ci.org. You can > subscribe to it here: > http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss. You can also > ping them in Freenode IRC at #zuul. Thanks for that reminder Claire. I would add that for things related to the operation of OpenStack's Zuul #openstack-infra on freenode is the place to be, even though there is an overlap of the People Who Know between those channels. > On 18-06-27 03:12 PM, Dean Troyer wrote: > Dang, I forgot this bit when setting up the jobs, so something like > this? https://review.openstack.org/578532 So to clarify a bit, this was a configuration issue, Chris talked with Jeremy and Clark in -infra, and the review above[0] puts the stx-* repos into a shared gate queue. It is working its way through the review process (it already has one +2). I don't believe anything else is required, please correct me if that is wrong. dt [0] https://review.openstack.org/578532 -- Dean Troyer dtroyer at gmail.com From dtroyer at gmail.com Thu Jun 28 17:46:27 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 28 Jun 2018 12:46:27 -0500 Subject: [Starlingx-discuss] Zuul is not automatically added to reviewer list In-Reply-To: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> Message-ID: On Thu, Jun 28, 2018 at 12:12 PM, Ding, Jack wrote: > Was there any config changes related to Zuul done lately? I pushed a few > reviews in stx-config but Zuul was not added to the Reviewers list. It was > added automatically a few days ago when I push to same repo. The only change to starling configs I am aware of (so far) is https://review.openstack.org/578532 that puts stx-* into a shared gate queue for Depends-On to work, that is not (yet) merged so it hasn't changed yet. dt -- Dean Troyer dtroyer at gmail.com From bruce.e.jones at intel.com Thu Jun 28 17:46:02 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 28 Jun 2018 17:46:02 +0000 Subject: [Starlingx-discuss] DPDK 100% CPU Message-ID: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> Abraham found a bug where DPDK is consuming 100% of the CPU time. Has anyone else seen this? There's a bug filed on https://storyboard.openstack.org/#!/story/2002747, any comments, other sightings, debug advice etc.. would be most welcome! brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt.Peters at windriver.com Thu Jun 28 18:18:19 2018 From: Matt.Peters at windriver.com (Peters, Matt) Date: Thu, 28 Jun 2018 18:18:19 +0000 Subject: [Starlingx-discuss] DPDK 100% CPU In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> Message-ID: That is normal behavior for DPDK based applications. It should not be considered a bug. From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Thursday, June 28, 2018 1:46 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] DPDK 100% CPU Abraham found a bug where DPDK is consuming 100% of the CPU time. Has anyone else seen this? There's a bug filed on https://storyboard.openstack.org/#!/story/2002747, any comments, other sightings, debug advice etc.. would be most welcome! brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Thu Jun 28 18:22:55 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Thu, 28 Jun 2018 18:22:55 +0000 Subject: [Starlingx-discuss] DPDK 100% CPU In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54EBD4@fmsmsx117.amr.corp.intel.com> Wow, but OK. Abraham can you close the bug please? From: Peters, Matt [mailto:Matt.Peters at windriver.com] Sent: Thursday, June 28, 2018 11:18 AM To: Jones, Bruce E ; starlingx-discuss at lists.starlingx.io Subject: RE: DPDK 100% CPU That is normal behavior for DPDK based applications. It should not be considered a bug. From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Thursday, June 28, 2018 1:46 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] DPDK 100% CPU Abraham found a bug where DPDK is consuming 100% of the CPU time. Has anyone else seen this? There's a bug filed on https://storyboard.openstack.org/#!/story/2002747, any comments, other sightings, debug advice etc.. would be most welcome! brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.friesen at windriver.com Thu Jun 28 18:55:39 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Thu, 28 Jun 2018 12:55:39 -0600 Subject: [Starlingx-discuss] DPDK 100% CPU In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54EBD4@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54EBD4@fmsmsx117.amr.corp.intel.com> Message-ID: <5B352F2B.40609@windriver.com> On 06/28/2018 12:22 PM, Jones, Bruce E wrote: > Wow, but OK. Abraham can you close the bug please? For some further background...when using poll-mode DPDK basically runs in a busy-loop, which allows it to avoid interrupt overhead at the cost of increased power consumption. Chris From abraham.arce.moreno at intel.com Fri Jun 29 00:16:02 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Fri, 29 Jun 2018 00:16:02 +0000 Subject: [Starlingx-discuss] DPDK 100% CPU In-Reply-To: <5B352F2B.40609@windriver.com> References: <9A85D2917C58154C960D95352B22818BAB54E94C@fmsmsx117.amr.corp.intel.com> <9A85D2917C58154C960D95352B22818BAB54EBD4@fmsmsx117.amr.corp.intel.com> <5B352F2B.40609@windriver.com> Message-ID: > > Wow, but OK. Abraham can you close the bug please? Sure Bruce :) > For some further background...when using poll-mode DPDK basically runs in a > busy-loop, which allows it to avoid interrupt overhead at the cost of > increased power consumption. Thanks Matt, Chris! From ada.cabrales at intel.com Fri Jun 29 01:02:13 2018 From: ada.cabrales at intel.com (Cabrales, Ada) Date: Fri, 29 Jun 2018 01:02:13 +0000 Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54E25A@fmsmsx117.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818BAB54E25A@fmsmsx117.amr.corp.intel.com> Message-ID: <4F6AACE4B0F173488D033B02A8BB5B7E7169FD30@fmsmsx104.amr.corp.intel.com> I like this proposal. I think it would give us periodic, stable versions to work on/with. Also, it gives us the opportunity to plan what would we have on each monthly | quarterly release, considering feature's priority. So, if we decide to follow this schema, let's define what we want to have ready for the Summit in November (the September release, as pointed by Bruce previously) and plan around that. Ada -- From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Wednesday, June 27, 2018 6:48 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we'd like to follow the "bus stop" model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned "Release 2" should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that "our current November release is the first quarterly release", I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be "stx.2018.07". The version number of that build would be "stx.2018.07.0x", where "0x" is a patch number. Yes, that's a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a "latest known to be good" build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter's quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month's (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling "Release 2" will need to change. If this proposal is accepted, we won't have a "release 2" anymore, just a "release stx.2018.08.x" released in September and "release stx 2018.11.x" released in December. This changes the content we'd have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it's inevitable that the StarlingX project has separate / different version numbers from TC, but I don't know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Fri Jun 29 12:57:17 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Fri, 29 Jun 2018 12:57:17 +0000 Subject: [Starlingx-discuss] build-pkgs: no such file or directory Message-ID: build-pkgs process shows today the directories not found: For EXAMPLE_SERVICE we have submitted the change https://review.openstack.org/#/c/579137/ find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-chilon/patch-scripts/EXAMPLE_SERVICE/centos/': No such file or directory For the rest I would like to hear from the active people sending patches to openstack/stx-integ if these changes are on hold or another patch is required from our side to remove the references: find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/security/spectre-meltdown-checker/centos/': No such file or directory find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/collectd-extensions/centos/': No such file or directory find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/influxdb-extensions/centos/': No such file or directory From yong.hu at intel.com Fri Jun 29 13:12:43 2018 From: yong.hu at intel.com (Hu, Yong) Date: Fri, 29 Jun 2018 13:12:43 +0000 Subject: [Starlingx-discuss] build-pkgs: no such file or directory Message-ID: In my impression lately WRS folks submitted patches relevant to meltdown-checker and collectd. Not sure if there are other patches which are required to merge together into "stx-integ" (mapped from "mwa-sparta"). On 29/06/2018, 8:57 PM, "Arce Moreno, Abraham" wrote: build-pkgs process shows today the directories not found: For EXAMPLE_SERVICE we have submitted the change https://review.openstack.org/#/c/579137/ find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-chilon/patch-scripts/EXAMPLE_SERVICE/centos/': No such file or directory For the rest I would like to hear from the active people sending patches to openstack/stx-integ if these changes are on hold or another patch is required from our side to remove the references: find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/security/spectre-meltdown-checker/centos/': No such file or directory find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/collectd-extensions/centos/': No such file or directory find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/influxdb-extensions/centos/': No such file or directory _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Jack.Ding at windriver.com Fri Jun 29 14:11:29 2018 From: Jack.Ding at windriver.com (Ding, Jack) Date: Fri, 29 Jun 2018 14:11:29 +0000 Subject: [Starlingx-discuss] code review workflow Message-ID: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA119F5@ALA-MBD.corp.ad.wrs.com> HI all, I have a bunch of reviews pending today. If you happened to review my changes, could you please do NOT +1 Workflow? I would like to run a script later after all reviews are approved to apply workflow in sequence to avoid conflicts and mismatch among multiple repos. Thanks, Jack From Jack.Ding at windriver.com Fri Jun 29 14:15:36 2018 From: Jack.Ding at windriver.com (Ding, Jack) Date: Fri, 29 Jun 2018 14:15:36 +0000 Subject: [Starlingx-discuss] Zuul is not automatically added to reviewer list In-Reply-To: <8CA7C914-7B23-4DA8-BBE5-F718E956A5EA@openstack.org> References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA1083E@ALA-MBD.corp.ad.wrs.com> <8CA7C914-7B23-4DA8-BBE5-F718E956A5EA@openstack.org> Message-ID: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA11A10@ALA-MBD.corp.ad.wrs.com> Update to the issue: false alarm. Zuul was still automatically added to my reviews it was just slower yesterday. Thanks for all the replies. Jack From: Claire Massey [mailto:claire at openstack.org] Sent: June 28, 2018 1:30 PM To: Ding, Jack Cc: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Zuul is not automatically added to reviewer list Hi there, Feel free to reach out to the Infra team directly for questions like this one. You can find them in Freenode IRC at #openstack-infra or their mailing list at openstack-infra at lists.openstack.org. Also, if you want to add some of these StarlingX specific items to the next Infra team meeting agenda, they meet on Tuesdays at 1900 UTC in IRC at #openstack-meeting. Cheers, Claire On Jun 28, 2018, at 12:12 PM, Ding, Jack > wrote: Was there any config changes related to Zuul done lately? I pushed a few reviews in stx-config but Zuul was not added to the Reviewers list. It was added automatically a few days ago when I push to same repo. Thanks, Jack _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.arce.moreno at intel.com Fri Jun 29 14:17:00 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Fri, 29 Jun 2018 14:17:00 +0000 Subject: [Starlingx-discuss] build-pkgs: package built failed , mock package missing Message-ID: This is the result of a daily build exercise from zero as part of our StarlingX/Developer Guide creation: https://wiki.openstack.org/wiki/StarlingX/Developer_Guide One of the things to debug failures during build-pkgs is to find out the failed packages, a "fail" file is created under each package directory: $ find $MY_WORKSPACE/std/results/ -name fail Now we choose one packages from our failing list e.g. .../shim-signed-12-1.tis.2/fail We want to verify the specific build failure for that package but its build.log shows only the Mock Version: $ cat $MY_WORKSPACE/std/results/aarcemor-starlingx-tis-r5-pike-std/build-info-1.0-3.tis/build.log Mock Version: 1.3.4 build-srpm-parallel was successful, we are in build-rpms-parallel stage. One error is common to all packages: 13:37:39 ERROR: Could not find useradd in chroot, maybe the install failed? And this is reflected also as our exit error when we try to enter the mock shell: $ mock -r $MY_BUILD_CFG --shell ... Installed: ... Dependency Installed: ... ... Complete! Finish: yum install ERROR: Could not find useradd in chroot, maybe the install failed? Then we look for that package, and it is part of shadow-utils $ sudo yum whatprovides \*useradd shadow-utils-4.1.5.1-24.el7.x86_64 $ sudo yum install shadow-utils We look at the content from our mock configuration, the shadow-utils is there: $ echo $MY_BUILD_CFG /localdisk/loadbuild/aarcemor/starlingx/std/configs/aarcemor-starlingx-tis-r5-pike-std/aarcemor-starlingx-tis-r5-pike-std.cfg $ vi $MY_BUILD_CFG config_opts['yum_install_command'] = 'install yum yum-utils shadow-utils distribution-gpg-keys' Looking more into the mock environment, we see no content under /var/lib/mock/. Any help is highly appreciated to debug further. From scott.little at windriver.com Fri Jun 29 15:55:40 2018 From: scott.little at windriver.com (Scott Little) Date: Fri, 29 Jun 2018 11:55:40 -0400 Subject: [Starlingx-discuss] build-pkgs: package built failed , mock package missing In-Reply-To: References: Message-ID: <60b836e9-3388-7bbc-f63c-9e6db7ec6e4a@windriver.com> I'm not observing this.  Perhaps a change in the @buildsys-build package group on your system. More inline below ... On 18-06-29 10:17 AM, Arce Moreno, Abraham wrote: > This is the result of a daily build exercise from zero as part of our StarlingX/Developer Guide creation: > https://wiki.openstack.org/wiki/StarlingX/Developer_Guide > > One of the things to debug failures during build-pkgs is to find out the failed packages, > a "fail" file is created under each package directory: > > $ find $MY_WORKSPACE/std/results/ -name fail > > Now we choose one packages from our failing list e.g. .../shim-signed-12-1.tis.2/fail > > We want to verify the specific build failure for that package but its build.log shows only the Mock Version: > > $ cat $MY_WORKSPACE/std/results/aarcemor-starlingx-tis-r5-pike-std/build-info-1.0-3.tis/build.log > Mock Version: 1.3.4 > > build-srpm-parallel was successful, we are in build-rpms-parallel stage. One error is common to all packages: > > 13:37:39 ERROR: Could not find useradd in chroot, maybe the install failed? > > And this is reflected also as our exit error when we try to enter the mock shell: > > $ mock -r $MY_BUILD_CFG --shell [SL] If you are using parallel build, please use the b0 config under the configs directory ... e.g. export MY_BUILD_ENVIRONMENT=$USER-$PROJECT-$SRC_BUILD_ENVIRONMENT export MY_DEBUG_BUILD_CFG_STD=$MY_WORKSPACE/std/configs/${MY_BUILD_ENVIRONMENT}-std/${MY_BUILD_ENVIRONMENT}-std.b0.cfg mock -r $MY_DEBUG_BUILD_CFG_STD --shell If you find that shadow-utils is still missing, I'd add it to ... $MY_REPO/build-tools/modify-build-cfg ... grep -q "config_opts\['chroot_setup_cmd'\] = 'install @buildsys-build pigz lbzip2 yumshadow-utils'" $FILE || \     echo "config_opts['chroot_setup_cmd'] = 'install @buildsys-build pigz lbzip2 yumshadow-utils'" >> $FILE ... > ... > Installed: ... > Dependency Installed: ... > ... > Complete! > Finish: yum install > ERROR: Could not find useradd in chroot, maybe the install failed? > > Then we look for that package, and it is part of shadow-utils > > $ sudo yum whatprovides \*useradd > shadow-utils-4.1.5.1-24.el7.x86_64 > $ sudo yum install shadow-utils > > We look at the content from our mock configuration, the shadow-utils is there: > > $ echo $MY_BUILD_CFG > /localdisk/loadbuild/aarcemor/starlingx/std/configs/aarcemor-starlingx-tis-r5-pike-std/aarcemor-starlingx-tis-r5-pike-std.cfg > $ vi $MY_BUILD_CFG > config_opts['yum_install_command'] = 'install yum yum-utils shadow-utils distribution-gpg-keys' > > Looking more into the mock environment, we see no content under /var/lib/mock/. > > Any help is highly appreciated to debug further. > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Fri Jun 29 15:58:33 2018 From: scott.little at windriver.com (Scott Little) Date: Fri, 29 Jun 2018 11:58:33 -0400 Subject: [Starlingx-discuss] build-pkgs: no such file or directory In-Reply-To: References: Message-ID: <35623038-0063-14bb-3a27-e524c6b3d175@windriver.com> My fault.  I got ahead of the merge progress of team mates.  I see you backed out EXAMPLE_SERVICE. I'll back out the remaining bits. I'll be glad when Depends-On starts working as expected. Scott On 18-06-29 08:57 AM, Arce Moreno, Abraham wrote: > build-pkgs process shows today the directories not found: > > For EXAMPLE_SERVICE we have submitted the change https://review.openstack.org/#/c/579137/ > find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-chilon/patch-scripts/EXAMPLE_SERVICE/centos/': No such file or directory > > For the rest I would like to hear from the active people sending patches to openstack/stx-integ if these changes are on hold or another patch is required from our side to remove the references: > find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/security/spectre-meltdown-checker/centos/': No such file or directory > find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/collectd-extensions/centos/': No such file or directory > find: '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layers/cgcs/mwa-sparta/monitoring/influxdb-extensions/centos/': No such file or directory > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From bruce.e.jones at intel.com Fri Jun 29 16:29:47 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 29 Jun 2018 16:29:47 +0000 Subject: [Starlingx-discuss] Weekly call notes for June 27th Message-ID: <9A85D2917C58154C960D95352B22818BAB54F42B@fmsmsx117.amr.corp.intel.com> Our etherpad of notes from our weekly calls can be found here: https://etherpad.openstack.org/p/stx-status Right now this is a private call at 1PM PST. We are working with the Foundation who will helping us turn this into a public call in a more Asia friendly time slot. The current proposal is early morning US Pacific time on Wednesday or Thursday. We hope to get it started after the US July holiday / vacation week. brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Fri Jun 29 16:57:34 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 29 Jun 2018 12:57:34 -0400 Subject: [Starlingx-discuss] code review workflow In-Reply-To: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA119F5@ALA-MBD.corp.ad.wrs.com> References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA119F5@ALA-MBD.corp.ad.wrs.com> Message-ID: <1530291388-sup-5435@lrrr.local> Excerpts from 's message of 2018-06-29 14:11:29 +0000: > HI all, > I have a bunch of reviews pending today. If you happened to review my changes, could you please do NOT +1 Workflow? > I would like to run a script later after all reviews are approved to apply workflow in sequence to avoid conflicts and mismatch among multiple repos. > Thanks, > Jack If you include a "Depends-On" link in your commit messages, Zuul will tie the commits together in a way that forces them to land in order, even across repositories. See https://docs.openstack.org/infra/manual/developers.html#cross-repository-dependencies for more details. Doug From dtroyer at gmail.com Fri Jun 29 17:08:49 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Fri, 29 Jun 2018 12:08:49 -0500 Subject: [Starlingx-discuss] code review workflow In-Reply-To: <1530291388-sup-5435@lrrr.local> References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA119F5@ALA-MBD.corp.ad.wrs.com> <1530291388-sup-5435@lrrr.local> Message-ID: On Fri, Jun 29, 2018 at 11:57 AM, Doug Hellmann wrote: > If you include a "Depends-On" link in your commit messages, Zuul will > tie the commits together in a way that forces them to land in order, > even across repositories. See > https://docs.openstack.org/infra/manual/developers.html#cross-repository-dependencies > for more details. I didn't initially put these repos into the same gate queue, so that's work across repos once https://review.openstack.org/578532 merges... dt -- Dean Troyer dtroyer at gmail.com From doug at doughellmann.com Fri Jun 29 17:20:06 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 29 Jun 2018 13:20:06 -0400 Subject: [Starlingx-discuss] code review workflow In-Reply-To: References: <4CBDE0F61EDB444598D6F4D3D2B1645B6BA119F5@ALA-MBD.corp.ad.wrs.com> <1530291388-sup-5435@lrrr.local> Message-ID: <1530292772-sup-5716@lrrr.local> Excerpts from Dean Troyer's message of 2018-06-29 12:08:49 -0500: > On Fri, Jun 29, 2018 at 11:57 AM, Doug Hellmann wrote: > > If you include a "Depends-On" link in your commit messages, Zuul will > > tie the commits together in a way that forces them to land in order, > > even across repositories. See > > https://docs.openstack.org/infra/manual/developers.html#cross-repository-dependencies > > for more details. > > I didn't initially put these repos into the same gate queue, so that's > work across repos once https://review.openstack.org/578532 merges... > > dt > OK, I thought depends-on worked even if things weren't in the same queue (at least in terms of not being able to merge a commit until its dependencies had merged). Doug From scott.little at windriver.com Fri Jun 29 20:09:04 2018 From: scott.little at windriver.com (Scott Little) Date: Fri, 29 Jun 2018 16:09:04 -0400 Subject: [Starlingx-discuss] Directory restructuring In-Reply-To: References: <543bf93f-e31e-8f7b-17c2-622837ac74e5@windriver.com> Message-ID: <064f76f3-2a56-871b-d9c3-266dbfac919d@windriver.com> I have the two sets of updates nearly ready. 1)  Rename the mwa-* subdirectories, making the directory name match the git name.  e.g. mwa-sparta will be replaced by stx-integ. 2) Strip out the addons/wr-cgcs/layers/cgcs, replacing it with 'stx' After both change sets, common paths will look like ... e.g. $MY_REPO/stx/stc-integ $MY_REPO/stx/git/nova I think we are targeting July 5 to have the change sets out for review, and hopefully quick acceptance. With respect to the manifest files, I'm still working with stx-r0.xml.  Is that ok, or would it be preferable to start a new one?  The old would be unbuildable.  I'm just wondering if it would help folks during the transition to still have access to the old manifest. Scott On 18-06-21 11:17 AM, Dean Troyer wrote: > On Thu, Jun 21, 2018 at 9:27 AM, Scott Little > wrote: >> The current directory structure leaves a lot to be desired. References to >> mwa and cgcs should be removed and the directory structure can be flattened >> a bit to reduce path lengths. I propose to ... >> >> 1) Rename the mwa-* subdirectories, making the directory name match the git >> name. e.g. mwa-sparta will be replaced by stx-integ. > ++ > > I naming the directories after the repo makes the most sense, thats > fine, that's what we are all used to and where the mwa-* names came > from before the Great Pivot. repo gives us the flexibility to do what > makes the most sense here. > >> 2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with >> 'stx-utils' is not very attractive. I'm thinking something more like >> 'packages' or 'src'. Other options welcome. > ++ > > I'm fine with a different name, not sure I have a better idea of what though. > >> Can we agree this is a positive step? Is it the right time to undertake >> this change? Both changes in the same set of updates, or split them? > Totally positive! My experiences say that this is the sort of thing > that will be painful no matter when we do it, waiting for X usually > means when X comes Y has appeared to wait on. I favor doing it as > soon as we know what we want to do. > > I would split them into two sets of reviews though, I think that will > make debugging a bit simpler with only one type of thing changing at a > time. > >> It will require both a manifest change, and a number of updates to hard >> coded paths within various scripts. Grep is my friend, but I might need a >> little help identifying scripts not originating from Wind Rivers original >> code drop. > We'll be able to help there, I think most of those are concerned with > things outside or next to the build tree, like the mirror creation. > >> I'm a little worried about out of tree or side branch copies of the >> manifests. Thought on how to handle this? > We can use Zulu/Gerrit's Depends-On capability to co-ordinate the > merge of these reviews so we do not spend a significant amount of time > with repos in a inconsistent state. Maybe make all of the (other) > reviews depend on the manifest review, then we +W the manifest review > last and Zulu will merge them all at roughly the same time. > > Right now there is only one manifest file in stx-manifest. The pain > here will be all in-flight work affected, which is likely to be a lot > of it. Ian has mentioned about 70 reviews queued up since R5 release, > I suspect much of that would need to be rebased. This is the 'X' I > mention above. If we hold the restructure to merge all of that first > something else may come up in the mean time. I would like to hear > from someone closer to those affected here about how to weigh this > tradeoff. > > Thanks for kicking this off Scott > dt > From dtroyer at gmail.com Fri Jun 29 20:45:09 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Fri, 29 Jun 2018 15:45:09 -0500 Subject: [Starlingx-discuss] Directory restructuring In-Reply-To: <064f76f3-2a56-871b-d9c3-266dbfac919d@windriver.com> References: <543bf93f-e31e-8f7b-17c2-622837ac74e5@windriver.com> <064f76f3-2a56-871b-d9c3-266dbfac919d@windriver.com> Message-ID: On Fri, Jun 29, 2018 at 3:09 PM, Scott Little wrote: > I have the two sets of updates nearly ready. > > 1) Rename the mwa-* subdirectories, making the directory name match the git > name. e.g. mwa-sparta will be replaced by stx-integ. > > 2) Strip out the addons/wr-cgcs/layers/cgcs, replacing it with 'stx' > > After both change sets, common paths will look like ... e.g. > > $MY_REPO/stx/stc-integ > $MY_REPO/stx/git/nova Much better! > I think we are targeting July 5 to have the change sets out for review, and > hopefully quick acceptance. OK, holiday week should be slow and is a good time to do this I think. We should have https://review.openstack.org/578532 merged by then so Depends-On will work across repos and we could make them all depend on the manifest change so everything merges at once. The cool thing is, if (when!) we have tests running, we could test the entire set together using this. I think you should go ahead and post them to Gerrit and mark them WIP so I don't go and merge them early (oops). repo can pull from Gerrit easily. That would give us a chance to try it out, we may have some additional things that need tweaking to follow your changes immediately. > With respect to the manifest files, I'm still working with stx-r0.xml. Is > that ok, or would it be preferable to start a new one? The old would be > unbuildable. I'm just wondering if it would help folks during the > transition to still have access to the old manifest. We need to make stx-manifest/default.xml be the normal starting point. Thanks Scott! dt -- Dean Troyer dtroyer at gmail.com From Brent.Rowsell at windriver.com Fri Jun 29 21:13:52 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Fri, 29 Jun 2018 21:13:52 +0000 Subject: [Starlingx-discuss] https://storyboard.openstack.org/#!/story/2002601 Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0C1070@ALA-MBD.corp.ad.wrs.com> A fix for this was delivered today under https://review.openstack.org/#/c/578921/ Any objections to marking the story as merged ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brent.Rowsell at windriver.com Fri Jun 29 21:33:24 2018 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Fri, 29 Jun 2018 21:33:24 +0000 Subject: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 In-Reply-To: References: <9A85D2917C58154C960D95352B22818BAB54B528@fmsmsx117.amr.corp.intel.com> Message-ID: <2588653EBDFFA34B982FAF00F1B4844EBB0C1112@ALA-MBD.corp.ad.wrs.com> Bruce, Any update on this ? Brent From: Peters, Matt [mailto:Matt.Peters at windriver.com] Sent: Thursday, June 21, 2018 11:32 AM To: JONES, BRUCE ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 Several people are using the latest StarlingX build in VirtualBox with success. The recent update that integrates ovs-dpdk into the system configuration framework and an upgraded version of OVS has been tested with VirtualBox. Are people still having issue with the latest code base? I don't see any details of the actual issue encountered in the bug report. If this is still an issue, can we get additional details describing the problem added? Regards, Matt From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] Sent: Thursday, June 21, 2018 11:23 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Bug: https://storyboard.openstack.org/#!/story/2002626 This bug is an issue that many of us have encountered - since the DPDK integration (the one Intel did internally), we are no longer able to bring the system up on a desktop within Virtual Box. It could be a bug in VB, in DPDK or somewhere else. Many of our devs use VB so this is a fairly high priority issue. This is currently assigned to Forrest but there might be folks on this list who can help. So I'm asking for help. :) bucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.e.jones at intel.com Fri Jun 29 22:10:56 2018 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 29 Jun 2018 22:10:56 +0000 Subject: [Starlingx-discuss] https://storyboard.openstack.org/#!/story/2002601 In-Reply-To: <2588653EBDFFA34B982FAF00F1B4844EBB0C1070@ALA-MBD.corp.ad.wrs.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0C1070@ALA-MBD.corp.ad.wrs.com> Message-ID: <9A85D2917C58154C960D95352B22818BAB54F5FE@fmsmsx117.amr.corp.intel.com> No objection from me and thank you very much! Doesn't the infrastructure mark Stories as merged once they merge? brucej From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] Sent: Friday, June 29, 2018 2:14 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] https://storyboard.openstack.org/#!/story/2002601 A fix for this was delivered today under https://review.openstack.org/#/c/578921/ Any objections to marking the story as merged ? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtroyer at gmail.com Fri Jun 29 23:11:06 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Fri, 29 Jun 2018 18:11:06 -0500 Subject: [Starlingx-discuss] https://storyboard.openstack.org/#!/story/2002601 In-Reply-To: <9A85D2917C58154C960D95352B22818BAB54F5FE@fmsmsx117.amr.corp.intel.com> References: <2588653EBDFFA34B982FAF00F1B4844EBB0C1070@ALA-MBD.corp.ad.wrs.com> <9A85D2917C58154C960D95352B22818BAB54F5FE@fmsmsx117.amr.corp.intel.com> Message-ID: On Fri, Jun 29, 2018 at 5:10 PM, Jones, Bruce E wrote: > Doesn’t the infrastructure mark Stories as merged once they merge? It does if the commit message has a Story: ##### footer in it. dt -- Dean Troyer dtroyer at gmail.com From abraham.arce.moreno at intel.com Sat Jun 30 04:52:35 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Sat, 30 Jun 2018 04:52:35 +0000 Subject: [Starlingx-discuss] build-pkgs: no such file or directory In-Reply-To: <35623038-0063-14bb-3a27-e524c6b3d175@windriver.com> References: <35623038-0063-14bb-3a27-e524c6b3d175@windriver.com> Message-ID: > > For EXAMPLE_SERVICE we have submitted the change > > https://review.openstack.org/#/c/579137/ > > find: > > '/localdisk/designer/aarcemor/starlingx/cgcs-root/addons/wr-cgcs/layer > > s/cgcs/mwa-chilon/patch-scripts/EXAMPLE_SERVICE/centos/': No such file > > or directory > My fault.  I got ahead of the merge progress of team mates.  I see you backed > out EXAMPLE_SERVICE. I'll back out the remaining bits. > I'll be glad when Depends-On starts working as expected. Not a problem Scott, any patch works. Thanks! From abraham.arce.moreno at intel.com Sat Jun 30 05:08:59 2018 From: abraham.arce.moreno at intel.com (Arce Moreno, Abraham) Date: Sat, 30 Jun 2018 05:08:59 +0000 Subject: [Starlingx-discuss] build-pkgs: package built failed , mock package missing In-Reply-To: <60b836e9-3388-7bbc-f63c-9e6db7ec6e4a@windriver.com> References: <60b836e9-3388-7bbc-f63c-9e6db7ec6e4a@windriver.com> Message-ID: > I'm not observing this. Perhaps a change in the @buildsys-build package group > on your system. > > More inline below ... Thanks for your guidance! I am now able to continue with the compilation process, I will debug some time later what are the changes in my setup. > > 13:37:39 ERROR: Could not find useradd in chroot, maybe the install failed? > > > > And this is reflected also as our exit error when we try to enter the mock shell: > > > > $ mock -r $MY_BUILD_CFG --shell > [SL] If you are using parallel build, please use the b0 config under the configs > directory ... e.g. Confirmed b0 config being used... > If you find that shadow-utils is still missing, I'd add it to ... > > $MY_REPO/build-tools/modify-build-cfg > > ... > grep -q "config_opts\['chroot_setup_cmd'\] = 'install @buildsys-build pigz lbzip2 > yumshadow-utils'" $FILE || \ > echo "config_opts['chroot_setup_cmd'] = 'install @buildsys-build pigz lbzip2 > yumshadow-utils'" >> $FILE ... I added it as suggested but it continued failing then I search for any other place buildsys-build [0] was used and I find that adding shadow-utils under b0 config made useradd to be installed and let me continue with the compilation process: $ .../ user-starlingx-tis-r5-pike-std.b0.cfg config_opts['rpmbuild_timeout'] = 0 config_opts['chroot_setup_cmd'] = 'install @buildsys-build pigz lbzip2 yum shadow-utils' config_opts['module_install'] = [] [0] https://fedoraproject.org/wiki/Archive:Legacy/Mock?rd=Legacy/Mock