- openstack-discuss - lists.openstack.org

[openstack-dev][tripleo] TripleO CI Summary: Sprint 23
by Rafael Folco 20 Dec '18

20 Dec '18

Greetings, The TripleO CI team has just completed Sprint 23 (Nov 28 thru Dec 19). The following is a summary of completed work during this sprint cycle: - Completed adding standalone scenarios(1-4) jobs and disabled equivalent multinode jobs on master to save upstream resources. We will now start adding the standalone scenario jobs to tripleo projects - Improved python3 support and fixed Tempest packaging on Fedora 28 job. This is part of python3 and RHEL8 validation in upstream CI. The Fedora 28 standalone job has flapped from passing to failed, currently failing on bug <https://bugs.launchpad.net/tripleo/+bug/1808118> [3]. - After the review of the team, we have decided to use upstream zuul containers to facilitate the tripleo job recreation [4] The team is continuing to evaluate software factory rpms as the base for this work. Instructions are posted internally atm. - Tested a new CI environment for OVB jobs on RDO cloud, aka “OVB 2.0”. Experiments include ovb deployment without the te-broker. The te-broker is now offline!!! - Tempest update can be found here [5]. The planned work for the next sprint are: - Continue to fix Fedora 28 standalone job and add Fedora 28 jobs to the promotion pipeline. - Add Standalone scenarios[1-4] jobs across TripleO repos for Stein - Follow the docs and test the new “Container Zuulv3” reproducer. - Continue to work on the OVB improvements The sprint board is tracked on Taiga [1]. The Ruck and Rover for this sprint are Ronnele Landy (rlandy) and Wes Hayutin (weshay). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. The Ruck and Rover notes for this sprint are tracked on etherpad [2]. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-3 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint24 [3] https://bugs.launchpad.net/tripleo/+bug/1808118 [4] https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001116… -- Rafael Folco Senior Software Engineer

1 0

[release] Release countdown for week R-15, Dec 24-28
by Sean McGinnis 20 Dec '18

20 Dec '18

Development Focus ----------------- There are a few project-specific deadlines coming up for milestone 2. Development should be focused on meeting any of those deadlines and preparing for the library releases that will be proposed at the milestone. General Information ------------------- This cycle we have stopped required milestone releases, and that has introduced a side-effect that means we need to take other steps to ensure that downstream packagers testing upgrades from Rocky to Stein do not have issues with the version numbers calculated by PBR on the master branch.More details can be found in the mailing list post here: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135706.html The release team has generated empty commits to cause PBR to increment its calculated version as a fix for the situation, and we have a few of those patches open still. Please merge them as soon as possible to support the people who are testing upgrades. https://review.openstack.org/#/q/status:open+branch:master+topic:sem-ver Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

Devstack - yet more problems on install
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Following on from the last email about br-ex causing everything to baulk, I manually created the br-ex using brctl addbr br-ex and got past that hurdle. But now falling over with another one ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified key was too long; max key length is 767 bytes') ERROR oslo_db.sqlalchemy.exc_filters Error during database migration: (pymysql.err.InternalError) (1071, u'Specified key was too long; max key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE COLUMN resource resource VARCHAR(300)'] (Background on this error at: http://sqlalche.me/e/2j85) Base OS is CentOS 7.5. I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. I'd appreciate some assistance please. David

3 3

Use cases mapping to MVP architectures - FEEDBACK NEEDED
by Ildiko Vancsa 20 Dec '18

20 Dec '18

