January 2019 - openstack-discuss - lists.openstack.org

Re: Why COA exam is being retired?
by Lauren Sell 16 Feb '19

16 Feb '19

Thanks very much for the feedback. When we launched the COA, the commercial market for OpenStack was much more crowded (read: fragmented), and the availability of individuals with OpenStack experience was more scarce. That indicated a need for a vendor neutral certification to test baseline OpenStack proficiency, and to help provide a target for training curriculum being developed by companies in the ecosystem. Three years on, the commercial ecosystem has become easier to navigate, and there are a few thousand professionals who have taken the COA and had on-the-job experience. As those conditions have changed, we've been trying to evaluate the best ways to use the Foundation's resources and time to support the current needs for education and certification. The COA in its current form is pretty resource intensive, because it’s a hands-on exam that runs in a virtual OpenStack environment. To maintain the exam (including keeping it current to OpenStack releases) would require a pretty significant investment in terms of time and money this year. From the data and demand we’re seeing, the COA did not seem to be a top priority compared to our investments in programs that push knowledge and training into the ecosystem like Upstream Institute, supporting OpenStack training partners, mentoring, and sponsoring internship programs like Outreachy and Google Summer of Code. That said, we’ve honestly been surprised by the response from training partners and the community as plans have been trickling out these past few weeks, and are open to discussing it. If there are people and companies who are willing to invest time and resources into a neutral certification exam, we could investigate alternative paths. It's very helpful to hear which education activities you find most valuable, and if you'd like to have a deeper discussion or volunteer to help, let me know and we can schedule a community call next week. Regardless of the future of the COA exam, we will of course continue to maintain the training marketplace at openstack.org to promote commercial training partners and certifications. There are also some great books and resources developed by community members listed alongside the community training. > From: Jay Bryant jungleboyj(a)gmail.com > Date: January 25, 2019 07:42:55 > Subject: Re: Why COA exam is being retired? > To: openstack-discuss(a)lists.openstack.org > >> On 1/25/2019 9:27 AM, Jonathan Proulx wrote: >>> On Fri, Jan 25, 2019 at 10:09:04AM -0500, Jay Pipes wrote: >>> :On 01/25/2019 09:09 AM, Erik McCormick wrote: >>> :> On Fri, Jan 25, 2019, 8:58 AM Jay Bryant <jungleboyj(a)gmail.com >>> >>> :> That's sad. I really appreciated having a non-vendory, ubiased, >>> :> community-driven option. >>> : >>> :+10 >>> : >>> :> If a vendor folds or moves on from Openstack, your certification >>> :> becomes worthless. Presumably, so long as there is Openstack, there >>> :> will be the foundation at its core. I hope they might reconsider. >>> : >>> :+100 >>> >>> So to clarify is the COA certifiaction going away or is the Foundation >>> just no longer administerign the exam? >>> >>> It would be a shame to loose a standard unbiased certification, but if >>> this is a transition away from directly providing the training and >>> only providing the exam specification that may be reasonable. >>> >>> -Jon >> >> When Allison e-mailed me last week they said they were having meetings >> to figure out how to go forward with the COA. The foundations partners >> were going to be offering the exam through September and they were >> working on communicating the status of things to the community. >> >> So, probably best to not jump to conclusions and wait for the official >> word from the community. >> >> - Jay > > >

1 2

[tc][all] Train Community Goals
by Lance Bragstad 16 Feb '19

16 Feb '19

Hi all, The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0]. During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes): 1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here. Does anyone have strong opinions either way about the goals listed above? [0] https://etherpad.openstack.org/p/BER-t-series-goals

15 26

Open Infrastructure Summit Denver - Community Voting Open
by Ashlee Ferguson 15 Feb '19

15 Feb '19

Hi everyone, Community voting for the Open Infrastructure Summit Denver sessions is open! You can VOTE HERE <https://www.openstack.org/summit/denver-2019/vote-for-speakers>, but what does that mean? Now that the Call for Presentations has closed, all submissions are available for community vote and input. After community voting closes, the volunteer Programming Committee members will receive the presentations to review and determine the final selections for Summit schedule. While community votes are meant to help inform the decision, Programming Committee members are expected to exercise judgment in their area of expertise and help ensure diversity of sessions and speakers. View full details of the session selection process here <https://www.openstack.org/summit/denver-2019/call-for-presentations/selecti…>. In order to vote, you need an OSF community membership. If you do not have an account, please create one by going to openstack.org/join <http://openstack.org/join>. If you need to reset your password, you can do that here <https://www.openstack.org/Security/lostpassword>. Hurry, voting closes Monday, February 4 at 11:59pm Pacific Time (Tuesday, February 5 at 7:59 UTC). Continue to visit https://www.openstack.org/summit/denver-2019 <https://www.openstack.org/summit/denver-2019> for all Summit-related information. REGISTER Register for the Summit <https://openinfrasummitandptgdenver.eventbrite.com/> before prices increase in late February! VISA APPLICATION PROCESS Make sure to secure your Visa soon. More information <https://www.openstack.org/summit/denver-2019/travel/#travel-support> about the Visa application process. TRAVEL SUPPORT PROGRAM February 27 is the last day to submit applications. Please submit your applications <https://www.openstack.org/summit/denver-2019/travel/#travel-support> by 11:59pm Pacific Time (February 28 at 7:59am UTC). If you have any questions, please email summit(a)openstack.org. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org

