- openstack-discuss - lists.openstack.org

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

12 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

[tc] smcginnis non-nomination for TC
by Sean McGinnis 12 Feb '19

12 Feb '19

As Chris said, it is probably good for incumbents to make it known if they are not running. This is my second term on the TC. It's been great being part of this group and trying to contribute whatever I can. But I do feel it is important to make room for new folks to regularly join and help shape things. So with that in mind, along with the need to focus on some other areas for a bit, I do not plan to run in the upcoming TC election. I would highly encourage anyone interested to run for the TC. If you have any questions about it, feel free to ping me for any thoughts/advice/feedback. Thanks for the last two years. I think I've learned a lot since joining the TC, and hopefully I have been able to contribute some positive things over the years. I will still be around, so hopefully I will see folks in Denver. Sean

6 5

[tc] cdent non-nomination for TC
by Chris Dent 12 Feb '19

12 Feb '19

Next week sees the start of election season for the TC [1]. People often worry that incumbents always get re-elected so it is considered good form to announce if you are an incumbent and do not intend to run. I do not intend to run. I've done two years and that's enough. When I was first elected I had no intention of doing any more than one year but at the end of the first term I had not accomplished much of what I hoped, so stayed on. Now, at the end of the second term I still haven't accomplished much of what I hoped, so I think it is time to focus my energy in the places where I've been able to get some traction and give someone else—someone with a different approach—a chance. If you're interested in being on the TC, I encourage you to run. If you have questions about it, please feel free to ask me, but also ask others so you get plenty of opinions. And do your due diligence: Make sure you're clear with yourself about what the TC has been, is now, what you would like it to be, and what it can be. Elections are fairly far in advance of the end of term this time around. I'll continue in my TC responsibilities until the end of term, which is some time in April. I'm not leaving the community or anything like that, I'm simply narrowing my focus. Over the past several months I've been stripping things back so I can be sure that I'm not ineffectively over-committing myself to OpenStack but am instead focusing where I can be most useful and make the most progress. Stepping away from the TC is just one more part of that. Thanks very much for the experiences and for the past votes. [1] https://governance.openstack.org/election/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

7 6

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

12 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

Denver PTG Attending Teams
by Kendall Nelson 12 Feb '19

12 Feb '19

Hello! The results are in! Here are the list of teams that are planning to attend the upcoming PTG in Denver, following the summit. Hopefully we are getting it to you soon enough to plan travel. If you haven't already registered yet, you can do that here[1]. If you haven't booked your hotel yet, please please please use our hotel block here[2]. ----------------------------------------- Pilot Projects: - Airship - Kata Containers - StarlingX OpenStack Components: - - Barbican - Charms - Cinder - Cyborg - Docs/I18n - Glance - Heat - Horizon - Infrastructure - Ironic - Keystone - LOCI - Manila - Monasca - Neutron - Nova - Octavia - OpenStack Ansible - OpenStack QA - OpenStackClient - Oslo - Placement - Release Management - Requirements - Swift - Tacker - TripleO - Vitrage - OpenStack-Helm SIGs: - API-SIG - AutoScaling SIG - Edge Computing Group - Extended Maintenance SIG - First Contact SIG - Interop WG/RefStack - K8s SIG - Scientific SIG - Security SIG - Self-healing SIG ------------------------------------------ If your team is missing from this list, its because I didn't get a 'yes' response from your PTL/Chair/Contact Person. Have them contact me and we can try to work something out. Now that we have this list, we will start putting together a draft schedule. See you all in Denver! -Kendall (diablo_rojo) [1] https://www.eventbrite.com/e/open-infrastructure-summit-project-teams-gathe… [2] https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE

1 0

[ironic] should console be renamed to seriale_console ?
by elfosardo 12 Feb '19

12 Feb '19

