Re: [openstack-dev] [horizon] how to get horizon related logs to syslog?
Akihiro Motoki writes:
> Hi,
>
> Horizon logging depends on Django configuration which supports full python
> logging [1].
> [1] does not provide enough examples.
> Perhaps [2] will help you (though I haven't tested it).
Based on https://docs.djangoproject.com/en/2.1/topics/logging/ it looks
like it should be possible to have Horizon's settings module disable
Django's logging configuration and call oslo.log to do that
configuration. I wonder if it would make sense to do that, for
consistency with the other services?
Doug
>
> [1] https://docs.djangoproject.com/en/2.0/topics/logging/
> [2]
> https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html
>
> Thanks,
> Akihiro
>
> 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
> viktor.tikka...@nokia.com>:
>
>> Hi!
>>
>> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
>> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>>
>> For example for Heat something similar to this (into file
>> templates/heat.conf.j2):
>>
>> # Syslog usage
>> {% if heat_syslog_enabled %}
>> use_syslog = True
>> syslog_log_facility = LOG_LOCAL3
>> {% else %}
>> log_file = /var/log/heat/heat.log
>> {% endif %}
>>
>> But how to get Horizon related logs to syslog?
>>
>> -V.
>>
>> __
>> 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 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
--
Doug
__
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
Luka Peschke writes: > Hello Doug, > > 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. > > Luka I was mostly concerned with future meetings, so that sounds like a good plan. Thanks! > > Le 2018-11-07 18:43, Doug Hellmann a écrit : >> Luka Peschke writes: >> >>> Hello, >>> >>> I'm making this e-mail to announce that the CloudKitty project will >>> be >>> holding IRC meetings from now on. They will be held in the >>> #cloudkitty >>> channel on Freenode. They should (for now) be held on the first >>> Friday >>> of each month at 15h00 UTC. Of course, the time / frequency can be >>> adapted to what suits the community the best. >>> >>> The first meeting will be an exception to this schedule. It will be >>> held on Friday the 9th of November at 15h00 UTC. Topics for this >>> meeting >>> can be found and proposed at >>> https://etherpad.openstack.org/p/cloudkitty-meeting-topics >>> >>> These meetings were a thing in the project's early days and have >>> slowly >>> stopped, which we really regret. >>> >>> This is part of a larger effort to get more in touch with the >>> community. We would gladly welcome new contributors, and any >>> contribution of any kind (bug report, review, documentation >>> suggestion/update, commit...), is welcome. There are several points >>> which should be tackled in order to ease interactions with the >>> community. These will be detailled and discussed during the first >>> meeting. >>> >>> For those interested in CloudKitty attending the Berlin summit, the >>> Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the >>> onboarding will be held on the 14/11 at 5:10pm in M-Räum 1. >>> >>> Cheers, >>> >>> Luka >>> >>> >>> __ >>> 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 >> >> Thanks, Luka. >> >> Please propose an update to the openstack-infra/irc-meetings >> repository >> to register the meeting info so it shows up on eavesdrop.openstack.org >> and the calendar published there. That will make it easier for other >> folks to find the meeting and keep it on their schedule. -- Doug __ 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
Luka Peschke writes: > Hello, > > I'm making this e-mail to announce that the CloudKitty project will be > holding IRC meetings from now on. They will be held in the #cloudkitty > channel on Freenode. They should (for now) be held on the first Friday > of each month at 15h00 UTC. Of course, the time / frequency can be > adapted to what suits the community the best. > > The first meeting will be an exception to this schedule. It will be > held on Friday the 9th of November at 15h00 UTC. Topics for this meeting > can be found and proposed at > https://etherpad.openstack.org/p/cloudkitty-meeting-topics > > These meetings were a thing in the project's early days and have slowly > stopped, which we really regret. > > This is part of a larger effort to get more in touch with the > community. We would gladly welcome new contributors, and any > contribution of any kind (bug report, review, documentation > suggestion/update, commit...), is welcome. There are several points > which should be tackled in order to ease interactions with the > community. These will be detailled and discussed during the first > meeting. > > For those interested in CloudKitty attending the Berlin summit, the > Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the > onboarding will be held on the 14/11 at 5:10pm in M-Räum 1. > > Cheers, > > Luka > > > __ > 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 Thanks, Luka. Please propose an update to the openstack-infra/irc-meetings repository to register the meeting info so it shows up on eavesdrop.openstack.org and the calendar published there. That will make it easier for other folks to find the meeting and keep it on their schedule. -- Doug __ 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-operators] FIPS Compliance
Joshua Cornutt writes: > On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann wrote: >> >> Joshua Cornutt writes: >> >> > Doug, >> > >> > I have such a list put together (my various installation documents for >> > getting these clouds working in FIPS mode) but it's hardly ready for >> > public consumption. I planned on releasing each bit as a code change >> > and/or bug ticket and letting the community consume it as it figures >> > some of these things out. >> >> It's likely that the overall migration will go better if we all have the >> full context. So I hope you can find some time to publish some of the >> information you've compiled to help with that. >> >> > I agree that some changes may break backwards compatibility (such as >> > Glance's image checksumming), but one approach I think could ease the >> > transition would be the approach I took for SSH key pair >> > fingerprinting (also MD5-based, as is Glance image checksums) found >> > here - https://review.openstack.org/#/c/615460/ . This allows >> > administrators to choose, hopefully at deployment time, the hashing >> > algorithm with the default of being the existing MD5 algorithm. >> >> That certainly seems like it would provide the most compatibility in the >> short term. >> >> That said, I honestly don't know the best approach for us to take. We're >> going to need people who understand the issues around FIPS and the >> issues around maintaining backwards-compatibility to work together to >> create a recommended approach. Perhaps a few of the folks on this thread >> would be interested in forming a team to work on that? >> >> Doug >> > > I'd be interested in that. Good idea I added "FIPS compliance" to the list of community goal ideas in https://etherpad.openstack.org/p/community-goals (see number 35, currently at the bottom of the etherpad). Please add more detail there about what exactly is involved, references, etc. -- whatever you think would be useful to someone learning about what this is. > >> > Another approach would be to make the projects "FIPS aware" where we >> > choose the hashing algorithm based on the system's FIPS-enforcing >> > state. An example of doing so is what I'm proposing for Django >> > (another FIPS-related patch that was needed for OSP 13) - >> > https://github.com/django/django/pull/10605 >> > >> > __ >> > 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 -- Doug __ 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] [python3] Enabling py37 unit tests
Mohammed Naser writes: > On Wed, Nov 7, 2018 at 2:07 PM Dr. Jens Harbott (frickler) > wrote: >> >> 2018-11-07 12:47 GMT+00:00 Mohammed Naser : >> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann wrote: >> >> >> >> Corey Bryant writes: >> >> >> >> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant >> >> > >> >> > wrote: >> >> > >> >> > I'd like to start moving forward with enabling py37 unit tests for a >> >> > subset >> >> > of projects. Rather than putting too much load on infra by enabling 3 x >> >> > py3 >> >> > unit tests for every project, this would just focus on enablement of >> >> > py37 >> >> > unit tests for a subset of projects in the Stein cycle. And just to be >> >> > clear, I would not be disabling any unit tests (such as py35). I'd just >> >> > be >> >> > enabling py37 unit tests. >> >> > >> >> > As some background, this ML thread originally led to updating the >> >> > python3-first governance goal (https://review.openstack.org/#/c/610708/) >> >> > but has now led back to this ML thread for a +1 rather than updating the >> >> > governance goal. >> >> > >> >> > I'd like to get an official +1 here on the ML from parties such as the >> >> > TC >> >> > and infra in particular but anyone else's input would be welcomed too. >> >> > Obviously individual projects would have the right to reject proposed >> >> > changes that enable py37 unit tests. Hopefully they wouldn't, of course, >> >> > but they could individually vote that way. >> >> > >> >> > Thanks, >> >> > Corey >> >> >> >> This seems like a good way to start. It lets us make incremental >> >> progress while we take the time to think about the python version >> >> management question more broadly. We can come back to the other projects >> >> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out. >> > >> > What's the impact on the number of consumption in upstream CI node usage? >> >> I think the relevant metric here will be nodes_used * time_used. >> nodes_used will increase by one, time_used for usual unit test jobs >> seems to be < 10 minutes, so I'd think that the total increase in CI >> usage should be neglegible compared to full tempest or similar jobs >> that take 1-2 hours. > > Indeed it doesn't look too bad: > > http://zuul.openstack.org/builds?job_name=openstack-tox-py35 > > It'll be good to try and aim to transition as quickly as possible to > avoid extra 'wasted' resources in the infrastructure side Right, I think we can live with it for a few weeks. -- Doug __ 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] [python3] Enabling py37 unit tests
Corey Bryant writes: > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant > wrote: > > I'd like to start moving forward with enabling py37 unit tests for a subset > of projects. Rather than putting too much load on infra by enabling 3 x py3 > unit tests for every project, this would just focus on enablement of py37 > unit tests for a subset of projects in the Stein cycle. And just to be > clear, I would not be disabling any unit tests (such as py35). I'd just be > enabling py37 unit tests. > > As some background, this ML thread originally led to updating the > python3-first governance goal (https://review.openstack.org/#/c/610708/) > but has now led back to this ML thread for a +1 rather than updating the > governance goal. > > I'd like to get an official +1 here on the ML from parties such as the TC > and infra in particular but anyone else's input would be welcomed too. > Obviously individual projects would have the right to reject proposed > changes that enable py37 unit tests. Hopefully they wouldn't, of course, > but they could individually vote that way. > > Thanks, > Corey This seems like a good way to start. It lets us make incremental progress while we take the time to think about the python version management question more broadly. We can come back to the other projects to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out. Doug __ 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-operators] FIPS Compliance
Joshua Cornutt writes: > Doug, > > I have such a list put together (my various installation documents for > getting these clouds working in FIPS mode) but it's hardly ready for > public consumption. I planned on releasing each bit as a code change > and/or bug ticket and letting the community consume it as it figures > some of these things out. It's likely that the overall migration will go better if we all have the full context. So I hope you can find some time to publish some of the information you've compiled to help with that. > I agree that some changes may break backwards compatibility (such as > Glance's image checksumming), but one approach I think could ease the > transition would be the approach I took for SSH key pair > fingerprinting (also MD5-based, as is Glance image checksums) found > here - https://review.openstack.org/#/c/615460/ . This allows > administrators to choose, hopefully at deployment time, the hashing > algorithm with the default of being the existing MD5 algorithm. That certainly seems like it would provide the most compatibility in the short term. That said, I honestly don't know the best approach for us to take. We're going to need people who understand the issues around FIPS and the issues around maintaining backwards-compatibility to work together to create a recommended approach. Perhaps a few of the folks on this thread would be interested in forming a team to work on that? Doug > Another approach would be to make the projects "FIPS aware" where we > choose the hashing algorithm based on the system's FIPS-enforcing > state. An example of doing so is what I'm proposing for Django > (another FIPS-related patch that was needed for OSP 13) - > https://github.com/django/django/pull/10605 > > __ > 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 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][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)
Ghanshyam Mann writes: > On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski > wrote > > Hi, > > > > > Wiadomość napisana przez Jeremy Stanley w dniu > 06.11.2018, o godz. 22:25: > > > > > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: > > > [...] > > >> also add jobs like "devstack-xenial" and "tempest-full-xenial" > > >> which projects can use still for some time if their job on Bionic > > >> would be broken now? > > > [...] > > > > > > That opens the door to piecemeal migration, which (as we similarly > > > saw during the Trusty to Xenial switch) will inevitably lead to > > > projects who no longer gate on Xenial being unable to integration > > > test against projects who don't yet support Bionic. At the same > > > time, projects which have switched to Bionic will start merging > > > changes which only work on Bionic without realizing it, so that > > > projects which test on Xenial can't use them. In short, you'll be > > > broken either way. On top of that, you can end up with projects that > > > don't get around to switching completely before release comes, and > > > then they're stuck having to manage a test platform transition on a > > > stable branch. > > > > I understand Your point here but will option 2) from first email lead to > the same issues then? > > seems so. approach 1 is less risky for such integrated testing issues and > requires less work. In approach 1, we can coordinate the base job migration > with project side testing with bionic. > > -gmann I like the approach of updating the devstack jobs to move everything to Bionic at one time because it sounds like it presents less risk of us ending up with something that looks like it works together but doesn't actually because it's tested on a different platform, as well as being less likely to cause us to have to do major porting work in stable branches after the release. We'll need to take the same approach when updating the version of Python 3 used inside of devstack. Doug __ 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-operators] FIPS Compliance
Luke Hinds writes: > On Tue, Nov 6, 2018 at 2:04 PM Julia Kreger > wrote: > >> >> >> On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann >> wrote: >> >>> Sean McGinnis writes: >>> >>> > I'm interested in some feedback from the community, particularly those >>> running >>> > OpenStack deployments, as to whether FIPS compliance [0][1] is >>> something folks >>> > are looking for. >>> [trim] >>> >>> I know we've had some interest in it at different times. I think some of >>> the changes will end up being backwards-incompatible, so we may need a >>> "FIPS-mode" configuration flag for those, but in other places we could >>> just switch hashing algorithms and be fine. >>> >>> I'm not sure if anyone has put together the details of what would be >>> needed to update each project, but this feels like it could be a >>> candidate for a goal for a future cycle once we have that information >>> and can assess the level of effort. >>> >>> Doug >>> >>> >> +1 to a FIPS-mode. I think it would be fair to ask projects, to over the >> course of the next month or three, to evaluate their current standing and >> report what they perceive the effort to be. >> >> I think only then we can really determine if it is the right direction to >> take for a cycle goal. >> >> -Julia >> __ >> 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 >> > > > Understand it's early to be discussing design, but would like to get it on > record that if we can, we should try to use 'Algorithm Agility' rather > then all moving to the next one up and setting to SHA. That way we can > deal with what might seem unfathomable now, happening later (strong cryptos > getting cracked). > __ > 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 Yeah, it feels like we want 1 place to get the right "current" algorithm. Unfortunately, we still need to support those old ones because we need to be able to validate any existing data like stored signatures. Is there already a python library out in the wild that we could use for providing a consistent API for that? If not, perhaps building that is an independent step someone could be working on now. Doug __ 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-operators] FIPS Compliance
Sean McGinnis writes: > I'm interested in some feedback from the community, particularly those running > OpenStack deployments, as to whether FIPS compliance [0][1] is something folks > are looking for. > > I've been seeing small changes starting to be proposed here and there for > things like MD5 usage related to its incompatibility to FIPS mode. But looking > across a wider stripe of our repos, it appears like it would be a wider effort > to be able to get all OpenStack services compatible with FIPS mode. > > This should be a fairly easy thing to test, but before we put in much effort > into updating code and figuring out testing, I'd like to see some input on > whether something like this is needed. > > Thanks for any input on this. > > Sean > > [0] https://en.wikipedia.org/wiki/FIPS_140-2 > [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators I know we've had some interest in it at different times. I think some of the changes will end up being backwards-incompatible, so we may need a "FIPS-mode" configuration flag for those, but in other places we could just switch hashing algorithms and be fine. I'm not sure if anyone has put together the details of what would be needed to update each project, but this feels like it could be a candidate for a goal for a future cycle once we have that information and can assess the level of effort. Doug __ 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] Dropping lazy translation support
Matt Riedemann writes: > On 11/5/2018 1:36 PM, Doug Hellmann wrote: >> I think the lazy stuff was all about the API responses. The log >> translations worked a completely different way. > > Yeah maybe. And if so, I came across this in one of the blueprints: > > https://etherpad.openstack.org/p/disable-lazy-translation > > Which says that because of a critical bug, the lazy translation was > disabled in Havana to be fixed in Icehouse but I don't think that ever > happened before IBM developers dropped it upstream, which is further > justification for nuking this code from the various projects. I agree. Doug __ 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] [tc] Technical Committee status update for 5 November
This is the weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == It has been three weeks since the last update email, in part due to my absence. We have lots of updates this time around. Project updates: * Add os_manila to openstack-ansible: https://review.openstack.org/#/c/608403/ * Add cells charms and interfaces: https://review.openstack.org/#/c/608866/ * Add octavia charm: https://review.openstack.org/#/c/608283/ * Add puppet-crane: https://review.openstack.org/#/c/610015/ * Add openstack-helm images repository: https://review.openstack.org/#/c/611895/ * Add blazar-specs repository: https://review.openstack.org/#/c/612431/ * Add openstack-helm docs repository: https://review.openstack.org/#/c/611896/ * Retire anchor: https://review.openstack.org/#/c/611187/ * Remove Dragonflow from governance: https://review.openstack.org/#/c/613856/ Other updates: * Reword "open source" definition in 4 Opens document to remove language that does not come through clearly when translated: https://review.openstack.org/#/c/613894/ * Support "Train" as a candidate name for the T series: https://review.openstack.org/#/c/611511/ * Update the charter section on TC meetings: https://review.openstack.org/#/c/608751/ == TC Meetings == In order to fulfill our obligations under the OpenStack Foundation bylaws, the TC needs to hold meetings at least once each quarter. We agreed to meet monthly, and to emphasize agenda items that help us move initiatives forward while leaving most of the discussion of those topics to the mailing list. Our first meeting was held on 1 Nov. The agendas for all of our meetings will be sent to the openstack-dev mailing list in advance, and links to the logs and summary will be sent as a follow up after the meeting. * http://lists.openstack.org/pipermail/openstack-dev/2018-November/136220.html The next meeting will be 6 December 1400 UTC in #openstack-tc == Team Liaisons == The TC liaisons to each project team for the Stein series are now assigned. Please contact your liaison if you have any issues the TC can help with, and watch for email from them to check in with your team before the end of this development cycle. * https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams == Sessions at the Forum == Many of us will be meeting in Berlin next week for the OpenStack Summit and Forum. There are several sessions related to project governance or community that may be of interest. * Getting OpenStack Users Involved in the Project: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22813/getting-openstack-users-involved-in-the-project * Community outreach when culture, time zones, and language differ: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22820/community-outreach-when-culture-time-zones-and-language-differ * Wednesday Keynote segment, Community Contributor Recognition & How to Get Started: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22959/community-contributor-recognition-and-how-to-get-started * Expose SIGs and WGs: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22750/expose-sigs-and-wgs * Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, Zuul): https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22815/cross-technical-leadership-session-openstack-kata-starlingx-airship-zuul * "Vision for OpenStack clouds" discussion: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22818/vision-for-openstack-clouds-discussion * Technical Committee Vision Retrospective: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22825/technical-committee-vision-retrospective * T series community goal discussion: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22814/t-series-community-goal-discussion == Ongoing Discussions == We have several governance changes up for review related to deciding how we will manage future Python 3 upgrades (including adding 3.7 and possibly dropping 3.5 during Stein). * Make python 3 testing requirement less specific: https://review.openstack.org/#/c/611010/ * Explicitly declare stein supported runtimes: https://review.openstack.org/#/c/611080/ * Resolution on keeping up with Python 3 releases: https://review.openstack.org/#/c/613145/ == TC member actions/focus/discussions for the coming week(s) == The TC, UC, and leadership of other foundation projects will join the foundation Board for a joint leadership meeting on 12 November. See the wiki for details. * https://wiki.openstack.org/wiki/Governance/Foundation/12Nov2018BoardMeeting == Contacting the TC == The Technical Commi
[openstack-dev] [tc] liaison assignments
TC members, I have updated the liaison assignments to fill in all of the gaps. Please take a moment to review the list [1] so you know your assignments. Next week will be a good opportunity to touch bases with your teams. Doug [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams __ 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] Dropping lazy translation support
Matt Riedemann writes: > This is a follow up to a dev ML email [1] where I noticed that some > implementations of the upgrade-checkers goal were failing because some > projects still use the oslo_i18n.enable_lazy() hook for lazy log message > translation (and maybe API responses?). > > The very old blueprints related to this can be found here [2][3][4]. > > If memory serves me correctly from my time working at IBM on this, this > was needed to: > > 1. Generate logs translated in other languages. > > 2. Return REST API responses if the "Accept-Language" header was used > and a suitable translation existed for that language. > > #1 is a dead horse since I think at least the Ocata summit when we > agreed to no longer translate logs since no one used them. > > #2 is probably something no one knows about. I can't find end-user > documentation about it anywhere. It's not tested and therefore I have no > idea if it actually works anymore. > > I would like to (1) deprecate the oslo_i18n.enable_lazy() function so > new projects don't use it and (2) start removing the enable_lazy() usage > from existing projects like keystone, glance and cinder. > > Are there any users, deployments or vendor distributions that still rely > on this feature? If so, please speak up now. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html > [2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages > [3] https://blueprints.launchpad.net/nova/+spec/i18n-messages > [4] https://blueprints.launchpad.net/nova/+spec/user-locale-api > > -- > > Thanks, > > Matt > > ___ > openstack-sigs mailing list > openstack-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs I think the lazy stuff was all about the API responses. The log translations worked a completely different way. Doug __ 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs
Doug Hellmann writes: > Doug Hellmann writes: > > I asked the owners of the name "heat" to allow us to use it, and they > rejected the request. So, I proposed a change to heat to update the > sdist name to "openstack-heat". > > * https://review.openstack.org/606160 This patch is now passing tests. Please prioritize reviewing it, because it is going to block releases of heat. Doug __ 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] [tc][all][goals] selecting community-wide goals for T development cycle
We will have a session at the forum to discuss the community-wide goals [0] we want to select for the T cycle. That's a long way off, but given the fact that we don't have a PTG between Berlin and Denver, and that we've recently had feedback that we need to have tools finished better before starting, I think we do need to begin the conversation now. The Forum session is on Thursday at 17:10, at the end of the Forum [1]. There's an etherpad up [2] for folks to start offering suggestions. And the etherpad with the archives of past ideas is also still online [3]. Let's use this thread to talk about the Forum session. If you want to propose a specific goal, please start a *new* thread here on openstack-dev so that we can keep all of the discussion clearly separated. Please keep in mind that these goals should apply to most, if not all, projects. Work to integrate 2 services can be managed through the normal feature prioritization processes of the teams involved. I will be moderating the discussion at the Forum, but I am not signing up as a goal champion or to drive the goal selection. If you are interested in helping with either of those things, please let me know. Doug [0] https://governance.openstack.org/tc/goals/index.html [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22814/t-series-community-goal-discussion [2] https://etherpad.openstack.org/p/BER-t-series-goals [3] https://etherpad.openstack.org/p/community-goals __ 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] agenda for TC meeting 1 Nov 1400 UTC
Doug Hellmann writes: > TC members, > > The TC will be meeting on 1 Nov at 1400 UTC in #openstack-tc to discuss > some of our ongoing initiatives. Here is the agenda for this week. > > * meeting procedures > > * discussion of topics for joint leadership meeting at Summit in > Berlin > > * completing TC liaison assignments > ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams > > * documenting chair responsibilities > ** https://etherpad.openstack.org/p/tc-chair-responsibilities > > * reviewing the health-check check list > ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Health_check_list > > * deciding next steps on technical vision statement > ** https://review.openstack.org/592205 > > * deciding next steps on python 3 and distro versions for PTI > ** https://review.openstack.org/610708 Add optional python3.7 unit test > enablement to python3-first > ** https://review.openstack.org/611010 Make Python 3 testing requirement less > specific > ** https://review.openstack.org/611080 Explicitly declare Stein supported > runtimes > ** https://review.openstack.org/613145 Resolution on keeping up with Python 3 > releases > > * reviews needing attention > ** https://review.openstack.org/613268 Indicate relmgt style for each > deliverable > ** https://review.openstack.org/613856 Remove Dragonflow from the official > projects list > > If you have suggestions for topics for the next meeting (6 Dec), please > add them to the wiki at > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions > > Doug > > __ > 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 The logs for this meeting are available now at Minutes: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.txt Log: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.log.html Doug __ 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][infra] Tag of openstack/keystone failed
Jeremy Stanley writes: > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > [...] >> Did I miss any options or issues with this approach? > > https://review.openstack.org/578557 How high of a priority is rolling that feature out? It does seem to eliminate this particular issue (even the edge cases described in the commit message shouldn't affect us based on our typical practices), but until we have one of the two changes in place we're going to have this issue with every release we tag. Doug > > -- > Jeremy Stanley > __ > 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 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] [tc] publishing openstack_governance library to PyPI
TC members, I have a series of patches up for review starting at [1] to create a small library for reading and manipulating the project reference data in the YAML files in the openstack/governance repository. After copying similar code into a 3rd repository that wants to consume it last cycle, I thought I ought to just go ahead and do this properly. The patch in [2] is an example of how the releases repository can take advantage of having a library like this. Please add the series to your review queue. Doug [1] https://review.openstack.org/#/c/614597 [2] https://review.openstack.org/614606 __ 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][infra] Tag of openstack/keystone failed
Doug Hellmann writes:
> z...@openstack.org writes:
>
>> Build failed.
>>
>> - publish-openstack-releasenotes-python3
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
>> : POST_FAILURE in 13m 53s
>> - publish-openstack-releasenotes
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
>> : SUCCESS in 13m 54s
>>
>> ___
>> Release-job-failures mailing list
>> release-job-failu...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> Keystone is configured in stable/queens with the release-notes-jobs
> project template and in master with the release-notes-jobs-python3
> template. This is, AFAICT, exactly what we said should be done. However,
> both of the templates include jobs in the "tag" pipeline, and tags are
> not branch-aware. That means we end up running both versions of the
> release notes publishing jobs when we tag a release, and the results may
> be unpredictable. This problem will affect other projects as well.
>
> I think we have a few options.
>
> 1. Move the job settings out of the source repository into
>project-config, like we do for the release jobs, so that we always
>run the same version in all cases.
>
>This has two downsides.
>
>First, we would have to support the python3 variant even on very old
>stable branches. That shouldn't be a very big concern, though,
>because that job does not install the source for the project or its
>dependencies.
>
>Second, we would have to modify all of the zuul configurations for
>all of our old branches, again. As much as I'm enjoying the jokes
>about how I'm padding my contribution stats this cycle, I don't
>really want to do that.
>
> 2. Make the job itself smart enough to figure out whether to run with
>python 2 or 3.
>
>We could update both jobs to look at some setting in the repo to
>decide which version to use. This feels excessively complicated,
>might still result in having to modify some settings in the stable
>branches, and would mean we would have to customize the shared
>versions of the jobs defined in the zuul-jobs repo.
>
> 3. Modify the python 2 version of the project template
>("release-notes-jobs") to remove the "tag" pipeline settings.
>
>This would let us continue to use the python 2 variant for tests and
>when patches merge, and only use the python 3 job for tags. As with
>option 1, we would have to be sure that the release notes job works
>under python 3 for all repos, but as described above that isn't a big
>concern.
>
> I think we should take option 3, and will be preparing a patch to do
> that shortly.
>
> Did I miss any options or issues with this approach?
>
> Doug
See https://review.openstack.org/614758
Doug
__
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][infra] Tag of openstack/keystone failed
z...@openstack.org writes:
> Build failed.
>
> - publish-openstack-releasenotes-python3
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
> : POST_FAILURE in 13m 53s
> - publish-openstack-releasenotes
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
> : SUCCESS in 13m 54s
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
Keystone is configured in stable/queens with the release-notes-jobs
project template and in master with the release-notes-jobs-python3
template. This is, AFAICT, exactly what we said should be done. However,
both of the templates include jobs in the "tag" pipeline, and tags are
not branch-aware. That means we end up running both versions of the
release notes publishing jobs when we tag a release, and the results may
be unpredictable. This problem will affect other projects as well.
I think we have a few options.
1. Move the job settings out of the source repository into
project-config, like we do for the release jobs, so that we always
run the same version in all cases.
This has two downsides.
First, we would have to support the python3 variant even on very old
stable branches. That shouldn't be a very big concern, though,
because that job does not install the source for the project or its
dependencies.
Second, we would have to modify all of the zuul configurations for
all of our old branches, again. As much as I'm enjoying the jokes
about how I'm padding my contribution stats this cycle, I don't
really want to do that.
2. Make the job itself smart enough to figure out whether to run with
python 2 or 3.
We could update both jobs to look at some setting in the repo to
decide which version to use. This feels excessively complicated,
might still result in having to modify some settings in the stable
branches, and would mean we would have to customize the shared
versions of the jobs defined in the zuul-jobs repo.
3. Modify the python 2 version of the project template
("release-notes-jobs") to remove the "tag" pipeline settings.
This would let us continue to use the python 2 variant for tests and
when patches merge, and only use the python 3 job for tags. As with
option 1, we would have to be sure that the release notes job works
under python 3 for all repos, but as described above that isn't a big
concern.
I think we should take option 3, and will be preparing a patch to do
that shortly.
Did I miss any options or issues with this approach?
Doug
__
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] [goal][python3] week 12 update
This is week 12 of the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html). Observant readers will notice that the last update email was during week 9. I've been out for a couple of weeks, but you've all been busy in that time! == What we learned last week == I'm still working on an upgrade script for heat to allow us to rename it and publish releases. * https://review.openstack.org/#/c/606160/ == Ongoing and Completed Work == We are very very close to finishing the phase of work that updates the tox settings and documentation build jobs. Those documentation updates should be relatively quick to review because they're very minimal patches. Please take a few minutes to look for them and let's try to get them merged before the first milestone. The tox patches may require a bit more work to update pylint and the goal champions could use your help there (see below). +-+--+-+--+-++---++ | Team| tox defaults | Docs| 3.6 unit | Failing | Unreviewed | Total | Champion | +-+--+-+--+-++---++ | adjutant| 1/ 1 | - | + | 0 | 1 | 2 | Doug Hellmann | | barbican| +| 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | blazar | +| + | +| 0 | 0 | 9 | Nguyen Hai | | Chef OpenStack | +| - | - | 0 | 0 | 2 | Doug Hellmann | | cinder | +| + | + | 0 | 0 |11 | Doug Hellmann | | cloudkitty | +| + | + | 0 | 0 | 9 | Doug Hellmann | | congress| +| + | +| 0 | 0 | 9 | Nguyen Hai | | cyborg | +| + | +| 0 | 0 | 7 | Nguyen Hai | | designate | +| + | +| 0 | 0 | 9 | Nguyen Hai | | Documentation | +| + | + | 0 | 0 |10 | Doug Hellmann | | dragonflow | -| + | +| 0 | 0 | 2 | Nguyen Hai | | ec2-api | 2/ 2 | + | +| 2 | 2 | 7 || | freezer | +| + | +| 0 | 0 |11 || | glance | +| + | +| 0 | 0 |10 | Nguyen Hai | | heat| 3/ 8 | + | 1/ 7 | 2 | 0 |21 | Doug Hellmann | | horizon | +| + | +| 0 | 0 |34 | Nguyen Hai | | I18n| +| - | - | 0 | 0 | 1 | Doug Hellmann | | InteropWG | 3/ 4 | + | 1/ 3 | 2 | 2 |10 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 |35 | Doug Hellmann | | karbor | +| + | +| 0 | 0 | 7 | Nguyen Hai | | keystone| +| + | + | 0 | 0 |18 | Doug Hellmann | | kolla | +| + | +| 0 | 0 | 5 || | kuryr | +| + | + | 0 | 0 | 9 | Doug Hellmann | | magnum | 2/ 5 | + | +| 0 | 1 |10 || | manila | +| + | +| 0 | 0 |13 | Goutham Pacha Ravi | | masakari| 2/ 5 | + | -| 0 | 2 | 6 | Nguyen Hai | | mistral | +| + | +| 0 | 0 |13 | Nguyen Hai | | monasca | 1/ 17 | + | + | 1 | 1 |34 | Doug Hellmann | | murano | +| + | +| 0 | 0 |14 || | neutron | 7/ 19 | 1/ 14 | 1/ 13 | 6 | 3 |46 | Doug Hellmann | | nova| +| + | +| 0 | 0 |14 || | octavia | +| + | +| 0 | 0 |12 | Nguyen Hai | | OpenStack Charms| 36/ 73 | - | - | 36 |
Re: [openstack-dev] [tripleo] reducing our upstream CI footprint
Alex Schultz writes: > Hey everyone, > > Based on previous emails around this[0][1], I have proposed a possible > reducing in our usage by switching the scenario001--011 jobs to > non-voting and removing them from the gate[2]. This will reduce the > likelihood of causing gate resets and hopefully allow us to land > corrective patches sooner. In terms of risks, there is a risk that we > might introduce breaking changes in the scenarios because they are > officially non-voting, and we will still be gating promotions on these > scenarios. This means that if they are broken, they will need the > same attention and care to fix them so we should be vigilant when the > jobs are failing. > > The hope is that we can switch these scenarios out with voting > standalone versions in the next few weeks, but until that I think we > should proceed by removing them from the gate. I know this is less > than ideal but as most failures with these jobs in the gate are either > timeouts or unrelated to the changes (or gate queue), they are more of > hindrance than a help at this point. > > Thanks, > -Alex > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html > [2] > https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged) > > __ > 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 This makes a lot of sense as a temporary measure. Thanks for continuing to drive these changes! Doug __ 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] [tc] agenda for TC meeting 1 Nov 1400 UTC
TC members, The TC will be meeting on 1 Nov at 1400 UTC in #openstack-tc to discuss some of our ongoing initiatives. Here is the agenda for this week. * meeting procedures * discussion of topics for joint leadership meeting at Summit in Berlin * completing TC liaison assignments ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams * documenting chair responsibilities ** https://etherpad.openstack.org/p/tc-chair-responsibilities * reviewing the health-check check list ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Health_check_list * deciding next steps on technical vision statement ** https://review.openstack.org/592205 * deciding next steps on python 3 and distro versions for PTI ** https://review.openstack.org/610708 Add optional python3.7 unit test enablement to python3-first ** https://review.openstack.org/611010 Make Python 3 testing requirement less specific ** https://review.openstack.org/611080 Explicitly declare Stein supported runtimes ** https://review.openstack.org/613145 Resolution on keeping up with Python 3 releases * reviews needing attention ** https://review.openstack.org/613268 Indicate relmgt style for each deliverable ** https://review.openstack.org/613856 Remove Dragonflow from the official projects list If you have suggestions for topics for the next meeting (6 Dec), please add them to the wiki at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions Doug __ 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-community] Sharing upstream contribution mentoring result with Korea user group
"Ian Y. Choi" writes: > Hello, > > I got involved organizing & mentoring Korean people for OpenStack > upstream contribution for about last two months, > and would like to share with community members. > > Total nine mentees had started to learn OpenStack, contributed, and > finally survived as volunteers for > 1) developing OpenStack mobile app for better mobile user interfaces > and experiences > (inspired from https://github.com/stackerz/app which worked on Juno > release), and > 2) translating OpenStack official project artifacts including documents, > and Container Whitepaper ( > https://www.openstack.org/containers/leveraging-containers-and-openstack/ ). > > Korea user group organizers (Seongsoo Cho, Taehee Jang, Hocheol Shin, > Sungjin Kang, and Andrew Yongjoon Kong) > all helped to organize total 8 offline meetups + one mini-hackathon and > mentored to attendees. > > The followings are brief summary: > - "OpenStack Controller" Android app is available on Play Store > : > https://play.google.com/store/apps/details?id=openstack.contributhon.com.openstackcontroller > (GitHub: https://github.com/kosslab-kr/openstack-controller ) > > - Most high-priority projects (although it is not during string freeze > period) and documents are > 100% translated into Korean: Horizon, OpenStack-Helm, I18n Guide, > and Container Whitepaper. > > - Total 18,695 words were translated into Korean by four contributors > (confirmed through Zanata API: > https://translate.openstack.org/rest/stats/user/[Zanata > ID]/2018-08-16..2018-10-25 ): > > ++---+-+ > | Zanata ID | Name | Number of words | > ++---+-+ > | ardentpark | Soonyeul Park | 12517 | > ++---+-+ > | bnitech | Dongbim Im | 693 | > ++---+-+ > | csucom | Sungwook Choi | 4397 | > ++---+-+ > | jaeho93 | Jaeho Cho | 1088 | > ++---+-+ > > - The list of projects translated into Korean are described as: > > +-+-+ > | Project | Number of words | > +-+-+ > | api-site | 20 | > +-+-+ > | cinder | 405 | > +-+-+ > | designate-dashboard | 4 | > +-+-+ > | horizon | 3226 | > +-+-+ > | i18n | 434 | > +-+-+ > | ironic | 4 | > +-+-+ > | Leveraging Containers and OpenStack | 5480 | > +-+-+ > | neutron-lbaas-dashboard | 5 | > +-+-+ > | openstack-helm | 8835 | > +-+-+ > | trove-dashboard | 89 | > +-+-+ > | zun-ui | 193 | > +-+-+ > > I would like to really appreciate all co-mentors and participants on > such a big event for promoting OpenStack contribution. > The venue and food were supported by Korea Open Source Software > Development Center ( https://kosslab.kr/ ). > > > With many thanks, > > /Ian > > ___ > Community mailing list > commun...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community This is an excellent success story, Ian, thank you for sharing it and for leading the effort. Doug __ 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
Zane Bitter writes: > On 19/10/18 11:17 AM, Zane Bitter wrote: >> I'd like to propose that we handle this by setting up a unit test >> template in openstack-zuul-jobs for each release. So for Stein we'd have >> openstack-python3-stein-jobs. This template would contain: >> >> * A voting gate job for the highest minor version of py3 we want to >> support in that release. >> * A voting gate job for the lowest minor version of py3 we want to >> support in that release. >> * A periodic job for any interim minor releases. >> * (Starting late in the cycle) a non-voting check job for the highest >> minor version of py3 we want to support in the *next* release (if >> different), on the master branch only. >> >> So, for example, (and this is still under active debate) for Stein we >> might have gating jobs for py35 and py37, with a periodic job for py36. >> The T jobs might only have voting py36 and py37 jobs, but late in the T >> cycle we might add a non-voting py38 job on master so that people who >> haven't switched to the U template yet can see what, if anything, >> they'll need to fix. > > Just to make it easier to visualise, here is an example for how the Zuul > config _might_ look now if we had adopted this proposal during Rocky: > > https://review.openstack.org/611947 > > And instead of having a project-wide goal in Stein to add > `openstack-python36-jobs` to the list that currently includes > `openstack-python35-jobs` in each project's Zuul config[1], we'd have > had a goal to change `openstack-python3-rocky-jobs` to > `openstack-python3-stein-jobs` in each project's Zuul config. If we set up the template before we branch stein for T, we could generate a patch as part of the branching process. Doug > > - ZB > > > [1] > https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs > > __ > 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 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] linter jobs testing packaging data
Earlier today I learned that we have a few repositories with linter jobs failing (or at least reporting warnings) because they are running "python setup.py check" to test that the packaging meta-data is OK. This method of testing has been deprecated in favor of using the command "twine check", which requires a bit of extra setup but performs multiple checks on the built packages. Luckily, test-release-openstack-python3 job already runs "twine check". Since it is part of the publish-to-pypi-python3 template, any python-based projects that are releasing using the new job template (which should be all official projects now) have test-release-openstack-python3 configured to run when any files related to packaging are modified. Therefore, rather than updating the failing linter jobs to perform the steps necessary to run twine, teams should simply remove the check and allow the existing test job to perform that check. In addition to avoiding redundancy, this means we will be able update the job in one place instead of having to touch every repo when twine inevitably changes in the future. Sean is working on a set of patches to fix up some of the repos that have issues, so please approve those quickly when they come in. Doug __ 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] [goals][upgrade-checkers] [telemetry] Upgrade checks for telemetry services
AKHIL Jain writes: > Hi Matt and Telemetry Team, > > I was going through the remaining project to be implemented with > upgrade-checkers placeholder framework. I would like to know about the > projects to implement the same under telemetry tab. > > According to my understanding from below link, multiple projects come under > telemetry: > https://wiki.openstack.org/wiki/Telemetry#Managed > > Aodh being alarming service triggers alarm when collected data breaks over > set rules. Also, Aodh work as a standalone project using any > backend(ceilometer, gnocchi. etc.): > So there are expected changes b/w releases. > > Ceilometer being data collection service(that helps in customer billing, > resource tracking, and alarming): As this service is involved in data pooling > from other projects. So there can be chances to perform upgrade checks. > > Panko being indexing service, that provides the ability to store and query > event data. Related changes to indexing objects can be checked while upgrading > > So, should we add upgrade-check command in each project or single command > upgrade-checks should be there to tell each service upgrade status? > > Thanks, > Akhil > __ > 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 Each of those services has its own configuration file and database, and the code is in separate repositories, so it seems like we would want a separate upgrade check command for each one. Doug __ 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] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
Monty Taylor writes: > On 10/29/18 10:47 AM, Doug Hellmann wrote: >> Monty Taylor writes: >> >>> Heya, >>> >>> Tobias and I were chatting at OpenStack Days Nordic about the Public >>> Cloud Working Group potentially taking over as custodians of the vendor >>> profile information [0][1] we keep in openstacksdk (and previously in >>> os-client-config) >>> >>> I think this is a fine idea, but we've got some dancing to do I think. >>> >>> A few years ago Dean and I talked about splitting the vendor data into >>> its own repo. We decided not to at the time because it seemed like extra >>> unnecessary complication. But I think we may have reached that time. >>> >>> We should split out a new repo to hold the vendor data json files. We >>> can manage this repo pretty much how we manage the >>> service-types-authority [2] data now. Also similar to that (and similar >>> to tzdata) these are files that contain information that is true >>> currently and is not release specific - so it should be possible to >>> update to the latest vendor files without updating to the latest >>> openstacksdk. >>> >>> If nobody objects, I'll start working through getting a couple of new >>> repos created. I'm thinking openstack/vendor-profile-data, owned/managed >>> by Public Cloud WG, with the json files, docs, json schema, etc, and a >>> second one, openstack/os-vendor-profiles - owned/managed by the >>> openstacksdk team that's just like os-service-types [3] and is a >>> tiny/thin library that exposes the files to python (so there's something >>> to depend on) and gets proposed patches from zuul when new content is >>> landed in openstack/vendor-profile-data. >>> >>> How's that sound? >> >> I understand the benefit of separating the data files from the SDK, but >> what is the benefit of separating the data files from the code that >> reads them? > > I'd say primarily so that the same data files can be used from other > languages. (similar to having the service-types-authority data exist > separate from the python library that consumes it.) > > Also - there is a separation of concerns, potentially. The review team > for a vendor-data repo could just be public cloud sig folks - and what > they are reviewing is the accuracy of the data. The python code to > consume that and interpret it is likely a different set of humans. The argument about languages is more convincing but I'll accept both answers. The plan makes sense to me, now. Doug __ 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] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
Monty Taylor writes: > Heya, > > Tobias and I were chatting at OpenStack Days Nordic about the Public > Cloud Working Group potentially taking over as custodians of the vendor > profile information [0][1] we keep in openstacksdk (and previously in > os-client-config) > > I think this is a fine idea, but we've got some dancing to do I think. > > A few years ago Dean and I talked about splitting the vendor data into > its own repo. We decided not to at the time because it seemed like extra > unnecessary complication. But I think we may have reached that time. > > We should split out a new repo to hold the vendor data json files. We > can manage this repo pretty much how we manage the > service-types-authority [2] data now. Also similar to that (and similar > to tzdata) these are files that contain information that is true > currently and is not release specific - so it should be possible to > update to the latest vendor files without updating to the latest > openstacksdk. > > If nobody objects, I'll start working through getting a couple of new > repos created. I'm thinking openstack/vendor-profile-data, owned/managed > by Public Cloud WG, with the json files, docs, json schema, etc, and a > second one, openstack/os-vendor-profiles - owned/managed by the > openstacksdk team that's just like os-service-types [3] and is a > tiny/thin library that exposes the files to python (so there's something > to depend on) and gets proposed patches from zuul when new content is > landed in openstack/vendor-profile-data. > > How's that sound? I understand the benefit of separating the data files from the SDK, but what is the benefit of separating the data files from the code that reads them? Doug > > Thanks! > Monty > > [0] > http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors > [1] > https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html > [2] http://git.openstack.org/cgit/openstack/service-types-authority > [3] http://git.openstack.org/cgit/openstack/os-service-types > > __ > 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 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] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Sean McGinnis writes: > During the Stein PTG in Denver, the release management team talked about ways > we can make things simpler and reduce the "paper pushing" work that all teams > need to do right now. One topic that came up was the usefulness of pushing > tags > around milestones during the cycle. > > There were a couple of needs identified for doing such "milestone releases": > 1) It tests the release automation machinery to identify problems before >the RC and final release crunch time. > 2) It creates a nice cadence throughout the cycle to help teams stay on >track and focus on the right things for each phase of the cycle. > 3) It gives us an indication that teams are healthy, active, and planning >to include their components in the final release. > > One of the big motivators in the past was also to have output that downstream > distros and users could pick up for testing and early packaging. Based on our > admittedly anecdotal small sample, it doesn't appear this is actually a big > need, so we propose to stop tagging milestone releases for the > cycle-with-milestone projects. One of the issues that was raised from downstream consumers [1] is that this complicates upgrade testing using packages, since tools like yum will think that the stable branch (with a final version tag) has a higher version number than master (with a dev version computed off of the first release candidate where the stable branch was created). We've discussed this problem in the past and not done anything because the downstream folks were always able to live with the gap until the first milestone. Now that we're unlikely to have milestone tags for most projects, the gap will extend to the length of the cycle, blocking upgrade testing until the release candidates are tagged, shortly before we're ready to release. They could guess at the next version numbers, but if they guess wrong they would be left with invalid packages and have to do a bunch of testing work again. It's better for us to provide authoritative information about version changes upstream. We need all projects to increment their version at least by one minor version at the start of each cycle to save space for patch releases on the stable branch, so we looked at a few options for triggering that update automatically. One option is to add a tag, like an alpha. This is somewhat appealing because the release team can just do it without anyone on the project teams having to worry about it. However, I don't particularly like this option for two reasons. First, the release team would have to monitor the work in each project and wait for some patch to land after the fork, so we could tag that (otherwise the branch would get the new version, too). More importantly, the tag would trigger a release, and I don't think we want to publish artifacts just to tweak the version calculation. A similarly low impact solution is to use pbr's Sem-Ver calculation feature and inject patches into master to bump the version being computed by 1 feature level (which should move from x.y.z.0rc1 to somethinglike x.y+1.0.devN). See [2] for details about how this works. This is the approach I prefer, and I have a patch to the branching scripts to add the Sem-Ver instruction to the patches we already generate to update reno [3]. That change should take care of our transition from Stein->T, but we're left with versions in Stein that are lower than Rocky right now. So, as a one time operation, Sean is going to propose empty patches with the Sem-Ver instruction in the commit message to all of the repositories for Stein deliverables that have stable/rocky branches. Let us know if you have any questions. Doug [1] http://lists.openstack.org/pipermail/openstack-operators/2018-October/015991.html [2] https://docs.openstack.org/pbr/latest/user/features.html#version [3] https://review.openstack.org/#/c/609827/ __ 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] [goals][python3] week 9 update
This is week 9 of the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html). == What we learned last week == We have claimed a few names on PyPI, and updated a few sdist names where we couldn't do that. The one remaining project with a rename is heat, and I'm working on an upgrade script that will clean up the old metadata to fix the duplicate plugin issue. * https://review.openstack.org/#/c/606160/ == Ongoing and Completed Work == The zuul migration portion of the goal work is completed! Thanks again to everyone who assisted with creating and reviewing those patches. We still have quite a few patches with tox settings and for documentation build updates left open or unreviewed. Those documentation updates should be relatively quick to review because they're very minimal patches. Please take a few minutes to look for them and let's try to get them merged before the first milestone. The tox patches may require a bit more work to update pylint and the goal champions could use your help there (see below). +-+--+-+--+-++---++ | Team| tox defaults | Docs| 3.6 unit | Failing | Unreviewed | Total | Champion | +-+--+-+--+-++---++ | adjutant| 1/ 1 | - | +| 0 | 1 | 2 | Doug Hellmann | | barbican| +| 1/ 3 | +| 1 | 1 | 7 | Doug Hellmann | | blazar | +| + | +| 0 | 0 | 9 | Nguyen Hai | | Chef OpenStack | +| - | -| 0 | 0 | 2 | Doug Hellmann | | cinder | +| + | +| 0 | 0 |11 | Doug Hellmann | | cloudkitty | +| + | +| 0 | 0 | 9 | Doug Hellmann | | congress| 1/ 3 | + | +| 0 | 0 | 9 | Nguyen Hai | | cyborg | +| + | +| 0 | 0 | 7 | Nguyen Hai | | designate | 2/ 4 | + | +| 0 | 1 | 9 | Nguyen Hai | | Documentation | +| + | +| 0 | 0 |10 | Doug Hellmann | | dragonflow | -| + | +| 0 | 0 | 2 | Nguyen Hai | | ec2-api | 2/ 2 | + | +| 2 | 2 | 7 || | freezer | 1/ 5 | + | +| 0 | 1 |11 || | glance | 1/ 4 | + | +| 0 | 0 |10 | Nguyen Hai | | heat| 3/ 8 | + | 1/ 7 | 0 | 0 |21 | Doug Hellmann | | horizon | 1/ 32 | + | +| 0 | 1 |34 | Nguyen Hai | | I18n| 1/ 1 | - | -| 0 | 0 | 1 | Doug Hellmann | | InteropWG | 3/ 4 | + | 1/ 3 | 1 | 3 |10 | Doug Hellmann | | ironic | 1/ 10 | + | +| 0 | 1 |35 | Doug Hellmann | | karbor | +| + | +| 0 | 0 | 7 | Nguyen Hai | | keystone| +| + | +| 0 | 0 |18 | Doug Hellmann | | kolla | +| + | +| 0 | 0 | 5 || | kuryr | +| + | +| 0 | 0 | 9 | Doug Hellmann | | magnum | 2/ 5 | + | +| 0 | 1 |10 || | manila | 1/ 8 | + | +| 0 | 0 |13 | Goutham Pacha Ravi | | masakari| 3/ 5 | + | -| 0 | 3 | 6 | Nguyen Hai | | mistral | +| + | +| 0 | 0 |13 | Nguyen Hai | | monasca | 1/ 17 | + | +| 1 | 1 |34 | Doug Hellmann | | murano | +| + | +| 0 | 0 |14 || | neutron | 8/ 18 | 2/ 14 | 2/ 13 | 5 | 4 |45 | Doug Hellmann | | nova| +| + | +| 0 | 0 |14 || | octavia | +
Re: [openstack-dev] [tc] assigning new liaisons to projects
Trinh Nguyen writes: > Thank Doug for coordinating this, > > Is there any way for us to update the health of the Searchlight project to > reflect the current state? Right now the status is not good to attract new > contributors. When the new liaisons are assigned, please talk to them about the current status. Doug > > Bests, > > On Fri, Oct 12, 2018 at 6:50 AM Doug Hellmann wrote: > >> Doug Hellmann writes: >> >> > TC members, >> > >> > Since we are starting a new term, and have several new members, we need >> > to decide how we want to rotate the liaisons attached to each our >> > project teams, SIGs, and working groups [1]. >> > >> > Last term we went through a period of volunteer sign-up and then I >> > randomly assigned folks to slots to fill out the roster evenly. During >> > the retrospective we talked a bit about how to ensure we had an >> > objective perspective for each team by not having PTLs sign up for their >> > own teams, but I don't think we settled on that as a hard rule. >> > >> > I think the easiest and fairest (to new members) way to manage the list >> > will be to wipe it and follow the same process we did last time. If you >> > agree, I will update the page this week and we can start collecting >> > volunteers over the next week or so. >> > >> > Doug >> > >> > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker >> > >> > >> __ >> > 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 >> >> I have cleared out the old assignments. Please go over and edit the wiki >> page to add yourself to the teams you want to volunteer for. Remember >> that each member needs to sign up for exactly 10 teams. If you don't >> volunteer for 10, we'll use the script to make random assignments for >> the remaining slots. >> >> Doug >> >> __ >> 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 >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz <https://www.edlab.xyz>* > __ > 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 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] assigning new liaisons to projects
Doug Hellmann writes: > TC members, > > Since we are starting a new term, and have several new members, we need > to decide how we want to rotate the liaisons attached to each our > project teams, SIGs, and working groups [1]. > > Last term we went through a period of volunteer sign-up and then I > randomly assigned folks to slots to fill out the roster evenly. During > the retrospective we talked a bit about how to ensure we had an > objective perspective for each team by not having PTLs sign up for their > own teams, but I don't think we settled on that as a hard rule. > > I think the easiest and fairest (to new members) way to manage the list > will be to wipe it and follow the same process we did last time. If you > agree, I will update the page this week and we can start collecting > volunteers over the next week or so. > > Doug > > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker > > __ > 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 I have cleared out the old assignments. Please go over and edit the wiki page to add yourself to the teams you want to volunteer for. Remember that each member needs to sign up for exactly 10 teams. If you don't volunteer for 10, we'll use the script to make random assignments for the remaining slots. Doug __ 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] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches
Doug Hellmann writes: > We have about 17 remaining patches to import zuul job settings into a > few repositories. Those are mostly in stable branches and the jobs are > failing in ways that may take us a long time to fix. > > Rather than waiting for those, Andreas and I are proposing that we have > someone from the infra team approve them, bypassing the test jobs. That > will allow us to complete the cleanup work in the project-config > repository, and will not leave the affected repositories in a state that > is any more (or less) broken than they are today. > > If you have any objections to the plan, please speak up quickly. I > would like to try to proceed before the end of the week. > > Doug > > +--+-+---++--+-+---+---+ > | Subject | Repo >| Team | Tests | Workflow | URL | > Branch| Owner | > +--+-+---++--+-+---+---+ > | import zuul job settings from project-config | openstack/aodh >| Telemetry | FAILED | NEW | https://review.openstack.org/598648 | > stable/ocata | Doug Hellmann | > | import zuul job settings from project-config | openstack/barbican >| barbican | FAILED | REVIEWED | https://review.openstack.org/599659 | > stable/queens | Doug Hellmann | > | import zuul job settings from project-config | openstack/barbican >| barbican | FAILED | REVIEWED | https://review.openstack.org/599661 | > stable/rocky | Doug Hellmann | > | import zuul job settings from project-config | openstack/castellan-ui > | barbican | FAILED | NEW | https://review.openstack.org/599649 | > master| Doug Hellmann | > | import zuul job settings from project-config | > openstack/ceilometermiddleware | Telemetry | FAILED | APPROVED | > https://review.openstack.org/598634 | master| Doug Hellmann | > | import zuul job settings from project-config | > openstack/ceilometermiddleware | Telemetry | FAILED | APPROVED | > https://review.openstack.org/598655 | stable/pike | Doug Hellmann | > | import zuul job settings from project-config | > openstack/ceilometermiddleware | Telemetry | PASS | NEW | > https://review.openstack.org/598661 | stable/queens | Doug Hellmann | > | import zuul job settings from project-config | > openstack/ceilometermiddleware | Telemetry | FAILED | NEW | > https://review.openstack.org/598667 | stable/rocky | Doug Hellmann | > | import zuul job settings from project-config | openstack/monasca-analytics >| monasca | FAILED | REVIEWED | https://review.openstack.org/595658 | > master| Doug Hellmann | > | import zuul job settings from project-config | openstack/networking-midonet >| neutron | PASS | REVIEWED | https://review.openstack.org/597937 | > stable/queens | Doug Hellmann | > | import zuul job settings from project-config | openstack/networking-sfc >| neutron | FAILED | NEW | https://review.openstack.org/597913 | > stable/ocata | Doug Hellmann | > | import zuul job settings from project-config | openstack/networking-sfc >| neutron | FAILED | NEW | https://review.openstack.org/597925 | > stable/pike | Doug Hellmann | > | import zuul job settings from project-config | openstack/python-aodhclient >| Telemetry | FAILED | NEW | https://review.openstack.org/598652 | > stable/ocata | Doug Hellmann | > | import zuul job settings from project-config | openstack/python-aodhclient >| Telemetry | FAILED | NEW | https://review.openstack.org/598657 | > stable/pike | Doug Hellmann | > | import zuul job settings from project-config | openstack/python-aodhclient >| Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | > stable/rocky | Doug Hellmann | > | import zuul job settings from project-config | > openstack/python-barbicanclient | barbican | FAILED | NEW | > https://review.openstack.org/599656 | stable/ocata | Doug Hellmann | > | import zuul job settings from project-config | > openstack/python-barbicanclient | barbican | FAILED | NEW | > https://review.openstack.org/599658 | stable/pike | Doug Hellmann | > +--+-+---++--+-+---+---+ Clark went ahead and merged
Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Ken Giusti writes: > On Tue, Oct 9, 2018 at 11:56 AM Doug Hellmann wrote: > >> Matthew Thode writes: >> >> > On 18-10-09 11:12:30, Doug Hellmann wrote: >> >> Matthew Thode writes: >> >> >> >> > several projects have had problems with the new release, some have >> ways >> >> > of working around it, and some do not. I'm sending this just to raise >> >> > the issue and allow a place to discuss solutions. >> >> > >> >> > Currently there is a review proposed to blacklist 9.0.0, but if this >> is >> >> > going to still be an issue somehow in further releases we may need >> >> > another solution. >> >> > >> >> > https://review.openstack.org/#/c/608835/ >> >> > >> >> > -- >> >> > Matthew Thode (prometheanfire) >> >> > >> __ >> >> > 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 >> >> >> >> Do you have links to the failure logs or bug reports or something? If I >> >> wanted to help I wouldn't even know where to start. >> >> >> > >> > >> http://logs.openstack.org/21/607521/2/check/cross-cinder-py35/e15722e/testr_results.html.gz >> >> These failures look like we should add a proper API to oslo.messaging to >> set the notification and rpc backends for testing. The configuration >> options are *not* part of the API of the library. >> >> There is already an oslo_messaging.conffixture module with a fixture >> class, but it looks like it defaults to rabbit. Maybe someone wants to >> propose a patch to make that a parameter to the constructor? >> > > oslo.messaging's conffixture uses whatever the config default for > transport_url is unless the test > specifically overrides it by setting the transport_url attribute. > The o.m. unit tests's base test class sets conffixture.transport_url to > "fake:/" to use the fake in memory driver. > That's the existing practice (I believe it's used like that outside of o.m.) OK, so it sounds like the fixture is relying on the configuration to be set up in advance, and that's the thing we need to change. We don't want users outside of the library to set up tests by using the configuration options, right? Doug __ 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Matthew Thode writes: > On 18-10-09 11:12:30, Doug Hellmann wrote: >> Matthew Thode writes: >> >> > several projects have had problems with the new release, some have ways >> > of working around it, and some do not. I'm sending this just to raise >> > the issue and allow a place to discuss solutions. >> > >> > Currently there is a review proposed to blacklist 9.0.0, but if this is >> > going to still be an issue somehow in further releases we may need >> > another solution. >> > >> > https://review.openstack.org/#/c/608835/ >> > >> > -- >> > Matthew Thode (prometheanfire) >> > __ >> > 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 >> >> Do you have links to the failure logs or bug reports or something? If I >> wanted to help I wouldn't even know where to start. >> > > http://logs.openstack.org/21/607521/2/check/cross-cinder-py35/e15722e/testr_results.html.gz These failures look like we should add a proper API to oslo.messaging to set the notification and rpc backends for testing. The configuration options are *not* part of the API of the library. There is already an oslo_messaging.conffixture module with a fixture class, but it looks like it defaults to rabbit. Maybe someone wants to propose a patch to make that a parameter to the constructor? > http://logs.openstack.org/21/607521/2/check/cross-glance-py35/e2161d7/testr_results.html.gz These failures should be fixed by releasing the patch that Mehdi provided that ensures there is a valid default transport configured. > http://logs.openstack.org/21/607521/2/check/cross-keystone-py35/908a1c2/testr_results.html.gz Lance has already described these as mocking implementation details of the library. I expect we'll need someone with keystone experience to work out what the best solution is to do there. > > -- > Matthew Thode (prometheanfire) > __ > 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 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Ben Nemec writes: > On 10/9/18 10:19 AM, Doug Hellmann wrote: >> Brian Rosmaita writes: >> >>> On 10/8/18 11:59 PM, Matthew Thode wrote: >>>> several projects have had problems with the new release, some have ways >>>> of working around it, and some do not. I'm sending this just to raise >>>> the issue and allow a place to discuss solutions. >>>> >>>> Currently there is a review proposed to blacklist 9.0.0, but if this is >>>> going to still be an issue somehow in further releases we may need >>>> another solution. >>>> >>>> https://review.openstack.org/#/c/608835/ >>> >>> As indicated in the commit message on the above patch, 9.0.0 contains a >>> bug that's been fixed in oslo.messaging master, so I don't think there's >>> any question that 9.0.0 has to be blacklisted. >> >> I've proposed releasing oslo.messaging 9.0.1 in >> https://review.openstack.org/609030 > > I also included it in https://review.openstack.org/#/c/609031/ (which I > see you found). Yeah, I abandoned my separate patch to do the same in favor of your omnibus patch. >> If we don't land the constraint update to allow 9.0.1 in, then there's >> no rush to blacklist anything, is there? > > Probably not. We'll want to blacklist it before we allow 9.0.1, but I > suspect this is mostly a test problem since in production the transport > would have to be set explicitly. > >> >>> As far as the timing/content of 9.0.1, however, that may require further >>> discussion. >>> >>> (In other words, I'm saying that when you say 'another solution', my >>> position is that we should take 'another' to mean 'additional', not >>> 'different'.) >> >> I'm not sure what that means. >> >> Doug >> >> __ >> 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 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Lance Bragstad writes: > Keystone is failing because it's missing a fix from oslo.messaging [0]. > That said, keystone is also relying on an internal implementation detail in > oslo.messaging by mocking it in tests [1]. The notification work has been > around in keystone for a *long* time, but it's apparent that we should > revisit these tests to make sure we aren't testing something that is > already tested by oslo.messaging if we're mocking internal implementation > details of a library. > > Regardless, blacklisting version 9.0.0 will work for keystone, but we can > work around it another way by either rewriting the tests to not care about > oslo.messaging specifics, or removing them if they're obsolete. Yeah, we keep running into these sorts of problems when folks mock past the public API boundary of a library, so let's eliminate them as we find them. If there's a way to add a fixture to oslo.messaging to support the tests we can do that, too. Doug > > [0] https://review.openstack.org/#/c/608196/ > [1] > https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/common/test_notifications.py#n1343 > > On Mon, Oct 8, 2018 at 10:59 PM Matthew Thode > wrote: > >> several projects have had problems with the new release, some have ways >> of working around it, and some do not. I'm sending this just to raise >> the issue and allow a place to discuss solutions. >> >> Currently there is a review proposed to blacklist 9.0.0, but if this is >> going to still be an issue somehow in further releases we may need >> another solution. >> >> https://review.openstack.org/#/c/608835/ >> >> -- >> Matthew Thode (prometheanfire) >> __ >> 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 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 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Brian Rosmaita writes: > On 10/8/18 11:59 PM, Matthew Thode wrote: >> several projects have had problems with the new release, some have ways >> of working around it, and some do not. I'm sending this just to raise >> the issue and allow a place to discuss solutions. >> >> Currently there is a review proposed to blacklist 9.0.0, but if this is >> going to still be an issue somehow in further releases we may need >> another solution. >> >> https://review.openstack.org/#/c/608835/ > > As indicated in the commit message on the above patch, 9.0.0 contains a > bug that's been fixed in oslo.messaging master, so I don't think there's > any question that 9.0.0 has to be blacklisted. I've proposed releasing oslo.messaging 9.0.1 in https://review.openstack.org/609030 If we don't land the constraint update to allow 9.0.1 in, then there's no rush to blacklist anything, is there? > As far as the timing/content of 9.0.1, however, that may require further > discussion. > > (In other words, I'm saying that when you say 'another solution', my > position is that we should take 'another' to mean 'additional', not > 'different'.) I'm not sure what that means. Doug __ 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
Matthew Thode writes: > several projects have had problems with the new release, some have ways > of working around it, and some do not. I'm sending this just to raise > the issue and allow a place to discuss solutions. > > Currently there is a review proposed to blacklist 9.0.0, but if this is > going to still be an issue somehow in further releases we may need > another solution. > > https://review.openstack.org/#/c/608835/ > > -- > Matthew Thode (prometheanfire) > __ > 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 Do you have links to the failure logs or bug reports or something? If I wanted to help I wouldn't even know where to start. Doug __ 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] Stepping down from Release Management team
Anne Bertucio writes: > Hi all, > > I have had a fantastic time getting to work on the Release Management > team and getting to know you all through the release marketing work, > however, it is time for me to step down from my role on the Release > Management team as I am moving on from my role at the Foundation and > will no longer be working on upstream OpenStack. I cannot thank you > all enough for how you all welcomed me into the OpenStack community > and for how much I have learned about open source development in my > time here. > > If you have questions about cycle-highlights, swing by #openstack-release. > If you have questions about release marketing, contact lau...@openstack.org. > For other inquiries, contact alli...@openstack.org. > While I won't be working upstream anymore, I'll only be a Tweet or IRC > message away. > > Thank you again, and remember that cycle-highlights should be > submitted by RC1. Thank you for everything, Anne! The cycle-highlights system you helped us create is a great example of using decentralization and peer review at the same time. I'm sure it's going to continue to be an important communication tool for the community. Doug __ 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs
Doug Hellmann writes: > Doug Hellmann writes: > >> Doug Hellmann writes: >> >>> Doug Hellmann writes: >> >>> I have filed requests with the maintainers of PyPI to claim the names >>> "keystone" and "congress". That may take some time. Please let me know >>> if you're willing to simply use "openstack-keystone" and >>> "openstack-congress" instead. I will take care of configuring PyPI and >>> proposing the patch to update your setup.cfg (that way you can approve >>> the change). >>> >>> * https://github.com/pypa/warehouse/issues/4770 >>> * https://github.com/pypa/warehouse/issues/4771 > > We haven't heard back about either of these requests, so I filed changes > with congress and keystone to change the dist names. > > * https://review.openstack.org/608332 (congress) > * https://review.openstack.org/608331 (keystone) > > Doug Dan Crosta has very graciously given us the name "keystone" so I abandoned that patch, made openstackci an owner, and uploaded the previous release. The patch to rename congress is approved, but sitting on top of one or two other patches that also need reviews. The patch to rename heat is failing the grenade tests, and we could use some help with fixing the problem. I think we need an upgrade script that removes the old package before installing the new one. Does someone want to learn how grenade scripts work? Doug __ 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] Zuul job backlog
Abhishek Kekane writes: > Hi Doug, > > Should I use something like SimpleHttpServer to upload a file and download > the same, or there are other efficient ways to handle it, > Kindly let me know if you are having any suggestions for the same. Sure, that would work, especially if your tests are running in the unit test jobs. If you're running a functional test, it seems like it would also be OK to just copy a file into the directory Apache is serving from and then download it from there. Doug > > Thanks & Best Regards, > > Abhishek Kekane > > > On Fri, Oct 5, 2018 at 4:57 PM Doug Hellmann wrote: > >> Abhishek Kekane writes: >> >> > Hi Matt, >> > >> > Thanks for the input, I guess I should use ' >> > http://git.openstack.org/static/openstack.png' which will definitely >> work. >> > Clark, Matt, Kindly let me know your opinion about the same. >> >> That URL would not be on the local node running the test, and would >> eventually exhibit the same problems. In fact we have seen issues >> cloning git repositories as part of the tests in the past. >> >> You need to use a localhost URL to ensure that the download doesn't have >> to go off of the node. That may mean placing something into the directory >> where Apache is serving files as part of the test setup. >> >> Doug >> __ 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] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches
We have about 17 remaining patches to import zuul job settings into a few repositories. Those are mostly in stable branches and the jobs are failing in ways that may take us a long time to fix. Rather than waiting for those, Andreas and I are proposing that we have someone from the infra team approve them, bypassing the test jobs. That will allow us to complete the cleanup work in the project-config repository, and will not leave the affected repositories in a state that is any more (or less) broken than they are today. If you have any objections to the plan, please speak up quickly. I would like to try to proceed before the end of the week. Doug +--+-+---++--+-+---+---+ | Subject | Repo | Team | Tests | Workflow | URL | Branch | Owner | +--+-+---++--+-+---+---+ | import zuul job settings from project-config | openstack/aodh | Telemetry | FAILED | NEW | https://review.openstack.org/598648 | stable/ocata | Doug Hellmann | | import zuul job settings from project-config | openstack/barbican | barbican | FAILED | REVIEWED | https://review.openstack.org/599659 | stable/queens | Doug Hellmann | | import zuul job settings from project-config | openstack/barbican | barbican | FAILED | REVIEWED | https://review.openstack.org/599661 | stable/rocky | Doug Hellmann | | import zuul job settings from project-config | openstack/castellan-ui | barbican | FAILED | NEW | https://review.openstack.org/599649 | master | Doug Hellmann | | import zuul job settings from project-config | openstack/ceilometermiddleware | Telemetry | FAILED | APPROVED | https://review.openstack.org/598634 | master | Doug Hellmann | | import zuul job settings from project-config | openstack/ceilometermiddleware | Telemetry | FAILED | APPROVED | https://review.openstack.org/598655 | stable/pike | Doug Hellmann | | import zuul job settings from project-config | openstack/ceilometermiddleware | Telemetry | PASS | NEW | https://review.openstack.org/598661 | stable/queens | Doug Hellmann | | import zuul job settings from project-config | openstack/ceilometermiddleware | Telemetry | FAILED | NEW | https://review.openstack.org/598667 | stable/rocky | Doug Hellmann | | import zuul job settings from project-config | openstack/monasca-analytics | monasca | FAILED | REVIEWED | https://review.openstack.org/595658 | master | Doug Hellmann | | import zuul job settings from project-config | openstack/networking-midonet | neutron | PASS | REVIEWED | https://review.openstack.org/597937 | stable/queens | Doug Hellmann | | import zuul job settings from project-config | openstack/networking-sfc | neutron | FAILED | NEW | https://review.openstack.org/597913 | stable/ocata | Doug Hellmann | | import zuul job settings from project-config | openstack/networking-sfc | neutron | FAILED | NEW | https://review.openstack.org/597925 | stable/pike | Doug Hellmann | | import zuul job settings from project-config | openstack/python-aodhclient | Telemetry | FAILED | NEW | https://review.openstack.org/598652 | stable/ocata | Doug Hellmann | | import zuul job settings from project-config | openstack/python-aodhclient | Telemetry | FAILED | NEW | https://review.openstack.org/598657 | stable/pike | Doug Hellmann | | import zuul job settings from project-config | openstack/python-aodhclient | Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | stable/rocky | Doug Hellmann | | import zuul job settings from project-config | openstack/python-barbicanclient | barbican | FAILED | NEW | https://review.openstack.org/599656 | stable/ocata | Doug Hellmann | | import zuul job settings from project-config | openstack/python-barbicanclient | barbican | FAILED | NEW | https://review.openstack.org/599658 | stable/pike | Doug Hellmann | +--+-+---++--+-+---+---+ __ 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] [tc] Technical Committee status update for 8 October 2018
This is the weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == Since the last update email, we have held another TC election in which 3 returning and 3 new members have been elected. Welcome again to our new and returning members, and thank you to the former members for their service! * http://lists.openstack.org/pipermail/openstack-dev/2018-September/135187.html If you missed it, I sent the summary of TC discussions at the PTG a while back. * http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.html Between being busy with the PTG and then the TC elections, I did not send a status update during September, so there are quite a few project updates to report. Project updates: * Add os-ken to neutron: https://review.openstack.org/#/c/588358/ * Add cookbook-openstack-bare-metal to Chef: * https://review.openstack.org/#/c/596746/ * Add mistral-extra to Mistral: https://review.openstack.org/#/c/597551/ * Add placement deliverable to Nova: * https://review.openstack.org/#/c/598380/ * Add metalsmith to Ironic: https://review.openstack.org/#/c/602075/ * Add oslo.upgradecheck to Oslo: * https://review.openstack.org/#/c/602483/ * Add puppet-placement to Puppet: * https://review.openstack.org/#/c/602870/ * Add ansible-role-chrony to TripleO: * https://review.openstack.org/#/c/603516/ * Add octavia-lib to Octavia: https://review.openstack.org/#/c/604890/ * Add neutron-interconnection to neutron: * https://review.openstack.org/#/c/599428/ Retired repositories: * Retire the development-proposals repository: https://review.openstack.org/#/c/600649/ * Retire fuxi: https://review.openstack.org/#/c/604527/ * Retire charm-ceph: https://review.openstack.org/#/c/604530/ Community Updates: * Add Jay Faulkner as ATC for Ironic: https://review.openstack.org/#/c/597212/ * Begin the T deveiopment cycle naming process: https://review.openstack.org/#/c/600354/ * The Operations Guide team adopted the HA Guide: https://review.openstack.org/#/c/601321/ * The Interop Working Group adopted the refstack tools: https://review.openstack.org/#/c/590179/ == TC Meetings == In order to fulfill our obligations under the OpenStack Foundation bylaws, the TC needs to hold meetings at least once each quarter. We have decided to schedule monthly meetings on IRC, and retain the existing office hours times for less formal discussions. See the thread for details. * http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html == Ongoing Discussions == Tony Breeds is coordinating the poll for names for the T development cycle and release series. * http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html == TC member actions/focus/discussions for the coming week(s) == We need to decide how we are going to handle updating the list of liaisons to projects this cycle. Please follow up on that thread. * http://lists.openstack.org/pipermail/openstack-dev/2018-October/135523.html Add the monthly meeting to your calendar. * http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html The next Foundation board meeting will be held via webex on 25 October. See the wiki for details. * https://wiki.openstack.org/wiki/Governance/Foundation/25Oct2018BoardMeeting == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-dev at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.o
[openstack-dev] [tc] assigning new liaisons to projects
TC members, Since we are starting a new term, and have several new members, we need to decide how we want to rotate the liaisons attached to each our project teams, SIGs, and working groups [1]. Last term we went through a period of volunteer sign-up and then I randomly assigned folks to slots to fill out the roster evenly. During the retrospective we talked a bit about how to ensure we had an objective perspective for each team by not having PTLs sign up for their own teams, but I don't think we settled on that as a hard rule. I think the easiest and fairest (to new members) way to manage the list will be to wipe it and follow the same process we did last time. If you agree, I will update the page this week and we can start collecting volunteers over the next week or so. Doug [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker __ 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] [tc] planned absence
TC members, I have some PTO planned, so I will be away from 13 Oct - 28 Oct. I approved the patch appointing Mohammed as vice chair this morning, so he will be serving as chair during that time. Doug __ 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] bringing back formal TC meetings
Based on the conversation in the other branch of this thread, I have filed [1] to start monthly meetings on November 1 at 1400 UTC. It may take a while before that actually shows up on the calendar, because it required adding a feature to yaml2ical [2]. We talked about using email to add items to the agenda, but I realized that's going to complicate the coordination between chair and vice chair, so I would like for us to use the wiki [2] to suggest agenda items. We will still rely on email to the openstack-dev or openstack-discuss list to set the formal agenda before the actual meeting. Let me know if you foresee any issues with that plan. Doug [1] https://review.openstack.org/608682 [2] https://review.openstack.org/608680 [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee __ 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs
Doug Hellmann writes: > Doug Hellmann writes: > >> Doug Hellmann writes: >> >>> I think we are ready to go ahead and switch all of the python packaging >>> jobs to the new set defined in the publish-to-pypi-python3 template >>> [1]. We still have some cleanup patches for projects that have not >>> completed their zuul migration, but there are only a few and rebasing >>> those will be easy enough. >>> >>> The template adds a new check job that runs when any files related to >>> packaging are changed (readme, setup, etc.). Otherwise it switches from >>> the python2-based PyPI job to use python3. >>> >>> I have the patch to switch all official projects ready in [2]. >>> >>> Doug >>> >>> [1] >>> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218 >>> [2] https://review.openstack.org/#/c/598323/ >> >> This change is now in place. The Ironic team discovered one issue, and >> the fix is proposed as https://review.openstack.org/606152 >> >> This change has also reopened the question of how to publish some of the >> projects for which we do not own names on PyPI. >> >> I registered manila, qinling, and zaqar-ui by uploading Rocky series >> releases of those projects and then added openstackci as an owner so we >> can upload new packages this cycle. >> >> I asked the owners of the name "heat" to allow us to use it, and they >> rejected the request. So, I proposed a change to heat to update the >> sdist name to "openstack-heat". >> >> * https://review.openstack.org/606160 >> >> We don't own "magnum" but there is already an "openstack-magnum" set up >> with old releases, so I have proposed a change to the magnum repo to >> change the dist name there, so we can resume using it. >> >> * https://review.openstack.org/606162 > > The owner of the name "magnum" has given us access, so I have set it up > with permission for the CI system to publish and I have abandoned the > rename patch. > >> I have filed requests with the maintainers of PyPI to claim the names >> "keystone" and "congress". That may take some time. Please let me know >> if you're willing to simply use "openstack-keystone" and >> "openstack-congress" instead. I will take care of configuring PyPI and >> proposing the patch to update your setup.cfg (that way you can approve >> the change). >> >> * https://github.com/pypa/warehouse/issues/4770 >> * https://github.com/pypa/warehouse/issues/4771 We haven't heard back about either of these requests, so I filed changes with congress and keystone to change the dist names. * https://review.openstack.org/608332 (congress) * https://review.openstack.org/608331 (keystone) Doug __ 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs
Doug Hellmann writes: > Doug Hellmann writes: > >> I think we are ready to go ahead and switch all of the python packaging >> jobs to the new set defined in the publish-to-pypi-python3 template >> [1]. We still have some cleanup patches for projects that have not >> completed their zuul migration, but there are only a few and rebasing >> those will be easy enough. >> >> The template adds a new check job that runs when any files related to >> packaging are changed (readme, setup, etc.). Otherwise it switches from >> the python2-based PyPI job to use python3. >> >> I have the patch to switch all official projects ready in [2]. >> >> Doug >> >> [1] >> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218 >> [2] https://review.openstack.org/#/c/598323/ > > This change is now in place. The Ironic team discovered one issue, and > the fix is proposed as https://review.openstack.org/606152 > > This change has also reopened the question of how to publish some of the > projects for which we do not own names on PyPI. > > I registered manila, qinling, and zaqar-ui by uploading Rocky series > releases of those projects and then added openstackci as an owner so we > can upload new packages this cycle. > > I asked the owners of the name "heat" to allow us to use it, and they > rejected the request. So, I proposed a change to heat to update the > sdist name to "openstack-heat". > > * https://review.openstack.org/606160 > > We don't own "magnum" but there is already an "openstack-magnum" set up > with old releases, so I have proposed a change to the magnum repo to > change the dist name there, so we can resume using it. > > * https://review.openstack.org/606162 The owner of the name "magnum" has given us access, so I have set it up with permission for the CI system to publish and I have abandoned the rename patch. > I have filed requests with the maintainers of PyPI to claim the names > "keystone" and "congress". That may take some time. Please let me know > if you're willing to simply use "openstack-keystone" and > "openstack-congress" instead. I will take care of configuring PyPI and > proposing the patch to update your setup.cfg (that way you can approve > the change). > > * https://github.com/pypa/warehouse/issues/4770 > * https://github.com/pypa/warehouse/issues/4771 > > Doug > > __ > 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 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] [Distutils] pip 18.1 has been released!
Watch for changes in pip's behavior. - Doug Pradyun Gedam writes: > On behalf of the PyPA, I am pleased to announce that pip 18.1 has just > been released. > > To install pip 18.1, you can run:: > > python -m pip install --upgrade pip > > or use get-pip as described in > https://pip.pypa.io/en/latest/installing. Note that > if you are using a version of pip supplied by your distribution > vendor, vendor-supplied > upgrades will be available in due course. > > The highlights of this release are: > > - Python 3.7 is now supported > - Dependency Links support is now scheduled for removal in pip 19.0 > (the next pip > release, scheduled in January 2019). > - Plaform specific options can now be used with the --target option, > to enable certain > workflows. > - Much more helpful error messages on invalid configuration files > - Many bug fixes and minor improvements > > Thanks to everyone who put so much effort into the new release. Many of the > contributions came from community members, whether in the form of code, > participation in design discussions and/or bug reports. The pip development > team is extremely grateful to everyone in the community for their > contributions. > > Thanks, > Pradyun > -- > Distutils-SIG mailing list -- distutils-...@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/YBYAYIXJ2WUUYCJLM7EWMQETJOW5W6ZZ/ __ 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][searchlight] What should I do with the missing releases?
Trinh Nguyen writes: > Dear release team, > > One thing comes up in my mind when preparing for the stein-1 release of > Searchlight that is what should we do with the missing releases (i.e. > Rocky)? Can I just ignore it or do I have to create a branch for it? There was no rocky release, so I don't really see any reason to create the branch. There isn't anything to maintain. Doug __ 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] bringing back formal TC meetings
Chris Dent writes: > On Thu, 4 Oct 2018, Doug Hellmann wrote: > >> TC members, please reply to this thread and indicate if you would find >> meeting at 1300 UTC on the first Thursday of every month acceptable, and >> of course include any other comments you might have (including alternate >> times). > > +1 > > Also, if we're going to set aside a time for a semi-formal meeting, I > hope we will have some form of agenda and minutes, with a fairly > clear process for setting that agenda as well as a process for I had in mind "email the chair your topic suggestion" and then "the chair emails the agenda to openstack-dev tagged [tc] a bit in advance of the meeting". There would also probably be some standing topics, like updates for ongoing projects. Does that work for everyone? Doug > making sure that the fast and/or rude typers do not dominate the > discussion during the meetings, as they used to back in the day when > there were weekly meetings. > > The "raising hands" thing that came along towards the end sort of > worked, so a variant on that may be sufficient. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent > __ > 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 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] bringing back formal TC meetings
Thierry Carrez writes: > Ghanshyam Mann wrote: >> On Fri, 05 Oct 2018 02:47:53 +0900 Jeremy Stanley >> wrote >> > On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote: >> > [...] >> > > TC members, please reply to this thread and indicate if you would >> > > find meeting at 1300 UTC on the first Thursday of every month >> > > acceptable, and of course include any other comments you might >> > > have (including alternate times). >> > >> > This time is acceptable to me. As long as we ensure that community >> > feedback continues more frequently in IRC and on the ML (for example >> > by making it clear that this meeting is expressly *not* for that) >> > then I'm fine with resuming formal meetings. >> >> +1. Time works fine for me, Thanks for considering the APAC TZ. >> >> I agree that we should keep encouraging the usual discussion in existing >> office hours, IRC or ML. I will be definitely able to attend other 2 office >> hours (Tuesday and Wednesday) which are suitable for my TZ. > > 1300 UTC is obviously good for me, but once we are off DST that will > mean 5am for our Pacific Time people (do we have any left ?). > > Maybe 1400 UTC would be a better trade-off? Julia is out west, but I think not all the way to PST. > Regarding frequency, I agree with mnaser that once per month might be > too rare. That means only 5-ish meetings for a given a 6-month > membership. But that can work if we use the meeting as a formal progress > status checkpoint, rather than a way to discuss complex topics. I think we can definitely manage the agenda to minimize the number of complex discussions. If that proves to be too hard, I wouldn't mind meeting more often, but there does seem to be a lot of support for preferring other venues for those conversations. Doug __ 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] [api] Open API 3.0 for OpenStack API
Gilles Dubreuil writes: >> About the micro version, we discuss with your team mate dmitry in >> another email [1] > > Obviously micro version is a point of contention. > My take on this is because consuming them has been proven harder than > developing them. > The beauty of GraphQL is that there is no need to deal with version at all. > New fields appears when needed and old one are marked deprecated. How does someone using GraphQL to use a cloud know when a specific field is available? How can they differentiate what is supported in one cloud from what is supported in another, running a different version of the same service? Doug __ 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] Zuul job backlog
Abhishek Kekane writes: > Hi Matt, > > Thanks for the input, I guess I should use ' > http://git.openstack.org/static/openstack.png' which will definitely work. > Clark, Matt, Kindly let me know your opinion about the same. That URL would not be on the local node running the test, and would eventually exhibit the same problems. In fact we have seen issues cloning git repositories as part of the tests in the past. You need to use a localhost URL to ensure that the download doesn't have to go off of the node. That may mean placing something into the directory where Apache is serving files as part of the test setup. Doug __ 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][Searchlight] Always build universal wheels
Trinh Nguyen writes: > Thank Jeremy, Doug for explaining. > > On Fri, Oct 5, 2018 at 6:54 AM Doug Hellmann wrote: > >> Jeremy Stanley writes: >> >> > On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote: >> > [...] >> >> Please avoid adding universal wheels to the project setup.cfg. >> > [...] >> > >> > Why would you avoid also adding it to the setup.cfg? The change you >> > cited is merely to be able to continue building universal wheels for >> > projects while the setup.cfg files are corrected over time, to >> > reduce the urgency of doing so. Wheel building happens in more >> > places than just our CI system, so only fixing it in CI is not a >> > good long-term strategy. >> >> I abandoned a couple of dozen patches submitted today by someone who was >> not coordinating with the goal champions with a message that said those >> patches were not needed because I didn't want folks to be dealing with >> this right now. >> >> Teams who want to update their setup.cfg can do so, but my intent is to >> ensure it is not required in order to produce releases with the >> automation in the short term. I thought about this some more last night, looking for reasons not to update all of the setup.cfg files. If this zuul migration project has shown anything, it's that we need to continue to be creative with finding ways to avoid touching every branch of every repository when we have build system changes to make. I support decentralizing the job management, but I think this is a case where we can avoid doing a bunch of work, and so we should. We've been saying we want to update the setup.cfg files to include the setting to cause a universal wheel to build because we want the local developer experience when building wheels to be the same as what we get from the CI system when we publish packages. I don't think that's a real requirement, though. The default behavior of bdist_wheel is to create a version-specific wheel, suitable for use with the version of python used to build it. The universal flag makes a wheel file that can be used under either python2 or python3. Perhaps surprisingly, the contents of a universal wheel are *exactly* the same as the contents of a version-specific wheel. Literally the *only* difference is the filename, which includes both versions so that pip will choose the universal file if no version-specific file exists. Therefore, for our CI system, we want to publish universal wheels to PyPI because they are more usable to consumers installing from there (including the CI system). On the other hand, for local builds, there's no particular reason to prefer a universal wheel over the version-specific format. If someone is building their own wheels for internal consumption, they can easily choose to keep the version-specific packages, or add the --universal flag like we're doing in the CI job. So, I think this all means we can leave the setup.cfg files as they are and not worry about updating the wheel format flag. Doug __ 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/os-log-merger failed
Jeremy Stanley writes: > On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote: > [...] >> HTTPError: 400 Client Error: Invalid value for classifiers. Error: >> 'Topic:: Utilities' is not a valid choice for this field for url: >> https://upload.pypi.org/legacy/ >> >> I'm not aware of any way to test those values easily before doing an >> upload. If someone knows of a way, please let me know. > > I started writing a distcheck utility based on some validation code > flit uses, but now that twine has a check option there is expressed > intent by Dustin to do it there (see description of > https://github.com/pypa/twine/pull/395 for details) which seems like > a more natural solution anyway. OK, good. The existing check job for packaging already runs 'twine check' so we should be covered when that feature is merged and released. Doug __ 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] Sphinx testing fun
Stephen Finucane writes: > On Thu, 2018-10-04 at 07:21 -0400, Doug Hellmann wrote: >> Stephen Finucane writes: [snip] >> > Anyway, we can go figure out what's changed here and handle it but this >> > is, at best, going to be a band aid. The fact is 'sphinx_testing' is >> > unmaintained and has been for some time now. The new hotness is >> > 'sphinx.testing' [3], which is provided (with zero documentation) as >> > part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm >> > pretty sure Monty (and a few others?) are vehemently against using in >> > OpenStack. That leaves us with three options: >> > >> > * Take over 'sphinx_testing' and bring it up-to-date. Maintain >> >forever. >> > * Start using 'sphinx.testing' and everything it comes with >> > * Delete any tests that use 'sphinx_testing' and deal with the lack of >> >coverage >> >> Could we change our tests to use pathlib to wrap app.outdir and get the >> same results as before? > > That's what I've done [2], which is kind of based on how I fixed this > in Sphinx. However, this is at best a stopgap. The fact remains that > 'sphinx_testing' is dead and the large changes that Sphinx is > undergoing (2.0 will be Python 3 only, with multiple other fixes) will > make further breakages more likely. Unless we want a repeat of the Mox > situation, I do think we should start thinking about this sooner rather > than later. Yeah, it sounds like we need to deal with the change. It looks like only the os-api-ref repo uses sphinx-testing. How many tests are we talking about having to rewrite/update there? Doug __ 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/os-log-merger failed
z...@openstack.org writes: > Build failed. > > - release-openstack-python > http://logs.openstack.org/b4/b4553baa59b1f13a57973f2a3cff9b57acf3d522/release/release-openstack-python/68d0da8/ > : POST_FAILURE in 5m 19s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED > > ___ > Release-job-failures mailing list > release-job-failu...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like there is a bad classifier in the os-log-merger setup.cfg file. HTTPError: 400 Client Error: Invalid value for classifiers. Error: 'Topic:: Utilities' is not a valid choice for this field for url: https://upload.pypi.org/legacy/ I'm not aware of any way to test those values easily before doing an upload. If someone knows of a way, please let me know. Doug __ 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][Searchlight] Always build universal wheels
Jeremy Stanley writes: > On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote: > [...] >> Please avoid adding universal wheels to the project setup.cfg. > [...] > > Why would you avoid also adding it to the setup.cfg? The change you > cited is merely to be able to continue building universal wheels for > projects while the setup.cfg files are corrected over time, to > reduce the urgency of doing so. Wheel building happens in more > places than just our CI system, so only fixing it in CI is not a > good long-term strategy. I abandoned a couple of dozen patches submitted today by someone who was not coordinating with the goal champions with a message that said those patches were not needed because I didn't want folks to be dealing with this right now. Teams who want to update their setup.cfg can do so, but my intent is to ensure it is not required in order to produce releases with the automation in the short term. Doug __ 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] [tc] bringing back formal TC meetings
During the TC office hours today [1] we discussed the question of resuming having formal meetings of the TC to ensure we are in compliance with the section of the bylaws that says "The Technical Committee shall meet at least quarterly." [2] As not all TC members were present today, we decide to move the discussion to the mailing list to ensure all members have input into the decision. A bit of background --- The TC used to hold formal weekly meetings with agendas, roll call, etc. We stopped doing that in an attempt to encourage more asynchronous communication and to include folks in all time zones. Those meetings were replaced with less formal "office hours" where TC members were encouraged to be present on IRC in case the community had questions or issues to raise in a synchronous forum. The bylaws section that describes the membership and some of the expectations for the Technical Committee specifically requires us to meet at least once quarter year. We have had meetings at the PTGs and summits, which while not recorded via a roll call were open and documented afterwards with summaries to this mailing list. With the change in event schedule, we will no longer have obvious opportunities to hold 4 in-person meetings each year. During the discussion today, we established the general consensus that our current informal office hours do not constitute a "meeting" in the sense that any of us understand this requirement. As a result, we need to consider changes to our current meeting policy to ensure we are in compliance with the foundation bylaws. Today's discussion -- A few folks expressed concern that we work to ensure these meetings *not* be seen as a replacement for asynchronous communication, and that we continue to encourage ad hoc discussions to continue to happen on the mailing list or during office hours. I think we agreed we could do that by managing the agenda carefully (i.e., the chair or vice chair would need to add topics to the agenda, rather than allowing anyone to add anything as we have done in the past). We also talked about only allowing recurring topics on the agenda, but I would prefer that we not write too many hard rules at the outset. We discussed how frequently we should meet, and everyone seemed to agree that weekly was too often and quarterly was not often enough. I proposed monthly, and there was some general support for that. We also talked about whether to find a new meeting time or to use one of the office hour times. As things stand now, the proposal is to try to find a time a few hours earlier than office hours on the first Thursday of each month for the meetings. The earlier time is so that APAC participants (Ghanshyam, in particular) do not need to stay up until midnight or later to participate. Next steps -- TC members, please reply to this thread and indicate if you would find meeting at 1300 UTC on the first Thursday of every month acceptable, and of course include any other comments you might have (including alternate times). Thanks, Doug [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-04.log.html#t2018-10-04T15:02:31 [2] https://www.openstack.org/legal/technical-committee-member-policy/ (item #4) __ 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] Sphinx testing fun
Stephen Finucane writes: > The tests in os-api-ref recently broke: > > > http://logs.openstack.org/62/606362/1/check/openstack-tox-py35/8b709de/testr_results.html.gz > > Specifically, we're seeing errors likes this: > > ft1.1: > os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method_StringException: > Traceback (most recent call last): > File > "/home/zuul/src/git.openstack.org/openstack/os-api-ref/.tox/py35/lib/python3.5/site-packages/sphinx_testing/util.py", > line 143, in decorator >func(*(args + (app, status, warning)), **kwargs) > File > "/home/zuul/src/git.openstack.org/openstack/os-api-ref/os_api_ref/tests/test_basic_example.py", > line 41, in setUp >self.html = (app.outdir / 'index.html').read_text(encoding='utf-8') >TypeError: unsupported operand type(s) for /: 'str' and 'str' > > Which is wrong because 'app.outdir' is not supposed to be an instance > of 'unicode' but rather 'sphinx_testing.path.path' [1] (which overrides > the '/' operator to act as concatenation because operator overloading > is always a good idea 😒) [2]. Is that a change in Sphinx's API? Or sphinx_testing's? > > Anyway, we can go figure out what's changed here and handle it but this > is, at best, going to be a band aid. The fact is 'sphinx_testing' is > unmaintained and has been for some time now. The new hotness is > 'sphinx.testing' [3], which is provided (with zero documentation) as > part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm > pretty sure Monty (and a few others?) are vehemently against using in > OpenStack. That leaves us with three options: > > * Take over 'sphinx_testing' and bring it up-to-date. Maintain > forever. > * Start using 'sphinx.testing' and everything it comes with > * Delete any tests that use 'sphinx_testing' and deal with the lack of >coverage Could we change our tests to use pathlib to wrap app.outdir and get the same results as before? Doug __ 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] [goal][python3] week 7 update
Doug Hellmann writes: > Doug Hellmann writes: > >> Doug Hellmann writes: >> >>> == Things We Learned This Week == >>> >>> When we updated the tox.ini settings for jobs like pep8 and release >>> notes early in the Rocky session we only touched some of the official >>> repositories. I'll be working on making a list of the ones we missed so >>> we can update them by the end of Stein. >> >> I see quite a few repositories with tox settings out of date (about 350, >> see below). Given the volume, I'm going to prepare the patches and >> propose them a few at a time over the next couple of weeks. > > Zuul looked bored this morning so I went ahead and proposed a few of the > larger batches of these changes for the Charms, OpenStack Ansible, and > Horizon teams. TripleO also has quite a few, but since we know the gate > is unstable I will hold off on those for now. > > There will be more patches when there is CI capacity again. > > Doug All of these patches have now been proposed. Doug __ 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] [goals][python3][barbican][monasca][neutron][charms][ansible][telemetry][trove][stable] completing zuul settings migration
We have 7 teams still working on the zuul setting migrations as part of the python3-first goal [1]. Quite a few of the changes are on stable branches, so will need attention from the stable teams for each project. If you need help reviewing those stable branch patches, please speak up so we can find some folks on the stable team to provide +2 votes. Some of the patches are failing the test jobs, probably because of bitrot on older stable branches. Those may need extra attention from project team members to fix, depending on the nature of the problems. I would like to have this portion of the work done by the first milestone, and I think we're close enough to do it. Please look through the list of patches for your project and ensure they are in your review queues. Thanks, Doug [1] https://review.openstack.org/#/q/topic:python3-first+is:open+message:%22import+zuul+job+settings+from+project-config%22 __ 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][neutron] Release of openstack/networking-bigswitch failed
AdityaVaja writes: > Hello Doug, > > I was going to send out an email or drop in on IRC to check how to fix that. > > We accidentally pushed 13.0.1 on stable/queens, instead of 12.0.5. (13.x.x > is rocky and 12.x.x is queens) > Tried reverting the situation by pushing 12.0.5 for the same commit hash on > queens, but that didn't work. Releases with commit hash can be compared > here [1]. > > Deleting the release from PYPI can be done, but deleting a tag from gerrit > is not possible without allowing forcePush from project-config - afaik. But > that seems like an extreme step. > Not sure how to fix the situation, so I thought checking with > openstack-release to get an idea. > > If your original suggestion of pushing 12.0.6 still stands, I can go ahead > and do that. I think that pushing 12.0.6 to a point on that branch after the 12.0.5/13.0.1 commit will produce a new release with version 12.0.6 that works correctly. Unfortunately, you're right that we don't have a good way to remove the old 13.0.1 release and tag. In the past we have just ignored that and moved on, although I think in some cases we did remove the package from PyPI to avoid having it installed accidentally. I don't know how many of your users are using pip to install the packages you build, so I don't know how important it will be for you to do that. Doug __ 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] Zuul job backlog
Wesley Hayutin writes: [snip] > The TripleO project has created a single node container based composable > OpenStack deployment [2]. It is the projects intention to replace most of > the TripleO upstream jobs with the Standalone deployment. We would like to > reduce our multi-node usage to a total of two or three multinode jobs to > handle a basic overcloud deployment, updates and upgrades[a]. Currently in > master we are relying on multiple multi-node scenario jobs to test many of > the OpenStack services in a single job. Our intention is to move these > multinode scenario jobs to single node job(s) that tests a smaller subset > of services. The goal of this would be target the specific areas of the > TripleO code base that affect these services and only run those there. This > would replace the existing 2-3 hour two node job(s) with single node job(s) > for specific services that completes in about half the time. This > unfortunately will reduce the overall coverage upstream but still allows us > a basic smoke test of the supported OpenStack services and their deployment > upstream. > > Ideally projects other than TripleO would make use of the Standalone > deployment to test their particular service with containers, upgrades or > for various other reasons. Additional projects using this deployment would > help ensure bugs are found quickly and resolved providing additional > resilience to the upstream gate jobs. The TripleO team will begin review to > scope out and create estimates for the above work starting on October 18 > 2018. One should expect to see updates on our progress posted to the > list. Below are some details on the proposed changes. [snip] Thanks for all of the details, Wes. I know the current situation has been hurting the TripleO team as well, so I'm glad to see a good plan in place to address it. I look forward to seeing updates about the progress. Doug __ 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] [goals][python3][heat][stable] how should we proceed with ocata branch
Zane Bitter writes: > On 3/10/18 9:42 AM, Matt Riedemann wrote: >> On 10/3/2018 7:58 AM, Doug Hellmann wrote: >>> There is one more patch to import the zuul configuration for the >>> heat-agents repository's stable/ocata branch. That branch is apparently >>> broken, and Zane suggested on the review [1] that we abandon the patch >>> and close the branch. >>> >>> That patch is the only thing blocking the cleanup patch in >>> project-config, so I would like to get a definitive answer about what to >>> do. Should we close the branch, or does someone want to try to fix >>> things up? > > I think we agreed on closing the branch, and Rico was looking into the > procedure for how to actually do that. OK. I am going to abandon the patch to import the zuul settings then. Abandoning all open patches is one of the early steps anyway, and doing that now for this 1 patch will allow us to proceed with the cleanup. Doug __ 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][neutron] Release of openstack/networking-bigswitch failed
z...@openstack.org writes: > Build failed. > > - release-openstack-python > http://logs.openstack.org/d1/d1df2f75e0e8259ddaaf5136f421567733ba7f5b/release/release-openstack-python/8a89663/ > : FAILURE in 6m 19s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED It looks like there's something wrong with the versioning in the stable/queens branch of the networking-bigswitch repository. The error I see when I run "python setup.py --name" locally is: ValueError: git history requires a target version of pbr.version.SemanticVersion(13.0.1), but target version is pbr.version.SemanticVersion(12.0.5) This is being caused by re-tagging the 13.0.1 release as 12.0.5. I think if we tag a *newer* commit as 12.0.6 that will work (it seems to work locally). Doug __ 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] [goals][python3][heat][stable] how should we proceed with ocata branch
There is one more patch to import the zuul configuration for the heat-agents repository's stable/ocata branch. That branch is apparently broken, and Zane suggested on the review [1] that we abandon the patch and close the branch. That patch is the only thing blocking the cleanup patch in project-config, so I would like to get a definitive answer about what to do. Should we close the branch, or does someone want to try to fix things up? Doug [1] https://review.openstack.org/#/c/597272/ __ 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] [goal][python3] week 8 update
This is week 8 of the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html). == Ongoing and Completed Work == I proposed a large set of new patches to update the tox settings for repositories that were still using python2 for doc, release note, linter, etc. jobs. Quite a few of those were duplicates, so if you find that someone else has already started that work please vote -1 on my patch with a link to the other one, and I'll abandon mine. +-+-+--+-+--+-++---++ | Team| zuul| tox defaults | Docs| 3.6 unit | Failing | Unreviewed | Total | Champion | +-+-+--+-+--+-++---++ | adjutant| + | 1/ 1 | - | + | 0 | 1 | 6 | Doug Hellmann | | barbican| 7/ 13 | +| 1/ 3 | + | 6 | 4 |20 | Doug Hellmann | | blazar | + | +| + | + | 0 | 0 |25 | Nguyen Hai | | Chef OpenStack | + | 2/ 2 | - | - | 1 | 1 | 3 | Doug Hellmann | | cinder | + | 1/ 3 | + | + | 0 | 1 |33 | Doug Hellmann | | cloudkitty | + | +| + | + | 0 | 0 |26 | Doug Hellmann | | congress| + | 1/ 3 | + | + | 1 | 1 |25 | Nguyen Hai | | cyborg | + | +| + | + | 0 | 0 |16 | Nguyen Hai | | designate | + | 2/ 4 | + | + | 0 | 1 |26 | Nguyen Hai | | Documentation | + | 1/ 5 | + | + | 1 | 1 |23 | Doug Hellmann | | dragonflow | + | -| + | + | 0 | 0 | 6 | Nguyen Hai | | ec2-api | + | 2/ 2 | + | + | 2 | 2 |14 || | freezer | waiting for cleanup | 1/ 5 | + | + | 0 | 1 |34 || | glance | + | 1/ 4 | + | + | 0 | 0 |26 | Nguyen Hai | | heat| 3/ 27 | 4/ 8 | 1/ 6 | 1/ 7 | 2 | 4 |48 | Doug Hellmann | | horizon | + | 1/ 32 | + | + | 0 | 1 |42 | Nguyen Hai | | I18n| + | 1/ 1 | - | - | 0 | 0 | 3 | Doug Hellmann | | InteropWG | + | 4/ 4 | + | 1/ 3 | 2 | 4 |14 | Doug Hellmann | | ironic | + | 1/ 10 | + | + | 0 | 1 |95 | Doug Hellmann | | karbor | + | +| + | + | 0 | 0 |22 | Nguyen Hai | | keystone| + | 1/ 7 | + | + | 0 | 0 |48 | Doug Hellmann | | kolla | + | 1/ 1 | + | + | 1 | 0 |13 || | kuryr | + | +| + | + | 0 | 0 |20 | Doug Hellmann | | magnum | + | 2/ 5 | + | + | 0 | 1 |27 || | manila | + | 4/ 8 | + | + | 0 | 0 |32 | Goutham Pacha Ravi | | masakari| + | 3/ 5 | + | - | 0 | 3 |24 | Nguyen Hai | | mistral | + | +| + | + | 0 | 0 |38 | Nguyen Hai | | monasca | 1/ 66 | 5/ 17 | + | + | 3 | 4 | 100 | Doug Hellmann | | murano | + | 2/ 5 | + | + | 0 | 2 |39 || | neutron | 15/ 73 | 12/ 18 | 2/ 14 | 2/ 13 | 18 | 18 | 118 | Doug Hellman
Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed
Miguel Angel Ajo Pelayo writes: > Thank you for the guidance and ping Doug. > > Was this triggered by [1] ? or By the 1.1.0 tag pushed to gerrit? The release jobs are always triggered by the git tagging event. The patches in openstack/releases run a job that adds tags, but the patch you linked to hasn't been merged yet, so it looks like it was caused by pushing the tag manually. Doug __ 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] [python3-first] support in stable branches
Dariusz Krol writes: > Hello Doug, > > thanks for your explanation. I was a little bit confused by changes to > stable branches with python3-first topic as I thought it has to do > something with adding new test configuration for python3. > > But as you explained this is about moving zuul-related configuration, > which is a part of python3-first goal (but it is not related to > supporting python3 by projects IMHO :) ) > > Anyway, it is now clear to me and sorry for making this confusion. Thanks for asking for clarification! Doug __ 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] [goal][python3] week 7 update
Doug Hellmann writes: > Doug Hellmann writes: > >> == Things We Learned This Week == >> >> When we updated the tox.ini settings for jobs like pep8 and release >> notes early in the Rocky session we only touched some of the official >> repositories. I'll be working on making a list of the ones we missed so >> we can update them by the end of Stein. > > I see quite a few repositories with tox settings out of date (about 350, > see below). Given the volume, I'm going to prepare the patches and > propose them a few at a time over the next couple of weeks. Zuul looked bored this morning so I went ahead and proposed a few of the larger batches of these changes for the Charms, OpenStack Ansible, and Horizon teams. TripleO also has quite a few, but since we know the gate is unstable I will hold off on those for now. There will be more patches when there is CI capacity again. Doug __ 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] [goal][python3] week 7 update
Jeremy Stanley writes: > On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote: >> Doug Hellmann wrote on 09/26/2018 06:29:11 PM: >> >> > * We do not want to set the override once in testenv, because that >> > breaks the more specific versions used in default environments like >> > py35 and py36 (at least under older versions of tox). >> >> >> I assume that something like >> https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=fa64a93c965e6a6692711962ad6584534da81695 >> should be a perfectly acceptable alternative in at least some cases. >> Agreed? > > I believe the confusion is that ignore_basepython_conflict didn't > appear in a release of tox until after we started patching projects > for this effort (in fact it was added to tox in part because we > discovered the issue in originally attempting to use basepython > globally). Right. The scripted patches work with older versions of tox as well. They also have the benefit of only changing the environments into which the new setting is injected, which means if you have a py27-do-something-random environment it isn't going to suddenly start using python 3 instead of python 2.7. The thing we care about for the goal is ensuring that the required jobs run under python 3. Teams are, as always, completely free to choose alternative implementations if they are willing to update the patches (or write alternative ones). Doug __ 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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs
Doug Hellmann writes: > I think we are ready to go ahead and switch all of the python packaging > jobs to the new set defined in the publish-to-pypi-python3 template > [1]. We still have some cleanup patches for projects that have not > completed their zuul migration, but there are only a few and rebasing > those will be easy enough. > > The template adds a new check job that runs when any files related to > packaging are changed (readme, setup, etc.). Otherwise it switches from > the python2-based PyPI job to use python3. > > I have the patch to switch all official projects ready in [2]. > > Doug > > [1] > http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218 > [2] https://review.openstack.org/#/c/598323/ This change is now in place. The Ironic team discovered one issue, and the fix is proposed as https://review.openstack.org/606152 This change has also reopened the question of how to publish some of the projects for which we do not own names on PyPI. I registered manila, qinling, and zaqar-ui by uploading Rocky series releases of those projects and then added openstackci as an owner so we can upload new packages this cycle. I asked the owners of the name "heat" to allow us to use it, and they rejected the request. So, I proposed a change to heat to update the sdist name to "openstack-heat". * https://review.openstack.org/606160 We don't own "magnum" but there is already an "openstack-magnum" set up with old releases, so I have proposed a change to the magnum repo to change the dist name there, so we can resume using it. * https://review.openstack.org/606162 I have filed requests with the maintainers of PyPI to claim the names "keystone" and "congress". That may take some time. Please let me know if you're willing to simply use "openstack-keystone" and "openstack-congress" instead. I will take care of configuring PyPI and proposing the patch to update your setup.cfg (that way you can approve the change). * https://github.com/pypa/warehouse/issues/4770 * https://github.com/pypa/warehouse/issues/4771 Doug __ 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] [python3-first] support in stable branches
Dariusz Krol writes: > Hello, > > > I'm specifically referring to branches mentioned in: > https://github.com/openstack/goal-tools/blob/4125c31e74776a7dc6a15d2276ab51ff3e73cd16/goal_tools/python3_first/jobs.py#L54 > I'm still not entirely sure what you're saying is happening that you do not expect to have happening, but I'll take a guess. The zuul migration portion of the goal work needs to move *all* of the Zuul settings for a repo into the correct branch because after the migration the job settings will no longer be in project-config at all and so zuul won't know which jobs to run on the stable branches if we haven't imported the settings. The migration script tries to figure out which jobs apply to which branches of each repo by looking at the branch specifier settings in project-config, and then it creates an import patch for each branch with the relevant jobs. Subsequent steps in the script change the documentation and release notes jobs and then add new python 3.6 testing jobs. Those steps only apply to the master branch. So, if you have a patch importing a python 3 job setting to a stable branch of a repo where you aren't expecting it (and it isn't supported), that's most likely because project-config has no branch specifiers for the job (meaning it should run on all branches). We did find several cases where that was true because projects added jobs without branch specifiers after the branches were created, and then back-ported no patches to the stable branch. See http://lists.openstack.org/pipermail/openstack-dev/2018-August/133594.html for details. Doug > I hope this helps. > > > Best, > > Dariusz Krol > > > On 09/27/2018 06:04 PM, Ben Nemec wrote: >> >> >> On 9/27/18 10:36 AM, Doug Hellmann wrote: >>> Dariusz Krol writes: >>> >>>> Hello Champions :) >>>> >>>> >>>> I work on the Trove project and we are wondering if python3 should be >>>> supported in previous releases as well? >>>> >>>> Actually this question was asked by Alan Pevec from the stable branch >>>> maintainers list. >>>> >>>> I saw you added releases up to ocata to support python3 and there are >>>> already changes on gerrit waiting to be merged but after reading [1] I >>>> have my doubts about this. >>> >>> I'm not sure what you're referring to when you say "added releases up to >>> ocata" here. Can you link to the patches that you have questions about? >> >> Possibly the zuul migration patches for all the stable branches? If >> so, those don't change the status of python 3 support on the stable >> branches, they just split the zuul configuration to make it easier to >> add new python 3 jobs on master without affecting the stable branches. >> >>> >>>> Could you elaborate why it is necessary to support previous releases ? >>>> >>>> >>>> Best, >>>> >>>> Dariusz Krol >>>> >>>> >>>> [1] https://docs.openstack.org/project-team-guide/stable-branches.html >>>> __ >>>> >>>> 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 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 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/os-log-merger failed
z...@openstack.org writes: > Build failed. > > - release-openstack-python > http://logs.openstack.org/d4/d445ff62676bc5b2753fba132a3894731a289fb9/release/release-openstack-python/629c35f/ > : FAILURE in 3m 57s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED The error here is ERROR: unknown environment 'venv' It looks like os-log-merger is not set up for the release-openstack-python job, which expects a specific tox setup. http://logs.openstack.org/d4/d445ff62676bc5b2753fba132a3894731a289fb9/release/release-openstack-python/629c35f/ara-report/result/7c6fd37c-82d8-48f7-b653-5bdba90cbc31/ __ 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][elections] Stein TC Election Results
Emmet Hikory writes: > Please join me in congratulating the 6 newly elected members of the > Technical Committee (TC): > > - Doug Hellmann (dhellmann) > - Julia Kreger (TheJulia) > - Jeremy Stanley (fungi) > - Jean-Philippe Evrard (evrardjp) > - Lance Bragstad (lbragstad) > - Ghanshyam Mann (gmann) Congratulations, everyone! I'm looking forward to serving with all of you for another term. > Full Results: > https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f773fda2d0695864 > > Election process details and results are also available here: > https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates helps > engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. Voter turnout > was significantly up from recent cycles. We need to ensure your voices are > heard. It's particularly good to hear that turnout is up, not just in percentage but in raw numbers, too. Thank you all for voting! Doug __ 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] Release model for feature-complete OpenStack libraries
writes: > How will we handle which versions of libraries work together? > And which combinations will be run thru CI? Dependency management will work the same way it does today. Each component (server or library) lists the versions of the dependencies it is compatible with. That information goes into the packages built for the component, and is used to ensure that a compatible version of each dependency is installed when the package is installed. We control what is actually tested by using the upper constraints list managed in the requirements repository. There's more detail about how that list is managed in the project team guide at https://docs.openstack.org/project-team-guide/dependency-management.html Doug __ 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] [python3-first] support in stable branches
Dariusz Krol writes: > Hello Champions :) > > > I work on the Trove project and we are wondering if python3 should be > supported in previous releases as well? > > Actually this question was asked by Alan Pevec from the stable branch > maintainers list. > > I saw you added releases up to ocata to support python3 and there are > already changes on gerrit waiting to be merged but after reading [1] I > have my doubts about this. I'm not sure what you're referring to when you say "added releases up to ocata" here. Can you link to the patches that you have questions about? > Could you elaborate why it is necessary to support previous releases ? > > > Best, > > Dariusz Krol > > > [1] https://docs.openstack.org/project-team-guide/stable-branches.html > __ > 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 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] [goals][python3] switching python package jobs
I think we are ready to go ahead and switch all of the python packaging jobs to the new set defined in the publish-to-pypi-python3 template [1]. We still have some cleanup patches for projects that have not completed their zuul migration, but there are only a few and rebasing those will be easy enough. The template adds a new check job that runs when any files related to packaging are changed (readme, setup, etc.). Otherwise it switches from the python2-based PyPI job to use python3. I have the patch to switch all official projects ready in [2]. Doug [1] http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/project-templates.yaml#n218 [2] https://review.openstack.org/#/c/598323/ __ 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] [goals][tc][ptl][uc] starting goal selection for T series
Monty Taylor writes: > Main difference is making sure these new deconstructed plugin teams > understand the client support lifecycle - which is that we don't drop > support for old versions of services in OSC (or SDK). It's a shift from > the support lifecycle and POV of python-*client, but it's important and > we just need to all be on the same page. That sounds like a reason to keep the governance of the libraries under the client tool project. Doug __ 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] [goals][tc][ptl][uc] starting goal selection for T series
Dean Troyer writes: > On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: >> I started documenting the compute API gaps in OSC last release [1]. It's a >> big gap and needs a lot of work, even for existing CLIs (the cold/live >> migration CLIs in OSC are a mess, and you can't even boot from volume where >> nova creates the volume for you). That's also why I put something into the >> etherpad about the OSC core team even being able to handle an onslaught of >> changes for a goal like this. > > The OSC core team is very thin, yes, it seems as though companies > don't like to spend money on client-facing things...I'll be in the > hall following this thread should anyone want to talk... > > The migration commands are a mess, mostly because I got them wrong to > start with and we have only tried to patch it up, this is one area I > think we need to wipe clean and fix properly. Yay! Major version > release! I definitely think having details about the gaps would be a prerequisite for approving a goal, but I wonder if that's something 1 person could even do alone. Is this an area where a small team is needed? >> I thought the same, and we talked about this at the Austin summit, but OSC >> is inconsistent about this (you can live migrate a server but you can't >> evacuate it - there is no CLI for evacuation). It also came up at the Stein >> PTG with Dean in the nova room giving us some direction. [2] I believe the >> summary of that discussion was: > >> a) to deal with the core team sprawl, we could move the compute stuff out of >> python-openstackclient and into an osc-compute plugin (like the >> osc-placement plugin for the placement service); then we could create a new >> core team which would have python-openstackclient-core as a superset > > This is not my first choice but is not terrible either... We built cliff to be based on plugins to support this sort of work distribution, right? >> b) Dean suggested that we close the compute API gaps in the SDK first, but >> that could take a long time as well...but it sounded like we could use the >> SDK for things that existed in the SDK and use novaclient for things that >> didn't yet exist in the SDK > > Yup, this can be done in parallel. The unit of decision for use sdk > vs use XXXclient lib is per-API call. If the client lib can use an > SDK adapter/session it becomes even better. I think the priority for > what to address first should be guided by complete gaps in coverage > and the need for microversion-driven changes. > >> This might be a candidate for one of these multi-release goals that the TC >> started talking about at the Stein PTG. I could see something like this >> being a goal for Stein: >> >> "Each project owns its own osc- plugin for OSC CLIs" >> >> That deals with the core team and sprawl issue, especially with stevemar >> being gone and dtroyer being distracted by shiny x-men bird related things. >> That also seems relatively manageable for all projects to do in a single >> release. Having a single-release goal of "close all gaps across all service >> types" is going to be extremely tough for any older projects that had CLIs >> before OSC was created (nova/cinder/glance/keystone). For newer projects, >> like placement, it's not a problem because they never created any other CLI >> outside of OSC. Yeah, I agree this work is going to need to be split up. I'm still not sold on the idea of multi-cycle goals, personally. > I think the major difficulty here is simply how to migrate users from > today state to future state in a reasonable manner. If we could teach > OSC how to handle the same command being defined in multiple plugins > properly (hello entrypoints!) it could be much simpler as we could > start creating the new plugins and switch as the new command > implementations become available rather than having a hard cutover. > > Or maybe the definition of OSC v4 is as above and we just work at it > until complete and cut over at the end. Note that the current APIs > that are in-repo (Compute, Identity, Image, Network, Object, Volume) > are all implemented using the plugin structure, OSC v4 could start as > the breaking out of those without command changes (except new > migration commands!) and then the plugins all re-write and update at > their own tempo. Dang, did I just deconstruct my project? It sure sounds like it. Congratulations! I like the idea of moving the existing code into libraries, having python-openstackclient depend on them, and then asking project teams for more help with them. > One thing I don't like about that is we
Re: [openstack-dev] [goal][python3] week 7 update
Doug Hellmann writes: > == Things We Learned This Week == > > When we updated the tox.ini settings for jobs like pep8 and release > notes early in the Rocky session we only touched some of the official > repositories. I'll be working on making a list of the ones we missed so > we can update them by the end of Stein. I see quite a few repositories with tox settings out of date (about 350, see below). Given the volume, I'm going to prepare the patches and propose them a few at a time over the next couple of weeks. As background, each repo needs a patch (to master only) that looks like [1]. It needs to set the "basepython" parameter in all of the relevant tox environments to "python3" to force using python 3. It is most important to set the docs, linters, pep8, releasenotes, lower-constraints and venv environments, but we also wanted to include bindep and cover if they are present. The patches I prepare will update all of those environments. We should also include any other environments that run jobs, but teams may want to duplicate some (and add the relevant jobs) rather than changing all of the functional test jobs. As with the other functional job changes, I will leave those up to the project teams. As the commit message on [1] explains, we are using "python3" on purpose: * We do not want to specify a minor version number, because we do not want to have to update the file every time we upgrade python. * We do not want to set the override once in testenv, because that breaks the more specific versions used in default environments like py35 and py36 (at least under older versions of tox). In case you want to watch for them, all of the new patches will use "fix tox python3 overrides" as the first line of the commit message (the tracking tool looks for that string). Doug [1] https://review.openstack.org/#/c/573355/ __ 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] [goals][tc][ptl][uc] starting goal selection for T series
Monty Taylor writes: > On 09/26/2018 01:55 PM, Tim Bell wrote: >> >> Doug, >> >> Thanks for raising this. I'd like to highlight the goal "Finish moving >> legacy python-*client CLIs to python-openstackclient" from the etherpad and >> propose this for a T/U series goal. >> >> To give it some context and the motivation: >> >> At CERN, we have more than 3000 users of the OpenStack cloud. We write an >> extensive end user facing documentation which explains how to use the >> OpenStack along with CERN specific features (such as workflows for >> requesting projects/quotas/etc.). >> >> One regular problem we come across is that the end user experience is >> inconsistent. In some cases, we find projects which are not covered by the >> unified OpenStack client (e.g. Manila). In other cases, there are subsets of >> the function which require the native project client. >> >> I would strongly support a goal which targets >> >> - All new projects should have the end user facing functionality fully >> exposed via the unified client >> - Existing projects should aim to close the gap within 'N' cycles (N to be >> defined) >> - Many administrator actions would also benefit from integration (reader >> roles are end users too so list and show need to be covered too) >> - Users should be able to use a single openrc for all interactions with the >> cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) >> >> The end user perception of a solution will be greatly enhanced by a single >> command line tool with consistent syntax and authentication framework. >> >> It may be a multi-release goal but it would really benefit the cloud >> consumers and I feel that goals should include this audience also. > > ++ > > It's also worth noting that we're REALLY close to a 1.0 of openstacksdk > (all the patches are in flight, we just need to land them) - and once > we've got that we'll be in a position to start shifting > python-openstackclient to using openstacksdk instead of python-*client. > > This will have the additional benefit that, once we've migrated CLIs to > python-openstackclient as per this goal, and once we've migrated > openstackclient itself to openstacksdk, the number of different > libraries one needs to install to interact with openstack will be > _dramatically_ lower. Would it be useful to have the SDK work in OSC as a prerequisite to the goal work? I would hate to have folks have to write a bunch of things twice. Do we have any sort of list of which projects aren't currently being handled by OSC? If we could get some help building such a list, that would help us understand the scope of the work. As far as admin features, I think we've been hesitant to add those to OSC in the past, but I can see the value. I wonder if having them in a separate library makes sense? Or is it better to have commands in the tool that regular users can't access, and just report the permission error when they try to run the command? Doug > >> -Original Message- >> From: Doug Hellmann >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Wednesday, 26 September 2018 at 18:00 >> To: openstack-dev , openstack-operators >> , openstack-sigs >> >> Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T >> series >> >> It's time to start thinking about community-wide goals for the T series. >> >> We use community-wide goals to achieve visible common changes, push for >> basic levels of consistency and user experience, and efficiently improve >> certain areas where technical debt payments have become too high - >> across all OpenStack projects. Community input is important to ensure >> that the TC makes good decisions about the goals. We need to consider >> the timing, cycle length, priority, and feasibility of the suggested >> goals. >> >> If you are interested in proposing a goal, please make sure that before >> the summit it is described in the tracking etherpad [1] and that you >> have started a mailing list thread on the openstack-dev list about the >> proposal so that everyone in the forum session [2] has an opportunity to >> consider the details. The forum session is only one step in the >> selection process. See [3] for more details. >> >> Doug >> >> [1]
Re: [openstack-dev] [storyboard][oslo] Fewer stories than bugs?
Ben Nemec writes: > Okay, I found a few bugs that are in launchpad but not storyboard: > > https://bugs.launchpad.net/python-stevedore/+bug/1784823 > https://bugs.launchpad.net/pbr/+bug/1777625 > https://bugs.launchpad.net/taskflow/+bug/1756520 > https://bugs.launchpad.net/pbr/+bug/1742809 > > The latter three are all in an incomplete state, so maybe that's being > ignored by the migration script? The first appears to be a completely > missing project. None of the stevedore bugs I've spot checked are in > storyboard. Maybe it has to do with the fact that the project name is > stevedore but the bug link is python-stevedore? I'm not sure why that > is, but there may be something a little weird going on with that > project. The name "stevedore" was taking on LP when I registered that project, so I had to use an alternative name. Doug __ 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] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Jeremy Stanley writes: > On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote: > [...] >> It tests the release automation machinery to identify problems >> before the RC and final release crunch time. > [...] > > More to the point, it helped spot changes to projects which made it > impossible to generate and publish their release artifacts. Coverage > has improved for finding these issues before merging now, as well as > in flight tests on proposed releases, making the risk lower than it > used to be. The new set of packaging jobs that are part of the publish-to-pypi-python3 project template also include a check queue job that runs when any of the packaging files (setup.*, README.rst, etc.) are modified. That should give us an even earlier warning of any packaging failures. Since all python projects will soon use the same release jobs, we will know that the job is working in general based on other releases (including more liberal use of our test repository before big deadlines). Doug __ 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] [goals][tc][ptl][uc] starting goal selection for T series
It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html __ 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] [goal][python3] week 7 update
This is week 7 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).
== Things We Learned This Week ==
When we updated the tox.ini settings for jobs like pep8 and release
notes early in the Rocky session we only touched some of the official
repositories. I'll be working on making a list of the ones we missed so
we can update them by the end of Stein.
== Ongoing and Completed Work ==
Teams are making great progress, but it looks like we have some
lingering changes in branches where the test jobs are failing.
+-+-+--+-+--+-++---++
| Team| zuul| tox defaults | Docs| 3.6 unit | Failing |
Unreviewed | Total | Champion |
+-+-+--+-+--+-++---++
| adjutant| + | -| - | +| 0 |
0 | 5 | Doug Hellmann |
| barbican| 11/ 13 | +| 1/ 3 | +| 6 |
4 |20 | Doug Hellmann |
| blazar | + | +| + | +| 0 |
0 |25 | Nguyen Hai |
| Chef OpenStack | + | -| - | -| 0 |
0 | 1 | Doug Hellmann |
| cinder | + | +| + | +| 0 |
0 |31 | Doug Hellmann |
| cloudkitty | + | +| + | +| 0 |
0 |24 | Doug Hellmann |
| congress| + | +| + | +| 0 |
0 |24 | Nguyen Hai |
| cyborg | + | +| + | +| 0 |
0 |16 | Nguyen Hai |
| designate | + | +| + | +| 0 |
0 |24 | Nguyen Hai |
| Documentation | + | +| + | +| 0 |
0 |22 | Doug Hellmann |
| dragonflow | + | -| + | +| 0 |
0 | 6 | Nguyen Hai |
| ec2-api | + | -| + | +| 0 |
0 |12 ||
| freezer | 3/ 23 | +| + | 2/ 4 | 2 |
0 |33 ||
| glance | + | 1/ 4 | + | +| 0 |
0 |26 | Nguyen Hai |
| heat| 3/ 27 | 1/ 5 | 1/ 6 | 1/ 7 | 3 |
2 |45 | Doug Hellmann |
| horizon | + | +| + | +| 0 |
0 |11 | Nguyen Hai |
| I18n| + | -| - | -| 0 |
0 | 2 | Doug Hellmann |
| InteropWG | + | -| + | 1/ 3 | 0 |
0 |10 | Doug Hellmann |
| ironic | 12/ 60 | +| 2/ 13 | 1/ 12 | 0 |
0 |90 | Doug Hellmann |
| karbor | + | +| + | +| 0 |
0 |22 | Nguyen Hai |
| keystone| + | +| + | +| 0 |
0 |47 | Doug Hellmann |
| kolla | + | -| + | +| 0 |
0 |12 ||
| kuryr | + | +| + | +| 0 |
0 |19 | Doug Hellmann |
| magnum | + | +| + | +| 0 |
0 |24 ||
| manila | 3/ 19 | +| + | +| 3 |
3 |28 | Goutham Pacha Ravi |
| masakari| + | +| + | -| 0 |
0 |21 | Nguyen Hai |
| mistral | + | +| + | +| 0 |
0 |37 | Nguyen Hai |
| monasca | 1/ 66 | 1/ 7 | + | +| 2 |
1 |90 | Doug Hellmann |
| murano | + | +| + | +| 0 |
0 |37 ||
| neutron | 21/ 73 | +| 2/ 14 | 2/ 13 | 11 |
12 | 106 | Doug Hellmann |
| nova| + | +| + | +| 0 |
0 |37 ||
| octavia | + | +| + | +| 0 |
0 |34 | Nguyen Hai |
| OpenStack Charms| 17/117 | -| - | -| 14 |
17 | 117
Re: [openstack-dev] [storyboard] Prioritization?
Adam Coldrick writes: > On Mon, 2018-09-24 at 22:47 +, Jeremy Stanley wrote: >> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote: >> [...] >> > At the PTG there was feedback from at least one team that >> > consumers of the data in storyboard want a priority setting on >> > each story. Historically the response to that has been that >> > different users will have different priorities, so each of them >> > using worklists is the best way to support those differences of >> > opinion. >> > >> > I think we need to reconsider that position if it's going to block >> > adoption. I think Ben's case is an excellent second example of >> > where having a field to hold some sort of priority value would be >> > useful. > > I'm strongly against reverting to having a single global priority value > for things in StoryBoard, especially so for stories as opposed to tasks. > Having a single global priority field for stories at best implies that a > cross-project story has the same priority in each project, and at worst > means cross-project discussions need to occur to find an agreement on an > acceptable priority (or one affected project's opinion overrules the > others, with the others' priorities becoming harder to understand at a > glance or just completely lost). I would be fine with 1 field per task. > For tasks I am less concerned in that aspect since cross-project support > isn't hurt, but remain of the opinion that a global field is the wrong > approach since it means that only one person (or group of people) gets to > visibly express their opinion on the priority of the task. While I agree that not everyone attaches the same priority to a given task, and it's important for everyone to be able to have their own say in the relative importance of tasks/stories, I think it's more important than you're crediting for downstream consumers to have a consistent way to understand the priority attached by the person(s) doing the implementation work. > Allowing multiple groups to express opinions on the priority of the same > tasks allows situations where (to use a real world example I saw recently, > but not in OpenStack) an upstream project marks a bug as medium priority > for whatever reason, but a downstream user of that project is completely > broken by that bug, meaning either providing a fix to it or persuading > someone else to is of critical importance to them. This example is excellent, and I think it supports my position. An important area where using boards or worklists falls short of my own needs is that, as far as I know, it is not possible to subscribe to notifications for when a story or task is added to a list or board. So as a person who submits a story, I have no way of knowing when the team(s) working on it add it to (or remove it from) a priority list or change its priority by moving it to a different lane in a board. Communicating about what we're doing is as important as gathering and tracking the list of tasks in the first place. Without a notification that the priority of a story or task has been lowered, how would I know that I need to go try to persuade the team responsible to raise it back up? Even if we add (or there is) some way for me to receive a notification based on board or list membership, without a real priority field we have several different ways to express priority (different tag names, a single worklist that's kept in order, a board with separate columns for each status, etc.). That means each team could potentially use a different way, which in turn means downstream consumers have to discover, understand, and subscribe to all of those various ways, and use them correctly, for every team they are tracking. I think that's an unreasonable burden to place on someone who is not working in the community constantly, as is the case for many of our operators who report bugs. > With global priority there is a trade-off, either the bug tracker displays > priorities with no reference as to who they are important to, downstream > duplicate the issue elsewhere to track their priority, or their expression > of how important the issue is is lost in a comment in order to maintain > the state of "all priorities are determined by the core team". I suppose that depends on the reason we're using the task tracker. If we're just throwing data into it without trying to use it to communicate, then I can see us having lots of different views of priority with the same level of "official-ness". I don't think that's what we're doing though. I think we're trying to help teams track what they've committed to do and *communicate* those commitments to folks outside of the team. And from that per
Re: [openstack-dev] [storyboard] Prioritization?
Jeremy Stanley writes: > On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote: > [...] >> At the PTG there was feedback from at least one team that >> consumers of the data in storyboard want a priority setting on >> each story. Historically the response to that has been that >> different users will have different priorities, so each of them >> using worklists is the best way to support those differences of >> opinion. >> >> I think we need to reconsider that position if it's going to block >> adoption. I think Ben's case is an excellent second example of >> where having a field to hold some sort of priority value would be >> useful. > > The alternative suggestion, for teams who want to be able to flag > some sort of bucketed priorities, is to use story tags. We could > even improve the import tool to accept some sort of > priority-to-tag-name mapping so that, say, when we import bugs for > Oslo their oslo-critical tag is applied to any with a critical > bugtask, oslo-medium to any with medium priority tasks, and so on. > Not all teams using StoryBoard will want to have a bucketed priority > scheme, and those who do won't necessarily want to use the same > number or kinds of priorities. That came up as a suggestion, too. The challenge there is that we cannot (as far as I know) sort on tags. So even if we have tags, we can't create a list of stories that is ordered automatically based on the priority. Maybe there's a solution to that? Doug __ 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] [storyboard] Prioritization?
Ben Nemec writes: > Hi, > > This came up in the Oslo meeting as a result of my initial look at the > test Storyboard import. It appears all of the priority data from > launchpad gets lost in the migration, which is going to make organizing > hundreds of bugs somewhat difficult. I'm particularly not fond of it > after spending last cycle whittling down our untriaged bug list. :-) > > Work lists and tags were mentioned as possible priority management tools > in Storyboard, so is there some way to migrate launchpad priorities into > one of those automatically? If not, are there any plans to add that? > > It sounded like a similar conversation is happening with a few other > teams so we wanted to bring the discussion to the mailing list for > visibility. > > Thanks. > > -Ben At the PTG there was feedback from at least one team that consumers of the data in storyboard want a priority setting on each story. Historically the response to that has been that different users will have different priorities, so each of them using worklists is the best way to support those differences of opinion. I think we need to reconsider that position if it's going to block adoption. I think Ben's case is an excellent second example of where having a field to hold some sort of priority value would be useful. Doug __ 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][ironic][tripleo][oslo][neutron] recovering from today's release failures
Doug Hellmann writes: > Earlier today a bad version of twine (1.12.0) caused issues with many of > the release jobs that were trying to publish artifacts to > pypi.python.org. I didn't notice those failures until after all of the > releases had been processed, unfortunately, which left us with quite a > few broken releases to try to recover from. > > After working out the cause of the problem, and finding that in fact > some, but not all, of the release artifacts were published, we started > making a list of the manual recovery steps we would have to take. And > that list was really really long. > > So, instead of doing all of that, we're going to re-tag the releases, > using new version numbers, to produce good artifacts. I have prepared > https://review.openstack.org/#/c/604875/ to do this. > > I will also run some tests to ensure the publishing works before > approving those re-releases. > > Sorry for the inconvenience, > Doug We've had a few release requests come in since this email, so I want to make sure everyone understands that we're going to wait to sort out the issues we already have before releasing anything else. The test release is waiting in the check queue still, so it's likely to be a while before we know for sure that things are working. Doug __ 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] [release][ironic][tripleo][oslo][neutron] recovering from today's release failures
Earlier today a bad version of twine (1.12.0) caused issues with many of the release jobs that were trying to publish artifacts to pypi.python.org. I didn't notice those failures until after all of the releases had been processed, unfortunately, which left us with quite a few broken releases to try to recover from. After working out the cause of the problem, and finding that in fact some, but not all, of the release artifacts were published, we started making a list of the manual recovery steps we would have to take. And that list was really really long. So, instead of doing all of that, we're going to re-tag the releases, using new version numbers, to produce good artifacts. I have prepared https://review.openstack.org/#/c/604875/ to do this. I will also run some tests to ensure the publishing works before approving those re-releases. Sorry for the inconvenience, Doug __ 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/group-based-policy failed
z...@openstack.org writes: > Build failed. > > - release-openstack-python > http://logs.openstack.org/7a/7abbf9af380eb236908f4d41d56e4cb1a0c2f135/release/release-openstack-python/ac1d5ab/ > : FAILURE in 8m 44s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED > > ___ > Release-job-failures mailing list > release-job-failu...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures The release-openstack-python job keeps failing with an SSL module error. It is currently running tox under python 2, and SSL support there has been steadily getting worse over time. I suggest trying to fix the release job by either updating the tox environment in the repo to use python 3, or switching to the new publish-to-pypi-python3 template which runs a job that uses python 3. See [1] for an example. Doug [1] https://review.openstack.org/#/c/598323 __ 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] Capturing Feedback/Input
Melvin Hillsman writes: > On Fri, Sep 21, 2018 at 11:16 AM Doug Hellmann > wrote: > >> Maybe we're overthinking the organization on this. What is special about >> the items that would be on this list compared to items opened directly >> against projects? >> > > Yeah unfortunately we do have a tendency to overthink/complicate things. > Not saying Storyboard is the right tool but suggested rather than having > something extra to maintain was what I understood. There are at least 3 > things that were to be addressed: > > - single pane so folks know where to provide/see updates > - it is not a catchall/dumpsite > - something still needs to be flushed out/prioritized (Public Cloud WG's > missing features spreadsheet for example) > - not specific to a single project (i thought this was a given since there > is already a process/workflow for single project) > > I could very well be wrong so I am open to be corrected. From my > perspective the idea in the room was to not circumvent anything internal > but rather make it easy for external viewers, passerbys, etc. When feedback > is gathered from Ops Meetup, OpenStack Days, Local meetups/events, we > discussed putting that here as well. Those are all good points. Sorry for making you rehash stuff that was already discussed. So I guess the idea is to have a place where several groups can track their own backlogs, but then a prioritized list can be created from those separate backlogs? In the Storyboard data model, that sounds like separate projects for each SIG or WG, and then 1 worklist that they all manually update with their priority items. I say "manually" because if we just combine all of the backlogs we don't have any good way to order the items and select the top N. Doug __ 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] Are we ready to put stable/ocata into extended maintenance mode?
Excerpts from Elõd Illés's message of 2018-09-21 16:08:28 +0200: > Hi, > > Here is an etherpad with the teams that have stable:follow-policy tag on > their repos: > > https://etherpad.openstack.org/p/ocata-final-release-before-em > > On the links you can find reports about the open and unreleased changes, > that could be a useful input for the before-EM/final release. > Please have a look at the report (and review the open patches if there > are) so that a release can be made if necessary. > > Thanks, > > Előd Thanks for pulling all of this information together! Doug __ 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] please vote
A few hours ago Emmet reported that we have around 20% participation in the Technical Committee election, so far. I think we can do better. Our community is founded on the idea that the contributors should decide how the project is run. PTL and TC elections are the most explicit example of this principle in action. The people elected to the TC this term will be representing your interests to the Board as the Foundation continues to evolve and expand its scope with new focus areas and projects. They also will continue to work on building and sustaining the community, choosing and organizing series goals, and making decisions that have long term effects on the project. Please take a few minutes to look at Kendall's instructions[1], find your ballot email, and think about which candidates you want to have on the committee. Then cast your vote, today. Doug [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134820.html __ 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
