- openstack-discuss - lists.openstack.org

[Kolla] Queens for debian images
by Jan Vondra 09 Jan '19

09 Jan '19

Dear Kolla team, during project for one of our customers we have upgraded debian part of kolla project using a queens debian repositories (http://stretch-queens.debian.net/debian stretch-queens-backports) and we would like to share this work with community. I would like to ask what's the proper process of contributing since the patches affects both kolla and kolla-ansible repositories. Also any other comments regarding debian in kolla would be appriciated. Thanks, Jan Vondra Ultimum Technologies s.r.o. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic http://ultimum.io

5 9

[octavia] What is our next plan about 'l3-active-active' blueprint?
by Jeff Yang 09 Jan '19

09 Jan '19

Dear Octavia team: The email aims to ask the development progress about l3-active-active blueprint. I noticed that the work in this area has been stagnant for eight months. https://review.openstack.org/#/q/l3-active-active I want to know the community's next work plan in this regard. Thanks.

4 7

[Nova] Suggestion needed for detach-boot-volume design
by Zhenyu Zheng 08 Jan '19

08 Jan '19

Hi Nova, Happy New Year! I've been working on detach-boot-volume[1] in Stein, we got the initial design merged and while implementing we have meet some new problems and now I'm amending the spec to cover these new problems[2]. The thing I want to discuss for wider opinion is that in the initial design, we planned to support detach root volume for only STOPPED and SHELVED/SHELVE_OFFLOADED instances. But then we found out that we allowed to detach volumes for RESIZED/PAUSED/SOFT_DELETED instances as well. Should we allow detaching root volume for instances in these status too? Cases like RESIZE could be complicated for the revert resize action, and it also seems unnecesary. Thoughts? BR, [1] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/volum… [2] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/volum… Kevin Zheng

3 4

[Cyborg] IRC meeting
by Li Liu 08 Jan '19

08 Jan '19

The IRC meeting will be held Tuesday at 0300 UTC, which is 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) /11 am Beijing time (Wednesday) This week's agenda: 1. Review Sundar's feature branch 2. Review and try to merge CoCo's patches https://review.openstack.org/#/c/625630/ https://review.openstack.org/#/c/624138/ 3. Track status updates -- Thank you Regards Li

2 2

[scientific-sig] IRC meeting 2100UTC: Lustre, conferences, CFPs
by Stig Telfer 08 Jan '19

08 Jan '19

Hi All - We have a Scientific SIG meeting later today at 2100 UTC (about an hour’s time). Everyone is welcome. Today I’d like to restart the efforts for better integration of Lustre with OpenStack, and to canvas for people with use cases for this. Plus start the year with the conference calendar. We meet at 2100 UTC in IRC channel #openstack-meeting. The agenda and full details are here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_8th_2019 Cheers Stig

1 0

Queens octavia error
by Ignazio Cassano 08 Jan '19

08 Jan '19

Hello All, I installed octavia on queens with centos 7, but when I create a load balance with the command openstack loadbalancer create --name lb1 --vip-subnet-id admin-subnet I got some errors in octavia worker.log: 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server failures[0].reraise() 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/taskflow/types/failure.py", line 343, in reraise 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server six.reraise(*self._exc_info) 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server result = task.execute(**arguments) 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/octavia/controller/worker/tasks/compute_tasks.py", line 192, in execute 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server raise exceptions.ComputeBuildException(fault=fault) 2019-01-07 16:16:05.050 85077 ERROR oslo_messaging.rpc.server ComputeBuildException: Failed to build compute instance due to: {u'message': u'Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance 5abc100b-5dc8-43f5-9e1c-e6afea0242d9.', u'code': 500, u'details': u' File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 581, in build_instances\n raise exception.MaxRetriesExceeded(reason=msg)\n', u'created': u'2019-01-07T15:15:59Z'} Anyone could help me, please ? Regards Ignazio

2 2

[dev][keystone][nova][oslo] unified limits + oslo.limit interface questions
by Lance Bragstad 08 Jan '19

08 Jan '19

Hi all, Before the holidays there was a bunch of discussion around unified limits and getting that integrated into nova. One of the last hurdles is smoothing out the interface between nova and the oslo.limit library, which John and Jay were helping out with a bunch. There are a couple of WIP patches proposed that attempt to work through this [0][1][2]. Now that people are starting to recover from the holidays, I wanted to start a thread on what remains for this work. Specifically, what can we do to air out the remaining concerns so that we can release a useable version of oslo.limit for services to consume. Thoughts? [0] https://review.openstack.org/#/c/615180/ John's WIP'd integration patch [1] https://review.openstack.org/#/c/602201/ nova specification [2] https://review.openstack.org/#/c/596520/21 XiYuan's patch to sort out the interface from oslo.limit

1 0

Ironic ibmc driver for Huawei server
by xmufive＠qq.com 08 Jan '19

08 Jan '19

Hi julia, According to the comment of story<https://storyboard.openstack.org/#!/story/2004635 >, 1. The spec for huawei ibmc drvier has been post here: https://storyboard.openstack.org/#!/story/2004635 , waiting for review. 2. About the third-party CI part, we provide mocked unittests for our driver's code. Not sure what third-party CI works for in this case. What else we should do? Thanks Qianbiao.NG

2 1

[dev] 'sqlalchemy.exc.NoSuchTableError: migration_tmp' errors due to SQLite 3.26.0
by Stephen Finucane 08 Jan '19

08 Jan '19

Just to note that I'm currently unable to run nova unit tests locally on Fedora 29 without downgrading my sqlite package. The error I'm seeing is: sqlalchemy.exc.NoSuchTableError: migration_tmp The root cause appears to be a change in 3.26.0 which is breaking sqlalchemy-migrate, as noted here: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1807262 Corey Bryant has proposed the patch for this patch, linked below, which should resolve this. Any chance an sqlalchemy-migrate core could look at this before I reach the point of not being able to downgrade my sqlite package and run nova unit tests? :) https://review.openstack.org/#/c/623564/5 Stephen

1 0

[ansible-openstack] Magnum/Heat k8s failed
by Alfredo De Luca 08 Jan '19

08 Jan '19

Hi all. I have installed ansible-openstal AIO. Now I d like to create a cluster k8s but heat gives me always an error below: 2019-01-08 15:35:03Z [alf-k8s-nerea4mr3b2c.kube_masters]: *CREATE_IN_PROGRESS state changed* 2019-01-08 15:35:24Z [alf-k8s-nerea4mr3b2c.kube_masters]: *CREATE_FAILED AuthorizationFailure: resources.kube_masters.resources[0].resources.master_wait_handle: Authorization failed.* 2019-01-08 15:35:24Z [alf-k8s-nerea4mr3b2c]: CREATE_FAILED Resource CREATE failed: AuthorizationFailure: resources.kube_masters.resources[0].resources.master_wait_handle: Authorization failed. Any idea what to check? Cheers -- *Alfredo*

