- openstack-discuss - lists.openstack.org

[Ops] ops meetups team meeting 2018-12-18
by Chris Morgan 07 Jan '19

07 Jan '19

Meeting minutes from our meeting today on IRC are linked below. Key points: - next meeting Jan 8th 2019 - ops meetup #1 looks likely to be at Deutsche Telekom, Berlin, March 7,8 2019 - the team hopes to confirm this soon and commence technical agenda planning early January - team meetings will continue to be 10AM EST Tuesdays on #openstack-operators Meeting ended Tue Dec 18 15:44:05 2018 UTC. 10:44 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… About the OpenStack Operators Meetups team: https://wiki.openstack.org/wiki/Ops_Meetups_Team Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

[nova] implementation options for nova spec: show-server-numa-topology
by yonglihe 06 Jan '19

06 Jan '19

Hi, guys This spec needs input and discuss for move on. Currently the spec is under reviewing: https://review.openstack.org/#/c/612256/8 Plus with POC code: https://review.openstack.org/#/c/621476/3 and related stein PTG discuss: https://etherpad.openstack.org/p/nova-ptg-stein start from line 897 NUMA topology had lots of information to expose, for saving you time to jumping into to the spec, the information need to return include NUMA related like: numa_node,cpu_pinning,cpu_thread_policy,cpuset,siblings, mem,pagesize,sockets,cores, threads, and PCI device's information. Base on IRC's discuss, we may have 3 options about how to deal with those blobs: 1) include those directly in the server response details, like the released POC does: https://review.openstack.org/#/c/621476/3 2) add a new sub-resource endpoint to servers, most likely use key word 'topology' then: "GET /servers/{server_id}/topology" returns the NUMA information for one server. 3) put the NUMA info under existing 'diagnostics' API. "GET /servers/{server_id}/diagnostics" this is admin only API, normal user loss the possible to check their topology. when the information put into diagnostics, they will be look like: { .... "numa_topology": { cells [ { "numa_node" : 3 "cpu_pinning": {0:5, 1:6}, "cpu_thread_policy": "prefer", "cpuset": [0,1,2,3], "siblings": [[0,1],[2,3]], "mem": 1024, "pagesize": 4096, "sockets": 0, "cores": 2, "threads": 2, }, ... ] # cells } "emulator_threads_policy": "share" "pci_devices": [ { "address":"00:1a.0", "type": "VF", "vendor": "8086", "product": "1526" }, ] } Regards Yongli He

3 8

[murano]Retire of murano-deployment project
by Rong Zhu 06 Jan '19

06 Jan '19

Hi, teams, Murano-deployment project is the third-party CI scripts and automatic tools. Since the third-party CI have already switched to openstack CI, this project doesn't need anymore. So we decided to retire murano-deployment project. Thanks, Rong Zhu -- Thanks, Rong Zhu

1 0

Ironic ibmc driver for Huawei server
by qianbiao.ng＠turnbig.net 05 Jan '19

05 Jan '19

Hi julia, According to the comment of story<https://storyboard.openstack.org/#!/story/2004635 >, 1. The spec for huawei ibmc drvier has been post here: https://storyboard.openstack.org/#!/story/2004635 , waiting for review. 2. About the third-party CI part, we provide mocked unittests for our driver's code. Not sure what third-party CI works for in this case. What else we should do? Thanks Qianbiao.NG

1 0

[docs] question about deprecation badges
by Adam Spiers 04 Jan '19

04 Jan '19

Hi all, I'm currently hacking on the deprecation badges in openstack-manuals, and there's a couple of things I don't understand. Any chance someone could explain why www/latest/badge.html doesn't just do: {% include 'templates/deprecated_badge.tmpl' %} like all the others? https://github.com/openstack/openstack-manuals/commit/961f544a4ec383d8b500a… I'm also what exactly would be wrong with the included CSS path if CSSDIR was used in www/templates/deprecated_badge.tmpl instead of heeding this caveat: https://github.com/openstack/openstack-manuals/commit/961f544a4ec383d8b500a… It would be good to fix it to use CSSDIR because currently it's awkward to test CSS changes. Thanks! Adam

