March 2019 - openstack-discuss - lists.openstack.org

[ZUN] Scaling of containers
by Anirudh Gupta 29 Mar '19

29 Mar '19

I have integrated Zun service with my existing openstack setup and I am able to launch a container using Heat Template. I am facing issue in scaling up of these contaiiners? I already have Senlin being installed at my setup, but senlin is unable to scale the cluster of containers. Can you please suggest any alternative i can use in order to scale Zun Containers Thanks Anirudh Gupta

2 5

[OpenStack][Marketplace]Add driver to openstack.org Marketplace page
by Rong Zhu 29 Mar '19

29 Mar '19

Hi, We want to add our neutron driver to openstack.org Marketplace page's OpenStack Drivers part. Please give me some guidelines. -- Thanks, Rong Zhu

1 0

[tc][ptl][all] Report: OpenStack gate testing migration to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 29 Mar '19

29 Mar '19

Hello Everyone, As we are close to Stein release, I am reporting the status of openstack gate testing on Bionic. Few legacy jobs patches are still under review to mark this activity complete. Currently OpenStack gate is running two type of zuul jobs, 1. DevStack based zuulv3 native jobs2. legacy jobs 1. DevStack based zuulv3 native jobs: These jobs are already migrated to Bionic and all the zuulv3 native jobs run on Bionic[1] 2.Legacy jobs: This is in-progress work. Most of the project's legacy jobs have been migrated along with legacy base jobs migration to bionic[2]. But there are below projects are pending to finish this migration: * Ironic - Patch is in gate to merge * Trove - More work to implement the element script for bionic is needed * networking-midonet - jobs are n-v as midonet is not yet ready on bionic. migration patch is up for review whenever midonet is good for bionic. * neutron - patch is up for review. It need another +2 * Masakari - Partch is up for review. * Glance - Patch is up for review. * tricircle - Patch is up for review. gate is alrwady broken in tricircle. I will contact PTL. I am discussing all the above patches with respective team to merge them soon. Open Patches: https://review.openstack.org/#/q/topic:legacy-job-bionic+status:open [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003761.ht… -gmann

2 4

[all][PTG] Strawman Schedule
by Kendall Nelson 29 Mar '19

29 Mar '19

Hello Everyone, In the attached picture or link [0] you will find the proposed schedule for the various tracks at the Denver PTG in April/May. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts especially when the event is three days long and we have over 40 teams meeting. If there is a critical conflict that was missed, please let us know, but otherwise we are not planning to change this proposal. You'll notice that: - Like in Dublin and the last time we were in Denver, a number of tracks do not get pre-allocated time, and will be scheduled on the spot in available rooms at the time that makes the most sense for the participants. - Every track will be able to book extra time and space in available extra rooms at the event via the PTGBot once its configured for the event. More details to come on that. - Airship & OpenStack Helm will each have a day and a half (with the opportunity to book more time as they need) but we hadn't decided which will go first And here are links to more information about the event[1], on registration[2] or booking a room at the event hotel[3] in case you haven't booked or registered yet :) See you there! -Kendall Nelson (diablo_rojo) [0] https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff… [1]https://www.openstack.org/ptg [2]https://www.eventbrite.com/e/open-infrastructure-summit-project-teams-gat… [3]https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE

5 9

[StarlingX][Nova] Upstream work status
by Dean Troyer 29 Mar '19

29 Mar '19

Last fall the StarlingX TSC approved a change in direction for the project that eliminated the use of private forks of OpenStack projects in favor of directly consuming upstream releases. This entailed a combination of upstreaming certain functionality and bug fixes from the original private forks and simply eliminating the dependency on other changes. In February StarlingX introduced a Kubernetes-based controller architecture that now deploys containerized OpenStack services built using OpenStack Helm and Airship's Armada. The upstreaming effort is still in progress with 31 items across 5 projects complete (or expected to still make Stein) and 20 items remaining to be completed, all in Nova. In preparing for the May release of StarlingX we have identified from this list of 20 items 3 features and 8 bug fixes as critical for the release. The StarlingX TSC is still committed to an upstream-first development process even though we did not reach our targets for Stein. In order to still have a widely usable May release we decided to maintain a branch of Nova Stein where we can backport these critical items as they are merged into Nova master during the Train development cycle. Aside from these 11 potential items[0] this branch will track upstream stable/stein. This branch will be hosted in the existing starlingx-staging/stx-nova repo[1] and I plan to enable a subset of Zuul testing there. The previous master branch will be renamed to stx/old-master in order to sync both master and stable/stein from upstream openstack/nova. So how is this different from the prior forks carried by StarlingX and its predecessor? * There are specific rules for what will be added to stable/stein beyond the upstream backport policy. * It is a one-time thing and the need goes away when these items are released in Train. Why did we choose to not just consume Nova master until Train is released? Of all OpenStack projects, Nova is arguably in the best position for anyone to just 'run from master'. However, the upcoming release of StarlingX is the first one using Kubernetes and has enough potential risk that we want everything else to be as stable as possible. StarlingX also has a long testing cycle since it is a top-to-bottom integrated project and having a core component changing regularly concerns our test and support teams. We will continue to work to complete the upstream items as early in the Train cycle as possible. If you have any questions or concerns please reply here, contact me or anyone on the StarlingX TSC, or find us in IRC at #starlingx. dt [0] The work items are listed in the 'Stein Backport Items' tab of the following spreadsheet: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD… * The last item marked for Glance and Cinder is out of scope here, it is work in a StarlingX project repo [1] https://github.com/starlingx-staging/stx-nova -- Dean Troyer dtroyer(a)gmail.com

