- openstack-discuss - lists.openstack.org

[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

Let's use [dev] for development discussions
by Thierry Carrez 21 Nov '18

21 Nov '18

Hi openstack-discuss, As part of the ML merge, we introduced a number of subject prefixes to help subscribers filter discussions. The most important ones are to use: [dev] For discussions that are purely development-oriented [ops] For discussions that are purely operations-oriented Of course (as we have realized with the amount of cross-posted topics), most discussions benefit from input from all our contributors, whether they come from an development or an operational background. For those, there is no need to apply [dev] and/or [ops] prefixes, just try to be informative by adding the project name, team name or other information instead. You can ping specific populations by adding: [tc] Discussions of interest for TC members [uc] Discussions of interest for UC members [ptl] Discussions of interest for all PTLs [release] Release team, release liaisons and PTLs You can also specifically use (with care): [all] For discussions that should really be of interest to EVERYONE See (and add!) other common subject prefixes at: https://etherpad.openstack.org/p/common-openstack-ml-topics Thanks for your help in making this common list more navigable. -- Thierry Carrez (ttx)

5 7

[manila] no meeting this week
by Tom Barron 21 Nov '18

21 Nov '18

Just a reminder that there will be no manila community meeting this week. Next manila meeting will be Thursday, 29 November, at 1500 UTC in #openstack-meeting-alt on freenode. Agenda here [1] - Feel free to add ... -- Tom Barron (tbarron) [1] https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting

1 0

[openstack-dev] [neutron] [drivers] Cancelling weekly meeting on November 23rd
by Miguel Lavalle 21 Nov '18

21 Nov '18

Dear Neutron team, Due to the Thanksgiving Holiday in the USA, several members of the team will not be able to attend the weekly meeting. Let's cancel it and resume normally on the 30th of November Best regards Miguel __________________________________________________________________________ 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

1 0

[infra] [zuul] [placement] Minimizing size/time of test node
by Chris Dent 21 Nov '18

21 Nov '18

I have a work in progress to run a little job in placement that gathers very simple performance numbers on some queries. This is being done as a sort of sanity check. As with many such things it is a bit rough around the edges and I'd like to make it smoother in a variety of ways. The WIP is at https://review.openstack.org/#/c/602484/ One of the ways I'd like to change it is to not rely on devstack. I need only mysql, uwsgi, python and the current revision of placement on the node. The current job uses devstack-minimal as its base but that's overkill and slow. What is the correct base job to use which, as long as I put the files in the right place, will gather the logs I want? Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 5