- openstack-discuss - lists.openstack.org

[openstacksdk][nova] distinguish image and boot from volume instances
by Blom, Merlin, NMU-OI 13 Dec '19

13 Dec '19

Hey, I wrote a function for distinguishing an image instance from an boot from volume instance for billing purpose. But it does not work this way, it seems as if BfV Instances also have the Image property set. Is there an elegant solution other than analyzing the volume attachment state? This cloud be a problem, because an image instance cloud also have volumes. def getBootFromVolInstances(serverId): '''Determines wether an instance is a boot frome volume instance''' server = conn.compute.find_server(serverId, ignore_missing=True) if server: if server.image: return False else: return True return False Merlin Blom Cloud System Engineer E-Mail: <mailto:merlin.blom@bertelsmann.de> merlin.blom(a)bertelsmann.de <https://www.arvato-systems.de> arvato-systems.de

3 3

Finding configuration values
by Albert Braden 13 Dec '19

13 Dec '19

This thread consists of 6 emails, all from me: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011465… This illustrates a problem I've seen in Openstack. Many of the configuration settings are undocumented, or the documentation is obscure. The only way for an openstack operator to know the correct setting is to be told by an openstack developer. Sometimes I get lucky and someone tells me the answer on IRC, or here on the list. Sometimes nobody does, and then it seems that I am stuck. I have to keep bugging the developers until they tell me the answer. In this case, after searching for a week, I opened a Neutron bug, and then one of the Neutron developers told me how to fix my config. What am I doing wrong? Is there a document I should be reading, that tells how to configure openstack? Why are there no answers in #openstack? Does everyone else have this same issue, or is it only me? How can Openstack operators find out how to configure Openstack, besides begging the developers for the answer?

4 5

[neutron] Drivers meetings cancelled
by Slawek Kaplonski 13 Dec '19

13 Dec '19

Hi neutrinos, As there is Christmas holidays season comming, we decided on today’s drivers meeting, we will cancel next meetings this year. We will meet as usual on January 10th. Happy holidays and see You all in January :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

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

[ironic] Last meeting of 2019 will be December 16th.
by Julia Kreger 11 Dec '19

11 Dec '19

Greetings everyone, During our weekly meeting this week[1], we had a consensus that we would hold the December 16th meeting as our last for the year as we anticipate a number of contributors will be taking time off. This doesn't prevent anyone from jumping in IRC and saying Good Morning! During this time of year, IRC does tend to become very quiet as people take time off from work. Please feel free to update the whiteboard as necessary[2]. If there are any issues that arise that require immediate attention by the community, please feel free to contact me on IRC. Thanks everyone! -Julia [1]: http://eavesdrop.openstack.org/meetings/ironic/2019/ironic.2019-12-09-15.00… [2]: https://etherpad.openstack.org/p/IronicWhiteBoard

1 0

QUERY ONMONASCA
by Muhammad Hasan 11 Dec '19

11 Dec '19

Hi, Can you share any hands on exercise in monasca api and monasca agent

2 1

[oslo] Schedule for the rest of 2019
by Ben Nemec 11 Dec '19

11 Dec '19

Hi, I said in the meeting I would send this out Monday, but then I didn't. Sorry. :-) I mentioned I was probably going to be out some this week and it looks like I'll be taking the afternoons off. How many? Who knows! Planning is really hard right now. Probably at least the rest of this week, and possibly into next week. So TLDR: If you need to get ahold of me, do it in the morning. I may not be available after that. I also expect the 20th to be my last working day for the year, so I'm going to take this opportunity to cancel the Oslo meetings on the 23rd and 30th. We'll resume in the new year on the 6th. Thanks. -Ben

2 2

[OSSA-2019-006] Credentials API allows listing and retrieving of all users credentials (CVE-2019-19687)
by Gage Hugo 11 Dec '19

11 Dec '19

===================================================================================== OSSA-2019-006: Credentials API allows listing and retrieving of all users credentials ===================================================================================== :Date: December 09, 2019 :CVE: CVE-2019-19687 Affects ~~~~~~~ - Keystone: ==15.0.0, ==16.0.0 Description ~~~~~~~~~~~ Daniel Preussker reported a vulnerability in Keystone's list credentials API. Any user with a role on a project is able to list any credentials with the /v3/credentials API when [oslo_policy] enforce_scope is false. Users with a role on a project are able to view any other users credentials, which could leak sign-on information for Time-based One Time Passwords (TOTP) or othewise. Deployments running keystone with [oslo_policy] enforce_scope set to false are affected. There will be a slight performance impact for the list credentials API once this issue is fixed. Patches ~~~~~~~ - https://review.opendev.org/697731 (Stein) - https://review.opendev.org/697611 (Train) - https://review.opendev.org/697355 (Ussuri) Credits ~~~~~~~ - Daniel Preussker (CVE-2019-19687) References ~~~~~~~~~~ - https://bugs.launchpad.net/keystone/+bug/1855080 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19687

1 0

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

11 Dec '19

