- openstack-discuss - lists.openstack.org

[TripleO] SELinux support
by Mikhail Fedosin 22 Dec '18

22 Dec '18

Hello! One of the most important tasks for this release cycle is to provide full SELinux support in the installed overcloud. Some work in this direction has already been done and in many respects, due to the recent changes, support is almost ready. However, I would like to ask a few questions about what else can be improved. In short, to provide SELinux support the main challenge for us is to ensure that docker can write to the directories protected by SELinux. To allow writing there we change the directory type to container_file_t or its alias svirt_sandbox_file_t. There are two ways to do this: 1. Explicitly - specify the type when creating a directory. # semanage fcontext -at container_file_t "/my_folder(/.*)?" # restorecon -R /my_folder # docker run -v /my_folder:/tmp/my_folder ... 2. Implicitly - use the suffix :z when mounting the partition when creating a container. # docker run -v /my_folder:/tmp/my_folder:z ... Both methods change selinux type of /my_folder to container_file_t and allow to write to the section inside the container. You can read more about this feature in the article https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cau… To see how it works, I wrote a small playbook that creates two directories on the host system and modifies their selinux types in two ways: http://paste.openstack.org/show/737234/ Currently there is no consensus in TripleO which of the ways to use. For example, in many cases both methods are used, which adds unnecessary redundancy: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… In some cases there is only :z https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… In some, only explicit setting of svirt_sandbox_file_t on the directory https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… Some services still do not have SELinux support: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… Such inconsistency leads to hard to find bugs and makes it difficult to understand the code. An example of such a bug could be this: Here we set selinux type to svirt_sandbox_file_t for /var/log/swift https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… And rewrite it back later: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… For this reason, I want to come to an agreement on how we will implement SELinux support. In my understanding, the best solution would be to use the suffix :z only. Its advantage is that docker (and podman) checks the directory's selinux type before launching the container and changes it accordingly. In other words, if the type was accidentally changed during the execution of the container, then when it is restarted ":z" will return the type back. In the case of explicit type setting, we get an error. Therefore, I propose to remove the explicit setting svirt_sandbox_file_t and add the suffix ":z" where it is still missing. What do you think? Best regards, Mikhail Fedosin

2 1

[goals][upgrade-checkers] Week R-16 Update
by Matt Riedemann 21 Dec '18

21 Dec '18

By my count, 34 of 43 projects have at least the initial framework change in place (up from 28 in November). Neutron has merged the change to enable loading upgrade checks via extension point: https://review.openstack.org/#/c/615196/ The designate check has been updated (thanks Ben) and is ready for review: https://review.openstack.org/#/c/604430/ - this one is not a placeholder Otherwise I would like to highlight some initial framework changes that I think are ready to go: * magnum: https://review.openstack.org/#/c/611505/ * cloudkitty: https://review.openstack.org/#/c/613076/ * aodh: https://review.openstack.org/#/c/614401/ * barbican: https://review.openstack.org/#/c/611574/ * ceilometer: https://review.openstack.org/#/c/614400/ -- Thanks, Matt

1 0

[manila] no community meeting 27 December
by Tom Barron 21 Dec '18

21 Dec '18

As agreed at our last meeting, we will skip the regular manila community meeting on 27 December and resume our weekly cadence on 3 January 2019 at 1500 UTC on freenode #openstack-meeting-alt. All are welcome, and as usual please feel free to add to the agenda [1]. -- Tom Barron (irc: tbarron) [1] https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit&se…

1 0

openstack-dev] [neutron] Cancelling next Neutron drivers meeting
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the Neutron drivers meeting on December 28th. We will resume normally on January 4th. Best regards Miguel

1 0

[dev][keystone] Keystone Team Update - Week of 17 December 2018
by Lance Bragstad 21 Dec '18

21 Dec '18

# Keystone Team Update - Week of 17 December 2018 ## News This week was really quiet due to the holiday. Note that there won't be keystone meetings or office hours for the next two weeks since they fall on Christmas Day and New Years. If you have questions, please don't hesitate to use asynchronous communication like the mailing lists, especially since folks are likely on vacation and not lingering in IRC. ### Granular Instance Locks There is a thread about solving the problem on granular instance locks [0], which is kind of policy related. We're currently airing out all possible solutions. [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001223… ## Open Specs Reminder that we're about a month away from specification freeze, so specification reviews are important. I'd like to specifically call attention to the renewable app creds specification [1] since that is one the few left on our radar for this release. Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh [0] https://review.openstack.org/#/c/604201/ ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 4 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 117 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. It'll be good to start ramping up review focus since we'll start running up against deadlines shortly after the new year. Please have a look if you have time. ## Bugs This week we opened 5 new bugs and closed 1. Bugs opened (5) Bug #1808859 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1808859 Bug #1809116 (keystone:Undecided) opened by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1809116 Bug #1809237 (keystone:Undecided) opened by varocho https://bugs.launchpad.net/keystone/+bug/1809237 Bug #1808550 (keystoneauth:Undecided) opened by Ievgeniia Zadorozhna https://bugs.launchpad.net/keystoneauth/+bug/1808550 Bug #1809101 (keystonemiddleware:Undecided) opened by leehom https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Bugs closed (1) Bug #1809237 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1809237 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html ## 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

[senlin] No meetings next two weeks
by Duc Truong 21 Dec '18

21 Dec '18

Everyone, Due to the holidays there will be no meetings on December 28th and January 3rd. We will resume the regular meetings on Friday January 11th at 530 UTC. Duc

1 0

[keystone] No meetings December 25th or January 1st
by Lance Bragstad 21 Dec '18

21 Dec '18

Hey all, We talked about this in last week's meeting, but I'm sending a reminder to the list. We won't be having a team meeting or holding office hours next week or the week after since they fall on Christmas Day and New Year's. We'll resume meetings and office hours on January 8th. Happy holidays, Lance

1 0

[openstack-dev] [neutron] Cancelling next two team meetings
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the weekly Neutron meeting on December 24th and January 1st. We will resume normally on January 7th Best regards Miguel

1 0

[openstack-dev] [neutron] [neutron-interconnection] neutron-interconnection core reviewers
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, During the Dublin PTG we discussed and approved a neutron-interconnection proposal. Over the past few months the spec was merged ( https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutron-int…) and the corresponding repo was also approved and created: https://review.openstack.org/#/c/599428/ and https://review.openstack.org/#/c/599429/. Earlier today the core team of reviewers was created. This team includes the current Neutron core plus Thomas Morin and Yannick Thomas. So let's start pushing and reviewing code Best regards Miguel

2 1

Re: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project
by Vedartham Bharath 21 Dec '18

21 Dec '18