4 5

[tc][all][self-healing-sig] Service-side health checks community goal for Train cycle
by Jean-Philippe Evrard 14 Feb '19

14 Feb '19

Hello everyone, As you might have seen on the ML, two of the 3 top contenders for the Train cycle community got some traction. Let's here talk about the last one: The service-side health checks. While people were interested in this goal previously, nobody really came forward on the pre-work. Last week, I met a few of my colleagues to see what we can do together. Matt (irc: mattoliverau), Adam (irc: aspiers), and I discussed about the different ways to implement this new API, with the help of many in #openstack-sdk. Long story short, the current framework might be "good enough" for extension already, as we could have extra "backends" (basically "tests"), to increase the coverage of this healthcheck endpoint. While the immediate next step would be to work on the v2 prototype that Graham started (see link [1], anyone is welcome to help there!), the next step would be far easier if it was crowd sourced: We need to know which service is already using that oslo middleware, which service doesn't want to use it, and which service is already ready for healtchecks. When we'll have a lay of the land, we'll know where the energy will be spent in this community goal: Would that be bringing oslo.middleware to <insert amount here> services or bringing common "backends" that can be used by each service (like DB/MQ/cache checks). I would be very happy if you could have a look at this ethercal [2], and add/edit your project capabilities there. Thank you in advance. Jean-Philippe Evrard (evrardjp) [1]: https://review.openstack.org/#/c/617924/ [2]: https://ethercalc.openstack.org/di0mxkiepll8

4 5

[manila][glusterfs] on queens error
by Ignazio Cassano 13 Feb '19

13 Feb '19

Hello All, I installed manila on my queens openstack based on centos 7. I configured two servers with glusterfs replocation and ganesha nfs. I configured my controllers octavia,conf but when I try to create a share the manila scheduler logs reports: Failed to schedule create_share: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter.: NoValidHost: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter. 2019-01-31 16:07:32.614 159380 INFO manila.message.api [req-241d66b3-8004-410b-b000-c6d2d3536e4a 89f76bc5de5545f381da2c10c7df7f15 59f1f232ce28409593d66d8f6495e434 - - -] Creating message record for request_id = req-241d66b3-8004-410b-b000-c6d2d3536e4a I did not understand if controllers node must be connected to the network where shares must be exported for virtual machines, so my glusterfs are connected on the management network where openstack controllers are conencted and to the network where virtual machine are connected. My manila.conf section for glusterfs section is the following [gluster-manila565] driver_handles_share_servers = False share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver glusterfs_target = root@10.102.184.229:/manila565 glusterfs_path_to_private_key = /etc/manila/id_rsa glusterfs_ganesha_server_username = root glusterfs_nfs_server_type = Ganesha glusterfs_ganesha_server_ip = 10.102.184.229 #glusterfs_servers = root(a)10.102.185.19 ganesha_config_dir = /etc/ganesha PS 10.102.184.0/24 is the network where controlelrs expose endpoint 10.102.189.0/24 is the shared network inside openstack where virtual machines are connected. The gluster servers are connected on both. Any help, please ? Ignazio

3 14

[keystone] x509 authentication
by Lance Bragstad 13 Feb '19

13 Feb '19

