April 2019 - openstack-discuss - lists.openstack.org

How to protect plain-text passwords in local.conf
by Akhil Jayakumar (akjayaku) 09 Apr '19

09 Apr '19

Hi Folks, Is there a way we can encrypt passwords in local.conf? If so could you please point me to the reference? Thanks, Akhil.

3 2

resize a vm to a flavor with pci-passthrough
by Manuel Sopena Ballesteros 09 Apr '19

09 Apr '19

Dear Openstack community, I have 1 physical node with x4 nvidia nv100 running 1 fat vm. Additionally I am adding a nvme drive into that host and I would like to attach the nvme drive to the vm. Ideally I prefer to avoid data migration and redeploy the software. My problem is that I don't have another host with gpus so I am guessing that the vm can't be migrated. Am I right assuming this? So far I thought about 2 possibilities but I don't know whether they would work: Option 1: crate a new flavor with the pci device pass-through and resize existing vm (I hope the new vm with the new flavor will have the nvme attached). Option 2: convert ephemeral virtual disk into a bootable volume. Destroy vm. Create new vm with the new volume as a boot device. Which option would be preferred? Is there any other think I can do? Thank you very much Manuel 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.

4 4

[tripleo] CI Community Meeting time changed
by Rafael Folco 09 Apr '19

09 Apr '19

The CI Community Meeting (office open hours) has been moved to 13:30 UTC (30 minutes before the TripleO meeting). *MEETING TIME: Every Tuesday at 13:30 UTC* in https://bluejeans.com/4113567798. Agenda: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting --rfolco

1 0

[trove] Propose changes of the core team
by Lingxian Kong 09 Apr '19

09 Apr '19

Hi team, According to the community recommended criteria when removing cores[1] and the recent 3 months review statistics[2][3], as Trove PTL of the Train dev cycle, I propose the following change to the team: Members to remove from core team: Luke Browning Maciej Jozefczyk Manoj Kumar Nikhil Manchanda Samuel Matzek Yao Wang Zhao Chao jian.song zhanggang Thanks for all of your contributions to Trove, you are all welcomed to come back to the team anytime when the situation changes. All Trove core members, please respond with your comments and objections. [1] https://docs.openstack.org/project-team-guide/ptl.html#criteria-when-removi… [2] https://www.stackalytics.com/report/contribution/trove/180 [3] https://www.stackalytics.com/report/contribution/python-troveclient/180 --- Lingxian Kong Catalyst Cloud

2 1

[telemetry] Telemetry for Train
by Trinh Nguyen 09 Apr '19

09 Apr '19

Hi team, As we discussed last time [1], the Telemetry team needs help to maintain its projects in Train. I and Lingxian Kong [2] will give it a try this cycle hopefully will keep Telemetry as healthy as possible. I would like to kick start Telemetry in Train by calling for a team meeting this week to figure out what really happening and plan for actions in Train. - IRC Channel: #openstack-telemetry - Time: TBD (dangtrinhnt UTC+9) - Discussion etherpad (put your name to the attendee list): https://etherpad.openstack.org/p/telemetry-train Please reply here or ping me on the IRC channel (dangtrinhnt) what your options are and we will set up the meeting. Moreover, I would like to ask the current core members of Telemetry to grant me and Lingxian Kong core reviewers privileges on all of the Telemetry projects on Gerrit (ceilometer, aodh, panko, etc.). Thanks and love to talk to you soon. Yours, [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.ht… [2] https://review.openstack.org/#/c/645122/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

4 13

CLOS networking support best practice?
by Syd Logan 09 Apr '19

09 Apr '19

Hi, Over the past few weeks I've experimented with neutron in search of an "ah-ha!" moment at which point I've discovered how to best to use OpenStack neutron to implement a large datacenter CLOS network that supports bi-directional traffic between tenants and the external network(s). While the exploration has been quite educational (and fun), I'm still not there, and looking for suggested compass heading(s) towards best practice(s) as of 2019. Back in 2015, a blog post http://www.dorm.org/blog/openstack-architecture-at-go-daddy-part-2-neutron/ suggests a certain amount of heavy lifing was needed to support GoDaddy's leaf-spine, but I'm hoping by now things might be supported a bit more "out of the box". If not, what is best approach, and what is missing that needs contribution in order to make it complete? TIA and Best, syd

1 0

[chef][stable] Chef OpenStack retiring stable branches
by Jens Harbott 09 Apr '19

09 Apr '19