It is our case: restarting solves. Many thanks Ignazio Il Mer 11 Dic 2019, 11:25 Slawek Kaplonski <skaplons(a)redhat.com> ha scritto: > Hi, > > I think You could hit bug https://bugs.launchpad.net/neutron/+bug/1848738 > Patch for partial fix for this issue is in master > https://review.opendev.org/#/c/689515/ and it was backported to Queens in > https://review.opendev.org/#/c/690731/ > > But You may also need to backport https://review.opendev.org/#/c/690700/ > to Queens branch to address this issue completly. > > > On 11 Dec 2019, at 10:35, Ignazio Cassano <ignaziocassano(a)gmail.com> > wrote: > > > > Hi, cat /var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts > > tag:tag1,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag1,option:classless-static-route, > 10.138.136.0/21,10.138.168.1,10.138.200.0/21,10.138.168.1,169.254.169.254/32,10.138.168.22,10.138.236.32/27,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.168.1 > > tag:tag1,249, > 10.138.136.0/21,10.138.168.1,10.138.200.0/21,10.138.168.1,169.254.169.254/32,10.138.168.22,10.138.236.32/27,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.168.1 > > tag:tag1,option:router,10.138.168.1 > > tag:tag2,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag2,option:classless-static-route, > 10.138.236.0/27,10.138.232.1,169.254.169.254/32,10.138.232.4,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.1 > > tag:tag2,249, > 10.138.236.0/27,10.138.232.1,169.254.169.254/32,10.138.232.4,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.1 > > tag:tag2,option:router,10.138.232.1 > > tag:tag5,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag5,option:classless-static-route, > 10.138.236.128/27,10.138.232.129,169.254.169.254/32,10.138.232.131,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.129 > > tag:tag5,249, > 10.138.236.128/27,10.138.232.129,169.254.169.254/32,10.138.232.131,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.129 > > tag:tag5,option:router,10.138.232.129 > > tag:tag9,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag9,option:classless-static-route, > 10.138.236.32/27,10.138.232.33,169.254.169.254/32,10.138.232.36,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.33 > > tag:tag9,249, > 10.138.236.32/27,10.138.232.33,169.254.169.254/32,10.138.232.36,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.33 > > tag:tag9,option:router,10.138.232.33 > > tag:tag11,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag11,option:classless-static-route, > 10.138.236.64/27,10.138.232.65,169.254.169.254/32,10.138.232.67,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.65 > > tag:tag11,249, > 10.138.236.64/27,10.138.232.65,169.254.169.254/32,10.138.232.67,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.65 > > tag:tag11,option:router,10.138.232.65 > > tag:tag12,option:dns-server,10.103.48.1,10.103.48.2 > > tag:tag12,option:classless-static-route, > 10.138.236.96/27,10.138.232.97,169.254.169.254/32,10.138.232.101,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,0.0.0.0/0,10.138.232.97 > > tag:tag12,249, > 10.138.236.96/27,10.138.232.97,169.254.169.254/32,10.138.232.101,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,0.0.0.0/0,10.138.232.97 > > > > > > > > > > Thanks > > > > Il giorno mer 11 dic 2019 alle ore 10:29 Slawek Kaplonski < > skaplons(a)redhat.com> ha scritto: > > Hi, > > > > Can You also send me content of the file > /var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts ? > > > > > On 11 Dec 2019, at 09:39, Ignazio Cassano <ignaziocassano(a)gmail.com> > wrote: > > > > > > Thanks for your help: > > > [root@podto2-osctrl01 ~]# neutron net-list > > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > > | id | name > | tenant_id | subnets > | > > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > > | 00361d96-0ea2-4378-8909-dbf7ef4c883f | NVLP2-Provider-backoffice1 > | 85cace94dcc7484c85ff9337eb1d0c4c | > 9ba2a03d-3f95-494f-bd38-7fe85471465d 10.138.179.0/24 | > > > | 28ac0a79-17a9-46f5-a418-77f386b821b5 | NVLP2-Provider-Bk > | 85cace94dcc7484c85ff9337eb1d0c4c | > 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 10.138.177.0/24 | > > > | 2e3edf38-7648-4ac8-a8d7-11448adedcca | NVLP2-Ext-Internet > | 85cace94dcc7484c85ff9337eb1d0c4c | > ff797a1f-7de4-4998-9bdc-29d1241ffb5b 84.240.191.0/24 | > > > | 34a3e80d-a662-4665-ad6f-a7a83e2be346 | NVLP2-Ext-Rupar > | 85cace94dcc7484c85ff9337eb1d0c4c | > 1a88e004-7062-4702-8965-b18ea9d6af87 10.138.181.0/24 | > > > | 435e5609-c91a-4e42-bd1a-87dbc24e4afa | HA network tenant > 85cace94dcc7484c85ff9337eb1d0c4c | | > 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 169.254.192.0/18 | > > > | 7f41aa95-b108-4224-9088-21e32d554646 | admin-self-net > | 85cace94dcc7484c85ff9337eb1d0c4c | > 272ca9b5-2aa0-45d2-90b4-70abe4feac49 192.168.90.0/24 | > > > | | > | | > ea1c69b8-ded6-4028-bba9-63db12213e36 192.168.100.0/24 | > > > | 8b876fb6-10a3-4e92-a499-f62a9d3aa32b | net-vx4-private > | 4e44aad117b64a34806c4785b31c3f88 | > dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b 192.168.213.0/24 | > > > | 993f14c9-1b40-47b7-8ee5-fcb00ef92d48 | HA network tenant > 4e44aad117b64a34806c4785b31c3f88 | | > d2129401-0349-4da3-87fa-5e521b071377 169.254.192.0/18 | > > > | a91bb860-32d6-4961-a319-bf39a492ff92 | NVL-INTERPOD-VNI-PRIV > | 85cace94dcc7484c85ff9337eb1d0c4c | > 7b8987f7-da16-48c0-b86c-f3c4fd507f22 10.138.240.48/28 | > > > | | > | | > a855f85b-46b7-4463-993b-8d867fb38556 10.138.240.0/28 | > > > | b11bd55d-c57b-48d1-9be4-ab690624fb76 | NVLP2-Prov-WEB > | 85cace94dcc7484c85ff9337eb1d0c4c | > 5f369cf5-8b26-4996-97d5-24434f928a84 10.138.236.32/27 | > > > | | > | | > adbe60f2-e02b-4294-8eb8-18ffb0b8bcda 10.138.168.0/21 | > > > | | > | | > ae1386b4-c6bc-4c69-909a-1e902df3bc3f 10.138.232.0/27 | > > > | | > | | > aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 10.138.236.128/27 | > > > | | > | | > b22247e8-fa4a-48bd-8a3f-dde5f22ee866 10.138.236.0/27 | > > > | | > | | > d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 10.138.232.128/27 | > > > | | > | | > d87341b3-f953-4a93-bcaf-46524fbb3408 10.138.236.96/27 | > > > | | > | | > de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee 10.138.200.0/21 | > > > | | > | | > e0a4ce65-9d39-496d-960c-88272cafad55 10.138.236.64/27 | > > > | | > | | > ee1bfd8b-231d-4e1d-83c8-d8d66346acef 10.138.232.32/27 | > > > | | > | | > efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 10.138.136.0/21 | > > > | | > | | > f4b9f50b-18e9-49b2-b0db-6a51cf968e95 10.138.232.64/27 | > > > | | > | | > f986c4b1-1efc-4973-87a8-74db536ac1c0 10.138.232.96/27 | > > > | b250fb4e-5d36-4aa6-bcfb-c623166312ca | net-vx1-private > | 85cace94dcc7484c85ff9337eb1d0c4c | > e0e82224-93e1-4369-b9c1-7d0ac1614837 192.168.213.0/24 | > > > | c767ef08-c1fb-45ed-bf1e-a4c464e12b93 | private-net > | 85cace94dcc7484c85ff9337eb1d0c4c | > fb8ec92c-afa6-48f1-b7f8-25e77462b28b 192.192.100.0/24 | > > > | cd8a928b-42ae-4673-ae19-c687cfd181d4 | NVLP2-Prov-BE > | 85cace94dcc7484c85ff9337eb1d0c4c | > 37b2ba42-6158-4a5f-96f0-48e476b4cd45 10.138.160.0/21 | > > > | | > | | > 8502138b-c2c0-4436-bec5-9221a36e0c8c 10.138.192.0/21 | > > > | | > | | > ceabf390-6489-4b5d-a5b9-305176def3a1 10.138.128.0/21 | > > > | dede00bb-bc23-40a8-a3b9-b273eb7533ff | > NVLP2-Prov-WEB2-test-2-network | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e > 10.138.185.112/28 | > > > | | > | | > b8668626-8c05-4c7d-a70b-a1485f0d666e 10.138.217.112/28 | > > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > > > > > [root@podto2-osctrl01 ~]# neutron subnet-list > > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > > | id | name > | tenant_id | cidr > | allocation_pools | > > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > > | 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 | NVLP2-Provider-Bk-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.177.0/24 > | {"start": "10.138.177.70", "end": "10.138.177.100"} | > > > | 1a88e004-7062-4702-8965-b18ea9d6af87 | NVLP2-Ext-Rupar-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.181.0/24 > | {"start": "10.138.181.20", "end": "10.138.181.150"} | > > > | 272ca9b5-2aa0-45d2-90b4-70abe4feac49 | admin-self-subnet2 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.90.0/24 > | {"start": "192.168.90.10", "end": "192.168.90.254"} | > > > | 37b2ba42-6158-4a5f-96f0-48e476b4cd45 | NVLP2-Prov-BE-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.160.0/21 > | {"start": "10.138.160.20", "end": "10.138.164.255"} | > > > | 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 | HA subnet tenant > 85cace94dcc7484c85ff9337eb1d0c4c | | > 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} > | > > > | 5f369cf5-8b26-4996-97d5-24434f928a84 | > NVLP2-Prov-Rupar02-2-0cf8fe671a-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.32/27 | {"start": > "10.138.236.35", "end": "10.138.236.47"} | > > > | 7b8987f7-da16-48c0-b86c-f3c4fd507f22 | NVLP2-Interpod-subnet-x4 > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.48/28 > | {"start": "10.138.240.61", "end": "10.138.240.61"} | > > > | 8502138b-c2c0-4436-bec5-9221a36e0c8c | > NVLP2-Prov-BE-subnet-78bc7d0889 | > e8c2a22432174638bdee830274845c38 | 10.138.192.0/21 | {"start": > "10.138.192.20", "end": "10.138.196.255"} | > > > | 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e | > NVLP2-Prov-WEB2-test-2-284f32dbb8-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.185.112/28 | {"start": > "10.138.185.114", "end": "10.138.185.119"} | > > > | 9ba2a03d-3f95-494f-bd38-7fe85471465d | > NVLP2-Provider-backoffice1-subnet | > 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.179.0/24 | {"start": > "10.138.179.20", "end": "10.138.179.150"} | > > > | a855f85b-46b7-4463-993b-8d867fb38556 | NVLP2-Interpod-subnet-x1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.0/28 > | {"start": "10.138.240.13", "end": "10.138.240.14"} | > > > | adbe60f2-e02b-4294-8eb8-18ffb0b8bcda | NVLP2-Prov-WEB-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.168.0/21 > | {"start": "10.138.168.20", "end": "10.138.172.255"} | > > > | ae1386b4-c6bc-4c69-909a-1e902df3bc3f | > NVLP2-Prov-Rupar01-2-d0f1fa90f7-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.0/27 | {"start": > "10.138.232.3", "end": "10.138.232.15"} | > > > | aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 | > NVLP2-Prov-Rupar05-2-93db411f87-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.128/27 | {"start": > "10.138.236.131", "end": "10.138.236.143"} | > > > | b22247e8-fa4a-48bd-8a3f-dde5f22ee866 | > NVLP2-Prov-Rupar01-2-6e53be6e00-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.0/27 | {"start": > "10.138.236.3", "end": "10.138.236.15"} | > > > | b8668626-8c05-4c7d-a70b-a1485f0d666e | > NVLP2-Prov-WEB2-test-2-dbe7f3376f-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.217.112/28 | {"start": > "10.138.217.114", "end": "10.138.217.119"} | > > > | ceabf390-6489-4b5d-a5b9-305176def3a1 | > NVLP2-Prov-BE-subnet-42bda158af | > e8c2a22432174638bdee830274845c38 | 10.138.128.0/21 | {"start": > "10.138.128.20", "end": "10.138.132.255"} | > > > | d2129401-0349-4da3-87fa-5e521b071377 | HA subnet tenant > 4e44aad117b64a34806c4785b31c3f88 | | > 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} > | > > > | d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 | > NVLP2-Prov-Rupar05-2-97e7a2473d-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.128/27 | {"start": > "10.138.232.131", "end": "10.138.232.143"} | > > > | d87341b3-f953-4a93-bcaf-46524fbb3408 | > NVLP2-Prov-Rupar04-2-a8223d4e2e-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.96/27 | {"start": > "10.138.236.99", "end": "10.138.236.111"} | > > > | dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b | sub-vx4 > | 4e44aad117b64a34806c4785b31c3f88 | 192.168.213.0/24 > | {"start": "192.168.213.100", "end": "192.168.213.200"} | > > > | de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee | > NVLP2-Prov-WEB-subnet-ae476243c2 | > e8c2a22432174638bdee830274845c38 | 10.138.200.0/21 | {"start": > "10.138.200.20", "end": "10.138.204.255"} | > > > | e0a4ce65-9d39-496d-960c-88272cafad55 | > NVLP2-Prov-Rupar03-2-3c7a3850d1-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.64/27 | {"start": > "10.138.236.67", "end": "10.138.236.79"} | > > > | e0e82224-93e1-4369-b9c1-7d0ac1614837 | sub-vx1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.213.0/24 > | {"start": "192.168.213.100", "end": "192.168.213.200"} | > > > | ea1c69b8-ded6-4028-bba9-63db12213e36 | admin-self-subnet1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.100.0/24 > | {"start": "192.168.100.2", "end": "192.168.100.254"} | > > > | ee1bfd8b-231d-4e1d-83c8-d8d66346acef | > NVLP2-Prov-Rupar02-2-ecfee60675-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.32/27 | {"start": > "10.138.232.35", "end": "10.138.232.47"} | > > > | efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 | > NVLP2-Prov-WEB-subnet-e7e65a3ed6 | > e8c2a22432174638bdee830274845c38 | 10.138.136.0/21 | {"start": > "10.138.136.20", "end": "10.138.140.255"} | > > > | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 | > NVLP2-Prov-Rupar03-2-40976657fe-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.64/27 | {"start": > "10.138.232.67", "end": "10.138.232.79"} | > > > | f986c4b1-1efc-4973-87a8-74db536ac1c0 | > NVLP2-Prov-Rupar04-2-729355c12e-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.96/27 | {"start": > "10.138.232.99", "end": "10.138.232.111"} | > > > | fb8ec92c-afa6-48f1-b7f8-25e77462b28b | provate-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.192.100.0/24 > | {"start": "192.192.100.2", "end": "192.192.100.254"} | > > > | ff797a1f-7de4-4998-9bdc-29d1241ffb5b | NVLP2-Ext-Internet-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 84.240.191.0/24 > | {"start": "84.240.191.2", "end": "84.240.191.170"} | > > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > > [root@podto2-osctrl01 ~]# neutron subnet-show > NVLP2-Prov-Rupar04-2-729355c12e-subnet > > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > > +-------------------+-----------------------------------------------------------------+ > > > | Field | Value > | > > > > +-------------------+-----------------------------------------------------------------+ > > > | allocation_pools | {"start": "10.138.232.99", "end": > "10.138.232.111"} | > > > | cidr | 10.138.232.96/27 > | > > > | created_at | 2019-11-29T08:14:32Z > | > > > | description | > | > > > | dns_nameservers | 10.103.48.1 > | > > > | | 10.103.48.2 > | > > > | enable_dhcp | True > | > > > | gateway_ip | 10.138.232.97 > | > > > | host_routes | {"nexthop": "10.138.232.97", "destination": " > 0.0.0.0/0"} | > > > | | {"nexthop": "10.138.232.97", "destination": " > 10.138.236.96/27"} | > > > | id | f986c4b1-1efc-4973-87a8-74db536ac1c0 > | > > > | ip_version | 4 > | > > > | ipv6_address_mode | > | > > > | ipv6_ra_mode | > | > > > | name | NVLP2-Prov-Rupar04-2-729355c12e-subnet > | > > > | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 > | > > > | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > > | revision_number | 4 > | > > > | service_types | > | > > > | subnetpool_id | > | > > > | tags | > | > > > | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > > | updated_at | 2019-12-10T13:43:02Z > | > > > > > > > > > If I create an instance on this subnet , it gets an address in the > allocation-pool correctly, but the default gateway is not 10.138.232.97, > but 10.138.232.65. > > > > > > This is a gatway of another subnet in the same vlan: > > > [root@podto2-osctrl01 ~]# neutron subnet-show > NVLP2-Prov-Rupar03-2-40976657fe-subnet > > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > > +-------------------+-----------------------------------------------------------------+ > > > | Field | Value > | > > > > +-------------------+-----------------------------------------------------------------+ > > > | allocation_pools | {"start": "10.138.232.67", "end": > "10.138.232.79"} | > > > | cidr | 10.138.232.64/27 > | > > > | created_at | 2019-11-29T08:13:14Z > | > > > | description | > | > > > | dns_nameservers | 10.103.48.1 > | > > > | | 10.103.48.2 > | > > > | enable_dhcp | True > | > > > | gateway_ip | 10.138.232.65 > | > > > | host_routes | {"nexthop": "10.138.232.65", "destination": " > 10.138.236.64/27"} | > > > | id | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 > | > > > | ip_version | 4 > | > > > | ipv6_address_mode | > | > > > | ipv6_ra_mode | > | > > > | name | NVLP2-Prov-Rupar03-2-40976657fe-subnet > | > > > | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 > | > > > | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > > | revision_number | 4 > | > > > | service_types | > | > > > | subnetpool_id | > | > > > | tags | > | > > > | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > > | updated_at | 2019-12-11T08:27:20Z > | > > > > +-------------------+-----------------------------------------------------------------+ > > > > > > The following is the dnsmasq process: > > > > > > [root@podto2-osctrl01 ~]# ps -afe|grep dns|grep b76 > > > nobody 70093 1 0 dic02 ? 00:00:04 dnsmasq --no-hosts > --no-resolv > --pid-file=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/pid > --dhcp-hostsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/host > --addn-hosts=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/addn_hosts > --dhcp-optsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts > --dhcp-leasefile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/leases > --dhcp-match=set:ipxe,175 --local-service --bind-interfaces > --dhcp-range=set:tag1,10.138.168.0,static,255.255.248.0,86400s > --dhcp-range=set:tag2,10.138.232.0,static,255.255.255.224,86400s > --dhcp-range=set:tag4,10.138.232.128,static,255.255.255.224,86400s > --dhcp-range=set:tag8,10.138.232.32,static,255.255.255.224,86400s > --dhcp-range=set:tag10,10.138.232.64,static,255.255.255.224,86400s > --dhcp-range=set:tag11,10.138.232.96,static,255.255.255.224,86400s > --dhcp-option-force=option:mtu,9000 --dhcp-lease-max=2208 --conf-file= > --domain=site02.nivolapiemonte.it > > > Ignazio > > > > > > > > > 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 > > > > > > > — > > Slawek Kaplonski > > Senior software engineer > > Red Hat > > > > — > Slawek Kaplonski > Senior software engineer > Red Hat > >