1 0

openstack queens octavia security group not found
by Ignazio Cassano 08 Jan '19

08 Jan '19

Hello everyone, I installed octavia with centos 7 queens. When I crreate a load balancer the amphora instance is not created because nova conductor cannot find the security group specified in octavia.conf. I am sure the security group id is correct but the nova condictor reports: 2019-01-08 09:06:06.803 11872 ERROR nova.scheduler.utils [req-75df2561-4bc3-4bde-86d0-40469058250c 62ed0b7f336b479ebda6f8587c4dd608 2a33760772ab4b0381a27735443ec4bd - default default] [instance: 83f2fd75-8069-47a5-9572-8949ec9b5cee] Error from last host: tst2-kvm02 (node tst2-kvm02): [u'Traceback (most recent call last):\n', u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1828, in _do_build_and_run_instance\n filter_properties, request_spec)\n', u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2108, in _build_and_run_instance\n instance_uuid=instance.uuid, reason=six.text_type(e))\n', u'RescheduledException: Build of instance 83f2fd75-8069-47a5-9572-8949ec9b5cee was re-scheduled: Security group fdd1ab71-bcd2-4b65-b5f2-f4c110b65602 not found.\n'] Please, what is wrong ? Regards Ignazio

2 16

Make tripleo-ci-fedora-28-standalone voting
by Felix Enrique Llorente Pastora 08 Jan '19

08 Jan '19

Hi All, The hibrid job to test fedora28 host and centos7 containers is working now and running tempest correctly (well it miss junit xml generation, but it's a matter of updating one RPM), so maybe is time for the job to be voting. What do you think? BR -- Quique Llorente Openstack TripleO CI

1 0

[loci] Release management for LOCI
by Thierry Carrez 08 Jan '19

08 Jan '19

Hi, loci folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it: 1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?) 2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it) 3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it) From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case. Thanks, -- Thierry Carrez (ttx)

4 7

[openstack-ansible]Enable DVR with routed network (Spine/Leaf)
by Cody 08 Jan '19

08 Jan '19

Hi OSA, Greetings! I wish to enable DVR in a routed network environment (i.e. a Leaf/Spine topology) using OSA. Has this feature been production ready under the OSA project? An example for the user_variables.yml and openstack_user_config.yml would be much appreciated. Thank you very much. Regards, Cody

2 1

[neutron] Functional tests job broken
by Slawomir Kaplonski 08 Jan '19

08 Jan '19

Hi Neutrinos, Since few days we have an issue with neutron-functional job [1]. Please don’t recheck Your patches now. It will not help until this bug will be fixed/workarouded. [1] https://bugs.launchpad.net/neutron/+bug/1810518 — Slawek Kaplonski Senior software engineer Red Hat

2 2

[tripleo][openstack-ansible] collaboration on os_tempest role update V - Jan 08, 2019
by Chandan kumar 07 Jan '19

07 Jan '19

Hello, Happy New Year all! Here is the first update (Dec, 19th, 18 to Jan 08, 19) of 2019 on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: * Update all plugin urls to use https rather than git - https://review.openstack.org/625670 * Remove octavia in favor of octavia-tempest-plugin - https://review.openstack.org/625828 * Add the manila-tempest-plugin - https://review.openstack.org/626181 * Added support for installing python-tempestconf from git - https://review.openstack.org/625904 * Use tempest_tempestconf_profile for handling named args - https://review.openstack.org/623187 * Use tempest_cloud_name for setting cloudname - https://review.openstack.org/628610 python-tempestconf * Add profile argument - https://review.openstack.org/621567 * Add unit test for profile feature - https://review.openstack.org/626889 * Fixed SafeConfigParser deprecation warning for py3 - https://review.openstack.org/628130 * Fix diff in gates - https://review.openstack.org/628180 * Added python-tempestconf-tempest-devstack-admin/demo-py3 - https://review.openstack.org/622865 Summary: * On os_tempest side, we have finished the python-tempestconf support and introduced tempest_cloud_name var in order to set cloud name from clouds.yaml for tempest tests. * python-tempestconf got --profile feature and added py3 based devstack jobs. Note: when we use tempest run --subunit It always return exit status 0, It is the desired behaviour of stestr [https://github.com/mtreinish/stestr/issues/210] The docs are now getting updated. We are working on implementing tempest last subcommand [https://review.openstack.org/#/c/511172/]related to the same. Things In-progress: os_tempest * Better tempest black and whitelist management - https://review.openstack.org/621605 * Add support for aarch64 images - https://review.openstack.org/620032 * Fix tempest workspace path - https://review.openstack.org/628182 * Configuration drives don't appear to work on aarch64+kvm - https://review.openstack.org/626592 * Use the inventory to enable/disable services by default - https://review.openstack.org/628979 * Synced tempest plugins names and services - https://review.openstack.org/628926 python-tempestconf * Create functional-tests role - https://review.openstack.org/626539 * Enable manila plugin in devstack - https://review.openstack.org/625191 Apart from this we have started working on integrating os_tempest with devstack and Tripleo standalone job. * Devstack - https://review.openstack.org/627482 * Tripleo CI - https://review.openstack.org/627500 We will try to finish os_tempest docs cleanup, whitelist/Blacklist tests management and os_tempest integration specs. I would like to thanks mkopec, arxcruz, cloudnull (reviewing patches in holidays), mnaser, jrosser, odyssey4me, marios & quiquell (from tripleo CI team on helping on os_tempest integration with Tripleo CI). Here is the 4th 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/2018-December/001116… Thanks, Chandan Kumar

1 0

[openstack-ansible]Enable DVR support with routed network (L3 spine)
by Cody 07 Jan '19

07 Jan '19

Hi OSA, Greetings! I wish to enable DVR in a routed network environment (i.e. a Leaf/Spine topology) using OSA. Has this feature been production ready under the OSA project? An example for the user_variables.yml would be great. Thank you very much. Regards, Cody

1 0

[goal][python3] week R-13 update
by Doug Hellmann 07 Jan '19

07 Jan '19

