June 2019 - openstack-discuss - lists.openstack.org

[k8s-sig][cinder] Ember-CSI goes Beta!
by Gorka Eguileor 06 Jun '19

06 Jun '19

Hi, The Ember-CSI team is happy to announce the release of version v0.9, marking the graduation of the project into Beta. Ember-CSI is where Kubernetes storage and OpenStack storage intersect. By leveraging existing Cinder drivers via cinderlib [1], Ember-CSI is able to provide block and mount storage to containers in any Kubernetes cluster supporting the Container Storage Interface (CSI) in a lightweight solution, as it doesn't need to deploy a DBMS or Message Broker systems, and doesn't need to deploy the usual Cinder API, Volume, or Scheduler services either. Key features of the project are: - Multi-driver support on single container - Support for mount filesystems - Support for block - Topology support - Snapshot support - Liveness probe - No need to deploy a DBMS in K8s (uses CRD for metadata) - Multi-CSI version support on single container (v0.2, v0.3, and v1.0) - Storage driver list tool - Support live debugging of running driver - Duplicated requests queuing support (for k8s) - Support of mocked probe (when using faulty sidecars) - Configurable default mount filesystem The Beta is available in Docker Hub [2] -under "stable" and "ember_0.9.0-stein" tags- as well as in PyPi [3]. After this milestone, where we have achieved feature parity with CSI v1.0, we will mostly focus on the areas we consider necessary for the transition into GA: upgrading mechanism, performance improvements, and documentation. If time permits, we will also work on features from newer CSI spec versions, such as volume expansion. For those interested in the project, the team can be reached on FreeNode's #ember-csi channel and at the Google group [4]. We also have a small site [5] with articles on how to try it on K8s with 2 backends (LVM and Ceph) and the github org [6]. Cheers, Gorka. [1]: https://opendev.org/openstack/cinderlib [2]: https://hub.docker.com/r/embercsi/ember-csi [3]: https://pypi.org/project/ember-csi/ [4]: https://groups.google.com/forum/#!forum/embercsi [5]: https://ember-csi.io [6]: https://github.com/embercsi/

1 0

[nova] API updates week 19-23
by gmann＠ghanshyammann.com 06 Jun '19

06 Jun '19

Hi All, Please find the Nova API updates of this week. API Related BP : ============ Code Ready for Review: ------------------------------ 1. Support adding description while locking an instance: - Topic: https://review.opendev.org/#/q/topic:bp/add-locked-reason+(status:open+OR+s… - Weekly Progress: OSC patch has been updated by tssurya. 2. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fl… - Weekly Progress: patches have been updated with review comments. 3. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress Spec Ready for Review: ----------------------------- 1. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: Under review and updates. 2. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. 3. Nova API cleanup - Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: Spec is merged. 4. Specifying az when restore shelved server - Spec: https://review.openstack.org/#/c/624689/ - Weekly Progress: Spec is updated for review comments. 5. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. 7. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Bi-weekly meeting today at 1400 UTC
by Tobias Rydberg 06 Jun '19

06 Jun '19

Hi all, This is a reminder for todays meeting for the Public Cloud SIG - 1400 UTC in #openstack-publiccloud. The main focus for the meeting will be continues discussions regarding the billing initiative. More information about that at https://etherpad.openstack.org/p/publiccloud-sig-billing-implementation-pro… Agenda at: https://etherpad.openstack.org/p/publiccloud-wg See you all later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

Re: [Release-job-failures] Tag of openstack/ironic failed
by Thierry Carrez 06 Jun '19

06 Jun '19

zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/c9/c9009f704afed7579c9d8dfcf7b774623966ef5b/tag/p… : POST_FAILURE in 13m 56s This error occurred after tagging openstack/ironic 11.1.3, due to some transient network issue during release notes build rsync: http://zuul.openstack.org/build/d6f47db4f78b44599c4036a7039a1f5b It prevented release notes for 11.1.3 from being published. However the ironic release notes were regenerated after that, resulting in proper publication: http://zuul.openstack.org/build/e1b75f44857e44b1a94c2499e8b5f742 https://docs.openstack.org/releasenotes/ironic/rocky.html#relnotes-11-1-3-s… Note that the release pipeline jobs completed successfully, so the release itself is OK. Impact: Release notes for ironic 11.1.3 were unavailable for 30min. TODO: None -- Thierry Carrez (ttx)

1 0

[ops] database archiving tool
by Pierre-Samuel LE STANG 06 Jun '19

06 Jun '19

Hi all, At OVH we needed to write our own tool that archive data from OpenStack databases to prevent some side effect related to huge tables (slower response time, changing MariaDB query plan) and to answer to some legal aspects. So we started to write a python tool which is called OSArchiver that I briefly presented at Denver few days ago in the "Optimizing OpenStack at large scale" talk. We think that this tool could be helpful to other and are ready to open source it, first we would like to get the opinion of the ops community about that tool. To sum-up OSArchiver is written to work regardless of Openstack project. The tool relies on the fact that soft deleted data are recognizable because of their 'deleted' column which is set to 1 or uuid and 'deleted_at' column which is set to the date of deletion. The points to have in mind about OSArchiver: * There is no knowledge of business objects * One table might be archived if it contains 'deleted' column * Children rows are archived before parents rows * A row can not be deleted if it fails to be archived Here are features already implemented: * Archive data in an other database and/or file (actually SQL and CSV formats are supported) to be easily imported * Delete data from Openstack databases * Customizable (retention, exclude DBs, exclude tables, bulk insert/delete) * Multiple archiving configuration * Dry-run mode * Easily extensible, you can add your own destination module (other file format, remote storage etc...) * Archive and/or delete only mode It also means that by design you can run osarchiver not only on OpenStack databases but also on archived OpenStack databases. Thanks in advance for your feedbacks. -- Pierre-Samuel Le Stang

