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

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

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

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

Re: [openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

Boden Russell <boden...@gmail.com> writes: > On 10/27/17 6:35 PM, James E. Blair wrote: >> >> We're rolling out a new version of Zuul that corrects the issues, and >> the migration doc has been updated. The main things to know are: >> >> * If your pr

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

"gong_ys2004" 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 the one I specified in the .zuull.yaml > https://review.openstack.org/#/c/516004/4/.zuul.yaml:I

[openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

Hi, I'd like to draw your attention to some things that we're changing in Zuul v3 that affect stable branches. We found a couple of interrelated issues where Zuul's behavior did not match our expectations, and we also had some incorrect advice in the migration doc. We're rolling out a new

Re: [openstack-dev] Gertty dashboards

Sławek Kapłoński writes: >>> "(NOT owner:self) status:open label:Code-Review-0,self >>> label:Workflow=0 (project:openstack/neutron OR >>> project:openstack/neutron-lib OR project:openstack/shade) >>> branch:master” >> >> If you haven't already, make sure you are subscribed

Re: [openstack-dev] Gertty dashboards

Jeremy Stanley writes: > It's software, so probably. That said, I expect Gertty would need > some sort of first-class dashboard support where it knows (beyond > simple keybindings for arbitrary queries, maybe similar to how it > treats owner:self changes?) that you want all

Re: [openstack-dev] Gertty dashboards

Sławek Kapłoński writes: > Hello, > > Recently I started using Getty and I think it’s good tool. > I have one problem which I don’t know how to solve. On web based > gerrit page (review.openstack.org) I have defined page with own query: > > "(NOT owner:self) status:open

[openstack-dev] [infra][all] Decommissioning Zuul v2

Hi, At the infra meeting[1] yesterday, there was general agreement that we have likely passed the point at which we would consider a rollback to Zuul v2, and will iterate forward on any further issues (as we have been doing since Sunday). We plan on freezing the Zuul v2 config[2] now, and keep

[openstack-dev] [infra][all] Stable branch jobs in Zuul v3

Hi, If you have started moving Zuul configuration into your project repos, please note the following: You will probably need to backport at least the "project" stanza to stable branches. Zuul's configuration is global; that includes configuration loaded from all branches of a project. So

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

Gary Kotton writes: > Hi, > At the moment the neutron, neutron-lib and many of the decomposed projects > are still failing with the v3. Does this mean that we are broken from the > 11th? > For the decomposed projects we have a work around to help address this in the >

[openstack-dev] [all][infra] Zuul v3 migration update

Hi, We started to migrate to Zuul v3 today, but ran into some problems which delayed us sufficiently that we're going to suspend activity until tomorrow. In the mean time, please consider the project-config repository frozen to all changes except those which are necessary for the migration. We

Re: [openstack-dev] [Release-job-failures][infra] Release of openstack-infra/zuul-sphinx failed

Jeremy Stanley writes: > On 2017-09-25 10:51:42 -0400 (-0400), Doug Hellmann wrote: >> I assume someone has already noticed that this release failed, but I'm >> forwarding it to the dev list just in case. > > Thanks for the heads up! And yes, it's currently under discussion in

[openstack-dev] 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-dev] [nova] bug triage experimentation

Sean Dague writes: > On 07/05/2017 03:23 PM, Emilien Macchi wrote: > >> >> I also believe that some of the scripts could be transformed into >> native features of Storyboard where bugs could be auto-triaged >> periodically without human intervention. >> Maybe it would convince

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

Thierry Carrez writes: > Removing the root cause would be a more radical move: stop offering > hosting to non-OpenStack projects on OpenStack infrastructure > altogether. We originally did that for a reason, though. The benefits of > offering that service are: > > 1- it

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

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

Clint Byrum writes: > Excerpts from Matthieu Huin's message of 2017-03-21 18:43:49 +0100: >> Hello James, >> >> Thanks for opening the discussion on this topic. I'd like to mention that a >> very common type of secrets that are used in Continuous Deployments >> scenarios are

[openstack-dev] [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-dev] [Sahara][infra] Jenkins based 3rd party CIs

Telles Nobrega writes: > Hello, > > we from Sahara use the compatibility layer with Zuulv2.5 and we are > wondering if with the change to Zuulv3 this compatibility layer will still > be maintained. > If the layer is removed it will reflect into some changes on our side and >

Re: [openstack-dev] [infra] where the mail-man lives?

"bogda...@mail.ru" writes: > The mail-man for the openstack-dev mail list is missing at least 'kolla' > and 'development' checkboxes. It would be nice to make its filter case > unsensitive as well, so it would match both 'All' and 'all' tags. How > could we fix that? Any place

Re: [openstack-dev] Zuul v3 - What's Coming: What to expect with the Zuul v3 Rollout

"bogda...@mail.ru" writes: > That's great news! In-repo configs will speed up development for teams, > with a security caveat for infrastructure team to keep in mind. The > ansible runner CI node which runs playbooks for defined jobs, should not > content sensitive information,

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.4.0

Mikhail Medvedev writes: > > In theory it is possible split diff and syntax spatially, so there > would be no need to mix diff and syntax colors. Mockup > http://i.imgur.com/gAD9x9v.png True, though I should have clarified my comments as applying particularly to the

Re: [openstack-dev] Announcing Gertty 1.4.0

"Sean M. Collins" writes: > For some reason I installed the newer version but still the version > string reports > > Gertty version: 1.1.1.dev24 When I install it from pypi via pip in a new virtualenv, I see: Gertty version: 1.4.0 Maybe you have an older copy installed

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.4.0

Masayuki Igawa <masayuki.ig...@gmail.com> writes: > Hi! > > On Wed, Jul 27, 2016 at 11:50 PM, James E. Blair <cor...@inaugust.com> wrote: >> Michał Dulko <michal.du...@intel.com> writes: >> >>> Just wondering - were there tries to implement synt

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.4.0

Michał Dulko writes: > Just wondering - were there tries to implement syntax highlighting in > diff view? I think that's the only thing that keeps me from switching to > Gertty. I don't know of anyone working on that, but I suspect it could be done using the pygments

[openstack-dev] Announcing Gertty 1.4.0

Announcing Gertty 1.4.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-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?

Kashyap Chamarthy writes: > If it reduces nondeterministic spam for the CI Infra, and makes us > achieve the task at hand, sure. [/me need to educate himself a > bit more on the Zuul pipeline infrastructure.] > > Worth filing this (and your 'idle pipeline' thought below) in

[openstack-dev] Upcoming changes now that Jenkins has retired

Now that we have retired Jenkins, we have some upcoming changes: * Console logs are now available via TCP The status page now has "telnet" protocol links to running jobs. If you connect to the host and port specified in that link, you will be sent the console log for that job up to that

[openstack-dev] There is no Jenkins, only Zuul

Since its inception, the OpenStack project has used Jenkins to perform its testing and artifact building. When OpenStack was two git repos, we had one Jenkins master, a few slaves, and we configured all of our jobs manually in the web interface. It was easy for a new project like OpenStack to

Re: [openstack-dev] [all] Removal of in progress console log access

Sean Dague writes: > Yes, that would let you see the results of an individual experimental > run that is complete before they all return and post to the change. Once > they are all done, they are listed on the change, so that's good enough. We'll need a Zuul restart for this, so

Re: [openstack-dev] [all] Removal of in progress console log access

Sean Dague <s...@dague.net> writes: > On 04/18/2016 11:22 AM, James E. Blair wrote: >> Sean Dague <s...@dague.net> writes: >> >>> Bummer. This gets used a to figure out the state of things given that >>> zuul links to the console even after the

Re: [openstack-dev] [all] Removal of in progress console log access

Sean Dague writes: > Bummer. This gets used a to figure out the state of things given that > zuul links to the console even after the job is complete. Changing that > to the log server link would mitigate the blind spot. Yeah, we know it's important, which is why we're working

Re: [openstack-dev] [ironic] Midcycle summary part 1/6

Jim Rollenhagen writes: > As a note, the asterisk setup that Infra provided was *fantastic*, and > the virtual-ness of this midcycle is going better than I ever expected. > Thanks again to the infra team for all that you do for us. <3 That's great to hear! I'm looking

Re: [openstack-dev] Announcing a simple new tool: git-restack

Paul Michali writes: > Sounds interesting... the link > https://docs.openstack.org/infra/git-restack/ referenced > as the home page in PyPI is a broken link. I'm clearly getting ahead of things. The correct link is: http://docs.openstack.org/infra/git-restack/ Thanks,

[openstack-dev] Announcing a simple new tool: git-restack

Hi, I'm pleased to announce a new and very simple tool to help with managing large patch series with our Gerrit workflow. In our workflow we often find it necessary to create a series of dependent changes in order to make a larger change in manageable chunks, or because we have a series of

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.3.0

Michał Dulko writes: > As this was sent to openstack-dev list, I'll ask a Gertty usage question > here. Was anyone able to use Gertty successfully behind a proxy? My > environment doesn't allow any traffic outside the proxy and I haven't > noticed a config option to set

[openstack-dev] Announcing Gertty 1.3.0

Announcing Gertty 1.3.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-dev] Troubleshooting cross-project comms

