January 2019 - openstack-discuss - lists.openstack.org

[Searchlight] Team meeting cancelled today
by Trinh Nguyen 13 Jan '19

13 Jan '19

Hi team, I will help to coordinate an upstream training webinar at 1400 today [1] so will have to cancel the team meeting. If you guys want to discuss something, please let me know, I will be on the IRC channel. [1] https://www.meetup.com/VietOpenStack/events/257860457/ Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[Searchlight] Nominating Thuy Dang for Searchlight core
by Trinh Nguyen 13 Jan '19

13 Jan '19

Hello team, I would like to nominate Thuy Dang <thuydang.de(a)gmail.com> for Searchlight core. He has been leading the effort to clarify our vision and working on some blueprints to make Searchlight a multi-cloud application. I believe Thuy will be a great resource for our team. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

[tripleo] TripleO Stein milestone 2 released !
by Emilien Macchi 13 Jan '19

13 Jan '19

We just released Stein Milestone 2 for TripleO, thanks all for your work: https://launchpad.net/tripleo/+milestone/stein-2 If your blueprint is done, please mark it as "Implemented" Or move it to stein-3. Bugs in progress will be moved to stein-3 automatically. By the end of the week, I'll move them myself otherwise but please do it if you can. I'll provide interesting stats at the end of Stein, where we compare numbers of fixed bugs and implemented blueprints over the cycles. Thanks, -- Emilien Macchi

1 0

[openstack-ZUN]
by Rania Adouni 13 Jan '19

13 Jan '19

hi everyone , I was trying to deploy wordpress -zun by using heat , this is the template I used "https://pastebin.com/0PGtWSVw" . now the stack create successfully the mysql image running but the wordpress image alwayes stopped and when I try to started and access to the container " openstack appcontainer exec --interactive rho-1-container apache2-foreground " i get this output : ********************************* connected to container "rho-1-container" type ~. to disconnect AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.16.0.3. Set the 'ServerName' directive globally to suppress this message AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.16.0.3. Set the 'ServerName' directive globally to suppress this message [Sun Jan 13 10:07:24.463058 2019] [mpm_prefork:notice] [pid 77] AH00163: Apache/2.4.25 (Debian) PHP/7.2.14 configured -- resuming normal operations [Sun Jan 13 10:07:24.463196 2019] [core:notice] [pid 77] AH00094: Command line: 'apache2 -D FOREGROUND' ***************************************************** and then the status of wordpress image back stopped !!!! the logs of wordpress image can be found here : https://pastebin.com/CitXk6zN thanks for any help !!

2 1

Review-Priority for Project Repos
by Surya Singh 11 Jan '19

11 Jan '19

Dear All, There are many occasion when we want to priorities some of the patches whether it is related to unblock the gates or blocking the non freeze patches during RC. So adding the Review-Priority will allow more precise dashboard. As Designate and Cinder projects already experiencing this[1][2] and after discussion with Jeremy brought this to ML to interact with these team before landing [3], as there is possibility that reapply the priority vote following any substantive updates to change could make it more cumbersome than it is worth. Teams please share your experience of using Review-Priority. [1] https://review.openstack.org/#/c/295253/ [2] https://review.openstack.org/#/c/620664/ [3] https://review.openstack.org/#/c/626824/ --- Best Regards Surya

12 17

[openstack-dev][tripleo] TripleO CI Summary: Sprint 24
by Rafael Folco 11 Jan '19

11 Jan '19

