February 2019 - openstack-discuss

[oslo] How to properly cleanup FakeExchangeManager between test cases
by Balázs Gibizer 20 Feb '19

20 Feb '19

Hi, Nova has tests that are using the oslo.messaging FakeDriver implementation by providing the 'fake://' transport url. The FakeExchangeManager keeps a class level dict of FakeExchange objects keyed by the communication topic[1]. This can cause that an RPC message sent by a test case is received by a later test case running in the same process. I did not find any proper way to clean up the FakeExchangeManager at the end of each test case to prevent this. To fix the problem in the nova test I did a hackish cleanup by overwriting FakeExchangeManager._exchanges directly during test case cleanup [2]. Is there a better way to do this cleanup? Cheers, gibi [1] https://github.com/openstack/oslo.messaging/blob/0a784d260465bc7ba878bedeb5… [2] https://review.openstack.org/#/c/637233/1/nova/tests/fixtures.py

3 2

[cinder]queens][vmax3] FC issue
by Ignazio Cassano 20 Feb '19

20 Feb '19

Hello All. I'am trying to configure cinder driver for vmax3 fc using the rest api driver. I am facing issues creating volumes from images because masking view errors: The error message received was Bad or unexpected response from the storage volume backend API: Error retrieving masking group On unisphere (8.4) log files I found that moveVolumeToStorageGroup is not found, while the openstack dell_emc rest-py is using it in its payload. Anyone could help us with this problem ? Regards Ignazio

1 0

[all] Denver Forum Brainstorming
by Kendall Nelson 20 Feb '19

20 Feb '19

Hello Everyone! Welcome to the topic selection process for our Forum in Denver! This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. For OpenStack Denver marks the beginning of Train’s release cycle, where ideas and requirements will be gathered. We should come armed with feedback from the upcoming Stein release if at all possible. We aim to ensure the broadest coverage of topics that will allow for multiple parts of the community getting together to discuss key areas within our community/projects. For OSF Projects (StarlingX, Zuul, Airship, Kata Containers) As a refresher, the idea is to gather ideas and requirements for your project’s upcoming release. Look to https://wiki.openstack.org/wiki/Forum for an idea of how to structure fishbowls and discussions for your project. The idea is to ensure the broadest coverage of topics, while allowing for the project community to discuss critical areas of concern. To make sure we are presenting the best topics for discussion, we have asked representatives of each of your projects to help us out in the Forum selection process. There are two stages to the brainstorming: 1.If you haven’t already, its encouraged that you set up an etherpad with your team and start discussing ideas you'd like to talk about at the Forum and work out which ones to submit. 2. On the 22nd of February, we will open up a more formal web-based tool for you to submit abstracts for the most popular sessions that came out of your brainstorming. Make an etherpad and add it to the list at: https://wiki.openstack.org/wiki/Forum/Denver2018 <https://wiki.openstack.org/wiki/Forum/Berlin2018> This is your opportunity to think outside the box and talk with other projects, groups, and individuals that you might not see during Summit sessions. Look for interested parties to collaborate with and share your ideas. Examples of typical sessions that make for a great Forum: - Strategic, whole-of-community discussions, to think about the big picture, including beyond just one release cycle and new technologies - eg Making OpenStack One Platform for containers/VMs/Bare Metal (Strategic session) the entire community congregates to share opinions on how to make OpenStack achieve its integration engine goal - Cross-project sessions, in a similar vein to what has happened at past forums, but with increased emphasis on issues that are of relevant to all areas of the community - eg Rolling Upgrades at Scale (Cross-Project session) – the Large Deployments Team collaborates with Nova, Cinder and Keystone to tackle issues that come up with rolling upgrades when there’s a large number of machines. - Project-specific sessions, where community members most interested in a specific project can discuss their experience with the project over the last release and provide feedback, collaborate on priorities, and present or generate 'blue sky' ideas for the next release - eg Neutron Pain Points (Project-Specific session) – Co-organized by neutron developers and users. Neutron developers bring some specific questions about implementation and usage. Neutron users bring feedback from the latest release. All community members interested in Neutron discuss ideas about the future. Think about what kind of session ideas might end up as: Project-specific, cross-project or strategic/whole-of-community discussions. There'll be more slots for the latter two, so do try and think outside the box! This part of the process is where we gather broad community consensus - in theory the second part is just about fitting in as many of the good ideas into the schedule as we can. Further details about the forum can be found at: https://wiki.openstack.org/wiki/Forum Thanks all! Kendall Nelson, on behalf of the OpenStack Foundation, User Committee & Technical Committee

2 1

