December 2019 - openstack-discuss

Upgrade: Juno -> Pike (or maybe later)
by Ken D'Ambrosio 13 Dec '19

13 Dec '19

Hey -- I've run a number of OpenStack clouds from multiple vendors for several years, now. But I've *never* done an upgrade. I've read some of the docs, but they don't really make it clear (at least, the ones I've thus-far found): * If going from Juno to something pretty recent is even feasible * If I have to do intermediate steps along the way * How likely it is to "just work:" complexity, common issues, etc. The fact that there's a clearly codified fallback procedure, while an inherently good thing to have, does concern me some. Any insights would be much appreciated. Thanks! -Ken

5 4

[all][tc] What happened in OpenStack Governance recently
by Jean-Philippe Evrard 13 Dec '19

13 Dec '19

Hello folks! We've finally made up our mind with the release naming process. We got a majority of the TC voting positively for a simplified release naming process [0]. Talking about naming, V-release naming poll already started [6]. Go pick your favorit now! Voting will officially end December 16, 2019 at 23:59 UTC! So... pick now! Thanks for Colleen Murphy (cmurphy) and Ghanshyam Mann (gmann) starting a policy pop up team [2]. Please raise your hand if you're interested to participate. devstack already migrated to Python3 and most of our non-python2 specific jobs are also migrated. Your test jobs (like grenade jobs) could need migration, like [1]. Also, if you want to know a full status update of the `Drop Python 2.7 Support`, you can find the status update in [9]. The ansible-sig has new repositories! ansible-collections-openstack [4], ansible-plugin-container-connection will be joining soon [5] There is a new charm charm-cinder-backup-swift-proxy [3] SIG guideline [8] is landed, so if you're maintaining or starting a SIG. Please check it out and provide your feedback to make it getting better. Thanks to Graham Hayes, the last OpenStack Foundation board meeting has officially approved to the savedotorg campaign [7]. Have a good week-end, enjoy your end of year holidays (assuming you have some soon), and merry Christmas/happy new year for those who celebrate them! :) Regards, JP & Rico [0] https://review.opendev.org/#/c/695071/3 [1] https://review.opendev.org/#/c/695088/ [2] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defau… [3] https://review.opendev.org/696723 [4] https://review.opendev.org/684740 [5] https://review.opendev.org/696737 [6] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011477… [7] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011155… [8] https://governance.openstack.org/sigs/reference/sig-guideline.html [9] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011432…

1 0

[nova] live migration with the NUMA topology
by Brin Zhang(张百林) 13 Dec '19

13 Dec '19

Hi folks:: About http://specs.openstack.org/openstack/nova-specs/specs/train/approved/numa-a… this spec in Train. I have a question, if the destination server's NUMA topology (e.g. nume_node=2) < source server's NUMA topology (e.g. numa_noed=4) in a instance. If I am living migration *this* instance, what will be happened? Rollback and keep the instance to the original status? Or make it to ERROR? In that SPEC I had not find the details about the red description in "Third, information about the instance’s new NUMA characteristics needs to be generated on the destination (an InstanceNUMATopolgy object is not enough, more on that later)", or lack of careful reading :). Anyway, I want to know how to deal with this NUMA topology during live migration? Thanks.

3 3

[dev] Counting the chaff
by Jeremy Stanley 12 Dec '19

12 Dec '19

It happens with some regularity that I or others are asked for code change volume numbers on OpenStack to compare its activity level against similar numbers published by other open-source projects, and I pretty much always wind up needing to couch my answers with the fact that commit counts published by projects following different workflows aren't directly comparable. Most often, these other projects employ an additive pull request model common to GitHub and similar platforms, which causes many times more commits to appear in their branch histories than happens with a rebase or squash model. (Note that there *are* plenty of high-profile projects on GitHub like Kubernetes using more of a rebase model, with PR owners typically force-pushing changes to address reviewer comments or CI results, and also projects where it's their custom to squash all commits in a PR before merging, so in those cases our normal change counts are more applicable for ~1:1 comparisons.) In order to be able to provide more useful data, I decided to try and find a way of approximating the "chaff" we discard when we merge the "wheat" of our rebased code changes. The Gerrit API provides information on the revision count for changes, so adding the number of revisions for each merged change basically gives us the answer. OpenStack's election tooling already tallies counts of changes merged, so adding an aggregate revision counter to that was fairly trivial: https://review.opendev.org/698291 A word on merge commits: While a direct count of Git commits will be additionally inflated by the merge commits used to stitch changes into a branch, and approach a 1:1 ratio with the number of changes merged in higher-volume projects (except possibly in projects squashing or cherry-picking/rebasing at merge time), GitHub's commit counts explicitly exclude merge commits in order to provide more useful metrics, therefore we don't need to factor them into our calculations: https://developer.github.com/v3/repos/statistics/#statistics-exclude-some-t… So with all that explanation out of the way (and thanks to those of you who read this far!), it's time for some numbers. Looking at the past five years, here's the breakdown... 1409697 revisions / 459770 changes ~= 3 Now this was calculated using the current OpenStack governance data so the exact change counts aren't official numbers because they could include data from a slightly different set of Git repositories than were official in those years, but the goal of this exercise was to obtain a rough coefficient so I think that's a reasonable simplification. This "GitHub coefficient" of 3 is then a number by which OpenStack change volume can be multiplied to provide a rough approximation for comparison with activity numbers for projects following the common GitHub iterative PR workflow (at least for projects which see similar levels of PR updating to OpenStack's change revision frequency). Out of curiosity, I also took a look at how that coefficient has evolved over time... 2015: 3.35 2016: 3.12 2017: 3.05 2018: 2.77 2019: 2.76 It's interesting to note that OpenStack's overall chaff-to-wheat ratio has been trending downward. This could be due to a number of factors. Are contributors getting better instruction and feedback to help them understand what reviewers expect? Is our project gating automation catching more errors and wasting less developer time on each change? Are reviewers possibly becoming more lax and fixing nits in subsequent changes rather than demanding more revisions to otherwise "good enough for now" changes? Are we seeing a rise in projects with lower affiliation diversity resulting in changes merging with minimal or no review? It could be any or all of these. I tried to dig back even farther to see if this pattern was consistent. What I found, in retrospect, should perhaps not be all that surprising... 2011: 1.79 2012: 2.12 2013: 2.72 2014: 3.18 Okay, so 2011/2012 are much lower, perhaps because contributors were still for the most part getting used to the ideas of code review and pre-merge testing in the first few years of the project. The data we have in Gerrit about this earlier period is also somewhat less reliable anyway, but it's worth pointing out that the curve for revisions-per-change roughly follows the curve for total change volume (peaking around 2014-2016). So maybe the answer is that when we try to move faster we become less efficient? Additional rebases due to a higher incidence of merge conflicts could be an explanation there. The patch which adds revision counting makes it possible to calculate change revisions for deliverables of different teams as well. These are the five teams with the highest and five with the lowest coefficients for this year... 12.5: I18n 5.58: Nova 5.33: OpenStack Helm 5.15: Cyborg 4.27: Storlets ... 1.74: SIGs (constructed "team" encompassing all SIG-owned repos) 1.73: Murano 1.64: Release Management 1.56: Puppet OpenStack 1.56: Requirements You can of course draw all sorts of conclusions from a comparison like this. Clearly there's something about the I18n team's changes which result in a very high revision count, but it's not immediately clear to me what that is (they only have a two repositories, one of which is basically unused and the other mostly just merges infrequent bot-proposed changes). It's also possible that the Nova team's reputation for being thorough reviewers is a well-deserved one. On the other hand some teams like Release Management and Requirements with well-structured, policy-oriented changes tend to merge at the first or second iteration on average. Hopefully some of you find this useful. For me, it's an interesting way to see evidence of some of the additional work our community is doing when it comes to making changes to its software, which isn't necessarily evident from the basic change counts we normally see published. It likely raises more questions than it answers, but I think the introspection it drives is also a healthy exercise for the community. One final note, I've got a trimmed-down and compressed archive of the data from which the above numbers were extracted I can forward to anyone wants to do their own digging, just let me know if you would like a copy. I was going to attach it to this analysis but that would have resulted in a >300KB message to the mailing list, so I thought better of that plan. -- Jeremy Stanley

