- openstack-discuss - lists.openstack.org

G8 H8
by Matt Riedemann 28 Jan '19

28 Jan '19

Time for a quick update on gate status. * There were some shelve tests that were failing ssh pretty badly in the tempest-slow job due to a neutron issue: https://launchpad.net/bugs/1812552. It seems https://review.openstack.org/#/c/631944/ might have squashed that bug. * Probably our biggest issue right now is test_subnet_details failing: http://status.openstack.org/elastic-recheck/#1813198. I suspect that is somehow related to using cirros 0.4.0 in devstack as of Jan 20. I have a tempest patch up for review to help debug that when it fails https://review.openstack.org/#/c/633225 since it seems we're not parsing nic names properly which is how we get the mangled udhcpc..pid file name. * Another nasty one that is affecting unit/functional tests (the bug is against nova but the query hits other projects as well) is http://status.openstack.org/elastic-recheck/#1813147 where subunit parsing fails. It seems cinder had to deal with something like this recently too so the nova team needs to figure out what cinder did to resolve this. I'm not sure if this is a recent regression or not, but the logstash trends start around Jan 17 so it could be recent. * https://bugs.launchpad.net/cinder/+bug/1810526 is a cinder bug related to etcd intermittently dropping connections and then cinder services hit ToozConnectionErrors which cause other things to fail, like volume status updates are lost during delete and then tempest times out waiting for the volume to be deleted. I have a fingerprint in the bug but it shows up in successful jobs too which is frustrating. I would expect that for grenade while services are being restarted (although do we restart etcd in grenade?) but it also shows up in non-grenade jobs. I believe cinder is just using tooz+etcd as a distributed lock manager so I'm not sure how valid it would be to add retries on that locking code or not when the service is unavailable. One suggestion in IRC was to not use tooz/etcd for DLM in single-node jobs but that kind of side-steps the issue - but if etcd is lagging because of lots of services eating up resources on the single node, it might not be a bad option. -- Thanks, Matt

4 5

[neutron] Neutron Bug Deputy report for week of Jan 21
by Lajos Katona 28 Jan '19

28 Jan '19

Hi Neutrinos, Here is the summary of neutron bugs that came in last week (starting from Jan. 21st). * Gate failures: * tempest-slow tests fails often (https://bugs.launchpad.net/neutron/+bug/1812552) * TestNetworkBasicOps:test_subnet_details intermittently fails with "cat: can't open '/var/run/udhcpc..pid': No such file or directory" (https://bugs.launchpad.net/neutron/+bug/1813198) => mriedem added extra logs to tempest (https://review.openstack.org/633225) let's see how that helps debugging. * neutron functional tests break with oslo.utils 3.39.1 and above (https://bugs.launchpad.net/neutron/+bug/1812922) => oslo.utils patch is on its way, in requirements the wrong oslo.utils versions were blacklisted. * Functional test neutron.tests.functional.services.portforwarding.test_port_forwarding.PortForwardingTestCase.test_concurrent_create_port_forwarding_delete_port fails (https://bugs.launchpad.net/neutron/+bug/1813540) * Unit test neutron.tests.unit.services.revisions.test_revision_plugin.TestRevisionPlugin. test_port_ip_update_revises failing (https://bugs.launchpad.net/neutron/+bug/1813417) * Medium * L2 agent do not clear old QoS rules after restart (https://bugs.launchpad.net/neutron/+bug/1812576) * In progress (https://review.openstack.org/632014) * Neutron-server takes a long time when creating a port with multiple addresses at once (https://bugs.launchpad.net/neutron/+bug/1813253) * Race during adding and updating same port in L3 agent's info can generate wrong radvd config file (https://bugs.launchpad.net/neutron/+bug/1813279) In progress: https://review.openstack.org/633236 * an instance can see other instances' unicast packages when security group firewall_driver is openvswitch (https://bugs.launchpad.net/neutron/+bug/1813439) * Invalid * Port with no active binding mark as dead (https://bugs.launchpad.net/neutron/+bug/1812788) * DOC: * create vm failed, RequiredOptError: value required for option lock_path in group (https://bugs.launchpad.net/neutron/+bug/1812497) * Fix on master: https://review.openstack.org/632316 * Networking Option 2: Self-service networks in neutron (https://bugs.launchpad.net/neutron/+bug/1812958) * duplicate of 1812497 Regards Lajos Katona (lajoskatona)

1 0

[tc][all] Train Community Goal - CLI
by Artem Goncharov 28 Jan '19

28 Jan '19

Hi everybody, One of the community goals for Train is to work on deprecation of individual clients in favor of unified OpenStackClient. This in turn consists (or might consist) from few individual targets: - bringing current state of the CLI support for each service on par with native service client (especially covering changes added with latest microversions) - ensuring SDK also supports all of the service/resource/attribute/method - switching OSC service to SDK, as soon as it is on the same level, as native service client (someone might argue, that this is a mandatory part for reaching the target, but I personally this should be as important for reaching the goal (in addition to avoid double work)) - deprecating individual clients (when prerequisites are fulfilled) In order to drive a bit the whole goal I have started working on gathering differences we have for services in OSC: https://etherpad.openstack.org/p/osc-gaps-analysis. I tried to analyze current state going from the API side, where for each service we have a set of resources (with corresponding attributes) and methods on those. To achieve that I was "parsing" a service documentation (do not kick me too hard for that ;-) and processing it further, leaving overall info as "yaml" since there is lots of info and in the background there are still some source "documents". Resulting document in some form represent a current status and a todo list. I would be happy if people who feel responsible for implementing CLI would have a look on that and provide a feedback, whether they find the whole analysis helpful or not (if not whether there are better ideas on how to track status and todo). There is still a lot to be done even to figure out the current status, but I feel we need to start moving if we want to achieve the target (even switching just a few services would be already an achievement). So, if you are willing to support the goal - please join me. Any help and work is welcome. Regards, Artem

2 2

Adding type hints to OpenStack (starting with Oslo)
by Cyril Roelandt 28 Jan '19

28 Jan '19

Hello, I have recently been looking at mypy[1], a static type checker for Python. It uses optional type hints[2] to perform type checking. Using mypy has many benefits: - it allows developers to find type-related bugs that could cause a program to crash or display an unexpected behaviour at runtime; - it replaces type information that is usually given in docstrings, and may be outdated; - mypy runs can be integrated into a CI, making sure there are no regressions; - mypy works with both Python 2 and 3; - adding type information may be done incrementally; - library developers may expose type information, helping their users. Type information is available for most of the standard Python library, and for the most popular libraries on PyPI, through typeshed[3]. It is therefore possible to write bad code such as: $ cat test.py import requests requests.get(123) And have mypy warn us that something is wrong: $ mypy test.py test.py:2: error: Argument 1 has incompatible type "int"; expected "Union[str, bytes]" I would like to add type hints to OpenStack, starting with a small project (because it would probably be quick and easy) that is used by a lot of other OpenStack projects (because they would benefit from the type hints as well). Oslo seems like a reasonable choice. I took the liberty of implementing a proof of concept on top of oslo.config[4]. Using this branch, you should be able to: 1) Run "tox -etype" to run mypy on the whole code base 2) Write a badly typed program such as this one: $ cat test.py from oslo_config import cfg common_opts = [ cfg.IntOpt('test', min='3'), cfg.HostAddressOpt('host', version='4'), ] And have mypy show you the type errors: $ mypy test.py test.py:4: error: Argument "min" to "IntOpt" has incompatible type "str"; expected "Optional[int]" test.py:5: error: Argument "version" to "HostAddressOpt" has incompatible type "str"; expected "Optional[int]" Does anyone know about mypy? Would anyone be interested in seeing type hints added to OpenStack? Looking forward to hearing your thoughts, Cyril [1] http://mypy-lang.org/ [2] https://www.python.org/dev/peps/pep-0484/ [3] https://github.com/python/typeshed [4] https://github.com/CyrilRoelandteNovance/oslo.config/tree/type

