January 2019 - openstack-discuss - lists.openstack.org

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

26 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 25 Jan '19

25 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 25 Jan '19

25 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 25 Jan '19

25 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 25 Jan '19

25 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 25 Jan '19

25 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 25 Jan '19

25 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 24 Jan '19

24 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 24 Jan '19

24 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 24 Jan '19

24 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 24 Jan '19

24 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 24 Jan '19

24 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 24 Jan '19

24 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 24 Jan '19

24 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 23 Jan '19

23 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 23 Jan '19

23 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 23 Jan '19

23 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 23 Jan '19

23 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 23 Jan '19

23 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