[openstack-dev] [os-upstream-institute] Today's meeting is cancelled
Hi All, Today’s meeting is cancelled due to travels this week. Please keep an eye on the open reviews and do any last minute fixes on the material that you can find. Safe travels to those of you who’re coming to Sydney! Best Regards, Ildikó (IRC: ildikov) __ 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] [neutron][classifier] CCF Meeting
Hi everyone. Reminder that the Common Classification Framework meeting is at 14:00 UTC. The Agenda can be found here: https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#All_Meetings.27_Agendas Regards. David. __ 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] [all] TC Report 43
Mike Perez wrote: > On 11:17 Oct 25, Flavio Percoco wrote: >> On 24/10/17 19:26 +0100, Chris Dent wrote: >>> It's clear that anyone and everyone _could_ write their own blogs and >>> syndicate to the [OpenStack planet](http://planet.openstack.org/) but >>> this doesn't have the same panache and potential cadence as an >>> official thing _might_. It comes down to people having the time. Eking >>> out the time for this blog, for example, can be challenging. >>> >>> Since this is the second [week in a >>> row](https://anticdent.org/tc-report-42.html) that Josh showed up with >>> an idea, I wonder what next week will bring? >> >> I might not be exactly the same but, I think the superuser's blog could be a >> good place to do some of this writing. There are posts of various kinds in >> that >> blog: technical, community, news, etc. I wonder how many folks from the >> community are aware of it and how many would be willing to contribute to it >> too. >> Contributing to the superuser's blog is quite simple, really. > > Anne used to do TC updates and they were posted to the OpenStack Blog: > > https://www.openstack.org/blog/category/technical-committee-updates/ Those were actually officially published by the Technical Committee (prepared by the "communications" workgroup that Anne was leading), so they were reviewed by TC members and represented the consensual view. There are really only two options: Editorial content to some official publication, where the posts are vetted by a review committee for correctness/consensus: that's what SuperUser is doing, and what the "official blog" was(?) doing. Personal content, where opinionated blogs are automatically aggregated with minimal on-topic checks: that's what the planet is doing. (Sometimes, a personal blog post makes great SuperUser content and is copied over) We could add a specific, technically-focused editorial outlet, or we could set up a specific, technically-focused personal blog aggregator. But I feel like we could also reuse the SuperUser publication and the existing Planet. The main issue seems to be the lack of produced content, rather than lack of discoverability of the existing outlets... -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [forum] Sydney Forum etherpad list
Hi everyone, Etherpads for the Forum sessions in Sydney can be found here: https://wiki.openstack.org/wiki/Forum/Sydney2017 If you are moderating such a session and the etherpad is missing, please add it ! -- Thierry Carrez (ttx) __ 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] Release countdown for week R-16 and R-15, November 4-17
Just what you've been waiting for, our regular release countdown email. Development Focus - With Queens-1 passed and the Summit/Forum, teams should be focusing on feature development and release goals. We believe all issues have been addressed with the release jobs and things should be back to "normal". Please let us know if you see anything out of the ordinary with release artifacts. For those attending the Forum, this should be a great week for getting feedback on existing and planned features and bringing that feedback to the team. General Information --- There are several projects following cycle-with-milestones that have not done a Queens-1 release: congress-dashboard, freezer[-web-ui], manila, searchlight[-ui], senlin, trove[-dashboard] We also have cycle-with-intermediary projects without a release yet. Please take a look and see if these are ready to do a release for this cycle yet. It's best to "release early, release often". aodh, ceilometer, ceilometermiddleware, django_openstack_auth, glance-store, heat-translator, ironic[-ui], karbor[-dashboard], keystonemiddleware, kolla[-ansible], kuryr-kubernetes, ldappool, manila-ui, mistral-lib, monasca-ceilometer, monasca-kibana-plugin, monasca-thresh, mox3, murano-agent, networking-hyperv, neutron-fwaas-dashboard, os-brick, os-client-config, os-traits, os-vif, os-win, osc-lib, panko, patrole, pycadf, python-aodhclient, python-barbicanclient, python-brick-cinderclient-ext, python-ceilometerclient, python-cloudkittyclient, python-congressclient, python-designateclient, python-freezerclient, python-glanceclient, python-ironic-inspector-client, python-ironicclient, python-karborclient, python-keystoneclient, python-magnumclient, python-manilaclient, python-mistralclient, python-muranoclient, python-neutronclient, python-novaclient, python-octaviaclient, python-openstackclient, python-pankoclient, python-saharaclient, python-searchlightclient, python-senlinclient, python-solumclient, python-swiftclient, python-tackerclient, python-tricircleclient, python-troveclient, python-vitrageclient ,python-zaqarclient, python-zunclient, requestsexceptions, solum-dashboard, solum, swift, tacker-horizon, tosca-parser, tripleo-quickstart, vitrage-dashboard, vitrage, zun[-ui] And one note on stable releases - I took a quick look and there aren't too many projects with merged changes waiting for a stable release, but there are a few projects that do have a sizable list. Make sure to do regular stable releases, assuming there are bugfixes ready to be made available. Upcoming Deadlines & Dates -- Forum at OpenStack Summit in Sydney: November 6-8 Queens-2 Milestone: December 7 -- Sean McGinnis (smcginnis) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
On Mon, Oct 30, 2017 at 9:46 PM, Doug Hellmann wrote: > Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100: > > Hi all, > > > > So far driver requirements [1] have been managed outside of > global-requirements. > > This was mostly necessary because some dependencies were not on PyPI. > This is no > > longer the case, and I'd like to consider managing them just like any > other > > dependencies. Pros: > > 1. making these dependencies (and their versions) more visible for > packagers > > 2. following the same policies for regular and driver dependencies > > 3. ensuring co-installability of these dependencies with each other and > with the > > remaining openstack > > 4. potentially using upper-constraints in 3rd party CI to test what > packagers > > will probably package > > 5. we'll be able to finally create a tox job running unit tests with all > these > > dependencies installed (FYI these often breaks in RDO CI) > > > > Cons: > > 1. more work for both the requirements team and the vendor teams > > 2. inability to use ironic release notes to explain driver requirements > changes > > 3. any objections from the requirements team? > > > > If we make this change, we'll drop driver-requirements.txt, and will use > > setuptools extras to list then in setup.cfg (this way is supported by > g-r) > > similar to what we do in ironicclient [2]. > > > > We either will have one list: > > > > [extras] > > drivers = > >sushy>=a.b > >python-dracclient>=x.y > >python-prolianutils>=v.w > >... > > > > or (and I like this more) we'll have a list per hardware type: > > > > [extras] > > redfish = > >sushy>=a.b > > idrac = > >python-dracclient>=x.y > > ilo = > >... > > ... > > > > WDYT? > > The second option is what I would expect. > > I also would prefer option 2 (per driver extras), with a catch-all [all] extra to install all of those in one short command I have a separate concern about ansible-deploy interface. It obviously depends on Ansibe, but so does most of upstream infra. I am not sure if adding (somehow restricted) Ansible to g-r won't break anything. Doug > > > > > [1] https://github.com/openstack/ironic/blob/master/driver- > requirements.txt > > [2] https://github.com/openstack/python-ironicclient/blob/ > master/setup.cfg#L115 > > > > __ > 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 > -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] onboarding session in Sydney
Anyone interested by TripleO and going to Sydney, We'll hold an onboarding session during the Summit, on Monday 6th at 4.20pm in C4.7 room. https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20438/tripleo-project-onboarding Everything will be tracked on this etherpad [1]. What to expect from this session: - Meet TripleO contributors - Ask any question, any help, on anything related to TripleO - Learn where to get started, how to contribute and how things work What to *not* expect: - an agenda (the session is driven by people in the room) - a presentation about our roadmap (we have a session for that, see [2] We're really exciting to hold this session for a second time, we're looking forward to meeting you there! [1] https://etherpad.openstack.org/p/SYD-forum-tripleo-onboarding [2] https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20398/tripleo-project-update -- Emilien Macchi on behalf of the TripleO team __ 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] [skip-level-upgrades][fast-forward-upgrades] PTG summary
The etherpad for the Fast-Forward Upgrades session at the Sydney forum is here: https://etherpad.openstack.org/p/SYD-forum-fast-forward-upgrades Please help us flesh it out and frame the discussion to make the best use of our time. I have included reference materials from previous sessions to use as a starting point. Thanks to everyone for participating! Cheers, Erik On Mon, Oct 30, 2017 at 11:25 PM, wrote: > See you there Eric. > > > > From: Erik McCormick [mailto:emccorm...@cirrusseven.com] > Sent: Monday, October 30, 2017 10:58 AM > To: Matt Riedemann > Cc: OpenStack Development Mailing List ; > openstack-operators > Subject: Re: [openstack-dev] [Openstack-operators] > [skip-level-upgrades][fast-forward-upgrades] PTG summary > > > > > > > > On Oct 30, 2017 11:53 AM, "Matt Riedemann" wrote: > > On 9/20/2017 9:42 AM, arkady.kanev...@dell.com wrote: > > Lee, > I can chair meeting in Sydney. > Thanks, > Arkady > > > > Arkady, > > Are you actually moderating the forum session in Sydney because the session > says Eric McCormick is the session moderator: > > > > I submitted it so it gets my name on it. I think Arkady and I are going to > do it together. > > > > https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20451/fast-forward-upgrades > > People are asking in the nova IRC channel about this session and were told > to ask Jay Pipes about it, but Jay isn't going to be in Sydney and isn't > involved in fast-forward upgrades, as far as I know anyway. > > So whoever is moderating this session, can you please create an etherpad and > get it linked to the wiki? > > https://wiki.openstack.org/wiki/Forum/Sydney2017 > > > > I'll have the etherpad up today and pass it among here and on the wiki. > > > > > > -- > > Thanks, > > Matt > > > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
On 17:51 Oct 30, Dmitry Tantsur wrote: > Hi all, > > So far driver requirements [1] have been managed outside of > global-requirements. This was mostly necessary because some dependencies > were not on PyPI. This is no longer the case, and I'd like to consider > managing them just like any other dependencies. Pros: > 1. making these dependencies (and their versions) more visible for packagers > 2. following the same policies for regular and driver dependencies > 3. ensuring co-installability of these dependencies with each other and with > the remaining openstack > 4. potentially using upper-constraints in 3rd party CI to test what > packagers will probably package > 5. we'll be able to finally create a tox job running unit tests with all > these dependencies installed (FYI these often breaks in RDO CI) I noticed Cinder is doing this with drivers, but in a different file: http://git.openstack.org/cgit/openstack/cinder/tree/driver-requirements.txt -- Mike Perez pgpjj5AdeWm9b.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding
On 02:34 Oct 24, Dave McCowan (dmccowan) wrote: > We're working on the Barbican Onboarding session now. I don't think our > Boston session went very well, and the results borne out; we were unable to > convert any attendee to active contributor. It was a much bigger group than > I was expecting and everyone was at a different starting point . I was > unprepared for both of those situations. > > I'd like to hear some success stories from Boston to learn from. > > For projects that were successful, what topics did you cover? > For prospective Sydney Onboarders, what do you want to learn at these > sessions? An effort we talked about at the last PTG and finally surfaced is the contributor portal [1] and contributor guide [2]. The portal is a good landing page to explore different projects and their contributor guides listed in the project yaml [3]. The contributor guide is included on the portal and the hope is people go through that first which includes general topics like irc setup, account setup and git setup. More people can contribute general topics so all projects benefit. The contributor guide should at least cover those topics for you to have groups break off and do. Then you can spend your preparing time on other topics like team specific topics and tools. If anyone has time and wants to help all projects choosing to use this guide, read my previous post [3] announcing this project and asking for help. [1] - https://www.openstack.org/community/ [2] - https://docs.openstack.org/contributors/ [3] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/123740.html -- Mike Perez pgpECvMlJObHd.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Next team meeting canceled
Hi all, unless there is a person who wants to chair our next Tuesday meeting, I'd like to cancel it due to OpenStack Summit. If there is a person who wants to run it, please speak up :) Thanks, Jakub __ 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] [docs] Request for docs team vision review (was: Evidence of Success)
Hi all, Changing the subject line for greater visibility. The docs team would appreciate it if more people from the community could provide feedback on our brand new 2017/2018 docs team vision document here: https://review.openstack.org/#/c/514779/ If the future of OpenStack documentation is of interest to you, please have a look and let us know what you think. This is a great chance to provide input on what you think the OpenStack docs community should focus on in the next 12 months or so. Thank you, pk On Fri, 27 Oct 2017 16:20:27 +0200 Petr Kovar wrote: > On Tue, 17 Oct 2017 17:27:10 +0200 > Petr Kovar wrote: > > > Thanks for your feedback, everybody. I made some more edits to the > > document and tried to address the remaining comments left in the etherpad. > > > > I think the current revision of the doc provides enough details on > > the metrics and goals, so it should be ready to be added to > > https://docs.openstack.org/doc-contrib-guide/ as an official project doc. > > Let us know if you have more comments. > > Just a quick update that a final review of the vision document can be found > here: > > https://review.openstack.org/#/c/514779/ > > Would be good to get move votes from the docs team and the community, > so please have a look. > > Thanks, > pk > > __ > 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 -- Petr Kovar Sr. Technical Writer | Customer Content Services Red Hat Czech, Brno __ 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] [horizon] Fetch resources in parallel
Hi team, We all know that unfortunately Horizon's performance not good enough in some cases. That's why we try to fix it on both sides: client-side and server-side. I would like to talk mostly about server-side now. On some views, we use 'futurist' library [1] to fetch resources from API's in parallel. I've filed a blueprint for this effort [2]. You can find some work in progress patches in the Gerrit. For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources from APIs. It requires some specific Apache configuration changes to allow WSGI app to create threads. It means, our code execution depends on Apache mod_wsgi configuration. To avoid this, we can use futurist.GreenThreadPoolExecutor. It uses eventlet green threads which can be used to speed-up I/O operations like 'call external API'. I did very simple performance testing [3] with proposed patch [4] for volumes views. My tests are not ideal but you can see how it's going with green thread. I propose to switch to the futurist.GreenThreadPoolExecutor and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will speed up parallel API calls and make Horizon independent on Apache or other web server configuration. I added this topic to the next weekly meeting agenda [5] so we can discuss it there too. [1] https://github.com/openstack/futurist/ [2] https://blueprints.launchpad.net/horizon/+spec/fetch-resources-in-parallel [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing [4] https://review.openstack.org/#/c/426493/ [5] https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_for_Next_Meeting Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [docs] Documentation new meeting time - Wednesday at 16:00 UTC
Hi all, Based on the input provided by the docs community, we are changing the docs meeting day from Thursday to Wednesday. Another change is that we'll meet in #openstack-doc. The time of the day remains the same. To reiterate, we'll meet tomorrow, 1st November at 16:00 UTC in #openstack-doc. For more details, and the agenda, see the meeting page: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting Thank you, pk __ 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] [ironic] testing ansible-deploy in gates
Hi all, as we have agreed on the PTG, we are about to pull the ansible-deploy interface from ironic-staging-drivers to ironic. We obviously need to test it on gates too, in a non-voting mode like snmp and redfish ones. This raises couple of questions/concerns: 1. Testing hardware types on gates. This is the first? interface that does not have any "classic" driver associated with it. All our devstack setup logic is currently based on classic drivers instead of hardware types, in particular all the "is_deployed_by" functions and logic depending on them. As we are about to deprecate the classic drivers altogether and eventually remove them, we ought to start moving our setup and testing procedures to hardware types as well. (another interesting point would be how much effort we need to adapt all our unit tests to use hw types instead of 'fake' and other classic drivers...) 2. Deploy ramdisk image to use. Current job in staging drivers does small rebuild of tinyipa image during deploy. I'd like to avoid it as much as possible, so I propose to add all the logic which is there to default build options and scripts of tinyipa build. This includes installing SSH server and enabling SSH access to the ramdisk, and some small mangling with files and file links. A separate question would be SSH keys. We could either not bake them to the image and generate them each time anew, but that would still require an image rebuild on (each?) devstack run. Or we could generate them once, bake the public key to the image and publish the private key to tarballs.o.o, so it could be re-used by IPA scripts and jobs to build fresh images on merge and during tests. There are surely certain security consideration to such approach, but as tinyipa is targeted for testing (virtual) environments and not production, I suppose we could probably neglect them. WDYT? Another aspect of this is (as we agreed) we would need to move all the 'imagebuild' folder content from IPA repo to a separate repo, and devise a way to use this repo in our devstack plugin. I'm eager to hear your thoughts and comments. Best regards, -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ 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] [ironic][tempest][qa] dropping the ironic-inspector-tempest-plugin repo
Hi all, there exists this repo http://git.openstack.org/cgit/openstack/ironic-inspector-tempest-plugin. It is basically empty and there's a single pending review adding initial cookiecutter-generated project stuff. I am not sure who/how asked for creation of this project (may be automated for the x-project goal?), but eventually Ironic community decided to keep tempest tests for both ironic and ironic-inspector in a single repo 'ironic-tempest-plugin' (work of moving ironic tests there is in progress, inspector will follow). Thus a question to QA/tempest team - would that play nice with tempest and scripts/logic around running it on gates if two separate projects with different names would have a common tempest plugin project? If yes, then we should request to delete this 'ironic-inspector-tempest-plugin' project as it is and will be empty and useless, just confusing users. If not, ironic community probably might have to re-assess its decision... Cheers, -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ 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] TC Report 44
There's been a fair bit of various TC discussion but as I'm packing for my rather tortured journey to [Sydney](https://www.openstack.org/summit/sydney-2017/) and preparing some last minute presentation materials, just a short TC Report this week, made up of links to topics in the IRC logs: * [Can openstack do self-healing?](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-24.log.html#t2017-10-24T21:37:33) This continues into the [following day](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-25.log.html#t2017-10-25T00:57:06). This discussion sort of asks "what are we actually trying to do here?" and seems to indicate there's a lot of missing functionality, depending on your use case and perspective. * [Planning Sydney and Dublin meetings with the board](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-25.log.html#t2017-10-25T13:36:27). * [More board meeting planning, and other summit planning](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-26.log.html#t2017-10-26T13:08:15). I will attempt to take notes at the board meeting and report them here. There will be no TC report next week due to summit. Nor the week after as I'll still be in Sydney, so expect the next one 21st of November. -- 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
Re: [openstack-dev] [horizon] Fetch resources in parallel
Just forgot to mention one other option: we can use celery [6] too but I didn't do any performance testing with it. This solution will be more complex. [6] http://www.celeryproject.org/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Oct 31, 2017 at 7:15 PM, Ivan Kolodyazhny wrote: > Hi team, > > We all know that unfortunately Horizon's performance not good enough in > some cases. That's why we try to fix it on both sides: client-side and > server-side. > > I would like to talk mostly about server-side now. On some views, we use > 'futurist' library [1] to fetch resources from API's in parallel. I've > filed a blueprint for this effort [2]. You can find some work in progress > patches in the Gerrit. > > For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources > from APIs. It requires some specific Apache configuration changes to allow > WSGI app to create threads. It means, our code execution depends on Apache > mod_wsgi configuration. > > To avoid this, we can use futurist.GreenThreadPoolExecutor. It > uses eventlet green threads which can be used to speed-up I/O operations > like 'call external API'. > > I did very simple performance testing [3] with proposed patch [4] for > volumes views. My tests are not ideal but you can see how it's going with > green thread. I propose to switch to the futurist.GreenThreadPoolExecutor > and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will > speed up parallel API calls and make Horizon independent on Apache or other > web server configuration. > > I added this topic to the next weekly meeting agenda [5] so we can discuss > it there too. > > > [1] https://github.com/openstack/futurist/ > [2] https://blueprints.launchpad.net/horizon/+spec/ > fetch-resources-in-parallel > [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ > ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing > [4] https://review.openstack.org/#/c/426493/ > [5] https://wiki.openstack.org/wiki/Meetings/Horizon# > Agenda_for_Next_Meeting > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Broken master promotion
Hi, for a little more than an hour, 21:35 - 22:40 UTC we had a new hash promoted as master, but it was broken, wasn't fully tested and was missing containers images. We reverted it to the last known good hash from September again and we managed to stop it from being propagated down the production chain. If one of your review was running a gate in master during that time, it probably picked the broken hash, and should be rerun. We isolated the problem, and we have another promotion run in about 1 hour. If that passes, (and at this point is likely to happen) it should be legit. Thanks. __ 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][election] Question for candidates: How do you think we can make our community more inclusive?
On 24 Oct 2017, at 4:47, Thierry Carrez wrote:
> Colleen Murphy wrote:
>> On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke
>> mailto:diana.joan.cla...@gmail.com>> wrote:
>>
>> Congrats on being elected to the TC, Colleen!
>>
>> You mentioned earlier in this thread that, "a major problem in the
>> tech world is not just attracting underrepresented contributors, but
>> retaining them".
>>
>> I'm curious if the TC has considered polling the people that have left
>> OpenStack for their experiences on this front.
>>
>> Something along the lines of:
>>
>> "I see you contributed 20 patches in the last cycle, but haven't
>> contributed recently, why did you stop contributing?".
>>
>> Given the recent layoffs, I suspect many of the responses will be
>> predicable, but you might find some worthwhile nuggets there
>> nonetheless.
>>
>> I'm not aware of such an initiative so far but I do think it would be
>> useful, and perhaps something we can partner with the foundation on.
>
> Kind of parallel to the polling idea:
>
> John Dickinson has some interesting scripts that he runs to detect
> deviation from a past contribution pattern (like someone who used to
> contribute a few patches per cycle but did not contribute anything over
> the past cycle, or someone who used to contribute a handful of patches
> per month who did not send a single patch over the past month). Once
> oddities in the contribution pattern are detected, he would contact the
> person to ask if anything happened or changed that made them stop
> contributing.
>
> John would probably describe it better than I did. I like that it's not
> just quantitative but more around deviation from an established
> contribution pattern, which lets him spot issues earlier.
That's a pretty good summary.
>
> Note that this sort of analysis works well when combined with personal
> outreach, which works better at project team level... If done at
> OpenStack level you would likely have more difficulty making it feel
> personal (if I end up reaching out to a Tacker dev that stopped
> contributing, it won't be as effective as if the Tacker PTL did the
> outreach). One thing we could do would be to productize those tools and
> make them available to a wider number of people.
TBH I haven't used these tools that much for a while. Between an increased an
increased personal reach-out ("Hey, what's going on?") and obvious stuff like
companies pulling away from OpenStack contributions, there haven't been any
surprises. Most of the active contributors have been pretty up-front about
their ability (or lack thereof) to contribute.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][tempest][qa] dropping the ironic-inspector-tempest-plugin repo
On Tue, Oct 31, 2017 at 08:22:10PM +0200, Pavlo Shchelokovskyy wrote: > Hi all, > > there exists this repo > http://git.openstack.org/cgit/openstack/ironic-inspector-tempest-plugin. > It is basically empty and there's a single pending review adding initial > cookiecutter-generated project stuff. > I am not sure who/how asked for creation of this project (may be automated > for the x-project goal?), > but eventually Ironic community decided to keep tempest tests for both > ironic and ironic-inspector in a single repo 'ironic-tempest-plugin' (work > of moving ironic tests there is in progress, inspector will follow). > > Thus a question to QA/tempest team - would that play nice with tempest and > scripts/logic around running it on gates if two separate projects with > different names would have a common tempest plugin project? > If yes, then we should request to delete this > 'ironic-inspector-tempest-plugin' project as it is and will be empty and > useless, just confusing users. > If not, ironic community probably might have to re-assess its decision... > I don't see anything wrong with this. The x-project goal is mostly about packaging for the plugins and ensuring we're actually doing branchless testing for all projects. It was always up to the project teams with plugins to maintain and organize the plugins however they saw fit. So if having 1 plugin for ironic and ironic-inspector makes the most sense that's what we should do. If a blank repo was created by someone for a separate ironic-inspector tempest plugin I think deleting that repo is fine. As for the mechanics of setting up the gate jobs, there aren't any complications with doing this. You just make sure you install the combined plugin on the test jobs for both projects and it should work fine. (this is actually part of the reason for the x-project goal, because doing this kind of thing with bundled in-tree plugins is much more difficult) -Matt Treinish signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpsMeetup 2018 March will be in Tokyo and registration is now open
Hi developers, I know everyone is busy planning for Sydney, but OpsMeetups Team is up for the next event and I like to raise awareness in the devs community as well. The registration page for the next OpsMeetup Midcycle in Tokyo (March 7-8 2018) is now open [1]. If you are new to OpsMeetup Midcycle, please check the wiki [2]. For more information on Tokyo Midcycle, check the wiki page for Tokyo [3]. It is not a pretty page yet, but will update with more information after Sydney. Please also join the agenda brainstorming on the etherpad [4] This time, we are planning to have "themed track" on couple of topics, and your feedback is more than welcome! OpsMeetups Team is having a catch up session at the Sydney summit, so if you are interested in knowing the team, please come join the session on Tue 15:20-16:00 [5]. [1] https://www.eventbrite.com/e/openstack-ops-midcycle-tokyo-tickets-39089912982 [2] https://wiki.openstack.org/wiki/Operations/Meetups [3] https://wiki.openstack.org/wiki/Operations/Meetups/TYO-ops-meetup [4] https://etherpad.openstack.org/p/TYO-ops-meetup-2018 [5] https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20481/ops-meetup-team-catch-up Hope to see you all in Tokyo next spring! Regards, Shintaro -- Shintaro MIZUNO (水野伸太郎) NTT Software Innovation Center TEL: 0422-59-4977 E-mail: mizuno.shint...@lab.ntt.co.jp __ 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] [oslo] No meeting next Monday( Nov 6)
Some of us will attend Sydney Summit, there is no urgent topic to discuss, so let's skip the meeting. -- ChangBo Guo(gcb) Community Director @EasyStack __ 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] [acceleration]Cyborg Team Weekly Meeting 2017.11.01
Hi Team, Sorry for meeting cancellation of past two weeks due to my biz travel, we will resume our weekly meeting today at #openstack-cyborg UTC 1500. Initial agenda could be found at https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting . -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
On Mon, Oct 30, 2017 at 05:51:49PM +0100, Dmitry Tantsur wrote: > Hi all, > > So far driver requirements [1] have been managed outside of > global-requirements. This was mostly necessary because some dependencies > were not on PyPI. This is no longer the case, and I'd like to consider > managing them just like any other dependencies. Pros: > 1. making these dependencies (and their versions) more visible for packagers > 2. following the same policies for regular and driver dependencies > 3. ensuring co-installability of these dependencies with each other and with > the remaining openstack > 4. potentially using upper-constraints in 3rd party CI to test what > packagers will probably package > 5. we'll be able to finally create a tox job running unit tests with all > these dependencies installed (FYI these often breaks in RDO CI) > > Cons: > 1. more work for both the requirements team and the vendor teams The biggest impact on the requirements team is the initial review to validate that the driver library meets all the criteria [1] There are 11 requirements in driver-requirements.txt 8 would be new. I haven't done a review but there is a non-zero chance one of these 8 could be rejected. At that point you're half in/out and that leaves ironic in an awkward place. > 2. inability to use ironic release notes to explain driver requirements > changes You can still do this, it's just harder because you don't have a single point where the updates are happening. At the moment when a change is proposed to modify driver-requirements you can reject the change until it has a release note. Now you'd need to check at release time if a release note was added. We can probably come up with a compromise solution. Perhaps annotate global requirements like: --- # sushy is used by ironic-drivers check for release note sushy>=0.1.0 --- Then in theory the requirements team could defer the change until it depends on a merged release note in ironic? It isn't 100% human proof. I haven't really thought about it though ... > 3. any objections from the requirements team? No objection from me but see the points above. > If we make this change, we'll drop driver-requirements.txt, and will use > setuptools extras to list then in setup.cfg (this way is supported by g-r) > similar to what we do in ironicclient [2]. > > We either will have one list: > > [extras] > drivers = > sushy>=a.b > python-dracclient>=x.y > python-prolianutils>=v.w > ... > > or (and I like this more) we'll have a list per hardware type: > > [extras] > redfish = > sushy>=a.b > idrac = > python-dracclient>=x.y > ilo = > ... > ... This one please. Yours Tony. [1] http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n265 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
On Mon, Oct 30, 2017 at 08:07:10PM -0400, Doug Hellmann wrote: > Excerpts from Richard.Pioso's message of 2017-10-30 23:11:31 +: > > 2. And would that be correctly handled? > > Good question. We should test the requirements update script to see. It does. I did a quick fictional test: This: --- diff --git a/setup.cfg b/setup.cfg index 6c3242535..01469c39f 100644 --- a/setup.cfg +++ b/setup.cfg @@ -25,6 +25,11 @@ packages = ironic ironic_tempest_plugin +[extras] +redfish1 = + sushy>=0.0.9 # Apache-2.0 +redfish2 = + sushy>=0.0.10 # Apache-2.0 [entry_points] oslo.config.opts = ironic = ironic.conf.opts:list_opts --- Becomes: --- [extras] redfish1 = - sushy>=0.0.9 # Apache-2.0 + sushy>=0.1.0 # Apache-2.0 redfish2 = - sushy>=0.0.10 # Apache-2.0 + sushy>=0.1.0 # Apache-2.0 --- After running the bot Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing
Hi All, Sending out a gentle reminder of Sydney Summit Forum Session regarding this topic. Extreme/Destructive Testing Tuesday, November 7, 1:50pm-2:30pm Sydney Convention and Exhibition Centre - Level 4 - C4.11 [https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20470/extremedestructive-testing] Eatherpad: https://etherpad.openstack.org/p/SYD-extreme-testing Your participation in this session would be greatly appreciated. --- Regards, Sampath On Mon, Aug 14, 2017 at 11:43 PM, Tim Bell wrote: > +1 for Boris’ suggestion. Many of us use Rally to probe our clouds and have > significant tooling behind it to integrate with local availability reporting > and trouble ticketing systems. It would be much easier to deploy new > functionality such as you propose if it was integrated into an existing > project framework (such as Rally). > > > > Tim > > > > From: Boris Pavlovic > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Monday, 14 August 2017 at 12:57 > To: "OpenStack Development Mailing List (not for usage questions)" > > Cc: openstack-operators > Subject: Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme > Testing > > > > Sam, > > > > Seems like a good plan and huge topic ;) > > > > I would as well suggest to take a look at the similar efforts in OpenStack: > > - Failure injection: https://github.com/openstack/os-faults > > - Rally Hooks Mechanism (to inject in rally scenarios failures): > https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_trigger_plugins.html > > > > > > Best regards, > Boris Pavlovic > > > > > > On Mon, Aug 14, 2017 at 2:35 AM, Sam P wrote: > > Hi All, > > This is a follow up for OpenStack Extreme Testing session[1] > we did in MEX-ops-meetup. > > Quick intro for those who were not there: > In this work, we proposed to add new testing framework for openstack. > This framework will provides tool for create tests with destructive > scenarios which will check for High Availability, failover and > recovery of OpenStack cloud. > Please refer the link on top of the [1] for further details. > > Follow up: > We are planning periodic irc meeting and have an irc > channel for discussion. I will get back to you with those details soon. > > At that session, we did not have time to discuss last 3 items, > Reference architectures > We are discussing about the reference architecture in [2]. > > What sort of failures do you see today in your environment? > Currently we are considering, service failures, backend services (mq, > DB, etc.) failures, > Network sw failures..etc. To begin with the implementation, we are > considering to start with > service failures. Please let us know what failures are more frequent > in your environment. > > Emulation/Simulation mechanisms, etc. > Rather than doing actual scale, load, or performance tests, we are > thinking to build a emulation/simulation mechanism > to get the predictions or result of how will openstack behave on such > situations. > This interesting idea was proposed by the Gautam and need more > discussion on this. > > Please let us know you questions or comments. > > Request to Mike Perez: > We discussed about synergies with openstack assertion tags and other > efforts to do similar testing in openstack. > Could you please give some info or pointer of previous discussions. > > [1] https://etherpad.openstack.org/p/MEX-ops-extreme-testing > [2] > https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/15477787/Extreme+Testing-Vision+Arch > > --- Regards, > Sampath > > __ > 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] [neutron][vpnaas] core reviewer proposal
Hi, On Fri, Oct 20, 2017 at 10:10 PM, Takashi Yamamoto wrote: > Hi, > > Unless anyone objects, i'll add the following people to neutron-vpnaas > core reviewers. [1] > > - Cao Xuan Hoang > - Akihiro Motoki > - Miguel Lavalle > > Hoang is the most active contributor for the project these days. > > I don't bother to introduce Akihiro and Miguel as i guess everyone here > knows them. :-) > > [1] https://review.openstack.org/#/admin/groups/502,members As I haven't received any concerns, I updated the list accordingly. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][networking-midonet] Core reviewers change proposal
Hi, On Fri, Oct 20, 2017 at 10:10 PM, Takashi Yamamoto wrote: > Hi, > > Unless anyone objects, I'll remove the following people from the list > of networking-midonet core reviewers. > > - Joe Mills > - Michael Micucci > > They made great contributions in the past (thank you!) but have not > reviewed any patches in the last 6 months. [2] > > [1] https://review.openstack.org/#/admin/groups/607,members > [2] http://stackalytics.com/report/contribution/networking-midonet/180 As I haven't received any concerns, I updated the members accordingly. __ 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
