Re: [OpenStack-Infra] Can we use short domain names for build log servers?

Sorin Sbarnea writes: > I would like to re-raise an older question: what can we do to avoid > using human-unfriendly URLs for our build logs? When was this question previously asked? > The current setup lead us to some URLs that seems more like a way to > test client limitations. What

Re: [OpenStack-Infra] OpenDev infra as an OSF pilot project

"Clark Boylan" writes: > On Sun, Mar 1, 2020, at 11:20 AM, Jonathan Bryce wrote: >> Hi everyone, >> >> I saw some of the discussions on different channels last week about the >> ongoing move of the OpenDev infra services out of OpenStack project and >> TC governance. One of the questions that

Re: [OpenStack-Infra] tarballs.openstack.org to AFS publishing gameplan

Ian Wienand writes: > On Wed, Jan 29, 2020 at 05:21:49AM +, Jeremy Stanley wrote: >> Of course I meant from /(.*) to tarballs.opendev.org/openstack/$1 so >> that clients actually get directed to the correct files. ;) > > Ahh yes, sorry you mentioned that in IRC and I should have >

Re: [OpenStack-Infra] proposal: custom favicon for review.o.o

Ian Wienand writes: > On Wed, Jan 29, 2020 at 06:35:28AM +, Sorin Sbarnea wrote: >> I guess that means that you are not against the idea. > > I know it's probably not what you want to hear, but as it seems > favicons are becoming a component of branding like a logo I think > you'd do well to

Re: [OpenStack-Infra] Checking release approvals automatically

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

Re: [OpenStack-Infra] Checking release approvals automatically

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

Re: [OpenStack-Infra] Report from Gerrit User Summit

"Clark Boylan" writes: > How does triggering work with the checks api? I seem to recall reading > the original design spec for the feature and that CI systems would > Poll Gerrit for changes that apply to their checks giving them a list > of items to run? Then as a future improvement there was

[OpenStack-Infra] Report from Gerrit User Summit

Hi, Monty and I attended the Gerrit User Summit and hackathon last week. It was very productive: we learned some good information about upgrading Gerrit, received offers of help doing so if we need it, formed closer ties with the Gerrit community, and fielded a lot of interest in Reno and Zuul.

[OpenStack-Infra] [all][infra] Zuul logs are in swift

Hi, We have made the switch to begin storing all of the build logs from Zuul in Swift. Each build's logs will be stored in one of 7 randomly chosen Swift regions in Fort Nebula, OVH, Rackspace, and Vexxhost. Thanks to those providers! You'll note that the links in Gerrit to the Zuul jobs now

[OpenStack-Infra] [release][infra] Supporting rget in our release process

Hi, A colleague at Red Hat is working on an effort to record signatures of release artifacts. Essentially it's a way to help users verify release artifacts (or determine if they have been changed) independent of PGP signatures. You can read about it here:

Re: [OpenStack-Infra] Zanata broken on Bionic

Frank Kloeker writes: > Just as a follow up: I've wrote down all required steps and ideas for > a migration to Weblate on [1]. Thanks for that! Will this be a topic at the PTG? > There are some issues adressed but thats not unsolvable (i.e. invent > openstackid as a OpenId provider). We may

[OpenStack-Infra] Announcing Gertty 1.6.0

Announcing Gertty 1.6.0 === Gertty is a console-based interface to the Gerrit Code Review system. Gertty is designed to support a workflow similar to reading network news or mail. It syncs information from Gerrit to local storage to support disconnected operation and easy

Re: [OpenStack-Infra] OpenDev git hosting migration and Gerrit downtime April 19, 2019

Thierry Carrez writes: > Clark Boylan wrote: >> Fungi has generated a master list of project renames for the >> openstack namespaces: http://paste.openstack.org/show/749402/. If >> you have a moment please quickly review these planned renames for >> any obvious errors or issues. > > One thing

[OpenStack-Infra] Gitea next steps

Hi, At the last infra team meeting, we talked about whether and how to proceed with Gitea. I'd like to summarize that quickly and make sure we're all on board with it. * We will continue to deploy our own Kubernetes using the k8s-for-openstack Ansible playbook that Monty found. Since that's

Re: [OpenStack-Infra] Kubernetes walkthrough (for OpenDev gitea)