Greetings, The TripleO CI team has just completed Sprint 24 (Dec 20 thru Jan 09). The following is a summary of completed work during this sprint cycle: - Created Zuul configuration and changed repository scripts for the new Fedora 28 promotion pipeline, including container build jobs. - Replaced multinode scenarios(1-4) with standalone scenarios(1-4) jobs across TripleO projects. Also fixed missing services for standalone scenario jobs. A few changes are still “in-flight” and are close to merge. - Tempest is now successfully running on Fedora 28 standalone jobs. - Improved reproducer solution using upstream Zuul containers by moving code to an ansible role in rdo-infra/ansible-role-tripleo-ci-reproducer and automated the libvirt setup. - Created a new OVB workflow without te-broker, moved OVB repo from github to gerrit and did a PoC with new reproducer and OVB jobs. The tebroker is no longer part of the ovb workflow. The planned work for the next sprint [1] are: - Apply changes for Fedora 28 promotion pipeline in production environment to start collecting logs for container build job. - Complete transition from multinode scenarios (1-4) to standalone jobs across all TripleO projects. - Improve the new Zuul container reproducer by automating nodepool config for libvirt. - Enable CI on OVB under ovb’s new git repo in the openstack namespace. - Refactor the upstream zuul job configuration to consolidate file parameters into one repo openstack-infra/tripleo-ci. - Begin to move the RDO-Phase2 Baremetal jobs to upstream tripleo. The Ruck and Rover for this sprint are Arx Cruz (arxcruz) and Sorin Sbarnea (ssbarnea). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Notes are recorded on etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-4 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint25

3 2

Re: Issues setting up a SolidFire node with Cinder
by Jay Bryant 11 Jan '19

11 Jan '19

Grant, Ah, if you are using a different VLAN for your storage traffic than that is likely the cause of the problem. Good luck getting the networking issue resolved. Jay On 1/11/2019 9:12 AM, Grant Morley wrote: > > Jay, > > Thanks for that info. It appears that the cinder-volume service can > speak to the SolidFire over the network but for some reason it can't > actually access it over iSCSI. I think it might be something to do > with how we are tagging / untagging VLANs. > > Thank you for your help, I think I am heading in the right direction now! > > Kind Regards, > > Grant > > On 11/01/2019 14:44, Jay Bryant wrote: >> >> Grant, >> >> Doing the boot from volume is actually quite different than attaching >> a volume to an instance. >> >> In the case that you are doing the boot from volume (assuming that >> your glance storage is not in the Solidfire) the volume is created >> and attached to where the cinder-volume service is running. Then the >> image is written into the volume. >> >> Have you verified that the host and container that is running >> cinder-volume is able to access the Solidfire backend? >> >> Jay >> >> On 1/11/2019 4:45 AM, Grant Morley wrote: >>> >>> Hi Jay, >>> >>> Thanks for the tip there. I am still having some trouble with it >>> which is really annoying. The strange thing is, I can launch a >>> volume and attach it to an instance absolutely fine. The only issue >>> I am having is literally creating this bootable volume. >>> >>> I assume creating a volume and attaching it to an instance is >>> exactly the same as creating a bootable volume minus the Nova part? >>> >>> I would just expect nothing to work if nothing could speak to the >>> SolidFire. >>> >>> Would it make a difference if the current image that is being copied >>> over to the bootable volume is in a ceph cluster? I know glance >>> should deal with it but I am wondering if the copy of the image is >>> the actual issue? >>> >>> Thanks again, >>> >>> On 11/01/2019 00:10, Jay S. Bryant wrote: >>>> >>>> Grant, >>>> >>>> So, the copy is failing because it can't find the volume to copy >>>> the image into. >>>> >>>> I would check the host and container for any iSCSI errors as well >>>> as the backend. It appears that something is going wrong when >>>> attempting to temporarily attach the volume to write the image into it. >>>> >>>> Jay >>>> >>>> On 1/10/2019 7:16 AM, Grant Morley wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We are in the process of trying to add a SolidFire storage >>>>> solution to our existing OpenStack setup and seem to have hit a >>>>> snag with cinder / iscsi. >>>>> >>>>> We are trying to create a bootable volume to allow us to launch an >>>>> instance from it, but we are getting some errors in our >>>>> cinder-volumes containers that seem to suggest they can't connect >>>>> to iscsi although the volume seems to create fine on the SolidFire >>>>> node. >>>>> >>>>> The command we are running is: >>>>> >>>>> openstack volume create --image $image-id --size 20 --bootable >>>>> --type solidfire sf-volume-v12 >>>>> >>>>> The volume seems to create on SolidFire but I then see these >>>>> errors in the "cinder-volume.log" >>>>> >>>>> https://pastebin.com/LyjLUhfk >>>>> >>>>> The volume containers can talk to the iscsi VIP on the SolidFire >>>>> so I am a bit stuck and wondered if anyone had come across any >>>>> issues before? >>>>> >>>>> Kind Regards, >>>>> >>>>> >>>>> -- >>>>> Grant Morley >>>>> Cloud Lead >>>>> Absolute DevOps Ltd >>>>> Units H, J & K, Gateway 1000, Whittle Way, Stevenage, Herts, SG1 2FP >>>>> www.absolutedevops.io <http://www.absolutedevops.io/> >>>>> grant(a)absolutedevops.io <mailto:grant@absolutedevops.io> 0845 874 >>>>> 0580 >>> -- >>> Grant Morley >>> Cloud Lead >>> Absolute DevOps Ltd >>> Units H, J & K, Gateway 1000, Whittle Way, Stevenage, Herts, SG1 2FP >>> www.absolutedevops.io <http://www.absolutedevops.io/> >>> grant(a)absolutedevops.io <mailto:grant@absolutedevops.io> 0845 874 0580 > -- > Grant Morley > Cloud Lead > Absolute DevOps Ltd > Units H, J & K, Gateway 1000, Whittle Way, Stevenage, Herts, SG1 2FP > www.absolutedevops.io <http://www.absolutedevops.io/> > grant(a)absolutedevops.io <mailto:grant@absolutedevops.io> 0845 874 0580