1 0

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

11 Dec '19

Hi, cat /var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts tag:tag1,option:dns-server,10.103.48.1,10.103.48.2 tag:tag1,option:classless-static-route, 10.138.136.0/21,10.138.168.1,10.138.200.0/21,10.138.168.1,169.254.169.254/32,10.138.168.22,10.138.236.32/27,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.168.1 tag:tag1,249, 10.138.136.0/21,10.138.168.1,10.138.200.0/21,10.138.168.1,169.254.169.254/32,10.138.168.22,10.138.236.32/27,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.168.1 tag:tag1,option:router,10.138.168.1 tag:tag2,option:dns-server,10.103.48.1,10.103.48.2 tag:tag2,option:classless-static-route, 10.138.236.0/27,10.138.232.1,169.254.169.254/32,10.138.232.4,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.1 tag:tag2,249, 10.138.236.0/27,10.138.232.1,169.254.169.254/32,10.138.232.4,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.1 tag:tag2,option:router,10.138.232.1 tag:tag5,option:dns-server,10.103.48.1,10.103.48.2 tag:tag5,option:classless-static-route, 10.138.236.128/27,10.138.232.129,169.254.169.254/32,10.138.232.131,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.129 tag:tag5,249, 10.138.236.128/27,10.138.232.129,169.254.169.254/32,10.138.232.131,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.129 tag:tag5,option:router,10.138.232.129 tag:tag9,option:dns-server,10.103.48.1,10.103.48.2 tag:tag9,option:classless-static-route, 10.138.236.32/27,10.138.232.33,169.254.169.254/32,10.138.232.36,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.33 tag:tag9,249, 10.138.236.32/27,10.138.232.33,169.254.169.254/32,10.138.232.36,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.33 tag:tag9,option:router,10.138.232.33 tag:tag11,option:dns-server,10.103.48.1,10.103.48.2 tag:tag11,option:classless-static-route, 10.138.236.64/27,10.138.232.65,169.254.169.254/32,10.138.232.67,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.65 tag:tag11,249, 10.138.236.64/27,10.138.232.65,169.254.169.254/32,10.138.232.67,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.96/27,0.0.0.0,0.0.0.0/0,10.138.232.65 tag:tag11,option:router,10.138.232.65 tag:tag12,option:dns-server,10.103.48.1,10.103.48.2 tag:tag12,option:classless-static-route, 10.138.236.96/27,10.138.232.97,169.254.169.254/32,10.138.232.101,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,0.0.0.0/0,10.138.232.97 tag:tag12,249, 10.138.236.96/27,10.138.232.97,169.254.169.254/32,10.138.232.101,10.138.236.32/27,0.0.0.0,10.138.168.0/21,0.0.0.0,10.138.232.0/27,0.0.0.0,10.138.236.128/27,0.0.0.0,10.138.236.0/27,0.0.0.0,10.138.232.128/27,0.0.0.0,10.138.236.96/27,0.0.0.0,10.138.200.0/21,0.0.0.0,10.138.236.64/27,0.0.0.0,10.138.232.32/27,0.0.0.0,10.138.136.0/21,0.0.0.0,10.138.232.64/27,0.0.0.0,0.0.0.0/0,10.138.232.97 Thanks Il giorno mer 11 dic 2019 alle ore 10:29 Slawek Kaplonski < skaplons(a)redhat.com> ha scritto: > Hi, > > Can You also send me content of the file > /var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts ? > > > On 11 Dec 2019, at 09:39, Ignazio Cassano <ignaziocassano(a)gmail.com> > wrote: > > > > Thanks for your help: > > [root@podto2-osctrl01 ~]# neutron net-list > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > | id | name > | tenant_id | subnets > | > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > | 00361d96-0ea2-4378-8909-dbf7ef4c883f | NVLP2-Provider-backoffice1 > | 85cace94dcc7484c85ff9337eb1d0c4c | > 9ba2a03d-3f95-494f-bd38-7fe85471465d 10.138.179.0/24 | > > | 28ac0a79-17a9-46f5-a418-77f386b821b5 | NVLP2-Provider-Bk > | 85cace94dcc7484c85ff9337eb1d0c4c | > 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 10.138.177.0/24 | > > | 2e3edf38-7648-4ac8-a8d7-11448adedcca | NVLP2-Ext-Internet > | 85cace94dcc7484c85ff9337eb1d0c4c | > ff797a1f-7de4-4998-9bdc-29d1241ffb5b 84.240.191.0/24 | > > | 34a3e80d-a662-4665-ad6f-a7a83e2be346 | NVLP2-Ext-Rupar > | 85cace94dcc7484c85ff9337eb1d0c4c | > 1a88e004-7062-4702-8965-b18ea9d6af87 10.138.181.0/24 | > > | 435e5609-c91a-4e42-bd1a-87dbc24e4afa | HA network tenant > 85cace94dcc7484c85ff9337eb1d0c4c | | > 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 169.254.192.0/18 | > > | 7f41aa95-b108-4224-9088-21e32d554646 | admin-self-net > | 85cace94dcc7484c85ff9337eb1d0c4c | > 272ca9b5-2aa0-45d2-90b4-70abe4feac49 192.168.90.0/24 | > > | | > | | > ea1c69b8-ded6-4028-bba9-63db12213e36 192.168.100.0/24 | > > | 8b876fb6-10a3-4e92-a499-f62a9d3aa32b | net-vx4-private > | 4e44aad117b64a34806c4785b31c3f88 | > dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b 192.168.213.0/24 | > > | 993f14c9-1b40-47b7-8ee5-fcb00ef92d48 | HA network tenant > 4e44aad117b64a34806c4785b31c3f88 | | > d2129401-0349-4da3-87fa-5e521b071377 169.254.192.0/18 | > > | a91bb860-32d6-4961-a319-bf39a492ff92 | NVL-INTERPOD-VNI-PRIV > | 85cace94dcc7484c85ff9337eb1d0c4c | > 7b8987f7-da16-48c0-b86c-f3c4fd507f22 10.138.240.48/28 | > > | | > | | > a855f85b-46b7-4463-993b-8d867fb38556 10.138.240.0/28 | > > | b11bd55d-c57b-48d1-9be4-ab690624fb76 | NVLP2-Prov-WEB > | 85cace94dcc7484c85ff9337eb1d0c4c | > 5f369cf5-8b26-4996-97d5-24434f928a84 10.138.236.32/27 | > > | | > | | > adbe60f2-e02b-4294-8eb8-18ffb0b8bcda 10.138.168.0/21 | > > | | > | | > ae1386b4-c6bc-4c69-909a-1e902df3bc3f 10.138.232.0/27 | > > | | > | | > aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 10.138.236.128/27 | > > | | > | | > b22247e8-fa4a-48bd-8a3f-dde5f22ee866 10.138.236.0/27 | > > | | > | | > d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 10.138.232.128/27 | > > | | > | | > d87341b3-f953-4a93-bcaf-46524fbb3408 10.138.236.96/27 | > > | | > | | > de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee 10.138.200.0/21 | > > | | > | | > e0a4ce65-9d39-496d-960c-88272cafad55 10.138.236.64/27 | > > | | > | | > ee1bfd8b-231d-4e1d-83c8-d8d66346acef 10.138.232.32/27 | > > | | > | | > efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 10.138.136.0/21 | > > | | > | | > f4b9f50b-18e9-49b2-b0db-6a51cf968e95 10.138.232.64/27 | > > | | > | | > f986c4b1-1efc-4973-87a8-74db536ac1c0 10.138.232.96/27 | > > | b250fb4e-5d36-4aa6-bcfb-c623166312ca | net-vx1-private > | 85cace94dcc7484c85ff9337eb1d0c4c | > e0e82224-93e1-4369-b9c1-7d0ac1614837 192.168.213.0/24 | > > | c767ef08-c1fb-45ed-bf1e-a4c464e12b93 | private-net > | 85cace94dcc7484c85ff9337eb1d0c4c | > fb8ec92c-afa6-48f1-b7f8-25e77462b28b 192.192.100.0/24 | > > | cd8a928b-42ae-4673-ae19-c687cfd181d4 | NVLP2-Prov-BE > | 85cace94dcc7484c85ff9337eb1d0c4c | > 37b2ba42-6158-4a5f-96f0-48e476b4cd45 10.138.160.0/21 | > > | | > | | > 8502138b-c2c0-4436-bec5-9221a36e0c8c 10.138.192.0/21 | > > | | > | | > ceabf390-6489-4b5d-a5b9-305176def3a1 10.138.128.0/21 | > > | dede00bb-bc23-40a8-a3b9-b273eb7533ff | NVLP2-Prov-WEB2-test-2-network > | e28e45dbbb3e4471a8fb6dd6cb99d01d | > 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e 10.138.185.112/28 | > > | | > | | > b8668626-8c05-4c7d-a70b-a1485f0d666e 10.138.217.112/28 | > > > +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ > > > > [root@podto2-osctrl01 ~]# neutron subnet-list > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > | id | name > | tenant_id | cidr | > allocation_pools | > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > | 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 | NVLP2-Provider-Bk-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.177.0/24 > | {"start": "10.138.177.70", "end": "10.138.177.100"} | > > | 1a88e004-7062-4702-8965-b18ea9d6af87 | NVLP2-Ext-Rupar-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.181.0/24 > | {"start": "10.138.181.20", "end": "10.138.181.150"} | > > | 272ca9b5-2aa0-45d2-90b4-70abe4feac49 | admin-self-subnet2 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.90.0/24 > | {"start": "192.168.90.10", "end": "192.168.90.254"} | > > | 37b2ba42-6158-4a5f-96f0-48e476b4cd45 | NVLP2-Prov-BE-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.160.0/21 > | {"start": "10.138.160.20", "end": "10.138.164.255"} | > > | 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 | HA subnet tenant > 85cace94dcc7484c85ff9337eb1d0c4c | | > 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} > | > > | 5f369cf5-8b26-4996-97d5-24434f928a84 | > NVLP2-Prov-Rupar02-2-0cf8fe671a-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.32/27 | {"start": > "10.138.236.35", "end": "10.138.236.47"} | > > | 7b8987f7-da16-48c0-b86c-f3c4fd507f22 | NVLP2-Interpod-subnet-x4 > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.48/28 > | {"start": "10.138.240.61", "end": "10.138.240.61"} | > > | 8502138b-c2c0-4436-bec5-9221a36e0c8c | > NVLP2-Prov-BE-subnet-78bc7d0889 | > e8c2a22432174638bdee830274845c38 | 10.138.192.0/21 | {"start": > "10.138.192.20", "end": "10.138.196.255"} | > > | 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e | > NVLP2-Prov-WEB2-test-2-284f32dbb8-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.185.112/28 | {"start": > "10.138.185.114", "end": "10.138.185.119"} | > > | 9ba2a03d-3f95-494f-bd38-7fe85471465d | > NVLP2-Provider-backoffice1-subnet | > 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.179.0/24 | {"start": > "10.138.179.20", "end": "10.138.179.150"} | > > | a855f85b-46b7-4463-993b-8d867fb38556 | NVLP2-Interpod-subnet-x1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.0/28 > | {"start": "10.138.240.13", "end": "10.138.240.14"} | > > | adbe60f2-e02b-4294-8eb8-18ffb0b8bcda | NVLP2-Prov-WEB-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.168.0/21 > | {"start": "10.138.168.20", "end": "10.138.172.255"} | > > | ae1386b4-c6bc-4c69-909a-1e902df3bc3f | > NVLP2-Prov-Rupar01-2-d0f1fa90f7-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.0/27 | {"start": > "10.138.232.3", "end": "10.138.232.15"} | > > | aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 | > NVLP2-Prov-Rupar05-2-93db411f87-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.128/27 | {"start": > "10.138.236.131", "end": "10.138.236.143"} | > > | b22247e8-fa4a-48bd-8a3f-dde5f22ee866 | > NVLP2-Prov-Rupar01-2-6e53be6e00-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.0/27 | {"start": > "10.138.236.3", "end": "10.138.236.15"} | > > | b8668626-8c05-4c7d-a70b-a1485f0d666e | > NVLP2-Prov-WEB2-test-2-dbe7f3376f-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.217.112/28 | {"start": > "10.138.217.114", "end": "10.138.217.119"} | > > | ceabf390-6489-4b5d-a5b9-305176def3a1 | > NVLP2-Prov-BE-subnet-42bda158af | > e8c2a22432174638bdee830274845c38 | 10.138.128.0/21 | {"start": > "10.138.128.20", "end": "10.138.132.255"} | > > | d2129401-0349-4da3-87fa-5e521b071377 | HA subnet tenant > 4e44aad117b64a34806c4785b31c3f88 | | > 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} > | > > | d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 | > NVLP2-Prov-Rupar05-2-97e7a2473d-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.128/27 | {"start": > "10.138.232.131", "end": "10.138.232.143"} | > > | d87341b3-f953-4a93-bcaf-46524fbb3408 | > NVLP2-Prov-Rupar04-2-a8223d4e2e-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.96/27 | {"start": > "10.138.236.99", "end": "10.138.236.111"} | > > | dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b | sub-vx4 > | 4e44aad117b64a34806c4785b31c3f88 | 192.168.213.0/24 > | {"start": "192.168.213.100", "end": "192.168.213.200"} | > > | de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee | > NVLP2-Prov-WEB-subnet-ae476243c2 | > e8c2a22432174638bdee830274845c38 | 10.138.200.0/21 | {"start": > "10.138.200.20", "end": "10.138.204.255"} | > > | e0a4ce65-9d39-496d-960c-88272cafad55 | > NVLP2-Prov-Rupar03-2-3c7a3850d1-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.64/27 | {"start": > "10.138.236.67", "end": "10.138.236.79"} | > > | e0e82224-93e1-4369-b9c1-7d0ac1614837 | sub-vx1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.213.0/24 > | {"start": "192.168.213.100", "end": "192.168.213.200"} | > > | ea1c69b8-ded6-4028-bba9-63db12213e36 | admin-self-subnet1 > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.100.0/24 > | {"start": "192.168.100.2", "end": "192.168.100.254"} | > > | ee1bfd8b-231d-4e1d-83c8-d8d66346acef | > NVLP2-Prov-Rupar02-2-ecfee60675-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.32/27 | {"start": > "10.138.232.35", "end": "10.138.232.47"} | > > | efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 | > NVLP2-Prov-WEB-subnet-e7e65a3ed6 | > e8c2a22432174638bdee830274845c38 | 10.138.136.0/21 | {"start": > "10.138.136.20", "end": "10.138.140.255"} | > > | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 | > NVLP2-Prov-Rupar03-2-40976657fe-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.64/27 | {"start": > "10.138.232.67", "end": "10.138.232.79"} | > > | f986c4b1-1efc-4973-87a8-74db536ac1c0 | > NVLP2-Prov-Rupar04-2-729355c12e-subnet | > e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.96/27 | {"start": > "10.138.232.99", "end": "10.138.232.111"} | > > | fb8ec92c-afa6-48f1-b7f8-25e77462b28b | provate-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 192.192.100.0/24 > | {"start": "192.192.100.2", "end": "192.192.100.254"} | > > | ff797a1f-7de4-4998-9bdc-29d1241ffb5b | NVLP2-Ext-Internet-subnet > | 85cace94dcc7484c85ff9337eb1d0c4c | 84.240.191.0/24 > | {"start": "84.240.191.2", "end": "84.240.191.170"} | > > > +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ > > [root@podto2-osctrl01 ~]# neutron subnet-show > NVLP2-Prov-Rupar04-2-729355c12e-subnet > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > +-------------------+-----------------------------------------------------------------+ > > | Field | Value > | > > > +-------------------+-----------------------------------------------------------------+ > > | allocation_pools | {"start": "10.138.232.99", "end": > "10.138.232.111"} | > > | cidr | 10.138.232.96/27 > | > > | created_at | 2019-11-29T08:14:32Z > | > > | description | > | > > | dns_nameservers | 10.103.48.1 > | > > | | 10.103.48.2 > | > > | enable_dhcp | True > | > > | gateway_ip | 10.138.232.97 > | > > | host_routes | {"nexthop": "10.138.232.97", "destination": " > 0.0.0.0/0"} | > > | | {"nexthop": "10.138.232.97", "destination": " > 10.138.236.96/27"} | > > | id | f986c4b1-1efc-4973-87a8-74db536ac1c0 > | > > | ip_version | 4 > | > > | ipv6_address_mode | > | > > | ipv6_ra_mode | > | > > | name | NVLP2-Prov-Rupar04-2-729355c12e-subnet > | > > | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 > | > > | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > | revision_number | 4 > | > > | service_types | > | > > | subnetpool_id | > | > > | tags | > | > > | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > | updated_at | 2019-12-10T13:43:02Z > | > > > > > > If I create an instance on this subnet , it gets an address in the > allocation-pool correctly, but the default gateway is not 10.138.232.97, > but 10.138.232.65. > > > > This is a gatway of another subnet in the same vlan: > > [root@podto2-osctrl01 ~]# neutron subnet-show > NVLP2-Prov-Rupar03-2-40976657fe-subnet > > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > > > +-------------------+-----------------------------------------------------------------+ > > | Field | Value > | > > > +-------------------+-----------------------------------------------------------------+ > > | allocation_pools | {"start": "10.138.232.67", "end": > "10.138.232.79"} | > > | cidr | 10.138.232.64/27 > | > > | created_at | 2019-11-29T08:13:14Z > | > > | description | > | > > | dns_nameservers | 10.103.48.1 > | > > | | 10.103.48.2 > | > > | enable_dhcp | True > | > > | gateway_ip | 10.138.232.65 > | > > | host_routes | {"nexthop": "10.138.232.65", "destination": " > 10.138.236.64/27"} | > > | id | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 > | > > | ip_version | 4 > | > > | ipv6_address_mode | > | > > | ipv6_ra_mode | > | > > | name | NVLP2-Prov-Rupar03-2-40976657fe-subnet > | > > | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 > | > > | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > | revision_number | 4 > | > > | service_types | > | > > | subnetpool_id | > | > > | tags | > | > > | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d > | > > | updated_at | 2019-12-11T08:27:20Z > | > > > +-------------------+-----------------------------------------------------------------+ > > > > The following is the dnsmasq process: > > > > [root@podto2-osctrl01 ~]# ps -afe|grep dns|grep b76 > > nobody 70093 1 0 dic02 ? 00:00:04 dnsmasq --no-hosts > --no-resolv > --pid-file=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/pid > --dhcp-hostsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/host > --addn-hosts=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/addn_hosts > --dhcp-optsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts > --dhcp-leasefile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/leases > --dhcp-match=set:ipxe,175 --local-service --bind-interfaces > --dhcp-range=set:tag1,10.138.168.0,static,255.255.248.0,86400s > --dhcp-range=set:tag2,10.138.232.0,static,255.255.255.224,86400s > --dhcp-range=set:tag4,10.138.232.128,static,255.255.255.224,86400s > --dhcp-range=set:tag8,10.138.232.32,static,255.255.255.224,86400s > --dhcp-range=set:tag10,10.138.232.64,static,255.255.255.224,86400s > --dhcp-range=set:tag11,10.138.232.96,static,255.255.255.224,86400s > --dhcp-option-force=option:mtu,9000 --dhcp-lease-max=2208 --conf-file= > --domain=site02.nivolapiemonte.it > > Ignazio > > > > > > 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 > > > > — > Slawek Kaplonski > Senior software engineer > Red Hat > >

