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

[magnum] Persistent Volume Claim with cinder backend
by Christian Zunker 24 Jan '19

24 Jan '19

Hi, we are running Magnum Rocky. I tried to create a persistent volume claim and got it working with provisioner: kubernetes.io/cinder But it failed with provisioner: openstack.org/standalone-cinder The docs state kubernetes.io/cinder is deprecated: https://kubernetes.io/docs/concepts/storage/storage-classes/#openstack-cind… Which one should be used in Rocky? This is our complete config for this case: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: cinder annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: EnsureExists provisioner: openstack.org/standalone-cinder parameters: type: volumes_hdd availability: cinderAZ_ceph --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 42Gi storageClassName: cinder regards Christian

2 1

[ptl][goals][python3] please update your team's status in the wiki
by Doug Hellmann 24 Jan '19

24 Jan '19

I noticed this morning that the last time the Python 3 status page [1] was updated in the wiki was August. I hope we've had changes to the level of support since then. Keeping that page up to date is part of fulfilling the goal this cycle. Please take a few minutes to review the content today and update it if necessary. Thanks! [1] https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projec… -- Doug

2 2

[openstack-dev] [neutron]
by Farhad Sunavala 24 Jan '19

24 Jan '19

Hi, I am open to suggestions.We have a need to switch traffic from our project to other projects without first getting out on the internet, floating IPs, etc. The other projects will be sharing their networks with our project.As shown in figure below, the orange network belongs to our project (10.0.0.0/26) The green network (172.31.0.0/24) belongs to another project andhas an overlapping network with the red tenant (172.31.0.0/16) For now, the solution is to create VMs in our project and make sure none of the interfaceshaving overlapping CIDRs. Thus, there is a VM attached to the 'orange' and 'red' netsand another VM attached to the 'orange' and 'green' nets. Problem: Too much resources (VMs) will need to be created if we have 100 tenants with overlapping networks. Solution:Is there a way I can minimize VM resource in our project by not allocating a separate VMfor shared networks with overlapping CIDRs? thanks,

3 3

[tc][telemetry][horizon] ceilometer-dashboard repository creation
by Jakub Slíva 24 Jan '19

24 Jan '19