Hi, Hereby I would like to forward you the mapping of use cases to MVP architectures that Gergely Csatari is working on. Please provide feedback on this work item to make sure we are considering all the aspects. Thanks and Best Regards, Gergely and Ildikó In the Edge Coputing Group we are collecting use cases for the edge cloud infrastructure. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now I’m looking for feedback. This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. Here I list the use cases and the mapped architecture scenarios: Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] Both distributed [3] and centralized [4] Universal customer premise equipment (uCPE) for Enterprise Network Services[6] Both distributed [3] and centralized [4] Unmanned Aircraft Systems (Drones) [7] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Cloud Storage Gateway - Storage at the Edge [8] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Open Caching - stream/store data at the edge [9] Both distributed [3] and centralized [4] Smart City as Software-Defined closed-loop system [10] The use case is not complete enough to figure out Augmented Reality -- Sony Gaming Network [11] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Analytics/control at the edge [12] The use case is not complete enough to figure out Manage retail chains - chick-fil-a [13] The use case is not complete enough to figure out At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] Smart Home [15] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Data Collection - Smart cooler/cold chain tracking [16] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event VPN Gateway Service Delivery [17] The use case is not complete enough to figure out [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_servi…. [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_cu… [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Air… [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storag… [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching… [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_a… [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Re… [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2F… [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retai… [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collect… [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_… _______________________________________________ Edge-computing mailing list Edge-computing(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing

1 1

[tc] Technical Committee Status for 17 Dec 2081
by Doug Hellmann 20 Dec '18

20 Dec '18

This is the (mostly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == Project updates: * Add os-resource-classes under Nova: https://review.openstack.org/#/c/621699/ Other updates: * I added a TC "house rule" for voting on updates to the release management metadata for projects, to make it easier to keep those up to date: https://review.openstack.org/#/c/622989/ * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. ** https://review.openstack.org/#/c/622902/ ** https://review.openstack.org/#/c/622903/ ** https://review.openstack.org/#/c/622904/ ** https://review.openstack.org/#/c/624704/ ** https://review.openstack.org/#/c/624951/ ** https://review.openstack.org/#/c/624996/ * I updated the documentation of chair responsibilities to include the OSF annual report: https://review.openstack.org/#/c/624790/ * Lance proposed an update to document the process for changing PTLs in the middle of a cycle: https://review.openstack.org/#/c/620928/ * Ghanshyam proposed an update to clarify the term of TC chair, since some responsibilities include managing the election fo the next chair: https://review.openstack.org/#/c/621498/ * Zane's resolution describing how we will keep up with future Python 3 releases has been approved: https://review.openstack.org/#/c/613145/ * Thierry and Chris' work to document the role of the TC has been approved: https://review.openstack.org/#/c/622400/ * I documented the official topic tags used to designate the voting rules to apply to each governance patch: https://review.openstack.org/#/c/625004/ == TC Meetings == The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ I have proposed an update to the TC house voting rules to cover documentation changes in the governance repository. * https://review.openstack.org/625005 Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat Akhmerov. * https://review.openstack.org/#/c/625537/ == TC member actions/focus/discussions for the coming week(s) == We need to work to approve Sean's patch with the Stein supported/testing runtimes list. * https://review.openstack.org/611080 Thierry started a thread on the mailing list about adapting our office hours times. It would be good for us to resolve that so we can make the change after the new year, so I have renewed the thread with a summary of the options. Please vote. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036… == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

3 4

[networking-ovs-dpdk] Issue creating br-ex...
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Hello Trying to re-run a Queens DPDK all-in-one using devstack which I built in August and hitting issues. The local.conf is identical between the two machines except I had to take the "stable/queens" off the end of the "networking-ovs-dpdk" plugin line as that no longer appears to work. The installation seems to proceed until it gets to setting the ip mtu on br-ex. I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for the system. OVS_NUM_HUGEPAGES=3072 #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G for the system. #OVS_NUM_HUGEPAGES=14336 OVS_DATAPATH_TYPE=netdev OVS_LOG_DIR=/opt/stack/logs #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 [[post-config|$NOVA_CONF]] [DEFAULT] firewall_driver=nova.virt.firewall.NoopFirewallDriver scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] [OVS] datapath_type=netdev [ml2_type_flat] #flat_networks=physnet1,physnet2,physnet3,physnet4 flat_networks=physnet1,physnet2 I cannot stress again how identical these systems are - same hardware, same base OS install (CentOS 7.5). I was (maybe erroneously!) thinking that if I had it devstack working on one system, having an identical system would be a piece of cake to install. This is the installation error: +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local bridge=br-ex +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' netdev '!=' system ']' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 set_mtu br-ex 1500 +functions:set_mtu:750 local dev=br-ex +functions:set_mtu:751 local mtu=1500 +functions:set_mtu:752 sudo ip link set mtu 1500 dev br-ex Cannot find device "br-ex" +functions:set_mtu:1 exit_trap +./stack.sh:exit_trap:522 local r=1 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545230781 1747 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen Can someone explain what is going on here please? Thanks David

3 4

[tc] Adapting office hours schedule to demand
by Thierry Carrez 20 Dec '18

20 Dec '18

Hi, A while ago, the Technical Committee designated specific hours in the week where members would make extra effort to be around on #openstack-tc on IRC, so that community members looking for answers to their questions or wanting to engage can find a time convenient for them and a critical mass of TC members around. We currently have 3 weekly spots: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays But after a few months it appears that: 1/ nobody really comes on channel at office hour time to ask questions. We had a questions on the #openstack-tc IRC channel, but I wouldn't say people take benefit of the synced time 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple of TC members present So the schedule is definitely not reaching its objectives, and as such may be a bit overkill. I was also wondering if this is not a case where the offer is hurting the demand -- by having so many office hour spots around, nobody considers them special. Should we: - Reduce office hours to one or two per week, possibly rotating times - Dump the whole idea and just encourage people to ask questions at any time on #openstack-tc, and get asynchronous answers - Keep it as-is, it still has the side benefit of triggering spikes of TC member activity Thoughts ? -- Thierry Carrez (ttx)

9 19

[magnum] Magnum missing project ID for octavia client
by Zufar Dhiyaulhaq 20 Dec '18

20 Dec '18

Hi, I am trying to create Kubenetes multi-master with Magnum. I get 'Create Failed error` in etcd_lb and api_lb and the log is : OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requea-8cce-27a3c49b9d28) full log from /var/log/magnum/magnum-conductor.api : 2018-12-20 22:41:33.362 9733 ERROR magnum.drivers.heat.driver [req-98498689-f584-47ab-b500-839a9e0d07cc - - - - -] Cluster error, stack staton: Resource CREATE failed: OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requ2a-8cce-27a3c49b9d28) I have working Octavia and magnum (only with 1 master, kubernetes or docker), this is my magnum configuration : [api] host = 10.111.111.10 [certificates] cert_manager_type = x509keypair [database] connection = mysql+pymysql:// magnum:556a8c5002cce3d8933@10.111.111.100/magnum [keystone_authtoken] memcached_servers = 10.111.111.10:11211,10.111.111.20:11211, 10.111.111.30:11211 auth_version = v3 auth_uri = http://10.111.111.100:5000/v3 project_domain_id = default project_name = service user_domain_id = default password = a13dfbbac5a0e03754773 username = magnum auth_url = http://10.111.111.100:35357 auth_type = password admin_user = magnum admin_password = a13dfbbac5a0e03754773 admin_tenant_name = service [trust] trustee_domain_name = magnum trustee_domain_admin_name = magnum_domain_admin trustee_domain_admin_password = b13dfbbac5a0e03754773 trustee_keystone_interface = public [oslo_messaging_notifications] driver = messaging [DEFAULT] transport_url=rabbit://openstack:5e81fb9286a573a1e4e33@10.111.111.10:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.20:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.30:5672 log_dir=/var/log/magnum [cinder_client] region_name = RegionOne [octavia_client] region_name = RegionOne Anyone know what is the problem? Thank you. Best Regards, Zufar Dhiyaulhaq

1 0

[openstack-ansible][cinder] Multiple backends for Cinder
by Cecilia Di Maulo 20 Dec '18

20 Dec '18

Dear all, I currently have a NFS backend for Cinder and I would like to add an iSCSI (hpmsa) backend. However I was wondering where should the cinder services run? For now cinder-api.service and cinder-scheduler.service run in a lxc while cinder-volume.service runs in bare metal on the controllers. I also would like to separate as much as possible the 2 backend types to be able to remove 'easily' my NFS backend once the other one has proved it really works. I was thinking to have the services related to the NFS backend in a lxc and the services related to the HPMSA backend on metal. Is this even possible? How should I do it? Should I name 2 different services in the container_skel or..? Thank you for your help, Best Regards, Cecilia

2 1

[IRONIC] vif attached to baremetal node DOWN
by Manuel Sopena Ballesteros 20 Dec '18

20 Dec '18

Dear Openstack community, I am having huge problems setting up baremetal port group: PROBLEM: VIF DOWN Environment: Openstack Rocky Deployment: kolla-ansible 7.0.0 Provider network # SERVER AND NEUTRON PORTS ########################## [root@openstack-deployment ~]# openstack server list +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ce8e10ab-12b4-476e-8990-b2aeda8510a0 | demo1 | ACTIVE | hpc=10.0.32.103 | centos7.5-image | my-baremetal-flavor | ... +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ [root@openstack-deployment ~]# openstack port list +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 1e1c3f40-1ee0-46d1-8e38-0b0617893ccf | | 7c:fe:90:12:1f:f0 | ip_address='10.0.32.103', subnet_id='506af593-659b-4c58-a180-897dd0b04957' | DOWN | ... +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ # BAREMETAL PORT GROUP ###################### [root@openstack-deployment ~]# openstack baremetal port group show 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 +----------------------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------------------+------------------------------------------------------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:27:53+00:00 | | extra | {} | | internal_info | {u'tenant_vif_port_id': u'1e1c3f40-1ee0-46d1-8e38-0b0617893ccf'} | | mode | 802.3ad | | name | zeus-54-hpc-bond | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | properties | {u'downdelay': 0, u'miimon': 110, u'xmit_hash_policy': u'layer2+3', u'updelay': 0} | | standalone_ports_supported | False | | updated_at | 2018-12-20T14:28:57+00:00 | | uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | +----------------------------+------------------------------------------------------------------------------------+ # BAREMETAL PORTS ################## [root@openstack-deployment ~]# openstack baremetal port show 4a00e6fa-a7c1-4916-b540-01fef95c90c1 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:28:09+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4a00e6fa-a7c1-4916-b540-01fef95c90c1 | +-----------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack baremetal port show 4510e849-ed21-46f8-bf4c-ca91c7e6b648 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f1 | | created_at | 2018-12-20T14:28:14+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4510e849-ed21-46f8-bf4c-ca91c7e6b648 | +-----------------------+--------------------------------------+ # NETWORK AND SUBNET CONFIG ############################### [root@openstack-deployment ~]# openstack network show hpc +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | nova | | created_at | 2018-12-17T02:07:46Z | | description | | | dns_domain | None | | id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | ipv4_address_scope | None | | ipv6_address_scope | None | | is_default | None | | is_vlan_transparent | None | | location | None | | mtu | 1500 | | name | hpc | | port_security_enabled | True | | project_id | b91520cff5bd45c59a8de07c38641582 | | provider:network_type | flat | | provider:physical_network | physnet1 | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 3 | | router:external | Internal | | segments | None | | shared | True | | status | ACTIVE | | subnets | 506af593-659b-4c58-a180-897dd0b04957 | | tags | | | updated_at | 2018-12-20T12:21:09Z | +---------------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack subnet show hpc_subnet +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 10.0.32.100-10.0.32.150 | | cidr | 10.0.0.0/16 | | created_at | 2018-12-17T02:07:49Z | | description | | | dns_nameservers | 8.8.8.8 | | enable_dhcp | True | | gateway_ip | 10.0.32.1 | | host_routes | | | id | 506af593-659b-4c58-a180-897dd0b04957 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | location | None | | name | hpc_subnet | | network_id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | project_id | b91520cff5bd45c59a8de07c38641582 | | revision_number | 2 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2018-12-20T12:21:09Z | +-------------------+--------------------------------------+ # BONUS: THIS IS THE NIC CONFIGURATION THAT WORKS ON A SERVER ############################################################## [root@zeus-52 ~]# cat /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1 BONDING_OPTS="downdelay=0 miimon=110 mode=802.3ad updelay=0" TYPE=Bond BONDING_MASTER=yes MTU=9000 PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=10.0.32.52 PREFIX=16 GATEWAY=10.0.32.1 DNS1=8.8.8.8 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME="Bond connection 1" UUID=5153a698-46ca-4234-a71b-7c88e4c92b91 DEVICE=bond0 ONBOOT=yes Any thought about what am I doing wrong or what to do next? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0