January 2020 - openstack-discuss - lists.openstack.org

[ironic][nova][neutron][cloud-init] Infiniband Support in OpenStack
by Kumari, Madhuri 22 Jan '20

22 Jan '20

Hi, I am trying to deploy a node with infiniband in Ironic without any success. The node has two interfaces, eth0 and ib0. The deployment is successful, node becomes active but is not reachable. I debugged and checked that the issue is with cloud-init. The cloud-init fails to configure the network interfaces on the node complaining that the MAC address of infiniband port(ib0) is not known to the node. Ironic provides a fake MAC address for infiniband ports and cloud-init is supposed to generate the actual MAC address of infiband ports[1]. But it fails[2] before reaching there. I have posted the issue in cloud-init[3] as well. Can someone please help me with this issue? How do we specify "TYPE=InfiniBand" from OpenStack? Currently the type sent is "phy" only. [1] https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpe… [2] https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpe… [3] https://bugs.launchpad.net/cloud-init/+bug/1857031 Regards, Madhuri

3 5

[nova] block_device_info being introduced to nova.virt.driver.ComputeDriver.rescue
by Lee Yarwood 22 Jan '20

22 Jan '20

Hello all, Just a heads up that as part of my work introducing stable device rescue to Nova the following change will be introducing an additional block_device_info argument to the signature of nova.virt.driver.ComputeDriver.rescue. virt: Provide block_device_info during rescue https://review.opendev.org/#/c/700811/ Any third party drivers implementing instance rescue will need to be updated. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

1 0

Updating Openstack from Pike non-containerised to something current
by Tony Pearce 22 Jan '20

22 Jan '20

I am planning to upgrade my Openstack Pike. Please could I ask some questions about this so I understand better how to proceed? *Background*: - I have Openstack Pike running on 3 nodes (2 x compute and 1 x controller). Storage is provided by a Cinder driver and separate vendor storage array (iSCSI). - I have a bug which is impacting Cinder in Pike which is not present in Queens/Stein. - Since I installed Openstack some years ago, I was not able to update/patch it for a number of reasons. - The Openstack which I installed was from the tripleo.org website and I followed the instructions there. - I have configured LBaaS that was available in Pike by making config changes to .conf files. - I recall reading a few months ago when I started looking into this that I need to update to the latest within the current version (Pike) first, before updating beyond Pike so I am planning for that. *Questions*: 1. do I first need to deconfigure / remove the LBaaS before attempting an upgrade beyond Pike? 2. The tripleo website is a little confusing. I am running Pike and it is not containerised. The upgrade info on tripleo.org mentions upgrades to Pike in a containerised environment. So should I follow the detail for the "Ocata and earlier" release in this case? ref: http://tripleo.org/upgrade/minor_update.html#updating-your-overcloud-ocata-… 3. Do I need to upgrade to each release? ie from Pike > Queens then Queens > Stein etc ? Or can I do this: a) update Pike to the latest in the current Pike release b) Update Pike to Train *What I've gathered so far:* - If I can execute the 'openstack overcloud update' and limit it to the controller node then I can apply this to a cloned environment consisting of 1 x undercloud "director" and 1 x controller but I am unable to stage this for the compute nodes because they are physical bare-metal - the tripleo website guide lists the latest as 'Rocky' but I could see Stein in the yum search. I think I can follow the tripleo guide with a pinch of salt and replace *rocky* with *stein* Thank you *Tony Pearce* | *Senior Network Engineer / Infrastructure Lead**Cinglevue International <https://www.cinglevue.com>* Email: tony.pearce(a)cinglevue.com Web: http://www.cinglevue.com *Australia* 1 Walsh Loop, Joondalup, WA 6027 Australia. Direct: +61 8 6202 0036 | Main: +61 8 6202 0024 Note: This email and all attachments are the sole property of Cinglevue International Pty Ltd. (or any of its subsidiary entities), and the information contained herein must be considered confidential, unless specified otherwise. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

2 3

volume local cache
by Fang, Liang A 22 Jan '20

22 Jan '20