Hey Jim, Thank you for the reply! I was looking at this untargeted specs page for the project. http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/d… It is stated in this page that this project is currently unassigned. I will start working on this spec. I will begin by studying Glance and start making smaller contributions to it for now. I need all the help I can get! I am very passionate about OpenStack and it's services! I will keep in touch with you and the developers through this mailing list and the IRC channel. Thank you Bharath On Fri, Dec 21, 2018, 7:20 PM Jim Rollenhagen <jim(a)jimrollenhagen.com wrote: > On Fri, Dec 21, 2018 at 2:50 AM Vedartham Bharath < > vedarthambharath(a)gmail.com> wrote: > >> Hi all, >> >> I am very interested in working on one of the untargeted approved >> specifications in Glance. It is titled "Eliminate Redundant Downloads >> of Uncached Images". >> I have noticed that it is currently unassigned. >> >> My experience with OpenStack: >> I have setup Devstack. >> I have worked extensively on Swift as part of a research project. >> I have set up Swift All in One multiple times. >> I have also set up a multi-server installation of Swift. >> I have studied the codebase of Swift and added my own features for my >> project. >> >> I don't have a lot of experience with Glance. >> I have experience with dealing with large codebases and I am willing to >> dedicate myself to study Glance and work on this project. >> I would love to know if it is up for grabs! >> > > Hi Bharath, > > The untargeted specs page for glance says "The following specs have been > reviewed and approved but have not been targeted for a release because the > proposer is no longer available to work on the implementation". I do see > the blueprint for the spec[0] is assigned, but I know Jesse no longer works > on OpenStack. I'd say go ahead and assign the blueprint to yourself and > start hacking! :) > > [0] https://blueprints.launchpad.net/glance/+spec/duplicate-downloads > > // jim >

2 1

Re: [Release-job-failures] Release of openstack/karma-subunit-reporter failed
by Thierry Carrez 21 Dec '18

21 Dec '18

zuul(a)openstack.org wrote: > - release-openstack-javascript http://logs.openstack.org/64/647112461fdc90aa3e468f0d5f846e16b032c87d/relea… : POST_FAILURE in 5m 07s > - announce-release announce-release : SKIPPED Error is npm ERR! You cannot publish over the previously published versions: 0.0.4. : karma-subunit-reporter History here is that the tag in the git repo was incorrectly named (v0.0.4) last time the release was manually uploaded to npm (as 0.0.4). Since this is a re-release of the tag with correct name (0.0.4), the fact that the publication is failing (and announcement is skipped) is probably a good thing. -- Thierry Carrez (ttx)

2 2

[placement] How do we migrate DB manipulating data?
by TETSURO NAKAMURA 21 Dec '18

21 Dec '18

Hi, I'd like to discuss how we can have DB upgrade migration method (with data manipulation) in placement. --- BackGround ========== https://bugs.launchpad.net/nova/+bug/1803925 * In Rocky, to have nested resource provider feature, we expanded the DB to have root provider id column. * The root provider id shouldn't be None and for root providers it should be the same value of its resource provider id. * In Rocky, the code is build in a backward compatible way doing online migration. * For each request of listing/showing resource providers, we look the root provider id and if it is stale and empty, we assume the resource provider is a root and set the same value as resource provider id. * Those providers that are not called in the Rocky cycle will still have an empty value for the root provider id. * In Stein or later, we want a way to be sure that all the root provider id contains some non-None value. * This is because we have a lot of TODOs in code which we want to clean up once we are sure all the root provider ids have non-None value in the DB. * In Stein, we are already ready use alembic to manage DB schema changes in placement. Question ======== How should we copy the resource provider id to root provider id if the root provider id is None? Options ======= 1. Do it in the alembic script in the same way as the schema expansion * This is done in the https://review.openstack.org/#/c/619126/ and brought several concerns. * We don't want the data manipulation migration to be inter-mixed with schema changes. * For cases skipping one release in an FFU fashion, there would be a lot of rows to be changed. 2. Have two stable version branches for alembic to separate schema changes and data manipulation * Neutron has been managing two branches in alembic already. * https://specs.openstack.org/openstack/neutron-specs/specs/liberty/online-sc… * Developers would specify on which branch to have a new version via some a new CLI something like; `placement-db-manage revision -m "description of revision" (--schema-change|--data-manipulate)` * We should be careful for the dependency management across the two branches. * https://alembic.sqlalchemy.org/en/latest/branches.html 3. Bring the online-migration batch CLI command * Follow the traditional way to manage DB data in Nova * `placement-manage db online-data-migration [--max-count]` * I'm looking into this in https://review.openstack.org/#/c/624942/. 4. Any other ideas? --- Since it looks like it's going to have an impact both on operators who upgrade and developers who add new features in placement, it is nice to seek more ideas and to have a consensus before we go further. Thanks, -- Tetsuro Nakamura <nakamura.tetsuro(a)lab.ntt.co.jp> NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan

3 3

[tripleo][ci] Reducing merge time by moving nv job to experimental
by Felix Enrique Llorente Pastora 21 Dec '18

21 Dec '18

Hello, To reduce merge time, would be nice from a review to go from check pipeline to gate pipeline without waiting for non-voting jobs, one way to do that is changing non-voting jobs at different pipelien like experimental one, so we have their result but don't wait for them to change to gate pipepeline. -- Quique Llorente Openstack TripleO CI

4 6

[glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project
by Vedartham Bharath 20 Dec '18

20 Dec '18

Hi all, I am very interested in working on one of the untargeted approved specifications in Glance. It is titled "Eliminate Redundant Downloads of Uncached Images". I have noticed that it is currently unassigned. My experience with OpenStack: I have setup Devstack. I have worked extensively on Swift as part of a research project. I have set up Swift All in One multiple times. I have also set up a multi-server installation of Swift. I have studied the codebase of Swift and added my own features for my project. I am willing to dedicate myself to study glance and work on this project. I would love to know if it is up for grabs! Bharath

1 1

[dev][tc] Feedback on adding the 'API Version Based Feature Discovery' in OpenStack Technical Vision
by Ghanshyam Mann 20 Dec '18

20 Dec '18

Hello everyone, As you know, last month we had merged the very well written technical vision doc by Zane[1]. To extend it further, I am proposing a section/item to add about API-Version based feature discovery [1]. Each OpenStack Service should provide a mechanism to know the supported min and max API version in a cloud which further will help to discover the enhanced or new features. Also, a user should be able to query detailed information about features and enhancement per version. Patch 621516 is documenting this API version based discovery idea in vision doc, and I am looking forward for more feedback/opinion on this. [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/#/c/621516/ -gmann

1 0

Backporting networking-ansible to Queens
by Dan Radez 20 Dec '18

20 Dec '18

We have requested to add ansible-runner and update the version of python-pexpect from 4.3 to 4.5 in the openstack-requirements repository. https://review.openstack.org/#/c/624048 This is in effort to enable the networking-ansible ML2 driver in Queens. It was developed as part of the Rocky development cycle. We understood that this is outside the structure of standard practice and would like to request an exception for this change in light of it's low risk. We have customers that are asking for this ML2 driver to be enabled in our product that is based on Queens. We would like to push these changes to upstream first. This exposes the community to this code and prevents the need to carry patches downstream. This ML2 driver is an add on feature that should carry little to no technical debt for the stable/Queens code base. Python-pexpect need to be updated and we will update Triple-o to enable it to install and configure the new driver. Otherwise the backport consists of adding the ansible-runner dependency and packaging the code for the networking-ansible ML2 driver. End users are impacted only when they choose to install the feature and enable it. Thank you for your consideration, Dan Radez

3 3

[cinder][ops][docs] policy configuration howto
by Brian Rosmaita 20 Dec '18

20 Dec '18

At last week's cinder meeting (5 December) we had a discussion about policy checks at the database layer. While these checks seem to make it difficult to perform some policy configurations, there are too many of them to simply remove them without impacting stability given our current test coverage (at least that's my feeling). Additionally, it's possible to handle the proposed use case (a read-only administrator) without making any code changes. So we decided to fix this issue by documenting how this could work. I've got a patch up for the documentation. I've flagged this email for cinder people to read for accuracy, operators to read to make sure the instructions are clear and detailed, and docs people to read for felicity of expression. Please leave comments on the patch: https://review.openstack.org/#/c/624424/ cheers, brian

3 4

[Cinder] Image Name of all Instances does not show up
by Minjun Hong 20 Dec '18

20 Dec '18

Hi. After I installed Cinder, 'Image Name' of the created instances does not show up on horizon. When I created instances without Cinder, 'Image Name' of all instances was filled with the name of image which is used for creating the instance on horizon, like this link (https://imgur.com/0Habda7) Actually, although this does not cause any critical incorrect operation, it can make the users who use the Openstack system confused what image is used for the instances. That's why I need to resolve this issue. How can I fill 'Image Name' column with the name of the image ? Thanks! Regards,

3 3

Re: Failed live migration and duplicate attachments
by Torin Woltjer 20 Dec '18

20 Dec '18

How would you recommend addressing the duplicate attachments? There doesn't seem to be any adverse effect of them being there, but I cannot detach them because they are root volumes.

2 1

[openstack-dev][tripleo] TripleO CI Summary: Sprint 23
by Rafael Folco 20 Dec '18

20 Dec '18

Greetings, The TripleO CI team has just completed Sprint 23 (Nov 28 thru Dec 19). The following is a summary of completed work during this sprint cycle: - Completed adding standalone scenarios(1-4) jobs and disabled equivalent multinode jobs on master to save upstream resources. We will now start adding the standalone scenario jobs to tripleo projects - Improved python3 support and fixed Tempest packaging on Fedora 28 job. This is part of python3 and RHEL8 validation in upstream CI. The Fedora 28 standalone job has flapped from passing to failed, currently failing on bug <https://bugs.launchpad.net/tripleo/+bug/1808118> [3]. - After the review of the team, we have decided to use upstream zuul containers to facilitate the tripleo job recreation [4] The team is continuing to evaluate software factory rpms as the base for this work. Instructions are posted internally atm. - Tested a new CI environment for OVB jobs on RDO cloud, aka “OVB 2.0”. Experiments include ovb deployment without the te-broker. The te-broker is now offline!!! - Tempest update can be found here [5]. The planned work for the next sprint are: - Continue to fix Fedora 28 standalone job and add Fedora 28 jobs to the promotion pipeline. - Add Standalone scenarios[1-4] jobs across TripleO repos for Stein - Follow the docs and test the new “Container Zuulv3” reproducer. - Continue to work on the OVB improvements The sprint board is tracked on Taiga [1]. The Ruck and Rover for this sprint are Ronnele Landy (rlandy) and Wes Hayutin (weshay). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. The Ruck and Rover notes for this sprint are tracked on etherpad [2]. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-3 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint24 [3] https://bugs.launchpad.net/tripleo/+bug/1808118 [4] https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001116… -- Rafael Folco Senior Software Engineer

1 0

[release] Release countdown for week R-15, Dec 24-28
by Sean McGinnis 20 Dec '18

20 Dec '18

Development Focus ----------------- There are a few project-specific deadlines coming up for milestone 2. Development should be focused on meeting any of those deadlines and preparing for the library releases that will be proposed at the milestone. General Information ------------------- This cycle we have stopped required milestone releases, and that has introduced a side-effect that means we need to take other steps to ensure that downstream packagers testing upgrades from Rocky to Stein do not have issues with the version numbers calculated by PBR on the master branch.More details can be found in the mailing list post here: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135706.html The release team has generated empty commits to cause PBR to increment its calculated version as a fix for the situation, and we have a few of those patches open still. Please merge them as soon as possible to support the people who are testing upgrades. https://review.openstack.org/#/q/status:open+branch:master+topic:sem-ver Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

Devstack - yet more problems on install
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Following on from the last email about br-ex causing everything to baulk, I manually created the br-ex using brctl addbr br-ex and got past that hurdle. But now falling over with another one ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified key was too long; max key length is 767 bytes') ERROR oslo_db.sqlalchemy.exc_filters Error during database migration: (pymysql.err.InternalError) (1071, u'Specified key was too long; max key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE COLUMN resource resource VARCHAR(300)'] (Background on this error at: http://sqlalche.me/e/2j85) Base OS is CentOS 7.5. I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. I'd appreciate some assistance please. David

3 3

Use cases mapping to MVP architectures - FEEDBACK NEEDED
by Ildiko Vancsa 20 Dec '18

20 Dec '18

Hi, Hereby I would like to forward you the mapping of use cases to MVP architectures that Gergely Csatari is working on. Please provide feedback on this work item to make sure we are considering all the aspects. Thanks and Best Regards, Gergely and Ildikó In the Edge Coputing Group we are collecting use cases for the edge cloud infrastructure. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now I’m looking for feedback. This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. Here I list the use cases and the mapped architecture scenarios: Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] Both distributed [3] and centralized [4] Universal customer premise equipment (uCPE) for Enterprise Network Services[6] Both distributed [3] and centralized [4] Unmanned Aircraft Systems (Drones) [7] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Cloud Storage Gateway - Storage at the Edge [8] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Open Caching - stream/store data at the edge [9] Both distributed [3] and centralized [4] Smart City as Software-Defined closed-loop system [10] The use case is not complete enough to figure out Augmented Reality -- Sony Gaming Network [11] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Analytics/control at the edge [12] The use case is not complete enough to figure out Manage retail chains - chick-fil-a [13] The use case is not complete enough to figure out At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] Smart Home [15] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Data Collection - Smart cooler/cold chain tracking [16] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event VPN Gateway Service Delivery [17] The use case is not complete enough to figure out [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_servi…. [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_cu… [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Air… [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storag… [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching… [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_a… [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Re… [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2F… [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retai… [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collect… [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_… _______________________________________________ Edge-computing mailing list Edge-computing(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing

1 1

[tc] Technical Committee Status for 17 Dec 2081
by Doug Hellmann 20 Dec '18

20 Dec '18

This is the (mostly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == Project updates: * Add os-resource-classes under Nova: https://review.openstack.org/#/c/621699/ Other updates: * I added a TC "house rule" for voting on updates to the release management metadata for projects, to make it easier to keep those up to date: https://review.openstack.org/#/c/622989/ * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. ** https://review.openstack.org/#/c/622902/ ** https://review.openstack.org/#/c/622903/ ** https://review.openstack.org/#/c/622904/ ** https://review.openstack.org/#/c/624704/ ** https://review.openstack.org/#/c/624951/ ** https://review.openstack.org/#/c/624996/ * I updated the documentation of chair responsibilities to include the OSF annual report: https://review.openstack.org/#/c/624790/ * Lance proposed an update to document the process for changing PTLs in the middle of a cycle: https://review.openstack.org/#/c/620928/ * Ghanshyam proposed an update to clarify the term of TC chair, since some responsibilities include managing the election fo the next chair: https://review.openstack.org/#/c/621498/ * Zane's resolution describing how we will keep up with future Python 3 releases has been approved: https://review.openstack.org/#/c/613145/ * Thierry and Chris' work to document the role of the TC has been approved: https://review.openstack.org/#/c/622400/ * I documented the official topic tags used to designate the voting rules to apply to each governance patch: https://review.openstack.org/#/c/625004/ == TC Meetings == The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ I have proposed an update to the TC house voting rules to cover documentation changes in the governance repository. * https://review.openstack.org/625005 Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat Akhmerov. * https://review.openstack.org/#/c/625537/ == TC member actions/focus/discussions for the coming week(s) == We need to work to approve Sean's patch with the Stein supported/testing runtimes list. * https://review.openstack.org/611080 Thierry started a thread on the mailing list about adapting our office hours times. It would be good for us to resolve that so we can make the change after the new year, so I have renewed the thread with a summary of the options. Please vote. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036… == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

3 4

[networking-ovs-dpdk] Issue creating br-ex...
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Hello Trying to re-run a Queens DPDK all-in-one using devstack which I built in August and hitting issues. The local.conf is identical between the two machines except I had to take the "stable/queens" off the end of the "networking-ovs-dpdk" plugin line as that no longer appears to work. The installation seems to proceed until it gets to setting the ip mtu on br-ex. I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for the system. OVS_NUM_HUGEPAGES=3072 #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G for the system. #OVS_NUM_HUGEPAGES=14336 OVS_DATAPATH_TYPE=netdev OVS_LOG_DIR=/opt/stack/logs #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 [[post-config|$NOVA_CONF]] [DEFAULT] firewall_driver=nova.virt.firewall.NoopFirewallDriver scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] [OVS] datapath_type=netdev [ml2_type_flat] #flat_networks=physnet1,physnet2,physnet3,physnet4 flat_networks=physnet1,physnet2 I cannot stress again how identical these systems are - same hardware, same base OS install (CentOS 7.5). I was (maybe erroneously!) thinking that if I had it devstack working on one system, having an identical system would be a piece of cake to install. This is the installation error: +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local bridge=br-ex +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' netdev '!=' system ']' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 set_mtu br-ex 1500 +functions:set_mtu:750 local dev=br-ex +functions:set_mtu:751 local mtu=1500 +functions:set_mtu:752 sudo ip link set mtu 1500 dev br-ex Cannot find device "br-ex" +functions:set_mtu:1 exit_trap +./stack.sh:exit_trap:522 local r=1 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545230781 1747 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen Can someone explain what is going on here please? Thanks David

3 4

[tc] Adapting office hours schedule to demand
by Thierry Carrez 20 Dec '18

20 Dec '18

Hi, A while ago, the Technical Committee designated specific hours in the week where members would make extra effort to be around on #openstack-tc on IRC, so that community members looking for answers to their questions or wanting to engage can find a time convenient for them and a critical mass of TC members around. We currently have 3 weekly spots: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays But after a few months it appears that: 1/ nobody really comes on channel at office hour time to ask questions. We had a questions on the #openstack-tc IRC channel, but I wouldn't say people take benefit of the synced time 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple of TC members present So the schedule is definitely not reaching its objectives, and as such may be a bit overkill. I was also wondering if this is not a case where the offer is hurting the demand -- by having so many office hour spots around, nobody considers them special. Should we: - Reduce office hours to one or two per week, possibly rotating times - Dump the whole idea and just encourage people to ask questions at any time on #openstack-tc, and get asynchronous answers - Keep it as-is, it still has the side benefit of triggering spikes of TC member activity Thoughts ? -- Thierry Carrez (ttx)

9 19

[magnum] Magnum missing project ID for octavia client
by Zufar Dhiyaulhaq 20 Dec '18

20 Dec '18

Hi, I am trying to create Kubenetes multi-master with Magnum. I get 'Create Failed error` in etcd_lb and api_lb and the log is : OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requea-8cce-27a3c49b9d28) full log from /var/log/magnum/magnum-conductor.api : 2018-12-20 22:41:33.362 9733 ERROR magnum.drivers.heat.driver [req-98498689-f584-47ab-b500-839a9e0d07cc - - - - -] Cluster error, stack staton: Resource CREATE failed: OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requ2a-8cce-27a3c49b9d28) I have working Octavia and magnum (only with 1 master, kubernetes or docker), this is my magnum configuration : [api] host = 10.111.111.10 [certificates] cert_manager_type = x509keypair [database] connection = mysql+pymysql:// magnum:556a8c5002cce3d8933@10.111.111.100/magnum [keystone_authtoken] memcached_servers = 10.111.111.10:11211,10.111.111.20:11211, 10.111.111.30:11211 auth_version = v3 auth_uri = http://10.111.111.100:5000/v3 project_domain_id = default project_name = service user_domain_id = default password = a13dfbbac5a0e03754773 username = magnum auth_url = http://10.111.111.100:35357 auth_type = password admin_user = magnum admin_password = a13dfbbac5a0e03754773 admin_tenant_name = service [trust] trustee_domain_name = magnum trustee_domain_admin_name = magnum_domain_admin trustee_domain_admin_password = b13dfbbac5a0e03754773 trustee_keystone_interface = public [oslo_messaging_notifications] driver = messaging [DEFAULT] transport_url=rabbit://openstack:5e81fb9286a573a1e4e33@10.111.111.10:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.20:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.30:5672 log_dir=/var/log/magnum [cinder_client] region_name = RegionOne [octavia_client] region_name = RegionOne Anyone know what is the problem? Thank you. Best Regards, Zufar Dhiyaulhaq

1 0

[openstack-ansible][cinder] Multiple backends for Cinder
by Cecilia Di Maulo 20 Dec '18

20 Dec '18

Dear all, I currently have a NFS backend for Cinder and I would like to add an iSCSI (hpmsa) backend. However I was wondering where should the cinder services run? For now cinder-api.service and cinder-scheduler.service run in a lxc while cinder-volume.service runs in bare metal on the controllers. I also would like to separate as much as possible the 2 backend types to be able to remove 'easily' my NFS backend once the other one has proved it really works. I was thinking to have the services related to the NFS backend in a lxc and the services related to the HPMSA backend on metal. Is this even possible? How should I do it? Should I name 2 different services in the container_skel or..? Thank you for your help, Best Regards, Cecilia

2 1

[IRONIC] vif attached to baremetal node DOWN
by Manuel Sopena Ballesteros 20 Dec '18

20 Dec '18

Dear Openstack community, I am having huge problems setting up baremetal port group: PROBLEM: VIF DOWN Environment: Openstack Rocky Deployment: kolla-ansible 7.0.0 Provider network # SERVER AND NEUTRON PORTS ########################## [root@openstack-deployment ~]# openstack server list +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ce8e10ab-12b4-476e-8990-b2aeda8510a0 | demo1 | ACTIVE | hpc=10.0.32.103 | centos7.5-image | my-baremetal-flavor | ... +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ [root@openstack-deployment ~]# openstack port list +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 1e1c3f40-1ee0-46d1-8e38-0b0617893ccf | | 7c:fe:90:12:1f:f0 | ip_address='10.0.32.103', subnet_id='506af593-659b-4c58-a180-897dd0b04957' | DOWN | ... +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ # BAREMETAL PORT GROUP ###################### [root@openstack-deployment ~]# openstack baremetal port group show 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 +----------------------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------------------+------------------------------------------------------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:27:53+00:00 | | extra | {} | | internal_info | {u'tenant_vif_port_id': u'1e1c3f40-1ee0-46d1-8e38-0b0617893ccf'} | | mode | 802.3ad | | name | zeus-54-hpc-bond | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | properties | {u'downdelay': 0, u'miimon': 110, u'xmit_hash_policy': u'layer2+3', u'updelay': 0} | | standalone_ports_supported | False | | updated_at | 2018-12-20T14:28:57+00:00 | | uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | +----------------------------+------------------------------------------------------------------------------------+ # BAREMETAL PORTS ################## [root@openstack-deployment ~]# openstack baremetal port show 4a00e6fa-a7c1-4916-b540-01fef95c90c1 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:28:09+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4a00e6fa-a7c1-4916-b540-01fef95c90c1 | +-----------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack baremetal port show 4510e849-ed21-46f8-bf4c-ca91c7e6b648 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f1 | | created_at | 2018-12-20T14:28:14+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4510e849-ed21-46f8-bf4c-ca91c7e6b648 | +-----------------------+--------------------------------------+ # NETWORK AND SUBNET CONFIG ############################### [root@openstack-deployment ~]# openstack network show hpc +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | nova | | created_at | 2018-12-17T02:07:46Z | | description | | | dns_domain | None | | id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | ipv4_address_scope | None | | ipv6_address_scope | None | | is_default | None | | is_vlan_transparent | None | | location | None | | mtu | 1500 | | name | hpc | | port_security_enabled | True | | project_id | b91520cff5bd45c59a8de07c38641582 | | provider:network_type | flat | | provider:physical_network | physnet1 | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 3 | | router:external | Internal | | segments | None | | shared | True | | status | ACTIVE | | subnets | 506af593-659b-4c58-a180-897dd0b04957 | | tags | | | updated_at | 2018-12-20T12:21:09Z | +---------------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack subnet show hpc_subnet +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 10.0.32.100-10.0.32.150 | | cidr | 10.0.0.0/16 | | created_at | 2018-12-17T02:07:49Z | | description | | | dns_nameservers | 8.8.8.8 | | enable_dhcp | True | | gateway_ip | 10.0.32.1 | | host_routes | | | id | 506af593-659b-4c58-a180-897dd0b04957 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | location | None | | name | hpc_subnet | | network_id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | project_id | b91520cff5bd45c59a8de07c38641582 | | revision_number | 2 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2018-12-20T12:21:09Z | +-------------------+--------------------------------------+ # BONUS: THIS IS THE NIC CONFIGURATION THAT WORKS ON A SERVER ############################################################## [root@zeus-52 ~]# cat /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1 BONDING_OPTS="downdelay=0 miimon=110 mode=802.3ad updelay=0" TYPE=Bond BONDING_MASTER=yes MTU=9000 PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=10.0.32.52 PREFIX=16 GATEWAY=10.0.32.1 DNS1=8.8.8.8 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME="Bond connection 1" UUID=5153a698-46ca-4234-a71b-7c88e4c92b91 DEVICE=bond0 ONBOOT=yes Any thought about what am I doing wrong or what to do next? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0

[Cinder] cinder-volume connection problem when creating the instance
by Minjun Hong 20 Dec '18

20 Dec '18

Hi. I'm installing Cinder service in an storage server of my laboratory and I need you guys' help about Cinder. I'm installing Cinder by referring 'Cinder Installation Guide for Ubuntu' ( https://docs.openstack.org/cinder/queens/install/index-ubuntu.html) However, when I request creating an instance, it seems that Openstack cannot receive the volume which the instance needs from the storage server. And seeing status message of tgt service for iSCSI, it seems that the service needs certain kernel module. Status of tgt service is following: > ● tgt.service - (i)SCSI target daemon > Loaded: loaded (/lib/systemd/system/tgt.service; enabled; vendor > preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 26min ago > Docs: man:tgtd(8) > Process: 2249 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v ready (code=exited, status=0/SUCCESS) > Process: 2230 ExecStartPost=/usr/sbin/tgt-admin -e -c > /etc/tgt/targets.conf (code=exited, status=0/SUCCESS) > Process: 2206 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v offline (code=exited, status=0/SUCCESS) > Main PID: 2170 (tgtd) > Status: "Starting event loop..." > Tasks: 1 > Memory: 2.7M > CPU: 87ms > CGroup: /system.slice/tgt.service > └─2170 /usr/sbin/tgtd -f > Dec 19 22:05:55 node0 systemd[1]: Starting (i)SCSI target daemon... > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: iser_ib_init(3434) Failed to > initialize RDMA; load kernel modules? > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: work_timer_start(150) use signal > based scheduler > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: bs_init(387) use signalfd > notification > Dec 19 22:05:55 node0 systemd[1]: Started (i)SCSI target daemon. And the status of Cinder-volume service as follows: > ● cinder-volume.service - OpenStack Cinder Volume > Loaded: loaded (/lib/systemd/system/cinder-volume.service; enabled; > vendor preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 45min ago > Main PID: 2110 (cinder-volume) > Tasks: 2 > Memory: 210.2M > CPU: 1min 23.649s > CGroup: /system.slice/cinder-volume.service > ├─2110 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > └─2657 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > Dec 19 22:05:55 node0 systemd[1]: Started OpenStack Cinder Volume. > Dec 19 22:06:00 node0 sudo[2658]: pam_unix(sudo:auth): auth could not > identify password for [cinder] Log message of Cinder-volume service continuously complains that the service cannot communicate with the internal driver (maybe, LVM?). In other words, when Cinder-volume is accessed (e.g. instance creation), an error message is printed and after that, the same message is repeated every second as follows: 2018-12-19 22:04:00.747 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Caught SIGTERM, > stopping children > 2018-12-19 22:04:00.784 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Waiting on 1 children > to exit > 2018-12-19 22:04:00.809 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Child 36039 killed by > signal 15 > 2018-12-19 22:05:58.378 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/Grammar.txt > 2018-12-19 22:05:58.403 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/PatternGrammar.txt > 2018-12-19 22:05:59.820 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler objects version 1.35 as minimum service version. > 2018-12-19 22:05:59.826 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler RPC version 3.10 as minimum service version. > 2018-12-19 22:05:59.875 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Determined volume DB > was empty at startup. > 2018-12-19 22:05:59.908 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "lvm" is deprecated. Use option "target_helper" from group "lvm". > 2018-12-19 22:05:59.914 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option > "iscsi_protocol" from group "lvm" is deprecated. Use option > "target_protocol" from group "lvm". > 2018-12-19 22:05:59.916 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Image-volume cache > disabled for host node0@lvm. > 2018-12-19 22:05:59.932 2110 INFO oslo_service.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting 1 workers > 2018-12-19 22:05:59.940 2657 INFO cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting cinder-volume > node (version 13.0.0) > 2018-12-19 22:05:59.942 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "DEFAULT" is deprecated. Use option "target_helper" from group > "DEFAULT". > 2018-12-19 22:05:59.952 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated for removal (The auth_uri option > is deprecated in favor of www_authenticate_uri and will be removed in the > S release.). Its value may be silently ignored in the future. > 2018-12-19 22:05:59.953 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated. Use option "www_authenticate_uri" > from group "keystone_authtoken". > 2018-12-19 22:05:59.961 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting volume driver > LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Failed to initialize > driver.: ProcessExecutionError: Unexpected error while running command. > Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs > --version > Exit code: 1 > Stdout: u'' > Stderr: u'sudo: no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Traceback (most > recent call last): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/manager.py", line 433, in init_host > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > self.driver.check_for_setup_error() > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/drivers/lvm.py", line 286, in > check_for_setup_error > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager if > volutils.supports_thin_provisioning(): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/utils.py", line 628, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > utils.get_root_helper()) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 225, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager return > LVM.get_lvm_version(root_helper) >= (2, 2, 95) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 202, in > get_lvm_version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > run_as_root=True) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", > line 424, in execute > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > cmd=sanitized_cmd) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > ProcessExecutionError: Unexpected error while running command. > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Command: sudo > cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Exit code: 1 > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stdout: u'' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stderr: u'sudo: > no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > 2018-12-19 22:06:00.075 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Initializing RPC > dependent components of volume driver LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.076 2657 ERROR cinder.utils > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Volume driver > LVMVolumeDriver not initialized > 2018-12-19 22:06:00.076 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Cannot complete RPC > initialization because driver isn't initialized properly.: > DriverNotInitialized: Volume driver not ready. > 2018-12-19 22:06:10.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:20.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:30.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:40.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:50.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:00.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:10.078 2657 WARNING cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Update driver status > failed: (config name lvm) is uninitialized. In above log, 'Manage for service cinder -volume node0@lvm is ...' is the repeated part. If there is anyone who has experienced this kind of problem, please give me any advice. Thanks!

2 2

[neutron] [upgrade] No meeting on Dec. 27th
by Lujin Luo 20 Dec '18

20 Dec '18

Hi everyone, We will not have the next subteam meeting on Dec. 27th. Thank you for all of your work this year, and let's resume in next year, Jan. 3rd. Happy Holidays! Best regards, Lujin

1 0

[nova][vitrage] Nova extended server attributes
by Ifat Afek 20 Dec '18

20 Dec '18

Hi, Is there a way to get Nova extended server attributes (and specifically, OS-EXT-SRV-ATTR:instance_name) as part of the notification that is sent upon instance creation? In Vitrage we are using the immediate notifications from Nova, but this specific information is missing. Thanks, Ifat

2 2

[watcher] core reviewers update
by Чадин Александр Сергеевич 20 Dec '18

20 Dec '18

Hello Watcher team, Some of core contributors are inactive for a year or more and their priorities have been changed. I suggest to remove the following contributors from core reviewers of Watcher: - Joe Cropper - Prashanth Hari - Prudhvi Rao Shedimbi - Susanne Balle - Vincent Francoise - David Tardivel If some of them would like to get back to work on Watcher, I see no barriers for that. Best Regards, ____ Alex

1 0

[storyboard] it's all gone quiet
by Mark Goddard 20 Dec '18

20 Dec '18

I haven't received an email from StoryBoard for a few weeks now. While I'm quite enjoying the silence, it's probably not productive... I'm subscribed to a few projects and have email notifications checked in preferences. Is it just me? Mark

2 1

[all] Please help document dependencies between services
by Thierry Carrez 20 Dec '18

20 Dec '18

Hi everyone, As Jimmy announced[1] a couple of weeks ago, we need your help in compiling accurate dependency information between OpenStack services, to display in future versions of the openstack.org/software pages[2]. Each OpenStack service may have hard dependencies (can't work without) or soft dependencies (benefits of the presence of) on other services, and that is very useful information for users looking into various OpenStack components. You can help accurately document those, by proposing changes to the openstack/openstack-map repository[3], looking up your service in the openstack_components.yaml file and adding the following keys: dependencies: (for hard dependencies, when the service can't work without those other services) see-also: (for soft dependencies, when the service benefits of the presence of those other services) As an example, you can look at Octavia's entry[4]. Once we have that information compiled, we'll be able to publish it on the website, adding links between related services. Thanks in advance, [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000568… [2] https://www.openstack.org/software/project-navigator/openstack-components#o… [3] https://git.openstack.org/cgit/openstack/openstack-map/ [4] https://git.openstack.org/cgit/openstack/openstack-map/tree/openstack_compo… -- Thierry Carrez (ttx)

1 0

[dev][qa] Cancelling QA Office Hour for next two weeks
by Ghanshyam Mann 20 Dec '18

20 Dec '18

Hello Everyone, I will be on vacation from 24th Dec till 9th Jan, so cancelling the QA office hour for the next two weeks (27th Dec and 3rd Jan). We will resume it from 10th Jan. -gmann

1 0

[ironic][neutron] Baremetal node cannot get back IP address from neutron
by Dave.Chen＠Dell.com 19 Dec '18

19 Dec '18

Hi all, I have setup ironic with devstack, initially, there are three fake nodes and I could successfully create a server, access to the server with the IP assigned from neutron as well, so I guess the configuration should be good, then I move to a real baremetal node, and want to do the same thing, so I issued the below command, $ openstack server create --flavor baremetal --image ${IMAGE_NAME} --key-name local realnode The node could power on and start to boot with PXE, two MAC address has been bound to the node, and seen from the BOOT screen the NIC was up but was pending on configuration and then exit, seem like it cannot get the IP address back from the Neutron. On the Ironic server, I can see the DHCP request from the baremetal node, but there is no ACK no IP offering here. $ sudo tcpdump -i enp0s3 -n port 67 and port 68 ... 18:21:08.112923 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:6b:4b:df:35:87, length 394 18:21:12.143679 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:6b:4b:df:35:87, length 394 ... Also tried to capture the traffic on the switch, it shows the request has been sent as well but no IP offering. dnsmasq is running, $ ps -ef | grep dnsm dnsmasq --no-hosts --strict-order --except-interface=lo --pid-file=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/pid --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/host --addn-hosts=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/addn_hosts --dhcp-optsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/opts --dhcp-leasefile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap4c76340a-7f --dhcp-range=set:tag1,10.0.0.0,static,255.255.255.192,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=64 --conf-file= --domain=openstacklocal The data in neutron looks like below, $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/host fa:16:3e:43:85:35,host-10-0-0-1.openstacklocal,10.0.0.1 fa:16:3e:19:60:19,host-10-0-0-2.openstacklocal,10.0.0.2 52:54:00:72:0e:a8,host-10-0-0-9.openstacklocal,10.0.0.9,set:348f921b-62c3-451f-884c-d630ae8f60b9 IP seems has been assigned to the baremetal node, but after the node changed its status to "Maintenance", the entry removed from this file, and the entry never get into the "lease" file, $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/leases 1545344481 52:54:00:72:0e:a8 10.0.0.9 host-10-0-0-9 01:52:54:00:72:0e:a8 The only entry listed here is for the fake node. Could anyone kindly give me any suggestion where to looking into? How can I identify the root cause? Many thanks! Best Regards, Dave Chen

1 1

[opensetack-discuss][Openstack-Helm] Patches for upgrade rally
by Jae Sang Lee 19 Dec '18

19 Dec '18

Hi, I recently watched IRC talk about revert rally commit. I posted a patch[1] to upgrade rally last October. This is because openstack-helm is using a very old rally, which caused a dependency error when creating another image. I also changed the helm-toolkit of openstack-helm-infra because we need to change the rally init script.[2] After patch # 1 has been applied first, patch # 2 has to be merged. Only patch # 2 has been merged. Failure of all chart helm test or patch # 2 has been reverted again. So I updated the patch to upgrade rally today[3][4]. I hope [3] merges first. After that, [4] should be merged. Thanks. Jaesang [1] https://review.openstack.org/#/c/586783/1 [2] https://review.openstack.org/#/c/607822/ [3] https://review.openstack.org/#/c/586783 [4] https://review.openstack.org/626490

1 0

[dev] How to develop changes in a series
by Nadathur, Sundar 19 Dec '18

19 Dec '18

On Dec 5, 2018, Eric fried wrote: > This started off as a response to some questions Sundar asked, but Ithought it might be interesting/useful for new[er] OpenStack developers at large, so broadcasting. Most of this is familiar material for those used to github process. The 'git restack' part is interesting, though it seems a lot like 'git rebase -i'. Eric answered far more than what I asked. Thanks, Eric. Regards, Sundar

2 1

[devstack][neutron] truble with setting local.conf with neutron
by Jea-Min Lim 19 Dec '18

19 Dec '18

Dear all, I`m trying to test neutron with qos module using devstack in OpenStack pike in a single VM environment. However, I can`t figure out how to run devstack with my local.conf[1]. While configuring network and bridges, devstack lost connection to outside VM. As a result, devstack couldn`t complete settings. My local.conf example is based on doc[2]. If you have any comments on my local.conf, reply in this mail or, if you know the working configuration, it would be glad to share with me. Regards, [1] http://paste.openstack.org/show/737586/ [2] https://docs.openstack.org/devstack/latest/guides/neutron.html

2 2

[Openstack] unexpected distribution of compute instances in queens
by Zufar Dhiyaulhaq 19 Dec '18

19 Dec '18

Hi, I am deploying OpenStack with 3 compute node, but I am seeing an abnormal distribution of instance, the instance is only deployed in a specific compute node, and not distribute among other compute node. this is my nova.conf from the compute node. (template jinja2 based) [DEFAULT] osapi_compute_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1'][ 'ipv4']['address'] }} metadata_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api [barbican] [cache] backend=oslo_cache.memcache_pool enabled=true memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 [cells] [cinder] os_region_name = RegionOne [compute] [conductor] [console] [consoleauth] [cors] [crypto] [database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://{{ vip }}:9292 [guestfs] [healthcheck] [hyperv] [ironic] [key_manager] [keystone] [keystone_authtoken] auth_url = http://{{ vip }}:5000/v3 memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = {{ nova_pw }} [libvirt] [matchmaker_redis] [metrics] [mks] [neutron] url = http://{{ vip }}:9696 auth_url = http://{{ vip }}:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = {{ neutron_pw }} service_metadata_proxy = true metadata_proxy_shared_secret = {{ metadata_secret }} [notifications] [osapi_v21] [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [pci] [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://{{ vip }}:5000/v3 username = placement password = {{ placement_pw }} [quota] [rdp] [remote_debug] [scheduler] discover_hosts_in_cells_interval = 300 [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = true keymap=en-us novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html novncproxy_host = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} [workarounds] [wsgi] [xenserver] [xvp] [placement_database] connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement what is the problem? I have lookup the openstack-nova-scheduler in the controller node but it's running well with only warning nova-scheduler[19255]: /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupportedWarning: Configuration option(s) ['use_tpool'] not supported the result I want is the instance is distributed in all compute node. Thank you. -- *Regards,* *Zufar Dhiyaulhaq* _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

9 23

[first contact] Cancelling Next Meeting
by Kendall Nelson 19 Dec '18

19 Dec '18

Hello! During the meeting yesterday, we voted to cancel our next meeting which would have been January 1 st. After that we will resume our regularly scheduled programming :) Have a good rest of the year everyone! -Kendall (diablo_rojo)

1 0

[publiccloud-wg][sigs] Reminder weekly meeting Public Cloud WG
by Tobias Rydberg 19 Dec '18

19 Dec '18

Hi everyone, Time for a new meeting for Public Cloud WG - tomorrow 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Hope to see a lot of you there for the last meeting during 2018! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

Failed live migration and duplicate attachments
by Torin Woltjer 19 Dec '18

19 Dec '18

After doing live migrations for some instances, and those migrations failing, the attached volumes show duplicates of the same attachment. This is the error message I get when the migration fails: https://pastebin.com/raw/3mxSVnRR openstack volume list shows the volume is attached to the instance twice. | a424fd41-a72f-4099-9c1a-47114d43c1dc | zktech-wpdb1 | in-use | 50 | Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda How do I remove the duplicate attachment, and why could the live migration be failing in the first place? Not all migrations fail, but sometimes they do and I have multiple volumes with duplicate attachments. Torin Woltjer Grand Dial Communications - A ZK Tech Inc. Company 616.776.1066 ext. 2006 www.granddial.com

2 2

[swift]Putting Swift storage disks to sleep
by Vedartham Bharath 19 Dec '18

19 Dec '18

Hi all, I am an undergraduate currently working on a research project which involves OpenStack Swift. In my project, I have set up Swift to run on 4 disks. I want to put down one of the hard disks to sleep i.e reduce the spin. I am using the hdparm tool in Linux to do this. The problem is that the disk automatically wakes back up after being put to sleep. I have found out that this is due to the fact that all the storage disks of Swift have to be mounted with XFS and the sync processes of XFS require the disk to wake up. I was wondering if there is a way to use a disk without a filesystem in Swift and if not, are there any other ways of putting storage disks in Swift to sleep? I have made sure the object replicator and object auditor do not wake the disk up. My goal is to be able to control putting the disk to sleep and waking it up when I need. Details of set up: Software: OpenStack Swift Newton with Keystone OS: Ubuntu 16.04 Thanks!

2 2

[nova] When can/should we remove old nova-status upgrade checks?
by Matt Riedemann 19 Dec '18

19 Dec '18

Questions came up in review [1] about dropping an old "nova-status upgrade check" which relies on using the in-tree placement database models for testing the check. The check in question, "Resource Providers", compares the number of compute node resource providers in the nova_api DB against the number of compute nodes in all cells. When the check was originally written in Ocata [2] it was meant to help ease the upgrade where nova-compute needed to be configured to report compute node resource provider inventory to placement so the scheduler could use placement. It looks for things like >0 compute nodes but 0 resource providers indicating the computes aren't reporting into placement like they should be. In Ocata, if that happened, and there were older compute nodes (from Newton), then the scheduler would fallback to not use placement. That fallback code has been removed. Also in Ocata, nova-compute would fail to start if nova.conf wasn't configured for placement [3] but that has also been removed. Now if nova.conf isn't configured for placement, I think we'll just log an exception traceback but not actually fail the service startup, and the node's resources wouldn't be available to the scheduler, so you could get NoValidHost failures during scheduling and need to dig into why a given compute node isn't being used during scheduling. The question is, given this was added in Ocata to ease with the upgrade to require placement, and we're long past that now, is the check still useful? The check still has lots of newton/ocata/pike comments in it, so it's showing its age. However, one could argue it is still useful for base install verification, or for someone doing FFU. If we keep this check, the related tests will need to be re-written to use the placement REST API fixture since the in-tree nova_api db tables will eventually go away because of extracted placement. The bigger question is, what sort of criteria do we have for dropping old checks like this besides when the related code, for which the check was added, is removed? FFU kind of throws a wrench in everything, but at the same time, I believe the prescribed FFU steps are that online data migrations (and upgrade checks) are meant to be run per-release you're fast-forward upgrading through. [1] https://review.openstack.org/#/c/617941/26/nova/tests/unit/cmd/test_status.… [2] https://review.openstack.org/#/c/413250/ [3] https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py… -- Thanks, Matt

5 5

Devstack failure “Oslo.concurrency”
by d.lake＠surrey.ac.uk 19 Dec '18

19 Dec '18

Hello I’m trying to rebuild a Devstack system on an identical machine to a working system from August. Same base OS (Centos 7.5), same simple local.conf. But this system is failing with Oslo.concurrency not at 2.26. This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. Yet something in Devstack insists on going back to 2.25.1 despite knowing that I need 2.26. What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. How do I work around this please? If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. Thanks David Sent from my iPhone

3 3

[tripleo][openstack-ansible] collaboration on os_tempest role update IV - Dec 19, 2018
by Chandan kumar 19 Dec '18

19 Dec '18

Hello, As 2018 is about to end, Here is the last updates on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: [1.] Create basic doc structure - https://review.openstack.org/623512 [2.] Added support for installing tempestconf from distro - https://review.openstack.org/622999 [3.] Revert "Use tempest run for generating subunit results" - https://review.openstack.org/625070 Revert reason: when --subunit flag is used with tempest run, either the tests passes or fails, It was always returning success. We are investigating and working on the same to fix it. python-tempestconf: [4.] Handle Forbidden exception when creating role - https://review.openstack.org/#/c/624411/ [5.] Adapt python-tempestconf to python3 - https://review.openstack.org/#/c/622343/ [6.] Add argument which allows users to add extensions - https://review.openstack.org/620379 Works still in progress: os_tempest: [1.] Better tempest black and whitelist management - https://review.openstack.org/621605 [2.] Update all plugin urls to use https rather than git - https://review.openstack.org/625670 [3.] Remove octavia in favor of octavia-tempest-plugin - https://review.openstack.org/625828 [4.] Use tempest_tempestconf_profile for handling named args - https://review.openstack.org/623187 [5.] Add tempestconf_git_url var for tempestconf testing - https://review.openstack.org/626092 [6.] Added support for installing python-tempestconf from git - https://review.openstack.org/625904 python-tempestconf: [7.] Add profile argument - https://review.openstack.org/621567 Summary: While working on adding support of python-tempestconf profile feature support in os_tempest, we found that we cannot test tempestconf patches with os_tempest as tempestconf is getting installed by pip, that's why we were working on adding support for the same to install it from git. Thanks to evrardjp, odyssey4me, jrosser, arxcruz, mnaser, kopecmartin for helping us on our silly queries. Upcoming two weeks: * Complete existing work in progress patches. Note: We are sending next update on 09th Jan, 2019 as Holidays started. Here is the third update [2] Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000831… Thanks, Chandan Kumar

2 1

[requirements] adding pre-commit to requirements blacklist (skip check)
by Sorin Sbarnea 19 Dec '18

19 Dec '18

It seems that the list of linters from the the blacklist.txt file is a bit outdated and missing things like: pre-commit bashate ansilbe-lint ansible-review I discovered that while trying to enable pre-commit on tripleo-upgrades and discovered that check-requirements jobs was failing. If someone can help me merge that it would be great https://review.openstack.org/#/c/626000/ <https://review.openstack.org/#/c/626000/> My review contains only pre-commit because that was the one I really needed but looking at the file it seems it may be useful to add all known https://github.com/openstack/requirements/blob/master/blacklist.txt <https://github.com/openstack/requirements/blob/master/blacklist.txt> Thanks Sorin

1 0

[dev][ops][monasca] Additional meeting time
by Bedyk, Witold 19 Dec '18

19 Dec '18

Hello everyone, Monasca team has decided to hold additional team meetings on Thursdays, 7am UTC [1]. This way we would like to offer more suitable meeting time for developers and operators from Asia/Australia. We would like to try this new format of `double meetings` for some time and we'll keep it if there is demand. Everyone interested is warmly invited to join. If you have any topics you would like to discuss, please add them to the agenda [2]. The next meetings are planned today 1500 UTC and tomorrow 0700 UTC. See you there Witek [1] http://eavesdrop.openstack.org/#Monasca_Team_Meeting [2] https://etherpad.openstack.org/p/monasca-team-meeting-agenda

1 0