- openstack-discuss - lists.openstack.org

[placement] update 18-47
by Chris Dent 23 Nov '18

23 Nov '18

HTML: https://anticdent.org/placement-update-18-47.html It's been a while since the last placement update. Summit happened. Seemed pretty okay, except for the food. People have things they'd like to do with placement. # Most Important We're starting to approach the point where we're thinking about the possibility of maybe turning off placement-in-nova. We're not there yet, and as is always the case with these kinds of things, it's the details at the end that present the challenges. As such there are a mass of changes spread around nova, placement, devstack, grenade, puppet and openstack-ansible related to making things go. More details on those below, but what we need is the same as ever: reviews. Don't be shy. If you're not a core or not familiar with placement, reviews are still very helpful. A lot of the patches take the form of "this _might_ be the right way to do this". # What's Changed There is now a placement-manage command which can do database migrations, driven by alembic. This means that the devstack patch which uses the extracted placement can merge soon. Several other testing related (turning on tempest and grenade for placement) changes depend-on that. Matt did a placement-status command which has a no-op we-are-here upgrade check. We've already met the python3 goals (I think?), so I reckon placement is good to go on community-wide goals. Woot. The PlacementFixture that placement provides for other projects to do functional tests with it has merged. There's a patch for [nova using it](https://review.openstack.org/#/c/617941/). The spec for [counting quota usage in placement](https://review.openstack.org/#/c/509042/) has been revived after learning at summit that a proposed workaround that didn't use placement wasn't really all that good for people using cells v2. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17. +1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 13. +2 # Specs Summit and U.S. Thanksgiving has disrupted progress on some of these, but there are still plenty of specs awaiting their future. _Many_ of these have unaddressed negative review comments. * <https://review.openstack.org/#/c/544683/> Account for host agg allocation ratio in placement (Still in rocky/) * <https://review.openstack.org/#/c/595236/> Add subtree filter for GET /resource_providers * <https://review.openstack.org/#/c/597601/> Resource provider - request group mapping in allocation candidate * <https://review.openstack.org/#/c/549067/> VMware: place instances on resource pool (still in rocky/) * <https://review.openstack.org/#/c/555081/> Standardize CPU resource tracking * <https://review.openstack.org/#/c/599957/> Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * <https://review.openstack.org/#/c/591037/> Modelling passthrough devices for report to placement * <https://review.openstack.org/#/c/603955/> Nova Cyborg interaction specification. * <https://review.openstack.org/#/c/601596/> supporting virtual NVDIMM devices * <https://review.openstack.org/#/c/603352/> Spec: Support filtering by forbidden aggregate * <https://review.openstack.org/#/c/552924/> Proposes NUMA topology with RPs * <https://review.openstack.org/#/c/569011/> Count quota based on resource class * <https://review.openstack.org/#/c/141219/> Adds spec for instance live resize * <https://review.openstack.org/#/c/612497/> Provider config YAML file * <https://review.openstack.org/#/c/509042/> Propose counting quota usage from placement and API database * <https://review.openstack.org/603545> Resource modeling in cyborg. # Main Themes ## Making Nested Useful Progress is being made on gpu-reshaping for libvirt and xen: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:…> Somewhat related to nested are a stack of changes to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615646/> ## Extraction (There's an [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) which tracks some of the work related to extraction. Please refer to that for additional information.) TripleO and OpenStack-Ansible are both working on tooling to install and/or upgrade to extracted placement: * <https://review.openstack.org/#/q/topic:tripleo-placement-extraction> * <https://review.openstack.org/#/q/project:openstack/openstack-ansible-os_pla…> libvirt support for GPU reshaping: * <https://review.openstack.org/#/c/599208/> Grenade and tempest testing for extracted placement: * Extracted placement in devstack: <https://review.openstack.org/600162> * Turning on tests: <https://review.openstack.org/#/c/617565/> * Some fixes to grenade using python3: <https://review.openstack.org/#/c/619728/> A replacement for `placeload` performance testing that was in the `nova-next` job: <https://review.openstack.org/#/c/619248/>. This might be of interest to people trying to do testing of live services without devstack. It starts with a basic node, turns on mysql, runs placement with uwsgi, and does the placeload testing. Note that this found a pretty strange [bug in _ensure_aggregates](https://bugs.launchpad.net/nova/+bug/1804453). Documentation tuneups: * Front page: <https://review.openstack.org/#/c/619273/> * Release-notes: <https://review.openstack.org/#/c/618708/> This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.h…. We've been putting off making a decision about os-resource-classes. Anyone have strong opinions? # Other Besides the 20 or so [open changes](https://review.openstack.org/#/q/status:open+project:openstack/pla… in placement itself, and those mentioned above, here are some other changes that may be of interest. * <https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios> Improve handling of default allocation ratios * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/602160/> Add OWNERSHIP $SERVICE traits * <https://review.openstack.org/#/c/586960/> zun: Use placement for unified resource management * <https://review.openstack.org/#/q/topic:cd/gabbi-tempest-job> Using gabbi-tempest for integration tests. * <https://review.openstack.org/#/q/project:openstack/blazar+topic:bp/placemen…> Blazar using the placement-api * <https://review.openstack.org/619626> Tenks doing some node management, with a bit of optional placement. * <https://review.openstack.org/617273> Extracted placement in loci * <https://review.openstack.org/#/c/613589/> Extracted placement in kolla * <https://review.openstack.org/#/c/613629/> Extracted placement in kolla-ansible # End Lot going on. Thanks to everyone for their contributions. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