Hi all, We've been going over keystone gaps that need to be addressed for edge use cases every Tuesday. Since Berlin, Oath has open-sourced some of their custom authentication plugins for keystone that help them address these gaps. The basic idea is that users authenticate to some external identity provider (Athenz in Oath's case), and then present an Athenz token to keystone. The custom plugins decode the token from Athenz to determine the user, project, roles assignments, and other useful bits of information. After that, it creates any resources that don't exist in keystone already. Ultimately, a user can authenticate against a keystone node and have specific resources provisioned automatically. In Berlin, engineers from Oath were saying they'd like to move away from Athenz tokens altogether and use x509 certificates issued by Athenz instead. The auto-provisioning approach is very similar to a feature we have in keystone already. In Berlin, and shortly after, there was general agreement that if we could support x509 authentication with auto-provisioning via keystone federation, that would pretty much solve Oath's use case without having to maintain custom keystone plugins. Last week, Colleen started digging into keystone's existing x509 authentication support. I'll start with the good news, which is x509 authentication works, for the most part. It's been a feature in keystone for a long time, and it landed after we implemented federation support around the Kilo release. Chances are there won't be a need for a keystone specification like we were initially thinking in the edge meetings. Unfortunately, the implementation for x509 authentication has outdated documentation, is extremely fragile, hard to set up, and hasn't been updated with improvements we've made to the federation API since the original implementation (like shadow users or auto-provisioning, which work with other federated protocols like OpenID Connect and SAML). We've started tracking the gaps with bugs [0] so that we have things written down. I think the good thing is that once we get this cleaned up, we'll be able to re-use some of the newer federation features with x509 authentication/federation. These updates would make x509 a first-class federated protocol. The approach, pending the bug fixes, would remove the need for Oath's custom authentication plugins. It could be useful for edge deployments, or even deployments with many regions, by allowing users to be auto-provisioned in each region. Although, it doesn't necessarily solve the network partition issue. Now that we have an idea of where to start and some bug reports [0], I'm wondering if anyone is interested in helping with the update or refactor. Because this won't require a specification, we can get started on it sooner, instead of having to wait for Train development and a new specification. I'm also curious if anyone has comments or questions about the approach. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509

4 6

[openstack-ansible] bug squash day!
by Mohammed Naser 13 Feb '19

13 Feb '19

Hi team, As you may have noticed, bug triage during our meetings has been something that has kinda killed attendance (really, no one seems to enjoy it, believe it or not!) I wanted to propose for us to take a day to go through as much bugs as possible, triaging and fixing as much as we can. It'd be a fun day and we can also hop on a more higher bandwidth way to talk about this stuff while we grind through it all. Is this something that people are interested in, if so, is there any times/days that work better in the week to organize? Thanks! Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 9

[neutron] CI issue related to pyroute2 and latest oslo.privsep
by Slawomir Kaplonski 13 Feb '19

13 Feb '19

Hi, Recently we had one more issue related to oslo.privsep and pyroute2. This caused many failures in Neutron CI. See [1] for details. Now fix (more like a workaround) for this issue is merged [2]. So if You saw in Your patch failing tempest/scenario jobs and in failed tests there were issues with SSH to instance through floating IP, please now rebase Your patch. It should be better :) [1] https://bugs.launchpad.net/neutron/+bug/1811515 [2] https://review.openstack.org/#/c/631275/ — Slawek Kaplonski Senior software engineer Red Hat

2 2

Re: Subject: Re: [Trove] State of the Trove service tenant deployment model
by Darek Król 13 Feb '19

13 Feb '19

On Wed, Jan 23, 2019 at 9:27 AM Fox, Kevin M <Kevin.Fox(a)pnnl.gov<mailto:Kevin.Fox@pnnl.gov>> wrote: > > I'd recommend at this point to maybe just run kubernetes across the vms and push the guest agents/workload to them. > This sounds like an overkill to me. Currently, different projects in openstack are solving this issue > in different ways, e.g. Octavia is using two-way SSL authentication API between the controller service and amphora(which is the vm running HTTP server inside), Magnum is using heat-container-agent that is communicating with Heat via API, etc. However, Trove chooses another option which has brought a lot of discussions over a long time. > In the current situation, I don't think it's doable for each project heading to one common solution, but Trove can learn from other projects to solve its own problem. > Cheers, > Lingxian Kong The Octavia way of communication was discussed by Trove several times in the context of secuirty. However, the security threat has been eliminated by encryption. I'm wondering if the Octavia way prevents DDOS attacks also ? Implementation of two-way SSL authentication API could be included in the Trove priority list IMHO if it solves all issues with security/DDOS attacks. This could also creates some share code between both projects and help other services as well. Best, Darek

4 5

Horizon extremely slow with 400 instances
by Satish Patel 11 Feb '19

11 Feb '19

folks, we have mid size openstack cloud running 400 instances, and day by day its getting slower, i can understand it render every single machine during loading instance page but it seems it's design issue, why not it load page from MySQL instead of running bunch of API calls behind then page? is this just me or someone else also having this issue? i am surprised why there is no good and robust Web GUI for very popular openstack? I am curious how people running openstack in large environment using Horizon. I have tired all kind of setting and tuning like memcache etc.. ~S

3 2