cor...@inaugust.com (James E. Blair) writes: > Hi, > > As part of the OpenDev Gerrit Hosting spec [1], we're planning on > running gitea as our primary git mirror. Monty and I have been working > on a system to run it in a fully HA manner using Kubernetes, cephfs, and > per

[OpenStack-Infra] Kubernetes walkthrough (for OpenDev gitea)

Hi, As part of the OpenDev Gerrit Hosting spec [1], we're planning on running gitea as our primary git mirror. Monty and I have been working on a system to run it in a fully HA manner using Kubernetes, cephfs, and percona. The changes to implement this are in review[2]. But there's a lot of

Re: [OpenStack-Infra] Launch node and the new bridge server

Ian Wienand writes: > On 08/28/2018 09:48 AM, Clark Boylan wrote: >> On Mon, Aug 27, 2018, at 4:21 PM, Clark Boylan wrote: >> One quick new observation. launch-node.py does not install puppet at >> all so the subsequent ansible runs on the newly launched instances >> will fail when attempting to

Re: [OpenStack-Infra] Moving logs into swift (redux)

Joshua Hesketh writes: > I know the CDN was complicated with the cloud provider we were using at the > time. However, I'm unsure what the CDN options are these days. Will there > be an API we can use to turn the CDN on per container and get the public > URL for example? A typical swift has the

Re: [OpenStack-Infra] Moving logs into swift (redux)

Doug Hellmann writes: > Excerpts from corvus's message of 2018-07-16 15:27:10 -0700: > >> The Zuul dashboard makes finding the location of logs for jobs >> (especially post jobs) simpler. So we no longer need logs.o.o to find >> the storage location (files or swift) for post jobs -- a user can

Re: [OpenStack-Infra] Moving logs into swift (redux)

