- openstack-discuss - lists.openstack.org

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 22 Jan '19

22 Jan '19

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[nova] Do we need to copy pci_devices to target cell DB during cross-cell resize?
by Matt Riedemann 22 Jan '19

22 Jan '19

While working on the code to create instance-related data in the target cell database during a cross-cell resize I noticed I wasn't copying over pci_devices [1] but when looking at the PciDevice object create/save methods, those aren't really what I'm looking for here. And looking at the data model, there is a compute_node_id field which is the compute_nodes.id primary key which won't match the target cell DB. I am not very familiar with the PCI device manager code and data model (it's my weakest area in nova lo these many years) but looking closer at this, am I correct in understanding that the PciDevice object and data model is really more about the actual inventory and allocations of PCI devices on a given compute node and therefore it doesn't really make sense to need to copy that data over to the target cell database. During a cross-cell resize, the scheduler is going to pick a target host in another cell and claim standard resources (VCPU, MEMORY_MB and DISK_GB) in placement, but things like NUMA/PCI claims won't happen until we do a ResourceTracker.resize_claim on the target host in the target cell. In that case, it seems the things I only need to care about mirroring is instance.pci_requests and instance.numa_topology, correct? Since those are the user-requested (via flavor/image/port) resources which will then result in PciDevice and NUMA allocations on the target host. I'm just looking for confirmation from others that better understand the data model in this area. [1] https://review.openstack.org/#/c/627892/5/nova/conductor/tasks/cross_cell_m… -- Thanks, Matt

2 2

[neutron] Neutron Bug Deputy report for week of Jan 14
by Nate Johnston 22 Jan '19

22 Jan '19

Neutron friends, Below is a summary of the neutron bugs that came in last week (Jan 14th). Any bugs with a preceding "(*)" are not yet in "in progress" state. Looks like lajoskatona is this week's bug deputy. Ports/IPAM - https://bugs.launchpad.net/bugs/1811905 Deferred IP allocation, port update with binding_host_id + set new mac address fails - https://bugs.launchpad.net/bugs/1812788 Port with no active binding mark as dead Gate Failures - (*) https://bugs.launchpad.net/bugs/1812364 Error "OSError: [Errno 22] failed to open netns" in l3-agent logs - https://bugs.launchpad.net/bugs/1812404 test_concurrent_create_port_forwarding_update_port failed with InvalidIpForSubnet - (*) https://bugs.launchpad.net/bugs/1812872 Trunk functional tests can interact with each other - https://bugs.launchpad.net/bugs/1812552 tempest-slow tests fails often L3 / DHCP - https://bugs.launchpad.net/bugs/1811873 get_l3_agent_with_min_routers fails with postgresql backend - (*) https://bugs.launchpad.net/bugs/1812118 Neutron doesn't allow to update router external subnets DNS - (*) https://bugs.launchpad.net/bugs/1812168 Neutron doesn't delete Designate entry when port is deleted QoS - https://bugs.launchpad.net/bugs/1812576 L2 agent do not clear old QoS rules after restart Oslo - https://bugs.launchpad.net/bugs/1812922 neutron functional tests break with oslo.utils 3.39.1 and above Docs - (*) https://bugs.launchpad.net/bugs/1812225 Firewall-as-a-Service (FWaaS) in neutron docs for Rocky still refer to plans for Ocata - (*) https://bugs.launchpad.net/bugs/1809578 Documentation might be wrong - https://bugs.launchpad.net/bugs/1812497 create vm failed, RequiredOptError: value required for option lock_path in group

1 0

[scientific-sig] IRC meeting at 2100 UTC: Jitter on SR-IOV IB, Terraform and Kubespray
by Stig Telfer 22 Jan '19

22 Jan '19

Hi All - We have a Scientific SIG IRC meeting in about 30 minutes in channel #openstack-meeting. Everyone is welcome. Today’s agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_22nd_2019 We have Jacob Anders from CSIRO talking about some recent research on latency and jitter for SR-IOV InfiniBand. We also have Martial Michel from DataMachines on Terraform and Kubespray. Cheers, Stig

1 0

Denver Summit CFP Closing Tomorrow
by Ashlee Ferguson 22 Jan '19

22 Jan '19

Hi everyone, The CFP closes in less than 48 hours, so make sure to submit your presentations, panels, and workshops <https://www.openstack.org/summit/denver-2019/call-for-presentations> for the Denver Open Infrastructure Summit before tomorrow, January 23 at 11:59pm PT (January 24 at 7:59am UTC). SUBMIT YOUR PRESENTATION <https://www.openstack.org/summit/denver-2019/call-for-presentations> Tracks: AI, Machine Learning & HPC CI/CD Container Infrastructure Edge Computing Hands-on Workshops Open Development (formerly Open Source Community) Open Infrastructure Basics Private & Hybrid Cloud Public Cloud Security - NEW! Telecom & NFV Full track descriptions <https://www.openstack.org/summit/denver-2019/summit-categories> For tips on your submissions, check out these articles for some advice from the Summit Programming Committees— http://superuser.openstack.org/articles/tips-for-the-open-infrastructure-su… http://superuser.openstack.org/articles/tips-open-development-track-denver-… http://superuser.openstack.org/articles/tips-for-talks-on-the-public-cloud-… Denver Summit registration <https://openinfrasummitandptgdenver.eventbrite.com/> and sponsor sales are currently open. Learn more <https://www.openstack.org/summit/denver-2019> Please email speakersupport(a)openstack.org <mailto:speakersupport@openstack.org> with any questions or feedback. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update VII - Jan 22, 2019
by Chandan kumar 22 Jan '19

22 Jan '19

Hello, Here is the seventh update (Jan 15 to Jan 22, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: * Add support for aarch64 images - https://review.openstack.org/#/c/620032/ * Configuration drives don't appear to work on aarch64+kvm - https://review.openstack.org/#/c/626592/ * Fix tempest workspace path - https://review.openstack.org/#/c/628182/ * Add libselinux-python package for Red Hat distro - https://review.openstack.org/#/c/631203/ * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/630917/ * Use tempest_domain_name var for setting domain - https://review.openstack.org/#/c/630957/ * Rename tempest_public_net_physical_{type to name} - https://review.openstack.org/#/c/631183/ * Add tempest_interface_name var for setting interface - https://review.openstack.org/#/c/630942/ ansible-config_template * Use usr/share/ansible/plugins for data_files - https://review.openstack.org/631214 ansible-role-python_venv_build * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/631777/ openstack-ansible-tests * Setup clouds.yaml on tempest node - https://review.openstack.org/631794 Tripleo-spec * New spec for stein: os_tempest tripleo integration - https://review.openstack.org/630654 Summary: * We have cleaned up os_tempest cloudname and network related vars, fixed tempest workspace upgrade issue and os_tempest got support of aarch64 images and nova Configuration drives. * Tripleo os_tempest spec published: https://specs.openstack.org/openstack/tripleo-specs/specs/stein/ostempest-t… Things in Progress: os_tempest * Always generate stackviz irrespective of tests pass or fail - https://review.openstack.org/631967 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Use the correct heat tests - https://review.openstack.org/630695 * Use tempest_cloud_name in tempestconf - https://review.openstack.org/631708 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 os_tempest integration with Tripleo * Added requirements for integrating os_tempest role - https://review.openstack.org/628421 * Run tempest using os_tempest role in standalone job - https://review.openstack.org/627500 * Use os_tempest for running tempest on standalone - https://review.openstack.org/628415 Upcoming week: * We are able to run tempest in Triplo CI standalone test results are here: http://logs.openstack.org/00/627500/65/check/tripleo-ci-centos-7-standalone… * We will try to finish os_tempest integration with tripleo and heat support in os_tempest. Thanks to odyssey4me, cloudnull, jrosser (a lot of help on different patches), Panda and Sagi from Tripleo CI team pabelanger and dmsimard on figuring out os_tempest dependencies, action_plugins and nested ansible. Here is the 6th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001730.… Thanks, Chandan Kumar

2 1

[Trove] State of the Trove service tenant deployment model
by Michael Richardson 22 Jan '19

22 Jan '19

Hi all, Is anyone aware of the current state of the "service tenant" deployment model for Trove, and whether it is a viable option; or whether the historical method of customer tenants/projects are still the recommended approach? Any and all comments/thoughts/gotchas would be most appreciated! Cheers, Michael

3 6

Fwd: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results
by Chris Morgan 22 Jan '19

22 Jan '19

Congrats to the new openstack foundation directors! Just FYI the following went to the foundation mailing list. Chris From: Jonathan Bryce <jonathan(a)openstack.org> Date: Fri, Jan 18, 2019, 12:42 Subject: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results To: <foundation(a)lists.openstack.org> Hello everyone, The 2019 election of Individual Directors has closed. Results are available at the following link: https://www.bigpulse.com/pollresults?code=1336400LYwRuQQZqR72BJRpKJYV The Bylaws amendments have now been passed by the Individual Member class. The elected and appointed directors will be seated at the Board meeting at the end of January. Congratulations to our new and returning directors. We actually had the highest number of voters for any of our elections participate this year, so thank you to everyone for joining in the process. Jonathan 210-317-2438 Individual Directors ----------------------------------------- Tim Bell ChangBo Guo Sean McGinnis Prakash Ramchandran Allison Randal Egle Sigler Monty Taylor Shane Wang Platinum Directors ----------------------------------------- Alan Clark Ruan He Anni Lai Mark McLoughlin Chris Price Imad Sousou Brian Stein Ryan Van Wyk Gold Directors ----------------------------------------- Mark Baker Johan Christenson Robert Esker Clemens Hardewig Arkady Kanevsky JunWei Liu Vijoy Pandey Joseph Wang _______________________________________________ Foundation mailing list Foundation(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation -- Chris Morgan <mihalis68(a)gmail.com>

2 1

About gitignore policy.
by Natal Ngétal 22 Jan '19

22 Jan '19

Hi everyone, I would to have more information about the .gitignore file policy. First I have made a patch to ignore backup files from vim editor. The patches was refused because that doesn't respect the OpenStack policy: https://review.openstack.org/#/c/631790/ https://review.openstack.org/#/c/631789/ The policy is available in a cookiecutter template repository: https://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/%7b%7bcookie… Then I have started to make patch, to align OpenStack projects with this policy: https://review.openstack.org/#/c/632086/ In nova project the patch was refused, the first reason was we have already talk about this subject. The second reason was this policy is only for the new projects. Oslo is not a new project and is follow this policy. I know is not a priority subject, but I just want understand. For me a policy must be followed by all projects, to harmonize all, but maybe I wrong. For example, in this case, I would to know what is the rules? The new projects must follow the policy but not the old ones? In this case, what the rules for old projects and can we defined also an policy for it? Thanks in advance for your help. My best regards

4 4

[qa] dynamic credentials with the tempest swift client
by Udi Kalifon 22 Jan '19

22 Jan '19

Hello. I am developing GUI tests (Selenium) for the openstack director. I am now trying to make use of tempest Swift client in one of the tests which needs to fetch a file from the tripleo plans. I added this code in our base class to access the client: class GUITestCase(test.BaseTestCase): credentials = ('admin', 'primary') @classmethod def setup_clients(cls): super(GUITestCase, cls).setup_clients() # Clients for Swift cls.account_client = cls.os_admin.account_client cls.container_client = cls.os_admin.container_client cls.object_client = cls.os_admin.object_client I then try to list the objects in the "overcloud" container, which is where the default plans are found: class TestSwift(GUITestCase): def test_swift(self): (resp, body) = self.container_client.list_container_objects( "overcloud") print resp print body It returns a "not found" error. I'm pretty sure that the reason for it not finding the container (which is definitely there) is that it creates a project and a user for itself, and uses those credentials for its interactions with the undercloud. I can see the POST calls in tempest.log that show that it's creating itself the dynamic credentials: INFO tempest.lib.common.rest_client [req-54a... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/projects 0.365s INFO tempest.lib.common.rest_client [req-d3f... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/users 0.493s INFO tempest.lib.common.rest_client [req-480... ] Request (TestSwift:setUpClass): 200 GET http://192.168.24.3:35357/v3/roles 0.297s INFO tempest.lib.common.rest_client [req-e0a... ] Request (TestSwift:setUpClass): 204 PUT http://192.168.24.3:35357/v3/projects/9e1e6b33dcbd4aebb546c56a7258d5e0/user… 0.270s INFO tempest.lib.common.dynamic_creds [-] *Acquired dynamic creds:* credentials: Credentials: {'username': u'tempest-TestSwift-1494291785', 'project_name': u'tempest-TestSwift-1494291785', 'project_domain_id': u'default', 'user_domain_id': u'default', 'tenant_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'user_domain_name': u'Default', 'domain_name': u'Default', 'tenant_name': u'tempest-TestSwift-1494291785', 'user_id': u'cc715537a0c048b7a8692a0c8304b94d', 'project_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'domain_id': u'default', 'project_domain_name': u'Default'}, Network: None, Subnet: None, Router: None So I'm looking for a way to utilize the client without it automatically creating itself dynamic credentials; it has to use the already-existing admin credentials on the admin project in order to see the container with the plans. What's the right way to do that, please? Thanks a lot in advance! Regards, Udi Kalifon; Senior QE; RHOS-UI Automation

3 4