3 2

[ops] Any experience with DELL M640 and BCM57840 network card ?
by Massimo Sgaravatto 29 Mar '19

29 Mar '19

Hi Did someone try using DELL M640 with BCM57840 network card as compute nodes ? I am asking because we are adding a new compute node with such hw configuration to our OpenStack Ocata installation (with CentOS 7.6). Each tiime we create a VM on this compute node, the compute node crashes (bnx2x_panic_dump). Not clear which specific event triggers the problem. It doesn't seem a hw problem (e.g. iperf works without problems). We are using the same network card, but on different servers (e.g. on some M630 systems). If we disable the tx-checksum-ipv4 on the data network interface (i.e. "ethtool -K em3 tx-checksum-ipv4 off") we don't see anymore the problem. Thanks, Massimo

3 4

[loci] Best way to clone from private repo
by Jake Yip 28 Mar '19

28 Mar '19

Hi all, We are currently looking at using LOCI to build images. One of the first stumbling blocks that I've faced is that our code is in a private git repo, and by default LOCI was written to clone from public repos. From what I can see so far there are a few ways to solve this problem: 1) Have our code checked out on the builder host into a dir in loci/data. This is the way addressed by patch [1]. This works for us. 2) Update loci scripts to allow `git clone` from a ssh repo. This is partly addressed by another patch [2]. There are still work to be done to add and remove ssh private and host keys into the image. 3) Use a multi-stage build [3]. I think this is cleanest and most exensible, but much more effort. I would love to get some pointers from people working on LOCI what they are using right now. Direction from LOCI core devs on how they would like to solve this problem will be much appreciated. Regards, Jake [1] https://review.openstack.org/#/c/643673/ [2] https://review.openstack.org/#/c/643296/ [3] https://docs.docker.com/develop/develop-images/multistage-build/

1 0

[nova] API office hour continuation
by Ghanshyam Mann 28 Mar '19

28 Mar '19

Hello Everyone, As you might know, we have been conducting the Nova API office hour on every Wed at 06:00 UTC [1]. After my movement to Canada, I will not be able to continue the office hour at the same time and would like to propose the new time. Before proposing the new time, I would like to ask if we want to continue it or we keep the API related discussion in Nova meeting or IRC channel. Please reply if you are interested in keeping the API office hour or meeting to discuss the API related discussion. Based on the number of interested people, I will propose a new time. NOTE: I will continue my Nova API subteam updates over ML irrespective of separate API office hour/meeting or not. [1] https://wiki.openstack.org/wiki/Meetings/NovaAPI -gmann

1 0

[requirements][mistral] Add yamlloader to global requirements
by Oleg Ovcharuk 28 Mar '19

28 Mar '19

Hi! Can you please add yamlloader library to global requirements? https://pypi.org/project/yamlloader/ It provides ability to preserve key order in dicts, it supports either python 2.7 and python 3.x, it provides better performance than built-in functions. Thank you.

8 13

[ansible][heat][openstacksdk][openstack-ansible]
by Bharat Kunwar 28 Mar '19

28 Mar '19

Hello I have a change to `os_stack` module in Ansible (https://github.com/ansible/ansible/pull/53757 <https://github.com/ansible/ansible/pull/53757>) which depended upon a change to openstacksdk which has finally been merged (https://github.com/openstack/openstacksdk/commit/a0ec8ef7fdc7b0860f29223406… <https://github.com/openstack/openstacksdk/commit/a0ec8ef7fdc7b0860f29223406…>). Is anyone on the Ansible side able to take a look at the pull request? Best Bharat

1 0