Clark Boylan writes: > Couple of thoughts about this and Ara specifically. Ara static > generation easily produces tens of thousands of files. Copying many > small files to the log server with rsync was often quite slow (on the > order of 10 minutes for some jobs (that is my fuzzy memory

Re: [OpenStack-Infra] Moving logs into swift (redux)

cor...@inaugust.com (James E. Blair) writes: > To summarize: static generation combined with a new role to upload to > swift using openstacksdk should allow us to migrate to swift fairly > quickly. Once there, we can work on a number of enhancements which I > will describe in a f

Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

We could consider hosting a config-project with pipeline definitions for third-party CI as an optional service folks could use. It would not, however, be able to support customized reporting messages or recheck syntax. -Jim ___ OpenStack-Infra mailing

Re: [OpenStack-Infra] zuulv3 feedback for 3pci

Paul Belanger writes: > Greetings, > > Over the last few weeks I've been helping the RDO project migrate away from > zuulv2 (jenkins) to zuulv3. Today all jobs have been migrated with the help of > the zuul-migrate script. We'll start deleting jenkins bits in the next few > days. > > I wanted

Re: [OpenStack-Infra] What's the future for git-review?

Jeremy already articulated my thoughts well; I don't have much to add. But I think it's important to reiterate that I find it extremely valuable that git-review perform its function ("push changes to Gerrit") simply and reliably. There are certainly projects we've created which are neglected due

[OpenStack-Infra] [infra] Behavior change in Zuul post pipeline

Hi, We recently changed the behavior* of the post pipeline in Zuul to only run jobs for the most recently merged changes on each project's branches. If you were relying on the old behavior where jobs ran on every merged change, let us know, we can make a new pipeline for that. But for the

[OpenStack-Infra] [infra][all] Upcoming Zuul behavior change for files and irrelevant-files

Hi, Earlier[1][2], we discussed proposals to make files and irrelevant-files easier to use -- particularly ways to make them overridable. We settled on an approach, and it is now implemented. We plan on upgrading OpenStack's Zuul to the new behavior on Monday, June 11, 2018. To summarize the

Re: [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

Doug Hellmann writes: >> * Move many of the git repos currently under the OpenStack project >> infrastructure team's governance to this new team. > > I'm curious about the "many" in that sentence. Which do you anticipate > not moving, and if this new team replaces the existing team then who >

[OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

Hi, With recent changes implemented by the OpenStack Foundation to include projects other than "OpenStack" under its umbrella, it has become clear that the "Project Infrastructure Team" needs to change. The infrastructure that is run for the OpenStack project is valued by other OpenStack

Re: [OpenStack-Infra] Options for logstash of ansible tasks

Ian Wienand writes: > The closest other thing I could find was "aggregate" [1]; but this > relies on having a unique task-id to group things together with. > Ansible doesn't give us this in the logs and AFAIK doesn't have a > concept of a uuid for tasks. We control the log

Re: [OpenStack-Infra] Public numbers about the scale of the infrastructure/CI ?

David Moreau Simard <dmsim...@redhat.com> writes: > On Mon, Mar 26, 2018 at 10:20 AM, James E. Blair <cor...@inaugust.com> wrote: >>> - # of jobs and Ansible playbooks per month ran by Zuul >> >> I'm curious about this one -- how were you planning on definin

Re: [OpenStack-Infra] Public numbers about the scale of the infrastructure/CI ?

David Moreau Simard writes: > Unless there's any objection, I'd have a slide with up to date numbers such > as: I don't have any objection to making them public (I believe nearly all, if not all, of these are public already). But I would like them to be as accurate as

[OpenStack-Infra] Zuul project evolution

Hi, To date, Zuul has (perhaps rightly) often been seen as an OpenStack-specific tool. That's only natural since we created it explicitly to solve problems we were having in scaling the testing of OpenStack. Nevertheless, it is useful far beyond OpenStack, and even before v3, it has found

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

Paul Belanger writes: > On Mon, Feb 19, 2018 at 08:28:27AM -0500, David Shrewsbury wrote: >> Hi, >> >> On Sun, Feb 18, 2018 at 10:25 PM, Ian Wienand wrote: >> >> > Hi, >> > >> > How should we go about restricting certain image builds to specific >>

[OpenStack-Infra] [infra][all] New Zuul Depends-On syntax

Hi, We recently introduced a new URL-based syntax for Depends-On: footers in commit messages: Depends-On: https://review.openstack.org/535851 The old syntax will continue to work for a while, but please begin using the new syntax on new changes. Why are we changing this? Zuul has grown the

[OpenStack-Infra] Merging feature/zuulv3 into master

Hi, On Thursday, January 18, 2018, we will merge the feature/zuulv3 branches of both Zuul and Nodepool into master. If you continuously deploy Zuul or Nodepool from master, you should make sure you are prepared for this. The current version of the single_node_ci pattern in puppet-openstackci

Re: [OpenStack-Infra] RFC: Zuul executor congestion control

writes: > Hi zuulers, > > the zuul-executor resource governor topic seems to be a recurring now > and we might want take the step and make it a bit smarter. To be honest, it keeps coming up because we haven't gotten around to finishing the work already in progress on this.

[OpenStack-Infra] New Zuul mailing lists

Hi, We've created two new mailing lists for Zuul. If you run an instance of Zuul, or are a user of Zuul, you should subscribe. The new lists are: zuul-annou...@lists.zuul-ci.org --- http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-announce This will be a

Re: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and Nodepool repos

Clark Boylan writes: > Hello, > > I think we are very close to being ready to merge the zuulv3 feature > branch into master in both the Zuul and Nodepool repos. In particular > we merged https://review.openstack.org/#/c/523951/ which should > prevent breakages for anyone

Re: [OpenStack-Infra] Hostnames

Clark Boylan writes: > On Sun, Jan 7, 2018, at 2:30 PM, David Moreau Simard wrote: >> When I compared ze10 with ze09 today, I noticed that ze09's "hostname" >> command returned "ze09" while ze10 had "ze10.openstack.org". >> >> However, both nodes had the full fqdn when

[OpenStack-Infra] Zuul mailing lists

Hi, We recently completed the work needed to host mailing lists for projects at their own domains. With our expanded focus in Zuul v3 on users beyond those related to the OpenStack project, now seems like a good time to create dedicated Zuul mailing lists. I'd like to create the following two

[OpenStack-Infra] Hostnames

Hi, It seems that every time we boot a new server, it either randomly has a hostname of foo, or foo.openstack.org. And maybe that changes between the first boot and second. The result of this is that our services which require that they know their hostname (which is a lot, especially the

[OpenStack-Infra] Test message

Hi, This is a test message following some maintenance to the mailing list server. There is no need to reply. Thanks, Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org

Re: [OpenStack-Infra] Xenial Upgrade Sprint Recap

Ian Wienand writes: > There's a bunch of stuff that wouldn't show up until live, but we > probably could have got a lot of prep work out of the way if the > integration tests were doing something. I didn't realise that although > we run the tests, most of our modules don't

Re: [OpenStack-Infra] Xenial Upgrade Sprint Recap

Clark Boylan writes: > Hello everyone, > > Just wanted to quickly recap what we got done this week during our > control plane upgrade to Xenial sprint. Thanks! Now that this is over, I wonder if we should start a 'marathon' (as opposed to a sprint) to finish the rest of

Re: [OpenStack-Infra] Nodepool drivers

Tristan Cacqueray writes: >>> I also proposed a 'plugin' interface so that driver are fully contained >>> in their namespace, which seems like another legitimate addition to this >>> feature: >>> https://review.openstack.org/524620 >> >> I think that will be a nice thing to

Re: [OpenStack-Infra] plan for Zuul and Nodepool to support Python3.x ?

"Apua A.Aa" writes: > Hi, > > As title, is there a plan or road map for Zuul and Nodepool to > support/migrate to Python3.x currently? Yes, the next versions, Zuul and Nodepool v3.0, will support python 3 only. Note that they will be very different from the current

Re: [OpenStack-Infra] Nodepool drivers

Tristan Cacqueray writes: > Hi, > > Top posting here to raise another complication. > James mentioned an API problem regarding the NodeRequestHandler > interface. Indeed the run_handler method should actually be part of the > generic code so that the driver's handler only

Re: [OpenStack-Infra] Zuul roadmap

Clint Byrum writes: > I know a bunch of this stuff is janky as all get out, because as much of the > jankiness is my own fault as anybody else's. But so much work has gone into > zuulv3 beyond what OpenStack needs, I am still not convinced we need to wait > for any of this.

Re: [OpenStack-Infra] Zuul roadmap

Fabien Boucher writes: >> * finish git driver >> > > If ok for you, I want to propose myself to work on that git driver topic. > I'll try to > provide a first patch asap. That's great, thanks! There's some code there already, but it has no tests and hasn't been used in a

Re: [OpenStack-Infra] Nodepool drivers

Tristan Cacqueray writes: > Hi, > > Now that the zuulv3 release is approaching, please find below a > follow-up on this spec. > > The current code could use one more patch[0] to untangle the common > config from the openstack provider specific bits. The patch often needs >

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

[OpenStack-Infra] Merging Zuul v3 into master

Hi, A while back we created a feature branch in git for Zuul and Nodepool v3 (feature/zuulv3). Now that OpenStack-Infra is running it, and all of our development focus is on it, we are unlikely to merge any more changes to Zuul v2 or issue another Zuul v2 release. In fact, we are approaching

[OpenStack-Infra] Zuul roadmap

Hi, At the PTG we brainstormed a road map for Zuul once we completed the infra cutover. I think we're in a position now that we can get back to thinking about this, so I've (slightly) cleaned it up and organized it here. I've grouped into a number of sections. First: Very Near Term

Re: [OpenStack-Infra] Zuul v3 questions

Rikimaru Honjo writes: > I confirmed the below PPA, but my version is the latest. > > https://launchpad.net/~ansible/+archive/ubuntu/bubblewrap > > Should I use ubuntu higher than 16.04...? We are running on 16.04. But it looks like this is the PPA we're using:

Re: [OpenStack-Infra] Some branch issues with Zuul

cor...@inaugust.com (James E. Blair) writes: ... > The Changes > === > > I believe the following changes will address all five problems and > achieve both design goals: > > a) Apply inheritance at the same time as variance > > Rather than applying inheritance a

[OpenStack-Infra] Zuul v3 questions (was: Re: [openstack-dev] Update on Zuul v3 Migration - and what to do about issues)

Rikimaru Honjo writes: > Hello, > > (Can I still use this thread?) In the future, you may want to start a new thread on openstack-infra@lists.openstack.org for general Zuul questions. I've changed the CC list and subject of this message to redirect the

Re: [OpenStack-Infra] Some branch issues with Zuul

Doug Hellmann writes: > In the discussion yesterday, and in the emails today, you've implied > that there is an ordering to job definitions beyond inheritance. Is that > discovery order documented somewhere? If not, is it simple enough to > describe in a few sentences

Re: [OpenStack-Infra] Some branch issues with Zuul

Andrea Frittoli writes: > We will need somewhere in the logs a description of the traversal that was > done to build the final job. I believe that would help debugging issues that > may arise from unexpected inheritance behaviour. > > Andrea Frittoli (andreaf) Yes!

[OpenStack-Infra] Ignoring pep8 E741

Hi, I discussed this briefly with some folks in IRC and received support, but I thought it wise to bring to the mailing list. I think we should add E741 to the list of pep8 errors that we ignore as a matter of course in infra projects. This is a recently added change which forbids the use of

[OpenStack-Infra] Some guidance on job variants

At the infra meeting today, we discussed how to handle job variants. I will try to summarize the discussion and extrapolate some things. The Zuul v3 migration doc in the infra manual is very clear that some project-templates should only be added in project-config, rather than in-repo[1].

[OpenStack-Infra] Some branch issues with Zuul

Hi, A number of issues related to how jobs are defined and run on projects with stable branches have come up recently. I believe they are all related, and they, as well as the solutions to them, must be considered together. The Problems I've identified the following five

[OpenStack-Infra] Zuul v3 tag checkouts

Hi, It turns out that there are some jobs in OpenStack's Zuul that were relying on a behavior in devstack-gate and zuul-cloner that would check out a tag when given an override branch. Zuul v3 is a bit more literal -- the 'override-branch' option (for both jobs and projects) will only checkout a

Re: [OpenStack-Infra] Nominating new project-config and zuul job cores

Clark Boylan writes: > Hello everyone, > > I'd like to nominate a few people to be core on our job related config > repos. Dmsimard, mnaser, and jlk have been doing some great reviews > particularly around the Zuul v3 transition. In recognition of this work > I propose that

Re: [OpenStack-Infra] Upcoming backwards incompatible change on Zuul master

cor...@inaugust.com (James E. Blair) writes: > Hi, > > We need to merge a backwards incompatible change to Zuul master. > > The change is: https://review.openstack.org/482856 and it makes Gerrit > label entries case sensitive. Unfortunately, some combinations of > Gerrit ve

Re: [OpenStack-Infra] Zuul feature/zuulv3 branch to be rewound

Darragh Bailey writes: >> The abandon/restore steps are required by Gerrit in order to delete the >> branch. We could force-push the branch tip, but this is the procedure >> we have asked and would ask any other project to use in a similar >> situation, in order to

[OpenStack-Infra] Zuul feature/zuulv3 branch to be rewound

Hi, A change recently landed on the feature/zuulv3 branch of Zuul with a Sem-Ver commit message footer. This is used by PBR to alter the way it constructs version numbers. It's pretty nifty, but in my opinion, it has a fundamental flaw: it can't be undone. I think use of this by a project

[OpenStack-Infra] Moving docs-draft to logs.o.o

Hi, We originally created the docs-draft site (and filesystem partition) because doc builds were *big* and we had to expire them much more quickly than build logs. The expiration times were 21 days for docs-draft and 6 months for build logs. The tables have turned. Docs-draft expiration is

Re: [OpenStack-Infra] [zuul] v3 UI enquiry

Darragh Bailey <daragh.bai...@gmail.com> writes: > On 6 September 2017 at 01:26, James E. Blair <cor...@inaugust.com> wrote: > >> Darragh Bailey <daragh.bai...@gmail.com> writes: >> >> > Hi, >> > >> > Currently the main issue fr

[OpenStack-Infra] Upcoming backwards incompatible change on Zuul master

Hi, We need to merge a backwards incompatible change to Zuul master. The change is: https://review.openstack.org/482856 and it makes Gerrit label entries case sensitive. Unfortunately, some combinations of Gerrit versions and underlying database configurations make this both necessary and

Re: [OpenStack-Infra] [zuul] v3 UI enquiry

Darragh Bailey writes: > Hi, > > Currently the main issue from end users, is the user experience around the > UI when looking at job results once the run is complete, and to a lesser > extend looking at your jobs in the zuul status page when running. > > I'm wondering if

Re: [OpenStack-Infra] Plan for devstack Zuul v3 jobs

David Moreau Simard writes: > I'm OK with this. > Should we get to a point where the scripts can be used by both Zuul v2 > and Zuul v3 simultaneously so that there is no "migration" or "cutover" so > to speak ? > > It might mean some amount of work but it shouldn't be too bad, I

[OpenStack-Infra] Plan for devstack Zuul v3 jobs

Hi, As many of you may recall, our plan to migrate the devstack jobs to Zuul v3 was to gradually convert pieces of the existing devstack-gate script to Ansible roles which would be shared between the Ansible run inside the devstack-gate script and the Ansible run by Zuul v3. Eventually, the idea

[OpenStack-Infra] Zuul v3: some layout checks disabled in project-config

Hi, With https://review.openstack.org/492697 we are moving gating of Zuul itself and some related job repos from Zuul v2 to Zuul v3. As part of this, we need to disable some of the checks that we perform on the layout file. That change disables the following checks for the openstack-infra/*

Re: [OpenStack-Infra] Blogging Question

Jeremy Stanley writes: > On 2017-08-03 20:34:14 + (+), Morgenstern, Chad wrote: >> I'm wondering, now that the ini is corrected (I hope), will our older >> posts show up or will only the blogs we post after the change is >> picked up show up on your site? > > The cache

[OpenStack-Infra] Announcing Gertty 1.5.0

Announcing Gertty 1.5.0 === Gertty is a console-based interface to the Gerrit Code Review system. Gertty is designed to support a workflow similar to reading network news or mail. It syncs information from Gerrit to local storage to support disconnected operation and easy

Re: [OpenStack-Infra] On the subject of HTTP interfaces and Zuul

Monty Taylor writes: > With that in mind, I believe the path should be for the new server > being written for the console-log streaming to be called "zuul-web" > and that it should serve the console-log websocket at /console-stream > or /console-log or something. > > We can

[OpenStack-Infra] [infra] Status of Zuul v3

Greetings! This periodic update is primarily intended as a way to keep contributors to the OpenStack community apprised of Zuul v3 project status, including future changes and milestones on our way to use in production. Additionally, the numerous existing and future users of Zuul outside of the

Re: [OpenStack-Infra] Nodepool drivers

Tristan Cacqueray writes: > Hi, > > With the nodepool-drivers[0] spec approved, I started to hack a quick > implementation[1]. Well I am not very familiar with the nodepool/zookeeper > architecture, thus this implementation may very well be missing important > bits... The

Re: [OpenStack-Infra] On the subject of HTTP interfaces and Zuul

Clint Byrum writes: > Excerpts from corvus's message of 2017-06-09 13:11:00 -0700: >> Clark Boylan writes: >> >> > I'm wary of this simply because it looks a lot like repeating >> > OpenStack's (now failed) decision to stick web servers in a bunch of >>

Re: [OpenStack-Infra] About aarch64 third party CI

Ricardo Carrillo Cruz writes: > This is a nodepool.yaml that can help you get going: > > http://paste.openstack.org/show/612191/ Glad it worked! You can drop 'zmq-publishers' from the config entirely. If 'images-dir' and 'diskimages' are required, then I would

Re: [OpenStack-Infra] On the subject of HTTP interfaces and Zuul

Clark Boylan writes: > I'm wary of this simply because it looks a lot like repeating > OpenStack's (now failed) decision to stick web servers in a bunch of > python processes then do cooperative multithreading with them along with > all your application logic. It just gets

Re: [OpenStack-Infra] On the subject of HTTP interfaces and Zuul

Clint Byrum writes: > Your words are more succinct than what I wrote, which is nice. I think > we agree on the general direction for the time being. > > However, I don't think ZK will be a good choice for async event > handling. I'd sooner expect MQTT to replace gear for that.

Re: [OpenStack-Infra] On the subject of HTTP interfaces and Zuul

Monty Taylor writes: > We should use aiohttp with no extra REST framework. > > Meaning: > > - aiohttp serving REST and websocket streaming in a scale-out tier > - talking RPC to the scheduler over gear or zk > - possible in-process aiohttp endpoints for k8s style health

Re: [OpenStack-Infra] Zuul V3: Behavior of change related requirements on push like events

Jeremy Stanley writes: > On 2017-05-30 12:53:15 -0700 (-0700), Jesse Keating wrote: > [...] >> Github labels: This is like approvals/reviews. > [...] > > Perhaps an interesting aside, Gerrit uses the same term (labels) for > how we're doing approvals and review voting. Yeah,

[OpenStack-Infra] Canceling Zuul meeting 2017-05-29

Hi, Due to the US holiday on Monday, the Zuul meeting on May 29, 2017 is canceled. Thanks, Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

Joshua Hesketh <joshua.hesk...@gmail.com> writes: > On Fri, May 26, 2017 at 1:09 AM, James E. Blair <cor...@inaugust.com> wrote: >> So I think that we should start out by simply silently ignoring any >> patchset elements in the URL. We could consider having Zuul

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

Jeremy Stanley writes: > On 2017-05-25 08:50:14 -0500 (-0500), Kevin L. Mitchell wrote: >> Can I suggest that, for OpenStack purposes, we also deploy some sort of >> bot that comments on reviews using the old syntax, to at least alert >> developers to the pending deprecation?

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

Sean Dague <s...@dague.net> writes: > On 05/24/2017 07:04 PM, James E. Blair wrote: > >> The natural way to identify a GitHub pull request is with its URL. >> >> This can be used to identify Gerrit changes as well, and will likely be >> well supported by oth

[OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

Hi, As part of Zuul v3, we're adding support for GitHub (and later possibly other systems). We want these systems to have access to the full power of cross-project-dependencies in the same way as Gerrit. However, the current syntax for the Depends-On footer is currently the Gerrit-specific

[OpenStack-Infra] Canceling 2017-05-15 Zuul meeting

Hi, I think enough of us have post-summit plans/chores/burnout that it makes sense to cancel the May 15, 2017 Zuul meeting. See you on May 22. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org

Re: [OpenStack-Infra] Ask.o.o Email not getting through?

Tom Fifield writes: > Hello infra, > > Exploratory question here, no idea what's actually going on. > > We have a prospective new user on Ask OpenStack, who despite trying > multiple auth methods (Launchpad & Google) multiple times did not > receive a confirmation email. > >

[OpenStack-Infra] Skipping 2017-04-10 Zuul meeting

Hi, We're going to have several absences next Monday, the 10th, so let's skip the Zuul meeting that day. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Test message

Hi, This is a test message to verify mailing list functionality after the upgrade. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [infra][security] Encryption in Zuul v3

Darragh Bailey <daragh.bai...@gmail.com> writes: > On 22 March 2017 at 15:02, James E. Blair <cor...@inaugust.com> wrote: > >> Ian Cordasco <sigmaviru...@gmail.com> writes: >> >> > >> > I suppose Barbican doesn't meet those requirements eith

Re: [OpenStack-Infra] [openstack-dev] [infra][security] Encryption in Zuul v3

Ian Cordasco <sigmaviru...@gmail.com> writes: > On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair <cor...@inaugust.com> wrote: >> We did talk about some other options, though unfortunately it doesn't >> look like a lot of that made it into the spec reviews. Among t

Re: [OpenStack-Infra] [openstack-dev] [infra][security] Encryption in Zuul v3

David Moreau Simard writes: > I don't have a horse in this race or a strong opinion on the topic, in > fact I'm admittedly not very knowledgeable when it comes to low-level > encryption things. > > However, I did have a question, even if just to generate discussion. > Did we

[OpenStack-Infra] [infra][security] Encryption in Zuul v3

Hi, In working on the implementation of the encrypted secrets feature of Zuul v3, I have found some things that warrant further discussion. It's important to be deliberate about this and I welcome any feedback. For reference, here is the relevant portion of the Zuul v3 spec:

Re: [OpenStack-Infra] [zuul] Feedback requested for tox job definition

Clark Boylan writes: > Also reading these job defs and comparing against the zuulv3 spec it > isn't clear to me what the expected behavior for inheriting pre and post > playbooks is. Seems like maybe pre is a queue so parent pre roles run > first and post is a stack so

Re: [OpenStack-Infra] Adding projects to zuulv3-dev.o.o

Paul Belanger writes: > Greetings! > > I wanted to start a thread about what people thought about expanding our > coverage of projects a little. I've been working on ansible roles for CI > things > for a while, and figure it might be a good first step to have zuulv3 test

[OpenStack-Infra] Multi-connection support in Zuul

Hi, For a while, Zuul has had support for connections to multiple services for use in triggering jobs, fetching changes, and reporting results. This has been in use (the github patches work with github, we do support reporting to gerrit as two different users, we send email over SMTP), but we

  1   2   3   >