Hello, our company created a little plugin to Horizon and we would like to share it with the community in a bit more official way. So I created change request (https://review.openstack.org/#/c/619235/) in order to create official repository under project Telemetry. However, PTL recommended me to put this new repository under OpenStack without any project - i.e. make it unofficial. I have also discussed this with Horizon team during their meeting (http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.…) and now I am bit stuck because I do not know how to proceed next. Could you, please, advise me? All opinions are appreciated. Jakub Sliva Ultimum Technologies s.r.o. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic http://ultimum.io

4 4

[cinder] volume snapshot on queens not working as in ocata
by Ignazio Cassano 24 Jan '19

24 Jan '19

2 3

Re: [docs] Nominating Alex Settle for openstack-doc-core
by Chason 23 Jan '19

23 Jan '19

So glad to see you back to us, Alex! \o/ Absolutely agree with this Nominating. > Date: Fri, 18 Jan 2019 14:42:33 +0100 > From: Petr Kovar <pkovar(a)redhat.com> > To: openstack-discuss(a)lists.openstack.org > Cc: Alex Settle <asettle(a)suse.com> > Subject: [docs] Nominating Alex Settle for openstack-doc-core > Message-ID: <20190118144233.132eb0e427389da15e725141(a)redhat.com> > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > Alex Settle recently re-joined the Documentation Project after a few-month > break. It's great to have her back and I want to formally nominate her for > membership in the openstack-doc-core team, to follow the formal process for > cores. > > Please let the ML know should you have any objections. > > Thanks, > pk > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list > openstack-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > > ------------------------------ > > End of openstack-discuss Digest, Vol 3, Issue 110 > *************************************************

1 0

[Release-job-failures] Release of openstack/sqlalchemy-migrate failed
by Sean McGinnis 23 Jan '19

23 Jan '19

There were release job failures with the latest sqlalchemy-migrate release. It appears it is another one of the issues with the readthedocs configuration not being correct. Everything else appears to have succeeded, so the new release is available. It just might need the published documentation manually updated. ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 23 Jan 2019 22:54:02 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Release of openstack/sqlalchemy-migrate failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - trigger-readthedocs-webhook http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : FAILURE in 2m 04s - release-openstack-python http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 4m 09s - announce-release http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 5m 51s - propose-update-constraints http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 3m 44s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

3 3

[infra][dev] Zuul promote pipeline for container publishing
by corvus＠inaugust.com 23 Jan '19

23 Jan '19

Hi, We recently added a new pipeline to OpenStack's Zuul, and three new jobs and roles to the zuul-jobs repo to support container publishing. If your project publishes containers, or may do so in the future, read on. The new pipeline is the "promote" pipeline. It runs jobs on changes after they merge, but unlike the "post" pipeline, it does not run with the resulting branch state after the merge -- it runs in the context of the change. This means that it's not suitable for building release artifacts, but that's not its purpose. Its purpose is to promote artifacts previously built in the gate pipeline to production. That is safe to do because anything built in the gate pipeline is built with the full future state of in-flight changes to all related projects and branches (even if it's built before they land). We build a lot of artifacts in the gate pipeline now, and then throw them away only to build them again in post. The promote pipeline is an attempt to avoid that waste and instead preserve artifacts built in gate and directly publish them -- but only if and when the changes for which they were built are merged. The first functional use of this system is in building container images and publishing them on Docker Hub. We have begun using this in openstack-infra to build container images of third-party applications, but this will work just as well and as easily for building images of applications in our infrastructure (for example, we are also starting to use this to publish Zuul images). To implement this, we wrote three jobs which are available now from zuul-jobs (and therefore can be used in any project or job in the system): * build-docker-image [1] * upload-docker-image [2] * promote-docker-image [3] The first job should run in the check pipeline and simply runs "docker build" on the arguments passed to it. It is used to verify that the build succeeds. The second job should run in the gate pipeline. It uploads the image to Docker Hub into the final repository location, but it only does so with a single tag with the form "change_123456" where '123456' is the Gerrit change number for the change under consideration. This will mean that docker pulls won't accidentally fetch the image yet. But the image is staged in Docker Hub and is ready to be promoted if the change passes all its tests and merges. The third job runs in the promote pipeline. This job, unlike the others, only performs Docker Hub API calls and requires no build resources. Therefore it is a zero-node job in Zuul -- a job which only runs on the Zuul executor. This job finds a previously uploaded image with a "change_" tag, and re-tags it with any specified tags ("latest" by default, but you can also tag version numbers or anything else). It also cleans up unused "change_" tags so they don't clutter up the repository. The nice thing about zero-node jobs is that they start and finish very quickly (since they don't have to deal with resource allocation and contention). With this system, an image will be fully published within about a minute after the change merges. To use this system, you will need to create (if you haven't done so already) a credential which is permitted to upload to an organization on Docker Hub, and you will need to add a secret [4] to Zuul for it. A complete example .zuul.yaml might look like this: - secret: name: myproject-dockerhub data: username: dockerhubuser password: !encrypted/pkcs1-oaep - DFlbrDM5eUMptMGIVMXV1g455xOJLi92UYF08Z2/JlIGu3t6v052o9FKlVyj1ZmpXs5+2 JTa5jHkLTvTsYs9fCaNcQc2nmViCyWNlbOMzjB17uiZOaYFNs1sMqZcUZbGEz7Y8ds6Qq NBXI10jWFPTah4QxUuBvUbT3vmjnUToCzexl5ZGhKgijcnROWfUsnlCdugpgoNIcPsUki zty5FotDihnrC8n8vIomVK6EClY38ty97pLrADzFDd+Cos/OUlvi2xooUhzx8Bn020rJA lqEU5v8LGXp5QkHx0MSDx6JY6KppJ/4p/yM+4By6l+A20zdcimxmgiNc9rMWPwDj7xsao m7NAZWmWqOO0Xkhgt6WOfugwgt9X46sgs2+yDEfbnI5ok8uRbAB/4FWj/KdpyXwhcf+O2 wEfhxLwDbAoGONQPjb4YcZmCXtmR7Qe5t+n2jyczWXvrbaBDUQP5a+YtVNN/xhmQ7D740 POlxv7bLxJAixzqaQ3d8Rz9ZEv6zzRuhWph32UQtZ1JxSNww+EvmXm2eEi2Q2z6pT1Cx/ j2OrFyA2GL/UJOVb15VHKF6bgHPHWJtpjPFhqdcvBhVute4BWB+KPcWH+y+apHN1enK3H tNJO9iqm34nKwSuj5ExmFw50LtwR5/9FyRuRPq/vBL+8y82v8FDmeYsBeobn5M= - job: name: myproject-build-image parent: build-docker-image description: Build Docker images. vars: &image_vars docker_images: - context: . repository: myproject/imagename - job: name: myproject-upload-image parent: upload-docker-image description: Build Docker images and upload to Docker Hub. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - job: name: myproject-promote-image parent: promote-docker-image description: Promote previously uploaded Docker images. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - project: check: jobs: - myproject-build-image gate: jobs: - myproject-upload-image promote: jobs: - myproject-promote-image If you find that you need jobs which behave slightly differently, you may be able to inherit from these jobs and add pre or post playbooks. Or if you need something particularly complicated, you can re-implement the jobs using the underlying roles in zuul-jobs, which have the same names an the jobs which invoke them. [1] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-build-docker-image [2] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-upload-docker-image [3] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-promote-docker-image [4] https://zuul-ci.org/docs/zuul/user/encryption.html

