May 2019 - openstack-discuss - lists.openstack.org

[nova][ptg][keystone] Summary: Unified Limits and Policy Refresh in Nova
by John Garbutt 07 May '19

07 May '19

Hi, A summary of the nova/keystone cross project PTG session. Full etherpad is here: https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone 1) Policy Refresh Spec: https://review.openstack.org/#/c/547850/ Notes: * Better defaults to make policy changes easier * Move from current to: System Admin vs Project Member * Also add System Reader and Project Reader ** Above requires more granular policy for some APIs ** Also change DB check: system or admin, eventually drop it * Lots of testing to avoid regressions * Patrole may be useful, but initial focus on in-tree tests Actions: * johnthetubaguy to update spec * melwitt, gmann and johnthetubaguy happy to work on these * upload POC for testing plan 2) Unified Limits Spec: https://review.opendev.org/#/c/602201/ Notes: * only move instances and resource class based quotas to keystone * work on tooling to help operators migrate to keystone based limits * adopt oslo.limit to enforce unified limits * eventually we get hierarchical limits and the "per flavor" use case Actions: * johnthetubaguy to update the spec * johnthetubaguy, melwitt, alex_xu happy to work on these things * work on POC to show approach Thanks, johnthetubaguy

1 0

[kayobe] Denver summit summary
by Mark Goddard 07 May '19

07 May '19

Hi, The Kayobe feedback & roadmap session Etherpad notes are at [1]. A major theme was documentation, including reference configurations and more around day 2 ops. On Tuesday evening we ran a packed workshop [2] on deploying OpenStack via Kayobe. It went pretty smoothly overall, and we had some positive feedback. Thanks to Packet for providing the infrastructure - the bare metal servers let us cover a lot of ground in a short time. Anyone wanting to try out the workshop can do so using a VM or bare metal server running CentOS 7 with at least 32GB RAM and 40GB disk. Follow the 'Full Deploy' section [3] in the README. I spoke with many people during the week who feel that Kayobe could be a great fit for them, which is really encouraging. Please look out for new users and contributors reaching out via IRC and the mailing list and help them get up to speed. [1] https://etherpad.openstack.org/p/DEN-19-kayobe-feedback-roadmap [2] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23426/a… [3] https://github.com/stackhpc/a-universe-from-nothing#full-deploy Cheers, Mark

1 0

[TripleO][PTG] Validation summary
by Cédric Jeanneret 07 May '19

07 May '19

Hello all, Last Saturday, we had a session about two topics: - Validation Framework - In-flight validations Here's a summary about the different discussions around those topics. ## Current state: - all the existing validations within "tripleo-validations" have been moved to the new format (proper ansible roles with dedicated playbook). Big thumb up to the involved people for the hard work! - Mistral runs them from the hard drive instead of using swift - Possibility to run validations through the CLI using the new "openstack tripleo validator" subcommand - Possibility to run the validations directly with ansible-playbook - Blog posts with demos and some explanations: ° https://cjeanner.github.io/openstack/tripleo/validations/2019/04/24/validat… ° https://cjeanner.github.io/openstack/tripleo/validations/2019/04/25/in-flig… ° https://cjeanner.github.io/openstack/tripleo/validations/2019/04/26/in-flig… ## TODO - Refactor tripleoclient code regarding the way ansible is called, in order to allow bypassing mistral (useful if mistral is broken or not available, like on a standalone deploy) - Get more validations from the Services teams (Compute, Neutron, and so on) - CI integration: get a job allowing to validate the framework (running the no-op validation and group) as well as validations themselves - Doc update (WIP: https://review.opendev.org/654943) - Check how the tripleo-validations content might be backported down to Pike or even Newton. We don't consider the CLI changes, since the cherry-picks will be more than painful, and might break things in a really bad way. You can find the whole, raw content on the following pad: https://etherpad.openstack.org/p/tripleo-ptg-train-validations In case you have questions or remarks, or want to dig further in the topics present on that pad, feel free to contact me or just run a thread on the ML :). Cheers, C. -- Cédric Jeanneret Software Engineer DFG:DF

1 0

[neutron] bug deputy notes 2019-04-29 - 2019-05-06
by Nate Johnston 07 May '19

07 May '19

Neutrinos, It was a quiet week with the summit and PTG. All reported bugs have a fix in progress except for 1827363. High: - "snat gateway port may stay 4095 after router fully initialized in l3 agent" * https://bugs.launchpad.net/bugs/1827754 * Fix in progress - "Network won't be synced when create a new network node" * https://bugs.launchpad.net/bugs/1827771 * Fix in progress - "Additional port list / get_ports() failures when filtering and limiting at the same time" * https://bugs.launchpad.net/neutron/+bug/1827363 Low: - "Remove deprecated SR-IOV devstack file" * https://bugs.launchpad.net/neutron/+bug/1827089 * Fix merged - "Routed provider networks in neutron - placement CLI example" * https://bugs.launchpad.net/bugs/1827418 * Fix in progress - "Wrong IPV6 address provided by openstack server create" * https://bugs.launchpad.net/neutron/+bug/1827489 * Fix merged Thanks, Nate

1 0

[cyborg] [ptg] PTG summary
by Nadathur, Sundar 06 May '19

06 May '19