1 0

[RHEL8-OSP15] Container Runtimes integration - Status report #7
by Emilien Macchi 11 Jan '19

11 Jan '19

Welcome to the seventh status report about the progress we make to Container Runtimes into Red Hat OpenStack Platform, version 15. You can read the previous report here: http://post-office.corp.redhat.com/archives/container-teams/2018-December/m… Our efforts are tracked here: https://trello.com/b/S8TmOU0u/tripleo-podman TL;DR =========================================== - Some OSP folks will meet in Brno next week, to work together on RHEL8/OSP15. See [1]. - We have replaced the Docker Healthchecks by SystemD timers when Podman is deployed. Now figuring out the next steps [2]. - Slow progress on the Python-based uploader (using tar-split + buildah), slowed by bugs. - We are waiting for podman 1.0 so we can build / test / ship it in TripleO CI. Context reminder =========================================== The OpenStack team is preparing the 15th version of Red Hat OpenStack Platform that will work on RHEL8. We are working together to support the future Container Runtimes which replace Docker. Done =========================================== - Implemented Podman healthchecks with SystemD timers: https://review.openstack.org/#/c/620372/ - Renamed SystemD services controlling Podman containers to not conflict with baremetal services https://review.openstack.org/#/c/623241/ - podman issues (reported by us) closed: - pull: error setting new rlimits: operation not permitted https://github.com/containers/libpod/issues/2123 - New podman version introduce new issue with selinux and relabelling: relabel failed "/run/netns": operation not supported https://github.com/containers/libpod/issues/2034 - container create failed: container_linux.go:336: starting container process caused "setup user: permission denied" https://github.com/containers/libpod/issues/1980 - "podman inspect --type image --format exists <image>" reports a not-friendly error when image doesn't exist in local storage https://github.com/containers/libpod/issues/1845 - container create failed: container_linux.go:336: starting container process caused "process_linux.go:293: applying cgroup configuration for process caused open /sys/fs/cgroup/cpuset/machine.slice/cpuset.cpus: no such file or directory" https://github.com/containers/libpod/issues/1841 - paunch/runner: test if image exists before running inspect https://review.openstack.org/#/c/619313/ - Fixing a bunch of issues with docker-puppet.py to reduce chances of race conditions. - A lot of SElinux work, to make everything working in Enforced mode. - tar-split packaging is done, and will be consumed in TripleO for the python image uplaoded In progress =========================================== - Still investigating standard_init_linux.go:203: exec user process caused \"no such file or directory\" [5]. This one is nasty and painful. It involves concurrency and we are evaluating solutions, but we'll probably end up reduce the default multi-processing of podman commands from 6 to 3 by default. - Investigating ways to gate new versions of Podman + dependencies: https://review.rdoproject.org/r/#/c/17960/ - Investigating how to consume systemd timers in sensu (healtchecks) [2] - Investigating and prototyping a pattern to safely spawn a container from a container with systemd https://review.openstack.org/#/c/620062 - Investigating how we can prune Docker data when upgrading from Docker to Podman https://review.openstack.org/#/c/620405/ - Using the new "podman image exist" in Paunch https://review.openstack.org/#/c/619313/ - Still implementing a Python-based container uploader (using tar-split and buildah) - this method will be the default later: https://review.openstack.org/#/c/616018/ - Testing future Podman 1.0 in TripleO [3] - Help the Skydive team to migrate to Podman [4] Blocked =========================================== Podman 1.0 contains a lot of fixes that we need (from libpod and vendored as well). Any comment or feedback is welcome, thanks for reading! [1] https://docs.google.com/document/d/18-1M1eSnlls6j2Op2TxyvyuqoOksxmwHOhqaD6B… [2] https://trello.com/c/g6bi5DQF/4-healthchecks [3] https://trello.com/c/2tXNLJUN/58-test-podman-10 [4] https://trello.com/c/tW935FGe/56-migrate-ansible-skydive-to-podman [5] https://github.com/containers/libpod/issues/1844 -- Emilien Macchi

