[openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train
Hi everybody! As the subject reads, the "T" release of OpenStack is officially "Train". Unlike recent choices Train was the popular choice so congrats! Thanks to everybody who participated and help with the naming process. Lets make OpenStack Train the release so awesome that people can't help but choo-choo-choose to run it[1]! Yours Tony. [1] Too soon? Too much? signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cloudkitty] IRC meetings and community
On Wed, Nov 07, 2018 at 08:35:02PM +0100, Luka Peschke wrote: > Here's the patch: https://review.openstack.org/#/c/616205/. If it is not > merged by Friday (date of the first meeting), I'll send the log of the first > meeting to this ML. Even if the above doesn't merge you can still use #startmeeting in #cloudkitty and the logs will be published to eavesdrop. The chnage you submitted its just about raising visibility not access control. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Results of the T release naming poll. open
Hello all! The results of the naming poll are in! **PLEASE REMEMBER** that these now have to go through legal vetting. So it is too soon to say 'OpenStack Train' is our next release, given that previous polls have had some issues with the top choice. In any case, the names will be sent off to legal for vetting. As soon as we have a final winner, I'll let you all know. https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_aac97f1cbb6c61df&rkey=7c8b5588574494c1 Result 1. Train (Condorcet winner: wins contests with all other choices) 2. Tiger loses to Train by 142–70 3. Timber loses to Train by 142–72, loses to Tiger by 100–76 4. Trail loses to Train by 150–55, loses to Timber by 93–62 5. Telluride loses to Train by 155–56, loses to Trail by 81–69 6. Teller loses to Train by 158–46, loses to Telluride by 70–67 7. Treasure loses to Train by 151–52, loses to Teller by 68–67 8. Teakettle loses to Train by 158–49, loses to Treasure by 75–67 9. Tincup loses to Train by 157–47, loses to Teakettle by 67–60 10. Turret loses to Train by 158–48, loses to Tincup by 75–56 11. Thomas loses to Train by 159–42, loses to Turret by 66–63 12. Trinidad loses to Train by 153–44, loses to Thomas by 70–56 13. Troublesome loses to Train by 165–41, loses to Trinidad by 69–62 14. Thornton loses to Train by 163–35, loses to Troublesome by 62–59 15. Tyrone loses to Train by 163–35, loses to Thornton by 58–38 16. Tarryall loses to Train by 170–31, loses to Tyrone by 54–50 17. Timnath loses to Train by 170–23, loses to Tarryall by 60–32 18. Tiny Town loses to Train by 168–29, loses to Timnath by 45–43 19. Torreys loses to Train by 167–29, loses to Tiny Town by 48–40 20. Trussville loses to Train by 169–25, loses to Torreys by 43–34 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Asking for suggestion of video conference tool for team and webinar
On Tue, Nov 06, 2018 at 06:07:18AM -0800, Julia Kreger wrote: > I don't know how the cost structure works for Bluejeans, but I've found it > works very well for calls with many people on video. I typically have calls > with 14+ people nearly everyone has their video enabled without a problem. Just for the record it has a limit of 100 connections[1] before you need to use 'primetime'. Yours Tony. [1] It's kinda sad that I've hit that :( signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all]Naming the T release of OpenStack -- Poll open
Hi all, Time is running out for you to have your say in the T release name poll. We have just under 3 days left. If you haven't voted please do! On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote: > Hi folks, > > It is time again to cast your vote for the naming of the T Release. > As with last time we'll use a public polling option over per user private URLs > for voting. This means, everybody should proceed to use the following URL to > cast their vote: > > > https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df&akey=b9e448b340787f0e > > We've selected a public poll to ensure that the whole community, not just > gerrit > change owners get a vote. Also the size of our community has grown such that > we > can overwhelm CIVS if using private urls. A public can mean that users > behind NAT, proxy servers or firewalls may receive an message saying > that your vote has already been lodged, if this happens please try > another IP. > > Because this is a public poll, results will currently be only viewable by > myself > until the poll closes. Once closed, I'll post the URL making the results > viewable to everybody. This was done to avoid everybody seeing the results > while > the public poll is running. > > The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results > will be > posted shortly after. > > [1] https://governance.openstack.org/tc/reference/release-naming.html > --- > > According to the Release Naming Process, this poll is to determine the > community preferences for the name of the T release of OpenStack. It is > possible that the top choice is not viable for legal reasons, so the second or > later community preference could wind up being the name. > > Release Name Criteria > - > > Each release name must start with the letter of the ISO basic Latin alphabet > following the initial letter of the previous release, starting with the > initial release of "Austin". After "Z", the next name should start with > "A" again. > > The name must be composed only of the 26 characters of the ISO basic Latin > alphabet. Names which can be transliterated into this character set are also > acceptable. > > The name must refer to the physical or human geography of the region > encompassing the location of the OpenStack design summit for the > corresponding release. The exact boundaries of the geographic region under > consideration must be declared before the opening of nominations, as part of > the initiation of the selection process. > > The name must be a single word with a maximum of 10 characters. Words that > describe the feature should not be included, so "Foo City" or "Foo Peak" > would both be eligible as "Foo". > > Names which do not meet these criteria but otherwise sound really cool > should be added to a separate section of the wiki page and the TC may make > an exception for one or more of them to be considered in the Condorcet poll. > The naming official is responsible for presenting the list of exceptional > names for consideration to the TC before the poll opens. > > Exact Geographic Region > --- > > The Geographic Region from where names for the S release will come is Colorado > > Proposed Names > -- > > * Tarryall > * Teakettle > * Teller > * Telluride > * Thomas : the Tank Engine > * Thornton > * Tiger > * Tincup > * Timnath > * Timber > * Tiny Town > * Torreys > * Trail > * Trinidad > * Treasure > * Troublesome > * Trussville > * Turret > * Tyrone > > Proposed Names that do not meet the criteria (accepted by the TC) > - > > * Train🚂 : Many Attendees of the first Denver PTG have a story to tell about > the trains near the PTG hotel. We could celebrate those stories with this > name > > Yours Tony. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all]Naming the T release of OpenStack -- Poll open
On Tue, Oct 30, 2018 at 11:25:02AM -0700, iain macdonnell wrote: > I must be losing it. On what planet is "Tiny Town" a single word, and > "Troublesome" not more than 10 characters? Sorry for the mistake. Should either of these names win the popular vote clearly they would not be viable. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all]Naming the T release of OpenStack -- Poll open
Hi folks, It is time again to cast your vote for the naming of the T Release. As with last time we'll use a public polling option over per user private URLs for voting. This means, everybody should proceed to use the following URL to cast their vote: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df&akey=b9e448b340787f0e We've selected a public poll to ensure that the whole community, not just gerrit change owners get a vote. Also the size of our community has grown such that we can overwhelm CIVS if using private urls. A public can mean that users behind NAT, proxy servers or firewalls may receive an message saying that your vote has already been lodged, if this happens please try another IP. Because this is a public poll, results will currently be only viewable by myself until the poll closes. Once closed, I'll post the URL making the results viewable to everybody. This was done to avoid everybody seeing the results while the public poll is running. The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results will be posted shortly after. [1] https://governance.openstack.org/tc/reference/release-naming.html --- According to the Release Naming Process, this poll is to determine the community preferences for the name of the T release of OpenStack. It is possible that the top choice is not viable for legal reasons, so the second or later community preference could wind up being the name. Release Name Criteria - Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again. The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable. The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process. The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo". Names which do not meet these criteria but otherwise sound really cool should be added to a separate section of the wiki page and the TC may make an exception for one or more of them to be considered in the Condorcet poll. The naming official is responsible for presenting the list of exceptional names for consideration to the TC before the poll opens. Exact Geographic Region --- The Geographic Region from where names for the S release will come is Colorado Proposed Names -- * Tarryall * Teakettle * Teller * Telluride * Thomas : the Tank Engine * Thornton * Tiger * Tincup * Timnath * Timber * Tiny Town * Torreys * Trail * Trinidad * Treasure * Troublesome * Trussville * Turret * Tyrone Proposed Names that do not meet the criteria (accepted by the TC) - * Train🚂 : Many Attendees of the first Denver PTG have a story to tell about the trains near the PTG hotel. We could celebrate those stories with this name Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack-infra/shade failed
On Wed, Oct 24, 2018 at 03:23:53AM +, z...@openstack.org wrote: > Build failed. > > - release-openstack-python3 > http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python3/e84da68/ > : POST_FAILURE in 2m 18s So this failed because pypi thinks there was a name collision[1]: HTTPError: 400 Client Error: File already exists. See https://pypi.org/help/#file-name-reuse for url: https://upload.pypi.org/legacy/ AFACIT the upload was successful: shade-1.27.2-py2-none-any.whl : 2018-10-24T03:20:00 d30a230461ba276c8bc561a27e61dcfd6769ca00bb4c652a841f7148a0d74a5a shade-1.27.2-py2.py3-none-any.whl : 2018-10-24T03:20:11 8942b56d7d02740fb9c799a57f0c4ff13d300680c89e6f04dadb5eaa854e1792 shade-1.27.2.tar.gz: 2018-10-24T03:20:04 ebf40040b892f3e9bd4229fd05fff7ea24a08c51e46b7f2d8b3901ce34f51cbf The strange thing is that the tar.gz was uploaded *befoer* the wheel even though our publish jobs explictly do it in the other order and the timestamp of the tar.gz doesn't match the error message. SO I think we have a bug somewhere, more digging tomorrow Yours Tony. [1] http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python3/e84da68/job-output.txt.gz#_2018-10-24_03_20_15_264676 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for a process to keep up with Python releases
On Mon, Oct 22, 2018 at 04:33:49PM +0200, Thomas Goirand wrote: > One of the reoccurring problem that I'm facing in Debian is that not > only Python 3 version is lagging behind, but OpenStack dependencies are > also lagging behind the distro. Often, the answer is "we don't support > this or that version of X", which of course is very frustrating. Can you provide a recent instance of this? I feel like we have a misunderstanding here. > One > thing which would be super nice, would be a non-voting gate job that > test with the latest version of every Python dependencies as well, so we > get to see breakage early. We've stopped seeing them since we decided it > breaks too often and we would hide problems behind the > global-requirement thing. We watch for this in requirements where everyday we update to the latest co-installable dependencies[1] and gate on them. If that passes it gets merged into the repo and used by all projects. Where we could do better is making the failures visible, and we're open to suggestions there. We have the following caps: cmd2!=0.8.3,<0.9.0;python_version<'3.0' # MIT construct<2.9 # MIT Django<2;python_version<'3.0' # BSD Django<2.1;python_version>='3.0' # BSD django-floppyforms<2 # BSD elasticsearch<3.0.0 # Apache-2.0 jsonpath-rw<2.0 # Apache-2.0 jsonschema<3.0.0 # MIT PrettyTable<0.8 # BSD python-congressclient<2000 # Apache-2.0 warlock<2 # Apache-2.0 XStatic-jQuery<2 # MIT License These of course do impact the dependencies that are considered co-installable and we're working towards minimising this list. You can see from[1] that the lates urllib is incompatible with botocore. So we'll exclude that from the update and try again. Meanwahile we'll file a bug (Possibly a patch) in botocore to get the cap removed or bumped. Yours Tony. [1] https://review.openstack.org/#/c/612252/ signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack
On Thu, Oct 18, 2018 at 05:35:39PM +1100, Tony Breeds wrote: > Hello all, > As per [1] the nomination period for names for the T release have > now closed (actually 3 days ago sorry). The nominated names and any > qualifying remarks can be seen at2]. > > Proposed Names > * Tarryall > * Teakettle > * Teller > * Telluride > * Thomas > * Thornton > * Tiger > * Tincup > * Timnath > * Timber > * Tiny Town > * Torreys > * Trail > * Trinidad > * Treasure > * Troublesome > * Trussville > * Turret > * Tyrone > > Proposed Names that do not meet the criteria > * Train I have re-worked my openstack/governance change[1] to ask the TC to accept adding Train to the poll as (partially) described in [2]. I present the names above to the community and Foundation marketing team for consideration. The list above does contain Train, clearly if the TC do not approve [1] Train will not be included in the poll when created. I apologise for any offence or slight caused by my previous email in this thread. It was well intentioned albeit, with hindsight, poorly thought through. Yours Tony. [1] https://review.openstack.org/#/c/611511/ [2] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Naming the T release of OpenStack
Hello all, As per [1] the nomination period for names for the T release have now closed (actually 3 days ago sorry). The nominated names and any qualifying remarks can be seen at2]. Proposed Names * Tarryall * Teakettle * Teller * Telluride * Thomas * Thornton * Tiger * Tincup * Timnath * Timber * Tiny Town * Torreys * Trail * Trinidad * Treasure * Troublesome * Trussville * Turret * Tyrone Proposed Names that do not meet the criteria * Train However I'd like to suggest we skip the CIVS poll and select 'Train' as the release name by TC resolution[3]. My think for this is * It's fun and celebrates a humorous moment in our community * As a developer I've heard the T release called Train for quite sometime, and was used often at the PTG[4]. * As the *next* PTG is also in Colorado we can still choose a geographic based name for U[5] * If train causes a problem for trademark reasons then we can always run the poll I'll leave[3] for marked -W for a week for discussion to happen before the TC can consider / vote on it. Yours Tony. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals [3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 [4] https://twitter.com/vkmc/status/1040321043959754752 [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] [requirements] Stepping down as core reviewer
On Tue, Oct 16, 2018 at 06:03:54PM +0530, ʂʍɒρƞįł Ҟưȴķɒʁʉɨ wrote: > Dear OpenStackers, > > For a few months now, I am not able to contribute to code or reviewing > Kolla and Requirements actively given my current responsibilities, I > would like to take a step back and release my core reviewer ability > for the Kolla and Requirements repositories. Swapnil, I'm sorry to see you go. It was a blast working with you and your generous nature. Safe travels and great luck with your path takes you. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][plugins] Horizon plugins validation on CI
On Wed, Oct 17, 2018 at 04:18:26PM +0300, Ivan Kolodyazhny wrote: > Hi all, > > We discussed this topic at PTG both with Horizon and other teams. Sounds > like everybody is interested to have some cross-project CI jobs to verify > that plugins are not broken with the latest Horizon changes. > > The initial idea was to use tempest plugins for this effort like we do for > Horizon [1]. We've got a very simple test to verify that Horizon is up and > running and a user is able to login. > > It's easy to implement such tests for any existing horizon plugin. I tried > it for Heat and Manila dashboards. Given that I know very little about this but isn't it just as simple as running the say the octavia-dashboard[1] npm tests on all horizon changes? This would be similar to the way we run the nova[2] functional tests on all constraints changes in openstack/requirements. Yours Tony. [1] Of course all dashbaords/plugins [2] Not just nova but you get the idea signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-upstream-institute] Find a slot for a meeting to discuss - ACTION NEEDED
On Sat, Sep 29, 2018 at 02:50:31PM +0200, Ildiko Vancsa wrote: > Hi Training Team, > > Based on the votes on the Doodle poll below we will have our ad-hoc meeting > __next Friday (October 5) 1600 UTC__. > > Hangouts link for the call: > https://hangouts.google.com/call/BKnvu7e72uB_Z-QDHDF2AAEI I don't suppose it was recorded? I was lucky enough to be on vacation for 3 weeks, which means I couldn't make the call. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Nominations for the "T" Release name
Hey everybody, Once again, it is time for us to pick a name for our "T" release. Since the associated Summit will be in Denver, the Geographic Location has been chosen as "Colorado" (State). Nominations are now open. Please add suitable names to https://wiki.openstack.org/wiki/Release_Naming/T_Proposals between now and 2018-10-15 23:59 UTC. In case you don't remember the rules: * Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again. * The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable. * The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process. * The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo". Names which do not meet these criteria but otherwise sound really cool should be added to a separate section of the wiki page and the TC may make an exception for one or more of them to be considered in the Condorcet poll. The naming official is responsible for presenting the list of exceptional names for consideration to the TC before the poll opens. Let the naming begin. Tony. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] (ex) PTL on vacation
Hi All, As Stable is no longer a project, I'm no longer a PTL so I don't really need to do this but ... I'm going on vacation for 3'ish weeks. I do plan on checking my email from time-to-time but really if anything comes up that needs urgent attention you'll need to ping stable-maint-core. I'm not fussy about my open changes so if they need fixing and you'd like them merged while I'm out feel free to upload your own revision. Have fun, I know I will ;D Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Tag of openstack/kuryr-kubernetes failed
On Tue, Sep 11, 2018 at 10:20:52AM +, z...@openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes > http://logs.openstack.org/6c/6ce2f5edd0b3dbb2c7edebca37ccc8219675e189/tag/publish-openstack-releasenotes/85bfc1a/ > : FAILURE in 4m 45s > - publish-openstack-releasenotes-python3 > http://logs.openstack.org/6c/6ce2f5edd0b3dbb2c7edebca37ccc8219675e189/tag/publish-openstack-releasenotes-python3/abd87f9/ > : SUCCESS in 4m 17s This looks like the same failure from yesterday which has been fix in reno but not yet released. As Doug points out the py3 job passed so the content is live ;P Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed
On Mon, Sep 10, 2018 at 05:58:21AM -0600, Doug Hellmann wrote: > The python3 version of the job worked. I think both jobs ran because the > repo is in the middle of its zuul settings transition and the cleanup > patch hasn't merged yet. Since one of them worked, I think the published > output should be OK. Ahh okay. Thanks Doug Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
On Wed, Sep 05, 2018 at 10:03:09AM -0500, Matthew Thode wrote: > The requirements team has gone ahead and made a aweful hack to get gate > unwedged. The commit message is a very good summary of our reasoning > why it has to be this way for now. My comment explains our plan going > forward (there will be a revert prepared as soon as this merges for > instance). > > step 1. merge this This == https://review.openstack.org/#/c/599277/ ; done and similar versions on stable branches. > step 2. look into and possibly fix our tooling (why was the gitref > addition not rejected by gate) Not done yet > step 3. fix networking-odl (release ceilometer) Done. See: * https://review.openstack.org/#/c/601487/ ; and * https://review.openstack.org/#/c/601488/ > step 4. unmerge this Done and marked as Depending on the reviews above. https://review.openstack.org/#/c/600123/ So I think we have the required reviews lined up to fix master, but they need votes from zuul and core teams. We can handle stable later ;P Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed
On Tue, Sep 11, 2018 at 07:39:39AM +1000, Ian Wienand wrote: > > On Mon, Sep 10, 2018 at 05:13:35AM +, z...@openstack.org wrote: > >> Build failed. > >> > >> - publish-openstack-releasenotes > >> http://logs.openstack.org/c8/c89ca61fdcaf603a10750b289228b7f9a3597290/tag/publish-openstack-releasenotes/fbbd0fa/ > >> : FAILURE in 4m 03s > > The line that is causing this is > > - Add OSC plugin support for the “Networking Service Function Chaining” ... > > see if you can find the unicode :) > > I did replicate it by mostly doing what the gate does; make a python2 > vitualenv and install everything, then run > > ./env/bin/sphinx-build -a -E -W -d releasenotes/build/doctrees/ \ >-b html releasenotes/source/ releasenotes/build/html/ > > In the gate, it doesn't use "tox -e releasenotes" ... which passes > because it's python3 and everything is unicode already. > > I think this is a reno problem, and I've proposed > > https://review.openstack.org/601432 Use unicode for debug string Thanks Ian! Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On Mon, Sep 10, 2018 at 08:40:28AM +0200, Julien Danjou wrote:
> On Mon, Sep 10 2018, Tony Breeds wrote:
>
> > It looks like in August this was already setup
> > https://review.openstack.org/#/c/591682/
> > So releases going forward will be on pypi.
> >
> > Julien, Do you mind me arranging for at least the following versions to
> > be published to pypi?
> >
> > [tony@thor ceilometer]$ for branch in
> > origin/stable/{ocata,pike,queens,rocky} ; do printf "%-25s: %s\n" $branch
> > "$(git describe --abbrev=0 $branch)" ; done
> > origin/stable/ocata : 8.1.5
> > origin/stable/pike : 9.0.6
> > origin/stable/queens : 10.0.1
> > origin/stable/rocky : 11.0.0
>
> Sure, go ahead!
Thanks!
Yours Tony.
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed
On Mon, Sep 10, 2018 at 05:13:35AM +, z...@openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes > http://logs.openstack.org/c8/c89ca61fdcaf603a10750b289228b7f9a3597290/tag/publish-openstack-releasenotes/fbbd0fa/ > : FAILURE in 4m 03s I'm not sure what caused this to fail and my attempts to reproduce it haven't been fruitful :( Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On Mon, Sep 10, 2018 at 11:02:06AM +1000, Ian Wienand wrote: > On 09/10/2018 09:39 AM, Tony Breeds wrote: > > Julien, Do you mind me arranging for at least the following versions to > > be published to pypi? > > For this particular case, I think our best approach is to have an > admin manually upload the tar & wheels from tarballs.openstack.org to > pypi. All other options seem to be sub-optimal: > > - if we re-ran the release pipeline, I *think* it would all be >idempotent and the publishing would happen, but there would be >confusing duplicate release emails sent. fungi also points[1] out that we'd re-sign/publish those artefacts which isn't desirable. So I think we're limited to publishing the existing artefacts (preferred) or waiting/making releases from the open branches. Yours Tony. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-09-10.log.html#t2018-09-10T04:16:37 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On Sat, Sep 08, 2018 at 03:21:38PM +1000, Tony Breeds wrote:
> On Fri, Sep 07, 2018 at 11:09:15AM +0200, Julien Danjou wrote:
>
> > You can, I've already said +1 on a review a few weeks ago. :)
>
> Oh great. I'll dig that up and push forward with that side of things if
> you don't mind.
It looks like in August this was already setup
https://review.openstack.org/#/c/591682/
So releases going forward will be on pypi.
Julien, Do you mind me arranging for at least the following versions to
be published to pypi?
[tony@thor ceilometer]$ for branch in origin/stable/{ocata,pike,queens,rocky} ;
do printf "%-25s: %s\n" $branch "$(git describe --abbrev=0 $branch)" ; done
origin/stable/ocata : 8.1.5
origin/stable/pike : 9.0.6
origin/stable/queens : 10.0.1
origin/stable/rocky : 11.0.0
Yours Tony.
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On Fri, Sep 07, 2018 at 11:09:15AM +0200, Julien Danjou wrote: > You can, I've already said +1 on a review a few weeks ago. :) Oh great. I'll dig that up and push forward with that side of things if you don't mind. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][keystone] python3 goal progress and tox_install.sh removal
On Thu, Sep 06, 2018 at 03:01:01PM -0500, Lance Bragstad wrote: > I'm noticing some odd cases with respect to the python 3 community goal > [0]. So far my findings are specific to keystone repositories, but I can > imagine this affecting other projects. > > Doug generated the python 3 reviews for keystone repositories, including > the ones for stable branches. We noticed some issues with the ones proposed > to stable (keystoneauth, python-keystoneclient) and master > (keystonemiddleware). For example, python-keystoneclient's stable/pike [1] > and stable/ocata [2] branches are both failing with something like [3]: > > ERROR: You must give at least one requirement to install (see "pip help > install") I've updated 1 and 2 to do the same thing that lots of other repos do and just exit 0 in this case. 1 and 2 now have a +1 from zuul. > I've attempted to remove tox_install.sh using several approaches with > keystonemiddleware master [7]. None of which passed both unit tests and the > requirements check. Doug pointed out the fix here, which I added. It passed most of the gate but failed in an unrelated neutron test so I've rechecked it. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] [release] [stable] Cherry-pick migration to stable/rocky
On Wed, Sep 05, 2018 at 10:54:25AM +0100, Dougal Matthews wrote: > On 5 September 2018 at 10:52, Dougal Matthews wrote: > > > (Note: I added [release] to the email subject, as I think that will make > > it visible to the right folks.) > > > > Darn. It should have been [stable]. I have added that now. Sorry for the > noise. Backporting a migration like that is OK as long as you don't skip migrations, that is to say revision '030' of the database should be the same on all branches. Given we've only just released rocky I expect that will be the case here. You absolutely must have a release note and call it out as upgrade impact and of course this is a minor release not a patch release. If y'all push a release note (probably on master too?) then I'm okay with the backport and release Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On Thu, Sep 06, 2018 at 01:33:12PM +0300, Michel Peterson wrote: > I remember that before landing the problematic patch [1] there was some > discussion around it. Basically the problem was not n-odl but ceilometer > not being in pypi, but we never foresaw this problem. > > Now that the problem is so critical, the question is how can we, from the > n-odl team, help in fixing this? I am open to help in any effort that > involves n-odl or any other project. As other have pointed out we can just ask the Telemetry team (PTL on CC) why we can't publish ceilometer to pypi? https://pypi.org/project/ceilometer/ certainly seems to be the right project. The crux of the code issue is: from ceilometer.network.statistics import driver in networking_odl/ceilometer/network/statistics/opendaylight_v2/driver.py If this is supposed to be used they way you are how are prjects supposed to get the ceilometer code? Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc] TC Candidacy
On Thu, Sep 06, 2018 at 09:24:39AM +1000, Tony Breeds wrote: > Hi JP, >I don't see a review in openstack/election from you. Are you able to > upload one befoer the deadline? > > Please see: > https://governance.openstack.org/election/#how-to-submit-a-candidacy > for more information. I really should have checked my email for merged changes before sending this sorry all. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][election] Last day for TC nominations
Hi folks, A quick reminder that we are in the last hours for TC candidate announcements. Nominations are open until Sep 06, 2018 23:45 UTC. If you want to stand for TC, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Thank you, [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc] TC Candidacy
On Wed, Sep 05, 2018 at 01:04:09PM +0200, jean-phili...@evrard.me wrote: > Hello everyone, > > I am hereby announcing my candidacy for a position on the OpenStack Technical > Committee (TC). Hi JP, I don't see a review in openstack/election from you. Are you able to upload one befoer the deadline? Please see: https://governance.openstack.org/election/#how-to-submit-a-candidacy for more information. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
On Fri, Aug 31, 2018 at 07:52:09PM -0500, Matthew Thode wrote: > The requirements project has a co-installability test for the various > projects, networking-odl being included. > > Because of the way the dependancy on ceilometer is done it is blocking > all reviews and updates to the requirements project. > > http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505 > > If networking-odl is not meant to be used as a library I'd recommend > it's removal from networking-bgpvpn (it's test-requirements.txt file). > Once that is done networking-odl can be removed from global-requirements > and we won't be blocked anymore. > > As a side note, fungi noticed that when you branched you are still > installing ceilometer from master. Also, the ceilometer team > doesnt wish it to be used as a library either (like networking-odl > doesn't wish to be used as a library). Yup this seems totally wrong for anything to be importing ceilometer directly like that. The networking-* projects are pretty tightly coupled so the links there are ok and workable but the ceilometer thing needs to be reconsidered. Having said that it's been part of the design for a while now. The "quick" fix would be to have ceilometer published to pypi, get requirements.txt fixed in networking-odl and re-release that. In order to unblock the requirements gate we *could* block 13.0.0 in global-requirements but that's strange as that means we're installing the queens version instead of rocky, and will more than likely have a cascade effect :( https://review.openstack.org/599277 is my pragmatic compromise while we work through this. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][tc] Nominations now open!
Nominations for the Technical Committee positions (6 positions) are now open and will remain open until Sep 06, 2018 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained on the election website[1]. Please note that the name of the file should match an email address in the foundation member profile of the candidate. Also for TC candidates election officials refer to the community member profiles at [2] please take this opportunity to ensure that your profile contains current information. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. The election will be held from Sep 18, 2018 23:45 UTC through to Sep 27, 2018 23:45 UTC. The electorate are the Foundation individual members that are also committers for one of the official teams[3] over the Aug 11, 2017 00:00 UTC - Aug 30, 2018 00:00 UTC timeframe (Queens to Rocky, as well as the extra-ATCs who are acknowledged by the TC[4]. Please see the website[5] for additional details about this election. Please find below the timeline: TC nomination starts @ Aug 30, 2018 23:45 UTC TC nomination ends @ Sep 06, 2018 23:45 UTC TC campaigning starts @ Sep 06, 2018 23:45 UTC TC campaigning ends@ Sep 18, 2018 23:45 UTC TC elections starts@ Sep 18, 2018 23:45 UTC TC elections ends @ Sep 27, 2018 23:45 UTC If you have any questions please be sure to either ask them on the mailing list or to the elections officials[6]. Thank you, [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy [2] http://www.openstack.org/community/members/ [3] https://governance.openstack.org/tc/reference/projects/ [4] https://releases.openstack.org/rocky/schedule.html#p-extra-atcs [5] https://governance.openstack.org/election/ [6] http://governance.openstack.org/election/#election-officials Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)
On Thu, Aug 30, 2018 at 09:12:57PM +, Jeremy Stanley wrote: > On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote: > [...] > > What needs to be done for this is full topic categories support > > under `options` page so people get to filter emails properly. > [...] > > Unfortunately, topic filtering is one of the MM2 features the > Mailman community decided nobody used (or at least not enough to > warrant preserving it in MM3). I do think we need to be consistent > about tagging subjects to make client-side filtering more effective > for people who want that, but if we _do_ want to be able to upgrade > we shouldn't continue to rely on server-side filtering support in > Mailman unless we can somehow work with them to help in > reimplementing it. The suggestion is to implement it as a 3rd party plugin or work with the mm community to implement: https://wiki.mailman.psf.io/DEV/Dynamic%20Sublists So if we decide we really want that in mm3 we have options. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][nova] Nominating melwitt for nova stable core
On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote: > I hereby nominate Melanie Witt for nova stable core. Mel has shown that she > knows the stable branch policy and is also an active reviewer of nova stable > changes. > > +1/-1 comes from the stable-maint-core team [1] and then after a week with > no negative votes I think it's a done deal. Of course +1/-1 from existing > nova-stable-maint [2] is also good feedback. > > [1] https://review.openstack.org/#/admin/groups/530,members > [2] https://review.openstack.org/#/admin/groups/540,members +1 from me! Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][election] TC Election Season
Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/election/#election-officials Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-upstream-institute] Restarting meetings on August 20
On Mon, Aug 20, 2018 at 10:23:07AM -0700, Kendall Nelson wrote: > Hello Everyone, > > To avoid meeting conflicts with the Women of OpenStack, we will actually be > doing meetings weekly on Mondays at 20:00 UTC on odd weeks. > > Long story short, our kickoff meeting after this luxurious summer break > will be a week from today on August 27th. > > Thanks everyone! > > See you next week :) I have a conflicting meeting on that schedule. I'll do my best to follow along from the meeting logs. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On Thu, Aug 16, 2018 at 10:45:32AM -0400, Doug Hellmann wrote: > Is there any reason we can't uncap pbr, at least within the CI jobs? It might work for the docs builds but jumping a major version of pbr, which if I recall caused problems ate the time (hence the lower-bound) for all octata projects wouldn't happen. How terrible would it be to branch openstackdocstheme and backport the fix without the pbr changes? It might also be possible, though I'm not sure how we'd land it, to branch (stable/ocata) openstackdocstheme today and just revert the pbr changes to set the lower bound. If you let me know what the important changes are to functionality in oslosdocstheme I can play with it next week. Having said that I'm aware there is time pressure here so I'm happy for others to do it Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On Thu, Aug 16, 2018 at 06:27:39AM +0200, Andreas Jaeger wrote: > Ocata should be retired by now ;) Let's drop it... *cough* extended maintenance *cough* ;P So we don't need the Ocata docs to be rebuilt with this version? Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On Wed, Aug 15, 2018 at 09:10:18AM -0400, Doug Hellmann wrote:
> Excerpts from Andreas Jaeger's message of 2018-08-15 09:28:51 +0200:
> > On 08/15/2018 07:25 AM, Tony Breeds wrote:
> > > On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:
> > >
> > >> Now that https://review.openstack.org/#/c/591671/ has landed, we need
> > >> someone to propose the backports of the constraint updates to all of the
> > >> existing stable branches.
> > >
> > > Done:
> > > https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements
> > >
> > > I'm not entirely convinced such a new release will work on older
> > > branches but I guess that's what CI is for :)
> >
> > openstackdocsstheme has:
> > sphinx!=1.6.6,!=1.6.7,>=1.6.2
> >
> > So, we cannot use it on branches that constraint sphinx to an older version,
> >
> > Sorry, can't check this right now from where I am,
> > Andreas
>
> That's a good point. We should give it a try, though. I don't think
> pip's constraints resolver takes version specifiers into account, so we
> should get the older sphinx and the newer theme. If those do happen to
> work together, it should be OK.
>
> If not, we need another solution. We may have to do more work to
> backport the theme change into an older version of the library to
> make it work in the old branches.
The queens and pike backports have merged but ocata filed with[1]
ContextualVersionConflict: (pbr 1.10.0
(/home/zuul/src/git.openstack.org/openstack/requirements/.tox/py27-check-uc/lib/python2.7/site-packages),
Requirement.parse('pbr!=2.1.0,>=2.0.0'), set(['openstackdocstheme']))
So we can't use the rocky release on ocata. I assume we need to do
something to ensure the docs are generated correctly.
Tony.
[1]
http://logs.openstack.org/96/591896/1/check/requirements-tox-py27-check-uc/ff17c54/job-output.txt.gz#_2018-08-15_05_28_25_148515
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On Wed, Aug 15, 2018 at 09:28:51AM +0200, Andreas Jaeger wrote: > openstackdocsstheme has: > sphinx!=1.6.6,!=1.6.7,>=1.6.2 > > So, we cannot use it on branches that constraint sphinx to an older version, > > Sorry, can't check this right now from where I am, Constraints --- origin/master : Sphinx===1.7.6 origin/stable/newton : Sphinx===1.2.3 origin/stable/ocata : Sphinx===1.3.6 origin/stable/pike: Sphinx===1.6.3 origin/stable/queens : Sphinx===1.6.5 Looks ok to me. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote: > Now that https://review.openstack.org/#/c/591671/ has landed, we need > someone to propose the backports of the constraint updates to all of the > existing stable branches. Done: https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements I'm not entirely convinced such a new release will work on older branches but I guess that's what CI is for :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm
On Mon, Aug 13, 2018 at 04:10:30PM -0700, Eric K wrote: > It appears that gabbi<1.42.1 is causing on error with heat tempest > plugin in congress stable/queens dsvm job [1][2][3]. The issue was > addressed in heat tempest plugin [4], but the problem remains for > stable/queens jobs because the queens upper-constraint is still at > 1.40.0 [5]. > > Any suggestions on how to proceed? Thank you! https://review.openstack.org/591561 Should fix it. You can create a no-op test that: Depends-On: https://review.openstack.org/591561 to verify it works. Doing so and reporting the change ID would be really helpful. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release
On Tue, Aug 14, 2018 at 12:11:53AM -0500, Matthew Thode wrote: > Maybe it'd be better to figure out what's using that removed method and > those would need the update? Given we have per-project deps in rocky only those that *need* the exclusion will need to apply it. I think it's fair to accept the U-c bump and block 0.11.0 in global-requirements. Then any project that find they're broken next week can just add the exclusion themselves and move on. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc][election] Timing of the Upcoming Stein TC election
On Thu, Aug 09, 2018 at 05:20:53PM -0400, Doug Hellmann wrote: > Excerpts from Tony Breeds's message of 2018-08-08 14:39:30 +1000: > > Hello all, > > With the PTL elections behind us it's time to start looking at the > > TC election. Our charter[1] says: > > > > The election is held no later than 6 weeks prior to each OpenStack > > Summit (on or before ‘S-6’ week), with elections held open for no less > > than four business days. > > > > Assuming we have the same structure that gives us a timeline of: > > > > Summit is at: 2018-11-13 > > Latest possible completion is at: 2018-10-02 > > Moving back to Tuesday: 2018-10-02 > > TC Election from 2018-09-25T23:45 to 2018-10-02T23:45 > > TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45 > > TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45 > > > > This puts the bulk of the nomination period during the PTG, which is > > sub-optimal as the nominations cause a distraction from the PTG but more > > so because the campaigning will coincide with travel home, and some > > community members take vacation along with the PTG. > > > > So I'd like to bring up the idea of moving the election forward a > > little so that it's actually the campaigning period that overlaps with > > the PTG: > > > > TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45 > > TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45 > > TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45 > > > > This gives us longer campaigning and election periods. > > > > There are some advantages to doing this: > > > > * A panel style Q&A could be held formally or informally ;P > > * There's improved scope for for incoming, outgoing and staying put TC > >members to interact in a high bandwidth way. > > * In personi/private discussions with TC candidates/members. > > > > However it isn't without downsides: > > > > * Election fatigue, We've just had the PTL elections and the UC > > elections are currently running. Less break before the TC elections > > may not be a good thing. > > * TC candidates that can't travel to the PTG could be disadvantaged > > * The campaigning would all happen at the PTG and not on the mailing > > list disadvantaging community members not at the PTG. > > > > So thoughts? > > > > Yours Tony. > > > > [1] https://governance.openstack.org/tc/reference/charter.html > > Who needs to make this decision? The current TC? I believe that the TC delegated that to the Election WG [1] but the governance here is a little gray/fuzzy. So I kinda think that if the TC doesn't object I can propose the patch to the election repo and you (as TC chair) can +/-1 is as you see fit. Is it fair to ask we do that shortly after the next TC office hours? Yours Tony. [1] https://governance.openstack.org/tc/reference/working-groups.html signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][tc][election] Timing of the Upcoming Stein TC election
Hello all, With the PTL elections behind us it's time to start looking at the TC election. Our charter[1] says: The election is held no later than 6 weeks prior to each OpenStack Summit (on or before ‘S-6’ week), with elections held open for no less than four business days. Assuming we have the same structure that gives us a timeline of: Summit is at: 2018-11-13 Latest possible completion is at: 2018-10-02 Moving back to Tuesday: 2018-10-02 TC Election from 2018-09-25T23:45 to 2018-10-02T23:45 TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45 TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45 This puts the bulk of the nomination period during the PTG, which is sub-optimal as the nominations cause a distraction from the PTG but more so because the campaigning will coincide with travel home, and some community members take vacation along with the PTG. So I'd like to bring up the idea of moving the election forward a little so that it's actually the campaigning period that overlaps with the PTG: TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45 TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45 TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45 This gives us longer campaigning and election periods. There are some advantages to doing this: * A panel style Q&A could be held formally or informally ;P * There's improved scope for for incoming, outgoing and staying put TC members to interact in a high bandwidth way. * In personi/private discussions with TC candidates/members. However it isn't without downsides: * Election fatigue, We've just had the PTL elections and the UC elections are currently running. Less break before the TC elections may not be a good thing. * TC candidates that can't travel to the PTG could be disadvantaged * The campaigning would all happen at the PTG and not on the mailing list disadvantaging community members not at the PTG. So thoughts? Yours Tony. [1] https://governance.openstack.org/tc/reference/charter.html signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results
Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Adrian Turjak * Barbican : Ade Lee * Blazar: Pierre Riteau * Chef OpenStack: Samuel Cassiba * Cinder: Jay Bryant * Cloudkitty: Luka Peschke * Congress : Eric Kao * Cyborg: Li Liu * Designate : Graham Hayes * Documentation : Petr Kovar * Dragonflow: [1] * Ec2 Api : Andrey Pavlov * Freezer : [1] * Glance: Erno Kuvaja * Heat : Rico Lin * Horizon : Ivan Kolodyazhny * I18n : Frank Kloeker * Infrastructure: Clark Boylan * Ironic: Julia Kreger * Karbor: Pengju Jiao * Keystone : Lance Bragstad * Kolla : Eduardo Gonzalez Gutierrez * Kuryr : Daniel Mellado * Loci : [1] * Magnum: Spyros Trigazis * Manila: Thomas Barron * Masakari : Sampath Priyankara * Mistral : Dougal Matthews * Monasca : Witek Bedyk * Murano: Rong Zhu * Neutron : Miguel Lavalle * Nova : Melanie Witt * Octavia : Michael Johnson * OpenStackAnsible : Mohammed Naser * OpenStackClient : Dean Troyer * OpenStackSDK : Monty Taylor * OpenStack Charms : Frode Nordahl * OpenStack Helm: Pete Birley * Oslo : Ben Nemec * Packaging Rpm : [1] * PowerVMStackers : Matthew Edmonds * Puppet OpenStack : Tobias Urdin * Qinling : Lingxian Kong * Quality Assurance : Ghanshyam Mann * Rally : Andrey Kurilin * RefStack : [1] * Release Management: Sean McGinnis * Requirements : Matthew Thode * Sahara: Telles Nobrega * Searchlight : [1] * Security : [1] * Senlin: Duc Truong * Solum : Rong Zhu * Storlets : Kota Tsuyuzaki * Swift : John Dickinson * Tacker: dharmendra kushwaha * Telemetry : Julien Danjou * Tricircle : baisen song * Tripleo : Juan Osorio Robles * Trove : [1] * Vitrage : Ifat Afek * Watcher : Alexander Chadin * Winstackers : [1] * Zaqar : wang hao * Zun : Wei Ji Elections: * Senlin: http://civs.cs.
Re: [openstack-dev] [tripleo] EOL process for newton branches
On Tue, Aug 07, 2018 at 02:34:45PM +1000, Tony Breeds wrote: > On Mon, Aug 06, 2018 at 07:27:37PM +0200, Andreas Jaeger wrote: > > Tony, > > > > On 2018-07-19 06:59, Tony Breeds wrote: > > > On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote: > > > > Option 2, EOL everything. > > > > Thanks a lot for your help on this one, Tony. > > > > > > No problem. > > > > > > I've created: > > > https://review.openstack.org/583856 > > > to tag final releases for tripleo deliverables and then mark them as > > > EOL. > > > > This one has merged now. > > Thanks. > > > > > > > Once that merges we can arrange for someone, with appropriate > > > permissions to run: > > > > > > # EOL repos belonging to tripleo > > > eol_branch.sh -- stable/newton newton-eol \ > > > openstack/instack openstack/instack-undercloud \ > > > openstack/os-apply-config openstack/os-collect-config \ > > > openstack/os-net-config openstack/os-refresh-config \ > > > openstack/puppet-tripleo openstack/python-tripleoclient > > > \ > > > openstack/tripleo-common > > > openstack/tripleo-heat-templates \ > > > openstack/tripleo-image-elements \ > > > openstack/tripleo-puppet-elements openstack/tripleo-ui \ > > > openstack/tripleo-validations > > > > Tony, will you coordinate with infra to run this yourself again - or let > > them run it for you, please? > > I'm happy with either option. If it hasn't been run when I get online > tomorrow I'll ask on #openstack-infra and I'll do it myself. Okay Ian gave me permission to do this. Those repos have been tagged newton-eol and had the branches deleted. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] EOL process for newton branches
On Mon, Aug 06, 2018 at 07:27:37PM +0200, Andreas Jaeger wrote: > Tony, > > On 2018-07-19 06:59, Tony Breeds wrote: > > On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote: > > > Option 2, EOL everything. > > > Thanks a lot for your help on this one, Tony. > > > > No problem. > > > > I've created: > > https://review.openstack.org/583856 > > to tag final releases for tripleo deliverables and then mark them as > > EOL. > > This one has merged now. Thanks. > > > > Once that merges we can arrange for someone, with appropriate > > permissions to run: > > > > # EOL repos belonging to tripleo > > eol_branch.sh -- stable/newton newton-eol \ > > openstack/instack openstack/instack-undercloud \ > > openstack/os-apply-config openstack/os-collect-config \ > > openstack/os-net-config openstack/os-refresh-config \ > > openstack/puppet-tripleo openstack/python-tripleoclient \ > > openstack/tripleo-common openstack/tripleo-heat-templates > > \ > > openstack/tripleo-image-elements \ > > openstack/tripleo-puppet-elements openstack/tripleo-ui \ > > openstack/tripleo-validations > > Tony, will you coordinate with infra to run this yourself again - or let > them run it for you, please? I'm happy with either option. If it hasn't been run when I get online tomorrow I'll ask on #openstack-infra and I'll do it myself. > Note that we removed the script with retiring release-tools repo, I propose > to readd with https://review.openstack.org/589236 and > https://review.openstack.org/589237 and would love your review on these, > please. I want to be sure that we import the right version... Thanks for doing that! LGTM +1 :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][election][senlin][tacker] Last chance to vote
Hello Senlin and Tacker contributors, Just a quick reminder that elections are closing soon, if you haven't already you should use your right to vote and pick your favourite candidate! You have until Aug 07, 2018 23:45 UTC. Thanks for your time! Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [designate][stable] Stable Core Team Updates
On Tue, Jul 31, 2018 at 06:39:36PM +0100, Graham Hayes wrote: > Hi Stable Team, > > I would like to nominate 2 new stable core reviewers for Designate. > > * Erik Olof Gunnar Andersson > * Jens Harbott (frickler) > > Erik has been doing a lot of stable reviews recently, and Jens has shown > that he understands the policy in other reviews (and has stable rights > on other repositories (like DevStack) already). Done. Jens doesn't seem to be doing active stable reviews but I've added them anyway. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][election][tc] Lederless projects.
On Wed, Aug 01, 2018 at 09:55:13AM +1000, Tony Breeds wrote: > > Hello all, > The PTL Nomination period is now over. The official candidate list > is available on the election website[0]. > > There are 8 projects without candidates, so according to this > resolution[1], the TC will have to decide how the following > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm, > RefStack, Searchlight, Trove and Winstackers. Hello TC, A few extra details[1]: --- Projects[1] :65 Projects with candidates :57 ( 87.69%) Projects with election: 2 ( 3.08%) --- Need election : 2 (Senlin Tacker) Need appointment : 8 (Dragonflow Freezer Loci Packaging_Rpm RefStack Searchlight Trove Winstackers) === Stats gathered@ 2018-08-01 00:11:59 UTC Of the 8 projects that can be considered leaderless, Trove did have a candidate[2] that doesn't meet the ATC criteria in that they do not have a merged change. I also excluded Security due to the governance review[3] to remove it as a project and the companion email discussion[4] Yours Tony. [1] http://paste.openstack.org/show/727002 [2] https://review.openstack.org/587333 [3] https://review.openstack.org/586896 [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132595.html signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][election] PTL voting underway
Hi folks, Polls for PTL elections are now open and will remain open for you to cast your vote until Aug 07, 2018 23:45 UTC. We are having elections for Senlin and Tacker. If you are a Foundation individual member and had a commit in one of the program's projects[0] over the Aug 11, 2017 00:00 UTC to Jul 24, 2018 00:00 UTC timeframe (Queens to Rocky) then you are eligible to vote. You should find your email with a link to the Condorcet page to cast your vote in the inbox of your gerrit preferred email[1]. What to do if you don't see the email and have a commit in at least one of the programs having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the program project repos[0] and email the election officials. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: http://governance.openstack.org/election/#stein-ptl-candidates Happy voting, [0] The list of the program projects eligible for electoral status: https://git.openstack.org/cgit/openstack/governance/plain/reference/projects.yaml?id=aug-2018-elections [1] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][election] PTL nominations are now closed
Hello all, The PTL Nomination period is now over. The official candidate list is available on the election website[0]. There are 8 projects without candidates, so according to this resolution[1], the TC will have to decide how the following projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm, RefStack, Searchlight, Trove and Winstackers. There are 2 projects that will have elections: Senlin, Tacker. The details for those will be posted shortly after we setup the CIVS system. Thank you, [0] http://governance.openstack.org/election/#stein-ptl-candidates [1] http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][Election] Last days for PTL nomination
Hello all, A quick reminder that we are in the last hours for PTL candidate nominations. If you want to stand for PTL, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2018-07-24 23:45:00 UTC Nominations end @ 2018-07-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 1 day, 22:12:07 Nominations progress : 72.50% --- Projects[2] :65 Projects with candidates :29 ( 44.62%) Projects with election: 0 ( 0.00%) --- Need election : 0 () Need appointment : 36 (Adjutant Blazar Cinder Designate Documentation Dragonflow Freezer Horizon Ironic Kolla Loci Manila Masakari Monasca Nova Octavia OpenStackAnsible OpenStackClient OpenStack_Helm Oslo Packaging_Rpm Puppet_OpenStack Qinling Rally RefStack Sahara Searchlight Security Solum Storlets Trove Vitrage Watcher Winstackers Zaqar Zun) === Stats gathered@ 2018-07-30 01:32:53 UTC This means that with approximately 2 days left, 39 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy [2] Assuming the open reviews below are validated https://review.openstack.org/#/q/is:open+project:openstack/election Which ATM includes: Magnum Tacker OpenStack_Charms Neutron Manilla Tripleo Barbican Murano [3] http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc][release][election][adjutant] Welcome Adjutant as an official project!
On Tue, Jul 17, 2018 at 01:52:39PM -0400, Doug Hellmann wrote: > The Adjutant team's application [1] to become an official project > has been approved. Welcome! > > As I said on the review, because it is past the deadline for Rocky > membership, Adjutant will not be considered part of the Rocky > release, but a future release can be part of Stein. > > The team should complete the onboarding process for new projects, > including holding PTL elections for Stein, Now would be a good time to do this :) See: https://governance.openstack.org/election/#how-to-submit-a-candidacy for details Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Fast-track: Remove Stable branch maintenance as a project team
On Thu, Jul 26, 2018 at 10:54:52PM -0500, Matt Riedemann wrote: > On 7/26/2018 4:37 PM, Sean McGinnis wrote: > > I'd be curious to hear more about why you don't think that tag is > > maintained. > > Are projects actively applying for the tag? > > > > > For projects that assert they follow stable policy, in the relase process we > > have extra scrutiny that nothing is being released on stable branches that > > would appear to violate the stable policy. > > Is this automated somehow and takes the tag specifically into account, e.g. > some kind of validation that for projects with the tag, a release on a > stable branch doesn't have something like "blueprint" in the commit message? > Or is that just manual code review of the change log? Manual review of the changelog. For project that assert the tag the list-changes job prints a big banner to get the attention of the release managers[1]. Those reviews need a +2 from me (or Alan) *and* a +2 from a release manager. I look at the commit messages and where thing look 'interesting' I go do code reviews on the backport changes. It isn't ideal but IMO it's far from unmaintained. If you had ideas on automation we could put in place to make this more robust, without getting in the way I'm all ears[2] Yours Tony. [1] http://logs.openstack.org/42/586242/1/check/releases-tox-list-changes/af61e24/job-output.txt.gz#_2018-07-26_15_30_07_144206 [2] Well not literally but I am listening ;P signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Fast-track: Remove Stable branch maintenance as a project team
On Thu, Jul 26, 2018 at 11:42:01AM -0500, Matt Riedemann wrote: > On 7/25/2018 3:07 PM, Mohammed Naser wrote: > > Hi everyone: > > > > This email is just to notify everyone on the TC and the community that > > the change to remove the stable branch maintenance as a project > > team[1] has been fast-tracked[2]. > > > > The change should be approved on 2018-07-28 however it is beneficial > > to remove the stable branch team (which has been moved into a SIG) in > > order for `tonyb` to be able to act as an election official. > > > > There seems to be no opposing votes however a revert is always > > available if any members of the TC are opposed to the change[3]. > > > > Thanks to Tony for all of his help in the elections. > > > > Regards, > > Mohammed > > > > [1]:https://review.openstack.org/#/c/584206/ > > [2]:https://governance.openstack.org/tc/reference/house-rules.html#other-project-team-updates > > [3]:https://governance.openstack.org/tc/reference/house-rules.html#rolling-back-fast-tracked-changes > > First time I've heard of it... http://lists.openstack.org/pipermail/openstack-dev/2018-July/132369.html > but thanks. I personally don't think calling > something a SIG magically makes people appear to help out, like creating a > stable maintenance official project team and PTL didn't really grow a > contributor base either, but so it goes. I'm not expecting magic to happen but, I think a SIG is a better fit. Since Dublin we've had Elod Illes appear and do good things so perhaps there is hope[1]! > Only question I have is will the stable:follows-policy governance tag [1] > also be removed? That wasn't on the cards, it's still the same gerrit group that is expected to approve (or not) new applications. Yours Tony. [1] Hope is not a strategy signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][meta] Proposing Retiring the Stable Branch project
On Fri, Jul 20, 2018 at 01:05:26PM +1000, Tony Breeds wrote: > > Hello folks, > So really the subject says it all. I fell like at the time we > created the Stable branch project team that was the only option. Since > then we have crated the SIG structure and in my opinion that's a better > fit. We've also transition from 'Stable Branch Maintenance' to > 'Extended Maintenance' > > Being a SIG will make it explicit that we *need* operator, user and > developer contributions. I meant to say I've created: https://review.openstack.org/584205 and https://review.openstack.org/584206 To make this transition. Thoughts? Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable][meta] Proposing Retiring the Stable Branch project
team and Opening the Extended Maintenance SIG Reply-To: Hello folks, So really the subject says it all. I fell like at the time we created the Stable branch project team that was the only option. Since then we have crated the SIG structure and in my opinion that's a better fit. We've also transition from 'Stable Branch Maintenance' to 'Extended Maintenance' Being a SIG will make it explicit that we *need* operator, user and developer contributions. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] EOL process for newton branches
On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote: > Option 2, EOL everything. > Thanks a lot for your help on this one, Tony. No problem. I've created: https://review.openstack.org/583856 to tag final releases for tripleo deliverables and then mark them as EOL. Once that merges we can arrange for someone, with appropriate permissions to run: # EOL repos belonging to tripleo eol_branch.sh -- stable/newton newton-eol \ openstack/instack openstack/instack-undercloud \ openstack/os-apply-config openstack/os-collect-config \ openstack/os-net-config openstack/os-refresh-config \ openstack/puppet-tripleo openstack/python-tripleoclient \ openstack/tripleo-common openstack/tripleo-heat-templates \ openstack/tripleo-image-elements \ openstack/tripleo-puppet-elements openstack/tripleo-ui \ openstack/tripleo-validations Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] EOL process for newton branches
Hi All, As of I3671f10d5a2fef0e91510a40835de962637f16e5 we have meta-data in openstack/releases that tells us that the following repos are at newton-eol: - openstack/instack-undercloud - openstack/os-net-config - openstack/puppet-tripleo - openstack/tripleo-common - openstack/tripleo-heat-templates I was setting up the request to create the tags and delete those branches but I noticed that the following repos have newton branches and are not in the list above: - openstack/instack - openstack/os-apply-config - openstack/os-collect-config - openstack/os-refresh-config - openstack/python-tripleoclient - openstack/tripleo-image-elements - openstack/tripleo-puppet-elements - openstack/tripleo-ui - openstack/tripleo-validations So I guess there are a couple of options here: 1) Just EOL the 5 repos that opensatck/releases knows are at EOL 2) EOL the repos from both lists ad update openstack/releases to flag them as such I feel like option 2 is the correct option but perhaps there is a reason those repos where not tagged and released Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Rocky blueprints
On Fri, Jul 13, 2018 at 10:12:04AM +1000, Tony Breeds wrote: > On Wed, Jul 11, 2018 at 10:39:30AM -0600, Alex Schultz wrote: > > Currently open with pending patches (may need FFE): > > - https://blueprints.launchpad.net/tripleo/+spec/multiarch-support > > I'd like an FFE for this, the open reviews are in pretty good shape and > mostly merged. (or +W'd). > > We'll need another tripleo-common release after > https://review.openstack.org/537768 merges which I'd really like to do > next week if possible. Upon reflection I've -W'd some of the changes for this blueprint until Stein. The 5 left are: https://review.openstack.org/#/q/topic:bp/multiarch-support+is:open+label:Workflow%253E-1 Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Rocky blueprints
On Wed, Jul 11, 2018 at 10:39:30AM -0600, Alex Schultz wrote: > Currently open with pending patches (may need FFE): > - https://blueprints.launchpad.net/tripleo/+spec/multiarch-support I'd like an FFE for this, the open reviews are in pretty good shape and mostly merged. (or +W'd). We'll need another tripleo-common release after https://review.openstack.org/537768 merges which I'd really like to do next week if possible. There is some cleanup that can be done but nothing that's *needed* for rocky. After that there is still a validation that I need to write, and docs to update. I appreciate the help and support I've had from the TripleO community to get to this point. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:31:34AM -0500, Monty Taylor wrote: > there is also > > https://review.openstack.org/#/c/580730/ > > which adds a role to install docker and configure it to use the correct > registry. shiny! That'll take care of all the docker setup nice! Can I create a job that Depends-On that one and see what happens when I try to build/run containers? /me suspects so but sometimes I like to check :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:05:09AM -0500, Matthew Thode wrote: > I'm of the opinion that we should decouple from distro supported python > versions and rely on what versions upstream python supports (longer > lifetimes than our releases iirc). Using docker/pyenv does this decoupling but I'm not convinced that any option really means that we dont' end up running something that's EOL somewhere. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 11:31:34AM -0500, Monty Taylor wrote: > FWIW, I use pyenv for python versions on my laptop and love it. I've > completely given up on distro-provided python for my own usage. Hmm okay I'll look at that and how it'd play with the generate job. It's quite possible I'm being short sighted but I'd really like to *not* have to build anything. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 01:52:56PM +, Jeremy Stanley wrote: > On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: > [...] > > I think most of the problems with Fedora stability are around > > bringing up a new Fedora every 6 months or so. They tend to change > > sufficiently within that time period to make this a fairly > > involved exercise. But once working they work for the ~13 months > > of support they offer. I know Paul Belanger would like to iterate > > more quickly and just keep the most recent Fedora available > > (rather than ~2). > [...] > > Regardless its instability/churn makes it unsuitable for stable > branch jobs because the support lifetime of the distro release is > shorter than the maintenance lifetime of our stable branches. Would > probably be fine for master branch jobs but not beyond, right? Yup we only run the generate job on master, once we branch it's up to poeple to update/review the lists. So I'd hope that we'd have f28 and f29 overlap and roll forward as needed/able Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][infra] Maintaining constraints for several python versions
On Thu, Jul 12, 2018 at 06:37:52AM -0700, Clark Boylan wrote: > On Wed, Jul 11, 2018, at 9:34 PM, Tony Breeds wrote: > > 1. Build pythons from source and use that to construct the venv > >[please no] > > Fungi mentions that 3.3 and 3.4 don't build easily on modern linux distros. > However, 3.3 and 3.4 are also unsupported by Python at this point, maybe we > can ignore them and focus on 3.5 and forward? We don't build new freeze lists > for the stable branches, this is just a concern for master right? The focus is master, but it came up in the context of shoudl we just remove the python_version=='3.4', it turns out that at least one OS that will supported rock will be running with python 3.4 so while 3.4 is EOL I have to admit I'd quite like to be able to keep the 3.4 stuff around for rocky (and probably stein). It isn't a hard requirement. > > 2. Generate the constraints in an F28 image. My F28 has ample python > >versions: > > - /usr/bin/python2.6 > > - /usr/bin/python2.7 > > - /usr/bin/python3.3 > > - /usr/bin/python3.4 > > - /usr/bin/python3.5 > > - /usr/bin/python3.6 > > - /usr/bin/python3.7 > >I don't know how valid this still is but in the past fedora images > >have been seen as unstable and hard to keep current. If that isn't > >still the feeling then we could go down this path. Currently there a > >few minor problems with bindep.txt on fedora and generate-constraints > >doesn't work with py3 but these are pretty minor really. > > I think most of the problems with Fedora stability are around bringing up a > new Fedora every 6 months or so. They tend to change sufficiently within that > time period to make this a fairly involved exercise. But once working they > work for the ~13 months of support they offer. I know Paul Belanger would > like to iterate more quickly and just keep the most recent Fedora available > (rather than ~2). Ok that's good context. It isn't that once the images are built they break it that they're hardish to build in the first place. I'd love to think that between Paul, Ian and I we'd be okay here but then again I don't really know what I'm saying ;P > > 3. Use docker images for python and generate the constraints with > >them. I've hacked up something we could use as a base for that in: > > https://review.openstack.org/581948 > > > >There are lots of open questions: > > - How do we make this nodepool/cloud provider friendly ? > >* Currently the containers just talk to the main debian mirrors. > > Do we have debian packages? If so we could just do sed magic. > > http://$MIRROR/debian (http://mirror.dfw.rax.openstack.org/debian for > example) should be a working amd64 debian package mirror. \o/ > > - Do/Can we run a registry per provider? > > We do not, but we do have a caching dockerhub registry proxy in each > region/provider. http://$MIRROR:8081/registry-1.docker if using older docker > and http://$MIRROR:8082 for current docker. This was a compromise between > caching the Internet and reliability. That'll do as long as it's easy to configure or transparent. > > - Can we generate and caches these images and only run pip install -U > >g-r to speed up the build > > Between cached upstream python docker images and prebuilt wheels mirrored in > every cloud provider region I wonder if this will save a significant amount > of time? May be worth starting without this and working from there if it > remains slow. Yeah it may be that I'm over thinking it. For me (locally) it's really slow but perhaps with infrastructure you've mentioned it isn't worth it. Certainly something to look at later if it's a problem. > > - Are we okay with using docker this way? > > Should be fine, particularly if we are consuming the official Python images. Yup that's the plan. I've sent a PR to get some images we'd need built that aren't there today. > > > > > I like #2 the most but I wanted to seek wider feedback. > > I think each proposed option should work as long as we understand the > limitations each presents. #2 should work fine if we have individuals > interested and able to spin up new Fedora images and migrate jobs to that > image after releases happen. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Stable review
On Thu, Jul 12, 2018 at 03:53:22PM +0900, Takashi Yamamoto wrote: > hi, > > queens branch of networking-midonet has had no changes merged since > its creation. > the following commit would tell you how many gate blockers have been > accumulated. > https://review.openstack.org/#/c/572242/ > > it seems the stable team doesn't have a bandwidth to review subprojects > in a timely manner. The project specific stable team is responsible for reviewing those changes. The global stable team will review project specific changes if they're requested to. I'll treat this email as such a request. Please ask a member of neutron-stable-maint[1] to take a look at your review. > i'm afraid that we need some policy changes. No we need more contributors to stable and extended maintenance periods. This is not a new problem, and one we're trying to correct. Yours Tony. [1] https://review.openstack.org/#/admin/groups/539,members signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [requirements][storyboard] Updates between SB and LP
Hi all, The requirements team is only a light user of Launchpad and we're looking at moving to StoryBoard as it looks like for the most part it'll be a better fit. To date the thing that has stopped us doing this is the handling of bugs/stories that are shared between LP and SB. Assume that requirements had migrated to SB, how would be deal with bugs like: https://bugs.launchpad.net/openstack-requirements/+bug/1753969 Is there a, supportable, bi-directional path between SB and LP? I suspect the answer is No. I imagine if we only wanted to get updates from LP reflected in our SB story we could just leave the bug tracker open on LP and run the migration tool "often". Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [requirements][infra] Maintaining constraints for several python versions
Hi Folks, We have a pit of a problem in openstack/requirements and I'd liek to chat about it. Currently when we generate constraints we create a venv for each (system) python supplied on the command line, install all of global-requirements into that venv and capture the pip freeze. Where this falls down is if we want to generate a freeze for python 3.4 and 3.5 we need an image that has both of those. We cheated and just 'clone' them so if python3 is 3.4 we copy the results to 3.5 and vice versa. This kinda worked for a while but it has drawbacks. I can see a few of options: 1. Build pythons from source and use that to construct the venv [please no] 2. Generate the constraints in an F28 image. My F28 has ample python versions: - /usr/bin/python2.6 - /usr/bin/python2.7 - /usr/bin/python3.3 - /usr/bin/python3.4 - /usr/bin/python3.5 - /usr/bin/python3.6 - /usr/bin/python3.7 I don't know how valid this still is but in the past fedora images have been seen as unstable and hard to keep current. If that isn't still the feeling then we could go down this path. Currently there a few minor problems with bindep.txt on fedora and generate-constraints doesn't work with py3 but these are pretty minor really. 3. Use docker images for python and generate the constraints with them. I've hacked up something we could use as a base for that in: https://review.openstack.org/581948 There are lots of open questions: - How do we make this nodepool/cloud provider friendly ? * Currently the containers just talk to the main debian mirrors. Do we have debian packages? If so we could just do sed magic. - Do/Can we run a registry per provider? - Can we generate and caches these images and only run pip install -U g-r to speed up the build - Are we okay with using docker this way? I like #2 the most but I wanted to seek wider feedback. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra][releases] couldn't find xstatic package in pypi after release job is merged
On Mon, Jul 09, 2018 at 04:38:47PM +0900, Xinni Ge wrote: > Hello openstack-infra team, > > I uploaded a patch to add a new release of xstatic-angular-material, and > thanks for your work it was merged several days ago. > Here is the link of the patch. > https://review.openstack.org/#/c/577018/ > > However, I cannot find the correct version in pypi index. It still shows an > initial version as 0.0.0. > https://pypi.org/project/xstatic-angular-material/ > > There was a similar problem before but it seems to be fixed already after > the following patches were merged. > https://review.openstack.org/#/c/559300/ > https://review.openstack.org/#/c/559373/ > > Could you help me with this issue please? Thank you very much. There was a thread about this starting here: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131773.html The tools side of things has been fixed, so if you correct the version in your package and ask for a new release things should work. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches
On Tue, Jun 26, 2018 at 09:03:40AM -0400, Doug Hellmann wrote: > Requirements team, > > At some point in the next few months we're going to want to raise > the constraint on openstackdocstheme in all of the old branches so > we can take advantage of a new feature for showing the supported > status of each version of a project. That feature isn't implemented > yet, but I thought it would be good to discuss in advance the need > to update the dependency and how to do it. > > The theme is released under an independent release model and does > not currently have stable branches. It depends on pbr and dulwich, > both of which should already be in the requirements and constraints > lists (dulwich is a dependency of reno). The only possible gottcha is if openstackdocstheme relies on a feature in any of pbr or dulwich which isn't in the version currently in upper-constratints.txt. If that happens we can easily bump those constraints also. > I think that means the simplest thing to do would be to just update > the constraint for the theme in the stable branches. Does that seem > right? Yup that seems to be all there is to it. Once the release happens the bot will propose the constraints bump on master which someone will need to cherry-pick onto the stable branches. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote: > Keystone is hitting this, too [0]. I attempted the same solution that > Tony posted, but no luck. I've even gone so far as removing every > comment from the module to see if that helps narrow down the problem > area, but sphinx still trips. The output from the error message isn't > very descriptive either. Has anyone else had issues fixing this for > python comments, not just docstrings? > > [0] https://bugs.launchpad.net/keystone/+bug/1778603 I did a little digging for the keystone problem and it's due to a missing ':' in https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820 So the correct way to fix this is to correct that in oauthlib, get it released and use that. I hit additional problems in that enabling -W in oauthlib, to pevent this happening in the future, lead me down a rabbit hole I don't really have cycles to dig out of. Here's a dump of where I got to[1]. Clearly it mixes "fixes" with debugging but it isn't too hard to reproduce and someone that knows more Sphinx will be able to understand the errors better than I can. [1] http://paste.openstack.org/show/724271/ Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint
On Mon, Jun 18, 2018 at 12:03:52PM +1000, Tony Breeds wrote: > Without strong objections I'll do that on (my) Monday 25th June. Done. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
On Wed, Jun 20, 2018 at 08:54:56PM +0900, Takashi Yamamoto wrote: > do you have a plan to submit these changes on gerrit? I didn't but I have now: * https://review.openstack.org/577028 * https://review.openstack.org/577029 Feel free to edit/test as you like. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint
Hello folks, Recently Ivan became the Horizon PTL and as with past PTLs (Hi Rob) isn't a member of the horizon-stable-maint team. Ivan is a member of the Cinder stable team and as such has demonstrated an understanding of the stable policy. Since the Dublin PTG Ivan has been doing consistent high quality reviews on Horizon's stable branches. As such I'm suggesting adding him to the existing stable team. Without strong objections I'll do that on (my) Monday 25th June. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages
On Fri, Jun 15, 2018 at 03:05:51PM -0400, Doug Hellmann wrote: > Excerpts from Jean-Philippe Evrard's message of 2018-06-15 17:37:02 +0200: > > > Not sure it'd help but one option we do is to create aliases based on > > > the title. Though since the PTLs don't have addresses on the openstack > > > domain an alias may not make as much sense, it'd have to be a full > > > account forward. It's useful for centralized spam filtering. > > > > I foresee this: > > 1) We create an alias to PTL email > > 2) PTL think that kind of emails are worth sharing with a team to balance > > work > > 3) We now have a project mailing list > > 4) People stop using openstack-dev lists. > > > > But that's maybe me... > > > > Yeah, setting all of that up feels like it would just be something > else we would have to remember to do every time we have an election. > I'm trying to reduce the number those kinds of tasks we have, so > let's not add a new one. While I'm not sure that JP's scenario would eventuate I am against adding the aliases and adding additional work for the election officials. It's not that this would be terribly hard to automate it just seems like duplication of data/effort whereas the change under review is pretty straight forward. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][stable] Stepping down from core
On Mon, Jun 04, 2018 at 01:31:11PM -0700, Ihar Hrachyshka wrote: > Hi neutrinos and all, > > As some of you've already noticed, the last several months I was > scaling down my involvement in Neutron and, more generally, OpenStack. > I am at a point where I feel confident my disappearance won't disturb > the project, and so I am ready to make it official. > > I am stepping down from all administrative roles I so far accumulated > in Neutron and Stable teams. I shifted my focus to another project, > and so I just removed myself from all relevant admin groups to reflect > the change. > > It was a nice 4.5 year ride for me. I am very happy with what we > achieved in all these years and a bit sad to leave. The community is > the most brilliant and compassionate and dedicated to openness group > of people I was lucky to work with, and I am reminded daily how > awesome it is. > > I am far from leaving the industry, or networking, or the promise of > open source infrastructure, so I am sure we will cross our paths once > in a while with most of you. :) I also plan to hang out in our IRC > channels and make snarky comments, be aware! Thanks for all your help and support with Stable Maintenance. Your input, and snarky comments will be missed! Best of luck with your new adventure! Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][kolla] tagging newton EOL
On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote: > hi stable team, > > Kolla project is ready for Newton EOL. Since kolla-ansible is split from > kolla since ocata cycle, so there is not newton branch in kolla-ansible. > please make following repo EOL > > openstack/kolla Okay I did this today but to be perfectly frank I suspect I've done it wrong. There was already an existing tag for newton-eol pointing at 3.0.3-20'ish so I tagged what was the HEAD of the existing newton branch which was 3.0.0.0rc1-335'ish: About to delete the branch stable/newton from openstack/kolla (rev 40e768ec2a370dc010be773af37e2ce417adda80) I'm not really sure about the history there. I apologise if I've made a mistake. but at least as we have everything in git we can recover the branches and retag if required. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStackAnsible] Tag repos as newton-eol
On Sun, Apr 29, 2018 at 09:36:15AM +0200, Jean-Philippe Evrard wrote: > Hello, > > > I'd like to phase out openstack/openstack-ansible-tests and > > openstack/openstack-ansible later. > > Now that we had the time to bump the roles in openstack-ansible, and > adapt the tests, we can now EOL the rest of newton, i.e.: > openstack/openstack-ansible and openstack/openstack-ansible-tests. > > Thanks for the help again Tony! Done. http://git.openstack.org/cgit/openstack/openstack-ansible/tag/?h=newton-eol http://git.openstack.org/cgit/openstack/openstack-ansible-tests/tag/?h=newton-eol Sorry for the delay. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote: > On 18-05-16 17:07:09, Doug Hellmann wrote: > > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500: > > > Sphinx has breaking changes (yet again) and we need to figure out how to > > > deal with it. I think the fix will be simple for affected projects, but > > > we should probably move forward on this. The error people are getting > > > seems to be 'Field list ends without a blank line; unexpected unindent.' > > > > > > I'd like to keep on 1.7.4 and have the affected projects fix the error > > > so we can move on, but the revert has been proposed (and approved to get > > > gate unbroken for them). https://review.openstack.org/568248 Any > > > advice from the community is welcome. > > > > > > > Is it sphinx, or docutils? > > > > Do you have an example of the error? > > > > From https://bugs.launchpad.net/networking-midonet/+bug/1771092 > > 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error: > 2018-05-13 14:22:06.176967 | ubuntu-xenial | > /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring > of > midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field > list ends without a blank line; unexpected unindent. > Adding something like: (.docs) [tony@thor networking-midonet]$ ( cd ../neutron && git diff ) diff --git a/neutron/db/l3_db.py b/neutron/db/l3_db.py index 33b5d99b1..66794542a 100644 --- a/neutron/db/l3_db.py +++ b/neutron/db/l3_db.py @@ -1091,8 +1091,8 @@ class L3_NAT_dbonly_mixin(l3.RouterPluginBase, :param internal_subnet: The subnet for the fixed-ip. :param external_network_id: The external network for floating-ip. -:raises: ExternalGatewayForFloatingIPNotFound if no suitable router -is found. +:raises: ExternalGatewayForFloatingIPNotFound if no suitable router \ + is found. """ # Find routers(with router_id and interface address) that (.docs) [tony@thor networking-midonet]$ ( cd ../os-vif && git diff ) diff --git a/os_vif/plugin.py b/os_vif/plugin.py index 56566a6..2a437a6 100644 --- a/os_vif/plugin.py +++ b/os_vif/plugin.py @@ -49,10 +49,11 @@ class PluginBase(object): Given a model of a VIF, perform operations to plug the VIF properly. :param vif: `os_vif.objects.vif.VIFBase` object. -:param instance_info: `os_vif.objects.instance_info.InstanceInfo` -object. -:raises `processutils.ProcessExecutionError`. Plugins implementing -this method should let `processutils.ProcessExecutionError` +:param instance_info: `os_vif.objects.instance_info.InstanceInfo` \ + object. + +:raises `processutils.ProcessExecutionError`. Plugins implementing \ +this method should let `processutils.ProcessExecutionError` \ bubble up. """ @@ -63,9 +64,10 @@ class PluginBase(object): :param vif: `os_vif.objects.vif.VIFBase` object. :param instance_info: `os_vif.objects.instance_info.InstanceInfo` -object. -:raises `processutils.ProcessExecutionError`. Plugins implementing -this method should let `processutils.ProcessExecutionError` + object. + +:raises `processutils.ProcessExecutionError`. Plugins implementing \ +this method should let `processutils.ProcessExecutionError` \ bubble up. """ fixes the midonet docs build for me (locally) on sphinx 1.7.4. I'm far from a sphinx expert but the chnages to neutron and os-vif seem correct to me. Perhaps the sphinx parser just got more strict? Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?
On Fri, May 11, 2018 at 08:37:43AM -0400, Julia Kreger wrote: > On Fri, May 11, 2018 at 8:20 AM, Dmitry Tantsur wrote: > > Hi, > [trim] > >> If there are no objections, I'll re-add him next week. > > > > > > I don't remember if we actually can add people to these teams or it has to > > be done by the main stable team. > > > I'm fairly sure I'm the person who deleted him from the group in the > first place :( As such, I think I has the magical powers... maybe > ;) I'm not sure you do have access to do that as the group is owned by stable-main-core. That being said I've re-added Jim. Technically it's nest week now :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Changes to keystone-stable-maint members
On Tue, Apr 24, 2018 at 10:58:06AM -0700, Morgan Fainberg wrote: > Hi, > > I am proposing making some changes to the Keystone Stable Maint team. > A lot of this is cleanup for contributors that have moved on from > OpenStack. For the most part, I've been the only one responsible for > Keystone Stable Maint reviews, and I'm not comfortable being this > bottleneck > > Removals > > Dolph Matthews > Steve Martinelli > Brant Knudson > > Each of these members have left/moved on from OpenStack, or in the > case of Brant, less involved with Keystone (and I believe OpenStack as > a whole). > > Additions > === > Lance Bragstad Done. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] roadmap on containers workflow
On Sun, Apr 15, 2018 at 07:24:58PM -0700, Emilien Macchi wrote: > This patch: https://review.openstack.org/#/c/561377 is deploying Docker and > Docker Registry v2 *before* containers deployment in the docker_steps. > It's using the external_deploy_tasks interface that runs right after the > host_prep_tasks, so still before starting containers. > > It's using the Ansible role that was prototyped on Friday, please take a > look and raise any concern. > Now I would like to investigate how we can run container workflows between > the deployment and docker and containers deployments. This looks pretty good to me and if I understand correctly as it's creating a v2 registry then we'll get manifest list images (for multi-arch) by default which is a massive win for me. Thanks Emilien > -- > Emilien Macchi > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements] uncapping eventlet
On Mon, Apr 09, 2018 at 09:58:28AM -0400, Doug Hellmann wrote: > Now that projects don't have to match the global requirements list > entries exactly we should be able to remove caps from within the > projects and keep caps in the global list for cases like this where we > know we frequently encounter breaking changes in new releases. The > changes to support that were part of > https://review.openstack.org/#/c/555402/ True. I was trying to add context to why we don't always rely on upper-constraints.txt to save us. So yeah we can start working towards removing the caps per project. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed
On Tue, Apr 03, 2018 at 02:05:35PM +0200, Elõd Illés wrote: > Hi, > > These patches probably solve the issue, if someone could review them: > > https://review.openstack.org/#/c/557005/ > > and > > https://review.openstack.org/#/c/557006/ > > Thanks, Thanks for digging into that. I've approved these even though they don't have a +2 from the neutron stable team. They look safe as the only impact tests, unblock the gate and also have +1's from subject matter experts. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements] uncapping eventlet
On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote: > My understanding of our use of upper constraints was that this should > (almost) always be the case for (almost) all dependencies. We should > rely on constraints instead of requirements caps. Capping libs like > pbr or eventlet and any other that is in use globally is incredibly > difficult to work with when you want to uncap it because you have to > coordinate globally. Instead if using constraints you just bump the > constraint and are done. Part of the reason that we have the caps it to prevent the tools that auto-generate the constraints syncs from considering these versions and then depending on the requirements team to strip that from the bot change before committing (assuming it passes CI). Once the work Doug's doing is complete we could consider tweaking the tools to use a different mechanism, but that's only part of the reason for the caps in g-r. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed
On Sat, Mar 31, 2018 at 06:17:41AM +, A mailing list for the OpenStack Stable Branch test reports. wrote: > Build failed. > > - build-openstack-sphinx-docs > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/networking-midonet/stable/pike/build-openstack-sphinx-docs/b20c665/html/ > : SUCCESS in 5m 48s > - openstack-tox-py27 > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/networking-midonet/stable/pike/openstack-tox-py27/75db3fe/ > : FAILURE in 11m 49s I'm not sure what's going on here but as with stable/ocata the networking-midonet periodic-stable jobs have been failing like this for close to a week. Can someone from that team take a look Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [midonet][Openstack-stable-maint] Stable check of openstack/networking-midonet failed
On Sat, Mar 31, 2018 at 06:17:07AM +, A mailing list for the OpenStack Stable Branch test reports. wrote: > Build failed. > > - build-openstack-sphinx-docs > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/networking-midonet/stable/ocata/build-openstack-sphinx-docs/2f351df/html/ > : SUCCESS in 6m 25s > - openstack-tox-py27 > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/networking-midonet/stable/ocata/openstack-tox-py27/c558974/ > : FAILURE in 14m 22s I'm not sure what's going on here but the networking-midonet periodic-stable jobs have been failing like this for close to a week. Can someone from that team take a look Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][stable] No more stable Phases welcome Extended Maintenance
Hi all, At Sydney we started the process of change on the stable branches. Recently we merged a TC resolution[1] to alter the EOL process. The next step is refinining the stable policy itself. I've created a review to do that. I think it covers most of the points from Sydney and Dublin. Please check it out: https://review.openstack.org/#/c/552733/ Yours Tony. [1] https://review.openstack.org/548916 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStackAnsible] Tag repos as newton-eol
On Thu, Mar 15, 2018 at 10:57:58AM +, Jean-Philippe Evrard wrote: > Looks good to me. This has been done now. Thanks for being patient :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] stable/queens: How to configure devstack to use openstacksdk===0.11.3 and os-service-types===1.1.0
On Fri, Mar 16, 2018 at 02:29:51PM +, Kwan, Louie wrote: > In the stable/queens branch, since openstacksdk0.11.3 and > os-service-types1.1.0 are described in openstack's upper-constraints.txt, > > https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L411 > https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L297 > > If I do > > > git clone https://git.openstack.org/openstack-dev/devstack -b stable/queens > > And then stack.sh > > We will see it is using openstacksdk-0.12.0 and os_service_types-1.2.0 Okay that's pretty strange. I can't think of why you'd be getting the master version of upper-constraints.txt from the queens branch. [tony@thor requirements]$ tools/grep-all.sh openstacksdk | grep -E '(master|queens)' origin/master : openstacksdk>=0.11.2 # Apache-2.0 origin/stable/queens : openstacksdk>=0.9.19 # Apache-2.0 origin/master : openstacksdk===0.12.0 origin/stable/queens : openstacksdk===0.11.3 [tony@thor requirements]$ tools/grep-all.sh os-service-types | grep -E '(master|queens)' origin/master : os-service-types>=1.2.0 # Apache-2.0 origin/stable/queens : os-service-types>=1.1.0 # Apache-2.0 origin/master : os-service-types===1.2.0 origin/stable/queens : os-service-types===1.1.0 I quick eyeball of the code doesn't show anything obvious. Can you provide the devstack log somewhere? > Having said that, we need the older version, how to configure devstack to use > openstacksdk===0.11.3 and os-service-types===1.1.0 We can try to work out why you're getting the wrong versions but what error/problem do you see with the version from master? I'd expect some general we need version X of FOO but Y is installed messages. Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
On Wed, Mar 28, 2018 at 03:34:32PM +0100, Graham Hayes wrote: > It is more complex than just "joining that team" if the project follows > stable policy. the stable team have to approve the additions, and do > reject people trying to join them. This is true but when we (I) say no I explain what's required to get $project-stable-maint for the requested people. Which typically boils down to "do the reviews that show they grok the stable policy" and we set a short runway (typically 3 months) It is absolutely that same as joining *any* core team. > I don't want to have a release where > someone has to self approve / ninja approve patches due to cores *not* > having the access rights that they previously had. You can always ping stable-maint-core to avoid that. Looking at recent stable reviews stable-maint-core and releease-managers have been doing a pretty good job there. And as this will happen in July/August there's plenty of time for it to be a non-issue. Yours Tony. [1] https://review.openstack.org/#/admin/groups/101,members [2] https://review.openstack.org/#/admin/groups/1098,members signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
On Mon, Mar 26, 2018 at 03:33:03PM +0200, Thierry Carrez wrote: > Let me know if you have any comment, otherwise we'll start using that > new process for the Rocky cycle (stable/rocky branch). Sounds good to me, Thanks Thierry Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStackAnsible] Tag repos as newton-eol
On Wed, Mar 14, 2018 at 09:40:33PM +, Jean-Philippe Evrard wrote: > Hello folks, > > The list is almost perfect: you can do all of those except > openstack/openstack-ansible-tests. > I'd like to phase out openstack/openstack-ansible-tests and > openstack/openstack-ansible later. Okay excluding the 2 repos above and filtering out projects that don't have newton branches we came down to: # EOL repos belonging to OpenStackAnsible eol_branch.sh -- stable/newton newton-eol \ openstack/ansible-hardening \ openstack/openstack-ansible-apt_package_pinning \ openstack/openstack-ansible-ceph_client \ openstack/openstack-ansible-galera_client \ openstack/openstack-ansible-galera_server \ openstack/openstack-ansible-haproxy_server \ openstack/openstack-ansible-lxc_container_create \ openstack/openstack-ansible-lxc_hosts \ openstack/openstack-ansible-memcached_server \ openstack/openstack-ansible-openstack_hosts \ openstack/openstack-ansible-openstack_openrc \ openstack/openstack-ansible-ops \ openstack/openstack-ansible-os_aodh \ openstack/openstack-ansible-os_ceilometer \ openstack/openstack-ansible-os_cinder \ openstack/openstack-ansible-os_glance \ openstack/openstack-ansible-os_gnocchi \ openstack/openstack-ansible-os_heat \ openstack/openstack-ansible-os_horizon \ openstack/openstack-ansible-os_ironic \ openstack/openstack-ansible-os_keystone \ openstack/openstack-ansible-os_magnum \ openstack/openstack-ansible-os_neutron \ openstack/openstack-ansible-os_nova \ openstack/openstack-ansible-os_rally \ openstack/openstack-ansible-os_sahara \ openstack/openstack-ansible-os_swift \ openstack/openstack-ansible-os_tempest \ openstack/openstack-ansible-pip_install \ openstack/openstack-ansible-plugins \ openstack/openstack-ansible-rabbitmq_server \ openstack/openstack-ansible-repo_build \ openstack/openstack-ansible-repo_server \ openstack/openstack-ansible-rsyslog_client \ openstack/openstack-ansible-rsyslog_server \ openstack/openstack-ansible-security If you confirm I have the list right this time I'll work on this tomorrow Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints
On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> The current version of proposed patches which drops tox_install.sh
> works in our CI. Even if we have neutron>=12.0.0 (queens) or
> horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> config, tox-sibling role ensures to install the latest master of
> neutron/horizon. It is okay in our CI.
>
> On the other hand, this change brings a couple of problems. I think it
> is worth discussed broadly here.
>
> (1) it makes difficult to run tests in local environment
> We have only released version of neutron/horizon on PyPI. It means
> PyPI version (i.e. queens) is installed when we run tox in our local
> development. Most neutron stadium projects and horizon plugins depends
> on the latest master. Test run in local environment will be broken. We
> need to install the latest neutron/horizon manually. This confuses
> most developers. We need to ensure that tox can run successfully in a
> same manner in our CI and local environments.
This is an issue I agree and one we need to think about but it will be
somewhat mitigated for local development by pbr siblings[1]
In the short term, developers can do something like:
for env in pep8,py35,py27 ; do
tox -e $env --notest
.tox/$env/bin/pip install -e /path/to/{horizon,neutron}
tox -e $env
done
Which is far from ideal but gives as a little breathing room to decide
if we need to revert and try again in a while or persist with the plan
as it stands.
pbr siblings wont fix all the issues we have and still makes consumption of
neutron and horizon (and plugins / stadium projects) difficult outside
of test.
> (2) neutron/horizon version in requirements.txt is confusing
> In the cycle-with-milestone model, a new version of neutron/horizon
> will be released only when a release is shipped.
> The code depends on the latest master, but requirements.txt says it
> depends on queens or later. It sounds confusing.
Yes we either need to create a new release-model or switch
neutron/horizon to the cycle-with-intermediary model and encourage
appropriate releases. I'd really like to avoid publishing daily to pypi.
Yours Tony.
[1]
https://review.openstack.org/#/q/status:open+project:openstack-dev/pbr+branch:master+topic:fix-siblings-entrypoints
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStackAnsible] Tag repos as newton-eol
Hi all, JP has asked me to to work with infra to tag the newton branches of the following repos as EOL: openstack/ansible-hardening openstack/openstack-ansible-apt_package_pinning openstack/openstack-ansible-ceph_client openstack/openstack-ansible-galera_client openstack/openstack-ansible-galera_server openstack/openstack-ansible-haproxy_server openstack/openstack-ansible-lxc_container_create openstack/openstack-ansible-lxc_hosts openstack/openstack-ansible-memcached_server openstack/openstack-ansible-nspawn_container_create openstack/openstack-ansible-nspawn_hosts openstack/openstack-ansible-openstack_hosts openstack/openstack-ansible-openstack_openrc openstack/openstack-ansible-os_aodh openstack/openstack-ansible-os_barbican openstack/openstack-ansible-os_ceilometer openstack/openstack-ansible-os_cinder openstack/openstack-ansible-os_designate openstack/openstack-ansible-os_glance openstack/openstack-ansible-os_gnocchi openstack/openstack-ansible-os_heat openstack/openstack-ansible-os_horizon openstack/openstack-ansible-os_ironic openstack/openstack-ansible-os_keystone openstack/openstack-ansible-os_magnum openstack/openstack-ansible-os_molteniron openstack/openstack-ansible-os_neutron openstack/openstack-ansible-os_nova openstack/openstack-ansible-os_octavia openstack/openstack-ansible-os_panko openstack/openstack-ansible-os_rally openstack/openstack-ansible-os_sahara openstack/openstack-ansible-os_swift openstack/openstack-ansible-os_tacker openstack/openstack-ansible-os_tempest openstack/openstack-ansible-os_trove openstack/openstack-ansible-pip_install openstack/openstack-ansible-pip_lock_down openstack/openstack-ansible-plugins openstack/openstack-ansible-rabbitmq_server openstack/openstack-ansible-repo_build openstack/openstack-ansible-repo_server openstack/openstack-ansible-rsyslog_client openstack/openstack-ansible-rsyslog_server openstack/openstack-ansible-security openstack/openstack-ansible-ops openstack/openstack-ansible-os_almanach openstack/openstack-ansible-os_cloudkitty openstack/openstack-ansible-os_congress openstack/openstack-ansible-os_freezer openstack/openstack-ansible-os_karbor openstack/openstack-ansible-os_monasca openstack/openstack-ansible-os_monasca-agent openstack/openstack-ansible-os_monasca-ui openstack/openstack-ansible-os_searchlight openstack/openstack-ansible-os_watcher openstack/openstack-ansible-os_zaqar openstack/openstack-ansible-specs openstack/openstack-ansible-tests I'll process that this week after getting an ACK from JP Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Blueprints for Rocky
On Tue, Mar 13, 2018 at 07:58:48AM -0600, Alex Schultz wrote: > Hey everyone, > > So we currently have 63 blueprints for currently targeted for > Rocky[0]. Please make sure that any blueprints you are interested in > delivering have an assignee set and have been approved. I would like > to have the ones we plan on delivering for Rocky to be updated by > April 3, 2018. Any blueprints that have not been updated will be > moved out to the next cycle after this date. My BP: https://blueprints.launchpad.net/tripleo/+spec/multiarch-support doesn't look like it needs an update but just in case I missed something it's still very much targeted at Rocky-1, and the ball is in my court :) Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