This is the weekly update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html) == Ongoing and Completed Work == This week is the second milestone for the Stein cycle. By this point I hoped to have python 3 functional test jobs in place for all projects, but we still have quite a ways to go to achieve that. I have added a few missing projects to the wiki page [1] and there is a *lot* of red on that page. I count 21 projects without functional test jobs running under python 3. We also have a few projects who don't seem to have voting python 3 unit test jobs, still. [1] https://wiki.openstack.org/wiki/Python3#Other_OpenStack_Applications_and_Pr… Now that folks are mostly back from the holidays, my patch to change the default version of python in devstack [2] is ready for approval. See the other thread on this list [3] for details. [2] https://review.openstack.org/#/c/622415/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001356.… == Next Steps == PTLs, please review the information for your projects on that page. If you have a functional test job, please update that part of the table with the name of the job. If you do not have a functional test job, please add any information you have about plans to implement one (blue prints, bugs, etc.) to the comments column in the table. == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Ve… 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug

1 0

[nova] Persistent memory resource tracking model
by Rui Zang 07 Jan '19

07 Jan '19

5 10

[neutron] Bug deputy report - week 1 2019
by Slawomir Kaplonski 07 Jan '19

07 Jan '19

Hi Neutrios, I was bug deputy last week. Below is summary of bugs reported this week: Critical bugs: * https://bugs.launchpad.net/neutron/+bug/1810314 - neutron objects base get_values() fails with KeyError - I marked it as Critical because it cause gate failures for Tricircle project, there is patch proposed for that https://review.openstack.org/#/c/628857/ but some OVO expert should take a look at it, * https://bugs.launchpad.net/neutron/+bug/1810518 - neutron-functional tests failing with oslo.privsep 1.31 - set to Critical as it cause gate failures, Ben Nemec is looking at it from oslo.privsep side. I found that all problems are caused by tests from neutron.tests.functional.agent.linux.test_netlink_lib.NetlinkLibTestCase so maybe if someone familiar with this code in Neutron can take a look at it too. High bugs: * https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins - I set it to High - it looks that we now require proper order of service plugins in config file, it is in progress, LIU Yulong is working on it. We also discussed that on last L3 sub team meeting. * https://bugs.launchpad.net/neutron/+bug/1810504 - neutron-tempest-iptables_hybrid job failing with internal server error while listining ports - set to High as it cause gate failures from time to time, patch proposed already: https://review.openstack.org/#/c/628492/ * https://bugs.launchpad.net/neutron/+bug/1810764 - XenServer cannot enable tunneling - this is fresh bug from today, I set it to High and it needs attention from someone familiar with Xenserver, Other bugs: * https://bugs.launchpad.net/neutron/+bug/1810025 - ovs-agent do not clear QoS rules after restart - in progress, I set it to Medium, patch proposed https://review.openstack.org/#/c/627779/ * https://bugs.launchpad.net/neutron/+bug/1810349 - agent gw ports created on non dvr destination hosts - DVR related issue, I set it to Medium - patch proposed: https://review.openstack.org/628071 * https://bugs.launchpad.net/neutron/+bug/1810563 - adding rules to security groups is slow - set to Medium, patch proposed https://review.openstack.org/628691 — Slawek Kaplonski Senior software engineer Red Hat

1 0

[Ops] ops meetups team meeting 2018-12-18
by Chris Morgan 07 Jan '19

07 Jan '19

Meeting minutes from our meeting today on IRC are linked below. Key points: - next meeting Jan 8th 2019 - ops meetup #1 looks likely to be at Deutsche Telekom, Berlin, March 7,8 2019 - the team hopes to confirm this soon and commence technical agenda planning early January - team meetings will continue to be 10AM EST Tuesdays on #openstack-operators Meeting ended Tue Dec 18 15:44:05 2018 UTC. 10:44 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… About the OpenStack Operators Meetups team: https://wiki.openstack.org/wiki/Ops_Meetups_Team Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

[nova] implementation options for nova spec: show-server-numa-topology
by yonglihe 06 Jan '19

06 Jan '19

Hi, guys This spec needs input and discuss for move on. Currently the spec is under reviewing: https://review.openstack.org/#/c/612256/8 Plus with POC code: https://review.openstack.org/#/c/621476/3 and related stein PTG discuss: https://etherpad.openstack.org/p/nova-ptg-stein start from line 897 NUMA topology had lots of information to expose, for saving you time to jumping into to the spec, the information need to return include NUMA related like: numa_node,cpu_pinning,cpu_thread_policy,cpuset,siblings, mem,pagesize,sockets,cores, threads, and PCI device's information. Base on IRC's discuss, we may have 3 options about how to deal with those blobs: 1) include those directly in the server response details, like the released POC does: https://review.openstack.org/#/c/621476/3 2) add a new sub-resource endpoint to servers, most likely use key word 'topology' then: "GET /servers/{server_id}/topology" returns the NUMA information for one server. 3) put the NUMA info under existing 'diagnostics' API. "GET /servers/{server_id}/diagnostics" this is admin only API, normal user loss the possible to check their topology. when the information put into diagnostics, they will be look like: { .... "numa_topology": { cells [ { "numa_node" : 3 "cpu_pinning": {0:5, 1:6}, "cpu_thread_policy": "prefer", "cpuset": [0,1,2,3], "siblings": [[0,1],[2,3]], "mem": 1024, "pagesize": 4096, "sockets": 0, "cores": 2, "threads": 2, }, ... ] # cells } "emulator_threads_policy": "share" "pci_devices": [ { "address":"00:1a.0", "type": "VF", "vendor": "8086", "product": "1526" }, ] } Regards Yongli He

3 8

[murano]Retire of murano-deployment project
by Rong Zhu 06 Jan '19

06 Jan '19

Hi, teams, Murano-deployment project is the third-party CI scripts and automatic tools. Since the third-party CI have already switched to openstack CI, this project doesn't need anymore. So we decided to retire murano-deployment project. Thanks, Rong Zhu -- Thanks, Rong Zhu

1 0

Ironic ibmc driver for Huawei server
by qianbiao.ng＠turnbig.net 05 Jan '19

05 Jan '19

Hi julia, According to the comment of story<https://storyboard.openstack.org/#!/story/2004635 >, 1. The spec for huawei ibmc drvier has been post here: https://storyboard.openstack.org/#!/story/2004635 , waiting for review. 2. About the third-party CI part, we provide mocked unittests for our driver's code. Not sure what third-party CI works for in this case. What else we should do? Thanks Qianbiao.NG

1 0

[docs] question about deprecation badges
by Adam Spiers 04 Jan '19

04 Jan '19

