- openstack-discuss - lists.openstack.org

[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 09 Dec '19

09 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 06 Dec '19

06 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 06 Dec '19

06 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 05 Dec '19

05 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

[all][requirements][drop-py27-support] Requirements is dropping cross tests with projects that will be dropping support for python2.7 this cycle
by Matthew Thode 05 Dec '19

05 Dec '19

Hi all, The requirements project is dropping python2.7 cross tests we do for those projects that are also dropping python2.7 support this cycle. We are doing this as wel do not know when projects will drop support (neutron seems to have done so, cinder is soon as well). This was originally scheduled for later but need to be pushed up as we missed the dependency requirements has on those projects for cross jobs. Here's the review if you are curious :D https://review.opendev.org/697377 -- Matthew Thode

3 2

How Bank or Financial sector benefited from OpenStack ?
by Mobarak Hossain 05 Dec '19

05 Dec '19

Hi, I want to approach to Bank for Open Infrastructure . They are asking how a Bank get benefited from Open Infrastructure .Except open Source . Is there any special features for Bank . I saw a video that Amex is using . Is there suggestion for me please let me know . Thanks -- Mobarak Hossain

2 1

[OSSN-0085] Cinder configuration option can leak secret key from Ceph backend
by Brian Rosmaita 05 Dec '19

05 Dec '19

Cinder configuration option can leak secret key from Ceph backend --- ### Summary ### This vulnerability is present only when Cinder has a Ceph backend *and* the ``rbd_keyring_conf`` option in the Cinder configuration file is set. (The option is unset by default.) Under these circumstances, the keyring content may be leaked to a regular user. ### Affected Services / Software ### Cinder, Pike, Queens, Rocky, Stein, Train ### Discussion ### When the ``rbd_keyring_conf`` option is set, a user who creates a volume and then does a local attach of that volume using the Cinder REST API, may discover the keyring content for the Ceph cluster. (This does not apply to the normal Nova attach process. The user must contact the Cinder REST API directly for this exploit.) If this user then gains access to the Ceph cluster independently of Cinder, these credentials may be used to access any volume in the cluster. This issue was reported by Raphael Glon of OVH. NOTE: This issue is different from OSSA-2019-003, through which Ceph credentials could be leaked from the Nova REST API during error conditions, but we suggest you take this opportunity to review that security advisory and make sure your system has been updated or patched to address it: https://security.openstack.org/ossa/OSSA-2019-003.html ### Recommended Actions ### Any installation currently using the ``rbd_keyring_conf`` option should immediately stop using that option. In order for Cinder backups to continue working, the Ceph keyring secrets should be deployed directly on cinder-backup hosts in their standard location: /etc/ceph/<cluster_name>.client.<user_name>.keyring The ``rbd_keyring_conf`` is deprecated in the Ussuri release and will be removed early in the 'V' development cycle. There is no replacement planned for this functionality. ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0085 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1849624 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg

1 0

What's the best recommendation of cache solution for Openstack services?
by 양유석 05 Dec '19

05 Dec '19

Hi, stackers. I wonder how other system deal with the problem we encountered. Any advice would be appreciated. He had a over 1000 hypervisors and hit some connection bottleneck in a DB. The DB instance handle all Openstack services (nova, neutron, cinder, glance ...) Also, we have some additional systems (kubernetes, consul...) which periodically request openstack API. Since most of request from additional systems is READ, I am trying to find cache approach for Openstack service. Although some services like keystone has their own caching layer, I could not find general solutions. Is there any project to solve this problem (reduce DB overhead in a lot of read overhead) I found oslo.cache only provide decorator for a function, so wonder there is any service level approach. Thanks

2 1

DHCP timeout when creating instances for specific tenants
by Grant Morley 05 Dec '19

05 Dec '19

Hi all, I wonder if anyone can help shed any light on an odd issue we are seeing with only a couple of specific tenants. Basically if they launch an instance they are taking about 5 minutes to launch rather than our usual 30 second or so launch. We are seeing the following on the instance logs: https://pastebin.com/hDstsd8G Weirdly it only seems to be happening for 1 or 2 new tenants. I have tested this on our personal account and a few other customers have tested and their instances launch really quickly as expected. Is there anything specific during the tenant creation that can cause this issue? Or are there any logs in nova / neutron I should be looking out for that might shed some light? I haven't seen anything that is obvious. Any help would be much appreciated as we are a little stumped at the moment. Many thanks, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

4 8

[neutron] Proposing Jakub Libosvar as Neutron core reviewer
by Slawek Kaplonski 05 Dec '19

05 Dec '19

Hi neutrinos, We already started process of migrating networking-ovn driver to be one of in-tree neutron drivers. Blueprint for that is [1]. As part of this process I today proposed to include networking-ovn-core group into neutron-core group. Mail about it can be found at [2]. One of persons in networking-ovn-group is Jakub Libosvar who was Neutron core for very long time in the past. He knows very well not only ovn related code but also have great knowledge about all Neutron code base. So I would like to propose to Jakub as Neutron core reviewer again as he will be back working on neutron again now, after ovn will be in-tree driver. What do You think about it? I will wait for Your opinions for 1 week from now. Thx for all Your comments about it. [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011240… — Slawek Kaplonski Senior software engineer Red Hat

7 7

[heat][heat-translator] add Hiroyuki Jo to heat-translator core reviewer
by Rico Lin 04 Dec '19

04 Dec '19

Hi all Hiroyuki Jo has been active in the past few months. Also, he raises his willingness to help maintain patches in the last PTG [1]. It's my pleasure to add Hiroyuki Jo to heat-translator-core team with condition that me and other core members should help to review his patch (so no self-approval) and provide review guideline if needed. Free feel to suggest otherwise. [1] https://etherpad.openstack.org/p/PVG-heat -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

Swedish University Engagement Program
by Kendall Nelson 04 Dec '19

04 Dec '19

Hello Everyone! During the PTG, I talked to Kim Hindhart (along with Ildiko Vancsa, Sean McGinnis, and Victoria Martinez de la Cruz) about a program he was working on with several universities in Sweden (Blekinge Institute of Technology, Uppsala University, and KTH Royal Institute of Technology) to get students involved in open source, specifically involved in OpenStack. While this program is still getting off the ground, with its first round to start in this coming February with students working on Horizon (led by Kim), we are hoping to collect work for the second round that will be more student driven. The only disclaimer is that items suggested might not get picked up until the fall semester in September. I am collecting low-hanging-fruit here on this etherpad[1].Hopefully you have a lot of things tagged as such on Launchpad/StoryBoard already and can easily add those links to the etherpad. Can't wait to see what we can come up with! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/swedish-university-program-work

1 0

[tripleo][ppc64le] Unexpected Return Code from TripleO Container Build Playbooks on ppc64le
by Adam Kimball 04 Dec '19

04 Dec '19

Hello all, Mike Turek and I have been working to get a ppc64le job to build tripleo containers for quite some time now. A few weeks back, we stumbled into a strange issue where the containers build job was issuing a return code 1, despite all containers successfully building. This has largely blocked our ability to push containers up to docker hub or report success through the delorean API. We've been pushing a number of patches to expand the logging of both our job, and the tripleo playbooks themselves, to get a better idea of what's going on. The most recent was a patch to show which containers have python futures that have been throwing exceptions, and why. [1] The end result of this seems to be that a number of jobs are reporting as incomplete. An example of this can be seen at timestamp 20:16:07 of an example build log. [2] However, upon checking the list of successfully built containers [3], or the RDO registry itself [4], one can see that the containers producing job not complete errors have actually built, and are being uploaded. The error log generated by the tripleo playbooks is also empty. [5] At this point, we're wondering what the path forward is. It seems like the issue stems from some unintended behavior in the tripleo playbooks themselves, not anything from our job. We're trying to figure out if this behavior is something that should be preventing us from reporting successful builds, and if so, how it can be fixed. Thanks, Adam Kimball [1] - https://review.opendev.org/#/c/695723/ [2] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master… [3] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master… [4] - https://console.registry.rdoproject.org/registry [5] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master…

2 1

[cinder] Ussuri Shanghai and Virtual PTG update
by Brian Rosmaita 04 Dec '19

04 Dec '19

The PTG summary document has been updated with a quick synopsis of what we discussed at the Virtual PTG last week: https://wiki.openstack.org/wiki/CinderUssuriPTGSummary All sessions (both Shanghai and Virtual) were recorded. The above page contains links to the recordings, which you can also find on the Cinder YouTube channel. Please look through the summary document to remind yourself about any actions you volunteered for. Additionally, there's an etherpad of unclaimed action items if you're looking for something to do: https://etherpad.openstack.org/p/cinder-ussuri-ptg-actions Thanks to everyone who participated in the PTG events. cheers, brian

1 0