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

[ptl][tripleo][election] PTL Candidacy
by Alex Schultz 12 Mar '19

12 Mar '19

I would like to nominate myself for the TripleO PTL role for the Train cycle. Having previously served as PTL during the Queens and Rocky cycle, I think we should focus on the same items as those cycles. We have done excellent work adding python3 support in TripleO. I would like us to return back to focusing on simplification and improving the user experience. * Simplifying the deployment process I believe we should spend time looking at what actions we can remove or reduce by automating them as part of the deployment process. Let's figure out if we can improve the default installation so that we don't have to specify so much. Additionally I would like to start investigating if we can remove some of the services we currently rely on in the undercloud as part of the deployment. * Reducing duplication and tech debt Continued cleanup after containerization by fully removing the baremetal deployment of services as possible. Cleaning up logging and error handling to improve operators ability to troubleshoot their installations. Thanks, Alex Schultz irc: mwhahaha

3 2

[ptg][openstack-ansible] ptg planning
by Mohammed Naser 12 Mar '19

12 Mar '19

Hi everyone, Just a heads up, we've got an etherpad going, please put your name down if you're attending and if there's any subjects you'd like to bring up. https://etherpad.openstack.org/p/osa-train-ptg Thanks Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[api][neutron] tagging support when creating a resource
by Akihiro Motoki 12 Mar '19

12 Mar '19

Hi API-SIG, neutron and tagging-related folks, This email ask opinions on tagging when creating a resource. We received a feature request to support tagging when creating a resource [1]. Neutron supports bulk creation of resources but the current tagging API recommended by the API-SIG does not define tagging when creating a resource. As a result, if we want to create 100 ports with specific tags, we need 1 (bulk creation) +100 (taggins per resource) API calls. It sounds nice to me to support tagging when creating a resource to address the above problem. What in my mind is to specify 'tags' attribute in a body of POST request like: {'port': {'name': 'foo', 'network_id': <network-id>, 'tags': ['red', 'blue'] } } I don't know the reason why the current API-SIG recommended tagging API does not support this model. The current tagging API defines "tags" as a subresource. Is there any reason this model was adopted? Best Regards, Akihiro Motoki (irc: amotoki) [1] https://bugs.launchpad.net/neutron/+bug/1815933 [RFE] Allow bulk-tagging of resources [2] https://specs.openstack.org/openstack/api-wg/guidelines/tags.html

4 5

Re: [nova][dev][ops] can we get rid of 'project_only' in the DB layer?
by Alex Xu 12 Mar '19

12 Mar '19

sorry, I lost the ML address again. Alex Xu <soulxu(a)gmail.com> 于2019年3月12日周二下午10:55写道： > After review this patch https://review.openstack.org/630769, it probably > leads me get some memory back. > > The reason we don't support user based policy and pass the instance's > context as target is John and Sean mention that we don't have enough test > to ensure all the APIs work correctly for cross the tenant user request. > > Similar to the patch https://review.openstack.org/630769 try to fix, that > patch fix the case admin user to execute a shelve action on normal tenant > user. If we enable a tenant user to execute an action on another tenant's > server, that will extend the case of https://review.openstack.org/630769, > we need ensure it works for that case also. > > So hope I remember correctly, just note at here, in case I forget mention > that in the future. > > melanie witt <melwittt(a)gmail.com> 于2019年2月20日周三下午4:16写道： > >> On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos(a)gmail.com> >> wrote: >> > On 2/18/2019 8:22 PM, melanie witt wrote: >> >> Right, that is the proposal in this email. That we should remove >> >> project_only=True and let the API policy check handle whether or not >> the >> >> user from a different project is allowed to get the instance. >> Otherwise, >> >> users are not able to use policy to control the behavior because it is >> >> hard-coded in the database layer. >> > >> > I think this has always been the long-term goal and I remember a spec >> > from John about it [1] but having said that, the spec was fairly >> > complicated (to me at least) and sounds like there would be a fair bit >> > of auditing of the API code we'd need to do before we can remove the DB >> > API check, which means it's likely not something we can complete at this >> > point in Stein. >> > >> > For example, I think we have a lot of APIs that run the policy check on >> > the context (project_id and user_id) as the target before even pulling >> > the resource from the database, and the resource itself should be the >> > target, right? >> > >> > [1] https://review.openstack.org/#/c/433037/ >> >> Thanks for the link -- I hadn't seen this spec yet. >> >> Yes, Alex just pinged me in #openstack-nova and now I finally understand >> his point that I kept missing before. He tried a test with my WIP patch >> and a user from project A was able to 'nova show' an instance from >> project B, even though the policy was set to 'rule:admin_or_owner'. The >> reason is because when the instance project/user isn't passed as a >> target to the policy check, the policy check for the request context >> project_id won't do anything. There's nothing for it to compare >> project_id with. This is interesting because it makes me wonder, what >> does a policy check like that [2] do then? It will take more learning on >> my part about the policy system to understand it. >> >> -melanie >> >> [2] >> >> https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb74460643… >> >> >> >> >>

