March 2019 - openstack-discuss - lists.openstack.org

[ptl][magnum][election] PTL Candidacy
by feilong 12 Mar '19

12 Mar '19

Greetings, I would like announce my candidacy to serve as the Magnum project team leader for the Train cycle, if you will have me. I've been working on and contributing to Magnum since Queens release as a core developer. And I have done a lot work for Magnum to help it getting production ready, e.g. the Calico network driver, nodes anti affinity, k8s health status check, Keystone auth, coreDNS autoscale, get Magnum certified by CNCF and etc. That said, I really understand the ups and downs which Magnum went through and I know the blueprints, direction and pains of this project, for interests from both private cloud and public cloud sides. For Train release (including the rest of Stein cycle), things I'd like to do: 1. Rolling upgrade Rolling upgrade is one of the most important features user want to see for a managed Kubernetes service. And in Magnum, we're thinking more deeper to provide a better user experience. For the rolling upgrade, we will support upgrade the base operating system, Kubernetes version and even add-ons running on top of Kubernetes. 2. Auto scaling/healing Another most wanted feature for Kubernetes cluster. With this feature, a user will be able to get an auto scaled cluster which can fix itself when there is any node failure. 3. Node groups Node groups provide users with the ability to specify groups of nodes with different properties for different purposes. Within the scope of a group users are able to define labels, used image, flavor, etc depending on the purpose. 4. Fedora CoreOS The most matured driver for Kubernetes in Magnum is Fedora Atomic, however, the Fedora community is moving to Fedora CoreOS, so we should start to think about the migration. 5. Containerize Kubernetes master This could be one of the most interesting features for Magnum and it's definitely hard work. Running Kubernetes master nodes in a seed/root Kubernetes could bring us a lot of benefits. 6. Helm for add-ons We have enabled Helm in Stein and this gives us a good opportunity to re-think our add-ons management strategy. Using Helm for our add-ons could make our vendors' life much easier. It has been a fantastic experience working with this amazing team and I know without the dedication and hard work of everyone who has contributed to Magnum we can't get those good work done. So the PTL of this cool team is most like a facilitator, coordinator, and mentor. I would be pleased to serve as PTL for Magnum for the Train cycle and I'd appreciate your vote. Thanks for your consideration! -- 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

[edge][nova][neutron][ironic][cinder][tripleo] Tagging edge related work items
by Ildiko Vancsa 11 Mar '19

11 Mar '19

Hi, As edge computing related topics and work items are hot topic on both architecture level as well as on the design and implementation side it would be great to be able to see the big picture better to be able to follow activities and connect the dots. I’m reaching out to you to get some feedback and discussions around ideas to get closer to this desire. It came up on the Edge WG meetings earlier that it would be desirable to track ongoing feature development and bug fixing activities that are relevant to edge. In order to create the least overhead and try to keep things simple and somewhat automated we had the idea of tagging relevant work items in StoryBoard and Launchpad and we can also do the same with spec reviews in case we feel that the tracking tools don’t give full coverage on ongoing activities. We could use a simple tag like ‘edge’ or come up with more meaningful ones if we feel the need. The goal for this first step is to be able to filter in the already existing tools to find work items easier. What do you think about the above idea as a starting point? Do you think it is feasible or do you have any suggestions to either tweak it or coming up something else that might work better? Thanks and Best Regards, Ildikó

3 3

[ptl][adjutant][election] PTL Candidacy
by Adrian Turjak 11 Mar '19

11 Mar '19

Hello OpenStackers, I'm submitting myself as the PTL for Adjutant during the Train cycle. As the main developer and project lead until now, I'm still the best suited to continue leading the project. My focus for Train will be onboarding of new devs, and having them help me with the refactor work that is still in progress. As such the planned work is still: - bringing the codebase to a much nicer state while decoupling certain elements of our internals, and adding support for async task processing. - rework the config system - introduce partial policy support rather than relying on hardcoded decorators. - rework notifications to be pluggable and how/when they are sent - rework the identity manager as a pluggable construct. - finish the long planned support for sub-project management - add project (and resource) termination logic which uses the currently planned community goal for Stein It should actually be a productive cycle, and we will in all likelihood be dropping python2 support by the end of it. Cheers, Adrian Turjak

1 0

[ptl][nova][election] PTL Candidacy
by melanie witt 11 Mar '19

11 Mar '19