Sean Dague writes: > Has anyone considered using #openstack-dev, instead of a new meeting > room? #openstack-dev is mostly a ghost town at this point, and deciding > that instead it would be the dedicated cross project space, including > meetings support, might be interesting. I

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

Sean Dague writes: > Given that it's on track for getting accepted upstream, it's probably > something we could cherry pick into our deploy, as it won't be a > divergence issue. Once it merges upstream, yes. -Jim

Re: [openstack-dev] [Fuel][Infra] HA deployment tests on nodepool

Aleksandra Fedorova writes: > Hi, everyone, > > > > in Fuel project we run two HA deployment tests for every commit in > openstack/fuel-library repository. Currently these tests are run by > Fuel CI - the standalone Third-Party CI system, which can vote on >

[openstack-dev] Report from Gerrit User Summit

Khai Do and I attended the Gerrit User Summit this weekend. It was a very busy weekend indeed with quite a lot of activity in all areas related to Gerrit. The following is a brief summary of items which may be of interest to our community. --==-- David Pursehouse from Sony Mobile spoke about

[openstack-dev] Announcing a new library: requestsexceptions

Hi, I'm pleased to announce the availability of a new micro-library named requestsexceptions. Now the task of convincing the requests library not to fill up your filesystem with warnings about SSL requests has never been easier! Over in infra-land, we use the requests library a lot, whether