Thanks to all Cyborg, Nova and Ironic developers for the productive PTG. * Cyborg-Nova integration: Demo slides are here [1]. The xproj etherpad with summary of outcomes is [2], and includes the demo slides link at the bottom. (The Cyborg PTG etherpad [3] also contains the link to the slides in Line 26.) Good to see that Nova has made Cyborg integration as a cycle theme [4]. * Major goals for Train release [5] were unanimously agreed upon. * Mapping names to IDs: All agreed on the need. The discussion on how to do that needs to be completed. By using alternative mechanisms for function IDs and region IDs, we could potentially avoid the need for a new API. * Good discussions on a variety of other topics, as can be seen in [3], but they need follow-up. * Owners identified for most of the ToDo tasks [3]. * In offline conversations after the PTG, ZTE developers have agreed to help with getting tempest CI started, to be followed up by others later. * Cyborg-Ironic cross-project [6]: Good discussion. The need for the integration was understood: between the types of bare metal servers, and varying number/types of accelerators, there is a combinatorial explosion of the number of variations; Cyborg can help address that. Need to write a spec for the approach. Next steps: * Cyborg/Nova integration: o Drive Nova spec to closure, write and merge some Cyborg specs (device profiles, REST API), merge Cyborg pilot code into master, incorporate some feedback in Nova patches. o Set up tempest CI, with a real or fake device. o Only after both steps above are done will Nova patches get merged. * Need to write a bunch of specs: Cyborg (REST API spec, driver API spec?), DDP-related specs, Ironic+Cyborg spec. * Complete the discussions on remaining items. [1] https://docs.google.com/presentation/d/1uHP2kVLiZVuRcdeCI8QaNDJILjix9VCO7wa… [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg [3] https://etherpad.openstack.org/p/cyborg-ptg-train [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005867.html [5] https://etherpad.openstack.org/p/cyborg-train-goals [6] https://etherpad.openstack.org/p/ptg-train-xproj-ironic-cyborg Regards, Sundar

1 0

[nova][ptg] Summary: Server group [anti-]affinity
by Eric Fried 06 May '19

06 May '19

The Issue: Doing server group affinity ("land all these instances on the same host") and anti-affinity ("...on different hosts") on the nova side is problematic in large deployments (like CERN). We'd like to do it on the placement side - i.e. have GET /allocation_candidates return [just the one host to which servers in the group are being deployed] (affinity); or [only hosts on which servers in the group have not yet landed] (anti-affinity). Summary: - Affinity is fairly easy: ?in_tree=<host on which any existing instance in my server group has been deployed>. - For anti-affinity, we need something like ?in_tree=!<inst.host for inst in server_group>. - The size of <the list> in the latter case could quickly get out of hand, exceeding HTTP/wsgi (querystring length) and/or database query (`AND resource_provider.uuid NOT IN <the list>`) limits. - Race conditions in both cases are a little tricky. - tssurya to come up with spec(s) for ?in_tree=!<list> and nova usage thereof, wherein discussions of the above issues can occur. - Unclear if this will make Train. efried .

2 1

[cinder] Third party CI failures with namespace changes
by Sean McGinnis 06 May '19

06 May '19

Just a heads up for third party CI maintainers. You should have already noticed this, but we have quite a few that are failing tests right now because the CI systems have not been updated for the new git namespaces. There are several I noticed that are failure trying to clone https://git.openstack.org/openstack-dev/devstack. With all of the changes a couple weeks ago, this should now be from https://opendev.org/openstack/devstack. Please update your CI's to pull from the correct location, or disable them for now until you are able to make the updates. The current barrage of CI failure comments soon after submitting patches are not particularly helpful. Thanks for your prompt attention to this. As a reminder, we have a third party CI policy that impacts in-tree drivers if third party CI's are not maintained and cannot give us useful feedback as to whether a driver is functional or not [0]. Thanks, Sean [0] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Non-Complian…

1 0

[cinder] No weekly meeting this week ...
by Jay Bryant 06 May '19

06 May '19

Team, It was discussed at the PTG last week that we would take this week off from our usual team meeting. So, enjoy getting an hour back on Wednesday and we will go back to our regularly scheduled meetings on May 15th . Thanks! Jay

1 0

Shanghai Summit Programming Committee Nominations Open
by Ashlee Ferguson 06 May '19

06 May '19

Thank you to everyone who attended the Open Infrastructure Summit in Denver. The event was a huge success! If you weren’t able to make it, check out the videos page [1]. Keynotes are up now, and the rest of the sessions will be uploaded in the next week. We’ll also be sharing a Summit recap in the Open Infrastructure Community Newsletter, which you can subscribe to here [2]. The next Summit + PTG will be in Shanghai, November 4 - 6, and the PTG will be November 6 - 8, 2019. Registration and Programming Committee nominations for the Shanghai Open Infrastructure Summit + PTG [3] are open! The Programming Committee helps select the content from the Call for Presentations (CFP) for the Summit schedule. Sessions will be presented in both English and Mandarin, so we will be accepting CFP submissions in both languages. The CFP will open early next week. • Nominate yourself or someone else for the Programming Committee [4] before May 20, 2019 • Shanghai Summit + PTG registration is available in the following currencies: • Register in USD [5] • Register in RMB (includes fapiao) [6] Thanks, Ashlee [1] https://www.openstack.org/videos [2] https://www.openstack.org/community/email-signup [3] https://www.openstack.org/summit/shanghai-2019 [4] http://bit.ly/ShanghaiProgrammingCommittee [5] https://app.eventxtra.link/registrations/6640a923-98d7-44c7-a623-1e2c9132b4… [6] https://app.eventxtra.link/registrations/f564960c-74f6-452d-b0b2-484386d33e…

1 0

[openstack-dev] [neutron] Cancelling Neutron weekly meeting on May 7th
by Miguel Lavalle 06 May '19

06 May '19

Dear Neutron Team, Since we just meet during the PTG, we will skip the weekly team meeting on May 7th. We will resume our meetings on the 13th Best regards

1 0