- openstack-discuss - lists.openstack.org

Rocky and older Ceph compatibility
by Linus Nilsson 07 Feb '19

07 Feb '19

Hi all, I'm working on upgrading our cloud, which consists of a block storage system running Ceph 11.2.1 ("Kraken") and a controlplane running OSA Newton. We want to migrate to Ceph Mimic and OSA Rocky respectively. As part of the upgrade plan we are discussing first going to Rocky while keeping the block system at the "Kraken" release. It would be helpful to know if anyone has attempted to run the Rocky Cinder/Glance drivers with Ceph Kraken or older? References or documentation is welcomed. I fail to find much information online, but perhaps I'm looking in the wrong places or I'm asking a question with an obvious answer. Thanks! Best regards, Linus UPPMAX När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

3 3

[openstack-ansible][magnum]
by Alfredo De Luca 07 Feb '19

07 Feb '19

Hi all. I finally instaledl successufully openstack ansible (queens) but, after creating a cluster template I create k8s cluster, it stuck on kube_masters <https://10.1.8.113/project/stacks/stack/6221608c-e7f1-4d76-b694-cdd7ec22c38…> b7204f0c-b9d8-4ef2-8f0b-afe4c077d039 <https://10.1.8.113/project/stacks/stack/b7204f0c-b9d8-4ef2-8f0b-afe4c077d03…> OS::Heat::ResourceGroup 16 minutes Create In Progress state changedcreate in progress....and after around an hour it says...time out. k8s master seems to be up.....at least as VM. any idea? *Alfredo*

5 43

[neutron] [upgrade] No meeting on Feb. 7th
by Lujin Luo 06 Feb '19

06 Feb '19

Hi team, I will not be able to chair the meeting tomorrow. Let's skip it and resume next week! Sorry for any inconvenience caused. Best regards, Lujin

1 0

