Re: [openstack-dev] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

Am Fr., 31. Aug. 2018 um 01:28 Uhr schrieb Doug Hellmann : Hi Doug, > | Packaging-rpm | 4 repos | We're ready - please send the patches. Greetings, Dirk __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [rpm-packaging] Step down as a reviewer

Hi Alberto, Am Mo., 13. Aug. 2018 um 11:08 Uhr schrieb Alberto Planas Dominguez : > I will change my role at SUSE at the end of the month (August 2018), so > I request to be removed from the core position on those projects. Sad to see you go, but I appreciate the heads up and wish you all the

[openstack-dev] [requirements][release] FFE for tooz 1.60.0

Hi, I would like to ask for a exception to add tooz 1.60.0 to stable/queens. As part of the msgpack-python -> msgpack switch over we converted all dependencies, but the tooz release did not include the dependency switch (not sure why, the branch point was just before the fix). As it is a one

Re: [openstack-dev] [release][requirements][monasca] FFE request for monasca-common

2018-02-08 11:05 GMT+01:00 Bedyk, Witold : > I would like to request FFE for monasca-common to be bumped in upper > constraints. The version has been bumped together with the rest of Monasca > components [1]. Monasca-common is used only in Monasca projects [2].

Re: [openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

2018-01-30 16:53 GMT+01:00 Matthew Thode : > LGTM, +2 +2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] Switching to longer development cycles

2017-12-13 17:17 GMT+01:00 Thierry Carrez : > - We'd only do one *coordinated* release of the OpenStack components per > year, and maintain one stable branch per year > - We'd elect PTLs for one year instead of every 6 months > - We'd only have one set of community goals

Re: [openstack-dev] [devstack] SUSE jobs started failing on peakmem_tracker

Hi David, Thanks for looking into this. I do watch devstack changes every once in a while but couldn't catch this one in time. The missing pmap -XX flag problem has been there forever but it used to be non fatal. Now it is, which is in principle a good change. I will make sure that it passes

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

Hi Igor, 2017-02-16 15:43 GMT+01:00 Igor Yozhikov : > I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for > Packaging-RPM core. > Alberto done a lot of reviews for as for project modules [1],[2] as for rest > of OpenStack components [3]. His

Re: [openstack-dev] [FFE][requirements] python-* clients from last 2 days

Hi Dims, 2017-01-27 13:51 GMT+01:00 Davanum Srinivas : > I've consolidated the changes to the upper-constraints into One single review: > https://review.openstack.org/#/c/426116/ I'm ok with it if we have release team buy in. Greetings, Dirk

[openstack-dev] [rpm-packaging[packaging][rpm] Draft mascot logo

Hi all, your feedback appreciated. I really like it :) Greetings, Dirk -- Forwarded message -- From: Heidi Joy Tretheway Date: 2016-10-19 20:59 GMT+02:00 Subject: Your draft logo & a sneak peek ​[...]​ We welcome you to *share this logo with your team

Re: [openstack-dev] [packaging][rpm] 3rd-party gates promotion to voting gates

Hi, >> Gates that do not leave verified +1 are called non-voting, so >> logically gates that leaves verified +1 are called voting gates. > +1 Eh, what I wanted to +1 was: +1 to promote the check jobs on rpm-packaging from MOS and SUSE CI as voting jobs. Sorry for mixing up definitions and then

Re: [openstack-dev] [packaging][rpm] 3rd-party gates promotion to voting gates

Hi, 2016-09-29 14:12 GMT+02:00 Haïkel : > Gates that do not leave verified +1 are called non-voting, so > logically gates that leaves verified +1 are called voting gates. +1 Greetings, Dirk __

Re: [openstack-dev] [Release] [FFE] two xstatic packages to be bumped in upper-constraints, please

Am 13.09.2016 05:03 schrieb "Tony Breeds" : > > The reviews are: > > > > update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1 > > https://review.openstack.org/#/c/368970/ > > > > update constraint for XStatic-smart-table to new release 1.4.13.2 > >

[openstack-dev] [requirements][FFE] pymod2pkg 0.5.4