Hi Gibi, Dan, Alex and dear Nova cores Nova Spec: https://review.opendev.org/#/c/689070/ Cinder Spec: https://review.opendev.org/#/c/684556/ Regarding the volume local cache spec, after several rounds of discussion in cinder weekly meeting, we continued discussed in cinder virtual mid-cycle ptg yesterday, and now cinder team is close to get agreement, and major ideas are: * Cinder sets “cacheable” property in volume type * Cinder should guarantee “cacheable” is set correctly, that means: should not set with “multiattach”, should not set for a backend that cannot be cached (NFS, RBD) * Os-brick prevents to attach a volume with cache mode that not safe in cloud environment * e.g. prevent write-back cache mode. So that all the operations, like live migration/snapshot/consistent group/volume backup can work as usual. * Nova schedules the VM with “cacheable” volume to servers with cache capability. * If no such available server, just go ahead without cache, but don’t fail it. * Schedule based on flavor (need more design here with Nova expert) Could you please comment on cinder spec if any before cinder team getting this hammered out? Thank you so much. Below is the performance test I did personally, using Optane SSD p4800x 750G as the cache. Setting fio with block size = 4k, iodepth=1 which is typical for latency measurement. The data may be slightly different on different environment, just FYI: In rand read test: [cid:image004.png@01D5D107.23D05610] In rand write test: [cid:image006.png@01D5D107.23D05610] In 70% rand read + 30% rand write mix test: [cid:image009.png@01D5D107.23D05610] Ceph in above chart means the baseline test, as shown in path ① below. Write-Through and Write-Back means open-cas cached, as shown in path②. [cid:image010.png@01D5D0FD.83839680] So even write-through mode, we still have lots of performance gains. Some concerns maybe: * In real world, the cache hit rate may cannot be so high (95% and more). * It depends on how big the cache device is. But normally a fast SSD with x TB size or a persistent memory with 512G size is big enough for hot data cache. * What will happen when backend storage is RDMA * Pure RDMA network link latency would be as low as ~10us. If plus the disk io to the storage system, the final latency would be dozens of microseconds. So it’s not suitable for an fast ssd(itself ~10us) to cache for RDMA volume, but we can use persistent memory (with latency about hundreds of nanosecond) to do the cache. I will do the measurement after Chinese new year. * It’s a pain that ceph cannot be supported * The major concern to mount ceph volume to host OS is the security considerations, right? It is a performance / security tradeoff for operators. In private cloud which OpenStack maybe mostly used, trust host OS would may be not a big problem, anyway, other backends rather than ceph are still doing in this way. I’m not going to change ceph to mount to host OS in this spec, but it’s not difficult for customer to switch to this way, like they customized other things. Regards LiangFang

1 0

[cinder] virtual mid-cycle summary available
by Brian Rosmaita 22 Jan '20

22 Jan '20

Hello Cinderinos, Thanks for a productive discussion today. I've posted a summary on the wiki so we can remember what happened and for the edification of those who didn't attend: https://wiki.openstack.org/wiki/CinderUssuriMidCycleSummary Also, I've posted a mid-cycle survey to get some feedback about the virtual connectivity and the format of today's meeting: https://forms.gle/muR2vMArZ7Eu1iV46 Please take the survey even if you didn't attend. (What I'm hoping to learn from the non-attendees is whether I could've communicated the event better, or whether the content was un-interesting, or what.) We'll be holding Session Two of the mid-cycle in a few weeks, so your feedback will be helpful in planning. cheers, brian PS: If the survey linked above is inaccessible in your country, please let me know and I'll figure something out so I can collect your feedback. The alternative to google forms I used last time was pretty limited in its free version, plus the only people who used it were located in countries where I know google forms are accessible (Europe & USA), so I succumbed to inertia and stuck with google forms.

1 0

[tc] Follow-up on action tems
by Jean-Philippe Evrard 21 Jan '20

21 Jan '20

Hello TC members, Here are a few things that should keep your attention, on top of the usual reviews... - We should start the business opportunities for 2020. Any takers? - We have action items from the last meeting: - ttx to post a summary of large scale sig's meeting on the ML this week. - mnaser to follow up on the static hosting - mnaser to push an update to distill what happened on the ML in terms of stable branch policy - jungleboyj to update the survey report patch - everyone to let the multi-arch SIG ( https://etherpad.openstack.org/p/Multi-arch) know if you have CI resources in different architectures - We have also new action items: - We should update the governance dashboard to include the "ideas" repo. Anyone? - We need to keep tracking on Telemetry status ( http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011586… ). - Our next meeting will host on 6 February. You can provide suggestion on agenda https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee - ttx should report on his investigation on possible bylaws change for an eventual leadership (tc/uc) merge, UC was more or less okay with the idea, which allows to continue forward the investigation. Note: There is no official stance from the TC on this yet. It's just investigation. - We have updated SIGs tags with https://review.opendev.org/#/c/695625/. This will make sure people aware of the actual status. And as mentioned action ttx and ricolin will works on expose that status tag on governance-sigs' page. And finally, some things to keep in mind: - We need to promote the first contact sig to organisations that might need help on getting things achieved in OpenStack - We need to start collecting ideas for the ideas repo. Regards, JP & Rico

1 0

