- openstack-discuss - lists.openstack.org

[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

[scientific-sig] IRC meeting today 2100 UTC (in one hour): Continued HPC container discussion, Open Infra Summit Lightning Talks
by Blair Bethwaite 20 Feb '19

20 Feb '19

Hi all, Probably just a quick meeting today. Keen to collect HPC container war stories and looking for interest from lightning talk presenters for the SIG BoF at the Summit... Cheers, b1airo

1 1

[tc][elections] TC candidacy
by Jim Rollenhagen 20 Feb '19

20 Feb '19

Hi friends, I'm throwing my name out there for a position on the TC, if you'll have me. I've been around OpenStack since 2014, when I began working on a bare metal cloud powered by Ironic. Since then, I've been a core reviewer for Ironic and spent three cycles as PTL. I've also spent this time developing and operating OpenStack at large scale at Rackspace and Yahoo^WOath^WVerizon Media. I've never been a member of the TC, but have spent a lot of time in meetings, office hours, IRC channels, and face to face meetings with the TC, over various iterations of its members. I care deeply about OpenStack, and believe that I can help shape the future. I'll be honest, I don't have specific objectives I want to accomplish as a TC member, that I can platform on. Things I do care about doing are: Make/keep the OpenStack community a happy place to be (as happy as people can be while working, anyway). I believe that this community is somewhat family-like, and we all have each other's best interests in mind. We seem to be collaborating better than we have in a long time, and I'd like to keep improving on that. I'd love to continue the work that folks have started to encourage more cross-project feature collaboration. Encourage more part-time contributors. People like someone scratching an itch in their lab at home, a user getting curious about a bug, or an operator that finds an edge case. I think it's easier for these types of people to contribute today than it has been in the past, but I believe we can keep improving on this. Our onboarding process can continue to improve. We should have more people willing to walk a new contributor through their first patch (kudos to the people doing this already!). And folks shouldn't have to spend thousands of dollars attending a summit to gain influence in the community. On that note, I should be clear that I won't be at the Denver summit, and probably not Shanghai. Purely personal reasons, my employer still has my back with upstream contributions. I believe my experience as a downstream dev, upstream dev, operator, IRC addict, and wanna-be thought leaderer makes me a decent fit to help drive the community forward. Thanks for reading, and thanks in advance for voting, even if it's not for me. // jim

1 0

[tc][elections] TC candidacy
by Rico Lin 20 Feb '19

20 Feb '19

Dear all, I'm announcing my candidacy for a position on the OpenStack Technical Committee. I'm Rico Lin. I have been in this community since 2014. And been deeply involved with technical contributions [1], I start from working with heat, which allows me to work on integration and management resources from multiple projects. I have served as Heat PTL for two years. Which allows me to learn better on how we can join users and operators' experiences and requirements and integrated with development workflow and technical decision processes. Here are my major goals with this seat in TC: * Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV) * Provide guidelines * Strong the structure of SIGs * Application Infra * Cross-cooperation between Users, Operators, and Developers * Diversity I'm already trying to put my goals to actions, still would really hope to join Technical Committee to bring more attention to those domains and get more actions taken. And of couse to take fully responsible for all TC's responsibilities besides above goals. Thank you for your consideration. Best Regards, Rico Lin (ricolin) IRC: ricolin Twitter: @ricolintwhttps://www.openstack.org/community/members/profile/33346/rico-linhttp://stackalytics.com/?release=all&user_id=rico-lin&metric=person-day Here I put some explanations for my goals: - Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV): This is a long-term goal for our community, but would really like to see this getting more scenario for use cases, and a more clear target for development. As we talk about Edge, AI, etc. It's essential to bring real use cases into this integration( like StarlingX bring some requirements cross-projects to real use cases). On the other hand, K8s SIG, Self-healing SIG, FEMDC SIG are all some nice place for this kind of interacting and integrating to happen. We also just start auto scaling SIG, which will also make a good candidate to achieve such missing too. - Provide unified guidelines and features: We now have `Guidelines for Organisations Contributing to OpenStack` [4]. This is something I believe is quite important for showing how can organizations interacting with OpenStack community correctly. I try to work on the same goal from event to event as well (give presentations like [5]). There are some other guidelines that need to update/renew as well (most of us, who already reading ML and work in the community for long, might no longer require to read guidelines, but remember, whoever try to join now a day, still require an up-to-date guideline to give them hints). To have unified guidelines (and even features), allows whoever lose track with communiy, can come back easily. Also it's confused for users and ops when they try to figure out how they can achieve a task (like doing auto-scaling) in OpenStack. And I pretty sure it's pice of cake for experienced ops, as much as I'm pretty sure it is very possible for other ops to encounter with a lot of confusion. - Strong the structure of SIGs/WGs: As I show in above two goals, SIGs/WGs plays some important roles. I do like to trigger discussions on how can we strengthen the structure of SIGs. Make them more efficient and become someplace for users and ops can directly interact with developers. For real use cases like an Edge computing use case issue, or an atomatic healing service issue. I can't think of a better place than FEMDC SIG and Self-healing SIG to record and target these issues. We might be able to allow Opts to feedback issues on SIG's StoryBoard and ask project teams to connect and review with it. There might be multiple ways to do this. So would really like to trigger this discussion. On the other hand, for some other task that don't require much long-term tracking. We will definitely have some way for all to easily start their communication, tests and development (like the `pop-up team` Thierry Carrez currently proposing). Which (IMO) will not have to deal with structure set up at all. - Application Infra: We've updated our resolution with [3] and saying we care about what applications needs on top of OpenStack. As for jobs from few projects are taking the role and thinking about what application needs, we should provide help with setting up community goals, making resolutions, or define what are top priority applications (can be a short-term definition) we need to focus on and taking action items/guidelines and finding weaknesses, so others from the community can follow (if they agree with the goals, but got no idea on what they can help, IMO this will be a good stuff). - Cross-cooperation between Users, Operators, and Developers: We have been losing some communication cross Users, Operators, and Developers. And it's never a good thing when users can share use cases, ops shares experiences, developers shares code, but they won't make it to one another not if a user provides developers by them self. In this case, works like StoryBoard should be in our first priority. We need a more solid way to bring user feedback to developers, so we can actually learn what's working or not for each feature. And maybe it's considerable, to strengthen the communication between TCs and UCs (User Committee). We take some steps (like merge PTG and Ops-meetup) to this goal, but I believe we can make the interacting more active. - Diversity: I have a long term question here. So how can you encourge people from the entire global to vote, and to care about some technology is relatively stable and old? It's not just about we're losing attractiveness (which is normal for any open source at the end), but also we're not as friendly as we think on globalization issue. If a new non-native developers cames in, do we actually expect him/she to be able to know what to vote, where are resources, what's the best way to trigger a cross-project idea? To try to bridge up across user group and technical team across global is not just something TC should be doing, but IMO TC definitely have their responsibility and roles in it. As for the reason why I should join, well... The math is easy. [2] shows we got around one-third of users from Asia (with 75% of users in China). Also IIRC, around the same percentage of developers. But we got 0 in TC. The actual works are hard. We need forwards our technical guideline to developers in Asia and provide chances to get more feedback from them, so we can provide better technical resolutions which should be able to tight developers all together. Which I think I'm a good candidate for this. [1] http://stackalytics.com/?release=all&user_id=rico-lin&metric=person-day [2] https://www.openstack.org/assets/survey/OpenStack-User-Survey-Nov17.pdf [3] https://review.openstack.org/#/c/447031/5/resolutions/20170317-cloud-applic… [4] https://docs.openstack.org/contributors/organizations/index.html [5] https://www.slideshare.net/GuanYuLin1/embrace-community-embrace-a-better-li… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[tc][elections] TC candidacy
by Alexandra Settle 20 Feb '19

20 Feb '19

Hi all, I am announcing my candidacy for a position on the OpenStack Technical Committee. I have been an active contributor to OpenStack manuals since the beginning of 2014, and have been a core member since early 2015. I am currently employed by SUSE to work on SUSE OpenStack Cloud and OpenStack. You may know me better as asettle on IRC. Over these last 3 years, I have been privileged to be a part of this community focusing primarily on OpenStack documentation and have been vocal about treating documentation as a first-class citizen [0]. My key achievement was working as the elected PTL for documentation in 2017 [1] where I initiated moving the documentation out of the OpenStack-manuals repository and into the individual project repositories. My announcement may be considered quite brazen, as I have just returned to the community after a year-long hiatus working on the virtualization side of the world in a product operations role, however I am keen to support and work for this community with a renewed sense of enthusiasm. My experience in the OpenStack sphere has revolved around documentation, making me a traditionally unlikely candidate for the position on the TC. My role as documentation core and PTL has provided me with a broad view of OpenStack projects, how they work, and who you all are. I believe the perspective I will bring to the TC will be unique and helpful, as my time with OpenStack has been primarily focused on the integration and communication of all projects. The technical committee is designed to provide technical leadership for OpenStack as a whole [2] and I believe this to be true. Over the years, there has been an unspoken consensus that we are all aiming for the success of OpenStack as free and open software, fully developed and used by a welcoming and supportive community. I hope to stand as a member of the TC and further promote this statement. Drawing on my past experience as a communicator, documentor, collaborator, breaker of (my own) feet, and all round cool person, I am aiming to focus on the following three things: breaking down barriers between projects (new and old) and contributors (new and old); the openness of the community and maintaining that focus; and embracing change. Thank you for your consideration, Alex p.s - Tony: https://review.openstack.org/637972 [0] https://en.wikipedia.org/wiki/First-class_citizen [1] https://github.com/openstack/election/blob/master/candidates/pike/Documenta… [2] https://www.openstack.org/foundation/tech-committee/

1 0

[oslo] Single approve py37 patches
by Ben Nemec 20 Feb '19

20 Feb '19

As the subject says, let's single approve the py37 job addition patches. They're machine-generated and part of a broader effort that has already been agreed upon, so as long as they're passing CI they should be fine. -Ben

3 3

[tc][election] TC candidacy
by Sylvain Bauza 20 Feb '19

20 Feb '19

Howdy folks, I wasn't thinking to provide my name for the TC election but unfortunately I only see a very few proposals that makes me a bit afraid. Given I love OpenStack and I think the Technical Comittee is more important than my personal values, I throw my hat now in the ring. In case you don't know me, I'm Sylvain Bauza (bauzas on IRC), working on OpenStack since... wow, 6 years already ? In 2013, I was an operator for a SME company when I wanted to use some cloud for our CI and our developers and I discovered OpenStack. After 6 months working on it as an operator, I knew it would be my new life for more than what I know. I moved to another company and became a developer creating a new project which was named Climate. You probably know about this project if I tell you the new name : Blazar. Yeah, Blazar is 6 years old too and I'm super happy to see this project be now important with new companies and developers on it. After 1 year on it, I changed again my position and became a Nova developer, eventually becoming nova-core. Time flies and now I'm still there, happy with what OpenStack became. Of course, it changed. Of course, we have less. But honestly, I haven't seen more operators using it previously than now, which means that we succeeded as a team to make OpenStack useful for our users. I will be honest and say that I now work more on downstream for our customers than upstream with the Nova community. If you see my upstream involment, it slowly decreased from the last cycles but don't think I'm out of the band. After all, that means that people use our code, right? Also, that doesn't necessarly mean that I'll stop working upstream, it's just a balance that needs to be challenged, and be sure that if I'm a TC member, I'll take care of this balance. Enough words about me. I guess you're more interested in knowing about what I think is important for a TC membership. Well, I have a few opinions. - first, OpenStack is used from startups with a few servers to large cloud providers with +200K hosts. That's where we succeeded as projects. I think it's very important to make sure that service projects run from 0 to X smoothly and make it a priority if not. - secondly, the user experience is very important when it comes to talk to service projects. Having consistent and versioned APIs is important, albeit also client usage. We have microversions in place, but the story isn't fully done yet. - thirdly, I think we won the complexity game. Deploying OpenStack is now smoothier than before, but there are still bumps on the road, and I think the TC is the place to arbitrate between the understandable will of having more and the reasonable concern about upgrades and deployment concerns. Those three items aren't exhaustive of course. We all have opinions and I'm just one of the many. By the way, if you read up to here, ask yourself : if you care about OpenStack, why wouldn't you propose your name too ? Thanks, -Sylvain

1 0

[infra] Patch submitters can remove core reviewer votes?
by Ben Nemec 20 Feb '19

20 Feb '19

See https://review.openstack.org/#/c/637703/ I'm assuming in that case it was an accident, but it doesn't seem like this should be possible at all. For example, if I had -2'd would it still have allowed the removal? Maybe you can only remove positive votes? Anyway, seemed weird to me so I thought I would bring it up. -Ben

3 4

[openstack-helm] would like to discuss review turnaround time
by Jaesuk Ahn 19 Feb '19

19 Feb '19

Dear all, There has been several patch sets getting sparse reviews. Since some of authors wrote these patch sets are difficult to join IRC meeting due to time and language constraints, I would like to pass some of their voice, and get more detail feedback from core reviewers and other devs via ML. I fully understand core reviewers are quite busy and believe they are doing their best efforts. period! However, I sometimes feel that turnaround time for some of patch sets are really long. I would like to hear opinion from others and suggestions on how to improve this. It can be either/both something each patch set owner need to do more, or/and it could be something we as a openstack-helm project can improve. For instance, it could be influenced by time differences, lack of irc presence, or anything else. etc. I really would like to find out there are anything we can improve together. I would like to get any kind of advise on the following. - sometimes, it is really difficult to get core reviewers' comments or reviews. I routinely put the list of patch sets on irc meeting agenda, however, there still be a long turnaround time between comments. As a result, it usually takes a long time to process a patch set, does sometimes cause rebase as well. - Having said that, I would like to have any advise on what we need to do more, for instance, do we need to be in irc directly asking each patch set to core reviewers? do we need to put core reviewers' name when we push patch set? etc. - Some of patch sets are being reviewed and merged quickly, and some of patch sets are not. I would like to know what makes this difference so that I can tell my developers how to do better job writing and communicating patch sets. There are just some example patch sets currently under review stage. 1. https://review.openstack.org/#/c/603971/ >> this ps has been discussed for its contents and scope. Cloud you please add if there is anything else we need to do other than wrapping some of commit message? 2. https://review.openstack.org/#/c/633456/ >> this is simple fix. how can we make core reviewer notice this patch set so that they can quickly view? 3. https://review.openstack.org/#/c/625803/ >> we have been getting feedbacks and questions on this patch set, that has been good. but round-trip time for the recent comments takes a week or more. because of that delay (?), the owner of this patch set needed to rebase this one often. Will this kind of case be improved if author engages more on irc channel or via mailing list to get feedback rather than relying on gerrit reviews? Frankly speaking, I don't know if this is a real issue or just way it is. I just want to pass some of voice from our developers, and really would like to hear what others think and find a better way to communicate. Thanks you. -- *Jaesuk Ahn*, Ph.D. Software Labs, SK Telecom

2 3