1 0

[Cinder][nova] queens backup
by Ignazio Cassano 23 Jan '19

23 Jan '19

Hi All, Please, I' d like to know if cinder backup and/or cinder snapshot call qemu guest agent for fsfreezing. If Yes, does it freeze file systems in the volume? Regards Ignazio

6 12

Re: [openstack-dev] [tripleo] reducing our upstream CI footprint
by Wesley Hayutin 23 Jan '19

23 Jan '19

On Thu, Nov 1, 2018 at 5:47 AM Derek Higgins <derekh(a)redhat.com> wrote: > On Wed, 31 Oct 2018 at 17:22, Alex Schultz <aschultz(a)redhat.com> wrote: > > > > Hey everyone, > > > > Based on previous emails around this[0][1], I have proposed a possible > > reducing in our usage by switching the scenario001--011 jobs to > > non-voting and removing them from the gate[2]. This will reduce the > > likelihood of causing gate resets and hopefully allow us to land > > corrective patches sooner. In terms of risks, there is a risk that we > > might introduce breaking changes in the scenarios because they are > > officially non-voting, and we will still be gating promotions on these > > scenarios. This means that if they are broken, they will need the > > same attention and care to fix them so we should be vigilant when the > > jobs are failing. > > > > The hope is that we can switch these scenarios out with voting > > standalone versions in the next few weeks, but until that I think we > > should proceed by removing them from the gate. I know this is less > > than ideal but as most failures with these jobs in the gate are either > > timeouts or unrelated to the changes (or gate queue), they are more of > > hindrance than a help at this point. > > > > Thanks, > > -Alex > > While on the topic of reducing the CI footprint > > something worth considering when pushing up a string of patches would > be to remove a bunch of the check jobs at the start of the patch set. > > e.g. If I'm working on t-h-t and have a series of 10 patches, while > looking for feedback I could remove most of the jobs from > zuul.d/layout.yaml in patch 1 so all 10 patches don't run the entire > suite of CI jobs. Once it becomes clear that the patchset is nearly > ready to merge, I change patch 1 leave zuul.d/layout.yaml as is. > > I'm not suggesting everybody does this but anybody who tends to push > up multiple patch sets together could consider it to not tie up > resources for hours. > > > > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html > > [2] > https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR… > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Greetings, Just a quick update.. The TripleO CI team is just about done migrating multinode scenario 1-4 jobs to the SingleNode job. This update and a few other minor changes have moved the needle with regards to TripleO's upstream resource consumption. In October of 2017 we had the following footprint.. tripleo: 111256883.96s, 52.45% [1] Today our footprint is now.. tripleo: 313097590.30s, 36.70% [2] We are still working the issue and we should see further improvement over the next couple months. I'll update the list again at the end of Stein. Thanks to Clark, Doug, Alex, Emilien and Juan for the work to make this happen!! Also thank you to the folks on the TripleO-CI team, you know who you are :) [1] http://paste.openstack.org/show/733644/ [2] http://paste.openstack.org/show/743188/

1 0