Hi, OpenStack RPM Packaging would like to update to pymod2pkg 0.5.4: https://review.openstack.org/#/c/367388/ this package is only used by packaging (renderspec and rpm-packaging git repos) that are on a release-independent schedule (iirc we're tagged as never-release) and since we're

Re: [openstack-dev] [requirements][FFE] block graphviz 0.5.0

Hi Tony, 2016-09-09 9:42 GMT+02:00 Tony Breeds : > Has some impact on octavia (doc-requirements) and rpm-packaging (internal > global-requirements.txt) Yeah, rpm-packaging shouldn't be a blocker on this, since we're just trying to keep a snapshot of g-r that we have

Re: [openstack-dev] [requirements][FFE] Request to allow os-vif 1.2.1 in upper-constraints for newton

Hi Matt, > This is the FFE to get this change in for newton: > > https://review.openstack.org/#/c/365165/ > > The os-vif 1.2.1 release was a bug fix patch release to get a high priority > bug [1] in for newton that is impacting the neutron linuxbridge job in the > gate [2]. > > So we already have

[openstack-dev] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group

Hi, I would like to suggest Javier Peña as an additional core reviewer for the packaging-rpm core group. He's been an extremely valueable contributor recently both doing regular reviews on the PRs as well as contributing more to the packaging effort overall. See

Re: [openstack-dev] [all][requirements] Refresher on how to use global requirements process

Hi Doug, > Cleaning up the readme makes a lot of sense. If we end up wanting to > split it a lot, I'd suggest moving some of the "consumer" facing info to > the project team guide, but it's moderately less easy to change there > because the reviewer group is different. .. which is a good thing,

[openstack-dev] [all] [requirements] Global Requirements Team contact point - #openstack-requirements

Hi all, I've updated https://wiki.openstack.org/wiki/Requirements#Contact (and also the rest of the wiki page) with newer information about global-requirements handling. Please if you find issues related to the global requirements update process in your project don't hesitate to join the

Re: [openstack-dev] [all][requirements] Refresher on how to use global requirements process

2016-05-19 1:08 GMT+02:00 Robert Collins : > It's already fully documented in the requirements repo README; if > there is no link to that from the project-guide, we should add one, > but I would not duplicate the content. Agreed. The project driver guide is not very

Re: [openstack-dev] [requirements] Bootstrapping new team for Requirements.

> That works for me. I'd prefer that meeting earlier in the week so perhaps > a UTC 11:00 Tuesday would be a good time to use until DST changes and then we > can re check based on who is active. Works for me. thanks for the writeup in the etherpad, that was very helpful. Lets meet on

[openstack-dev] [packaging-rpm] PTL candidacy for the Newton Cycle

Hi everyone, I'd like to announce my candidacy for the RPM Packaging for OpenStack PTL. I am putting up the candidacy because I would feel honored to continue doing the PTL role, but I'm also fine with passing on the torch. At the end of the day what matters is that the project becomes successful

Re: [openstack-dev] [rpm-packaging] core reviewers nomination

Haikel, > I'd like to propose new candidates for RPM packaging core reviewers: > Alan Pevec > Jakub Ruzicka +1 Greetings, Dirk __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] Fwd: [cloud-devel] Summit Report - Dirk

Hi, > Ha, I'm surprised you forwarded this. But thanks. :) Yeah, I guess I need to be more explicit on where my mails should be forwarded to without even asking me next time.. I apologize wholeheartedly. > Also, this is the first time Neutron has been more popular/buzzworthy than > Nova? Oh,

[openstack-dev] [rpm-packaging] PTL Candidacy

Hi, I'd like to announce my candidacy for the RPM Packaging for OpenStack PTL. During the Liberty cycle I've been co-PTL'ing this together with Haïkel Guemar as a bootstrap. For the Mitaka cycle we've been notified that this setup needs to be adjusted to a single PTL. Therefore we discussed this

[openstack-dev] [rpm-packaging] Meeting minutes IRC meeting July 16th

Hi, extraction of the meeting minutes from https://etherpad.openstack.org/p/openstack-rpm-packaging we agreed to switch to the standard way of doing meeting minutes once the infra review got merged. its a bit of a short minutes, feel free to reach out to number80 or me in case you have