7 11

[magnum][queens] issues
by Ignazio Cassano 28 Jan '19

28 Jan '19

I am trying patches you just released for magnum (git fetch git:// git.openstack.org/openstack/magnum refs/changes/30/629130/9 && git checkout FETCH_HEAD) I got same issues on proxy. In the old version I modified with the help of spyros the scripts under /usr/lib/python2.7/dist-packages/magnum/drivers/common/templates/kubernetes/fragments because PROXY variables are not inherited in /etc/sysconfig/heat-params PROXY E NO PROXY variables are present but we must modify configure-kubernetes-master.sh to force them . /etc/sysconfig/heat-params echo "configuring kubernetes (master)" _prefix=${CONTAINER_INFRA_PREFIX:-docker.io/openstackmagnum/} export HTTP_PROXY=${HTTP_PROXY} export HTTPS_PROXY=${HTTPS_PROXY} export NO_PROXY=${NO_PROXY} echo "HTTP_PROXY IS ${HTTP_PROXY}" exporting the above variables when external network has a proxy, the master is installed but stack hangs creating kube master Resource Group Regards Ignazio

2 6

[neutron] CI meeting on 29.01.2019 cancelled
by Slawomir Kaplonski 28 Jan '19

28 Jan '19

Hi, I will not be able to drive Neutron CI meeting on Tuesday 29.01.2019 so lets cancel it for this week. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[qa][tempest] Waiting for interface status == ACTIVE before checking status
by Terry Wilson 27 Jan '19

27 Jan '19

In the networking-ovn project, we hit this bug *very* often: https://bugs.launchpad.net/tempest/+bug/1728600. You can see the logstash here where it has failed 330 times in the last week: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3… The bug has been around since 2017, and there are earlier reports of it than that. The bug happens in some projects outside of networking-ovn as well. At the core of the issue is that _get_server_port_id_and_ip4 loops through server ports to return ones that are ACTIVE, but there is a race where a port could become temporarily inactive if the ml2 driver continually monitors the actual port status. In the case we hit, os-vif started recreating the ovs port during an operation, so we would detect the status of the port as down and change the status, and then when the port is recreated we set the port status back to up. If the check happens while the port is down, the test fails. There have been comments that the port status shouldn't flip w/o any user request that would cause it, but that would mean that a plugin/driver would have to ignore the actual status of a port and that seems wrong. External things can affect what state a port is in. https://review.openstack.org/#/c/449695/7/tempest/scenario/manager.py adds a wait mechanism to checking the port status so that momentary flips of port status will not cause the test to inadvertently fail. The patch currently has 10 +1s. We really need to get this fixed. Thanks! Terry

4 7

[Seachlight] Team meeting today at 13:30UTC
by Trinh Nguyen 27 Jan '19

27 Jan '19

Hi team, We will have the team meeting today at 13:30UTC. Join us at #openstack-searchlight Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[ops] Berlin ops meet up march 2019
by Chris Morgan 25 Jan '19

25 Jan '19

We (the ops meet ups team) just heard that the city of Berlin just decided that March 8th 2019 is to be a public holiday. Our first reaction is to see if we can just pull the ops meet up forward one day (making it the 6th and 7th instead of the 7th and the 8th). Please let us know if this would be a problem for you ASAP. A good example might be if you have already booked flights. Since the even tickets have not been issued yet, we are hoping that's not the case for anyone. Moving to the 6th and 7th allows it to happen during normal business days for the host, Deutsch Telekom. I don't personally like the idea of trying to keep the 8th when it's a public holiday. Regards, Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

[cinder] Proposing new Core Members ...
by Jay Bryant 25 Jan '19

25 Jan '19

Team, I would like propose two people who have been taking a more active role in Cinder reviews as Core Team Members: First, Rajat Dhasmana who has been active in doing reviews the last couple of releases (http://www.stackalytics.com/?module=cinder-group&user_id=whoami-rajat) He has also made efforts to join our PTG and Forum sessions remotely, has helped to stay on top of bugs and has submitted a number of fixes recently. I feel he would be a great addition to our team. Also, I would like to propose Yikun Jiang as a core member. He had big shoes to fill, back-filling TommyLike Hu and he has stood to the challenge. Continuing to implement the features that TommyLike had in progress and taking an active role as a reviewer: (http://www.stackalytics.com/?module=cinder-group&user_id=yikunkero) I think that both Rajat and Yikun will be welcome additions to help replace the cores that have recently been removed. If there is no disagreement I plan to add both people to the core reviewer list in a week. Thanks! Jay Bryant (jungleboyj)

4 4

[dev] Upcoming git-review changes
by Stephen Finucane 25 Jan '19

25 Jan '19

Happy Friday, Just a quick heads up that the upcoming release of git-review, likely 2.0, removes a feature. Currently, git-review will detect the presence of "bug", "lp", "blueprint" or "bp" in commit messages and, if found, set the Gerrit topic for that submitted review to something based on the blueprint/bug. As noted in the commit that removed this [1], this hadn't been updated to support StoryBoard and there was no desire to do so given the OpenStack-specific nature of this feature along with the fact that it often did the wrong thing. We (being the people who authored and reviewed the patch) think this is definitely a good thing to do, but if anyone has genuine concerns about the removal of this functionality, be sure to raise them here or on #openstack-infra before we push that release out next week. Cheers, Stephen [1] https://github.com/openstack-infra/git-review/commit/03768832c4

2 3

[dev][keystone] Keystone Team Update - Week of 21 January 2019
by Colleen Murphy 25 Jan '19

25 Jan '19

# Keystone Team Update - Week of 21 January 2019 ## News ### Technical Vision Statement >From time to time we talk about writing a mission statement for keystone, and then the idea always loses steam due to unfocused motivation. Luckily the TC has now given us some excellent starting points[1] and has requested we publish a similar team statement and/or update the overall guiding document[2]. We started taking notes on how keystone measures up with the overall vision[3] and whoever finds time first will write up an addition to the keystone contributor guide, where we can further discuss on the review. [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.… [3] https://etherpad.openstack.org/p/keystone-technical-vision-notes ### External and Tokenless Auth (What's old is new again) In working with the Edge computing group and the engineers at Oath we've been revisiting external authentication with X.509 as well as tokenless authentication[4][5], both ancient features in keystone. Though they are under-tested and have suffered mild bitrot they are still useful features. External authentication with mod_ssl can potentially be used as a drop-in replacement for the custom authentication plugin that Oath currently uses for their IdP Athenz. It does not on its own solve the Edge use case in which a client may be unable to connect to the keystone server for long periods of time, but the ideas can be used as a starting point for proper offline authentication. Tokenless authentication is closely tied to X.509 authentication and was a useful idea for starting to reduce the security impact of bearer tokens, but it was never fully implemented. We have been discussing revamping that feature and will be working on cleaning up the bitrot and the documentation around these features. [4] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-01-22-1… [5] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 16 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 80 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 4 new bugs and closed 2. Bug #1813057 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1813057 Bug #1813085 (keystone:Undecided) opened by Tim Buckley https://bugs.launchpad.net/keystone/+bug/1813085 Bug #1813183 (keystone:Undecided) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1813183 Bug #1813265 (keystone:Undecided) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1813265 Bugs fixed (2) Bug #1794864 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1794864 Bug #1804522 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804522 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Feature proposal freeze happens next week, if you are working on a feature for Stein please have at least a WIP on Gerrit ASAP. The feature freeze is five weeks after that, so major features that are not already fairly far along may have to be pushed to Train. ## Shout-outs Thanks Guang for being super helpful with all of our X.509 and tokenless auth questions! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 0

Re: Ironic ibmc driver for Huawei server
by Julia Kreger 25 Jan '19

25 Jan '19

Greetings, If your CI can vote on ci-sandbox, you should be able to vote on ironic. I don't remember having to grand permissions previously. If not, please let me know and I'll contact the Infrastructure team. -Julia On Thu, Jan 24, 2019 at 7:50 PM xmufive(a)qq.com <sokoban(a)foxmail.com> wrote: > Hi julia， > > It seems the basic features of our 3rd party CI is ready. It now could > verify +1 on openstack-dev/ci-sandbox[1]. > I am writing for asking for permission of review ironic project for > huawei-ironic-ci. > > The account used for huawei-ironic-ci is: > > Username > huawei-ironic-ci > Full Name Huawei Ironic CI > Email Address zhengxianhui(a)huawei.com > Registered Jan 14, 2019 8:00 PM > Account ID 29800 > > [1] https://review.openstack.org/#/c/630893/ > > > Thanks, > > ------------------ 原始邮件 ------------------ > *发件人:* "Julia Kreger"<juliaashleykreger(a)gmail.com>; > *发送时间:* 2019年1月9日(星期三) 晚上10:47 > *收件人:* "xmufive(a)qq.com"<sokoban(a)foxmail.com>; > *抄送:* "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; > *主题:* Re: Ironic ibmc driver for Huawei server > > Ironic does not have a deadline for merging specs. We will generally > avoid landing large features the closer we get to the end of the > cycle. If third party CI is up before the end of the cycle, I suspect > it would just be a matter of iterating the driver code through review. > You may wish to propose it sooner rather than later, and we can begin > to give you feedback from there. > > -Julia > > On Tue, Jan 8, 2019 at 11:21 PM xmufive(a)qq.com <sokoban(a)foxmail.com> > wrote: > > > > Hi Julia， > > > > When is the deadline of approving specs, I am afraid that huawei ibmc > spec will be put off util next release. > > > > Thanks > > Qianbiao NG > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: "Julia Kreger"<juliaashleykreger(a)gmail.com>; > > 发送时间: 2019年1月9日(星期三) 凌晨2:26 > > 收件人: "xmufive(a)qq.com"<sokoban(a)foxmail.com>; > > 抄送: "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; > > 主题: Re: Ironic ibmc driver for Huawei server > > > > Greetings Qianbiao.NG, > > > > Welcome to Ironic! > > > > The purpose and requirement of Third Party CI is to test drivers are > > in working order with the current state of the code in Ironic and help > > prevent the community from accidentally breaking an in-tree vendor > > driver. Vendors do this by providing one or more physical systems in a > > pool of hardware that is managed by a Zuul v3 or Jenkins installation > > which installs ironic (typically in a virtual machine), and configures > > it to perform a deployment upon the physical bare metal node. Upon > > failure or successful completion of the test, the results are posted > > back to OpenStack Gerrit. > > > > Ultimately this helps provide the community and the vendor with a > > level of assurance in what is released by the ironic community. The > > cinder project has a similar policy and I'll email you directly with > > the contacts at Huawei that work with the Cinder community, as they > > would be familiar with many of the aspects of operating third party > > CI. > > > > You can find additional information here on the requirement and the > > reasoning behind it: > > > > > https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-par… > > > > We may also be able to put you in touch with some vendors that have > > recently worked on implementing third-party CI. I'm presently > > inquiring with others if that will be possible. If you are able to > > join Internet Relay Chat, our IRC channel (#openstack-ironic) has > > several individual who have experience setting up and maintaining > > third-party CI for ironic. > > > > Thanks, > > > > -Julia > > > > On Tue, Jan 8, 2019 at 8:54 AM xmufive(a)qq.com <sokoban(a)foxmail.com> > wrote: > > > > > > 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

Why COA exam is being retired?
by Eduardo Gonzalez 25 Jan '19

25 Jan '19

Reading the info in the COA site [0] says the following* "The OpenStack Foundation is winding down the administration of the COA exam".* Is there any reason for retiring the exam? I've tried to find a notice in the mailing list but not found anything at all. [0] https://www.openstack.org/coa/ Regards

6 6

Not getting full bandwidth VXLAN + DVR
by Yedhu Sastri 25 Jan '19

25 Jan '19

Hello, In our OpenStack environment(Newton) we are using 10G network in all our nodes. We are using OVS bridging with VXLAN tunneling and DVR. We also enabled Jumbo frames in NIC and also in physical switches. We also enabled VXLAN offloading in our NIC. irqbalance is running which suppose to distribute the network irqs to all cores of the CPU. But unfortunately we are only getting below 1G bandwidth when communicate with our VM's with floating IP's from compute hosts. We tested it using iperf and results are like Host to VM using floating IP - less than 1Gbits/sec VM to VM using internal IP - ~2.5Gbits/sec Any idea or solutions to solve this issue is much appreciated. -- With kind regards, Yedhu Sastri

2 1

Not getting full bandwidth VXLAN + DVR
by Yedhu Sastri 25 Jan '19

25 Jan '19

Hello, In our OpenStack environment(Newton) we are using 10G network in all our nodes. We are using OVS bridging with VXLAN tunneling and DVR. We also enabled Jumbo frames in NIC and also in physical switches. We also enabled VXLAN offloading in our NIC. irqbalance is running which suppose to distribute the network irqs to all cores of the CPU. But unfortunately we are only getting below 1G bandwidth when communicate with our VM's with floating IP's from compute hosts. We tested it using iperf and results are like Host to VM using floating IP - less than 1Gbits/sec VM to VM using internal IP - ~2.5Gbits/sec Any idea or solutions to solve this issue is much appreciated. -- With kind regards, Yedhu Sastri

1 0

[Keystone] How to retrieve secret key for a given access key id
by Pritha Srivastava 24 Jan '19

24 Jan '19

Hi All, I have a scenario where I need to retrieve the secret key of a given access key id (of EC2 credentials) from Keystone. I know that this can be done by sending a GET request to the following URL: v3/users/{user_id}/credentials/OS-EC2/access_key_id I don't have the user_id required for the above request, but I have the admin username and admin password, that was used to create the EC2 credentials. Is there a way to get the user_id, and then get the secret key from Keystone? Thanks, Pritha

1 0

[nova][dev] stein blueprint tracking status
by melanie witt 24 Jan '19

24 Jan '19

Hi all, I've updated our stein blueprint tracking status etherpad with all of our approved blueprints for the cycle and notes about their current status: https://etherpad.openstack.org/p/nova-stein-blueprint-status Feature freeze s-3 is fast approaching on March 7. Let's use this etherpad to help us focus our work and complete as much as we can in the next 6 weeks. At the top, I've collected status on our cycle themes. TL;DR is that some efforts have stalled and we probably need people to jump in and help. Some people are already helping, and that's awesome! Please use this etherpad as a review guide and a place to communicate notes about blueprint status and progress, anything that will help us all move forward on completing implementations and reviews. Communication will be key as we try to get things done by s-3. Use the etherpad, #openstack-nova on IRC, and the ML to ask questions, get unstuck, and give updates. Let me know if I've missed any blueprints and feel free to add notes about any items that need to be moved, etc. Cheers, -melanie

1 0

[magnum] Persistent Volume Claim with cinder backend
by Christian Zunker 24 Jan '19

24 Jan '19

Hi, we are running Magnum Rocky. I tried to create a persistent volume claim and got it working with provisioner: kubernetes.io/cinder But it failed with provisioner: openstack.org/standalone-cinder The docs state kubernetes.io/cinder is deprecated: https://kubernetes.io/docs/concepts/storage/storage-classes/#openstack-cind… Which one should be used in Rocky? This is our complete config for this case: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: cinder annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: EnsureExists provisioner: openstack.org/standalone-cinder parameters: type: volumes_hdd availability: cinderAZ_ceph --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 42Gi storageClassName: cinder regards Christian

2 1

[ptl][goals][python3] please update your team's status in the wiki
by Doug Hellmann 24 Jan '19

24 Jan '19

I noticed this morning that the last time the Python 3 status page [1] was updated in the wiki was August. I hope we've had changes to the level of support since then. Keeping that page up to date is part of fulfilling the goal this cycle. Please take a few minutes to review the content today and update it if necessary. Thanks! [1] https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projec… -- Doug

2 2

[openstack-dev] [neutron]
by Farhad Sunavala 24 Jan '19

24 Jan '19

Hi, I am open to suggestions.We have a need to switch traffic from our project to other projects without first getting out on the internet, floating IPs, etc. The other projects will be sharing their networks with our project.As shown in figure below, the orange network belongs to our project (10.0.0.0/26) The green network (172.31.0.0/24) belongs to another project andhas an overlapping network with the red tenant (172.31.0.0/16) For now, the solution is to create VMs in our project and make sure none of the interfaceshaving overlapping CIDRs. Thus, there is a VM attached to the 'orange' and 'red' netsand another VM attached to the 'orange' and 'green' nets. Problem: Too much resources (VMs) will need to be created if we have 100 tenants with overlapping networks. Solution:Is there a way I can minimize VM resource in our project by not allocating a separate VMfor shared networks with overlapping CIDRs? thanks,

3 3

[tc][telemetry][horizon] ceilometer-dashboard repository creation
by Jakub Slíva 24 Jan '19

24 Jan '19

Hello, our company created a little plugin to Horizon and we would like to share it with the community in a bit more official way. So I created change request (https://review.openstack.org/#/c/619235/) in order to create official repository under project Telemetry. However, PTL recommended me to put this new repository under OpenStack without any project - i.e. make it unofficial. I have also discussed this with Horizon team during their meeting (http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.…) and now I am bit stuck because I do not know how to proceed next. Could you, please, advise me? All opinions are appreciated. Jakub Sliva Ultimum Technologies s.r.o. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic http://ultimum.io

4 4

[cinder] volume snapshot on queens not working as in ocata
by Ignazio Cassano 24 Jan '19

24 Jan '19

2 3

Re: [docs] Nominating Alex Settle for openstack-doc-core
by Chason 23 Jan '19

23 Jan '19

So glad to see you back to us, Alex! \o/ Absolutely agree with this Nominating. > Date: Fri, 18 Jan 2019 14:42:33 +0100 > From: Petr Kovar <pkovar(a)redhat.com> > To: openstack-discuss(a)lists.openstack.org > Cc: Alex Settle <asettle(a)suse.com> > Subject: [docs] Nominating Alex Settle for openstack-doc-core > Message-ID: <20190118144233.132eb0e427389da15e725141(a)redhat.com> > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > Alex Settle recently re-joined the Documentation Project after a few-month > break. It's great to have her back and I want to formally nominate her for > membership in the openstack-doc-core team, to follow the formal process for > cores. > > Please let the ML know should you have any objections. > > Thanks, > pk > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list > openstack-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > > ------------------------------ > > End of openstack-discuss Digest, Vol 3, Issue 110 > *************************************************

1 0

[Release-job-failures] Release of openstack/sqlalchemy-migrate failed
by Sean McGinnis 23 Jan '19

23 Jan '19

There were release job failures with the latest sqlalchemy-migrate release. It appears it is another one of the issues with the readthedocs configuration not being correct. Everything else appears to have succeeded, so the new release is available. It just might need the published documentation manually updated. ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 23 Jan 2019 22:54:02 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Release of openstack/sqlalchemy-migrate failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - trigger-readthedocs-webhook http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : FAILURE in 2m 04s - release-openstack-python http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 4m 09s - announce-release http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 5m 51s - propose-update-constraints http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 3m 44s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

3 3

[infra][dev] Zuul promote pipeline for container publishing
by corvus＠inaugust.com 23 Jan '19

23 Jan '19

Hi, We recently added a new pipeline to OpenStack's Zuul, and three new jobs and roles to the zuul-jobs repo to support container publishing. If your project publishes containers, or may do so in the future, read on. The new pipeline is the "promote" pipeline. It runs jobs on changes after they merge, but unlike the "post" pipeline, it does not run with the resulting branch state after the merge -- it runs in the context of the change. This means that it's not suitable for building release artifacts, but that's not its purpose. Its purpose is to promote artifacts previously built in the gate pipeline to production. That is safe to do because anything built in the gate pipeline is built with the full future state of in-flight changes to all related projects and branches (even if it's built before they land). We build a lot of artifacts in the gate pipeline now, and then throw them away only to build them again in post. The promote pipeline is an attempt to avoid that waste and instead preserve artifacts built in gate and directly publish them -- but only if and when the changes for which they were built are merged. The first functional use of this system is in building container images and publishing them on Docker Hub. We have begun using this in openstack-infra to build container images of third-party applications, but this will work just as well and as easily for building images of applications in our infrastructure (for example, we are also starting to use this to publish Zuul images). To implement this, we wrote three jobs which are available now from zuul-jobs (and therefore can be used in any project or job in the system): * build-docker-image [1] * upload-docker-image [2] * promote-docker-image [3] The first job should run in the check pipeline and simply runs "docker build" on the arguments passed to it. It is used to verify that the build succeeds. The second job should run in the gate pipeline. It uploads the image to Docker Hub into the final repository location, but it only does so with a single tag with the form "change_123456" where '123456' is the Gerrit change number for the change under consideration. This will mean that docker pulls won't accidentally fetch the image yet. But the image is staged in Docker Hub and is ready to be promoted if the change passes all its tests and merges. The third job runs in the promote pipeline. This job, unlike the others, only performs Docker Hub API calls and requires no build resources. Therefore it is a zero-node job in Zuul -- a job which only runs on the Zuul executor. This job finds a previously uploaded image with a "change_" tag, and re-tags it with any specified tags ("latest" by default, but you can also tag version numbers or anything else). It also cleans up unused "change_" tags so they don't clutter up the repository. The nice thing about zero-node jobs is that they start and finish very quickly (since they don't have to deal with resource allocation and contention). With this system, an image will be fully published within about a minute after the change merges. To use this system, you will need to create (if you haven't done so already) a credential which is permitted to upload to an organization on Docker Hub, and you will need to add a secret [4] to Zuul for it. A complete example .zuul.yaml might look like this: - secret: name: myproject-dockerhub data: username: dockerhubuser password: !encrypted/pkcs1-oaep - DFlbrDM5eUMptMGIVMXV1g455xOJLi92UYF08Z2/JlIGu3t6v052o9FKlVyj1ZmpXs5+2 JTa5jHkLTvTsYs9fCaNcQc2nmViCyWNlbOMzjB17uiZOaYFNs1sMqZcUZbGEz7Y8ds6Qq NBXI10jWFPTah4QxUuBvUbT3vmjnUToCzexl5ZGhKgijcnROWfUsnlCdugpgoNIcPsUki zty5FotDihnrC8n8vIomVK6EClY38ty97pLrADzFDd+Cos/OUlvi2xooUhzx8Bn020rJA lqEU5v8LGXp5QkHx0MSDx6JY6KppJ/4p/yM+4By6l+A20zdcimxmgiNc9rMWPwDj7xsao m7NAZWmWqOO0Xkhgt6WOfugwgt9X46sgs2+yDEfbnI5ok8uRbAB/4FWj/KdpyXwhcf+O2 wEfhxLwDbAoGONQPjb4YcZmCXtmR7Qe5t+n2jyczWXvrbaBDUQP5a+YtVNN/xhmQ7D740 POlxv7bLxJAixzqaQ3d8Rz9ZEv6zzRuhWph32UQtZ1JxSNww+EvmXm2eEi2Q2z6pT1Cx/ j2OrFyA2GL/UJOVb15VHKF6bgHPHWJtpjPFhqdcvBhVute4BWB+KPcWH+y+apHN1enK3H tNJO9iqm34nKwSuj5ExmFw50LtwR5/9FyRuRPq/vBL+8y82v8FDmeYsBeobn5M= - job: name: myproject-build-image parent: build-docker-image description: Build Docker images. vars: &image_vars docker_images: - context: . repository: myproject/imagename - job: name: myproject-upload-image parent: upload-docker-image description: Build Docker images and upload to Docker Hub. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - job: name: myproject-promote-image parent: promote-docker-image description: Promote previously uploaded Docker images. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - project: check: jobs: - myproject-build-image gate: jobs: - myproject-upload-image promote: jobs: - myproject-promote-image If you find that you need jobs which behave slightly differently, you may be able to inherit from these jobs and add pre or post playbooks. Or if you need something particularly complicated, you can re-implement the jobs using the underlying roles in zuul-jobs, which have the same names an the jobs which invoke them. [1] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-build-docker-image [2] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-upload-docker-image [3] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-promote-docker-image [4] https://zuul-ci.org/docs/zuul/user/encryption.html

1 0

[Cinder][nova] queens backup
by Ignazio Cassano 23 Jan '19

23 Jan '19

Hi All, Please, I' d like to know if cinder backup and/or cinder snapshot call qemu guest agent for fsfreezing. If Yes, does it freeze file systems in the volume? Regards Ignazio

6 12

Re: [openstack-dev] [tripleo] reducing our upstream CI footprint
by Wesley Hayutin 23 Jan '19

23 Jan '19

On Thu, Nov 1, 2018 at 5:47 AM Derek Higgins <derekh(a)redhat.com> wrote: > On Wed, 31 Oct 2018 at 17:22, Alex Schultz <aschultz(a)redhat.com> wrote: > > > > Hey everyone, > > > > Based on previous emails around this[0][1], I have proposed a possible > > reducing in our usage by switching the scenario001--011 jobs to > > non-voting and removing them from the gate[2]. This will reduce the > > likelihood of causing gate resets and hopefully allow us to land > > corrective patches sooner. In terms of risks, there is a risk that we > > might introduce breaking changes in the scenarios because they are > > officially non-voting, and we will still be gating promotions on these > > scenarios. This means that if they are broken, they will need the > > same attention and care to fix them so we should be vigilant when the > > jobs are failing. > > > > The hope is that we can switch these scenarios out with voting > > standalone versions in the next few weeks, but until that I think we > > should proceed by removing them from the gate. I know this is less > > than ideal but as most failures with these jobs in the gate are either > > timeouts or unrelated to the changes (or gate queue), they are more of > > hindrance than a help at this point. > > > > Thanks, > > -Alex > > While on the topic of reducing the CI footprint > > something worth considering when pushing up a string of patches would > be to remove a bunch of the check jobs at the start of the patch set. > > e.g. If I'm working on t-h-t and have a series of 10 patches, while > looking for feedback I could remove most of the jobs from > zuul.d/layout.yaml in patch 1 so all 10 patches don't run the entire > suite of CI jobs. Once it becomes clear that the patchset is nearly > ready to merge, I change patch 1 leave zuul.d/layout.yaml as is. > > I'm not suggesting everybody does this but anybody who tends to push > up multiple patch sets together could consider it to not tie up > resources for hours. > > > > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html > > [2] > https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR… > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Greetings, Just a quick update.. The TripleO CI team is just about done migrating multinode scenario 1-4 jobs to the SingleNode job. This update and a few other minor changes have moved the needle with regards to TripleO's upstream resource consumption. In October of 2017 we had the following footprint.. tripleo: 111256883.96s, 52.45% [1] Today our footprint is now.. tripleo: 313097590.30s, 36.70% [2] We are still working the issue and we should see further improvement over the next couple months. I'll update the list again at the end of Stein. Thanks to Clark, Doug, Alex, Emilien and Juan for the work to make this happen!! Also thank you to the folks on the TripleO-CI team, you know who you are :) [1] http://paste.openstack.org/show/733644/ [2] http://paste.openstack.org/show/743188/

1 0

[docs] Nominating Alex Settle for openstack-doc-core
by Petr Kovar 23 Jan '19

23 Jan '19

Hi all, Alex Settle recently re-joined the Documentation Project after a few-month break. It's great to have her back and I want to formally nominate her for membership in the openstack-doc-core team, to follow the formal process for cores. Please let the ML know should you have any objections. Thanks, pk

13 14

oslo.messaging, OpenSSL 1.1.1a, Eventlet and Python 3.7
by Thomas Goirand 23 Jan '19

23 Jan '19

Hi there! Just a quick return from my experience. While testing all what's in the subject in Debian Buster/Sid (testing a full deployment), I noticed that most (if not all) components wouldn't connect to RabbitMQ. The crash was like this: http://paste.openstack.org/show/743089/ This happened in: - cinder-scheduler - nova-conductor - neutron-api - neutron-rpc-server and probably many more. After some search-engine time, I found this patch: https://github.com/eventlet/eventlet/pull/531/commits This fixed the issue for me (on all OpenStack components). I've pushed it in the eventlet Debian package Git repository, and hopefully, I'll be able to push it to Buster before the release (currently waiting on approval from the current package maintainer). Hoping this helps the project and/or some deployment people, Cheers, Thomas Goirand (zigo) P.S: More soon about the latest update of OCI.

2 2

[all][oslo][coordination] remove method get_transport in transport.py
by Herve Beraud 23 Jan '19

23 Jan '19

Hello everybody! Since few months oslo plan to remove an deprecated method (oslo_messaging.get_transport). In a first this method was deprecated to facilitate removing rpc_backend support, get_transport aliases was deprecated to simplify the code and the tests. Aliases were first depreacted in oslo.messaging 5.20.0 during Pike and now we want to definitely remove this method. The support of this aliases was planed to be remove during milestone stein-1. So I propose to all projects who use this deprecated method to start to move to the right oslo.messaging supported transport methods (get_rpc_transport or get_notification_transport depends on your needs). This thread will try to coordinate projects during migrator. I already submit a patch[1] to oslo.messaging to start to remove this method. To move forward on this topic I personaly plan to propose patchs to projects that I know that use it. To ensure a better removing, to be sure that all projects remove usages of this method, and to merge in the right order, I propose to you to use the same topic in your gerrit reviews by using refer the bug https://bugs.launchpad.net/oslo.messaging/+bug/1714945 in your commit (Related-Bug: #1714945). Please ensure that all your projects stop to use this method. If you facing an issue please reply to this thread to centralize support during the migrator. You can track this topic by visiting this page: https://review.openstack.org/#/q/topic:bug/1714945+(status:open+OR+status:m… [1] https://review.openstack.org/632523 Cheers! Best! -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[TripleO][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes: UPDATE
by Bogdan Dobrelya 23 Jan '19

23 Jan '19

Here is an update. The %{systemd_ordering} macro is proposed for lightening containers images and removing the systemd dependency for containers. Please see & try patches in the topic [0] for RDO, and [1][2][3][4][5] for generic Fedora 29 rpms. I'd very appreciate if anyone building Kolla containers for f29/(rhel8 yet?) could try these out as well. PS (somewhat internal facing but who cares): I wonder if we could see those changes catched up automagically for rhel8 repos as well? > I'm tracking systemd changes here [0],[1],[2], btw (if accepted, > it should be working as of fedora28(or 29) I hope) > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1668688 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1668687 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1668678 -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[scientific-sig] IRC meeting Wednesday 1100 UTC: 2FA with FreeIPA, OpenInfra Days London, ISC 2019
by Stig Telfer 23 Jan '19

23 Jan '19

Hi All - We have a Scientific SIG IRC meeting coming up on Wednesday 16th at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Full agenda and details are here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019> We’ve got quite a bit to cover this week. Our headline item is a presentation on experiences configuring 2FA for OpenStack using FreeIPA. We also have some exciting events coming up, and discussion on a possible Scientific OpenStack BoF at the International Supercomputer Conference in Frankfurt in June. Cheers, Stig

2 3

Subject: Re: [Trove] State of the Trove service tenant deployment model
by Darek Król 22 Jan '19

22 Jan '19

On Tue, Jan 22, 2019 at 07:29:25PM +1300, Zane Bitter wrote: > Last time I heard (which was probably mid-2017), the Trove team had > implemented encryption for messages on the RabbitMQ bus. IIUC each DB being > managed had its own encryption keys, so that would theoretically prevent > both snooping and spoofing of messages. That's the good news. > > The bad news is that AFAIK it's still using a shared RabbitMQ bus, so > attacks like denial of service are still possible if you can extract the > shared credentials from the VM. Not sure about replay attacks; I haven't > actually investigated the implementation. > > cheers, > Zane. > Excellent - many thanks for the confirmation. > > Cheers, > Michael Hello Michael and Zane, sorry for the late reply. I believe Zane is referring to a video from 2017 [0]. Yes, messages from trove instances are encrypted and the keys are kept in Trove DB. It is still a shared message bus, but it can be a message bus dedicated for Trove only and separated from message bus shared by other Openstack services. DDOS attacks are also mentioned in the video as a potential threat but there is very little details and possible solutions. Recently we had some internal discussion about this threat within Trove team. Maybe we could user Rabbitmq mechanisms for flow control mentioned in [1,2,3] ? Another point, I'm wondering if this is a problem only in Trove or is it something other services would be interesting in also ? Best, Darek [0] https://youtu.be/dzvcKlt3Lx8 [1] https://www.rabbitmq.com/flow-control.html [2] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-p… [3] https://tech.labs.oliverwyman.com/blog/2013/08/31/controlling-fast-producer…

6 9

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 22 Jan '19

22 Jan '19

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[nova] Do we need to copy pci_devices to target cell DB during cross-cell resize?
by Matt Riedemann 22 Jan '19

22 Jan '19

While working on the code to create instance-related data in the target cell database during a cross-cell resize I noticed I wasn't copying over pci_devices [1] but when looking at the PciDevice object create/save methods, those aren't really what I'm looking for here. And looking at the data model, there is a compute_node_id field which is the compute_nodes.id primary key which won't match the target cell DB. I am not very familiar with the PCI device manager code and data model (it's my weakest area in nova lo these many years) but looking closer at this, am I correct in understanding that the PciDevice object and data model is really more about the actual inventory and allocations of PCI devices on a given compute node and therefore it doesn't really make sense to need to copy that data over to the target cell database. During a cross-cell resize, the scheduler is going to pick a target host in another cell and claim standard resources (VCPU, MEMORY_MB and DISK_GB) in placement, but things like NUMA/PCI claims won't happen until we do a ResourceTracker.resize_claim on the target host in the target cell. In that case, it seems the things I only need to care about mirroring is instance.pci_requests and instance.numa_topology, correct? Since those are the user-requested (via flavor/image/port) resources which will then result in PciDevice and NUMA allocations on the target host. I'm just looking for confirmation from others that better understand the data model in this area. [1] https://review.openstack.org/#/c/627892/5/nova/conductor/tasks/cross_cell_m… -- Thanks, Matt

2 2

[neutron] Neutron Bug Deputy report for week of Jan 14
by Nate Johnston 22 Jan '19

22 Jan '19

Neutron friends, Below is a summary of the neutron bugs that came in last week (Jan 14th). Any bugs with a preceding "(*)" are not yet in "in progress" state. Looks like lajoskatona is this week's bug deputy. Ports/IPAM - https://bugs.launchpad.net/bugs/1811905 Deferred IP allocation, port update with binding_host_id + set new mac address fails - https://bugs.launchpad.net/bugs/1812788 Port with no active binding mark as dead Gate Failures - (*) https://bugs.launchpad.net/bugs/1812364 Error "OSError: [Errno 22] failed to open netns" in l3-agent logs - https://bugs.launchpad.net/bugs/1812404 test_concurrent_create_port_forwarding_update_port failed with InvalidIpForSubnet - (*) https://bugs.launchpad.net/bugs/1812872 Trunk functional tests can interact with each other - https://bugs.launchpad.net/bugs/1812552 tempest-slow tests fails often L3 / DHCP - https://bugs.launchpad.net/bugs/1811873 get_l3_agent_with_min_routers fails with postgresql backend - (*) https://bugs.launchpad.net/bugs/1812118 Neutron doesn't allow to update router external subnets DNS - (*) https://bugs.launchpad.net/bugs/1812168 Neutron doesn't delete Designate entry when port is deleted QoS - https://bugs.launchpad.net/bugs/1812576 L2 agent do not clear old QoS rules after restart Oslo - https://bugs.launchpad.net/bugs/1812922 neutron functional tests break with oslo.utils 3.39.1 and above Docs - (*) https://bugs.launchpad.net/bugs/1812225 Firewall-as-a-Service (FWaaS) in neutron docs for Rocky still refer to plans for Ocata - (*) https://bugs.launchpad.net/bugs/1809578 Documentation might be wrong - https://bugs.launchpad.net/bugs/1812497 create vm failed, RequiredOptError: value required for option lock_path in group

1 0

[scientific-sig] IRC meeting at 2100 UTC: Jitter on SR-IOV IB, Terraform and Kubespray
by Stig Telfer 22 Jan '19

22 Jan '19

Hi All - We have a Scientific SIG IRC meeting in about 30 minutes in channel #openstack-meeting. Everyone is welcome. Today’s agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_22nd_2019 We have Jacob Anders from CSIRO talking about some recent research on latency and jitter for SR-IOV InfiniBand. We also have Martial Michel from DataMachines on Terraform and Kubespray. Cheers, Stig

1 0

Denver Summit CFP Closing Tomorrow
by Ashlee Ferguson 22 Jan '19

22 Jan '19

Hi everyone, The CFP closes in less than 48 hours, so make sure to submit your presentations, panels, and workshops <https://www.openstack.org/summit/denver-2019/call-for-presentations> for the Denver Open Infrastructure Summit before tomorrow, January 23 at 11:59pm PT (January 24 at 7:59am UTC). SUBMIT YOUR PRESENTATION <https://www.openstack.org/summit/denver-2019/call-for-presentations> Tracks: AI, Machine Learning & HPC CI/CD Container Infrastructure Edge Computing Hands-on Workshops Open Development (formerly Open Source Community) Open Infrastructure Basics Private & Hybrid Cloud Public Cloud Security - NEW! Telecom & NFV Full track descriptions <https://www.openstack.org/summit/denver-2019/summit-categories> For tips on your submissions, check out these articles for some advice from the Summit Programming Committees— http://superuser.openstack.org/articles/tips-for-the-open-infrastructure-su… http://superuser.openstack.org/articles/tips-open-development-track-denver-… http://superuser.openstack.org/articles/tips-for-talks-on-the-public-cloud-… Denver Summit registration <https://openinfrasummitandptgdenver.eventbrite.com/> and sponsor sales are currently open. Learn more <https://www.openstack.org/summit/denver-2019> Please email speakersupport(a)openstack.org <mailto:speakersupport@openstack.org> with any questions or feedback. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update VII - Jan 22, 2019
by Chandan kumar 22 Jan '19

22 Jan '19

Hello, Here is the seventh update (Jan 15 to Jan 22, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: * Add support for aarch64 images - https://review.openstack.org/#/c/620032/ * Configuration drives don't appear to work on aarch64+kvm - https://review.openstack.org/#/c/626592/ * Fix tempest workspace path - https://review.openstack.org/#/c/628182/ * Add libselinux-python package for Red Hat distro - https://review.openstack.org/#/c/631203/ * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/630917/ * Use tempest_domain_name var for setting domain - https://review.openstack.org/#/c/630957/ * Rename tempest_public_net_physical_{type to name} - https://review.openstack.org/#/c/631183/ * Add tempest_interface_name var for setting interface - https://review.openstack.org/#/c/630942/ ansible-config_template * Use usr/share/ansible/plugins for data_files - https://review.openstack.org/631214 ansible-role-python_venv_build * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/631777/ openstack-ansible-tests * Setup clouds.yaml on tempest node - https://review.openstack.org/631794 Tripleo-spec * New spec for stein: os_tempest tripleo integration - https://review.openstack.org/630654 Summary: * We have cleaned up os_tempest cloudname and network related vars, fixed tempest workspace upgrade issue and os_tempest got support of aarch64 images and nova Configuration drives. * Tripleo os_tempest spec published: https://specs.openstack.org/openstack/tripleo-specs/specs/stein/ostempest-t… Things in Progress: os_tempest * Always generate stackviz irrespective of tests pass or fail - https://review.openstack.org/631967 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Use the correct heat tests - https://review.openstack.org/630695 * Use tempest_cloud_name in tempestconf - https://review.openstack.org/631708 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 os_tempest integration with Tripleo * Added requirements for integrating os_tempest role - https://review.openstack.org/628421 * Run tempest using os_tempest role in standalone job - https://review.openstack.org/627500 * Use os_tempest for running tempest on standalone - https://review.openstack.org/628415 Upcoming week: * We are able to run tempest in Triplo CI standalone test results are here: http://logs.openstack.org/00/627500/65/check/tripleo-ci-centos-7-standalone… * We will try to finish os_tempest integration with tripleo and heat support in os_tempest. Thanks to odyssey4me, cloudnull, jrosser (a lot of help on different patches), Panda and Sagi from Tripleo CI team pabelanger and dmsimard on figuring out os_tempest dependencies, action_plugins and nested ansible. Here is the 6th 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-January/001730.… Thanks, Chandan Kumar

2 1

[Trove] State of the Trove service tenant deployment model
by Michael Richardson 22 Jan '19

22 Jan '19

Hi all, Is anyone aware of the current state of the "service tenant" deployment model for Trove, and whether it is a viable option; or whether the historical method of customer tenants/projects are still the recommended approach? Any and all comments/thoughts/gotchas would be most appreciated! Cheers, Michael

3 6

Fwd: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results
by Chris Morgan 22 Jan '19

22 Jan '19

Congrats to the new openstack foundation directors! Just FYI the following went to the foundation mailing list. Chris From: Jonathan Bryce <jonathan(a)openstack.org> Date: Fri, Jan 18, 2019, 12:42 Subject: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results To: <foundation(a)lists.openstack.org> Hello everyone, The 2019 election of Individual Directors has closed. Results are available at the following link: https://www.bigpulse.com/pollresults?code=1336400LYwRuQQZqR72BJRpKJYV The Bylaws amendments have now been passed by the Individual Member class. The elected and appointed directors will be seated at the Board meeting at the end of January. Congratulations to our new and returning directors. We actually had the highest number of voters for any of our elections participate this year, so thank you to everyone for joining in the process. Jonathan 210-317-2438 Individual Directors ----------------------------------------- Tim Bell ChangBo Guo Sean McGinnis Prakash Ramchandran Allison Randal Egle Sigler Monty Taylor Shane Wang Platinum Directors ----------------------------------------- Alan Clark Ruan He Anni Lai Mark McLoughlin Chris Price Imad Sousou Brian Stein Ryan Van Wyk Gold Directors ----------------------------------------- Mark Baker Johan Christenson Robert Esker Clemens Hardewig Arkady Kanevsky JunWei Liu Vijoy Pandey Joseph Wang _______________________________________________ Foundation mailing list Foundation(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation -- Chris Morgan <mihalis68(a)gmail.com>

2 1

About gitignore policy.
by Natal Ngétal 22 Jan '19

22 Jan '19

Hi everyone, I would to have more information about the .gitignore file policy. First I have made a patch to ignore backup files from vim editor. The patches was refused because that doesn't respect the OpenStack policy: https://review.openstack.org/#/c/631790/ https://review.openstack.org/#/c/631789/ The policy is available in a cookiecutter template repository: https://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/%7b%7bcookie… Then I have started to make patch, to align OpenStack projects with this policy: https://review.openstack.org/#/c/632086/ In nova project the patch was refused, the first reason was we have already talk about this subject. The second reason was this policy is only for the new projects. Oslo is not a new project and is follow this policy. I know is not a priority subject, but I just want understand. For me a policy must be followed by all projects, to harmonize all, but maybe I wrong. For example, in this case, I would to know what is the rules? The new projects must follow the policy but not the old ones? In this case, what the rules for old projects and can we defined also an policy for it? Thanks in advance for your help. My best regards

4 4

[qa] dynamic credentials with the tempest swift client
by Udi Kalifon 22 Jan '19

22 Jan '19

Hello. I am developing GUI tests (Selenium) for the openstack director. I am now trying to make use of tempest Swift client in one of the tests which needs to fetch a file from the tripleo plans. I added this code in our base class to access the client: class GUITestCase(test.BaseTestCase): credentials = ('admin', 'primary') @classmethod def setup_clients(cls): super(GUITestCase, cls).setup_clients() # Clients for Swift cls.account_client = cls.os_admin.account_client cls.container_client = cls.os_admin.container_client cls.object_client = cls.os_admin.object_client I then try to list the objects in the "overcloud" container, which is where the default plans are found: class TestSwift(GUITestCase): def test_swift(self): (resp, body) = self.container_client.list_container_objects( "overcloud") print resp print body It returns a "not found" error. I'm pretty sure that the reason for it not finding the container (which is definitely there) is that it creates a project and a user for itself, and uses those credentials for its interactions with the undercloud. I can see the POST calls in tempest.log that show that it's creating itself the dynamic credentials: INFO tempest.lib.common.rest_client [req-54a... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/projects 0.365s INFO tempest.lib.common.rest_client [req-d3f... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/users 0.493s INFO tempest.lib.common.rest_client [req-480... ] Request (TestSwift:setUpClass): 200 GET http://192.168.24.3:35357/v3/roles 0.297s INFO tempest.lib.common.rest_client [req-e0a... ] Request (TestSwift:setUpClass): 204 PUT http://192.168.24.3:35357/v3/projects/9e1e6b33dcbd4aebb546c56a7258d5e0/user… 0.270s INFO tempest.lib.common.dynamic_creds [-] *Acquired dynamic creds:* credentials: Credentials: {'username': u'tempest-TestSwift-1494291785', 'project_name': u'tempest-TestSwift-1494291785', 'project_domain_id': u'default', 'user_domain_id': u'default', 'tenant_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'user_domain_name': u'Default', 'domain_name': u'Default', 'tenant_name': u'tempest-TestSwift-1494291785', 'user_id': u'cc715537a0c048b7a8692a0c8304b94d', 'project_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'domain_id': u'default', 'project_domain_name': u'Default'}, Network: None, Subnet: None, Router: None So I'm looking for a way to utilize the client without it automatically creating itself dynamic credentials; it has to use the already-existing admin credentials on the admin project in order to see the container with the plans. What's the right way to do that, please? Thanks a lot in advance! Regards, Udi Kalifon; Senior QE; RHOS-UI Automation

3 4

[oslo] Meetings next two weeks
by Ben Nemec 22 Jan '19

22 Jan '19

I had some last-minute travel come up for next week (the 28th-1st) which means I may have spotty availability. I'm not sure if I'll be able to run the meeting on Monday. I guess you can watch for courtesy pings and if they don't happen then chances are I couldn't. :-) The next week (4th-8th) I'm on vacation so I definitely won't be around. Unless someone else wants to run the meeting that one will not happen for sure. -Ben

1 0

UC Election - Looking for Election Officials
by Matt Van Winkle 22 Jan '19

22 Jan '19

Hey Stackers, We are getting ready for the Winter UC election and we need to have at least two Election Officials. I was wondering if you would like to help us on that process. You can find all the details of the election at *https://governance.openstack.org/uc/reference/uc-election-feb2019.html <https://governance.openstack.org/uc/reference/uc-election-feb2019.html>*. I do want to point out to those who are new that Election Officials are unable to run in the election itself but can of course vote. The election dates will be: January 21 - February 03, 05:59 UTC: Open candidacy for UC positions February 04 - February 10, 11:59 UTC: UC elections (voting) Please, reach out to any of the current UC members or simple reply to this email if you can help us in this community process. Thanks, OpenStack User Committee Amy, Leong, Matt, Melvin, and Joseph

4 4

[Release-job-failures][puppet] Release of openstack/puppet-aodh failed
by Jean-Philippe Evrard 22 Jan '19

22 Jan '19

Hello, puppet-aodh failed [3] to release due to an issue in the upload- puppetforge role, for a permission issue [0]. Maybe a privilege escalation is required in [1], or a deeper analysis needs to be done. The role was changed 5 days ago [2], so I am not sure this code had the chance to be tested in post release pipelines. Could someone have a look, please? Thank you in advance. Jean-Philippe Evrard (evrardjp) [0]: http://logs.openstack.org/61/617ffad84b633618490ca1023f8a31d9694b31a9/relea… [1]: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/upload-p… [2]: https://github.com/openstack-infra/zuul-jobs/commit/fd8ffc6711d6481e2fcd40d… [3]: http://lists.openstack.org/pipermail/release-job-failures/2019-January/0010…

2 2

[nova][ops] Problems disabling notifications on state changes
by Massimo Sgaravatto 22 Jan '19

22 Jan '19

I am disabling ceilometer on my OpenStack Ocata cloud. As fas as I understand, besides stopping the ceilometer services, I can also apply the following changes to nova.conf on the compute nodes: instance_usage_audit = True --> false notify_on_state_change = vm_and_task_state --> None I have a problem with the latter change: # grep ^notify_on_state_change /etc/nova/nova.conf notify_on_state_change=None but in the nova log: 2019-01-21 08:31:48.246 6349 ERROR nova ConfigFileValueError: Value for option notify_on_state_change is not valid: Valid values are [None, vm_state, vm_and_task_state], but found 'None' I have also tried setting notify_on_state_change=<None> but it complains that it is not a valid value I can simply comment that line, but I am afraid there is a problem somewhere Thanks, Massimo

2 2

Question about Heat parser
by adjandeye.sylla＠orange.com 22 Jan '19

22 Jan '19

Dear all, In the context of my post-doc research, I'm working with HOT templates and I want to parse them. Instead of developing a new parser, I want to reuse the one that is used by Heat but I don't want to connect to a running OpenStack to do the parsing. Is it possible to use Heat as a standalone parser (i.e. without connecting to a running OpenStack) ? Thank you for your answer. Best regards, Adja SYLLA _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 2

[all] New Automatic SIG (continue discussion)
by Rico Lin 21 Jan '19

21 Jan '19

Dear all To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name. And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases. If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284… [2] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000813… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

6 8