- openstack-discuss - lists.openstack.org

[Openstack] [OpenStack][Keystone] the controller is node listening on port 5000
by Soheil Pourbafrani 25 Nov '18

25 Nov '18

Hi, I installed keystone step by step according to the OpenStack Doc <https://docs.openstack.org/keystone/rocky/install/keystone-install-rdo.html> but the http server is not listening on the port 5000! The only difference is my hostname (address) is "controller.a.b" instead of "controller". In verifying part of the document I could do all (like creating a user, project, ....) but after installing glance, I found out the Glance API is not running properly and it's because of Keystone is not listening on port 5000! Here are AUTH variables: export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=XXX export OS_AUTH_URL=http://controller.a.b:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 When I try "glance image-list", I got: "http://controller.a.b:9292/v2/images?limit=20&sort_key=name&sort_dir=asc: Unable to establish connection" Here is TCP listening ports: tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1614/master tcp 0 0 0.0.0.0:9191 0.0.0.0:* LISTEN 961/python2 tcp 0 0 0.0.0.0:25672 0.0.0.0:* LISTEN 957/beam.smp tcp 0 0 192.168.0.31:3306 0.0.0.0:* LISTEN 1622/mysqld tcp 0 0 192.168.0.31:2379 0.0.0.0:* LISTEN 963/etcd tcp 0 0 192.168.0.31:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 192.168.0.31:2380 0.0.0.0:* LISTEN 963/etcd tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 1/systemd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 953/sshd tcp6 0 0 ::1:25 :::* LISTEN 1614/master tcp6 0 0 :::5000 :::* LISTEN 960/httpd tcp6 0 0 :::5672 :::* LISTEN 957/beam.smp tcp6 0 0 ::1:11211 :::* LISTEN 952/memcached tcp6 0 0 :::80 :::* LISTEN 960/httpd tcp6 0 0 :::22 :::* LISTEN 953/sshd As you can see httpd is listening on port 5000 IPV6, but it's not active for IPV4! Here is keystone.log: 2018-11-24 15:55:59.685 17325 INFO keystone.common.wsgi [req-9fedd505-5d98-4c12-a6ad-967f28c766e7 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.275 17327 INFO keystone.common.wsgi [req-ca93da87-1d9f-4611-835c-d6972054b8e1 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.929 17328 INFO keystone.common.wsgi [req-cf8c6af8-342d-4b14-9826-ba27e5f2897a 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] GET http://controller.a.b:5000/v3/domains/default 2018-11-24 15:56:14.753 17325 INFO keystone.common.wsgi [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] POST http://controller.a.b:5000/v3/users 2018-11-24 15:56:14.773 17325 WARNING py.warnings [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] /usr/lib/python2.7/site-packages/oslo_policy/policy.py:896: UserWarning: Policy identity:create_user failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required warnings.warn(msg) Another difference between my system and document is that I use static IP and here are interface settings: TYPE="Ethernet" PROXY_METHOD="none" BROWSER_ONLY="no" BOOTPROTO="none" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_ADDR_GEN_MODE="stable-privacy" NAME="enp2s0" UUID="62aa5ce8-64da-41b4-abd3-293fd43584fa" DEVICE="enp2s0" ONBOOT="yes" IPADDR="192.168.0.X" PREFIX="24" GATEWAY="192.168.0.1" DNS1="192.168.0.1" DNS2="8.8.8.8" IPV6_PRIVACY="no" What can be the cause? _______________________________________________ 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

[oslo] [config] Using environment variables for config options
by Chris Dent 24 Nov '18

24 Nov '18

I don't recall seeing any specific announcement for this, and I think it is a pretty useful feature, so I thought I'd write about some functionality that I added to oslo.config and was released in 6.7.0. Especially since a lot of people I've mentioned this to thought we already had it. The new version is able to satisfy any registered config option by looking in the process environment for a variable with a predictable name and using its value if set. Options are satisfied in this order: * command line args * environment * config file(s) * everything else (using the new(ish) "sources" concept) In the past it was possible to get config from the environment if the option had been pre-defined as using something in the environment as its default. This new way is much more flexible, and in my experience ideal for container-based environments where you would like an immutable container but want small differences between multiple instances of the same container to be easy to control. Or if you don't need much config at all, you can avoid using a config file entirely. I've been using this with placement, where it's possible to set up a testable placement service with just two environment variables: OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret@127.0.0.1/placement?charset=utf8 OS_API__AUTH_STRATEGY=noauth2 This shows the pattern of the environment variable name: OS_<config group>__<config opt> There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module… I hope this proves as useful for other people as it has for me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[Openstack-operators] urlopen error [Errno 113] No route to host
by Jawad Ahmed 24 Nov '18