[tc] The future of the "Help most needed" list
by Thierry Carrez 20 Feb '19

20 Feb '19

Hi everyone, The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project". [1] https://governance.openstack.org/tc/reference/help-most-needed.html This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help. When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems). So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back. Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list. Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions? -- Thierry Carrez (ttx)

13 35

nova vs neutron SR-IOV
by Manuel Sopena Ballesteros 20 Feb '19

20 Feb '19

Dear Openstack community, What are the differences between setting up SR-IOV in nova vs neutron? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0

[all] [TC] 'Train' Technical Committee Campaigning Begins!
by Kendall Nelson 20 Feb '19

20 Feb '19

Developers, The TC Election Campaigning Period has now started [1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms [2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform [2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. -Kendall (diablo_rojo) [1] https://governance.openstack.org/election/ [2] http://git.openstack.org/cgit/openstack/election/tree/candidates/train/TC

1 0

[all] [TC] 'Train' Technical Committee Election Nominations Closed
by Kendall Nelson 20 Feb '19

20 Feb '19

TC Nomination period is now over. The official candidate list is available on the election website[0]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Feb 26, 2019 23:45 UTC. Thank you, [0] http://governance.openstack.org/election/#train-tc-candidates

1 0

[goal][python3] week R-7 update
by Doug Hellmann 20 Feb '19

20 Feb '19

This is the regular update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html) == Current Status == After last week's several teams updated their status in the wiki, and at least one team changed the job they had running so that it is voting. The list of teams who have not completed this step is still longer than I would like, but everyone is either working on it or has put it on their roadmap. == Ongoing and Completed Work == We also have a fair number of tox update patches left open. I intend to abandon any of those that I submitted when we hit RC1 for Stein, because I plan to be working on other things next cycle. If you see your project name below and want to get your version of the patch landed before that deadline, look for the patch with topic tag 'python3-first'. +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | Team | tox defaults | Docs | 3.6 unit | Failing | Unreviewed | Total | Champion | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | adjutant | 1/ 1 | - | + | 0 | 0 | 2 | Doug Hellmann | | barbican | + | 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | heat | 1/ 8 | + | + | 0 | 0 | 21 | Doug Hellmann | | InteropWG | 1/ 2 | + | + | 0 | 0 | 8 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 | 35 | Doug Hellmann | | magnum | 1/ 5 | + | + | 0 | 0 | 10 | | | masakari | 1/ 4 | + | - | 0 | 0 | 5 | Nguyen Hai | | neutron | 2/ 17 | + | + | 1 | 1 | 44 | Doug Hellmann | | OpenStack Charms | 7/ 73 | - | - | 7 | 2 | 73 | Doug Hellmann | | Quality Assurance | 1/ 9 | + | + | 0 | 1 | 30 | Doug Hellmann | | rally | 1/ 3 | + | - | 1 | 1 | 5 | Nguyen Hai | | swift | 2/ 3 | + | + | 2 | 1 | 6 | Nguyen Hai | | tacker | 1/ 4 | + | + | 1 | 0 | 9 | Nguyen Hai | | Telemetry | 1/ 7 | + | + | 0 | 1 | 19 | Doug Hellmann | | tripleo | 1/ 53 | + | + | 0 | 1 | 89 | Doug Hellmann | | trove | 1/ 5 | + | + | 0 | 0 | 11 | Doug Hellmann | | User Committee | 3/ 3 | + | - | 0 | 2 | 5 | Doug Hellmann | | | 45/ 61 | 56/ 57 | 55/ 55 | 13 | 11 | 1068 | | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ == Next Steps == == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Ve… 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug

2 5

[tc][elections] TC candidacy
by Feilong Wang 20 Feb '19

20 Feb '19

Hi everyone, I'm announcing my candidacy for a position on the OpenStack Technical Committee. For those of you who don't know me yet, I'm Feilong Wang, currently working for Catalyst Cloud as head of R&D. Catalyst Cloud is a public cloud running on OpenStack based in New Zealand, before that I worked for IBM System & Technology Lab for OpenStack upstream work. As for OpenStack upstream, now I'm a core contributor of OpenStack Magnum and actively involve the integration between OpenStack and Kubernetes. Besides, I was serving as the PTL of Zaqar (OpenStack Messaging Service) for years. Before that, I was mainly working for Glance (OpenStack Image Service) as a core reviewer since Folsom 2012. In my opinion, currently the role of the TC is more important than ever. Some large companies already downsized their investment for OpenStack or switching their focus to containers/k8s, but meanwhile many companies from APAC, especially China, are heavily investing OpenStack. Although it's a pain to lose great contributors, the companies having real requirements for OpenStack are kept. It's a good time for us to think about how to define/care OpenStack, for whom we're building the software and how to build a collaborative/integrated community. As a TC member I want to bring focus in below areas: #1 Integration and Collaboration As a distributed cloud platform, it's good to decouple different services to make each service do one thing well. However, seems most of projects are solely focusing on their own offering and not enough projects are paying attention to the global impact. I would like to push a more tighter collaboration between projects and obviously it will make the integration more easier and efficient. Operators should expect different projects can work together smoothly just like they're different parts within one project. As a maintainer of a public cloud running on OpenStack, I know the pain of our ops, when they try to migrate a service or adding a new service in existing cluster. So I'd like to see more interlocks between PTL and TC members to understand the gaps and fill the gaps. #2 Users & Operators Listen closely to the voice of users and operators and this pretty much align with the mission of OpenStack as below. "To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable." To implement a useful, stable cloud platform, we can't work behind closed doors, but closely work with the user and operator community. As far as I know, except the user survey, we don't have more formal process/approach to collect the feedback from our users and operators, though the operators mailing list and some random forum sessions at OpenStack summit are helpful. And IMHO, currently we’re mixing feedback collected from different perspectives. For example, most of the feedback from operators are how to easily deploy/manage the cloud. But the tenant user/developers' requirements are more related to functions, UX, etc. I can see we have put a lot of effort to address the pain of operators, but obviously, we do also need more work to make the tenant users/developer’s life easier. #3 Better UX This is the tiny part sometimes skipped by us. But I think it's important for us to put effort on. For example, we can release a docker image including all our openstack clients, so user don't have to deal with python depedencies. Another example is enforcing restricted API consistency across different services. It would be an honor to be member of your technical committee. Thanks for your consideration! -- Feilong Wang -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

1 0

[tc] Technical Committee Status report for February 19
by Doug Hellmann 20 Feb '19

20 Feb '19

This is a 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 == Project updates: * Retire puppet-stackalytics ** https://review.openstack.org/#/c/631820/ * Extra ATCs for I18n team ** https://review.openstack.org/#/c/633398/ * Add roles for managing HSM hardware to OpenStack-Ansible ** https://review.openstack.org/#/c/631324/ * Add os_mistral role to OpenStack-Ansible ** https://review.openstack.org/#/c/634817/ * Remove instack from TripleO ** https://review.openstack.org/#/c/635278/ Other updates: * Zane Clarified the meaning of design goals in the technical vision document ** https://review.openstack.org/#/c/631435/ * Ghanshyam added version-based feature discovery to the technical vision ** https://review.openstack.org/#/c/621516/ * I fixed the tool that reports on status of governance changes against various voting rules to deal with formal votes properly ** https://review.openstack.org/#/c/636418/ == TC Meetings == The most recent TC meeting was on 7 February. Logs were sent to the mailing list after the meeting. * http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002493… The next TC meeting is scheduled for 7 March @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Jean-Philippe has proposed adding openSUSE to the list of supported platforms in the PTI. * https://review.openstack.org/#/c/633460/ Ed Leafe has proposed creating a Placement team * https://review.openstack.org/#/c/636416/ We have a few conversations around the "help most wanted" list. * Ivan is proposing to add Horizon to the existing list: https://review.openstack.org/#/c/633798/ * Lance is proposing to add a section about working on unified limits and quota management: https://review.openstack.org/#/c/637025/ * Thierry proposed creating a Padawan mentoring program, as part of a larger discussion around ways to replace the existing list: https://review.openstack.org/#/c/636956/ Thierry has also proposed a clarification to the technical goal setting role of the TC. * https://review.openstack.org/#/c/636948/ We are discussing whether it makes sense to use stackalytics reports when making governance decisions or providing details about team from a governance perspective. There is some question about the open nature of the tool and whether the data collection algorithms have changed recently with the updated implementation. * Linking to metrics from team pages on governance.o.o: https://review.openstack.org/#/c/636665/ * Jeremy's patch to remove the team fragility tool, which uses stackalytics data: https://review.openstack.org/#/c/636721/ Rico has proposed a patch to record the fact that the new auto-scaling SIG owns the auto-scaling-sig git repo. It isn't up to the TC to set ownership, but we record the information along with other ownership details so it can be used for building voter rolls. * https://review.openstack.org/#/c/637126/ Gorka has proposed a patch to add the cinderlib repository to the cinder team. * https://review.openstack.org/#/c/637614/ == TC member actions/focus/discussions for the coming week(s) == It's election time, so I expect most of us will be focused on the discussions associated with the campaign. == 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-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

1 0