- openstack-discuss - lists.openstack.org

[nova] nova spec show-server-group response format
by yonglihe 26 Feb '19

26 Feb '19

Hi, guys The approved spec show-server-group had 2 options for response. 1. First one(current spec): "server": { "server_groups": [ # not cached "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" ] } } related discuss: https://review.openstack.org/#/c/612255/11/specs/stein/approved/show-server… digest: This decouple the current implementation of server groups then get a generic API. 2 Second one: "server": { "server_group": { "name": "groupA", "id": "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" } related discuss: https://review.openstack.org/#/c/612255/4/specs/stein/approved/list-server-… digest: people have tried to change the api to allow adding/removing servers to/from groups, but still not implement yet. we need align this for continuing this work. thanks. Reference: bp: https://blueprints.launchpad.net/nova/+spec/show-server-group spec: https://review.openstack.org/#/c/612255/13/specs/stein/approved/show-server… code: https://review.openstack.org/#/c/621474/23 Regards Yongli He

3 2

[openstack-helm] Initial spec for multiple container distribution support
by Pete Birley 26 Feb '19

26 Feb '19

Hi, One of the items that came up in the meeting this week was to get a spec together for supporting multiple distributions in containers managed via OpenStack-Helm. Currently, we ubiquitously use Ubuntu-based images, but would also like to support both CentOS and OpenSUSE in addition. As there's a lot to discuss here, I've created the following etherpad to allow us to work through these issues prior to the next meeting - at which point we should hopefully be at the point where we can start writing a formal spec. * https://etherpad.openstack.org/p/openstack-helm-container-distro-support Cheers Pete

1 0

[openstack-helm] Team Meeting (5th March 2019)
by Pete Birley 26 Feb '19

26 Feb '19

Hey! The next OpenStack-Helm meeting will be held on the 5th March, at 3pm UTC in #openstack-meeting-4 in freenode IRC. Thanks to all those who could attend the one we held on the 26th Feb: * the agenda we used is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-02-26 * the minutes logged here: http://eavesdrop.openstack.org/meetings/openstack_helm/2019/openstack_helm.… It would be great if people interested in OSH could attend, though we appreciate that's not possible, or desirable, for many. The agenda for the next meeting is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-03-05 please feel free to add to it, even if you cannot attend. Look forward to seeing you all either in IRC or here. Cheers Pete

1 0

[ops] ops meetups team meeting in 5 minutes - Berlin NEXT WEEK!
by Chris Morgan 26 Feb '19

26 Feb '19

Those of you interested or attending, please join us on #openstack-operators to have a final chat about next week's ops meetup in Berlin. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[nova][neutron][os-vif] upcoming release of os-vif
by Sean Mooney 26 Feb '19

26 Feb '19

hi everyone. As many people know the non-client lib freeze is thursday the 28th so it is time to do the final os-vif release for stein. there are a number of pending patches to os-vif https://review.openstack.org/#/q/project:openstack/os-vif+status:open+branc… while i think we can merge several of them i have sorted them into groups below. required: remove use of brctl from vif_plug_linux_bridge https://review.openstack.org/636822 remove use of brctl from vif_plug_linux_bridge https://review.openstack.org/636821 prefer to merge: Add native implementation OVSDB API https://review.openstack.org/482226 make functional tests run on python 3 https://review.openstack.org/638053 nice to have: modify functional base.py to allow using vscode https://review.openstack.org/638058 docs: Add API docs for VIF types https://review.openstack.org/637009 doc: Use sphinx.ext.todo for profile, datapath offload types https://review.openstack.org/638405 docs: Start using sphinx.ext.autodoc for VIF types https://review.openstack.org/638404 docs: Add API docs for profile, datapath offload types https://review.openstack.org/638395 defer: Add 'SUPPORT_BW_CONFIG' option to VIFs https://review.openstack.org/636933 the required patches are makeing there way though the gate. i would hope we can merge most of the patches in the prefer and nice to have buckets but my intent is to propose a patch to the release repo tonight with the head of master proably at or after 20:00 UTC which will be around noon PST. that will give eu and us folks that want to review these changes a resonably amount of time. ideally we can try and get the release out early tommorow. once that is done os-vif will go into a a feature freeze until RC1 is released of nova and neutron at which point it will unfreeze. once i submit the patch for the release until thursday i would like to do a full code freeze on os-vif so that if there are any bugs that show up in the gate we can fix those without accepting any other changes. once we pass the non-client lib freeze on thrusday non feature patches such as docs changes or testing changes are fine but features should wait to RC1. regards sean

2 2

Not able to collect cpu_util metric
by rahul gupta 26 Feb '19

26 Feb '19

Hi All, I have created a question here: https://answers.launchpad.net/ceilometer/+question/678802 Can you please respond. I have been scanning through all the web to get info regarding how can I calculate / read cpu_util metric. I am using devstack on latest *master*. Please let me know if you need any other details. Question Posted: I am trying to setup autoscale stack using open stack. I am having problem reading cpu_util value from the instances. Error: Feb 26 07:21:43 rgupta-op-stack ceilometer-polling[8197]: 2019-02-26 07:21:43.146 8476 DEBUG ceilometer.compute.pollsters [-] 6e982e28-4cb4-42b2-b608-be4ec4ce1d35/cpu_util volume: Unavailable _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:113 Feb 26 07:21:43 rgupta-op-stack ceilometer-polling[8197]: 2019-02-26 07:21:43.146 8476 WARNING ceilometer.compute.pollsters [-] cpu_util statistic in not available for instance 6e982e28-4cb4-42b2-b608-be4ec4ce1d35: NoVolumeException rgupta@rgupta-op-stack:~$ openstack --version openstack 3.17.0 rgupta@rgupta-op-stack:~$ openstack metric list | grep cpu | 70b2d180-6902-42b7-abaf-e34f89aafd2e | ceilometer-low | cpu | ns | 6e982e28-4cb4-42b2-b608-be4ec4ce1d35 | | fa3239df-9bfe-4cf4-a267-106f23fbcb0b | ceilometer-low | vcpus | vcpu | 5fce3174-40ab-484d-8da1-6ccbc8017cc6 | How do I add a new metric cpu_util to this list? Can someone point to a documentation with example. I have read through the metrics.yaml documentation but not sure how to see the parameters that are part of payload? Thanks Rahul

1 0

[requirements][requests] security update for requests in stable branches
by Matthew Thode 26 Feb '19

26 Feb '19

Recently it was reported to us that requests had a recent release that addressed a CVE (CVE-2018-18074). Requests has no stable branches so the only way to update openstack stable branches is to update to 2.20.1 in this case. I wanted to pass this by people as requests is generally a nasty library with nasty surprises. It's passed our cross and dvsm gating though (for rocky) so indications look good. What I'm asking you for is anything that could go wrong with updating (rocky in this case, but possibly back to newton, depending on co-installability). Please let me know any blockers to to update (in the review preferably). https://review.openstack.org/637124 Thanks, -- Matthew Thode

5 9

[charms] removal reminder
by Ryan Beisner 26 Feb '19

26 Feb '19

Hi All, This is a courtesy reminder that the following charm projects were deprecated [1], received final releases with the 18.11 OpenStack Charms Release, and will be removed prior to the Stein / 19.04 OpenStack Charms releases. [1] https://docs.openstack.org/charm-guide/latest/1811.html charm-glusterfs (unmaintained) charm-interface-odl-controller-api (unmaintained) charm-manila-glusterfs (unmaintained) charm-murano (unmaintained) charm-neutron-api-odl (unmaintained) charm-nova-compute-proxy (unmaintained) charm-odl-controller (unmaintained) charm-openvswitch-odl (unmaintained) charm-trove (unmaintained) Cheers, Ryan

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update XII - Feb 26, 2019
by Chandan kumar 26 Feb '19

26 Feb '19

Hello, Here is the 11th update (Feb 20 to Feb 26, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: * os_tempest got the support of enabling/disabling stackviz report generation It will help end-user to save them for generating stackviz report each time while testing locally. * If OVN is used always select tempest_private_net_provider_type to geneve while running os_tempest or tempest with different installer. Things got merged os_tempest * Revert "Only init a workspace if doesn't exists" - https://review.openstack.org/637801 * Add iputils to use the ping command - https://review.openstack.org/638189 * Fix redhat iputtils - https://review.openstack.org/638444 * Remove the private option from include_role - https://review.openstack.org/638557 * use tempest_run_stackviz to generate stackviz report - https://review.openstack.org/638360 tripleo * Set tempest_private_net_provider_type to geneve for os_tempest - https://review.openstack.org/637838 Things in progress: os_tempest * update depenencies for os_tempest: https://review.openstack.org/#/q/topic:os_tempest_deps+(status:open+OR+stat… * Enable heat support in os_tempest: https://review.openstack.org/#/q/topic:os_tempest_heat+(status:open+OR+stat… * Update workspace tempest.conf on changes - https://review.openstack.org/638014 Some interesting stuff coming: * since os_tempest is integrated with tripleo, now we have os_tempest playbook where we have more than 19 vars passed to os_tempest in order to run it. Where we are going to keep those vars so that end user can run it easily. Related reviews: * os_tempest - move deployment tool related vars to vars dir - https://review.openstack.org/639258 * tripleo - Standardize os_tempest playbook and set vars dynamically - https://review.openstack.org/639310 * whether to ship config_template action plugin as pypi deps - https://review.openstack.org/#/c/638383/ Feel free to join today's OSA meeting on #openstack-ansible channel at 16:00 UTC, we will try to get some interesting discussions. <https://wiki.openstack.org/wiki/Meetings/openstack-ansible> Thanks to cjloader (for iputils patch), arxcruz & jrosser on stackviz, evrardjp on config_template as os_tempest deps and cloudnull for always reviewing our patches. Here is the 11th 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-February/002860… Thanks, Chandan Kumar

1 0

[dev][qa][tempest-plugins] Fixing the setting and usage of service_availability config option in tempest plugins
by Ghanshyam Mann 26 Feb '19

26 Feb '19

HI All, After we split all the tempest plugins into the separate repo, service_available.<service-name> registration is in happening in the corresponding tempest plugins with default value as true. Example [1]. This leave service_available.<service-name> config options might have incorrect value and its incorrect usage when it is used in cross tempest plugin. Bugs[2] Recently Octavia-tempest-plugin faced the issue of duplicating the registration of same config option[3]. Previously Devstack used to set all the service_available config option which will be removed as devstack should be responsible to take care of 6 services only owned by Tempest and rest all goes on the service's devstack plugin side [4]. Current problem: 1. service_available.<service-name> default value is True and not set based on actual service availability. 2. tempest plugins need required tempest plugin to installed which register service_available.<service-name> config option but they are not in requirement.txt. To fix both problems, we need to do fixes in service and tempest plugin side. 1. Devstack should set only tempest own services - https://review.openstack.org/#/c/619973/ 2. each plugin to set their service as service_availability in their devstack plugin - In progress 3. Change the default value of service_available.<service> config option default value to false. 4. Add used tempest plugins in tempest plugins's requirements.txt after adding it in g-r. step#3 which change the config option default value from True to False will be done after step#2, to avoid any backward incompatible changes in term of skip the tests in any job. Third party CI reply on that default value has to set its value based on actual service availability check if they do not do currently. I am going to push the patches on service and plugin side, please let me know your opinion, feedback or any concern on this approach. [1] https://git.openstack.org/cgit/openstack/barbican-tempest-plugin/tree/barbi… [2] https://bugs.launchpad.net/congress/+bug/1743688 [3] https://bugs.launchpad.net/tripleo/+bug/1817154 [4] https://review.openstack.org/#/c/619973/ -gmann

1 0