RE: [openstack-dev] StarlingX gap analysis to converge with OpenStack master
by Xu, Chenjie 22 Nov '18

22 Nov '18

Hi Miguel, There is another RFE “Add l2pop support for floating IP resources” proposed to Launchpad. This RFE also comes from StarlingX and the link is below: https://bugs.launchpad.net/neutron/+bug/1803494 Could you please help review this RFE? I think this RFE can be added to the gap analysis. What’s more, there is a bug and a RFE relating to l2pop and neutron-dynamic-routing is being written and is expected to be released next week. Best Regards, Xu, Chenjie From: Miguel Lavalle [mailto:miguel@mlavalle.com] Sent: Thursday, November 22, 2018 2:12 AM To: openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org>; OpenStack Development Mailing List <openstack-dev(a)lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master Hi Stackers, One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Best regards Miguel

2 1

[Openstack] Fwd: FOSDEM‘19 Virtualization & IaaS Devroom CfP
by Piotr Kliczewski 22 Nov '18

22 Nov '18

A friendly reminder that Cfp is due by 1st of December. Please submit your proposal using: https://penta.fosdem.org/submission/FOSDEM19 ---------- Forwarded message --------- From: Piotr Kliczewski <pkliczew(a)redhat.com> Date: Wed, Oct 17, 2018 at 9:41 AM Subject: [Openstack] FOSDEM‘19 Virtualization & IaaS Devroom CfP To: <openstack(a)lists.openstack.org> We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2019, to be hosted on February 2nd 2019. This year will mark FOSDEM’s 19th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 2nd & 3rd, 2019. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2018. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 1 December 2019 Acceptance notifications: 14 December 2019 Final schedule announcement: 21 December 2019 Devroom: 2nd February 2019 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Speaker Mentoring Program As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for new speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: Never presented before or Presented only lightning talks or Presented full-length talks at small meetups (<50 ppl) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Call for Mentors Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker biography and any specific fields of expertise (for example, KVM, OpenStack, storage, etc.) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? As the mentoring program coordinator, email Brian Proffitt[3] and he will be happy to answer your questions! Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact Brian Proffitt, for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17> https://penta.fosdem.org/submission/FOSDEM19 [2] iaas-virt-devroom at lists.fosdem.org <https://lists.fosdem.org/listinfo/fosdem> [3] bkp at redhat.com <https://lists.fosdem.org/listinfo/fosdem> _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[Openstack-operators] openstack-annsible networking layout before running playbooks
by Jawad Ahmed 22 Nov '18