[openstack-dev] Do not modify (or read) ERROR_ON_CLONE in devstack gate jobs

Hi, Recently we noted some projects modifying the ERROR_ON_CLONE environment variable in devstack gate jobs. It is never acceptable to do that. It is also not acceptable to read its value and alter a program's behavior. Devstack is used by developers and users to set up a simple OpenStack

Re: [openstack-dev] [glance] proposed priorities for Mitaka

Thierry Carrez writes: > Doug Hellmann wrote: >> [...] >> 1. Resolve the situation preventing the DefCore committee from >>including image upload capabilities in the tests used for trademark >>and interoperability validation. >> >> 2. Follow through on the

Re: [openstack-dev] Gerrit downtime on Friday 2015-09-11 at 23:00 UTC

cor...@inaugust.com (James E. Blair) writes: > On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for > about 30 minutes while we rename some projects. > > Existing reviews, project watches, etc, should all be carried > over. This has been completed without incident

[openstack-dev] [infra] PTL non-candidacy

Hi, I've been the Infrastructure PTL for some time now and I've been fortunate to serve during a time when we have not only grown the OpenStack project to a scale that we only hoped we would attain, but also we have grown the Infrastructure project itself into truly uncharted territory. Serving

[openstack-dev] Gerrit downtime on Friday 2015-09-11 at 23:00 UTC

On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for about 30 minutes while we rename some projects. Existing reviews, project watches, etc, should all be carried over. Currently, we plan on renaming the following projects: stackforge/os-ansible-deployment -

[openstack-dev] Stackforge migration on October 17; action required for stackforge projects

Hi, In a previous message[1] I described a plan for moving projects in the stackforge/ git namespace into openstack/. We have scheduled this migration for Saturday October 17, 2015. If you are responsible for a stackforge project, please visit the following wiki page as soon as possible and add

[openstack-dev] Migrating existing projects in the stackforge namespace

Hi, As mentioned previously[1], we are retiring the stackforge/ namespace for git repositories and creating new projects in openstack/. This is largely a cosmetic change and does not change the governance model for new projects. As part of this we want to move all of the projects that are

Re: [openstack-dev] Stackforge namespace retirement

Fox, Kevin M kevin@pnnl.gov writes: What is the process for current stackforge projects to move into the openstack namespace then? Is it a simple request now, or a more complicated process? Great question. I have proposed a process for that in a new thread:

[openstack-dev] Stackforge namespace retirement

Hi, The TC has recently been considering what the big tent means for Stackforge. In short, very little will be changing, except that we will now start putting projects previously destined for stackforge/ in the openstack/ git namespace. The big tent is a recognition that there are a lot of

  1   2   3   >