1 0

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

11 Dec '19

Thanks for your help: [root@podto2-osctrl01 ~]# neutron net-list neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ | id | name | tenant_id | subnets | +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ | 00361d96-0ea2-4378-8909-dbf7ef4c883f | NVLP2-Provider-backoffice1 | 85cace94dcc7484c85ff9337eb1d0c4c | 9ba2a03d-3f95-494f-bd38-7fe85471465d 10.138.179.0/24 | | 28ac0a79-17a9-46f5-a418-77f386b821b5 | NVLP2-Provider-Bk | 85cace94dcc7484c85ff9337eb1d0c4c | 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 10.138.177.0/24 | | 2e3edf38-7648-4ac8-a8d7-11448adedcca | NVLP2-Ext-Internet | 85cace94dcc7484c85ff9337eb1d0c4c | ff797a1f-7de4-4998-9bdc-29d1241ffb5b 84.240.191.0/24 | | 34a3e80d-a662-4665-ad6f-a7a83e2be346 | NVLP2-Ext-Rupar | 85cace94dcc7484c85ff9337eb1d0c4c | 1a88e004-7062-4702-8965-b18ea9d6af87 10.138.181.0/24 | | 435e5609-c91a-4e42-bd1a-87dbc24e4afa | HA network tenant 85cace94dcc7484c85ff9337eb1d0c4c | | 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 169.254.192.0/18 | | 7f41aa95-b108-4224-9088-21e32d554646 | admin-self-net | 85cace94dcc7484c85ff9337eb1d0c4c | 272ca9b5-2aa0-45d2-90b4-70abe4feac49 192.168.90.0/24 | | | | | ea1c69b8-ded6-4028-bba9-63db12213e36 192.168.100.0/24 | | 8b876fb6-10a3-4e92-a499-f62a9d3aa32b | net-vx4-private | 4e44aad117b64a34806c4785b31c3f88 | dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b 192.168.213.0/24 | | 993f14c9-1b40-47b7-8ee5-fcb00ef92d48 | HA network tenant 4e44aad117b64a34806c4785b31c3f88 | | d2129401-0349-4da3-87fa-5e521b071377 169.254.192.0/18 | | a91bb860-32d6-4961-a319-bf39a492ff92 | NVL-INTERPOD-VNI-PRIV | 85cace94dcc7484c85ff9337eb1d0c4c | 7b8987f7-da16-48c0-b86c-f3c4fd507f22 10.138.240.48/28 | | | | | a855f85b-46b7-4463-993b-8d867fb38556 10.138.240.0/28 | | b11bd55d-c57b-48d1-9be4-ab690624fb76 | NVLP2-Prov-WEB | 85cace94dcc7484c85ff9337eb1d0c4c | 5f369cf5-8b26-4996-97d5-24434f928a84 10.138.236.32/27 | | | | | adbe60f2-e02b-4294-8eb8-18ffb0b8bcda 10.138.168.0/21 | | | | | ae1386b4-c6bc-4c69-909a-1e902df3bc3f 10.138.232.0/27 | | | | | aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 10.138.236.128/27 | | | | | b22247e8-fa4a-48bd-8a3f-dde5f22ee866 10.138.236.0/27 | | | | | d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 10.138.232.128/27 | | | | | d87341b3-f953-4a93-bcaf-46524fbb3408 10.138.236.96/27 | | | | | de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee 10.138.200.0/21 | | | | | e0a4ce65-9d39-496d-960c-88272cafad55 10.138.236.64/27 | | | | | ee1bfd8b-231d-4e1d-83c8-d8d66346acef 10.138.232.32/27 | | | | | efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 10.138.136.0/21 | | | | | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 10.138.232.64/27 | | | | | f986c4b1-1efc-4973-87a8-74db536ac1c0 10.138.232.96/27 | | b250fb4e-5d36-4aa6-bcfb-c623166312ca | net-vx1-private | 85cace94dcc7484c85ff9337eb1d0c4c | e0e82224-93e1-4369-b9c1-7d0ac1614837 192.168.213.0/24 | | c767ef08-c1fb-45ed-bf1e-a4c464e12b93 | private-net | 85cace94dcc7484c85ff9337eb1d0c4c | fb8ec92c-afa6-48f1-b7f8-25e77462b28b 192.192.100.0/24 | | cd8a928b-42ae-4673-ae19-c687cfd181d4 | NVLP2-Prov-BE | 85cace94dcc7484c85ff9337eb1d0c4c | 37b2ba42-6158-4a5f-96f0-48e476b4cd45 10.138.160.0/21 | | | | | 8502138b-c2c0-4436-bec5-9221a36e0c8c 10.138.192.0/21 | | | | | ceabf390-6489-4b5d-a5b9-305176def3a1 10.138.128.0/21 | | dede00bb-bc23-40a8-a3b9-b273eb7533ff | NVLP2-Prov-WEB2-test-2-network | e28e45dbbb3e4471a8fb6dd6cb99d01d | 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e 10.138.185.112/28 | | | | | b8668626-8c05-4c7d-a70b-a1485f0d666e 10.138.217.112/28 | +--------------------------------------+----------------------------------------------------+----------------------------------+--------------------------------------------------------+ [root@podto2-osctrl01 ~]# neutron subnet-list neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ | id | name | tenant_id | cidr | allocation_pools | +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ | 0705b470-ce99-46c8-944c-cfbfc6a2a5f7 | NVLP2-Provider-Bk-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.177.0/24 | {"start": "10.138.177.70", "end": "10.138.177.100"} | | 1a88e004-7062-4702-8965-b18ea9d6af87 | NVLP2-Ext-Rupar-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.181.0/24 | {"start": "10.138.181.20", "end": "10.138.181.150"} | | 272ca9b5-2aa0-45d2-90b4-70abe4feac49 | admin-self-subnet2 | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.90.0/24 | {"start": "192.168.90.10", "end": "192.168.90.254"} | | 37b2ba42-6158-4a5f-96f0-48e476b4cd45 | NVLP2-Prov-BE-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.160.0/21 | {"start": "10.138.160.20", "end": "10.138.164.255"} | | 5bbb31c3-a2cd-4e30-a194-60cee122d0e9 | HA subnet tenant 85cace94dcc7484c85ff9337eb1d0c4c | | 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} | | 5f369cf5-8b26-4996-97d5-24434f928a84 | NVLP2-Prov-Rupar02-2-0cf8fe671a-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.32/27 | {"start": "10.138.236.35", "end": "10.138.236.47"} | | 7b8987f7-da16-48c0-b86c-f3c4fd507f22 | NVLP2-Interpod-subnet-x4 | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.48/28 | {"start": "10.138.240.61", "end": "10.138.240.61"} | | 8502138b-c2c0-4436-bec5-9221a36e0c8c | NVLP2-Prov-BE-subnet-78bc7d0889 | e8c2a22432174638bdee830274845c38 | 10.138.192.0/21 | {"start": "10.138.192.20", "end": "10.138.196.255"} | | 92da59f1-df82-470b-a2ea-9b9b6f6c8e5e | NVLP2-Prov-WEB2-test-2-284f32dbb8-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.185.112/28 | {"start": "10.138.185.114", "end": "10.138.185.119"} | | 9ba2a03d-3f95-494f-bd38-7fe85471465d | NVLP2-Provider-backoffice1-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.179.0/24 | {"start": "10.138.179.20", "end": "10.138.179.150"} | | a855f85b-46b7-4463-993b-8d867fb38556 | NVLP2-Interpod-subnet-x1 | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.240.0/28 | {"start": "10.138.240.13", "end": "10.138.240.14"} | | adbe60f2-e02b-4294-8eb8-18ffb0b8bcda | NVLP2-Prov-WEB-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 10.138.168.0/21 | {"start": "10.138.168.20", "end": "10.138.172.255"} | | ae1386b4-c6bc-4c69-909a-1e902df3bc3f | NVLP2-Prov-Rupar01-2-d0f1fa90f7-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.0/27 | {"start": "10.138.232.3", "end": "10.138.232.15"} | | aefeeb08-7fb8-43c7-adc8-e8b0538b57d9 | NVLP2-Prov-Rupar05-2-93db411f87-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.128/27 | {"start": "10.138.236.131", "end": "10.138.236.143"} | | b22247e8-fa4a-48bd-8a3f-dde5f22ee866 | NVLP2-Prov-Rupar01-2-6e53be6e00-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.0/27 | {"start": "10.138.236.3", "end": "10.138.236.15"} | | b8668626-8c05-4c7d-a70b-a1485f0d666e | NVLP2-Prov-WEB2-test-2-dbe7f3376f-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.217.112/28 | {"start": "10.138.217.114", "end": "10.138.217.119"} | | ceabf390-6489-4b5d-a5b9-305176def3a1 | NVLP2-Prov-BE-subnet-42bda158af | e8c2a22432174638bdee830274845c38 | 10.138.128.0/21 | {"start": "10.138.128.20", "end": "10.138.132.255"} | | d2129401-0349-4da3-87fa-5e521b071377 | HA subnet tenant 4e44aad117b64a34806c4785b31c3f88 | | 169.254.192.0/18 | {"start": "169.254.192.1", "end": "169.254.255.254"} | | d3e834ef-5f7c-43b7-b52d-fd8e223e6c50 | NVLP2-Prov-Rupar05-2-97e7a2473d-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.128/27 | {"start": "10.138.232.131", "end": "10.138.232.143"} | | d87341b3-f953-4a93-bcaf-46524fbb3408 | NVLP2-Prov-Rupar04-2-a8223d4e2e-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.96/27 | {"start": "10.138.236.99", "end": "10.138.236.111"} | | dcd2ad5c-afb5-420b-bfa8-7b89ab511f5b | sub-vx4 | 4e44aad117b64a34806c4785b31c3f88 | 192.168.213.0/24 | {"start": "192.168.213.100", "end": "192.168.213.200"} | | de2c0bc9-85d4-4e5b-b1ae-d39ae6bbc6ee | NVLP2-Prov-WEB-subnet-ae476243c2 | e8c2a22432174638bdee830274845c38 | 10.138.200.0/21 | {"start": "10.138.200.20", "end": "10.138.204.255"} | | e0a4ce65-9d39-496d-960c-88272cafad55 | NVLP2-Prov-Rupar03-2-3c7a3850d1-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.236.64/27 | {"start": "10.138.236.67", "end": "10.138.236.79"} | | e0e82224-93e1-4369-b9c1-7d0ac1614837 | sub-vx1 | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.213.0/24 | {"start": "192.168.213.100", "end": "192.168.213.200"} | | ea1c69b8-ded6-4028-bba9-63db12213e36 | admin-self-subnet1 | 85cace94dcc7484c85ff9337eb1d0c4c | 192.168.100.0/24 | {"start": "192.168.100.2", "end": "192.168.100.254"} | | ee1bfd8b-231d-4e1d-83c8-d8d66346acef | NVLP2-Prov-Rupar02-2-ecfee60675-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.32/27 | {"start": "10.138.232.35", "end": "10.138.232.47"} | | efd1f72c-8bd3-4b25-a3fc-e2698dd734d7 | NVLP2-Prov-WEB-subnet-e7e65a3ed6 | e8c2a22432174638bdee830274845c38 | 10.138.136.0/21 | {"start": "10.138.136.20", "end": "10.138.140.255"} | | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 | NVLP2-Prov-Rupar03-2-40976657fe-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.64/27 | {"start": "10.138.232.67", "end": "10.138.232.79"} | | f986c4b1-1efc-4973-87a8-74db536ac1c0 | NVLP2-Prov-Rupar04-2-729355c12e-subnet | e28e45dbbb3e4471a8fb6dd6cb99d01d | 10.138.232.96/27 | {"start": "10.138.232.99", "end": "10.138.232.111"} | | fb8ec92c-afa6-48f1-b7f8-25e77462b28b | provate-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 192.192.100.0/24 | {"start": "192.192.100.2", "end": "192.192.100.254"} | | ff797a1f-7de4-4998-9bdc-29d1241ffb5b | NVLP2-Ext-Internet-subnet | 85cace94dcc7484c85ff9337eb1d0c4c | 84.240.191.0/24 | {"start": "84.240.191.2", "end": "84.240.191.170"} | +--------------------------------------+---------------------------------------------------+----------------------------------+-------------------+--------------------------------------------------------+ [root@podto2-osctrl01 ~]# neutron subnet-show NVLP2-Prov-Rupar04-2-729355c12e-subnet neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +-------------------+-----------------------------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------------------------+ | allocation_pools | {"start": "10.138.232.99", "end": "10.138.232.111"} | | cidr | 10.138.232.96/27 | | created_at | 2019-11-29T08:14:32Z | | description | | | dns_nameservers | 10.103.48.1 | | | 10.103.48.2 | | enable_dhcp | True | | gateway_ip | 10.138.232.97 | | host_routes | {"nexthop": "10.138.232.97", "destination": "0.0.0.0/0"} | | | {"nexthop": "10.138.232.97", "destination": " 10.138.236.96/27"} | | id | f986c4b1-1efc-4973-87a8-74db536ac1c0 | | ip_version | 4 | | ipv6_address_mode | | | ipv6_ra_mode | | | name | NVLP2-Prov-Rupar04-2-729355c12e-subnet | | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 | | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d | | revision_number | 4 | | service_types | | | subnetpool_id | | | tags | | | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d | | updated_at | 2019-12-10T13:43:02Z | If I create an instance on this subnet , it gets an address in the allocation-pool correctly, but the default gateway is not 10.138.232.97, but 10.138.232.65. This is a gatway of another subnet in the same vlan: [root@podto2-osctrl01 ~]# neutron subnet-show NVLP2-Prov-Rupar03-2-40976657fe-subnet neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +-------------------+-----------------------------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------------------------+ | allocation_pools | {"start": "10.138.232.67", "end": "10.138.232.79"} | | cidr | 10.138.232.64/27 | | created_at | 2019-11-29T08:13:14Z | | description | | | dns_nameservers | 10.103.48.1 | | | 10.103.48.2 | | enable_dhcp | True | | gateway_ip | 10.138.232.65 | | host_routes | {"nexthop": "10.138.232.65", "destination": " 10.138.236.64/27"} | | id | f4b9f50b-18e9-49b2-b0db-6a51cf968e95 | | ip_version | 4 | | ipv6_address_mode | | | ipv6_ra_mode | | | name | NVLP2-Prov-Rupar03-2-40976657fe-subnet | | network_id | b11bd55d-c57b-48d1-9be4-ab690624fb76 | | project_id | e28e45dbbb3e4471a8fb6dd6cb99d01d | | revision_number | 4 | | service_types | | | subnetpool_id | | | tags | | | tenant_id | e28e45dbbb3e4471a8fb6dd6cb99d01d | | updated_at | 2019-12-11T08:27:20Z | +-------------------+-----------------------------------------------------------------+ The following is the dnsmasq process: [root@podto2-osctrl01 ~]# ps -afe|grep dns|grep b76 nobody 70093 1 0 dic02 ? 00:00:04 dnsmasq --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/host --addn-hosts=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/opts --dhcp-leasefile=/var/lib/neutron/dhcp/b11bd55d-c57b-48d1-9be4-ab690624fb76/leases --dhcp-match=set:ipxe,175 --local-service --bind-interfaces --dhcp-range=set:tag1,10.138.168.0,static,255.255.248.0,86400s --dhcp-range=set:tag2,10.138.232.0,static,255.255.255.224,86400s --dhcp-range=set:tag4,10.138.232.128,static,255.255.255.224,86400s --dhcp-range=set:tag8,10.138.232.32,static,255.255.255.224,86400s --dhcp-range=set:tag10,10.138.232.64,static,255.255.255.224,86400s --dhcp-range=set:tag11,10.138.232.96,static,255.255.255.224,86400s --dhcp-option-force=option:mtu,9000 --dhcp-lease-max=2208 --conf-file= --domain=site02.nivolapiemonte.it Ignazio 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 > >