Dear Stackers, It has been my privilege to serve as PTL of the Nova project over the Rocky and Stein cycles, and I would be happy to serve another cycle, if you'll have me. I remain most motivated by serving operators and users in our community. I spend as much time as I can communicating with operators at the Summit Forum, the PTG, and the #openstack-nova channel to answer questions, help with problems, give guidance, obtain feedback, and make changes and improvements based on their feedback. I am proud to say that we receive operator code contributions regularly in Nova, and I want to do everything we can to keep it that way or even increase it. Similarly, it's always great when operators participate in our Summit Forum and/or PTG sessions. We always have participation and I appreciate that. To operators: if there is anything I can do to help you participate, please let me know. Stein was a busy cycle, with one of the primary efforts being the placement service extraction. This was an enormous change with significant impact on operators, and I worked hard to ensure we had a plan that would consider the consumers of our deliverables. I consulted with team members with expertise in upgrades and deployment tooling and strove to find consensus among members of different groups with different priorities. We made a lot of progress on the placement extraction plan, but because upgrade support and testing were not able to be implemented in deployment tools in time, we did not delete the placement code from Nova in Stein. The placement code is left as a bridge for operators in Stein, to be able to run with integrated placement until we have upgrade support and testing and operators feel ready to move to extracted placement. So, next cycle, we have a lot of important cross-project work to do with deployment tools teams to coordinate upgrades support and testing, and removal of the placement code from Nova. This of the highest priority. In Stein, I worked on two features focused on usability and operational robustness: configurable maximum number of disk devices to attach to a single instance and counting quota usage from placement (down/poor performing cell resiliency). We landed only the data migration piece of the counting quota usage series, but that positions us well to be able to migrate a lot of data in Stein and start counting quota usage from placement in Train. Next cycle, I want to focus on coordinating what deployment tools need to support upgrading to extracted placement and deletion of the placement code in Nova, project management duties, and bugs. It is essential that we get the upgrade/extracted placement work squared away in Train, as early as possible. Finally, cross-project efforts are important to me and I participate in discussions whenever I can. I actively participated in most of the unified limits/oslo.limit sessions at summit and PTG, to lend my experience working with quotas in Nova to help those working on the design and implementation. And recently, I had a productive discussion with Lance Bragstad about Keystone authorization scopes, which resulted in him drafting this great document for all of us: https://review.openstack.org/638563. I want to help drive adoption of auth scopes in Nova, to help Nova become more self-service and enable operators to let non-admin users have access to whatever APIs they choose. Thanks for reading and thank you for your consideration. Best, -melanie

1 0

[ptl][neutron][election] PTL Candidacy
by Miguel Lavalle 11 Mar '19

11 Mar '19

Hello OpenStackers, I write this to submit my candidacy for Neutron PTL during the Train cycle. I have had a blast being the project's PTL for the past three cycles. After everything is said and done, the most rewarding part of this job is to get to work with an amazing group of top notch software engineers from around the World. I will be grateful forever for everything that you all have taught me. So I humbly ask for another chance to be trained during Train. We had a successful Stein cycle, delivering on most of the goals we set for ourselves in Denver: * Delivered most of the implementation of bandwidth based scheduling, that enables Neutron and Nova to guarantee network bandwidth to instances based on QoS policies. * To better serve edge computing use cases, we partnered with the StarlingX team to implement management of network segments ranges dynamically through a new API extension. * Extended Neutron QoS to support L3 router gateway IPs. * Improved the performance of port creation in bulk to better support containers use cases. * Improved the security groups implementation by optimizing the performance of rules creation and making security groups shareable with the RBAC mechanism. * We created the os-ken project, OpenStack community fork of the Ryu library, which will not be supported by its original implementor anymore. os-ken is now maintained by the Neutron project team. * We continued our efforts of de-coupling common functionality from the Neutron repository and moving it to neutron-lib. * We worked hard on past and present community goals, so at the end of Stein Neutron will be completely caught up. * We implemented a successful mentoring program for prospective core reviewers. This enabled us to add three new members to the Neutron team: Nate Johnston, Hongbin Lu and Liu Yulong. We also added Bernard Cafarelli, Ryan Tidwell and Manuel Buil as stable branches, BGP Dynamic Routing and networking-sfc core reviewers, respectively. Moving forward, these are some of the goals that I propose for the team during the Train cycle: * Improve the usability of routed networks by allowing more that one segment per network per compute host. This will enable the scaling up of deployments without being constrained by subnet IP address ranges. * Add the capabillity to tag ports during bulk creation, to better support containers use cases. * Actively continue our collaboration with the StarlingX team to identify and implement better support for edge computing use cases. * Continue the implementation of smart NICs support. * During Stein, we formed a performance sub-team with the aim of improving Neutron's scalability. We will bring this effort to fruition by identifying and implementing areas of improvement based on the characterization work we are doing with osprofiler and the EnOS (Experimental eNvironment for OpenStack) team. * We will continue our efforts of de-coupling common functionality from the Neutron repository and moving it to neutron-lib. * I see myself, with the support of my current employer, actively involved in the project and the community for many cycles in the future. I think, though, that we are getting to a point where it is healthy to pass the baton to a new leader. To that end, I will actively encourage team members to step up to the plate in the next cycle. I will support and help propective candidates every step of the way. Thank you for your consideration and for taking the time to read this Miguel Lavalle (mlavalle)

