From iwienand at redhat.com Mon Dec 2 10:41:44 2019 From: iwienand at redhat.com (Ian Wienand) Date: Mon, 2 Dec 2019 21:41:44 +1100 Subject: [OpenStack-Infra] Creating OpenDev control-plane docker images and naming In-Reply-To: <20191126063107.GB1161931@fedora19.localdomain> References: <20191126063107.GB1161931@fedora19.localdomain> Message-ID: <20191202104144.GA1502908@fedora19.localdomain> On Tue, Nov 26, 2019 at 05:31:07PM +1100, Ian Wienand wrote: > What I would propose is that projects do *not* have a single, > top-level Dockerfile, but only (potentially many) specifically > name-spaced versions. > [2] I started looking at installing these together from a Dockerfile > in system-config. The problem is that you have a "build context", > basically the directory the Dockerfile is in and everything under > it. I started looking closely at this, and I think have reversed my position from above. That is, I think we should keep the OpenDev related dockerfiles in system-config. [1] is a change in system-config to add jobs to build openstacksdk, diskimage-builder and nodepool-[builder|launcher] containers. It does this by having these projects as required-projects: in the job configuration and copying the Dockerfile into the Zuul-checked-out source (and using that as the build context). A bit ugly, but it works. However, to use these jobs for nodepool CI requires importing them into zuul/nodepool. This is tested with [2]. However, Zuul just reports: This change depends on a change with an invalid configuration. It only depends-on [1], which has a valid configuration, at least in the opendev tenant. I think that this has to do with the zuul tenant not having the projects that are used by required-jobs: from the new system-config jobs [3], but am not certain it doesn't have something else to do with the config errors at [4]. I have filed [5] because at the minimum a more helpful error would be good. -i [1] https://review.opendev.org/696000 [2] https://review.opendev.org/696486 [3] https://review.opendev.org/696859 [4] https://zuul.opendev.org/t/zuul/config-errors [5] https://storyboard.openstack.org/#!/story/2006968 From cboylan at sapwetik.org Tue Dec 3 16:24:29 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 03 Dec 2019 08:24:29 -0800 Subject: [OpenStack-Infra] Infra Team Meeting Agenda for December 3, 2019 Message-ID: <2a1cd5fa-787e-4653-b4ec-06a79645a8cb@www.fastmail.com> We will meet at 19:00UTC on December 3 (today) in #openstack-meeting with this agenda. Sorry for the late send. I was busy traveling yesterday. == Agenda for next meeting == * Announcements * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack] ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Possible gitea/go-git bug in current version of gitea we are running https://storyboard.openstack.org/#!/story/2006849 * General topics ** Trusty Upgrade Progress (clarkb 20191203) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191203) *** Infra-root needs to create AFS volumes. ** dib/nodepool container (ianw 20191203) *** http://lists.openstack.org/pipermail/openstack-infra/2019-November/006529.html ** Discussion on retiring services that are largely unmaintained or unused (clarkb 20191203) *** Want to start this discussion as services like Ask are barely on life support and we should probably clean them up. *** https://etherpad.openstack.org/infra-service-list * Open discussion From cboylan at sapwetik.org Tue Dec 3 16:52:54 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 03 Dec 2019 08:52:54 -0800 Subject: [OpenStack-Infra] Openstack console not working In-Reply-To: References: Message-ID: On Wed, Nov 27, 2019, at 10:47 PM, Ali Hosseinbeigi wrote: > Hi, > > Ive installed openstack (train) via MAAS and juju (Conjure-up, nova-kvm ). > > Every thing works fine but I have problem with instance console. > > When I click on console the message “Instance Console Unable to load > console. Please reload page to try again.” appears. > > Is there anyone to helm me? Sent this to the first thread too, but to ensure it gets seen I'll send it to this one as well. Hope this helps. This mailing list is used to coordinate the efforts to produce OpenStack software: things like Gerrit and Zuul. Unfortunately this means we are not in a great position to help debug OpenStack installations. For that you should send mail to openstack-discuss at lists.openstack.org instead. Clark From cboylan at sapwetik.org Tue Dec 3 20:05:14 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 03 Dec 2019 12:05:14 -0800 Subject: [OpenStack-Infra] OpenDev Independence and Governance Message-ID: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> Hello everyone, The OpenDev project has been running semi formally for about a year now. During this time we have tried to accomodate the needs of our various constituent projects, but we've still (for the most part) formally operated under OpenStack's governance. In order to better serve the projects we host that are not OpenStack we think it is important for OpenDev to become an independent entity with its own governance structure. In James Blair's winterscale email [0] he suggested that we create a governing council made up of the OpenDev PTL and a representative from each of the OpenStack Foundation's official projects that currently consume OpenDev resources (currently OpenStack itself, Airship, and Zuul). This suggestion creates two levels of governance for the OpenDev team. The first is the position of PTL for the OpenDev project. If we want to continue to manage this position as we've managed it for the OpenStack Infra team, then we can have elections for the position every 6 months. The nominee pool and electorate would be individuals that have contributed changes to OpenDev in the last 12 months. For the council, membership would be small, but I think demands on this group would also be minimal. Ideally the OpenDev team would be left to figure out technical details for services and this council would be used as a check on service changes or other behavioral updates that affect how OpenDev's users interact with the system. Since this group would be starting with an even number of individuals we may need to determine tie breaker requirements upfront. Also, we may want to consider if the "else" group of OpenDev users need a voice. Individuals representing constituent projects should be nominated by their project leadership. As for next steps, I think we want to sort out these governance details to where we are generally happy with them, then we can make the formal request to the OpenStack TC to pull anchor and sail a bit more independently. Feedback is more than welcome, Clark [0] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130896.html From thierry at openstack.org Wed Dec 4 10:46:18 2019 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 4 Dec 2019 11:46:18 +0100 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> Message-ID: Clark Boylan wrote: > [...] > In James Blair's winterscale email [0] he suggested that we create a governing council made up of the OpenDev PTL and > a representative from each of the OpenStack Foundation's official projects that currently consume OpenDev resources > (currently OpenStack itself, Airship, and Zuul). This suggestion creates two levels of governance for the OpenDev team. > > The first is the position of PTL for the OpenDev project. If we want to continue to manage this position as we've managed it > for the OpenStack Infra team, then we can have elections for the position every 6 months. The nominee pool and electorate > would be individuals that have contributed changes to OpenDev in the last 12 months. That sounds good. Only comment: "PTL" meaning "project team lead", it's a bit of an OpenStack-ism which might not make perfect sense in the Opendev context. > For the council, membership would be small, but I think demands on this group would also be minimal. Ideally the OpenDev team > would be left to figure out technical details for services and this council would be used as a check on service changes or > other behavioral updates that affect how OpenDev's users interact with the system. Since this group would be starting with > an even number of individuals we may need to determine tie breaker requirements upfront. Also, we may want to consider > if the "else" group of OpenDev users need a voice. Individuals representing constituent projects should be nominated by > their project leadership. I feel like this group should more of an advisory board (to get feedback) than a governance council (to vote on motions on a one project = one vote basis). If you go for a governance structure, it creates a number of issues imho, like tie breaking, or the fact that OpenStack's vote is arguably more important than StarlingX's (being a pilot project) or Kata's (only using very few of the Opendev services). Choosing an advisory board style, there is no formal vote, just official feedback on priorities and proposals, which can then be properly weighed by the OpenDev lead and contributors. You can integrate additional seats to represent "else" opendev users without having to over-think how their voice compares to an OSF project voice. I'm also wondering if the advisory board should not also include seats for the infrastructure donors... Since we should definitely be making sure Opendev goes in a direction that encourages them to continue investing in (or increase) the resources that they give us. -- Thierry Carrez (ttx) From mnaser at vexxhost.com Wed Dec 4 14:45:48 2019 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 4 Dec 2019 09:45:48 -0500 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> Message-ID: On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote: > > Clark Boylan wrote: > > [...] > > In James Blair's winterscale email [0] he suggested that we create a governing council made up of the OpenDev PTL and > > a representative from each of the OpenStack Foundation's official projects that currently consume OpenDev resources > > (currently OpenStack itself, Airship, and Zuul). This suggestion creates two levels of governance for the OpenDev team. > > > > The first is the position of PTL for the OpenDev project. If we want to continue to manage this position as we've managed it > > for the OpenStack Infra team, then we can have elections for the position every 6 months. The nominee pool and electorate > > would be individuals that have contributed changes to OpenDev in the last 12 months. > > That sounds good. Only comment: "PTL" meaning "project team lead", it's > a bit of an OpenStack-ism which might not make perfect sense in the > Opendev context. > > > For the council, membership would be small, but I think demands on this group would also be minimal. Ideally the OpenDev team > > would be left to figure out technical details for services and this council would be used as a check on service changes or > > other behavioral updates that affect how OpenDev's users interact with the system. Since this group would be starting with > > an even number of individuals we may need to determine tie breaker requirements upfront. Also, we may want to consider > > if the "else" group of OpenDev users need a voice. Individuals representing constituent projects should be nominated by > > their project leadership. > > I feel like this group should more of an advisory board (to get > feedback) than a governance council (to vote on motions on a one project > = one vote basis). > > If you go for a governance structure, it creates a number of issues > imho, like tie breaking, or the fact that OpenStack's vote is arguably > more important than StarlingX's (being a pilot project) or Kata's (only > using very few of the Opendev services). > > Choosing an advisory board style, there is no formal vote, just official > feedback on priorities and proposals, which can then be properly weighed > by the OpenDev lead and contributors. You can integrate additional seats > to represent "else" opendev users without having to over-think how their > voice compares to an OSF project voice. > > I'm also wondering if the advisory board should not also include seats > for the infrastructure donors... Since we should definitely be making > sure Opendev goes in a direction that encourages them to continue > investing in (or increase) the resources that they give us. I wanted to bring this up but indeed, I think that as an infrastructure donor, there is a significant investment from our side and knowing where and how that's going is important > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. https://vexxhost.com From fungi at yuggoth.org Wed Dec 4 14:57:17 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 4 Dec 2019 14:57:17 +0000 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> Message-ID: <20191204145716.yvlmmugdjzs7lved@yuggoth.org> On 2019-12-04 09:45:48 -0500 (-0500), Mohammed Naser wrote: > On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote: [...] > > I'm also wondering if the advisory board should not also include seats > > for the infrastructure donors... Since we should definitely be making > > sure Opendev goes in a direction that encourages them to continue > > investing in (or increase) the resources that they give us. > > I wanted to bring this up but indeed, I think that as an infrastructure > donor, there is a significant investment from our side and knowing > where and how that's going is important Yep, you mentioned it at the PTG and I think it's a great idea. Not only does it provide a means for technical representatives from our resource donors to give more direct feedback and even debate topics between one another, it also gives the OpenDev sysadmins a clearer point of contact when they need to reach out to those same donors. Combining with Thierry's idea, perhaps there are two advisory boards for OpenDev, one for the projects participating in it and one for the resource donors? Or would they be better combined into a single advisory board? And yeah, on the earlier "PTL" point, I agree we could stand to come up with a better term (service coordinator?). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From thierry at openstack.org Thu Dec 5 10:12:41 2019 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 5 Dec 2019 11:12:41 +0100 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <20191204145716.yvlmmugdjzs7lved@yuggoth.org> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> <20191204145716.yvlmmugdjzs7lved@yuggoth.org> Message-ID: <63ed248d-e11a-4f5f-3034-ebd3ca814a90@openstack.org> Jeremy Stanley wrote: > On 2019-12-04 09:45:48 -0500 (-0500), Mohammed Naser wrote: >> On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote: > [...] >>> I'm also wondering if the advisory board should not also include seats >>> for the infrastructure donors... Since we should definitely be making >>> sure Opendev goes in a direction that encourages them to continue >>> investing in (or increase) the resources that they give us. >> >> I wanted to bring this up but indeed, I think that as an infrastructure >> donor, there is a significant investment from our side and knowing >> where and how that's going is important > > Yep, you mentioned it at the PTG and I think it's a great idea. Not > only does it provide a means for technical representatives from our > resource donors to give more direct feedback and even debate topics > between one another, it also gives the OpenDev sysadmins a clearer > point of contact when they need to reach out to those same donors. > > Combining with Thierry's idea, perhaps there are two advisory boards > for OpenDev, one for the projects participating in it and one for > the resource donors? Or would they be better combined into a single > advisory board? For the sake of simplicity I'd suggest having a single stakeholders/advisory board, especially if we don't expect those boards to formally vote (one seat = one vote style) on motions. The main idea, as you mentioned, is to have clear contact points and get their feedback on priorities and direction. -- Thierry Carrez (ttx) From cboylan at sapwetik.org Thu Dec 5 23:52:10 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 05 Dec 2019 15:52:10 -0800 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> Message-ID: <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> On Tue, Dec 3, 2019, at 12:05 PM, Clark Boylan wrote: > Hello everyone, > > The OpenDev project has been running semi formally for about a year > now. During this time we have tried to accomodate the > needs of our various constituent projects, but we've still (for the > most part) formally operated under OpenStack's governance. > In order to better serve the projects we host that are not OpenStack we > think it is important for OpenDev to become an > independent entity with its own governance structure. > > In James Blair's winterscale email [0] he suggested that we create a > governing council made up of the OpenDev PTL and > a representative from each of the OpenStack Foundation's official > projects that currently consume OpenDev resources > (currently OpenStack itself, Airship, and Zuul). This suggestion > creates two levels of governance for the OpenDev team. > > The first is the position of PTL for the OpenDev project. If we want to > continue to manage this position as we've managed it > for the OpenStack Infra team, then we can have elections for the > position every 6 months. The nominee pool and electorate > would be individuals that have contributed changes to OpenDev in the > last 12 months. > > For the council, membership would be small, but I think demands on this > group would also be minimal. Ideally the OpenDev team > would be left to figure out technical details for services and this > council would be used as a check on service changes or > other behavioral updates that affect how OpenDev's users interact with > the system. Since this group would be starting with > an even number of individuals we may need to determine tie breaker > requirements upfront. Also, we may want to consider > if the "else" group of OpenDev users need a voice. Individuals > representing constituent projects should be nominated by > their project leadership. > > As for next steps, I think we want to sort out these governance details > to where we are generally happy with them, then we > can make the formal request to the OpenStack TC to pull anchor and sail > a bit more independently. > > Feedback is more than welcome, > Clark > > [0] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130896.html Incorporating feedback I've produced this revised proposal: The OpenDev project will be governed by two entities. The first is the service coordinator. Responsibilities for the service coordinator are essentially the same of the existing Infra team PTL. They coordinate work of contributors and act as a tie breaker when clear consensus isn't found. The service coordinator is elected every 6 months. The nominee pool and electorate are individuals that have contributed changes to OpenDev in the last 12 months. The second is an advisory board made up of representatives from OpenDev's user base of projects and organizations that contribute compute resources. This advisory board provides a formal location for both our users and contributing orgs to express their needs to the OpenDev project. This creates a clear contact point for feedback on priorities and direction. Their input will help ensure that the OpenDev project is a good steward of the resources provided to it and that user needs are being addressed. Contributing orgs and user projects are not required to join the advisory board, but are encouraged to do so. Individuals on the board would be selected by their own constituency as that constituency feels is appropriate. The advisory board will also serve as a point of contact for the OpenDev project when making changes that may be disruptive. The intent is to create bidirectional communication between OpenDev and the advisory board. How does this look? Clark From thierry at openstack.org Fri Dec 6 09:35:09 2019 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 6 Dec 2019 10:35:09 +0100 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> Message-ID: <0cf7de65-a265-ba47-c7f4-dfa4f6fe2c67@openstack.org> Clark Boylan wrote: > [...] > The OpenDev project will be governed by two entities. The first is the service coordinator. Responsibilities for the service coordinator are essentially the same of the existing Infra team PTL. They coordinate work of contributors and act as a tie breaker when clear consensus isn't found. > > The service coordinator is elected every 6 months. The nominee pool and electorate are individuals that have contributed changes to OpenDev in the last 12 months. > > The second is an advisory board made up of representatives from OpenDev's user base of projects and organizations that contribute compute resources. This advisory board provides a formal location for both our users and contributing orgs to express their needs to the OpenDev project. This creates a clear contact point for feedback on priorities and direction. Their input will help ensure that the OpenDev project is a good steward of the resources provided to it and that user needs are being addressed. > > Contributing orgs and user projects are not required to join the advisory board, but are encouraged to do so. Individuals on the board would be selected by their own constituency as that constituency feels is appropriate. > > The advisory board will also serve as a point of contact for the OpenDev project when making changes that may be disruptive. The intent is to create bidirectional communication between OpenDev and the advisory board. > > How does this look? Loving it. -- Thierry Carrez (ttx) From mnaser at vexxhost.com Fri Dec 6 14:53:33 2019 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 6 Dec 2019 09:53:33 -0500 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <0cf7de65-a265-ba47-c7f4-dfa4f6fe2c67@openstack.org> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> <0cf7de65-a265-ba47-c7f4-dfa4f6fe2c67@openstack.org> Message-ID: On Fri, Dec 6, 2019 at 4:37 AM Thierry Carrez wrote: > > Clark Boylan wrote: > > [...] > > The OpenDev project will be governed by two entities. The first is the service coordinator. Responsibilities for the service coordinator are essentially the same of the existing Infra team PTL. They coordinate work of contributors and act as a tie breaker when clear consensus isn't found. > > > > The service coordinator is elected every 6 months. The nominee pool and electorate are individuals that have contributed changes to OpenDev in the last 12 months. > > > > The second is an advisory board made up of representatives from OpenDev's user base of projects and organizations that contribute compute resources. This advisory board provides a formal location for both our users and contributing orgs to express their needs to the OpenDev project. This creates a clear contact point for feedback on priorities and direction. Their input will help ensure that the OpenDev project is a good steward of the resources provided to it and that user needs are being addressed. > > > > Contributing orgs and user projects are not required to join the advisory board, but are encouraged to do so. Individuals on the board would be selected by their own constituency as that constituency feels is appropriate. > > > > The advisory board will also serve as a point of contact for the OpenDev project when making changes that may be disruptive. The intent is to create bidirectional communication between OpenDev and the advisory board. > > > > How does this look? > > Loving it. LGTM too! :) > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From fungi at yuggoth.org Fri Dec 6 15:35:13 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 6 Dec 2019 15:35:13 +0000 Subject: [OpenStack-Infra] OpenDev Independence and Governance In-Reply-To: <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> References: <36266580-70f6-4aa0-af94-40c503a0079b@www.fastmail.com> <8893dfae-f0f4-48b4-b563-4d1abf2a422e@www.fastmail.com> Message-ID: <20191206153513.sroaflt6ao2ognbb@yuggoth.org> On 2019-12-05 15:52:10 -0800 (-0800), Clark Boylan wrote: [...] > The OpenDev project will be governed by two entities. The first is > the service coordinator. Responsibilities for the service > coordinator are essentially the same of the existing Infra team > PTL. They coordinate work of contributors and act as a tie breaker > when clear consensus isn't found. > > The service coordinator is elected every 6 months. The nominee > pool and electorate are individuals that have contributed changes > to OpenDev in the last 12 months. > > The second is an advisory board made up of representatives from > OpenDev's user base of projects and organizations that contribute > compute resources. This advisory board provides a formal location > for both our users and contributing orgs to express their needs to > the OpenDev project. This creates a clear contact point for > feedback on priorities and direction. Their input will help ensure > that the OpenDev project is a good steward of the resources > provided to it and that user needs are being addressed. > > Contributing orgs and user projects are not required to join the > advisory board, but are encouraged to do so. Individuals on the > board would be selected by their own constituency as that > constituency feels is appropriate. > > The advisory board will also serve as a point of contact for the > OpenDev project when making changes that may be disruptive. The > intent is to create bidirectional communication between OpenDev > and the advisory board. > > How does this look? I'm not certain it's correct to say that the advisory board is an entity which governs OpenDev; it's a source of input into decisions made by the group and/or coordinator but it's not a decision-making authority. I'm also not sure it's an incorrect way to phrase it either: GCIDE definition #2 of "govern" does include "to influence" as a possible interpretation there. So it still might work, I'm just slightly worried about future misinterpretation of the intent behind that choice of word. Overall though, I think this is excellent and embodies the idea elegantly--thanks again--great stuff! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From cboylan at sapwetik.org Mon Dec 9 21:31:56 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 09 Dec 2019 13:31:56 -0800 Subject: [OpenStack-Infra] Meeting Agenda for December 10, 2019 Message-ID: <86256dfa-e586-465e-ad2f-40d40ea676d4@www.fastmail.com> We will have our weekly team meeting at 19:00UTC December 10, 2019 in #openstack-meeting. We will use this agenda: == Agenda for next meeting == * Announcements ** No meeting December 24, 2019 and December 31, 2019 * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Possible gitea/go-git bug in current version of gitea we are running https://storyboard.openstack.org/#!/story/2006849 *** Bug seems to remain present after Gitea 1.10 upgrade * General topics ** Trusty Upgrade Progress (clarkb 20191210) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191210) *** Infra-root needs to create AFS volumes. ** dib/nodepool container (ianw 20191210) *** http://lists.openstack.org/pipermail/openstack-infra/2019-November/006529.html ** Discussion on retiring services that are largely unmaintained or unused (clarkb 20191210) *** Want to start this discussion as services like Ask are barely on life support and we should probably clean them up. *** https://etherpad.openstack.org/infra-service-list * Open discussion From joshua.hesketh at gmail.com Mon Dec 9 23:28:07 2019 From: joshua.hesketh at gmail.com (Joshua Hesketh) Date: Tue, 10 Dec 2019 10:28:07 +1100 Subject: [OpenStack-Infra] Resigning from infra-core Message-ID: Hello all, I've been dreading writing this for a while now but all good things must come to an end. Due to changes at work and my inability to sustain any significant contributions to the project I think that regrettably it is time to resign from infra-core. It has been a wonderful experience contributing to OpenStack and OpenDev I'll miss working with everybody and it has been an absolute pleasure to get to know some of you both professionally and personally. I will certainly miss you all and cannot understate how thrilled I am to have had this chance to work with everyone. It has been a highlight of both my career and in some cases my life. Having said that, I will still be around, so please do not hesitate to contact me should you need my input on anything or if there is something I can do to help. I also intend to still be involved with Zuul in whatever capacity I can. I hope that our paths will cross again in the near future, and wish you all all the best with the projects going forward. Kind regards, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Mon Dec 9 23:40:07 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 09 Dec 2019 15:40:07 -0800 Subject: [OpenStack-Infra] Resigning from infra-core In-Reply-To: References: Message-ID: <829f27af-8bcf-46cd-97fe-30eee9ae3020@www.fastmail.com> On Mon, Dec 9, 2019, at 3:28 PM, Joshua Hesketh wrote: > Hello all, > > I've been dreading writing this for a while now but all good things > must come to an end. Due to changes at work and my inability to sustain > any significant contributions to the project I think that regrettably > it is time to resign from infra-core. > > It has been a wonderful experience contributing to OpenStack and > OpenDev I'll miss working with everybody and it has been an absolute > pleasure to get to know some of you both professionally and personally. > I will certainly miss you all and cannot understate how thrilled I am > to have had this chance to work with everyone. It has been a highlight > of both my career and in some cases my life. > > Having said that, I will still be around, so please do not hesitate to > contact me should you need my input on anything or if there is > something I can do to help. I also intend to still be involved with > Zuul in whatever capacity I can. > > I hope that our paths will cross again in the near future, and wish you > all all the best with the projects going forward. > > Kind regards, > Josh Thank you for all the help over the years. I too have enjoyed working with you and am sad to make this change official. If you ever make it back towards openstack/opendev we'd be happy to add you into the core group again. Also thank you for giving us the best Gerrit username ever: Turbo Hipster. I wish you luck with your new endeavors and hope to see you around, Clark From fungi at yuggoth.org Tue Dec 10 00:13:46 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 10 Dec 2019 00:13:46 +0000 Subject: [OpenStack-Infra] Resigning from infra-core In-Reply-To: References: Message-ID: <20191210001346.qfo3o2upav4zt7cl@yuggoth.org> Thanks for all the help these many years, I'm glad to know you'll at least still be keeping an eye on us! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From sgw at linux.intel.com Fri Dec 13 16:48:21 2019 From: sgw at linux.intel.com (Saul Wold) Date: Fri, 13 Dec 2019 08:48:21 -0800 Subject: [OpenStack-Infra] Fwd: CVE References in LPs are messed up after centos feature branch rebase In-Reply-To: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> Message-ID: Hello Infra team: Apparently something got messed up with Launchpad and updating a number of starlingx repos with a feature branch. I was following the methodology of updating a feature branch with changes from master via merges and I guess when I pushed that to gerrit and it merged, it caused some Launchpad ugliness. See email below. Thoughts? Thanks Sau! -------- Forwarded Message -------- Subject: CVE References in LPs are messed up after centos feature branch rebase Date: Fri, 13 Dec 2019 00:30:26 +0000 From: Khalil, Ghada To: Saul Wold Hi Saul, The CVE References in about 15 LPs are now messed up after the rebase of the f-centos8 feature branch. The rebase updated a large # of launchpads and somehow automatically added CVE references (from a subset of bugs) to all of them. Any idea what is going on here? Here are some examples: https://bugs.launchpad.net/starlingx/+bug/1844579 Originally had no CVE References. Now it has 3 references. https://bugs.launchpad.net/starlingx/+bug/1849200 Originally only had CVE-2018-15686 as a CVE Reference. Now it has all the recently fixed CVEs linked to this bug. Snapshot from the full activity log: Here is the query that shows that all the bugs that were picked up in the rebase now have CVE links: https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* direct 613.270.2273  skype ghada.khalil.ottawa 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 From thierry at openstack.org Fri Dec 13 17:01:03 2019 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 13 Dec 2019 18:01:03 +0100 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: References: Message-ID: I moved to implementation on this, but I hit an issue with the original plan: > [...] > The job should be lightweight enough to run on the executor. With all > those safeguards in place, I do not expect it to trigger significant > additional load. My current implementation is a python script run from tox. But I can't use the standard tox jobs as they have "hosts:all" tasks all over them which are bypassed[1] if the job is run on the executor. [1] See https://zuul.opendev.org/t/openstack/build/4056ca3ee8b247ebbe1cbb1474191c16/console Ideally I would define my own narrow playbook to run the script, without inheriting from the standard tox job. However the current script requires some dependencies to be installed (openstack-governance, yaml...). Here are the options I see: 1- reimplementing most of the unittests/tox job logic in "hosts:localhost" playbook(s) -- would mean lots of copypaste, does not rhyme so well with "lightweight", and increases execution times significantly 2- rewrite the Python script so that it can run on stdlib -- not sure I want to write a YAML parser from scratch though 3- Abandon the idea of running on the executor -- the trick is that for such a short job the overhead of requesting a test node is a bit heavy, and we want to run the job on every vote change on release requests Other ideas? -- Thierry Carrez (ttx) From cboylan at sapwetik.org Fri Dec 13 17:17:05 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 13 Dec 2019 09:17:05 -0800 Subject: [OpenStack-Infra] =?utf-8?q?Fwd=3A_CVE_References_in_LPs_are_mess?= =?utf-8?q?ed_up_after_centos_feature_branch_rebase?= In-Reply-To: References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> Message-ID: <12e19637-d7fe-495a-824a-145df26a3bc7@www.fastmail.com> On Fri, Dec 13, 2019, at 8:48 AM, Saul Wold wrote: > > Hello Infra team: > > Apparently something got messed up with Launchpad and updating a number > of starlingx repos with a feature branch. > > I was following the methodology of updating a feature branch with > changes from master via merges and I guess when I pushed that to gerrit > and it merged, it caused some Launchpad ugliness. See email below. > > Thoughts? I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. > > Thanks > Sau! > > > > -------- Forwarded Message -------- > Subject: CVE References in LPs are messed up after centos feature > branch rebase > Date: Fri, 13 Dec 2019 00:30:26 +0000 > From: Khalil, Ghada > To: Saul Wold > > > > Hi Saul, > > The CVE References in about 15 LPs are now messed up after the rebase of > the f-centos8 feature branch. The rebase updated a large # of launchpads > and somehow automatically added CVE references (from a subset of bugs) > to all of them. Any idea what is going on here? > > Here are some examples: > > https://bugs.launchpad.net/starlingx/+bug/1844579 > > Originally had no CVE References. Now it has 3 references. > > https://bugs.launchpad.net/starlingx/+bug/1849200 > > Originally only had CVE-2018-15686 as a CVE Reference. Now it has all > the recently fixed CVEs linked to this bug. > > Snapshot from the full activity log: > > Here is the query that shows that all the bugs that were picked up in > the rebase now have CVE links: > > https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search > > *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* > direct 613.270.2273  skype ghada.khalil.ottawa > > 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 > > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From corvus at inaugust.com Fri Dec 13 17:31:40 2019 From: corvus at inaugust.com (James E. Blair) Date: Fri, 13 Dec 2019 09:31:40 -0800 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: (Thierry Carrez's message of "Fri, 13 Dec 2019 18:01:03 +0100") References: Message-ID: <87h824t9mr.fsf@meyer.lemoncheese.net> Thierry Carrez writes: > I moved to implementation on this, but I hit an issue with the > original plan: > >> [...] >> The job should be lightweight enough to run on the executor. With >> all those safeguards in place, I do not expect it to trigger >> significant additional load. > > My current implementation is a python script run from tox. But I can't > use the standard tox jobs as they have "hosts:all" tasks all over them > which are bypassed[1] if the job is run on the executor. > > [1] See > https://zuul.opendev.org/t/openstack/build/4056ca3ee8b247ebbe1cbb1474191c16/console > > Ideally I would define my own narrow playbook to run the script, > without inheriting from the standard tox job. However the current > script requires some dependencies to be installed > (openstack-governance, yaml...). > > Here are the options I see: > > 1- reimplementing most of the unittests/tox job logic in > "hosts:localhost" playbook(s) -- would mean lots of copypaste, does > not rhyme so well with "lightweight", and increases execution times > significantly On the contrary, this is quite simple. The jobs in zuul-jobs are designed to have very simple playbooks which are typically just lists of roles. Our goal was to make them as much like using JJB as possible. These are the 2 playbooks involved: https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/tox/pre.yaml https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/tox/run.yaml Ultimately the entire job is just a list of 4 roles: - ensure-tox - ensure-python - revoke-sudo - tox Please feel free to make a job with whatever role combination you need. If you plan to run on the executor, you do not need ensure-python; we know it's there. Nor do you need revoke-sudo; we know we don't have sudo. On the other hand, Zuul restricts what can be run on the executor by playbooks in untrusted repos, and executing a subprocess like tox is one of the restricted actions, so if you did make a "hosts: localhost" playbook, it would not work if run out of the releases repo. It would need to be put in the project-config repo, and changes to the job would not be self-testing. But if you've got this mostly working already, that's probably not a big deal. But back on the first hand, I think that installing python packages in a virtualenv is too heavyweight for a job to run on the executor. The candidates we usually look for are things that can run with what's already installed. Happily, yaml is already installed, because it's kind of a big deal on the executor. Unhappily, openstack-governance is not merely a repo you need to have on-disk, but is actually a python package you need installed (wow, when did that happen?). We were so close. If you just needed to run a python script that imported yaml and read a file out of governance, I'd say it would be a great candidate for running on the executor. But I think the installation of openstack-governance (which has its own requirements that are not installed on the executor) pushes this over the line, and we should run it on a full node. > 2- rewrite the Python script so that it can run on stdlib -- not sure > I want to write a YAML parser from scratch though If you want to drop the dependency on openstack-governance and rewrite the "business logic" parts of that without rewriting the yaml parsing parts (since PyYAML is installed), then the above is a viable option. > 3- Abandon the idea of running on the executor -- the trick is that > for such a short job the overhead of requesting a test node is a bit > heavy, and we want to run the job on every vote change on release > requests Maybe #2 is worth it then? -Jim From tdecacqu at redhat.com Fri Dec 13 18:44:53 2019 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Fri, 13 Dec 2019 18:44:53 +0000 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: References: Message-ID: <87h824awuy.tristanC@fedora> On Fri, Dec 13, 2019 at 18:01 Thierry Carrez wrote: [...] > 3- Abandon the idea of running on the executor -- the trick is that for > such a short job the overhead of requesting a test node is a bit heavy, > and we want to run the job on every vote change on release requests > > Other ideas? > We usually run such jobs in kubernetes pods, perhaps a new k8s provider could be added to opendev? Regards, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From fungi at yuggoth.org Fri Dec 13 21:09:35 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 13 Dec 2019 21:09:35 +0000 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: References: Message-ID: <20191213210935.cctccyraac5d6hfz@yuggoth.org> On 2019-12-13 18:01:03 +0100 (+0100), Thierry Carrez wrote: [...] > Ideally I would define my own narrow playbook to run the script, without > inheriting from the standard tox job. However the current script requires > some dependencies to be installed (openstack-governance, yaml...). > > Here are the options I see: > > 1- reimplementing most of the unittests/tox job logic in "hosts:localhost" > playbook(s) -- would mean lots of copypaste, does not rhyme so well with > "lightweight", and increases execution times significantly > > 2- rewrite the Python script so that it can run on stdlib -- not sure I want > to write a YAML parser from scratch though > > 3- Abandon the idea of running on the executor -- the trick is that for such > a short job the overhead of requesting a test node is a bit heavy, and we > want to run the job on every vote change on release requests > > Other ideas? Stepping back and thinking about the overall goal (at least what I recall originally discussing), you basically want to look at what the change proposes to update in the releases repo, join that with project information in openstack-governance to get the list of liaisons, then contact Gerrit and add those liaisons as requested reviewers on the change or leave a review comment listing them (or maybe both), right? Assuming that's the case, the repos and Git and pyyaml are available to the workspace on the executor easily enough. Gerrit has a REST API and we have requests already importable too if Ansible's built-in HTTP module isn't sufficiently flexible... is that enough to get it done? That's basically what I was thinking about when I originally suggested a job "lightweight enough to run on the executor." I assumed it would work similar to some other jobs we already have which use an Ansible playbook to call a remote REST API with some supplied credentials based on some information in a change. Speculatively testing changes to the job will be tough of course because of the need to avoid leaking the Gerrit secret, but that's going to be the case with any playbook which needs to authenticate to a remote service. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From thierry at openstack.org Sat Dec 14 17:30:01 2019 From: thierry at openstack.org (Thierry Carrez) Date: Sat, 14 Dec 2019 18:30:01 +0100 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: <87h824t9mr.fsf@meyer.lemoncheese.net> References: <87h824t9mr.fsf@meyer.lemoncheese.net> Message-ID: <01321aaf-713d-6a5c-14d7-14fa60415e94@openstack.org> James E. Blair wrote: > [...] > But back on the first hand, I think that installing python packages in a > virtualenv is too heavyweight for a job to run on the executor. The > candidates we usually look for are things that can run with what's > already installed. Happily, yaml is already installed, because it's > kind of a big deal on the executor. Unhappily, openstack-governance is > not merely a repo you need to have on-disk, but is actually a python > package you need installed (wow, when did that happen?). > > We were so close. If you just needed to run a python script that > imported yaml and read a file out of governance, I'd say it would be a > great candidate for running on the executor. But I think the > installation of openstack-governance (which has its own requirements > that are not installed on the executor) pushes this over the line, and > we should run it on a full node. Actually the script only uses openstack-governance to parse YAML files that are in the governance repository... So if YAML is available and the contents of the governance repo are accessible, that can easily work. The only drawback compared to using the governance lib is that it will not survive a change in the YAML format of governance files... but then it's not the only thing that would break if we did that. So it looks like a simple Python script that only imports yaml would work on the executor. The script uses requests as well, but I can make it use urllib instead (unless requests is pre-installed on the executor too ?) Thanks for the full analysis, I learned a couple of things :) -- Thierry Carrez (ttx) From sgw at linux.intel.com Mon Dec 16 15:46:04 2019 From: sgw at linux.intel.com (Saul Wold) Date: Mon, 16 Dec 2019 07:46:04 -0800 Subject: [OpenStack-Infra] Fwd: CVE References in LPs are messed up after centos feature branch rebase In-Reply-To: References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> Message-ID: <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> Hi Clark, Sorry, I only get the archive of Infra and Ghada is not on the list, if you can please reply to us and the list that would be great. > > I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. Is there a different way to do the merge activity? > > Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? > Yes, that comment does not belong with that bug and because the comment includes CVE-2019-XXXXX formating it adds the CVE References metadata also. > If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. Modifying the merge trees would defeat the purpose of doing the merge I think. Does this issue not affect other projects or are we yet again doing strange operations in StarlingX ;-)! Not sure how hare it would be to filter for feature branches. Thanks Sau! On 12/13/19 8:48 AM, Saul Wold wrote: > > Hello Infra team: > > Apparently something got messed up with Launchpad and updating a number > of starlingx repos with a feature branch. > > I was following the methodology of updating a feature branch with > changes from master via merges and I guess when I pushed that to gerrit > and it merged, it caused some Launchpad ugliness. See email below. > > Thoughts? > > Thanks > Sau! > > > > -------- Forwarded Message -------- > Subject:     CVE References in LPs are messed up after centos feature > branch rebase > Date:     Fri, 13 Dec 2019 00:30:26 +0000 > From:     Khalil, Ghada > To:     Saul Wold > > > > Hi Saul, > > The CVE References in about 15 LPs are now messed up after the rebase of > the f-centos8 feature branch. The rebase updated a large # of launchpads > and somehow automatically added CVE references (from a subset of bugs) > to all of them. Any idea what is going on here? > > Here are some examples: > > https://bugs.launchpad.net/starlingx/+bug/1844579 > > Originally had no CVE References. Now it has 3 references. > > https://bugs.launchpad.net/starlingx/+bug/1849200 > > Originally only had CVE-2018-15686 as a CVE Reference. Now it has all > the recently fixed CVEs linked to this bug. > > Snapshot from the full activity log: > > Here is the query that shows that all the bugs that were picked up in > the rebase now have CVE links: > > https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search > > > *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* > direct 613.270.2273  skype ghada.khalil.ottawa > > 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 > From cboylan at sapwetik.org Mon Dec 16 16:22:18 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 16 Dec 2019 08:22:18 -0800 Subject: [OpenStack-Infra] =?utf-8?q?Fwd=3A_CVE_References_in_LPs_are_mess?= =?utf-8?q?ed_up_after_centos_feature_branch_rebase?= In-Reply-To: <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> Message-ID: <80983118-a157-48df-92a5-73f84cbda718@www.fastmail.com> On Mon, Dec 16, 2019, at 7:46 AM, Saul Wold wrote: > > Hi Clark, > > Sorry, I only get the archive of Infra and Ghada is not on the list, if > you can please reply to us and the list that would be great. > > > > I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. > > Is there a different way to do the merge activity? > > > > > Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? > > > Yes, that comment does not belong with that bug and because the comment > includes CVE-2019-XXXXX formating it adds the CVE References metadata also. Can you expand on this? Why does the comment not belong with the bug? The bug was fixed on the f/centos8 branch and that is what the comment is telling you. Where is the CVE References metadata? > > > If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. > > Modifying the merge trees would defeat the purpose of doing the merge I > think. Does this issue not affect other projects or are we yet again > doing strange operations in StarlingX ;-)! Not sure how hare it would > be to filter for feature branches. Yes, you probably don't want to change the merge trees as the idea here is to bring the feature branch up to date, and probably the most important aspect of that is ensuring you've merged security fixes. Use of feature branches at all may qualify as "strange". Most projects tend to develop against their target branch. You'll see large change series from nova for example rather than creating feature branches for that work. This means most projects are never in a situation to potentially hit this problem. One major historical exception to this has been the swift project. It is possible they have run into this problem but ignored it? Or not seen it as problematic? I did double check that the change merge hook code doesn't handle feature branches as a special case already (openstack uses the feature/ prefix not f/ so thought maybe there was a difference in matchers?) but I found nothing. https://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/update_bug.py#L222-L252 is the code in question and what we'd end up updating if we wanted to apply some rule set to the bot around feature branches. Something else to keep in mind, there has been some discussion of replacing these existing bots with Zuul jobs similar to how github replication is done. That could possibly give different repos far more flexibility through Zuul configuration specific to that repo. This may be another approach worth taking if we find we end up doing something StarlingX specific. > > Thanks > Sau! > > > > > > On 12/13/19 8:48 AM, Saul Wold wrote: > > > > Hello Infra team: > > > > Apparently something got messed up with Launchpad and updating a number > > of starlingx repos with a feature branch. > > > > I was following the methodology of updating a feature branch with > > changes from master via merges and I guess when I pushed that to gerrit > > and it merged, it caused some Launchpad ugliness. See email below. > > > > Thoughts? > > > > Thanks > > Sau! > > > > > > > > -------- Forwarded Message -------- > > Subject:     CVE References in LPs are messed up after centos feature > > branch rebase > > Date:     Fri, 13 Dec 2019 00:30:26 +0000 > > From:     Khalil, Ghada > > To:     Saul Wold > > > > > > > > Hi Saul, > > > > The CVE References in about 15 LPs are now messed up after the rebase of > > the f-centos8 feature branch. The rebase updated a large # of launchpads > > and somehow automatically added CVE references (from a subset of bugs) > > to all of them. Any idea what is going on here? > > > > Here are some examples: > > > > https://bugs.launchpad.net/starlingx/+bug/1844579 > > > > Originally had no CVE References. Now it has 3 references. > > > > https://bugs.launchpad.net/starlingx/+bug/1849200 > > > > Originally only had CVE-2018-15686 as a CVE Reference. Now it has all > > the recently fixed CVEs linked to this bug. > > > > Snapshot from the full activity log: > > > > Here is the query that shows that all the bugs that were picked up in > > the rebase now have CVE links: > > > > https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search > > > > > > *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* > > direct 613.270.2273  skype ghada.khalil.ottawa > > > > 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 > > From corvus at inaugust.com Mon Dec 16 18:28:05 2019 From: corvus at inaugust.com (James E. Blair) Date: Mon, 16 Dec 2019 10:28:05 -0800 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: <01321aaf-713d-6a5c-14d7-14fa60415e94@openstack.org> (Thierry Carrez's message of "Sat, 14 Dec 2019 18:30:01 +0100") References: <87h824t9mr.fsf@meyer.lemoncheese.net> <01321aaf-713d-6a5c-14d7-14fa60415e94@openstack.org> Message-ID: <87v9qgnn0q.fsf@meyer.lemoncheese.net> Thierry Carrez writes: > James E. Blair wrote: >> [...] >> But back on the first hand, I think that installing python packages in a >> virtualenv is too heavyweight for a job to run on the executor. The >> candidates we usually look for are things that can run with what's >> already installed. Happily, yaml is already installed, because it's >> kind of a big deal on the executor. Unhappily, openstack-governance is >> not merely a repo you need to have on-disk, but is actually a python >> package you need installed (wow, when did that happen?). >> >> We were so close. If you just needed to run a python script that >> imported yaml and read a file out of governance, I'd say it would be a >> great candidate for running on the executor. But I think the >> installation of openstack-governance (which has its own requirements >> that are not installed on the executor) pushes this over the line, and >> we should run it on a full node. > > Actually the script only uses openstack-governance to parse YAML files > that are in the governance repository... So if YAML is available and > the contents of the governance repo are accessible, that can easily > work. > > The only drawback compared to using the governance lib is that it will > not survive a change in the YAML format of governance files... but > then it's not the only thing that would break if we did that. > > So it looks like a simple Python script that only imports yaml would > work on the executor. The script uses requests as well, but I can make > it use urllib instead (unless requests is pre-installed on the > executor too ?) Yes, requests is installed too. > Thanks for the full analysis, I learned a couple of things :) You're welcome! -Jim From cboylan at sapwetik.org Tue Dec 17 00:13:27 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 16 Dec 2019 16:13:27 -0800 Subject: [OpenStack-Infra] Meeting Agenda for December 17, 2019 Message-ID: <27f9ebae-ddeb-4aaa-a564-6d31acbe5eff@www.fastmail.com> We will meet for the last time in 2019 on December 17 at 19:00UTC in #openstack-meeting with this agenda: == Agenda for next meeting == * Announcements ** No meeting December 24, 2019 and December 31, 2019 * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Possible gitea/go-git bug in current version of gitea we are running https://storyboard.openstack.org/#!/story/2006849 *** Bug seems to remain present after Gitea 1.10 upgrade * General topics ** Trusty Upgrade Progress (clarkb 20191217) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191217) *** Infra-root needs to create AFS volumes. ** Discussion on retiring services that are largely unmaintained or unused (clarkb 20191217) *** Want to start this discussion as services like Ask are barely on life support and we should probably clean them up. *** https://etherpad.openstack.org/infra-service-list * Open discussion From hashar at free.fr Tue Dec 17 10:04:37 2019 From: hashar at free.fr (Antoine Musso) Date: Tue, 17 Dec 2019 11:04:37 +0100 Subject: [OpenStack-Infra] Resigning from infra-core In-Reply-To: References: Message-ID: <7dbf3a44-2cad-5f66-9afd-df2cf38fc24a@free.fr> On 10/12/2019 00:28, Joshua Hesketh wrote: > Hello all, > > I've been dreading writing this for a while now but all good things > must come to an end. Due to changes at work and my inability to > sustain any significant contributions to the project I think that > regrettably it is time to resign from infra-core. > > It has been a wonderful experience contributing to OpenStack and > OpenDev I'll miss working with everybody and it has been an absolute > pleasure to get to know some of you both professionally and > personally. I will certainly miss you all and cannot understate how > thrilled I am to have had this chance to work with everyone. It has > been a highlight of both my career and in some cases my life. > > Having said that, I will still be around, so please do not hesitate to > contact me should you need my input on anything or if there is > something I can do to help. I also intend to still be involved with > Zuul in whatever capacity I can. > > I hope that our paths will cross again in the near future, and wish > you all all the best with the projects going forward. > > Kind regards, > Josh Hello Joshua, I am not very active anymore, but still have vivid memories of my interactions with you a few years ago. Thank you for the Zuul changes that introduces the reporters, sources, triggers. I remember that chain of patches being rebased over and over until it went suitable for merging. Thank you for bringing in Swift support to Zuul. Even if I have never deployed it, that definitely sounded like a very cool and nice feature. Thank you for all the kindly reviews you have made to my (and others) patches, you have been instrumental in making me love python again and trust in open source development models. Thank you for the explanations of how Turbo-Hipster fetched patches from CI. That eventually has lead me to port the git logic from devstack shell script to python and spawned the zuul-cloner command (now gone RIP). Have a good summer :] Antoine "hashar" Musso From sgw at linux.intel.com Tue Dec 17 18:16:19 2019 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 17 Dec 2019 10:16:19 -0800 Subject: [OpenStack-Infra] Fwd: CVE References in LPs are messed up after centos feature branch rebase In-Reply-To: <80983118-a157-48df-92a5-73f84cbda718@www.fastmail.com> References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> <80983118-a157-48df-92a5-73f84cbda718@www.fastmail.com> Message-ID: <816d506c-1d2c-edd2-d0b5-98fc458477c3@linux.intel.com> On 12/16/19 8:22 AM, Clark Boylan wrote: > On Mon, Dec 16, 2019, at 7:46 AM, Saul Wold wrote: >> >> Hi Clark, >> >> Sorry, I only get the archive of Infra and Ghada is not on the list, if >> you can please reply to us and the list that would be great. >>> >>> I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. >> >> Is there a different way to do the merge activity? >> >>> >>> Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? >>> >> Yes, that comment does not belong with that bug and because the comment >> includes CVE-2019-XXXXX formating it adds the CVE References metadata also. > > Can you expand on this? Why does the comment not belong with the bug? The bug was fixed on the f/centos8 branch and that is what the comment is telling you. Where is the CVE References metadata? > The "merge commit" message contains all the commits that are part of the merge commit. I guess the hook sees the merge commit with the Closes: tag and adds the complete commit message to the associated launchpad bugs (in the case of multiple closes due to multiple commit messages in the merge commit. Since that larger "merge commit" message contains CVE reference they get added to the Closes: tagged bugs. Look again at https://bugs.launchpad.net/starlingx/+bug/1844579 Below the description is the CVE Reference with links to the CVE mentioned. This launchpad has nothing to do with the CVEs in question. I guess this is done inside launchpad, not in the opendev bugtask. Does that make more sense? >> >>> If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. >> >> Modifying the merge trees would defeat the purpose of doing the merge I >> think. Does this issue not affect other projects or are we yet again >> doing strange operations in StarlingX ;-)! Not sure how hare it would >> be to filter for feature branches. > > Yes, you probably don't want to change the merge trees as the idea here is to bring the feature branch up to date, and probably the most important aspect of that is ensuring you've merged security fixes. > > Use of feature branches at all may qualify as "strange". Most projects tend to develop against their target branch. You'll see large change series from nova for example rather than creating feature branches for that work. This means most projects are never in a situation to potentially hit this problem. One major historical exception to this has been the swift project. It is possible they have run into this problem but ignored it? Or not seen it as problematic? > I think we chose to use feature branches since there are multiple repos in StarlingX and we need a way to coordinate work across them. They might not have as many CVE reference also, since StarlingX has many references to Linux Userspace which can contain more CVEs. > I did double check that the change merge hook code doesn't handle feature branches as a special case already (openstack uses the feature/ prefix not f/ so thought maybe there was a difference in matchers?) but I found nothing. https://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/update_bug.py#L222-L252 is the code in question and what we'd end up updating if we wanted to apply some rule set to the bot around feature branches. > Yeah, I agree a check here might be the right place for this. > Something else to keep in mind, there has been some discussion of replacing these existing bots with Zuul jobs similar to how github replication is done. That could possibly give different repos far more flexibility through Zuul configuration specific to that repo. This may be another approach worth taking if we find we end up doing something StarlingX specific. > Something to consider down the road. Sau! >> >> Thanks >> Sau! >> >> >> >> >> >> On 12/13/19 8:48 AM, Saul Wold wrote: >>> >>> Hello Infra team: >>> >>> Apparently something got messed up with Launchpad and updating a number >>> of starlingx repos with a feature branch. >>> >>> I was following the methodology of updating a feature branch with >>> changes from master via merges and I guess when I pushed that to gerrit >>> and it merged, it caused some Launchpad ugliness. See email below. >>> >>> Thoughts? >>> >>> Thanks >>> Sau! >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject:     CVE References in LPs are messed up after centos feature >>> branch rebase >>> Date:     Fri, 13 Dec 2019 00:30:26 +0000 >>> From:     Khalil, Ghada >>> To:     Saul Wold >>> >>> >>> >>> Hi Saul, >>> >>> The CVE References in about 15 LPs are now messed up after the rebase of >>> the f-centos8 feature branch. The rebase updated a large # of launchpads >>> and somehow automatically added CVE references (from a subset of bugs) >>> to all of them. Any idea what is going on here? >>> >>> Here are some examples: >>> >>> https://bugs.launchpad.net/starlingx/+bug/1844579 >>> >>> Originally had no CVE References. Now it has 3 references. >>> >>> https://bugs.launchpad.net/starlingx/+bug/1849200 >>> >>> Originally only had CVE-2018-15686 as a CVE Reference. Now it has all >>> the recently fixed CVEs linked to this bug. >>> >>> Snapshot from the full activity log: >>> >>> Here is the query that shows that all the bugs that were picked up in >>> the rebase now have CVE links: >>> >>> https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search >>> >>> >>> *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* >>> direct 613.270.2273  skype ghada.khalil.ottawa >>> >>> 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 >>> From cboylan at sapwetik.org Tue Dec 17 18:36:49 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 17 Dec 2019 10:36:49 -0800 Subject: [OpenStack-Infra] =?utf-8?q?Fwd=3A_CVE_References_in_LPs_are_mess?= =?utf-8?q?ed_up_after_centos_feature_branch_rebase?= In-Reply-To: <816d506c-1d2c-edd2-d0b5-98fc458477c3@linux.intel.com> References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> <80983118-a157-48df-92a5-73f84cbda718@www.fastmail.com> <816d506c-1d2c-edd2-d0b5-98fc458477c3@linux.intel.com> Message-ID: On Tue, Dec 17, 2019, at 10:16 AM, Saul Wold wrote: > > > On 12/16/19 8:22 AM, Clark Boylan wrote: > > On Mon, Dec 16, 2019, at 7:46 AM, Saul Wold wrote: > >> > >> Hi Clark, > >> > >> Sorry, I only get the archive of Infra and Ghada is not on the list, if > >> you can please reply to us and the list that would be great. > >>> > >>> I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. > >> > >> Is there a different way to do the merge activity? > >> > >>> > >>> Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? > >>> > >> Yes, that comment does not belong with that bug and because the comment > >> includes CVE-2019-XXXXX formating it adds the CVE References metadata also. > > > > Can you expand on this? Why does the comment not belong with the bug? The bug was fixed on the f/centos8 branch and that is what the comment is telling you. Where is the CVE References metadata? > > > The "merge commit" message contains all the commits that are part of the > merge commit. I guess the hook sees the merge commit with the Closes: > tag and adds the complete commit message to the associated launchpad > bugs (in the case of multiple closes due to multiple commit messages in > the merge commit. > > Since that larger "merge commit" message contains CVE reference they get > added to the Closes: tagged bugs. Look again at > https://bugs.launchpad.net/starlingx/+bug/1844579 > Below the description is the CVE Reference with links to the CVE > mentioned. This launchpad has nothing to do with the CVEs in question. > I guess this is done inside launchpad, not in the opendev bugtask. > > Does that make more sense? Yes, that helps. And yes I believe launchpad is doing its own string scraping and deciding to list those CVEs. I don't believe we are triggering that explicitly. > > >> > >>> If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. > >> > >> Modifying the merge trees would defeat the purpose of doing the merge I > >> think. Does this issue not affect other projects or are we yet again > >> doing strange operations in StarlingX ;-)! Not sure how hare it would > >> be to filter for feature branches. > > > > Yes, you probably don't want to change the merge trees as the idea here is to bring the feature branch up to date, and probably the most important aspect of that is ensuring you've merged security fixes. > > > > Use of feature branches at all may qualify as "strange". Most projects tend to develop against their target branch. You'll see large change series from nova for example rather than creating feature branches for that work. This means most projects are never in a situation to potentially hit this problem. One major historical exception to this has been the swift project. It is possible they have run into this problem but ignored it? Or not seen it as problematic? > > > I think we chose to use feature branches since there are multiple repos > in StarlingX and we need a way to coordinate work across them. Note, Zuul's depends-on functionality is designed to address the need for coordinating work between repos without needing to drastically change workflow. > > They might not have as many CVE reference also, since StarlingX has many > references to Linux Userspace which can contain more CVEs. > > > I did double check that the change merge hook code doesn't handle feature branches as a special case already (openstack uses the feature/ prefix not f/ so thought maybe there was a difference in matchers?) but I found nothing. https://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/update_bug.py#L222-L252 is the code in question and what we'd end up updating if we wanted to apply some rule set to the bot around feature branches. > > > Yeah, I agree a check here might be the right place for this. Based on the above description of the problem what we'd need to do here is remove CVE references from merge commit comments on Launchpad? The tricky bit is knowing when that is appropriate or not and "this is a merge commit" might be the answer. One way to do that would be to report only the merge commit message to the bug. You'd potentially lose launchpad synchronization if you wanted updates in the child commits though. > > > Something else to keep in mind, there has been some discussion of replacing these existing bots with Zuul jobs similar to how github replication is done. That could possibly give different repos far more flexibility through Zuul configuration specific to that repo. This may be another approach worth taking if we find we end up doing something StarlingX specific. > > > Something to consider down the road. > > Sau! > > >> > >> Thanks > >> Sau! > >> > >> > >> > >> > >> > >> On 12/13/19 8:48 AM, Saul Wold wrote: > >>> > >>> Hello Infra team: > >>> > >>> Apparently something got messed up with Launchpad and updating a number > >>> of starlingx repos with a feature branch. > >>> > >>> I was following the methodology of updating a feature branch with > >>> changes from master via merges and I guess when I pushed that to gerrit > >>> and it merged, it caused some Launchpad ugliness. See email below. > >>> > >>> Thoughts? > >>> > >>> Thanks > >>> Sau! > >>> > >>> > >>> > >>> -------- Forwarded Message -------- > >>> Subject:     CVE References in LPs are messed up after centos feature > >>> branch rebase > >>> Date:     Fri, 13 Dec 2019 00:30:26 +0000 > >>> From:     Khalil, Ghada > >>> To:     Saul Wold > >>> > >>> > >>> > >>> Hi Saul, > >>> > >>> The CVE References in about 15 LPs are now messed up after the rebase of > >>> the f-centos8 feature branch. The rebase updated a large # of launchpads > >>> and somehow automatically added CVE references (from a subset of bugs) > >>> to all of them. Any idea what is going on here? > >>> > >>> Here are some examples: > >>> > >>> https://bugs.launchpad.net/starlingx/+bug/1844579 > >>> > >>> Originally had no CVE References. Now it has 3 references. > >>> > >>> https://bugs.launchpad.net/starlingx/+bug/1849200 > >>> > >>> Originally only had CVE-2018-15686 as a CVE Reference. Now it has all > >>> the recently fixed CVEs linked to this bug. > >>> > >>> Snapshot from the full activity log: > >>> > >>> Here is the query that shows that all the bugs that were picked up in > >>> the rebase now have CVE links: > >>> > >>> https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search > >>> > >>> > >>> *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* > >>> direct 613.270.2273  skype ghada.khalil.ottawa > >>> > >>> 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 > >>> > From anteaya at anteaya.info Tue Dec 17 20:56:11 2019 From: anteaya at anteaya.info (Anita Kuno) Date: Tue, 17 Dec 2019 15:56:11 -0500 Subject: [OpenStack-Infra] Resigning from infra-core In-Reply-To: References: Message-ID: On 2019-12-09 6:28 p.m., Joshua Hesketh wrote: > It has been a highlight of both my > career and in some cases my life. The feeling is mutual. be well in all you do. Anita From sgw at linux.intel.com Wed Dec 18 18:19:57 2019 From: sgw at linux.intel.com (Saul Wold) Date: Wed, 18 Dec 2019 10:19:57 -0800 Subject: [OpenStack-Infra] Fwd: CVE References in LPs are messed up after centos feature branch rebase In-Reply-To: References: <151EE31B9FCCA54397A757BC674650F0C16044F8@ALA-MBD.corp.ad.wrs.com> <10e92750-32f7-5065-2f91-d17d9009723b@linux.intel.com> <80983118-a157-48df-92a5-73f84cbda718@www.fastmail.com> <816d506c-1d2c-edd2-d0b5-98fc458477c3@linux.intel.com> Message-ID: On 12/17/19 10:36 AM, Clark Boylan wrote: > On Tue, Dec 17, 2019, at 10:16 AM, Saul Wold wrote: >> >> >> On 12/16/19 8:22 AM, Clark Boylan wrote: >>> On Mon, Dec 16, 2019, at 7:46 AM, Saul Wold wrote: >>>> >>>> Hi Clark, >>>> >>>> Sorry, I only get the archive of Infra and Ghada is not on the list, if >>>> you can please reply to us and the list that would be great. >>>>> >>>>> I think what happened here is you merged bug fixes (in this case cve bug fixes) from master into a feature branch. Then when you pushed that merge commit and merged it, the bot noticed that those bug fixes had merged to the feature branch and commented with those details on the bug. I believe this is "correct" behavior from the bot. >>>> >>>> Is there a different way to do the merge activity? >>>> >>>>> >>>>> Is the issue the existence of comments like https://bugs.launchpad.net/starlingx/+bug/1844579/comments/18 on the bugs? Or is there some other metadata that is being added that I am missing? >>>>> >>>> Yes, that comment does not belong with that bug and because the comment >>>> includes CVE-2019-XXXXX formating it adds the CVE References metadata also. >>> >>> Can you expand on this? Why does the comment not belong with the bug? The bug was fixed on the f/centos8 branch and that is what the comment is telling you. Where is the CVE References metadata? >>> >> The "merge commit" message contains all the commits that are part of the >> merge commit. I guess the hook sees the merge commit with the Closes: >> tag and adds the complete commit message to the associated launchpad >> bugs (in the case of multiple closes due to multiple commit messages in >> the merge commit. >> >> Since that larger "merge commit" message contains CVE reference they get >> added to the Closes: tagged bugs. Look again at >> https://bugs.launchpad.net/starlingx/+bug/1844579 >> Below the description is the CVE Reference with links to the CVE >> mentioned. This launchpad has nothing to do with the CVEs in question. >> I guess this is done inside launchpad, not in the opendev bugtask. >> >> Does that make more sense? > > Yes, that helps. And yes I believe launchpad is doing its own string scraping and deciding to list those CVEs. I don't believe we are triggering that explicitly. > Yes, I realized that after looking at the code you shared with me earlier. This is part of why we might want to consider a simpler merge message to avoid this scraping problem. >> >>>> >>>>> If we don't want comments like that to appear you'd need to modify your merged trees so that bug fixes don't go from master into the feature branch. Or we'd need to come up with some rule set we can apply to the bot to filter bugs out in certain circumstances. >>>> >>>> Modifying the merge trees would defeat the purpose of doing the merge I >>>> think. Does this issue not affect other projects or are we yet again >>>> doing strange operations in StarlingX ;-)! Not sure how hare it would >>>> be to filter for feature branches. >>> >>> Yes, you probably don't want to change the merge trees as the idea here is to bring the feature branch up to date, and probably the most important aspect of that is ensuring you've merged security fixes. >>> >>> Use of feature branches at all may qualify as "strange". Most projects tend to develop against their target branch. You'll see large change series from nova for example rather than creating feature branches for that work. This means most projects are never in a situation to potentially hit this problem. One major historical exception to this has been the swift project. It is possible they have run into this problem but ignored it? Or not seen it as problematic? >>> >> I think we chose to use feature branches since there are multiple repos >> in StarlingX and we need a way to coordinate work across them. > > Note, Zuul's depends-on functionality is designed to address the need for coordinating work between repos without needing to drastically change workflow. > We are aware of that, but it's more about the StarlingX workflow and enabling of changes like moving to a new base OS needs to be done outside of master. So we still need to use the feature branch to enable and test new functionality outside of master. >> >> They might not have as many CVE reference also, since StarlingX has many >> references to Linux Userspace which can contain more CVEs. >> >>> I did double check that the change merge hook code doesn't handle feature branches as a special case already (openstack uses the feature/ prefix not f/ so thought maybe there was a difference in matchers?) but I found nothing. https://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/update_bug.py#L222-L252 is the code in question and what we'd end up updating if we wanted to apply some rule set to the bot around feature branches. >>> >> Yeah, I agree a check here might be the right place for this. > > Based on the above description of the problem what we'd need to do here is remove CVE references from merge commit comments on Launchpad? The tricky bit is knowing when that is appropriate or not and "this is a merge commit" might be the answer. One way to do that would be to report only the merge commit message to the bug. You'd potentially lose launchpad synchronization if you wanted updates in the child commits though. > Yes, As I mentioned above having an abbreviated commit message posted via the hooks is likely the best approach so we can at least track the merge happend for those bugs. Do you need some kind of storyboard or launchpad for this kind of change? Thanks Sau! >> >>> Something else to keep in mind, there has been some discussion of replacing these existing bots with Zuul jobs similar to how github replication is done. That could possibly give different repos far more flexibility through Zuul configuration specific to that repo. This may be another approach worth taking if we find we end up doing something StarlingX specific. >>> >> Something to consider down the road. >> >> Sau! >> >>>> >>>> Thanks >>>> Sau! >>>> >>>> >>>> >>>> >>>> >>>> On 12/13/19 8:48 AM, Saul Wold wrote: >>>>> >>>>> Hello Infra team: >>>>> >>>>> Apparently something got messed up with Launchpad and updating a number >>>>> of starlingx repos with a feature branch. >>>>> >>>>> I was following the methodology of updating a feature branch with >>>>> changes from master via merges and I guess when I pushed that to gerrit >>>>> and it merged, it caused some Launchpad ugliness. See email below. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks >>>>> Sau! >>>>> >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject:     CVE References in LPs are messed up after centos feature >>>>> branch rebase >>>>> Date:     Fri, 13 Dec 2019 00:30:26 +0000 >>>>> From:     Khalil, Ghada >>>>> To:     Saul Wold >>>>> >>>>> >>>>> >>>>> Hi Saul, >>>>> >>>>> The CVE References in about 15 LPs are now messed up after the rebase of >>>>> the f-centos8 feature branch. The rebase updated a large # of launchpads >>>>> and somehow automatically added CVE references (from a subset of bugs) >>>>> to all of them. Any idea what is going on here? >>>>> >>>>> Here are some examples: >>>>> >>>>> https://bugs.launchpad.net/starlingx/+bug/1844579 >>>>> >>>>> Originally had no CVE References. Now it has 3 references. >>>>> >>>>> https://bugs.launchpad.net/starlingx/+bug/1849200 >>>>> >>>>> Originally only had CVE-2018-15686 as a CVE Reference. Now it has all >>>>> the recently fixed CVEs linked to this bug. >>>>> >>>>> Snapshot from the full activity log: >>>>> >>>>> Here is the query that shows that all the bugs that were picked up in >>>>> the rebase now have CVE links: >>>>> >>>>> https://bugs.launchpad.net/starlingx/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=in-f-centos8&field.tags_combinator=ANY&field.has_cve.used=&field.has_cve=on&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search >>>>> >>>>> >>>>> *Ghada Khalil*, Manager, Titanium Cloud, *Wind River* >>>>> direct 613.270.2273  skype ghada.khalil.ottawa >>>>> >>>>> 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5 >>>>> >>