24 Nov '18

Hi all, Has anyone come across this error with utility container.I am running CentOS7 with Queens. After running setup-infrastructure.yml getting into this error while rest is success.Any workaround ? internal_lb_vip_address: 172.25.30.101 fatal: [rmq-db_utility_container-8e503460]: FAILED! => {"changed": false, "content": "", "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [Errno 113] No route to host>", "redirected": false, "status": -1, "url": " http://172.25.30.101:8181/os-releases/18.0.0/centos-7.5-x86_64/requirements… "} Thank you. -- Greetings, Jawad Ahmed _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

[forum] Summary of the "Better expose what we produce" session
by Thierry Carrez 24 Nov '18

24 Nov '18

Hi everyone, The OpenStack community produces a complex landscape of services and other deliverables. Presenting those to the rest of the world in a way that is comprehensive, makes sense and is not overwhelming has been a constant challenge. During this forum session in Berlin we presented the status of various efforts and websites, and discussed next steps. You can see the notes of the session at: https://etherpad.openstack.org/p/BER-better-expose-what-we-produce The plan going forward is to: 1. Continue improving the information presented on openstack.org/software and make more elements driven by the openstack/openstack-map repository YAML files. Immediate next steps include rolling out a new "Overview" page, providing an example YAML template, adding project update video links to the YAML for easier update, and finishing compiling "dependency" information from teams. We will also consider adding diagrams, although it creates a lot of consistency challenges. 2. Make the pages less about the teams and more about the software. That involves creating team pages (or enriching those from the governance website) and link to them instead of displaying information on the software page. 3. Brainstorm ways to move the "drivers list" (currently displayed in the "marketplace" using outdated data from stackalytics Drivers page) directly on the software page 4. For deployment tools, include data from the deployment tool comparison effort (discussed in another session), and consider making room for third-party tools as well. Also as a comparison point see https://kubernetes.io/docs/setup/pick-right-solution/ 5. For SDKs, include non-developed-locally language SDKs in a separate tab, and engage with the groups working on SDK certification / validation to see if there is any additional information we can show. Also as a comparison point see https://kubernetes.io/docs/reference/using-api/client-libraries/ Thanks ! -- Thierry Carrez (ttx)

4 3

Re: [Openstack-operators] Openstack zun on centos???
by Hongbin Lu 24 Nov '18

24 Nov '18

Hi Edoardo, It looks you gets your answer from others. I just want to add a few more comments. We (the Zun team) would like to have CentOS included in our installation guide and I have created a ticket for that: https://blueprints.launchpad.net/zun/+spec/installation-guide-for-centos . It will be picked up by contributors if someone interests to work on it. I expect the steps would be very similar as Ubuntu expect a few necessary tweaks. Right now, there is no Debian or RPM packages for Zun so we instruct users to install from source, which might be a bit painful. I would like to see Zun included in distro packages and I will see if we can recruit contributors to work on that, or I will work on that myself. Best regards, Hongbin On Wed, Nov 14, 2018 at 1:51 PM Ignazio Cassano <ignaziocassano(a)gmail.com> wrote: > Hi Edoardo, > does it mean openstack kolla installs zun using pip ? > I did not find any zun rpm package > Regards > Ignazio > > Il giorno Mer 14 Nov 2018 18:38 Eduardo Gonzalez <dabarren(a)gmail.com> ha > scritto: > >> Hi Cassano, you can use zun in centos deployed by kolla-ansible. >> >> https://docs.openstack.org/kolla-ansible/latest/reference/zun-guide.html >> >> Regards >> >> El mié., 14 nov. 2018 17:11, Ignazio Cassano <ignaziocassano(a)gmail.com> >> escribió: >> >>> Hi All, >>> I'd like to know if openstack zun will be released for centos. >>> Reading documentation at docs.openstack.org only ubuntu installation is >>> reported. >>> Many thanks >>> Ignazio >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators(a)lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

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

24 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 23 Nov '18

23 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 23 Nov '18

23 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 23 Nov '18

23 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