4 4

[nova] No more meetings til 2020
by Eric Fried 12 Dec '19

12 Dec '19

Next nova meeting is January 2nd (2100 UTC), though I don't expect it to be heavily attended. efried .

1 0

[largescale-sig] Next meeting: Dec 18, 9utc
by Thierry Carrez 12 Dec '19

12 Dec '19

Hi everyone, The Large Scale SIG will have a meeting next week on Wednesday, Dec 18 at 9 UTC[1] in #openstack-meeting on IRC. [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20191218T09 Since the first meeting[2], the SIG was officially approved[3] and is now listed on the SIG page[4]. [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011206… [3] https://review.opendev.org/696302 [4] https://governance.openstack.org/sigs/ For our next meeting I'd like us to work on refining the initial goals that we discussed at the first meeting, ideally splitting them into early objectives and initial steps. The two goals are documented in the following etherpads: Scaling within one cluster, and instrumentation of the bottlenecks: https://etherpad.openstack.org/p/large-scale-sig-cluster-scaling Document large scale configuration and tips &tricks: https://etherpad.openstack.org/p/large-scale-sig-documentation In preparation for the meeting, please review those documents and add specific actions, notes and comments to them. Regards, -- Thierry Carrez (ttx)

1 0

[infra][zuul][kolla] ansible_python_interpreter & stable branches
by Mark Goddard 12 Dec '19