1 0

Work around for bug 1851516: grub2-mkconfig with ARM ?
by Darrin Vallis 10 Dec '19

10 Dec '19

Hello We are using diskimage-builder to generate an ARM UEFI ISO for the Akraino REC blueprint. We have exactly the same problem documented here: https://bugs.launchpad.net/diskimage-builder/+bug/1851516 When our script uses grub2-mkconfig, grub.cfg is not relocated as shown grub2-mkconfig -0 /boot/efi/EFI/centos/grub.cfg The image is built with /boot/grub2/grub.cfg instead. Any thoughts on a work around for this? Thanks Darrin Vallis Ampere FAE | Austin TX 512-791-5908 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

2 1

neutron-metadata-agent broken pipe
by Albert Braden 10 Dec '19

10 Dec '19

Is anyone else seeing this? We are running Rocky. As our production cluster grows in size we are starting to have trouble with neutron-metadata-agent. After restarting it is happy for a minute and then it complains "2019-12-06 17:54:24.615 664587 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 11, greater than warning threshold: 10. There could be a leak. Increasing threshold to: 20" It increases the threshold a couple of times and then after increasing to 40 we start to see errors: 2019-12-06 17:55:10.119 664578 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe It looks like increasing the threshold to 40 fails because it keeps trying: 2019-12-06 17:55:17.452 664597 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 21, greater than warning threshold: 20. There could be a leak. Increasing threshold to: 40 And the errors increase until the log is nothing but errors, and VMs fail to boot. root@us01odc-p02-ctrl1:~# tail -f /var/log/neutron/neutron-metadata-agent.log self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.664 664597 INFO eventlet.wsgi.server [-] 10.195.73.174,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 62.1517761 2019-12-06 17:59:23.756 664583 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.757 664583 INFO eventlet.wsgi.server [-] 10.195.65.69,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 63.0419171 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent [-] Unexpected error.: MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent Traceback (most recent call last): 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 89, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent instance_id, tenant_id = self._get_instance_and_tenant_id(req) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 162, in _get_instance_and_tenant_id 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ports = self._get_ports(remote_address, network_id, router_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 155, in _get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._get_ports_for_remote_address(remote_address, networks) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/cache_utils.py", line 116, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.func(target_self, *args, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 137, in _get_ports_for_remote_address 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ip_address=remote_address) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 106, in _get_ports_from_server 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.plugin_rpc.get_ports(self.context, filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 72, in get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return cctxt.call(context, 'get_ports', filters=filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 173, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent time.sleep(wait) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent self.force_reraise() 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent six.reraise(self.type_, self.value, self.tb) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 150, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._original_context.call(ctxt, method, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 179, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=self.retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 133, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 584, in send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout, retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 573, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 459, in wait 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent message = self.waiters.get(msg_id, timeout=timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in get 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 'to message ID %s' % msg_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 2019-12-06 17:59:23.778 664595 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) What's causing this? Are we overloading RMQ?