1 0

[all][ptl]tc] Only 24 hours remaining for PTL nominations
by Jeremy Stanley 11 Mar '19

11 Mar '19

A quick reminder that we are in the last hours for PTL candidate nominations. If you want to stand for PTL, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. The following projects are still lacking any PTL candidate at this time: Adjutant Congress Glance Heat I18n Magnum Monasca Neutron Octavia OpenStack Helm PowerVMStackers Puppet OpenStack Tacker Telemetry Tripleo Vitrage Zaqar This means that with approximately 1 day left, these 17 projects may be deemed leaderless. In this case the TC will oversee PTL selection as described by [2]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Jeremy Stanley

1 0

[ptl][ironic][election] PTL Candidacy
by Julia Kreger 11 Mar '19

11 Mar '19

Greetings fellow carbon based lifeforms and sentient software programs, I would like announce my candidacy to serve as the Ironic project team leader for the Train cycle, if you will have me. Passion is a funny thing. It drives us and motivates us, but it does not tell us when we are done. And I can say for certain that I am not done. Last cycle we turned the dial to eleven and this cycle we've reached twelve. I suspect we need to re-calibrate the dial and begin a new standard for audio volume measurement. We achieved more than I could have imagined for this past cycle, but not quite what we planned. Our wants, desires, purpose, and meaning are fluid. It is clear to me we evolved because the needs of those we support have changed while keeping a single central theme. To make it easier to deploy and manage bare metal. To continue on this journey, I think we must embrace and extend our operator community. Just as with our use cases and hardware support. We must no longer think of ourselves as only a service with-in the confines of OpenStack. We must view beyond our OpenStack roots while continuing to strengthen them. We can only do this by growing our community. Together, I am sure we can further make bare metal rock. And perhaps, somewhere along the way, we may take over the world. Julia Kreger (TheJulia)

1 0

[ptl][tacker][election] Only one more day to submit your candidacy for Tacker PTL
by Trinh Nguyen 11 Mar '19

11 Mar '19

Hi team, Just so you know that we have only 1 more day left [1] to submit your candidacy for Tacker PTL. Please do it asap. Bests, [1] https://governance.openstack.org/election/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[edge][all] Edge hacking days
by Ildiko Vancsa 11 Mar '19

11 Mar '19

Hi, A few of us in the Edge WG are working on to organize hacking days[1] to ensure we can have some dedicated time to progress with work items as well as speed up the learning phase in areas like identity or image management or bootstrap testing activities. Our thinking is to organize these as virtual events through Google Hangouts or any other tool we prefer to use to keep in contact. We can also leverage conferences to try and organize in person occasions even if not for a full day. Would you be interested in participating? If yes what is the topic/task you would like to work on? Thanks and Best Regards, Ildikó [1] http://lists.openstack.org/pipermail/edge-computing/2019-March/000555.html

1 1

[ptl][cinder][election] PTL Candidacy ...
by Jay Bryant 11 Mar '19

11 Mar '19

All, This letter is to indicate my interest in continuing to serve as the Cinder PTL for the Train release. This would be my fourth release as PTL and am happy to continue leading the Cinder project. Over the last three releases, for which I have been PTL, I have seen Cinder transition from focussing on merging new functionality to focussing on fixing bugs and improving Cinder's stability. This is a natural progression for a project of this type and, I feel, requires the team to take a new approach to how we go forward. During the Train release I think that the team should continue to look at the bugs filed against Cinder and work to address them. We started reducing the number of bugs during Stein and I hope that we can continue that momentum in Train. I also feel that we need to be better about monitoring 3rd Party CI runs and ensure that they are testing what they should be testing. With the move to Python3 ensuring it is being tested and that each driver works with Python3 is going to be essential. Other goals I have during Train include: * Continuing to address how cinderlib fits with Cinder * Continuing to reach out to our users seeking their input for improvement * Continued improvement of core reviewer participation * Increasing the breadth of testing against Cinder I look forward to the continued opportunity to lead the Cinder project. Sincerely, Jay Bryant (jungleboyj)

1 0