1 1

[ops] OpenStack Operators Meetup, March 2019
by Chris Morgan 11 Jan '19

11 Jan '19

Dear All The OpenStack Ops Meetups team is pleased to announce preliminary details for the next Ops Meetup. The event will be held March 7th and 8th in Berlin, Germany and is being hosted by Deutsche Telekom(DT). We thank them for their kind offer to host this event. The exact venue has not yet been decided but DT has two similar facilities both reserved at present and they will be working out shortly which one works better for them. DT's proposal is here https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019-berlin The meetups team will be sharing the planning docs for the technical agenda in the next few weeks. So far, there has been interest expressed in having a research track at this meetup alongside the general track. Please let us know ASAP if that is of interest. Looking forward to seeing operators in Berlin! Chris Morgan (on behalf of the ops meetups team) -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[Openstack-discuss][Cinder] Fail to mount the volume on the target node
by Minjun Hong 11 Jan '19

11 Jan '19

Hi. After I installed Cinder, I have had a problem which I cannot make instances with volume storage. I created an instance on Horizon and it always has failed. Actually, I'm using Xen as the hypervisor and there was not any special log about Nova. But, in the Xen's log (/var/log/xen/bootloader.5.log), I saw the hypervisor cannot find the volume which is provided by Cinder: Traceback (most recent call last): > File "/usr/lib/xen/bin/pygrub", line 929, in <module> > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel And, I also found something noticeable in the Cinder's log ('/var/log/cinder/cinder-volume.log' on the Block storage node): 2018-12-31 04:08:11.189 12380 INFO cinder.volume.manager > [req-93eb0ad3-6c6c-4842-851f-435e15d8639b bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] Attaching volume > 4c21b8f1-ff07-4916-9692-e74759635978 to instance > bea7dca6-fb04-4791-bac9-3ad560280cc3 at mountpoint /dev/xvda on host None. It seems that Cinder cannot receive information of the target node ('on host None' above) so, I think it can cause the problem that Cinder fails to provide the volume due to lack of the host information. Since I could not find any other logs except that log, I need more hints. Please give me some help Thanks! Regard,

2 1