12 Dec '19

Hi, It appears that Zuul is now using python3 as the ansible_python_interpreter for Ubuntu [0]. This seems to also affect stable branches. For kolla ansible this has broken our deploy job which uses the pip module to install our dependencies, and now does so using python3. For Stein and earlier, our scripts use #/usr/bin/env python, which links to python2. I think we can easily fix this by setting ansible_python_interpreter in our zuul vars on stable branches, but perhaps there are some other unintended side-effects? Cheers, Mark [0] https://zuul.opendev.org/t/openstack/build/e0c56c36ef064c9dae00d31ea2979b32…

1 0

[manila] No weekly meeting on 12/12/2019
by Goutham Pacha Ravi 11 Dec '19

11 Dec '19

Hi Zorillas and other interested stackers, Numerous Manila contributors convened today for a virtual PTG and discussed a range of topics [1]. I will compile the concerns, agreements and action items and send out a summary to this list soon. We also decided that we would skip this week's meeting since some of us will be on PTO tomorrow 12/12 and most pressing concerns were addressed during the Virtual PTG. If you have any questions/concerns, please bring them to #openstack-manila on freenode; or post on this mailing list. See you all on 19th Dec 2019 at 15:00 UTC! [2] Cheers! Goutham [1] https://etherpad.openstack.org/p/shanghai-ptg-manila-virtual [2] https://wiki.openstack.org/wiki/Manila/Meetings

1 0

Re: [neutron][queens] dhcp issue
by Ignazio Cassano 11 Dec '19

11 Dec '19

Slawek, I got same errors in /var/log/messages: Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send DHCP/BOOTP option 121: no space left in packet Il giorno mer 11 dic 2019 alle ore 09:19 Slawek Kaplonski < skaplons(a)redhat.com> ha scritto: > Hi, > > Can You maybe give us some more details? Like how exactly this network and > subnets looks like (neutron net-show and neutron subnet-show), and please > also check dnsmasq config files - those are located on node where DHCP > agent is running. If You will do something like: > > ps aux | grep <network_id> > > You will find dnsmasq process for this network. > > > On 10 Dec 2019, at 16:52, Ignazio Cassano <ignaziocassano(a)gmail.com> > wrote: > > > > Hello Everyone, > > I have an openstack queens installation based on centos 7. > > I created a shared vlan network and multiple subnet under it. > > When I start an instance on one of the subnet network it gets the > correct ip based on its subnet but the gateway seems random (one of the > subnet of the vlan). > > > > Any suggestion, please ? > > > > Ignazio > > > > — > Slawek Kaplonski > Senior software engineer > Red Hat > >

3 5

a question about ironic booting from volume
by 海风吹 11 Dec '19

11 Dec '19

hi:    The pike version of ironic support the feature: booting from volume. There is a question: when booting from volume, the baremetal node should be reachable to the storage node,but when deploy done, the baremetal's network  completely belong to the vpc. How could the baremetal node booting from volume??      I should add the extar storage nic to communicate with storage node??         expecting for the answer thanks guo

2 1