Hi all, I'm currently hacking on the deprecation badges in openstack-manuals, and there's a couple of things I don't understand. Any chance someone could explain why www/latest/badge.html doesn't just do: {% include 'templates/deprecated_badge.tmpl' %} like all the others? https://github.com/openstack/openstack-manuals/commit/961f544a4ec383d8b500a… I'm also what exactly would be wrong with the included CSS path if CSSDIR was used in www/templates/deprecated_badge.tmpl instead of heeding this caveat: https://github.com/openstack/openstack-manuals/commit/961f544a4ec383d8b500a… It would be good to fix it to use CSSDIR because currently it's awkward to test CSS changes. Thanks! Adam

2 3

Re: [octavia] What is our next plan about 'l3-active-active' blueprint?
by Jeff Yang 04 Jan '19

04 Jan '19

I have no new specs, I plan to follow the original blueprint. https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/acti… Jeff Yang <yjf1970231893(a)gmail.com> 于2019年1月5日周六下午12:16写道： > I have no new specs, I plan to follow the original blueprint. > > https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/acti… > > Sa Pham <saphi070(a)gmail.com> 于2019年1月5日周六上午11:58写道： > >> Hi Jeff, >> >> Do you have design and specs for that. >> >> >> Best, >> >> Sa Pham Dang >> Cloud RnD Team - VCCLOUD >> Phone: 0986849582 >> Skype: great_bn >> >> On Jan 5, 2019, at 10:29 AM, Jeff Yang <yjf1970231893(a)gmail.com> wrote: >> >> Yes, I want to reboot this work recently. And, I want to replace >> exabgp with >> os-ken, So I may need to rewrite some patches. >> >> Michael Johnson <johnsomor(a)gmail.com> 于2019年1月5日周六上午8:02写道： >> >>> Hi Jeff, >>> >>> Unfortunately the team that was working on that code had stopped due >>> to internal reasons. >>> >>> I hope to make the reference active/active blueprint a priority again >>> during the Train cycle. Following that I may be able to look at the L3 >>> distributor option, but I cannot commit to that at this time. >>> >>> If you are interesting in picking up that work, please let me know and >>> we can sync up on that status of the WIP patches, etc. >>> >>> Michael >>> >>> On Thu, Jan 3, 2019 at 11:19 PM Jeff Yang <yjf1970231893(a)gmail.com> >>> wrote: >>> > >>> > Dear Octavia team: >>> > The email aims to ask the development progress about >>> l3-active-active blueprint. I >>> > noticed that the work in this area has been stagnant for eight months. >>> > https://review.openstack.org/#/q/l3-active-active >>> > I want to know the community's next work plan in this regard. >>> > Thanks. >>> >>

1 0

Per-VM CPU & RAM allocation?
by Ken D'Ambrosio 04 Jan '19

04 Jan '19

Hi! If I go into the UI, I can easily see how much each VM is allocated for RAM and CPU. However, I've googled until I'm blue in the face, and can't seem to see a way -- either through CLI or API -- to get that info. "nova limits --tenant <foo>" SEEMS like it should... except (at least on my Juno cloud), the "used" column is either full of zeros or dashes. Clearly, if it's in the UI, it's possible... somehow. But it seemed like it might be easier to ask the list than go down the rabbit hole of tcp captures. Any ideas? Thanks! -Ken P.S. Not interested in CPU-hours/usage -- I'm just looking for how much is actually allocated.

3 2

Update on gate status for the new year
by Clark Boylan 04 Jan '19

04 Jan '19

I'm still not entirely caught up on everything after the holidays, but thought I would attempt to do another update on gate reliability issues since those were well received last month. Overall things look pretty good based on elastic-recheck data. That said I think this is mostly due to low test volume over the holidays and our 10 day index window. We should revisit this next week or the week after to get a more accurate view of things. On the infra team side of things we've got quota issues in a cloud region that has decreased our test node capacity. Waiting on people to return from holidays to take a look at that. We also started tracking hypervisor IDs for our test instances (thank you pabelanger) to try and help identify when specific hypervisors might be the cause of some of our issues. https://review.openstack.org/628642 is a followup to index that data with our job log data in Elasticsearch. We've seen some ssh failures in tripleo jobs on limestone [0] and neutron and zuul report constrained IOPS there resulting in failed database migrations. I think the idea with 628642 is to see if we can narrow that down to specific hypervisors. On the project side of things our categorization rates are quite low [1][2]. If your changes are evicted from the gate due to failures it would be helpful if you could spend a few minutes to try and identify and fingerprint those failures. We'll check back in a week or two when we should have a much better data set to look at. [0] http://status.openstack.org/elastic-recheck/index.html#18100542 [1] http://status.openstack.org/elastic-recheck/data/integrated_gate.html [2] http://status.openstack.org/elastic-recheck/data/others.html Clark

2 1

[cinder] Addition mid-cycle details ...
by Jay Bryant 04 Jan '19

04 Jan '19

Team, We are at about a month away from the Cinder Mid-Cycle in Raleigh. I have started requesting drinks/snacks and have rooms reserved. I soon will need a firm number of people attending so that I can finalize the various requests. If you are planning to physically attend and have not yet added your name to our planning etherpad [1] please do so ASAP. I have reserved a room at the Hyatt House Raleigh Durham Airport (10962 Chapel Hill Road, Morrisville, NC, 27560, USA ) <http://maps.google.com/?q=loc:35.85501,-78.8407> if people want to stay at the same hotel as myself. It is close to the Lenovo site which will make it easier to travel if we have unexpected snowy weather there. We can also carpool to reduce the problem of finding parking. I am arriving the afternoon of 2/4/19 and leaving the morning of 2/9/19. Also a reminder to please add topics to the mid-cycle planning etherpad regardless of whether you are able to attend or not. Look forward to seeing you in Raleigh next month! Jay (jungleboyj) [1] https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning

1 0

[all] One month with openstack-discuss (a progress report)
by Jeremy Stanley 04 Jan '19

04 Jan '19