1 4

Work around for bug 1851516: grub2-mkconfig with ARM ? (Resubmit)
by Darrin Vallis 10 Dec '19

10 Dec '19

Hello We are using diskimage-builder to generate an ARM UEFI ISO for the Akraino REC blueprint. We have exactly the same problem documented here: https://bugs.launchpad.net/diskimage-builder/+bug/1851516 When our script uses grub2-mkconfig, grub.cfg is not relocated as shown grub2-mkconfig -0 /boot/efi/EFI/centos/grub.cfg The image is built with /boot/grub2/grub.cfg instead. Any thoughts on a work around for this? Thanks Darrin Vallis Ampere FAE | Austin TX 512-791-5908 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

1 0

[octavia][stein issue
by Ignazio Cassano 10 Dec '19

10 Dec '19

Hello, I've just installed stein on centos 7 with octavia. I created the amphora image based on centos , but when a load balance is created the amphora instance does note have any proces on port 9443 and the worker reports: 2019-12-10 08:40:14.456 3710 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.: ConnectTimeout: HTTPSConnectionPool(host='10.102.143.94', port=9443): Max retries exceeded with url: // (Caused by ConnectTimeoutError(<urllib3.connection.VerifiedHTTPSConnection object at 0x7f4a04de0d10>, 'Connection to 10.102.143.94 timed out. (connect timeout=10.0)')) Network connectivity and security groups are ok. I connected on the instance via ssh and I cannot see any listening 9443 port. Anyone can help me, please ? Ignazio

2 2

[sahara] Sahara meetings for the rest of 2019 - dates confirmed
by Jeremy Freudberg 10 Dec '19

10 Dec '19

The next Sahara meeting will be December 19, 2019 at 1400 UTC in #openstack-sahara. (There will be no Sahara meeting December 12, 2019 or December 26, 2019.)

1 0

[neutron][queens] dhcp issue
by Ignazio Cassano 10 Dec '19

10 Dec '19

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

1 0

[cinder] weekly meeting change reminder
by Brian Rosmaita 10 Dec '19

10 Dec '19

(No, I'm not planning to send this out every week ... this will be the final reminder email.) This is a quick reminder that this week's Cinder meeting will be held as usual on Wednesday, but: new time: 1400 UTC new channel: #openstack-meeting-4 See you there! brian

1 0

[Image-Encryption] No meeting until January
by Josephine Seifert 10 Dec '19

10 Dec '19

Hello, I will have vacation until January, so the next meeting will take place at 6th of Januar. I wish you all nice holidays and a happy new year :)

1 0

[all] OpenStack V Release Naming Poll
by Sean McGinnis 10 Dec '19

10 Dec '19

Hey everyone, This is to officially announce the beginning of the CIVS poll to determine the "V" release name. Since the Train release, we use a public poll. This means that rather than having a unique voting URL for each person, all voting can be done using the following URL: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_13ccd49b66cfd1b4&akey=39d9… A public poll can mean that users behind NAT, proxy servers or firewalls may receive an error message saying that your vote has already been lodged. If this happens please try another IP. Voting will officially end December 16, 2019 at 23:59 UTC. The results of the voting will be shared soon afterwards, but keep in mind there will need to be a marketing and legal review of any selected names before it is finalized. Import Note On Name Review -------------------------- There are a couple steps that I am consolidating from our official process [0]. I believe this to be harmless, but if anyone has any concerns about this please do raise them and we can discuss and avoid any issues for future elections. I will be proposing some updates to clarify our election process either way. First, there is a discrete step for marketing review. I believe that can be done as part of the post-voting name review. Second is to consult with the TC to have names removed. I also believe that can be done as part of the post-voting review, but also think that due to past concerns about this process it is best to allow voting on all of the names first, then determine if something is not appropriate. I think this should be more efficient, but ultimately I determined this course of action due to not allowing enough time for step 6 of the process. For that I want to apologize to everyone sincerely. I do think (and hope) this will not be an issue, but again, please do not hesitate to raise concerns about this. Sean [0] https://governance.openstack.org/tc/reference/release-naming.html

4 7

[stein][octavia] api error
by Ignazio Cassano 09 Dec '19

09 Dec '19

Hello All, I've just installed octavia on centos 7 stein, but when I call the octavia command line, the octavia api.log reports: 2019-12-09 22:03:40.986 7925 WARNING keystonemiddleware.auth_token [req-1dea61b8-5c61-4b97-9be5-b1fd8c273984 - - - - -] Identity response: {"error":{"code":401,"message":"The request you have made requires authentication.","title":"Unauthorized"}} : Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-4264ea33-ad5c-46a7-99af-def5570e7e47) 2019-12-09 22:03:41.008 7925 WARNING keystonemiddleware.auth_token [req-1dea61b8-5c61-4b97-9be5-b1fd8c273984 - - - - -] Identity response: {"error":{"code":401,"message":"The request you have made requires authentication.","title":"Unauthorized"}} : Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-02b07d72-431b-421c-9735-3289228e7df1) 2019-12-09 22:03:41.008 7925 CRITICAL keystonemiddleware.auth_token [req-1dea61b8-5c61-4b97-9be5-b1fd8c273984 - - - - -] Unable to validate token: Identity server rejected authorization necessary to fetch token data: ServiceError: Identity server rejected authorization necessary to fetch token data Please, any help ? Regards Ignazio

1 1

Openstack CI Failing from Friday(6-Dec-2019)
by Sikka, Rishabh 09 Dec '19

09 Dec '19

Dear All , >From Saturday onwards our openstack CI is failing for ISCSI driver at very early stage of devstack setup and for FC driver it is getting queued. Please let us know if there is any changes are done from community end. >From the failure log and last success log we can conclude with below error -: Failure log -: http://54.201.44.218/53/696853/1/check/3par-iscsi-driver-master-client-pip-… + ./stack.sh:main:224 : [[ ! xenial =~ (bionic|stretch|jessie|f29|opensuse-15.0|opensuse-15.1|opensuse-tumbleweed|rhel7) ]] + ./stack.sh:main:225 : echo 'WARNING: this script has not been tested on xenial' WARNING: this script has not been tested on xenial + ./stack.sh:main:226 : [[ '' != \y\e\s ]] + ./stack.sh:main:227 : die 227 'If you wish to run this script anyway run with FORCE=yes' + functions-common:die:195 : local exitcode=0 + functions-common:die:196 : set +o xtrace [Call Trace] ./stack.sh:227:die [ERROR] ./stack.sh:227 If you wish to run this script anyway run with FORCE=yesnon-zero return code ################################## Success log-: http://54.201.44.218/14/685914/9/check/3par-iscsi-driver-master-client-pip-… + ./stack.sh:main:224 : [[ ! xenial =~ (xenial|artful|bionic|stretch|jessie|f29|opensuse-15.0|opensuse-15.1|opensuse-tumbleweed|rhel7) ]] + ./stack.sh:main:235 : export_proxy_variables + functions-common:export_proxy_variables:2154 : isset http_proxy + functions-common:isset:171 : [[ -v http_proxy ]] + functions-common:export_proxy_variables:2155 : export http_proxy=http://192.168.75.1:8118/ + functions-common:export_proxy_variables:2155 : http_proxy=http://192.168.75.1:8118/ + functions-common:export_proxy_variables:2157 : isset https_proxy + functions-common:isset:171 : [[ -v https_proxy ]]

2 1

Re: [sahara] Next Sahara meeting date
by Jeremy Freudberg 09 Dec '19

09 Dec '19

Oops, I meant to write in my original message that 19 Dec is also an option. I think I would also prefer 19 Dec for the date of the next meeting. Let's allow some time for thoughts from the rest of the team but likely I will announce an exceptional meeting for 19 Dec 1400UTC. Not sure if #openstack-meeting-3 is actually available or if we are even allowed to use it for an exceptional meeting. But we can figure that out later... On Mon, Dec 9, 2019 at 1:22 PM Luigi Toscano <ltoscano(a)redhat.com> wrote: > > On Monday, 9 December 2019 17:20:26 CET Jeremy Freudberg wrote: > > As a reminder, the Sahara team currently meets every two weeks. A > > meeting was not held 28 Nov due to the Thanksgiving holiday. A meeting > > will not be held 12 Dec as I am on PTO. > > > > In order to determine the next meeting date we need to answer two questions: > > - Is there desire to meet on 26 Dec, despite the nearby holidays? > > - Is a gap in meetings from 14 Nov to 9 Jan acceptable? > > > > Depending on those answers, the next Sahara meeting will either be on > > 26 Dec or 9 Jan. > > Uhm, could we exceptionally met on Dec 19 ? That would probably solve the > issue. > > I can't totally guarantee to be around on Dec 26, even though it shouldn't be > a big problem, so that's my emergency scenario. > > Ciao > -- > Luigi > >

1 0

[sahara] Next Sahara meeting date
by Jeremy Freudberg 09 Dec '19

09 Dec '19

As a reminder, the Sahara team currently meets every two weeks. A meeting was not held 28 Nov due to the Thanksgiving holiday. A meeting will not be held 12 Dec as I am on PTO. In order to determine the next meeting date we need to answer two questions: - Is there desire to meet on 26 Dec, despite the nearby holidays? - Is a gap in meetings from 14 Nov to 9 Jan acceptable? Depending on those answers, the next Sahara meeting will either be on 26 Dec or 9 Jan. Let me know. Thanks, Jeremy

1 0

【ironic】 booting from volume
by 海风吹 09 Dec '19

09 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

1 0

High CPU utilization by systemd process || debian 8
by Md. Farhad Hasan Khan 09 Dec '19

09 Dec '19

Hi, We are observing high CPU utilization by systemd process. 100% CPU utilize by systemd process when no user is being logged in to the server but CPU utilization became 0% while any user logged in to the server. What cloud be possible reason behind this issue and solution? Log collected via login to the server via ssh or console: (0% CPU utilization) top -b -n 1 | grep systemd | grep 612 612 root 20 0 3386692 2.051g 4932 T 0.0 6.5 22029:26 systemd Log collected without login to the server : (100% CPU utilization) # ssh user(a)192.168.18.11 <mailto:user@192.168.18.11> top -b -n 1 | grep systemd | grep 612 user(a)192.168.18.11's <mailto:user@192.168.18.11's> password: 612 root 20 0 3386692 2.051g 4932 S 789.2 6.5 22031:31 systemd Please find the server information: lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release: 8.11 Codename: jessie uname -r 3.16.0-6-amd64 Thanks & B’Rgds, Rony

2 1

[magnum] [stein] kubernetes stack does not terminate
by Ignazio Cassano 08 Dec '19

08 Dec '19

hello, I've just installed stein with magnum on centos 7. I am creating a kubernetes cluster but it is running since 22 minutes and I think it will not work because the heat stack is waiting OSSoftwareDeployment completes I presume something is not working on heat with magnum. I ran several stack with Software Deployment without magnum, and they worked fine Thanks Ignazio

2 16

RE: High CPU utilization by systemd process || debian 8
by Md. Farhad Hasan Khan 07 Dec '19

07 Dec '19

Hi, Please help to solve this. Thanks/Rony From: Md. Farhad Hasan Khan [mailto:rony.khan@brilliant.com.bd] Sent: Saturday, December 7, 2019 11:55 AM To: 'OpenStack Discuss' Subject: High CPU utilization by systemd process || debian 8 Hi, We are observing high CPU utilization by systemd process. 100% CPU utilize by systemd process when no user is being logged in to the server but CPU utilization became 0% while any user logged in to the server. What cloud be possible reason behind this issue and solution? Log collected via login to the server via ssh or console: (0% CPU utilization) top -b -n 1 | grep systemd | grep 612 612 root 20 0 3386692 2.051g 4932 T 0.0 6.5 22029:26 systemd Log collected without login to the server : (100% CPU utilization) # ssh user(a)192.168.18.11 <mailto:user@192.168.18.11> top -b -n 1 | grep systemd | grep 612 user(a)192.168.18.11's <mailto:user@192.168.18.11's> password: 612 root 20 0 3386692 2.051g 4932 S 789.2 6.5 22031:31 systemd Please find the server information: lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release: 8.11 Codename: jessie uname -r 3.16.0-6-amd64 Thanks & B’Rgds, Rony

1 0

neutron-metadata-agent broken pipe
by Albert Braden 07 Dec '19

07 Dec '19

As our production cluster grows in size we are starting to have trouble with neutron-metadata-agent. After restarting it is happy for a minute and then it complains "2019-12-06 17:54:24.615 664587 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 11, greater than warning threshold: 10. There could be a leak. Increasing threshold to: 20" It increases the threshold a couple of times and then after increasing to 40 we start to see errors: 2019-12-06 17:55:10.119 664578 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe It looks like increasing the threshold to 40 fails because it keeps trying: 2019-12-06 17:55:17.452 664597 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 21, greater than warning threshold: 20. There could be a leak. Increasing threshold to: 40 And the errors increase until the log is nothing but errors, and VMs fail to boot. root@us01odc-p02-ctrl1:~# tail -f /var/log/neutron/neutron-metadata-agent.log self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.664 664597 INFO eventlet.wsgi.server [-] 10.195.73.174,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 62.1517761 2019-12-06 17:59:23.756 664583 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.757 664583 INFO eventlet.wsgi.server [-] 10.195.65.69,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 63.0419171 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent [-] Unexpected error.: MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent Traceback (most recent call last): 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 89, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent instance_id, tenant_id = self._get_instance_and_tenant_id(req) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 162, in _get_instance_and_tenant_id 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ports = self._get_ports(remote_address, network_id, router_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 155, in _get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._get_ports_for_remote_address(remote_address, networks) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/cache_utils.py", line 116, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.func(target_self, *args, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 137, in _get_ports_for_remote_address 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ip_address=remote_address) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 106, in _get_ports_from_server 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.plugin_rpc.get_ports(self.context, filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 72, in get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return cctxt.call(context, 'get_ports', filters=filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 173, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent time.sleep(wait) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent self.force_reraise() 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent six.reraise(self.type_, self.value, self.tb) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 150, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._original_context.call(ctxt, method, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 179, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=self.retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 133, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 584, in send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout, retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 573, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 459, in wait 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent message = self.waiters.get(msg_id, timeout=timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in get 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 'to message ID %s' % msg_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 2019-12-06 17:59:23.778 664595 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) What's causing this? Are we overloading RMQ?

1 0

[nova][ironic] Changing an owner of a provisioned node
by Matt Riedemann 07 Dec '19

07 Dec '19

The 1.50 microversion [1] in the ironic API added the "owner" field to the node and I'm trying to use that to add some scheduler filtering in nova [2]. It's my understanding that the owner field on a provisioned node (instance_uuid on the node is set) can be changed, but I'm surprised that is allowed. Was that an oversight in developing that feature? The use case for the scheduler filter is baremetal nodes are owned by different (non-admin) projects in a deployment. When a non-admin project creates a baremetal server via nova, nova will filter out nodes that are not owned by the project (based on the node.owner field). If a node isn't owned by any project, only admins can use it. Admins also have access to all nodes regardless of owner. Given that, let's say user 1 from project A creates a server on nova X that is owned by project A (node.owner=A). Then the node.owner is changed to project B. What should happen? Should nova detect that ownership change and stop the node or something? Note that with other resources that can transfer ownership, like volumes, that can only be done when they aren't in use. So why don't we have the same rules for nodes? Assuming we do want to enforce this in the API (a 409 response when trying to change the owner on a provisioned node), how would that be done given this is a problem since 1.50 which was added in Stein? Would a policy rule be added to ironic to determine if someone can change the owner on a provisioned node and if so, what would be the default rule? The same as "baremetal:node:update" (rule:is_admin)? [1] https://docs.openstack.org/ironic/latest/contributor/webapi-version-history… [2] https://blueprints.launchpad.net/nova/+spec/ironic-tenant-filter -- Thanks, Matt

3 3

RE: Rebooted VM disappears when HV lacks memory
by Albert Braden 06 Dec '19

06 Dec '19

Hi Sean, I didn't want to mess with prod configs but shelve/unshelve works. Thanks for your advice! -----Original Message----- From: Sean Mooney <smooney(a)redhat.com> Sent: Friday, December 6, 2019 3:53 AM To: Albert Braden <albertb(a)synopsys.com>; openstack-discuss(a)lists.openstack.org Subject: Re: Rebooted VM disappears when HV lacks memory On Fri, 2019-12-06 at 02:22 +0000, Albert Braden wrote: > Update: It looks like attempting to migrate any VM, alive or dead, from an oversubscribed hypervisor throws the same > error. Maybe I should have done the migrations before setting cpu_allocation_ratio and ram_allocation_ratio. > > Is there a way to recover from this besides deleting VMs from the oversubscribed hypervisors? you could tempoerally set the allocation ratio higher to allow the vm to boot then try migrating it again. you could also maybe try shelving the vm, waiting for ti to be shelve offloaded then unshelve it. > > -----Original Message----- > From: Albert Braden > Sent: Thursday, December 5, 2019 6:08 PM > To: openstack-discuss(a)lists.openstack.org > Subject: RE: Rebooted VM disappears when HV lacks memory > > We changed cpu_allocation_ratio and ram_allocation_ratio to 1 on the hypervisors. Now I'm trying to clean up the mess. > > I'm trying to cold-migrate dead VMs from an oversubscribed hypervisor, but they are failing to migrate: > > root@us01odc-p02-ctrl1:~# os hypervisor list --long|grep hv199 > > 218 | us01-p02-hv199.internal.synopsys.com | QEMU | 10.195.54.226 | up | 138 | 80 > > | 1122304 | 772691 | > > root@us01odc-p02-ctrl1:~# openstack server migrate fc250e76-4ca5-44b1-a6a0-8a7c7ad48c24 > No valid host was found. No valid host found for cold migrate (HTTP 400) (Request-ID: req-cc048221-abaf-4be0-bc90- > f28eecec3df5) > > But we have lots of hosts with space, and if I build a new VM with the same flavor it works. When I check the logs, it > appears that the migration fails because the hypervisor we are moving from is oversubscribed: > > /var/log/nova/nova-conductor.log:2019-12-05 17:30:17.163 48989 WARNING nova.scheduler.client.report [req-cc048221- > abaf-4be0-bc90-f28eecec3df5 5b288691527245bda715ab7744a193e9 deea2d8541f741eda6fb0d242d16bb23 - default > 824941b2ad6a43d7984fab9390290f18] Unable to post allocations for instance 87608240-1ad2-45fc-b4f0-c118e3bf0262 (409 > {"errors": [{"status": 409, "request_id": "req-e56d29f8-c97e-41ac-8481-0598f3c681b2", "detail": "There was a conflict > when trying to complete your request.\n\n Unable to allocate inventory: Unable to create allocation for 'MEMORY_MB' on > resource provider 'fde477cd-fd3d-4296-838c-f9c54b3e97ef'. The requested amount would exceed the capacity. ", "title": > "Conflict"}]}) > > 'fde477cd-fd3d-4296-838c-f9c54b3e97ef' is the UUID of hv199: > > root@us01odc-p02-ctrl1:~# curl -s -X GET -H "X-Auth-Token: $token" -H "Content-Type: application/json" " > http://us01odc-p02-lb.internal.synopsys.com:28778/resource_providers/fde477…";echo > {"generation": 40, "uuid": "fde477cd-fd3d-4296-838c-f9c54b3e97ef", "links": [{"href": "/resource_providers/fde477cd- > fd3d-4296-838c-f9c54b3e97ef", "rel": "self"}, {"href": "/resource_providers/fde477cd-fd3d-4296-838c- > f9c54b3e97ef/inventories", "rel": "inventories"}, {"href": "/resource_providers/fde477cd-fd3d-4296-838c- > f9c54b3e97ef/usages", "rel": "usages"}], "name": "us01-p02-hv199.internal.synopsys.com"} > > What am I doing wrong? Do I need to move the live VMs away from hv199 to make room for the dead ones? > > > > -----Original Message----- > From: Sean Mooney <smooney(a)redhat.com> > Sent: Wednesday, December 4, 2019 4:30 AM > To: Albert Braden <albertb(a)synopsys.com>; openstack-discuss(a)lists.openstack.org > Subject: Re: Rebooted VM disappears when HV lacks memory > > On Wed, 2019-12-04 at 00:51 +0000, Albert Braden wrote: > > We are running Rocky and we have the allocation bug because we set cpu_allocation_ratio and ram_allocation_ratio to > > 1 > > on the controllers but not on the hypervisors, so the hypervisors are oversubscribed. When we try to reboot a VM > > when > > the HV is short memory, the VM is deleted from the HV. It still exists in Openstack but not on the HV. Is it > > possible > > to recover a VM from this state? > > so the vm is likely not deleted the harddisk and the libvirt domain will still be defiend. my guess is starting the > vm cause the oom reaper to kill the qemu process when it was relaunched. > > if you are deploying with memory over subsription enabled you should configre enough swap space equal to total > memory* ram_allocation_ratio. > > if you do that you you should be able to start the vm. now the other option is while the vm is stopped you can > cold migrate it to another host and then start it there.

1 0

openstack volume snapshots and deleting
by Ratliff, John 06 Dec '19

06 Dec '19

If I create a volume, snapshot it, and create a new volume from that snapshot, I cannot seem to delete the snapshot until the volume is deleted. Is this intentional, or am I doing something wrong? Is the new volume based on the snapshot, and that's why I can't delete it? We're using CEPH as a storage backend if that makes a difference. openstack volume snapshot create -volume base-volume base-ss openstack volume create -snapshot base-ss new-volume openstack volume snapshot delete base-ss The last command is the one that fails. It gives no error message. It just doesn't actually delete the snapshot. But If I do this: openstack volume delete new-volume openstack volume snapshot delete base-ss Then it works. I also tried creating a snapshot, creating a volume from the snapshot, then creating a volume from that volume, but I still cannot delete the snapshot until both volumes are deleted. I do not want everlasting snapshots, so I hope I'm doing something wrong that someone can point out. Thanks. --John

3 6

openstack cli server stop command
by Ratliff, John 06 Dec '19

06 Dec '19

Does the openstack server stop command do an ACPI shutdown or does it do the equivalent of pulling the power plug? I want to know if it's safe to run this command rather than logging into the machine and running shutdown (for say a RHEL7 instance). If it does an ACPI shutdown, what happens if the machine doesn't respond? Is there a command to force the machine off? Thanks. --John

2 2

[nova][cinder][ops] question/confirmation of legacy vol attachment migration
by Matt Riedemann 06 Dec '19

06 Dec '19

Hello Cinderinos, I've now got a working patch that migrates legacy volume attachments to new style v3 attachments [1]. The fun stuff showing it working is in this paste [2]. We want to do this data migration in nova because we still have a lot of compatibility code since Queens for pre-v3 style attachments and we can't remove that compatibility code (ever) if we don't first make sure we provide a data migration routine for operators to roll through. So for example if this lands in Ussuri we can can enforce a nova-status upgrade check in V and rip out code in X. Without digging into the patch, this is the flow: 1. On nova-compute restart, query the nova DB for instances on the compute host with legacy volume attachments. 2. For each of those, create a new style attachment with the host connector and update the BlockDeviceMapping information in the nova DB (attachment_id and connection_info). 3. Delete the existing legacy attachment so when the server is deleted the volume status goes back to 'available' due to proper attachment reference counting in the Cinder DB. My main question is on #3. Right now I'm calling the v3 attachment delete API rather than the v2 os-terminate_connection API. Is that sufficient to cleanup the legacy attachment on the storage backend even though the connection was created via os-initialize_connection originally? Looking at the cinder code, attachment_delete hits the connection terminate code under the covers [3]. So that looks OK. The only thing I can really think of is if a host connector is not provided or tracked with the legacy attachment, is that going to cause problems? Note that I think volume drivers are already required to deal with that today anyway because of the "local delete" scenario in the compute API where the compute host that the server is on is down and thus we don't have a host connector to provide to Cinder to terminate the connection. So Cinder people, are you OK with this flow? Hello Novaheads, Do you have any issues with the above? Note the migration routine is threaded out on compute start so it doesn't block, similar to the ironic flavor data migration introduced in Pike. One question I have is if we should add a config option for this so operators can enable/disable it as needed. Note that this requires nova to be configured with a service user that has the admin role to do this stuff in cinder since we don't have a user token, similar to nova doing things with neutron ports without a user token. Testing this with devstack requires [4]. By default [cinder]/auth_type is None and not required so by default this migration routine is not going to run so maybe that is sufficient? Hello Operatorites, Do you have any issues with what's proposed above? [1] https://review.opendev.org/#/c/549130/ [2] http://paste.openstack.org/show/781063/ [3] https://github.com/openstack/cinder/blob/410791580ef60ddb03104bf20766859ed9… [4] https://review.opendev.org/#/c/685488/ -- Thanks, Matt

5 10

email alert settings are not applied (ask.openstack.org)
by Eugen Block 06 Dec '19

06 Dec '19

Hi all, I'm not really sure if this is the right place to ask but I'll try it anyway. I'm regularly checking ask.openstack.org for interesting questions and sometimes I comment and respond. In my profile I configured instant email notification if someone comments or responds to my questions/comments. But this has never worked properly, I think this worked just once two or three years ago, never again. The only setting that seems to work is the weekly notification about new questions. Can anyone comment on this? Should I try to change the email address and see if that works? Any insight is appreciated! Regards, Eugen

2 2

[horizon] Shanghai PTG recap
by Akihiro Motoki 06 Dec '19

06 Dec '19

Hi, I am summarizing the horizon PTG in Shanghai. One month passed from the PTG, but I believe the summary is still useful :-) Eight folks joined the session and we had productive discussions. Thanks all! - PTG etherpad https://etherpad.openstack.org/p/horizon-u-ptg - release priority etherpad https://etherpad.openstack.org/p/horizon-release-priorities [Priorities for Ussuri] After the PTG, we discussed the project priorities for Ussuri based on the PTG discussion and agreed the following as project priorities. We will cover them in the weekly team meetings. * High * Catch up the new policy mechanism * Bump and clean up Django versions * Error message refactoring * Medium * xstatic updates * ini-based-configuration * Chinese translation handling [PTG recap] * Train retrospective * To keep * We succeeded to restore integration tests in horizon and several plugins. They just cover basic GET scenarios. Most JS tests do not cover scenario testing so it would be a good step to avoid plugin breakage. * We can keep the project healthiness to some level regardless of the low number of contributors. * To improve * The bundle policy files in horizon is out of date from back-end services and there was no progress since Stein release. For example, the new policies (system scope, deprecated policies) from the keystone repo does not work with horizon. It should be priorities in Ussuri release. We will join the pop-up team for the policy enhancement. * Some community goal from queens has not completed. (Most of them have done.) * Supported versions of Django and Python * We discussed the plan to enable Django 2.2 (the current LTS) by default and drop Django 1.11 support. The current plan is to bump the default Django to 2.2 around milestone-1 and drop Django 1.11 support by milestone-2. The minimum goal is to support Django 2.2 as it will be the only LTS supported by Django community as of Ussuri release. * The version changes in Django may break horizon plugins so we need enough time to test them in real deployments. * Integration test coverage would help the transition of Django version and let's try integration tests more with our best. * X-Static updates * Many xstatic packages are not updated for long. They has has fixes including security fixes, so we need to update them. radomir volunteered for the effort. * JS loading * e0ne shared his experiences on his trial to implement a plugin using react. * The problem is that it is not easy to use newer JS libraries. An example of problmes with a current approach is https://review.opendev.org/#/c/652657/ * It comes from the gap between the xstatic way to use same versions for all JS applications and modern JS packaging like webpack. * There is no good conclusion in this topic, but a long-term goal would be to use modern packaging mechanism instead of xstatic. It could be an issue for distribution packagers. * Horizon plugins maintenance * This slot covered topics around horizon plugin ecosystem and their maintenance. * The main outcomes are: * we agreed to change the release model of horizon to cycle-with-intermediary. Horizon plugins use horizon as library and we need to release horizon promptly whenever we have changes which affect plugins. cycle-with-intermediary model would fit more for this purpose. * A concern on that multiple major version bump potentially happens was raised, but we agreed that the version number does not matter and the best practice to avoid this is to drop deprecated features at the beginning of the cycle. * horizon team asked individual project teams with horizon plugins to give +2 right to horizon cores to make plugin maintenance smooth. * Most team agreed and we had conversations with more team at the PTG. * One important note is that horizon team should shouldn’t merge anything to plugins without +2 from plugin team. * We will update our documentation to cover this change in the plugin maintenance and e0ne volunteered for it. * Some side-discussion happened. There was no decision but they might be worth considering in future. * An idea to split nova/cinder/neutron/keystone/.... support to plugins and make them mandatory dependencies. * Use of micro-frontend concept * Chinese translation handling * From horizon perspective we agreed that we would like to move to the new locale names (zh-hans/hant) both in horizon (+plugins). * The main questions are the transition plan and locales for documentations. Further discussion with the i18n team happened in Shanghai. The summary of the discussion will be coming soon, but the first step agreed is that the horizon team confirms the new locales work fine in horizon. * Feature Gaps * Brief discussions happened for features with volunteers. * We will visit the status of the gaps in the etherpad https://etherpad.openstack.org/p/horizon-feature-gap * Refactor Error Messages * We received a good number of bug reports which complain that horizon error messages are too general and hide error details. * We agree to show both error message summary (translated) and detail message from API. * An idea discussed is to have a collapsible box to show an error detail along with a summary message. This approach would bring us a good balance of translated message and error detail from back-end services. * It would be a nice improvement in Ussuri. * Deprecations and Removals * Short discussion covered potential feature deprecation and removals. * Cinder v2 support will be dropped soon. * ini-based-configuration * amotoki expressed that he continues the effort and hopefully completes it in Ussuri. * API versions of backend services * horizon uses the minimum microversions to communicate with back-end services unless new versions are required to support features. * The possibility to bump the minimum versions used (per cycle?) was discussed and we agreed to keep the current strategy considering dev resources and maintenance. * Adoption of openstacksdk was discussed. openstacksdk supports older APIs and it would help us keep the current strategy on API versions used. * To use openstacksdk, we need to explore how to instantiate keystonauth Auth object with a token (as horizon stores only token and does not store auth information). We can start the investigation on this and e0ne volunteered. That's all we discussed in Shanghai. I hope we will have good progress in Ussuri. Best Regards, Akihiro Motoki (irc: amotoki)

