Re: [OpenStack-Infra] [zuul] Software Factory 2.7 is officially released with native zuulv3 support
On 2017-11-28 05:35:54 + (+), Tristan Cacqueray wrote: > We are pleased to announce that Software Factory version 2.7 is > now available. Among other things, it includes a native zuulv3 > support: [...] Not to take away from how awesome this is (it definitely is, congratulations!) but it would have been better to present the "Zuul v3 support" as a technology preview. Zuul hasn't released 3.0.0 yet, v3 is very much in beta with remaining features planned before release. I worry that people trying it out via SF might get a negative impression since it's still an incomplete work in progress at this point. In the interest of learning lessons from history, let's do our best not have a repeat of the GCC 2.96 incident. ;) -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [zuul] third-party CI for zuul-jobs
Jens Harbott writes: > 2017-11-23 5:28 GMT+00:00 Tristan Cacqueray : > ... >> TL;DR; Is it alright if we re-enable this CI and report those tests on >> zuul-jobs patchsets? > > I like the general idea, but please wait for more feedback until doing so. I am in favor of the idea in general, thanks! > Also, IMHO it would be better if you could change the "recheck-sf" > trigger to something that does not also rerun upstream checks. What > seems to work well for other projects is "run ci-name", where ci-name > is the name of the Gerrit account. Actually, I'd prefer that we do the opposite. I'd like the recheck command for both to just be "recheck". There's no harm in both systems re-running tests for a change in this case, and it keeps things simpler for developers. The requirements in https://docs.openstack.org/infra/system-config/third_party.html#requirements state that all systems should honor "recheck". I'd like to go beyond that in zuul-jobs and say that third-party ci systems on that repo should *only* honor "recheck". In the meeting today we agreed that we should start by reporting without voting, gain some confidence, then enable +1/-1 voting. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Merging Zuul v3 into master
On 2017-11-27 15:31:41 -0800 (-0800), James E. Blair wrote: [...] > * If you have outstanding changes proposed to Zuul or Nodepool master > branches, please take a moment and determine whether they are still > relevant in Zuul v3. [...] In an attempt to help this along, I created the following pad yesterday where we can attempt to classify open Zuul and Nodepool changes for their respective repos' master branches: https://etherpad.openstack.org/p/zuulv2-outstanding-change-triage -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Merging Zuul v3 into master
On Mon, Nov 27, 2017 at 5:31 PM, James E. Blair wrote: > ... > > * If you are able to contribute to making the necessary changes to > puppet-openstackci, please reply here to volunteer to do so. > ... I am working on the puppet-openstackci update. Any other third-party CI operators using the module are welcome to chime in. Mikhail Medvedev (mmedvede) ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Tracking the work we are doing and the work we want to get done
Hello, One of the things that has come up a bit recently is onboarding of individuals new to Infra and how they can find what work needs to be done. This is particularly important as Infra has been added to the TC's top help wanted list. We've got a help wanted list under infra-specs (https://specs.openstack.org/openstack-infra/infra-specs/#help-wanted) which is not really up to date with all the things I think we want help with. Thinking about this not everything we want help with will be a spec, but it seems reasonable that we should be able to write a story in storyboard for these items. Since every spec already needs a story the list of stories in storyboard is a superset of our specs. With that in mind I decided to make a storyboard board to manage an Infra TODO list. You can find it at https://storyboard.openstack.org/#!/board/54. I've added a couple hours of searching and brain racking worth of items to the board but I am sure it is incomplete. Feel free to add stuff that you notice is missing. For the "help wanted" lane tag stories with 'openstack-infra-help-wanted' and for the "in progress" lane tag stories with 'openstack-infra-inprogress'. My hope is that we can make this useful enough that the infra-specs help wanted list can just link to this board in the future. Let me know what you think. This is largely an experiment and I don't intend on being the only user of this tool/information. Clark ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