1 0

[wsme][dev] WSME needs cores
by Chris Dent 12 Mar '19

12 Mar '19

Most of the people listed as cores for WSME [1] are either not very active in the community any more or not actively interested in maintaining WSME. I'm in the latter group and wish to stop paying attention to it (because I don't use it and neither do the projects that I work on). To do that, though, it would be good to be able to assign a few more cores who are from projects that _do_ use it so that there's a reasonable bench of people to attend to things that will need to be done to keep it happy. The following is an incomplete list of projects that import WSME. aodh blazar cloudkitty cyborg glance ironic magnum mistral mogan octavia qinling watcher (I considered putting all these in the subject header that would have been incredibly tedious and noisy.) Octavia has representation on WSME-core, but beyond that, it's not clear. If you are a part of one of these projects and interested, please let me know and we'll make something happen. Apart from security and bug maintenance, WSME is a bit out of date with regard to testing plans. It does already support Python3, but it currently only tests with Python 3.5. Let me know. Whatever the outcome of these discussions, I'll be removing myself from WSME core and taking "check in on WSME" from my recurring todo list by next Tuesday. Thanks for your attention. [1] https://review.openstack.org/#/admin/groups/202,members -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[ptl][vitrage]election]
by Ifat Afek 12 Mar '19

12 Mar '19

Hi all, I would like to announce my candidacy to continue as Vitrage PTL for the Train release. I’ve been the PTL of Vitrage since the day it started and I'll be happy to continue leading it in the next six months. I think we've had a very successful Stein cycle. Our main features include: * New and simplified template language * Improved resource query APIs * New service list API * Integrations with more openstack components (Trove, Zaqar, Monasca) * More flexible configuration for the Prometheus datasource Moving forward, these are the areas that I believe we should focus on: * Continue the cross-project work that we started in Stein. Some of our plans relate to the self-healing SIG effort: finish the integration with Monasca, allow configuring Vitrage via Heat templates for auto-healing scenarios, and in general integrate with more datasources - both OpenStack and external. * Extend the Vitrage support for Kubernetes. In addition to performing root cause analysis over Kubernetes nodes, we would like to consider also Helm charts, Kubernetes deployments, and optionally pods. * Improve the Vitrage UI, hopefully using a new React-based plugin. * Extend the Vitrage community. I'll be happy to see more contributors joining our effort. I look forward to working with you all in the coming cycle. Thank you, Ifat.

1 0

[ptl][puppet][election] PTL Candidacy
by Shengping Zhong 12 Mar '19

12 Mar '19