2 3

Re: [octavia] What is our next plan about 'l3-active-active' blueprint?
by Jeff Yang 04 Jan '19

04 Jan '19

I have no new specs, I plan to follow the original blueprint. https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/acti… Jeff Yang <yjf1970231893(a)gmail.com> 于2019年1月5日周六下午12:16写道： > I have no new specs, I plan to follow the original blueprint. > > https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/acti… > > Sa Pham <saphi070(a)gmail.com> 于2019年1月5日周六上午11:58写道： > >> Hi Jeff, >> >> Do you have design and specs for that. >> >> >> Best, >> >> Sa Pham Dang >> Cloud RnD Team - VCCLOUD >> Phone: 0986849582 >> Skype: great_bn >> >> On Jan 5, 2019, at 10:29 AM, Jeff Yang <yjf1970231893(a)gmail.com> wrote: >> >> Yes, I want to reboot this work recently. And, I want to replace >> exabgp with >> os-ken, So I may need to rewrite some patches. >> >> Michael Johnson <johnsomor(a)gmail.com> 于2019年1月5日周六上午8:02写道： >> >>> Hi Jeff, >>> >>> Unfortunately the team that was working on that code had stopped due >>> to internal reasons. >>> >>> I hope to make the reference active/active blueprint a priority again >>> during the Train cycle. Following that I may be able to look at the L3 >>> distributor option, but I cannot commit to that at this time. >>> >>> If you are interesting in picking up that work, please let me know and >>> we can sync up on that status of the WIP patches, etc. >>> >>> Michael >>> >>> On Thu, Jan 3, 2019 at 11:19 PM Jeff Yang <yjf1970231893(a)gmail.com> >>> wrote: >>> > >>> > Dear Octavia team: >>> > The email aims to ask the development progress about >>> l3-active-active blueprint. I >>> > noticed that the work in this area has been stagnant for eight months. >>> > https://review.openstack.org/#/q/l3-active-active >>> > I want to know the community's next work plan in this regard. >>> > Thanks. >>> >>

1 0

Per-VM CPU & RAM allocation?
by Ken D'Ambrosio 04 Jan '19

04 Jan '19

Hi! If I go into the UI, I can easily see how much each VM is allocated for RAM and CPU. However, I've googled until I'm blue in the face, and can't seem to see a way -- either through CLI or API -- to get that info. "nova limits --tenant <foo>" SEEMS like it should... except (at least on my Juno cloud), the "used" column is either full of zeros or dashes. Clearly, if it's in the UI, it's possible... somehow. But it seemed like it might be easier to ask the list than go down the rabbit hole of tcp captures. Any ideas? Thanks! -Ken P.S. Not interested in CPU-hours/usage -- I'm just looking for how much is actually allocated.

3 2

Update on gate status for the new year
by Clark Boylan 04 Jan '19

04 Jan '19

I'm still not entirely caught up on everything after the holidays, but thought I would attempt to do another update on gate reliability issues since those were well received last month. Overall things look pretty good based on elastic-recheck data. That said I think this is mostly due to low test volume over the holidays and our 10 day index window. We should revisit this next week or the week after to get a more accurate view of things. On the infra team side of things we've got quota issues in a cloud region that has decreased our test node capacity. Waiting on people to return from holidays to take a look at that. We also started tracking hypervisor IDs for our test instances (thank you pabelanger) to try and help identify when specific hypervisors might be the cause of some of our issues. https://review.openstack.org/628642 is a followup to index that data with our job log data in Elasticsearch. We've seen some ssh failures in tripleo jobs on limestone [0] and neutron and zuul report constrained IOPS there resulting in failed database migrations. I think the idea with 628642 is to see if we can narrow that down to specific hypervisors. On the project side of things our categorization rates are quite low [1][2]. If your changes are evicted from the gate due to failures it would be helpful if you could spend a few minutes to try and identify and fingerprint those failures. We'll check back in a week or two when we should have a much better data set to look at. [0] http://status.openstack.org/elastic-recheck/index.html#18100542 [1] http://status.openstack.org/elastic-recheck/data/integrated_gate.html [2] http://status.openstack.org/elastic-recheck/data/others.html Clark