22 Nov '18

Hi all, I am deploying openstack-ansible in test environment where I need to use br-mgmt bridge for both storage and management traffic (same bridge for both) so that container interfaces eth1 and eth2 will connect to br-mgmt for mgmt and storage traffic at same time.Does it make sense if I ll setup provider networks openstack_user_config.yml as below? tunnel_bridge: "br-vxlan" //separate bridge for vxlan though management_bridge: "br-mgmt" provider_networks: - network: container_bridge: "br-mgmt" container_type: "veth" container_interface: "eth1" ip_from_q: "container" type: "raw" group_binds: - all_containers - hosts is_container_address: true is_ssh_address: true - network: container_bridge: "br-mgmt" container_type: "veth" container_interface: "eth2" ip_from_q: "storage" type: "raw" group_binds: - glance_api - cinder_api - cinder_volume - nova_compute Help would be appreciated. -- Greetings, Jawad Ahmed _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

2 1

[openstack-dev][tacker] seeking feedback for HealVnfRequest implementation
by Shewale, Bhagyashri 22 Nov '18

22 Nov '18

Hi All, As discussed in the summit, "vdu_autoheal" monitoring policy action implementation should be as per ETSI standard HealVnfRequest interface [1] (refer comment given on patch https://review.openstack.org/#/c/612595/9 ) Started working on the same but have some quires so needs some feedback and inputs. As per the ETSI doc [1] the data model for HealVnfRequest contains two request parameters (cause anddditionalParams) (Check section: 5.5.2.9 Type: HealVnfReques from [1]) The Request Payload for HealVnfRequest (ETSI data structure: HealVnfRequest) should be the dictionary as mentioned in [2] (Check section: Healing VNFs Using ETSI API from [2]) But the “addtionalParams” parameter should be part of "HealVnfOpConfig” and that expects two parameters (cause and parameter) as mentioned in [3] (Check section: 7.1.5.6 HealVnfOpConfig information element from [3]) So accordingly I have designed the request data for vdu_autoheal monitoring policy action as below: Heal Request Data for monitoring: { "cause": "", "additionalParams": [ {“parameter”: <Resource name given in the vnfd template for eg. VDU1>, “cause”: [<Reason for failure of the resource>]}, {“parameter”: <Resource name given in the vnfd template for eg. CP1>, “cause”: [<Reason for failure of the resource]} ] } Please let me know the opinion about the same. Also "HealVnfOpConfig” having type as “tosca.datatypes.nfv.VnfHealOperationConfiguration” as per the ONAP [4] and the schema for that is as mentioned below: Schema: tosca.datatypes.nfv.VnfHealOperationConfiguration derived_from: tosca.datatypes.Root properties: #parameters: #modeled as part of the operation parameter list causes: type: list entry_schema: type: string so does that mean we can accepts this request in tosca template for HealVnfRequest? [1]: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.05.01_60/gs_NFV… [2]: https://www.cisco.com/c/en/us/td/docs/net_mgmt/elastic_services_controller/… [3]: https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV… [4]: https://onap.readthedocs.io/en/beijing/submodules/modeling/modelspec.git/do… Regards, Bhagyashri Shewale Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged,confidential, and proprietary data. If you are not the intended recipient,please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

[openstack-dev] [ZUN] [kuryr-libnetwork]
by Rania Adouni 21 Nov '18

21 Nov '18

Hi everyone, I was trying to create container but I just ended up by this error : *Docker internal error: 500 Server Error: Internal Server Error ("failed to update store for object type *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 <http://192.168.1.20:2379>: connect: connection refused").* Then I back to Verify operation of the kuryr-libnetwork, if it work fine or not with command : *docker network create --driver kuryr --ipam-driver kuryr --subnet 10.10.0.0/16 <http://10.10.0.0/16> --gateway=10.10.0.1 test_net * But i get this error : *Error response from daemon: failed to update store for object type *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 <http://192.168.1.20:2379>: connect: connection refused * *Ps: 192.168.1.20 is the address of my controller Node !!* some help will be nice and thanks . Best Regards, Rania Adouni __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

3 4

[openstack-dev] StarlingX gap analysis to converge with OpenStack master
by Miguel Lavalle 21 Nov '18

21 Nov '18

Hi Stackers, One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Best regards Miguel

5 7

[k8s] [manila] Manila CSI driver plan
by Tom Barron 21 Nov '18

21 Nov '18

[Robert Vasek, Red Hat colleagues working in this space: please correct any mis-understandings or omissions below] At the Berlin Summit SIG-K8s Working session [1] [2], we agreed to follow up with a note to the larger community summarizing our plan to enable Manila as RWX storage provider for k8s and other container orchestrators. Here it is :) Today there are kubernetes external service providers [3] [4] for Manila with NFS protocol back ends, as well as a way to use an external service provider on the master host in combination with a CSI CephFS node-host plugin [5]. We propose to target an end-to-end, multi-protocol Manila CSI plugin -- aiming at CSI 1.0, which should get support in container orchestrators early in 2019. Converging on CSI will: * provide support for multiple Container Orchestrators, not just k8s * de-couple storage plugin development from k8s life-cycle going forwards * unify development efforts and distributions and set clear expectations for operators and deployers Since manila needs to support multiple file system protocols such as CephFS native and NFS, we propose that work align to the multiplexing CSI architecture outlined here [6]. High level work plan: * Write master host multiplexing controller and node proxy plugins. * Use CephFS node-only plugin from [5] * Write NFS node-only plugin NFS and CephFS are immediate priorities - other file system protocols supported by manila can be added over time if there is interest. -- Tom Barron (irc: tbarron) [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22752/s… [2] https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit [3] https://github.com/kubernetes-incubator/external-storage [4] https://github.com/kubernetes/cloud-provider-openstack [5] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21997/d… [6] https://github.com/container-storage-interface/spec/issues/263#issuecomment…

1 0

[tc][python3] next steps for resolution on tracking python 3 releases
by Doug Hellmann 21 Nov '18

21 Nov '18

We currently have 3 changes up for review related to our python 3 testing plans. I think if we line them up in a series it will be clearer how they relate to each other and how we can move ahead with them as a set. I think first we need Zane's resolution [1], since that describes the process we want to use. We're dealing with some final wording questions there, but I think it's very close to ready as it is now. Next, we want Sean's patch that sets the versions we want tested for Stein [2]. Zane proposed that we should have goal champions designated in that change, so we could find someone to do that or we could go ahead and take it as-is and add that information later. Finally, we need a variation of Jeremy's patch that makes the PTI less detailed [3]. One update we could make there is to describe how to find (or link to) the information in the previous patch instead of using any specific versions at all. Thoughts? [1] https://review.openstack.org/#/c/613145/ [2] https://review.openstack.org/#/c/611080/ [3] https://review.openstack.org/#/c/611010/ -- Doug

2 1

OpenStack Summit Berlin Presentation Videos & Slides
by Jimmy McArthur 21 Nov '18

21 Nov '18

Thank you to everyone for a great OpenStack Summit last week in Berlin! As you know, there were hundreds of breakout sessions to catch last week. Videos from the keynote sessions are currently available here [1], and our team is working to get the other breakout session videos loaded as quickly as possible. We're currently expecting all videos to be posted by mid-December, and if we get them up sooner, I'll update this thread. In the meantime, you can watch the keynotes videos [2] and watch this page [3] for updates. Please also note that we sent out a link to all presenters to upload their slides. As they are uploaded, they can be found on the details page for each presentation on the Berlin Summit Schedule [3] (along with videos, as they are processed). Cheers, Jimmy [1] https://www.openstack.org/videos/summits/berlin-2018 [2] https://www.openstack.org/videos/ [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/

4 5