Greetings Openstackers! Currently ironic supports only one type of console: serial The current implementation also gives as assumed the support for just one type of console, but not that long ago a spec to also support a graphical console type [1] has been accepted and we're now close to see a first patch with basic support merged [2]. With the introduction of the support for the graphical console, the need to define a new parameter called "console_type" has been recognized. In practice, at the moment that would mean having "console" and "graphical" as console types, which could result in a confusing and in the end not correct implementation. With this message I'd like to start a discussion on the potential impact of the possible future renaming of everything that currently involves the serial console from "console" to "serial_console" or equivalent. Thanks, Riccardo [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/vn… [2] https://review.openstack.org/#/c/547356/

1 0

[PTLs] Got unfinished business from Berlin?
by Matt Van Winkle 12 Feb '19

12 Feb '19

Greetings, PTLs, cores or anyone on point for a key feature, In an effort to make the feedback loop even stronger between the dev and ops community, the UC is actively looking for any unfinished etherpads or topics from the Berlin summit that need more Ops input. We'd like to get them proposed as potential topics at the upcoming Ops Meetup (strangely enough back in Berlin) [1] If you have something your dev team needs input on, please propose it here: [2] so it can get voted on by the attendees and organizers. There is a section titled "Session Ideas" that you can list the topic in. Feel free to link an etherpad if one exists. The UC will continue to push to tie discussions at forums/PTGs to those at the Ops meetups and OpenStack Days - and vice versa. Thanks in advance! VW [1] https://www.eventbrite.com/e/openstack-ops-meetup-berlin-tickets-55034908894 [2] https://etherpad.openstack.org/p/BER-ops-meetup -- Matt Van Winkle Senior Manager, Software Engineering | Salesforce

1 0

[ops] last weeks ops meetups team minutes
by Chris Morgan 12 Feb '19

12 Feb '19

Meeting ended Tue Feb 5 15:31:14 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:31 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:31 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:31 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Next meeting is in 25 minutes on #openstack-operators Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[nova] Can we drop the cells v1 docs now?
by Matt Riedemann 12 Feb '19

12 Feb '19

I have kind of lost where we are on dropping cells v1 code at this point, but it's probably too late in Stein. And technically nova-network won't start unless cells v1 is configured, and we've left the nova-network code in place while CERN is migrating their deployment to neutron*. CERN is running cells v2 since Queens and I think they have just removed this [1] to still run nova-network without cells v1. There has been no work in Stein to remove nova-network [2] even though we still have a few API related things we can work on removing [3] but that is very low priority. To be clear, CERN only cares about the nova-network service, not the APIs which is why we started removing those in Rocky. As for cells v1, if we're not going to drop it in Stein, can we at least make incremental progress and drop the cells v1 related docs to further signal the eventual demise and to avoid confusion in the docs about what cells is (v1 vs v2) for newcomers? People can still get the cells v1 in-tree docs on the stable branches (which are being published [4]). [1] https://github.com/openstack/nova/blob/bff3fd1cd/nova/cmd/network.py#L43 [2] https://blueprints.launchpad.net/nova/+spec/remove-nova-network-stein [3] https://etherpad.openstack.org/p/nova-network-removal-rocky [4] https://docs.openstack.org/nova/queens/user/cells.html#cells-v1 *I think they said there are parts of their deployment that will probably never move off of nova-network, and they will just maintain a fork for that part of the deployment. -- Thanks, Matt

3 2

[tripleo][openstack-ansible] collaboration on os_tempest role update X - Feb 12, 2019
by Chandan kumar 12 Feb '19

12 Feb '19

Hello, Here is the 10th update (Feb 06 to Feb 12, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: This week we basically worked on clearing up/merging the existing patches like: * For debugging networking issue for os_tempest, we have router ping * Added telemetry tempest plugin support * The os_tempest overview page got rewrite: https://docs.openstack.org/openstack-ansible-os_tempest/latest/overview.html * Added use of user/password for secure image download And from myside, not to much work as busy with ruck/rover on TripleO Side. Things got merged OS_TEMPEST: * Update all plugin urls to use https rather than git - https://review.openstack.org/633752 * venv: use inventory_hostname instead of ansible_hostname - https://review.openstack.org/635187 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Add user and password for secure image download (optional) - https://review.openstack.org/625266 * Ping router once it is created - https://review.openstack.org/633883 * Improve overview subpage - https://review.openstack.org/633934 python-venv_build: * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/634377 In Progress work: OS_TEMPEST * Use the correct heat tests - https://review.openstack.org/#/c/630695/ * Add option to disable router ping - https://review.openstack.org/636211 * Add tempest_service_available_mistral with distro packages - https://review.openstack.org/635180 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 TripleO: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Goal of this week: * Unblock os_heat gate due to mpi4py dependency and other issue * Complete skip list reuse on tripleo side Thanks to jrosser, mnaser, odyssey4me, guilhermesp on router_ping, os_heat help, arxcruz on reuse skip list & mkopec for improving doc. Here is the 9th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002382… Thanks, Chandan Kumar

1 0