Hello OpenStackers, I'm submitting myself as PTL candidate for the Puppet OpenStack project during the Train cycle[1]. I've been active in the OpenStack community since 2016 and as core reviewer from Ocata cycle. My stats for the last 90 days can be viewed here[2]. My goals for the Train cycle in the following areas: * Deprecate many parameters and remove a lot of deprecate parameters. * Improving documentation around established patterns and best practices. * Add python3 packages support. * Improve testing of Puppet 6. * Improve the puppet-senlin module. * Fix some bugs. I'm happy to welcome new contributors to the project. Thanks for taking the time to read through this roadmap and to consider my candidacy. [1]https://review.openstack.org/#/c/642655/ [2]https://stackalytics.com/report/contribution/puppet%20openstack-group/90 Best regards Shengping Zhong (zhongshengping)

1 0

[ptl][octavia][election] PTL Candidacy
by Adam Harwell 12 Mar '19

12 Mar '19

Hey ya'll! As it seems that Michael is finally stepping down from his role as PTL this cycle (which I find deeply depressing, as I believe he is the best PTL we could ask for), I suppose someone has to try to fill the gaping void left by his departure. I humbly submit that I will do my best, if you'll let me try. As a contributor to Octavia since its inception (which seems so long ago now), I have had the privilege of working closely with most of you over the years, and I have been continuously proud of the things we have accomplished together. Stein will be yet another great release, with an impressive set of new features and fixes that should make Octavia easier to use for operators and users alike. Provider and flavor support especially is a big win, as it will finally allow us to drop support for neutron-lbaas, and pave the way for more broad adoption in the near future. I hope that we can continue with the momentum we've maintained in the past few years, and do great things together in Train. If you choose me, I *will* be relying heavily on each and every one of you for support, as Michael's shoes seem impossible to fill alone, especially as a newbie to PTL life. I hope we can count on each other as we continue this great adventure, and I hope to see many of you soon in Denver! Thanks, --Adam Harwell

1 0

[monasca][elections] Candidacy for Monasca PTL
by Witek Bedyk 12 Mar '19

12 Mar '19

Hello, I would like to announce my candidacy to continue as the PTL of Monasca for the Train release. In the next release I would like to focus on the following goals: * strengthen the community and improve active participation and contribution * consolidate the project by concentrating on the core functionality (metrics, logs, events), reducing legacy components and upgrading middleware * continue working on and promoting containerized deployment and Prometheus integration * continue to improve the documentation * collaborate with other OpenStack projects, e.g. by contributing to self-healing and auto-scaling SIGs Apart from that I'll do my best to promote Monasca and coordinate community work. Thank you for considering my candidacy and I'm looking forward to another very productive cycle. Best greetings Witek

1 0

[ptl][tacker][election] PTL Candidacy
by Dharmendra Kushwaha 12 Mar '19

12 Mar '19

Hi Everyone, I would like to announce my candidacy again for Tacker PTL role for Train cycle. I am Dharmendra Kushwaha known as dkushwaha on IRC, active member of Tacker community since Mitaka release. I run as Tacker PTL in Stein cycle. I would like to thanks all who supported Tacker with their contributions in Stein cycle. It is a great experience for me to working in Tacker project with very supportive contributors team. In Stein cycle we planned limited features level activities and more towards project stability and max test & code coverage things. We were able to deliver some rich features like VDU auto-healing and VNF resource reservation, and multiple other features & improvements with the help of great team support. Some of our planned activities are still in progress, and hope to complete them soon. My plan for Train cycle will be more towards: * Tacker CI/CD Improvement: - In stein cycle we added large number of test unit cases, but still we have to work in this area to get max coverage. - Focus to introduce more functional and scenario tests. * Tacker stability & production ready: - Focus to have more error-handling and significant logging. * More towards NFV-MANO rich features: - Make Tacker more ESTI compatible. - CSAR support. * More works in SFC area. * Enhancement on container based VNFs. * More physical gathering of Tacker team in OpenStack conferences. You can find my complete contributions here: http://stackalytics.com/?release=all&project_type=all&metric=commits&user_i… Thanks for reading and consideration my candidacy. Thanks & Regards Dharmendra Kushwaha IRC: dkushwaha

1 0