The Chef OpenStack project still has a set of repos with stable/newton branches, however those have been announced as EOL for more than a year [0], but we missed to actually close them down. I plan to do so in a couple of days unless there is some justified objection. See [1] for a list of the affected repositories and the commit hashes that are targeted to receive the "newton-eol" tag. The situation with the stable/ocata branches is similar, but while we did announce them as EOL in [0], too, the date mentioned there seems wrong. Also, there seems to be some confusion about the situation for the global OpenStack project, which doesn't seem to have retired stable/ocata for any project yet. Still, we don't have any open patches for stable/ocata, we don't have a working CI for it, and there also isn't anyone using it known to me. So please respond if there is a reason to keep the stable/ocata branches in their current state, otherwise I'd start the process to tag them as EOL, too. Jens [0] https://docs.openstack.org/openstack-chef/queens/install/genealogy. html#releases-summary [1] https://review.openstack.org/649945

2 1

openstack-ansible AIO error : os_swift : Get md5sum of local builder files
by Dimitris Theoharis 09 Apr '19

09 Apr '19

Hello I have been trying to add SWIFT in AIO for some testing but i always get the error i will post below. I have tried Ubuntu bionic and Centos 7 and git cloned 18.1.4 , 18.1.6 , 19.0.0.0rc2 , master all versions give me the same error about SWIFT . As i understand the error may be an ansible bug but not quite sure . the bootstrap-ansible installs version 2.7.9 this is the error: TASK [os_swift : Verify md5sum of builder files] ******************************************************************************************************************************************************************************************************************************* skipping: [aio1] => (item=aio1) fatal: [aio1]: FAILED! => {"msg": "The conditional check 'hostvars[item]['builder_md5sum'] != md5sum.stdout' failed. The error was: error while evaluating conditional (hostvars[item]['builder_md5sum'] != md5sum.stdout): 'ansible.vars.hostvars.HostVarsVars object' has no attribute 'builder_md5sum'\n\nThe error appears to have been in '/etc/ansible/roles/os_swift/tasks/swift_rings_post_distribution_check.yml': line 24, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# As this is post sync all should match and not be empty\n- name: Verify md5sum of builder files\n ^ here\n"} here is a very detailed error log https://pastebin.com/7B2wgac4 any tips ? thanks Dimitris Theoharis DevOps Engineer w: auvious.com e: dimtheo(a)auvious.com

1 0

[PTG][nova][neutron][cyborg][placement][ironic][cinder] Cross-project PTG planning
by Eric Fried 09 Apr '19

09 Apr '19

All- Starting to plan for Denver, I'd like to get a feel for cross-project sessions involving Nova. I made a pass through the Nova etherpad [1] and started extracting the bits that were obvious cross-project topics with Neutron [2], Cyborg [3], and Placement [4]. In a couple of places where I wasn't sure I left `XPROJ?`. We usually also have cross-project sessions with Cinder and Ironic. I saw no obvious topics with which to seed those etherpads yet, but please do so as they arise. Similarly, if other project teams have topics to discuss with Nova, please create an etherpad and link it from the bottom of [1] and the wiki [5]. Looking at the room schedule [6], how do folks feel about earmarking Friday morning for cross-project sessions? As the etherpads fill up we'll hopefully get a better idea of how much time to schedule for each. And doing it relatively early gives us time to prioritize spillover for Saturday if that becomes necessary. <what is going on in Eric's head?> Why granular etherpads? I'm hoping it will be more manageable than the enormous monolithic etherpad we usually end up with. We often tend to split out some pieces on the fly anyway; just trying to anticipate the need. Besides, granular is my middle name. </what> Thanks, efried [1] https://etherpad.openstack.org/p/nova-ptg-train [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg [4] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [5] https://wiki.openstack.org/wiki/PTG/Train/Etherpads [6] https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff…

6 5

[scientific-sig][ironic] Gathering datapoints - Ironic integration with data centre inventory management
by Stig Telfer 09 Apr '19

09 Apr '19

Hi All - Following some recent discussion with our friends at CERN, they are interested in gathering data, use cases and opinions about how Ironic could integrate with external DCIM tools. The idea is that Ironic’s essential node data could be enriched by being cross-referenced with lifecycle data, location, etc (and perhaps vice versa). We would like to bring some operator experience and Scientific SIG users tend to care for a broad base of hardware outside of their OpenStack estate. I might argue that Scientific SIG users stand to gain much from external integrations like this. Let’s put it on the agenda for this week’s IRC meeting (Wednesday 1100 UTC) and I hope people will come along with wish lists and constructive ideas that might be good input to help the CERN team gauge what good options might be. Cheers, Stig

1 0