[openstack-dev] [tc] Adding rpm-packaging to the openstack git namespace

Hello OpenStackers, hello TC, Haikel and I have just submitted an update to the change to the governance repo to add RPM packaging to the OpenStack projects: https://review.openstack.org/#/c/191587 As a start there we'd like to do a dual PTL from Red Hat (Haikel) and SUSE (myself) and we'd like

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Hi Joshua, An example of some specs already doing this (they are built using the cheetah template engine/style): https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs They are turned into 'normal' spec files (the compilation part) during build time. Right, I

[openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Hi, A couple of packagers from RDO and SUSE met today on IRC to kick off brain storming on unified upstream rpm packaging for OpenStack. Please note: there are currently two movements going on: RDO would like to move their Liberty packaging from github.com and gerrithub to openstack gerrit, and

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Hi Russel, I'm just kind of curious ... as both the RDO and SUSE folks look closer at this, how big are the differences? From the overall big picture, we're doing pretty much the same thing. We have both a tool chain to continuously track changes as they happen in upstream git, packaging that

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Hi Derek, I selected these 80 to move all of what RDO is currently maintaining on gerrithub to review.openstack.org, this was perhaps too big a set and in RDO we instead may need to go hybrid. Yeah, In my opinion we ahve lots of repeated divergence between the different python modules, so

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Hi Derek, 2015-06-09 0:34 GMT+02:00 Derek Higgins der...@redhat.com: This patch would result in 80 packaging repositories being pulled into gerrit. I personally would prefer to start with fewer but common packages between all RPM distros (is there more than Red Hat and SUSE ?) than starting

Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?

2014-10-02 14:19 GMT+02:00 Duncan Thomas duncan.tho...@gmail.com: Hi, What is actually needed is those who rely on the stable branch(es) existence need to step forward and dedicate resources to it. Putting the work on people not interested is just the same as killing them off, except slower,

Re: [openstack-dev] [All] [I18N] compiling translation message catalogs

Hi Julie, I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE packaging: the Horizon team would love to have your opinion on this (it came up during our weekly meeting). I was somehow not CC'ed although I'm the SUSE packager for OpenStack. In my opinion a) is the option

Re: [openstack-dev] [all] sample config files should be ignored in git...

Hi, When I was an operator, I regularly referred to the sample config files in the git repository. The sample config files in git repository are tremendeously useful for any operator and OpenStack Packager. Having them generateable with a tox line is very cumbersome. As a minimum those config

Re: [openstack-dev] [Openstack-operators] [TripleO] consistency vs packages in TripleO

Hi Robert, So far: - some packages use different usernames - some put things in different places (and all of them use different places to the bare metal ephemeral device layout which requires /mnt/). - possibly more in future. Somehow I miss between your suggestions of option #A and #B

Re: [openstack-dev] bad default values in conf files

were not appropriate for real deployment, and our puppet modules were not providing better values https://bugzilla.redhat.com/show_bug.cgi?id=1064061. I'd agree that raising the caching timeout is a not a good production default choice. I'd also argue that the underlying issue is fixed with

Re: [openstack-dev] [Hacking] unit test code is too less

Hi Zhi Qiang, for i.e. the hacking rule h233 in hacking looks not so robust, https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345 it cannot detect \bprint$ \bprint xxx, (\s+ It currently detects both as a violation of the rule, which is IMHO correct. Please note that

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

Hi Sean, Cinder uncapping python-keystoneclient will get us past this. There is a review exactly proposing that: https://review.openstack.org/#/c/36344/ Though I'm not quite sure how we got to this break point in the first place. I think this is due to the django_openstack_auth breakage

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days https://bugs.launchpad.net/keystone/+bug/1200214 created. Greetings, Dirk ___ OpenStack-dev mailing list

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Hi Thierry, Indeed. The whole idea behind a single release channel for python client libraries was that you should always be running the latest, as they should drastically enforce backward compatibility. Well, backward compatibility can be tricky when it comes to test. We've for example