First, I want to thank everyone here for the remarkably smooth transition to openstack-discuss at the end of November. It's been exactly one month today since we shuttered the old openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists and forwarded all subsequent posts for them to the new list address instead. The number of posts from non-subscribers has dwindled to the point where it's now only a few each day (many of whom also subscribe immediately after receiving the moderation autoresponse). As of this moment, we're up to 708 subscribers. Unfortunately it's hard to compare raw subscriber counts because the longer a list is in existence the more dead addresses it accumulates. Mailman does its best to unsubscribe addresses which explicitly reject/bounce multiple messages in a row, but these days many E-mail addresses grow defunct without triggering any NDRs (perhaps because they've simply been abandoned, or because their MTAs just blackhole new messages for deleted accounts). Instead, it's a lot more concrete to analyze active participants on mailing lists, especially since ours are consistently configured to require a subscription if you want to avoid your messages getting stuck in the moderation queue. Over the course of 2018 (at least until the lists were closed on December 3) there were 1075 unique E-mail addresses posting to one of more of the openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists. Now, a lot of those people sent one or maybe a handful of messages to ask some question they had, and then disappeared again... they didn't really follow ongoing discussions, so probably won't subscribe to openstack-discuss until they have something new to bring up. On the other hand, if we look at addresses which sent 10 or more messages in 2018 (an arbitrary threshold admittedly), there were 245. Comparing those to the list of addresses subscribed to openstack-discuss today, there are 173 matches. That means we now have *at least* 70% of the people who sent 10 or more messages to the old lists subscribed to the new one. I say "at least" because we don't have an easy way to track address changes, and even if we did that's never going to get us to 100% because there are always going to be people who leave the lists abruptly for various reasons (perhaps even disappearing from our community entirely). Seems like a good place to be after only one month, especially considering the number of folks who may not have even been paying attention at all during end-of-year holidays. As for message volume, we had a total of 912 posts to openstack-discuss in the month of December; comparing to the 1033 posts in total we saw to the four old lists in December of 2017, that's a 12% drop. Consider, though, that right at 10% of the messages on the old lists were duplicates from cross-posting, so that's really more like a 2% drop in actual (deduplicated) posting volume. It's far less of a reduction than I would have anticipated based on year-over-year comparisons (for example, December of 2016 had 1564 posts across those four lists). I think based on this, it's safe to say the transition to openstack-discuss hasn't hampered discussion, at least for its first full month in use. -- Jeremy Stanley

5 4

[openstack-dev] [neutron] Changing the meeting channel for Neutron upgrades weekly meeting
by Miguel Lavalle 04 Jan '19

04 Jan '19

Lujin and Nate and Neutrinos, Please be aware that the meeting room for the Neutron upgrades channel is being changed: https://review.openstack.org/#/c/626182. due to infra optimization. Cheers Miguel

1 0

[goals][upgrade-checkers] Week R-14 Update
by Matt Riedemann 04 Jan '19

04 Jan '19

There has not been much progress since the R-16 update [1] let's assume because of the holiday break. There is a new trove patch which replaces the placeholder check with a real upgrade check [2]. I have left comments on that review. I am not sure if that is due to some new changes in trove which require the upgrade check, or if this is just something that has always been needed when upgrading trove. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001266… [2] https://review.openstack.org/#/c/627555/ -- Thanks, Matt

1 0

[placement] update 19-00
by Chris Dent 04 Jan '19

04 Jan '19

HTML: https://anticdent.org/placement-update-19-00.html Welcome to the first placement update of 2019. May all your placements have sufficient resources this year. # Most Important A few different people have mentioned that we're approaching crunch time on pulling the trigger on deleting the placement code from nova. The week of the 14th there will be a meeting to iron out the details of what needs to be done prior to that. If this is important to you, watch out for an announcement of when it will be. This is a separate issue from putting placement under its own governance, but some of the requirements [declared](http://lists.openstack.org/pipermail/openstack-dev/2018-September… for that, notably a deployment tool demonstrating an upgrade from placement-in-nova to placement-alone, are relevant. Therefore, reviewing and tracking the deployment tool related work remains critical. Those are listed below. Also, it is spec freeze next week. There are quite a lot of specs that are relevant to placement and scheduling that are close, but not quite. Mel has sent out [an email](http://lists.openstack.org/pipermail/openstack-discuss/2019-January/… about which specs most need attention. # What's Changed * There's an [os-resource-classes](https://pypi.org/p/os-resource-classes) now, already merged in placement, with a change posted [for nova](https://review.openstack.org/#/c/628278/). It's effectively the same as os-traits, but for resource classes. * There's a release of a 0.1.0 of placement [pending](https://review.openstack.org/628400). This won't have complete documentation, but will mean that there's an actually usable openstack-placement on PyPI, with what we expect to be the final python module requirements. * This has been true for a while, but it seems worth mentioning, via coreycb: "you can install placement-api on bionic with the stein cloud archive enabled". * A `db stamp` command has been added to `placement-manage` tool which makes it possible for someone who has migrated their data from nova to say "I'm at version X". * placement functional tests have been removed from nova. * Matt did a mess of work to make initializing the scheduler report client in nova less expensive and redundant. * Improving the handling of [allocation ratios](https://docs.openstack.org/nova/latest/admin/configuration/schedule… has merged, allowing for "initial allocation ratios". # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 15. -2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 15. +2 # Specs Spec freeze next week! Only one of the previously listed specs has merged since early December and a new one has been added (at the end). * <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/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. * <https://review.openstack.org/#/c/609960/> Support filtering of allocation_candidates by forbidden aggregates * <https://review.openstack.org/601596> support virtual persistent memory # Main Themes ## Making Nested Useful Progress continues on gpu-reshaping for libvirt and xen: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Also making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> There's a [review guide](http://lists.openstack.org/pipermail/openstack-discuss/2018-December… for those patches. Eric's in the process of doing lots of cleanups 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/615677> ## Extraction The [extraction etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) is starting to contain more strikethrough text than not. Progress is being made. I'll refactor that soon so it is more readable, before the week of the 14th meeting. The main tasks are the reshaper work mentioned above and the work to get deployment tools operating with an extracted placement: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla and Kolla Ansible](https://review.openstack.org/#/q/topic:split-placement) Loci's change to have an extracted placement has merged. Kolla has a patch to [include the upgrade script](https://review.openstack.org/#/q/topic:upgrade-placement). It raises the question of how or if the `mysql-migrate-db.sh` should be distributed. Should it maybe end up in the pypi distribution? Documentation tuneups: * 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…, to that end: * <https://review.openstack.org/#/c/628183/> A stack of changes to nova to remove placement from the install docs. * <https://review.openstack.org/#/c/628220/> Install docs in placement. I wrote to the [mailing list](http://lists.openstack.org/pipermail/openstack-discuss/2019-January/0… asking for input on making sure these things are close to correct, especially with regard to distro-specific things like package names. * <https://review.openstack.org/#/c/628324> Change to openstack-manuals to assert that placement is publishing install docs. Depends on the above. * There is a patch to [delete placement](https://review.openstack.org/#/c/618215/) from nova that we've put an administrative -2 on while we determine where things are (see about the meeting above). * There's a pending patch to support [online data migrations](https://review.openstack.org/#/c/624942/). This is important to make sure that fixup commands like `create_incomplete_consumers` can be safely removed from nova and implemented in placement. # Other There are currently 13 [open changes](https://review.openstack.org/#/q/project:openstack/placement+statu… in placement itself. Most of the time critical work is happening elsewhere (notably the deployment tool changes listed above). Of those placement changes, the [database-related](https://review.openstack.org/#/q/owner:nakamura.tetsuro%2… ones from Tetsuro are the most important. Outside of placement: * <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/#/c/621645/> WIP: add Placement aggregates tests (in tempest) * <https://review.openstack.org/627326> blazar: Consider the number of reservation inventory * <https://review.openstack.org/622316> Add placement client for basic GET operations (to tempest) # End Lot's of good work in progress. Our main task is making sure it all gets review and merged. The sooner we do, the sooner people get to use it and find all the bugs we're sure to have left lying around. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[oslo] Problem when use library "oslo.messaging" for HA Openstack
by Thành Nguyễn Bá 04 Jan '19

04 Jan '19

Dear all, I have a problem when use 'notification listener' oslo-message for HA Openstack. It raise 'oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 172.16.4.125:5672 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'false' but current is 'true''. How can i fix this?. I think settings default in my program set 'durable' is False so it can't listen RabbitMQ Openstack? This is my nova.conf > http://paste.openstack.org/show/738813/ And section [oslo_messaging_rabbit] [oslo_messaging_rabbit] > rabbit_ha_queues = true > rabbit_retry_interval = 1 > rabbit_retry_backoff = 2 > amqp_durable_queues= true *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu(a)gmail.com

3 4

Openstack CLI using a non-zero return code for successful command.
by Rafael Weingärtner 04 Jan '19

04 Jan '19

Hello OpenStackers, I have been using "openstack" CLI for a while now, and for most of the commands (the ones I used so far), when it is successful, I receive a return code (RC) 0 (ZERO). However, when using the command "openstack federation protocol set --identity-provider <idP> --mapping <mappingName> <protocol>", I am getting an RC 1 (ONE) as the exit code for successful executions as well. Is this a known bug? -- Rafael Weingärtner

1 0

[nova][dev] tracking spec reviews ahead of spec freeze
by melanie witt 04 Jan '19

04 Jan '19

Hey all, Spec freeze is coming up shortly after the holidays on January 10, 2019. Since we don't have much time after returning to work next year before spec freeze, let's keep track of specs that are close to approval or otherwise candidates to focus on in the last stretch before freeze. Here's an etherpad where I've collected a list of possible candidates for focus the first week of January. Feel free to add notes and specs I might have missed: https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze Cheers, -melanie

2 3

[nova][ops] Trying to get per-instance live migration timeout action spec unstuck
by Matt Riedemann 04 Jan '19

04 Jan '19

I'm looking at this (previously approved [1]) spec again [2] and trying to sort out what needs to happen to reach agreement on this feature. Note the dependent blueprint is now complete in Stein [3]. The idea is pretty simple: provide new parameters to the live migration API to (1) override [libvirt]/live_migration_completion_timeout [4] and/or (2) provide a timeout action in case the provided (or configured) timeout is reached which would override [libvirt]/live_migration_timeout_action [5]. The use case is also pretty simple: you can have a default timeout and action (abort) configured but there could be cases where you need to override that on a per-instance basis to move a set of VMs off a host for maintenance, so you want to tell nova to force complete (post-copy or pause) in case of a timeout. The abort and force-complete actions are the same as in the API ([6] and [7] respectively). There are two main sticking points against this in the review: 1. This can already be done using existing APIs (as noted) client-side if monitoring the live migration and it times out for whatever you consider a reasonable timeout at the time. 2. The libvirt driver is the only one that currently supports abort and force-complete. For #1, while valid as a workaround, is less than ideal since it would mean having to orchestrate that into any tooling that needs that kind of workaround, be that OSC, openstacksdk, python-novaclient, gophercloud, etc. I think it would be relatively simple to pass those parameters through with the live migration request down to nova-compute and have the parameters override the config options and then it's natively supported in the API. For #2, while also true, I think is not a great reason *not* to support per-instance timeouts/actions in the API when we already have existing APIs that do the same thing and have the same backend compute driver limitations. To ease this, I think we can sort out two things: a) Can other virt drivers that support live migration (xenapi, hyperv, vmware in tree, and powervm out of tree) also support abort and force-complete actions? John Garbutt at least thought it should be possible for xenapi at the Stein PTG. I don't know about the others - driver maintainers please speak up here. The next challenge would be getting driver maintainers to actually add that feature parity, but that need not be a priority for Stein as long as we know it's possible to add the support eventually. b) There are pre-live migration checks that happen on the source compute before we initiate the actual guest transfer. If a user (admin) specified these new parameters and the driver does not support them, we could fail the live migration early. This wouldn't change the instance status but the migration would fail and an instance action event would be recorded to explain why it didn't work, and then the admin can retry without those parameters. This would shield us from exposing something in the API that could give a false sense of functionality when the backend doesn't support it. Given all of this, are these reasonable compromises to continue trying to drive this feature forward, and more importantly, are other operators looking to see this functionality added to nova? Huawei public cloud operators want it because they routinely are doing live migrations as part of maintenance activities and want to be able to control these values per-instance. I assume there are other deployments that would like the same. If this is something you'd like to see move forward, please speak up soon since the nova spec freeze for Stein is January 10. [1] https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-m… [2] https://review.openstack.org/#/c/600613/ [3] https://blueprints.launchpad.net/nova/+spec/live-migration-force-after-time… [4] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.li… [5] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.li… [6] https://developer.openstack.org/api-ref/compute/?expanded=#delete-abort-mig… [7] https://developer.openstack.org/api-ref/compute/?expanded=#force-migration-… -- Thanks, Matt

5 9

[openstack-dev] [neutron] Cancelling Neutron drivers meeting on January 4th
by Miguel Lavalle 03 Jan '19

03 Jan '19

Hi Neutrinos, Today I spent time triaging RFEs. I posted comments and questions in several of them in order to get them in good shape to be discussed by the Drivers team. None are ready to be discussed, though. As a consequence. I am cancelling the meeting on January 4th. Best regards Miguel

1 0

[loci] Loci Meeting for January 3, 2019
by Chris Hoge 03 Jan '19

03 Jan '19

On Friday, January 3 we will resume our Loci team meetings at 7 AM PT/ 15 UTC after an extended end-of-year break. We will revisit our plan for building stable branches (in light of several failures to build stable branches on a few distributions because of requirements failures), coming up with a more robust testing strategy, and planning new development priorities for the remainder of the cycle. Thanks, Chris https://etherpad.openstack.org/p/loci-meeting

1 1

[tripleo] OVB stable/1.0 branch created
by Ben Nemec 03 Jan '19

03 Jan '19

Just a quick update on the status of OVB. There's some discussion on [1] about how to handle importing it to Gerrit, and it looks like we first want to wrap up the 2.0-dev feature branch so we don't have to mess with that after import. As a result, I've cut the stable/1.0 branch from current OVB master. Anyone who's not ready to try out 2.0 should start pointing at stable/1.0 instead of master as the 2.0-dev branch will soon be merged back to master. This will leave us with a branch structure that better matches most other OpenStack projects. We should probably give consumers some time to get switched over, but it sounds like TripleO CI already pins to a specific commit in OVB so it may not affect that. Once a little time has passed we can do the 2.0-dev merge and proceed with the import. I also made a wordier blog post about this[2]. Let me know if you have any feedback. Thanks. -Ben 1: https://review.openstack.org/#/c/620613/ 2: http://blog.nemebean.com/content/openstack-virtual-baremetal-import-plans

2 1

[tripleo] Scenario Standalone ci jobs update - voting and promotion pipeline
by Marios Andreou 03 Jan '19

03 Jan '19

o/ TripleO's & Happy New Year \o/ if you are tracking the ci squad you may know that one area of focus recently is moving the scenario-multinode jobs to harder/better/faster/stronger (most importantly *smaller* but not as cool) scenario-standalone equivalents. Scenarios 1-4 are now merged [1]. For the current sprint [2] ci squad is doing cleanup on those. This includes making sure the new jobs are used in all the places the multinode jobs were e.g.[3][4] (& scens 2/3 will follow) and fixing any missing services or any other nits we find. Once done we can move on to the rest - scenarios 5/6 etc. We are looking for any feedback about the jobs in general or any one in particular if you have some special interest in a particular service (see [5] for reminder about services and scenarios). Most importantly those jobs are now being set as voting (e.g. already done for 1/4 at [1]) and the next natural step once voting is to add them into the master promotion pipeline. Please let us know if you think this is a bad idea or with any other feedback or suggestion. regards &thanks for reading! marios [1] https://github.com/openstack-infra/tripleo-ci/blob/3d634dc2874f95a9d4fd97a1… [2] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-3 [3] https://review.openstack.org/#/q/topic:replace-scen1 [4] https://review.openstack.org/#/q/topic:replace-scen4 [5] https://github.com/openstack/tripleo-heat-templates#service-testing-matrix

3 2

[neutron] Switching Ocata branch to Extended maintenance
by Bernard Cafarelli 03 Jan '19

03 Jan '19

Hello and happy new year, as discussed in our final 2018 meeting [0], we plan to switch the Ocata branch of Neutron to Extended maintenance [1]. There will be a final Ocata release for Neutron itself. Stadium projects backports only included test fixes so do not really need a final release. We will then mark the branch as ocata-em. Any comments or objections? Especially from driver projects maintainers, as these have independent releases. [0] http://eavesdrop.openstack.org/meetings/networking/2018/networking.2018-12-… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#extended… -- Bernard Cafarelli

1 0

[release] Release countdown for week R-13, Jan 7-11
by Sean McGinnis 03 Jan '19

03 Jan '19

Welcome back from the holiday lull! Development Focus ----------------- Teams should be focused on completing milestone 2 activities by January 10 and checking overall progress for the development cycle. General Information ------------------- The Stein membership freeze coincides with the Stein-2 milestone on the 10th. While doing an audit of all officially governed team repos, there are quite a few that have not had an official release done yet. If your team has added any repos for deliverables you would like to have included in the Stein coordinated release, please add at least an empty template deliverable file for now so we can help track those. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. Another reminder about the changes this cycle with library deliverables that follow the cycle-with-milestones release model. As announced, we will be automatically proposing releases for these libraries at milestone 2 if there have been any functional changes since the last release to help ensure those changes are picked up by consumers with plenty of time to identify and correct issues. More detail can be found in the original mailing list post describing the changes: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html Any other cycle-with-intermediary deliverables that have not requested a release by January 10 will be switched to the cycle-with-rc model as discussed previously: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

[placement] [packaging] [docs] WIP placement install docs
by Chris Dent 03 Jan '19

03 Jan '19

I've started a very wippy work in progress [1] for placement installation docs within the extracted placement repository, using the existing docs from nova as a base. I'd like to draw the attention of rdo, ubuntu, and obs packagers as the docs follow the existing pattern of documenting install on those three distros. However, since placement is not fully packaged yet, I'm making some guesses in the docs about how things will be set up and how packages will be named. So if people who are interested in such things could have a look that would be helpful. I've stubbed out, but not yet completed, a from-pypi page as well, as with placement, installation can become as simple as pip install + run a single command line with the right args, if that's what you want. I think people should be able to see that too. Thanks. [1] https://review.openstack.org/628220 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tc] agenda for Technical Committee Meeting 3 Jan 2019 @ 1400 UTC
by Doug Hellmann 03 Jan '19

03 Jan '19

TC Members, Our next meeting will be this Thursday, 3 Jan at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee We have several items of old business to wrap up: * technical vision for openstack We have approved the first draft of the vision [1], and have one update proposed by gmann [2]. What are the next steps for this change to the vision? Are we ready to remove this topic from the tracker now, and treat further updates as individual work items? [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/#/c/621516/ * next step in TC vision/defining the role of the TC We also approved a document explaining the role of the TC [3]. Is there more work to do here, or are we ready to remove this from the tracker now? [3] https://governance.openstack.org/tc/reference/role-of-the-tc.html * keeping up with python 3 releases We have approved all of the patches for documenting the policy and for selecting the versions to be covered in Stein. What are the next steps for ensuring that any implementation work is handled? * Reviewing TC Office Hour Times and Locations The most recent mailing list thread [4] was resolved with no changes to the number of office hours. Does anyone want to propose different times, or are we happy with the current schedule? [4] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000542… and we also have a couple of items of new business to take up: * Train cycle goals selection update Checking with lbragstad and evrardjp for any updates to share with us this month. * health check status for stein How is it going contacting the PTLs for the health check for stein? Does anyone have anything to raise based on what they have learned in their conversations? -- Doug

1 1

[glance] (Silly) question about container_format and disk_format
by Andre Florath 03 Jan '19

03 Jan '19

Hello! I do not completely understand the parameters 'container_format' and 'disk_format' as described in [1]. The documentation always uses 'the format' but IMHO there might be two formats involved. Are those formats either (A) the formats of the image file that is passed in. Like (from the official documentation [2]) $ openstack image create --disk-format qcow2 --container-format bare \ --public --file ./centos63.qcow2 centos63-image qcow2 / bare are the formats of the passed in image. or (B) the formats that are used internally to store the image Like $ openstack image create --disk-format vmdk --container-format ova \ --public --file ./centos63.qcow2 centos63-image vmdk / ova are formats that are used internally in OpenStack glance to store the image. In this case there must be an auto-detection of the image file format that is passed in and an automatic conversion into the new format. Kind regards Andre [1] https://developer.openstack.org/api-ref/image/v2/index.html?expanded=create… [2] https://docs.openstack.org/glance/pike/admin/manage-images.html

2 2

Re: [Infra][Cinder] Request for voting permission from LINBIT LINSTOR CI (linbit_ci@linbit.com) for Cinder projects
by Woojay Poynter 03 Jan '19

03 Jan '19

Hello, I would like to request a voting permission on LINBIT LINSTOR CI for Cinder project. We are looking to satisfy third-party testing requirement for Cinder volume driver for LINSTOR (https://review.openstack.org/#/c/624233/) The CI's test result of the lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ While the driver itself is still being tweaked on the remaining two failed tests, I hope I can have the CI portion of the requirement ready w/ this request. The testbeds are jenkins slave running fresh installation of devstack w/ target patch triggered from gerrit with lvmthin storage backend managed by LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for block replication. Some of the test results of the LINBIT LINSTOR CI running on openstack-dev/ci-sandbox are here; https://review.openstack.org/#/c/627599/ https://review.openstack.org/#/c/627596/ https://review.openstack.org/#/c/626625/ Thank you for your time during the holidays. Sincerely, Woojay Poynter -- 541-435-1001 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. On Fri, Dec 28, 2018 at 1:51 PM Woojay Poynter <woojay(a)linbit.com> wrote: > Hello, > > I would like to request a voting permission on LINBIT LINSTOR CI for > Cinder project. We are looking to satisfy third-party testing requirement > for Cinder volume driver for LINSTOR ( > https://review.openstack.org/#/c/624233/) The CI's test result of the > lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ > > While the driver itself is still being tweaked on the remaining two failed > tests, I hope I can have the CI portion of the requirement ready w/ this > request. > > The testbeds are jenkins slave running fresh installation of devstack w/ > target patch triggered from gerrit with lvmthin storage backend managed by > LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for > block replication. > > Some of the test results of the LINBIT LINSTOR CI running on > openstack-dev/ci-sandbox are here; > https://review.openstack.org/#/c/627599/ > https://review.openstack.org/#/c/627596/ > https://review.openstack.org/#/c/626625/ > > Thank you for your time during the holidays. > > Sincerely, > > Woojay Poynter > -- > 541-435-1001 > woojay(a)linbit.com > > LINBIT | Keeping the Digital World Running > DRBD – Corosync – Pacemaker > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > -- Woojay Poynter – Software Developer +1 503 573-1262 x211 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

2 1

[cinder] Is the cinder Active-Active feature OK？
by Jaze Lee 03 Jan '19

03 Jan '19

Hello, In my opinion, all rest api will get to manager of cinder volume. If the manager is using DLM, we can say cinder volume can support active-active. So, can we rewrite the comments and option's help in page https://github.com/openstack/cinder/blob/master/cinder/cmd/volume.py#L78 ? Thanks a lot. -- 谦谦君子

2 2

[neutron] Bug deputy report 17th~23rd Dec 2018
by Paweł Suder 02 Jan '19

02 Jan '19

Hello Neutrons, Following bugs/RFE/issues have been raised during last week. Some of them were already recognized, triaged, checked: >From oldest: https://bugs.launchpad.net/neutron/+bug/1808731 [RFE] Needs to restart metadata proxy with the start/restart of l3/dhcp agent - IMO need to discus how to do that. https://bugs.launchpad.net/neutron/+bug/1808916 Update mailinglist from dev to discuss - it is done. https://bugs.launchpad.net/neutron/+bug/1808917 RetryRequest shouldn't log stack trace by default, or it should be configurable by the exception - confirmed by Sławek ;) https://bugs.launchpad.net/neutron/+bug/1809037 [RFE] Add anti_affinity_group to binding:profile - RFE connected with another RFE from Nova related to NFV and (anti)affinity of resources like PFs. https://bugs.launchpad.net/neutron/+bug/1809080 reload_cfg doesn't work correctly - change in review, I tried to review, but no comments left - new contributor https://bugs.launchpad.net/neutron/+bug/1809134 - TypeError in QoS gateway_ip code in l3-agent logs - review in progress https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins - review in progress https://bugs.launchpad.net/neutron/+bug/1809447 - performance regression from mitaka to ocata - not triaged, I am not sure how to handle it - it is a wide thing.. https://bugs.launchpad.net/neutron/+bug/1809497 - bug noticed on gates related to another bug opened last week: https://bugs.launchpad.net/neu tron/+bug/1809134 Wish you a good time this week and for the next year! :) Cheers, Paweł

2 2

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback
by Rico Lin 02 Jan '19

02 Jan '19

Dear all Tl;dr; I gonna use this ML to give a summary of the forum [1] and asking for feedback for the idea of new SIG. We have a plan to create a new SIG for autoscaling which to cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. So if you have any thoughts for the new SIG (good or bad) please share it here. Here I summarize our discussion in the forum session `Autoscaling Integration, improvement, and feedback`. If you like to learn more or input your thoughts, feel free to put it in etherpad [1] or simply reply to this email. In the forum, we have been discussed the scope and possibility to integrate effort from Heat, Senlin, and also autoscaling across OpenStack to K8s. There are some long-term goals that we can start on like create a document for general Autoscaling on OpenStack, Common library for cross-project usage, or create real scenario cases to test on our CI. And the most important part is how can we help users and satisfied use cases without confuse them or making too much duplication effort across communities/projects. So here's an action we agree on, is to trigger discussion for either we need to create a new SIG for autoscaling. We need to define the scope and the goal for this new SIG before we go ahead and create one. The new SIG will cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. For example, we can have a document about do autoscaling in OpenStack, but we need a place to put it and keep maintain it. And we can even have a place to set up CI to test all scenario for autoscaling. I think it's possible to extend the definition of this SIG, but we have to clear our goal and make sure we actually doing a good thing and make everyone's life easier. On the other hand we also need to make sure we do not duplicate the effort of other SIGs/WGs. Also The reason I add `ptl` tag for this ML is that this SIG or the concept of `autoscaling` might be very deferent to different projects. So I really wish to hear from anyone and any projects who are interested in this topic. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

4 3