5 10

[oslo] Bandit Strategy
by Ben Nemec 06 Jun '19

06 Jun '19

Nefarious cap bandits are running amok in the OpenStack community! Won't someone take a stand against these villainous headwear thieves?! Oh, sorry, just pasted the elevator pitch for my new novel. ;-) Actually, this email is to summarize the plan we came up with in the Oslo meeting this morning. Since we have a bunch of projects affected by the Bandit breakage I wanted to make sure we had a common fix so we don't have a bunch of slightly different approaches in each project. The plan we agreed on in the meeting was to push a two patch series to each repo - one to cap bandit <1.6.0 and one to uncap it with a !=1.6.0 exclusion. The first should be merged immediately to unblock ci, and the latter can be rechecked once bandit 1.6.1 releases to verify that it fixes the problem for us. We chose this approach instead of just tweaking the exclusion in tox.ini because it's not clear that the current behavior will continue once Bandit fixes the bug. Assuming they restore the old behavior, this should require the least churn in our repos and means we're still compatible with older versions that people may already have installed. I started pushing patches under https://review.opendev.org/#/q/topic:cap-bandit (which prompted the digression to start this email ;-) to implement this plan. This is mostly intended to be informational, but if you have any concerns with the plan above please do let us know immediately. Thanks. -Ben

8 32

[kolla][tripleo] Podman/buildah
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, At the Denver forum during the kolla feedback session [1], the topic of support for podman [2] and buildah [3] was raised. RHEL/CentOS 8 removes support for Docker [4], although presumably it will still be possible to pull down an RPM from https://download.docker.com/linux/. Currently both kolla and kolla-ansible interact with docker via the docker python module [5], which interacts with the docker daemon API. Given that podman and buildah are not daemons, I would expect the usage model to be a bit different. There is a python API for podman [6] which we might be able to use. I understand that Tripleo uses buildah to build images already (please correct me if I'm wrong). How is this achieved with kolla? Perhaps using 'kolla-build --template-only' to generate Dockerfiles then invoking buildah separately? Are you planning to work on adding buildah support to kolla itself? For running services, Tripleo uses Paunch [7] to abstract away the container engine, and it appears Podman support was added here - building CLI argument strings rather than via a python API [8]. For anyone using kolla/kolla-ansible, please provide feedback on how useful/necessary this would be to you. Thanks, Mark [1] https://etherpad.openstack.org/p/DEN-train-kolla-feedback [2] https://podman.io/ [3] https://buildah.io/ [4] https://access.redhat.com/solutions/3696691 [5] https://github.com/docker/docker-py [6] https://github.com/containers/python-podman [7] https://docs.openstack.org/developer/paunch/readme.html [8] https://github.com/openstack/paunch/blob/ecc2047b2ec5eaf39cce119abe1678ac19…

5 8

[airship] Is Ironic ready for Airship?
by 郭勇 06 Jun '19

06 Jun '19

I know Airship choose Maas as bare mental management tool. I want to know whether Maas is more suitable for Airship when it comes to under-infrastructure? If Maas is more suitable, then what feature should ironic develop? Thanks for your reply

2 1

[kolla][tripleo] Python 3, CentOS/RHEL 8
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, At the recent kolla virtual PTG [1], we discussed the move to python 3 images in the Train cycle. hrw has started this effort for Ubuntu/Debian source images [2] and is making good progress. Next we will need to consider CentOS and RHEL. It seems that for Train RDO will provide only python 3 packages with support for CentOS 8 [3]. There may be some overlap in the trunk (master) packages where there is support for both CentOS 7 and 8. We will therefore need to combine the switch to python 3 with a switch to a CentOS/RHEL 8 base image. Some work was started during the Stein cycle to support RHEL 8 images with python 3 packages. There will no doubt be a few scripts that need updating to complete this work. We'll also need to test to ensure that both binary and source images work in this new world. Tripleo team - what are your plans for CentOS/RHEL 8 and python 3 this cycle? Are you planning to continue the work started in kolla during the Stein release? Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg [2] https://blueprints.launchpad.net/kolla/+spec/debian-ubuntu-python3 [3] https://review.rdoproject.org/etherpad/p/moving-rdo-to-centos8 [4] https://review.opendev.org/#/c/632156/

2 2

[upgrade][neutron] supported release window on rolling upgrade
by Akihiro Motoki 06 Jun '19

06 Jun '19

The neutron team is discussing how many releases we should support in RPC messages [1] (to drop downgrade codes in OVO). This affects rolling upgrade scenarios. Controller nodes are upgrade in FFU way, but we cannot upgrade compute nodes at once. This means controller nodes with N+X release need to talk compute nodes with N release. As of now, the neutron team is thinking to support LTS to LTS upgrade scenarios for major distributions and N->N+4 looks like the longest window. Rolling upgrade scenarios affect not only neutron but also other projects like nova, so I am sending this mail for broader input. [1] https://review.opendev.org/#/c/661995/ Thanks, Akihiro Motoki (irc: amotoki)

1 0