2 1

[cinder] Addition mid-cycle details ...
by Jay Bryant 04 Jan '19

04 Jan '19

Team, We are at about a month away from the Cinder Mid-Cycle in Raleigh. I have started requesting drinks/snacks and have rooms reserved. I soon will need a firm number of people attending so that I can finalize the various requests. If you are planning to physically attend and have not yet added your name to our planning etherpad [1] please do so ASAP. I have reserved a room at the Hyatt House Raleigh Durham Airport (10962 Chapel Hill Road, Morrisville, NC, 27560, USA ) <http://maps.google.com/?q=loc:35.85501,-78.8407> if people want to stay at the same hotel as myself. It is close to the Lenovo site which will make it easier to travel if we have unexpected snowy weather there. We can also carpool to reduce the problem of finding parking. I am arriving the afternoon of 2/4/19 and leaving the morning of 2/9/19. Also a reminder to please add topics to the mid-cycle planning etherpad regardless of whether you are able to attend or not. Look forward to seeing you in Raleigh next month! Jay (jungleboyj) [1] https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning

1 0

[all] One month with openstack-discuss (a progress report)
by Jeremy Stanley 04 Jan '19

04 Jan '19

First, I want to thank everyone here for the remarkably smooth transition to openstack-discuss at the end of November. It's been exactly one month today since we shuttered the old openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists and forwarded all subsequent posts for them to the new list address instead. The number of posts from non-subscribers has dwindled to the point where it's now only a few each day (many of whom also subscribe immediately after receiving the moderation autoresponse). As of this moment, we're up to 708 subscribers. Unfortunately it's hard to compare raw subscriber counts because the longer a list is in existence the more dead addresses it accumulates. Mailman does its best to unsubscribe addresses which explicitly reject/bounce multiple messages in a row, but these days many E-mail addresses grow defunct without triggering any NDRs (perhaps because they've simply been abandoned, or because their MTAs just blackhole new messages for deleted accounts). Instead, it's a lot more concrete to analyze active participants on mailing lists, especially since ours are consistently configured to require a subscription if you want to avoid your messages getting stuck in the moderation queue. Over the course of 2018 (at least until the lists were closed on December 3) there were 1075 unique E-mail addresses posting to one of more of the openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists. Now, a lot of those people sent one or maybe a handful of messages to ask some question they had, and then disappeared again... they didn't really follow ongoing discussions, so probably won't subscribe to openstack-discuss until they have something new to bring up. On the other hand, if we look at addresses which sent 10 or more messages in 2018 (an arbitrary threshold admittedly), there were 245. Comparing those to the list of addresses subscribed to openstack-discuss today, there are 173 matches. That means we now have *at least* 70% of the people who sent 10 or more messages to the old lists subscribed to the new one. I say "at least" because we don't have an easy way to track address changes, and even if we did that's never going to get us to 100% because there are always going to be people who leave the lists abruptly for various reasons (perhaps even disappearing from our community entirely). Seems like a good place to be after only one month, especially considering the number of folks who may not have even been paying attention at all during end-of-year holidays. As for message volume, we had a total of 912 posts to openstack-discuss in the month of December; comparing to the 1033 posts in total we saw to the four old lists in December of 2017, that's a 12% drop. Consider, though, that right at 10% of the messages on the old lists were duplicates from cross-posting, so that's really more like a 2% drop in actual (deduplicated) posting volume. It's far less of a reduction than I would have anticipated based on year-over-year comparisons (for example, December of 2016 had 1564 posts across those four lists). I think based on this, it's safe to say the transition to openstack-discuss hasn't hampered discussion, at least for its first full month in use. -- Jeremy Stanley

5 4