1 0

[ptl] Train cycle-trailing release deadline
by Sean McGinnis 06 Dec '19

06 Dec '19

Hello all, For those teams with cycle-trailing deliverables, this is a reminder to make sure to get your Train series deliverables released. We like to have all of those out within three months of the coordinated release. For reference, here is a list of deliverables we have marked as Train cycle-trailing in the releases repo that do not appear to have a final release: cinderlib kayobe kolla-ansible kolla-cli kolla openstack-ansible tripleo-ui If these, or any others, need to be added or changed for Ussuri, please propose a placeholder deliverable file under deliverables/ussuri or update any existing ones with any needed changes. Thanks! Sean

3 3

Rebooted VM disappears when HV lacks memory
by Albert Braden 06 Dec '19

06 Dec '19

2 4

[magnum][stein] broken pipe
by Ignazio Cassano 05 Dec '19

05 Dec '19

Hello, I installed magnum stein on centos 7 but magnum-api reports the following error in /var/log/messages: Dec 5 21:14:49 tst2-osctrl01 magnum-api: Traceback (most recent call last): Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 568, in process_request Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.finish_request(request, client_address) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 334, in finish_request Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.RequestHandlerClass(request, client_address, self) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__ Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.finish() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.wfile.close() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/socket.py", line 279, in close Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.flush() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/socket.py", line 303, in flush Dec 5 21:14:49 tst2-osctrl01 magnum-api: self._sock.sendall(view[write_offset:write_offset+buffer_size]) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 401, in sendall Dec 5 21:14:49 tst2-osctrl01 magnum-api: tail = self.send(data, flags) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 395, in send Dec 5 21:14:49 tst2-osctrl01 magnum-api: return self._send_loop(self.fd.send, data, flags) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 382, in _send_loop Dec 5 21:14:49 tst2-osctrl01 magnum-api: return send_method(data, *args) Dec 5 21:14:49 tst2-osctrl01 magnum-api: error: [Errno 32] Broken pipe Anyone could help me please ? Regards Ignazio