[nova[metadata] queens issues
by Ignazio Cassano 06 Feb '19

06 Feb '19

Hello All, I am facing an issue with nova metadata or probably something is missed by design. If I create an instance from an image with os_require_quiesce='yes' and hw_qemu_guest_agent='yes' and the image contain the package quemu-guest-agent, when the instance boots the service quemu.gust-agent starts fine because all needed device are created in kvm for the instance. If I destory the instance and boot another instance from the volume used by the previous instance, metadata are missed and qemu-guest agent does not start, I think this is a problem from backupping and restoring instances. Regards Ignazio

1 0

Manila Upstream Bugs
by Jason Grosso 06 Feb '19

06 Feb '19

Hello All, This is an email to the OpenStack manila upstream community but anyone can chime in would be great to get some input from other projects and how they organize their upstream defects and what tools they use... My goal here is to make the upstream manila bug process easier, cleaner, and more effective. My thoughts to accomplish this are by establishing a process that we can all agree upon. I have the following points/questions that I wanted to address to help create a more effective process: - Can we as a group go through some of the manila bugs so we can drive the visible bug count down? - How often as a group do you have bug scrubs? - Might be beneficial if we had bug scrubs every few months possibly? - It might be a good idea to go through the current upstream bugs and weed out one that can be closed or invalid. - When a new bug is logged how to we normally process this bug - How do we handle the importance? - When a manila bugs comes into launchpad I am assuming one of the people on this email will set the importance? - "Assigned" I will also assume it just picked by the person on this email list. - I am seeing some bugs "fixed committed" with no assignment. How do we know who was working on it? - What is the criteria for setting the importance. Do we have a standard understanding of what is CRITICAL or HIGH? - If there is a critical or high bug what is the response turn-around? Days or weeks? - I see some defect with HIGH that have not been assigned or looked at in a year? - I understand OpenStack has some long releases but how long do we normally keep defects around? - Do we have a way to archive bugs that are not looked at? I was told we can possibly set the status of a defect to “Invalid” or “Opinion” or “Won’t Fix” or “Expired" - Status needs to be something other than "NEW" after the first week - How can we have a defect over a year that is NEW? - Who is possible for see if there is enough information and if the bug is invalid or incomplete and if incomplete ask for relevant information. Do we randomly look at the list daily , weekly, or monthly to see if new info is needed? I started to create a google sheet [1] to see if it is easier to track some of the defect vs the manila-triage pad[2] . I have added both links here. I know a lot will not have access to this page I am working on transitioning to OpenStack ether cal. [1] https://docs.google.com/spreadsheets/d/1oaXEgo_BEkY2KleISN3M58waqw9U5W7xTR_… [2] https://etherpad.openstack.org/p/manila-bug-triage-pad *[3]* https://ethercalc.openstack.org/uc8b4567fpf4 I would also like to hear from all of you on what your issues are with the current process for upstream manila bugs using launchpad. I have not had the time to look at storyboard https://storyboard.openstack.org/ but I have heard that the OpenStack community is pushing toward using Storyboard, so I will be looking at that shortly. Any input would be greatly appreciated... Thanks All, Jason Grosso Senior Quality Engineer - Cloud Red Hat OpenStack Manila jgrosso(a)redhat.com

3 2

[ironic] cisco-ucs-managed and cisco-ucs-standalone drivers - Python3 and CI
by Julia Kreger 06 Feb '19

06 Feb '19

Greetings fellow OpenStack humans, AIs, and unknown entities! At present, ironic has two hardware types, or drivers, that are presently in the code base to support Cisco UCS hardware. These are "cisco-ucs-managed" and "cisco-ucs-standalone". At present they utilize an underlying library which is not python3 compatible and has been deprecated by the vendor. In their current state the drivers will need to be removed from ironic when python2 support is removed. While work was started[1][2] to convert these drivers, the patch author seems to have stopped working on updating these drivers. Repeated attempts to contact prior ironic contributors from Cisco and the aforementioned patch author have gone unanswered. To further complicate matters, it appears the last time Cisco CI <ml2.ci(a)cisco.com> [3] last voted was on January 30th [4] of this year and the the log server [5] appears to be unreachable. Ironic's requirement is that a vendor driver has to have third-party CI to remain in-tree. At present it appears ironic will have no choice but to deprecate the "cisco-ucs-managed" and "cisco-ucs-standalone" hardware types and remove them in the Train cycle. If nobody steps forward to maintain the drivers and CI does not return, the drivers will be marked deprecated during the Stein cycle, and ironic shall proceed to remove them during Train. Please let me know if there are any questions or concerns. Thanks, -Julia [1]: https://review.openstack.org/#/c/607732 [2]: https://review.openstack.org/#/c/598194 [3]: https://review.openstack.org/#/q/reviewedby:%22Cisco+CI+%253Cml2.ci%2540cis… [4]: https://review.openstack.org/#/c/620376/ [5]: http://3ci-logs.ciscolabs.net/76/620376/4/check/dsvm-tempest-ironic-cimc-jo…

1 0

[openstack-helm] How to specify nova override for multiple pci alias
by Gauld, James 06 Feb '19

06 Feb '19

How can I specify a helm override to configure nova PCI alias when there are multiple aliases? I haven't been able to come up with a YAML compliant specification for this. Are there other alternatives to be able to specify this as an override? I assume that a nova Chart change would be required to support this custom one-alias-entry-per-line formatting. Any insights on how to achieve this in helm are welcomed. Background: There is a limitation in the nova.conf specification of PCI alias in that it does not allow multiple PCI aliases as a list. The code says "Supports multiple aliases by repeating the option (not by specifying a list value)". Basically nova currently only supports one-alias-entry-per-line format. Ideally I would specify global pci alias in a format similar to what can be achieved with PCI passthrough_whitelist, which can takes JSON list of dictionaries. This is what I am trying to specify in nova.conf (i.e., for nova-api-osapi and nova-compute): [pci] alias = {dict 1} alias = {dict 2} . . . The following nova configuration format is desired, but not as yet supported by nova: [pci] alias = [{dict 1}, {dict 2}] The following snippet of YAML works for PCI passthrough_whitelist, where the value encoded is a JSON string: conf: nova: overrides: nova_compute: hosts: - conf: nova: pci: passthrough_whitelist: '[{"class_id": "030000", "address": "0000:00:02.0"}]' Jim Gauld

3 5

[all] Denver Open Infrastructure Summit Community Contributor Awards!
by Kendall Nelson 06 Feb '19

06 Feb '19

Hello Everyone! As we approach the Summit (still a ways away thankfully), its time to kick off the Community Contributor Award nominations[1]! For those of you that have never heard of the CCA, I'll briefly explain what they are :) We all know people in our communities that do the dirty jobs, we all know people that will bend over backwards trying to help someone new, we all know someone that is a savant in some area of the code we could never hope to understand. These people rarely get the thanks they deserve and the Community Contributor Awards are a chance to make sure they know that they are appreciated for the amazing work they do and skills they have. As always, participation is voluntary :) Nominations will close on April 14th at 7:00 UTC and recipients will be announced at the Open Infrastructure Summit in Denver[2]. Recipients will be selected by a panel of top-level OSF project representatives who wish to participate. Finally, congrats again to recipients in Berlin[3]! -Kendall Nelson (diablo_rojo) [1] https://openstackfoundation.formstack.com/forms/train_cca_nominations [2]https://www.openstack.org/summit/denver-2019/ <https://www.openstack.org/summit/berlin-2018/> [3] http://superuser.openstack.org/articles/openstack-community-contributor-awa…

1 0

[magnum][kayobe][kolla-ansible] heat-container-agent reports that `publicURL endpoint for orchestration service in null region not found` and `Source [heat] Unavailable.`
by Bharat Kunwar 06 Feb '19

06 Feb '19

I have a Magnum deployment using stable/queens which appears to be successful in every way when you look at `/var/log/cloud-init.log` and `/var/log/cloud-init-output.log`. They look something like this: http://paste.openstack.org/show/744620/ http://paste.openstack.org/show/744621/ However, `heat-container-agent` log reports this on repeat: Feb 06 17:56:38 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: Source [heat] Unavailable. Feb 06 17:56:38 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: /var/lib/os-collect-config/local-data not found. Skipping Feb 06 17:56:54 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: publicURL endpoint for orchestration service in null region not found These are the parts of the heat stack that stay in CREATE_IN_PROGRESS for a long time before eventually failing: http://paste.openstack.org/show/744638/ As a result, the workers never get created. Here is what my magnum.conf looks like: http://paste.openstack.org/show/744625 <http://paste.openstack.org/show/744625>. And this is what the heat params looks like: http://paste.openstack.org/show/744639/ <http://paste.openstack.org/show/744639/> I have tried setting `send_cluster_metrics=False` and also tried adding `region_name` to [keystone*] inside `magnum.conf`. What else should I try? Best Bharat

1 0

[Cinder][driver][ScaleIO]
by Martin Chlumsky 06 Feb '19

06 Feb '19

Hello, We are using EMC ScaleIO as our backend to cinder. When we delete VMs that have attached volumes and then try deleting said volumes, the volumes will sometimes end in state error_deleting. The state is reached because for some reason the volumes are still mapped (in the ScaleIO sense of the word) to the hypervisor despite the VM being deleted. We fixed the issue by setting the following option to True in cinder.conf: # Unmap volume before deletion. (boolean value) sio_unmap_volume_before_deletion=False What is the reasoning behind this option? Why would we ever set this to False and why is it False by default? It seems you would always want to unmap the volume from the hypervisor before deleting it. Thank you, Martin

4 6