- openstack-discuss - lists.openstack.org

[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 21 Dec '18

21 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 21 Dec '18

21 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 21 Dec '18

21 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