[all][tc] What happened in OpenStack Governance recently
by Jean-Philippe Evrard 21 Jan '20

21 Jan '20

Hello everyone, It's official, the V release will be codenamed Victoria! The TC is now working on declaring its runtimes [A]. The TC has merged a change in its charter, establishing new rules for the future terms [B]. This will give us leeway for elections and term lengths. The cycle goals selection schedule was made clearer, so that we don't add goals to the teams too late in the future [C]. We have selected the 'project specific PTL and contributor guides' as an official goal for Ussuri. I invite you to read the update of Ghanshyam Mann (gmann) to follow what's going on for our Ussuri goals [D]. You should also have a look at the zuul legacy migration [G], as it could eventually be selected as a V goal :) In terms of release naming, we'll start the W naming process soon, because we know that naming things are hard [E]. If you're interested by security policy, you can have a look at Jeremy's patch [F]. In terms of projects: - There is a new official charm, for watcher [H] - js-openstack-lib is now part of the openstacksdk team [I] - there is a new neutron project, ovn-octavia-provider [J] - the ansible-sig got a new repository, ansible-plugin-container- connection [K] - Justin Ferrieu is the PTL for Cloudkitty for the rest of the cycle [L] - sushi-cli is now part of the ironic team [M] Happy new year to our Chinese community! Regards, Jean-Philippe & Rico [A]: https://review.opendev.org/#/c/693743/ [B]: https://review.opendev.org/#/c/699277/ [C]: https://review.opendev.org/#/c/698299/ [D]: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012019.… [E]: https://review.opendev.org/#/c/702414/ [F]: https://review.opendev.org/#/c/678426/ [G]: https://review.opendev.org/#/c/691278/ [H]: https://review.opendev.org/#/c/702072/ [I]: https://review.opendev.org/#/c/701854/ [J]: https://review.opendev.org/#/c/697095/ [K]: https://review.opendev.org/#/c/696737/ [L]: https://review.opendev.org/#/c/701214/ [M]: https://review.opendev.org/#/c/700914/

1 0

[all][ci] Gate jobs failures because of broken pip
by Takashi Kajinami 21 Jan '20

21 Jan '20

Hi All, I now observe some of the gate jobs are failing[1] because of broken pip[2], and it guess that we need to pin pip to avoid the error atm. [1] https://81b633e2c5fe858f8400-d324a81a71d524d51ede3dc5aee27774.ssl.cf5.rackc… [2] https://github.com/pypa/pip/issues/7217 May I ask for some help to set that pinning ? I couldn't find the correct way to pin pip after several investigation ... Thank you, Takashi -- ---------- Takashi Kajinami Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

3 2

[tripleo][ironic][ansible][openstack-ansible] Ironic/Baremetal Ansible modules
by Sagi Shnaidman 21 Jan '20

21 Jan '20

Hi, all in the light of finding the new home place for openstack related ansible modules [1] I'd like to discuss the best strategy to create Ironic ansible modules. Existing Ironic modules in Ansible repo don't cover even half of Ironic functionality, don't fit current needs and definitely require an additional work. There are a few topics that require attention and better be solved before modules are written to save additional work. We prepared an etherpad [2] with all these questions and if you have ideas or suggestions on how it should look you're welcome to update it. We'd like to decide the final place for them, name conventions (the most complex one!), what they should look like and how better to implement. Anybody interested in Ansible and baremetal management in Openstack, you're more than welcome to contribute. Thanks [1] https://review.opendev.org/#/c/684740/ [2] https://etherpad.openstack.org/p/ironic-ansible-modules -- Best regards Sagi Shnaidman

9 18

[horizon][cloudkitty][tacker][masakari][congress][karbar][trove] Drop python2.7 and Django1.11 support in horizon plugins
by Akihiro Motoki 21 Jan '20

21 Jan '20

Hi, I am sending this mail to encourage reviews in horizon plugins. - Drop python 2.7 and Django 1.11 - Remove six usage Horizon has dropped python 2.7 support and Django 1.11 support (which is the last version with python 2.7 support). We proposed changes to horizon plugins to catch up with these changes. - Most projects have merged them. Thanks for your cooperation. - There are several pending reviews. https://review.opendev.org/#/q/topic:drop-django111-support+status:open - Django 1.11 drop depends on python 2.7 drop. In case of karbar-dashboard, python 2.7 drop needs to land before it. https://review.opendev.org/#/c/694442/ horizon also has dropped six usage. There are plugins which depends six on horizon requirements. We proposed a series of changes to avoid UT breakages in plugins. Reviews on them are also appreciated. https://review.opendev.org/#/q/topic:remove-six+status:open Thanks, Akihiro Motoki (amotoki)

1 0