1 0

[goals][Drop Python 2.7 Support] Week R-23 Update
by Ghanshyam Mann 05 Dec '19

05 Dec '19

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-23 week. We are in phase-1 which targets all the OpenStack services to drop the py2 support. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… NOTE: Phase-2 is for Library (including client library), QA tooling. Phase-3 is mainly for openstack/requirement and audit to all repo. (we can always adjust the schedule to make it smooth migration. For example, dropping a few testing jobs from phase-2/3 candidates if any cross-testing jobs are failing due to phase-1 candidates dropping the support[1].) Summary: ======= Patches to all services repo have been up for review[2]. The OpenStack services have not merged the py2 drop patches: * Adjutant * Barbican * Designate * ec2-api * Glance * Neutron * Freezer * Kolla * Monasca * Karbor * Congress * Telemetry * Storlets * Sahara * Blazar * Masakari * Placement * Heat (heat-dashboard patch is note merged ) * Tacker * Trove * Zaqar * Quinling * Manila * Tricircle * openstack-helm * python-openstackclient The OpenStack services dropped the py2 support: * Cinder * Nova * Ironic * Keystone * Octavia * Watcher * Vitrage * Zun * Winstackers * Mistral * Cyborg * Kuryr * Cloudkitty * Murano * Solum * Magnum * Senlin * Searchlight * openstack-ansible - I do not think we need any update in openstack-ansible? release notes jobs etc are already on py3. Rest all projects are targetted for phase-2 (after m-1). How you can help: ============== - Review the patches. Push the patches if I missed any repo targetted for phase-1. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011392… [2] https://review.opendev.org/#/q/topic:drop-py27-support -gmann

1 0

[release] Release countdown for week R-22
by Sean McGinnis 05 Dec '19

05 Dec '19

Development Focus ----------------- The Ussuri-1 milestone is next week, on December 12! Project team plans for the Ussuri cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Train release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Ussuri-1 milestone: December 12 (R-22 week)

1 0