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-dev] [all] Ongoing spam in Freenode IRC channels

Monty Taylor writes: > On 08/01/2018 12:45 AM, Ian Wienand wrote: >> Hello, >> I'd suggest to start, people with an interest in a channel can request >> +r from an IRC admin in #openstack-infra and we track it at [2] > > To mitigate the pain caused by +r - we have created a channel called >

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-dev] [python3][tc][infra][docs] changing the documentation build PTI to use tox

Doug Hellmann writes: > Excerpts from Zane Bitter's message of 2018-07-09 11:04:28 -0400: >> On 05/07/18 16:46, Doug Hellmann wrote: >> > I have a governance patch up [1] to change the project-testing-interface >> > (PTI) for building documentation to restore the use of tox. >> > >> > We

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-dev] [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

Re: [openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Doug Hellmann writes: > Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900: >> Yes, It will not be set on LIBS_FROM_GIT as we did not set it >> explicitly. But gate running on any repo does run job on current >> change set of that repo which is nothing but "master + current patch >>

[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

[openstack-dev] [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-dev] Winterscale: a proposal regarding the project infrastructure

Joshua Hesketh writes: > So the "winterscale infrastructure council"'s purview is quite limited in > scope to just govern the services provided? > > If so, would you foresee a need to maintain some kind of "Infrastructure > council" as it exists at the moment to be the technical design body?

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

Doug Hellmann writes: >> >> * Establish a "winterscale infrastructure council" (to be renamed) which >> >> will govern the services that the team provides by vote. The council >> >> will consist of the PTL of the winterscale infrastructure team and one >> >> member from each official

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 >

Re: [openstack-dev] [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

[openstack-dev] 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-dev] [Zun] Relocate jobs from openstack/zun to openstack/zun-tempest-plugin

Hongbin Lu writes: > The goal of those patches is to move the job definitions and playbooks from > openstack/zun to openstack/zun-tempest-plugin. The advantages of such > change are as following: > > * Make job definitions closer to tempest test cases so that it is optimal

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

Jeremy Stanley <fu...@yuggoth.org> writes: > On 2018-05-15 09:40:28 -0700 (-0700), James E. Blair wrote: > [...] >> We're also talking about making a new kind of job which can continue to >> run after it's "finished" so that you could use it to do something

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

Bogdan Dobrelya writes: > * check out testing depends-on things, (Zuul should have done this for you, but yes.) > * build repos and all tripleo docker images from these repos, > * upload into a swift container, with an automatic expiration set, the > de-duplicated and

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

Bogdan Dobrelya writes: > Added a few more patches [0], [1] by the discussion results. PTAL folks. > Wrt remaining in the topic, I'd propose to give it a try and revert > it, if it proved to be worse than better. > Thank you for feedback! > > The next step could be reusing

Re: [openstack-dev] Overriding project-templates in Zuul

Joshua Hesketh writes: >> >> I think in actuality, both operations would end up as intersections: >> >> === === >> Matcher Template Project Result >> === === >> files AB

Re: [openstack-dev] Overriding project-templates in Zuul

cor...@inaugust.com (James E. Blair) writes: > So a job with "files: tests/" and "irrelevant-files: docs/" would > never run because it's impossible to satisfy both. Jeremy pointed out in IRC that that's not what would happen. So... let me rephrase that: >

Re: [openstack-dev] Overriding project-templates in Zuul

Joshua Hesketh writes: > I might be misunderstanding at which point a job is chosen to be ran and > therefore when it's too late to dissuade it. However, if possible, would it > make more sense for the project-local copy of a job to overwrite the > supplied files and

[openstack-dev] Overriding project-templates in Zuul

Hi, If you've had difficulty overriding jobs in project-templates, please read and provide feedback on this proposed change. We tried to make the Zuul v3 configuration language as intuitive as possible, and incorporated a lot that we learned from our years running Zuul v2. One thing that we

[openstack-dev] Zuul memory improvements

Hi, We recently made some changes to Zuul which you may want to know about if you interact with a large number of projects. Previously, each change to Zuul which updated Zuul's configuration (e.g., a change to a project's zuul.yaml file) would consume a significant amount of memory. If we had

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

Clark Boylan writes: ... > I've since worked out a change that passes tempest using a global > virtualenv installed devstack at > https://review.openstack.org/#/c/558930/. This needs to be cleaned up > so that we only check for and install the virtualenv(s) once and we >

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

Andrea Frittoli writes: > Dear all, > > a quick update on the current status. > > Zuul has been fixed to use the correct branch for roles coming from > different repositories [1]. > The backport of the devstack patches to support multinode jobs is almost > complete.

[openstack-dev] [all] Changes to Zuul role checkouts

Hi, We recently fixed a subtle but important bug related to how Zuul checks out repositories it uses to find Ansible roles for jobs. This may result in a behavior change, or even an error, for jobs which use roles defined in projects with multiple branches. Previously, Zuul would (with some

Re: [openstack-dev] [devstack][qa] Changes to devstack LIBS_FROM_GIT

Sean McGinnis writes: > On Wed, Mar 28, 2018 at 07:37:19PM -0400, Doug Hellmann wrote: >> Excerpts from corvus's message of 2018-03-28 13:21:38 -0700: >> > Hi, >> > >> > I've proposed a change to devstack which slightly alters the >> > LIBS_FROM_GIT behavior. This

[openstack-dev] [devstack][qa] Changes to devstack LIBS_FROM_GIT

Hi, I've proposed a change to devstack which slightly alters the LIBS_FROM_GIT behavior. This shouldn't be a significant change for those using legacy devstack jobs (but you may want to be aware of it). It is more significant for new-style devstack jobs. The change is at

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

[openstack-dev] 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

[openstack-dev] Zuul flaw in json logging

Hi, If your project is using secrets in Zuul v3, please see the attached message to determine whether they may have been disclosed. OpenStack's Zuul is now running with the referenced fix in place, and we have verified that the secrets used in the project-config repo (eg, to upload logs and

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

Bogdan Dobrelya writes: > Hello. > As Zuul documentation [0] explains, the names "check", "gate", and > "post" may be altered for more advanced pipelines. Is it doable to > introduce, for particular openstack projects, multiple check > stages/steps as check-1, check-2 and

[openstack-dev] [all][infra] Some new Zuul features

Hi, We've rolled out a few new Zuul features you may find useful. Added a post-timeout job attribute == We refined the way timeouts are handled. The "timeout" attribute of a job (which defaults to 30 minutes but can be changed by any job) now covers the time

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 >>

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

Andrea Frittoli writes: > Dear all, > > this is the first or a series of ~regular updates on the migration of > Tempest / Grenade jobs to Zuul v3 native. > > The QA team together with the infra team are working on providing the > OpenStack community with a set of base

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

Andrea Frittoli writes: >> That has no irrelevant-files matches, and so matches everything. If you >> drop the use of that template, it will work as expected. Or, if you can >> say with some certainty that nova's irrelevant-files set is not >> over-broad, you could

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

cor...@inaugust.com (James E. Blair) writes: > The reason is that, contrary to earlier replies in this thread, the > /#/c/ version of the change URL does not work. The /#/c/ form of Gerrit URLs should work now; if it doesn't, please let me know. I would still recommend (and personall

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

Zane Bitter writes: > Yeah, it's definitely nice to have that flexibility. e.g. here is a > patch that wouldn't merge for 3 months because the thing it was > dependent on also got proposed as a backport: > > https://review.openstack.org/#/c/514761/1 > > From an OpenStack

[openstack-dev] [all][infra] Automatically generated Zuul changes (topic: zuulv3-projects)

Hi, Occasionally we will make changes to the Zuul configuration language. Usually these changes will be backwards compatible, but whether they are or not, we still want to move things forward. Because Zuul's configuration is now spread across many repositories, it may take many changes to do

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

Eric Fried writes: > For my part, I tried it [1] and it doesn't seem to have worked. (The > functional test failure is what the dep is supposed to have fixed.) Did > I do something wrong? > > [1] https://review.openstack.org/#/c/533821/12 If you examine the "items:"

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

Balázs Gibizer writes: > Hi, > > I'm getting more and more confused how the zuul job hierarchy works or > is supposed to work. Hi! First, you (or others) may or may not have seen this already -- some of it didn't exist when we first rolled out v3, and some of it

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

Mathieu Gagné <mga...@calavera.ca> writes: > On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair <cor...@inaugust.com> wrote: >> Mathieu Gagné <mga...@calavera.ca> writes: >> >>> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec <openst...@nemebean.com> w

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

Mathieu Gagné writes: > On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: >> >> >> I'm curious what this means as far as best practices for inter-patch >> references. In the past my understanding was the the change id was >> preferred, both because

[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-dev] [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

[openstack-dev] 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-dev] [tripleo] storyboard evaluation

Emmet Hikory writes: > Emilien Macchi wrote: > >> What we need to investigate: >> - how do we deal milestones in stories and also how can we have a >> dashboard with an overview per milestone (useful for PTL + TripleO >> release managers). > >     While the storyboard API

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

[openstack-dev] Zuul dashboard available

Hi, I'd like to draw your attention to a recently added feature in Zuul. If you visit http://zuulv3.openstack.org/ you will note three tabs at the top of the screen (you may need to shift-reload the page): Status, Jobs, Builds. The "Jobs" page shows you a list of all of the jobs in the system,

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-dev] [tc] [all] TC Report 49

Chris Dent writes: > The expansion of the Foundation was talked about at the summit in > Sydney, but having something happen this quickly was a bit of a > surprise, leading to some [questions in >

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

Re: [openstack-dev] [devstack][zuul] About devstack plugin orders and the log to contain the running local.conf

cor...@inaugust.com (James E. Blair) writes: > "gong_ys2004" <gong_ys2...@aliyun.com> writes: > >> Hi, everyone >> I am trying to migrate tacker's functional CI job into new zuul v3 >> framework, but it seems: >> 1. the devstack plugin order is not t

Re: [openstack-dev] [all] Changes to releasenotes and docs build jobs

Monty Taylor writes: > * We use -W only if setup.cfg sets it > > * Installs dependencies via bindep for doc environment. Binary deps, > such as graphviz, should be listed in bindep and marked with a 'doc' > tag. > > * doc/requirements.txt is used for installation of python

Re: [openstack-dev] Removing internet access from unit test gates

Jeremy Stanley writes: > On 2017-11-21 17:46:14 +0100 (+0100), Thomas Goirand wrote: > [...] >> Doing this kind of a patch at first on a few project's tox.ini, >> absolutely! I might even start with Horizon and PBR (yes, there's a >> problem there as well... which I haven't

Re: [openstack-dev] [TripleO] Planning for job execution outside the gate with Zuul v3

David Moreau Simard writes: > The reason why I mention "outside the gate" is because one of the features > of Zuul v3 is to dynamically construct its configuration by including > different repositories. > For example, the Zuul v3 from review.rdoproject.org can selectively

Re: [openstack-dev] Upstream LTS Releases

Erik McCormick <emccorm...@cirrusseven.com> writes: > On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair <cor...@inaugust.com> wrote: >> Erik McCormick <emccorm...@cirrusseven.com> writes: >> >>> The concept, in general, is to create a new set of cores f

Re: [openstack-dev] Upstream LTS Releases

Erik McCormick writes: > The concept, in general, is to create a new set of cores from these > groups, and use 3rd party CI to validate patches. There are lots of > details to be worked out yet, but our amazing UC (User Committee) will > be begin working out the

[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

  1   2   3   4   5   >