February 2019 - openstack-discuss

[kolla] Debugging with kolla-ansible
by Michael Still 04 Feb '19

04 Feb '19

Heya, I'm chasing a bug at the moment, and have been able to recreate it with a stock kolla-ansible install. The next step is to add more debugging to the OpenStack code to try and chase down what's happening. Before I go off and do something wildly bonkers, does anyone have a nice way of overriding locally the container image that kolla is using for a given container? The best I've come up with at the moment is something like: - copy the contents of the container out to a directory on the host node - delete the docker container - create a new container which mimics the previous container (docker inspect and some muttering) and have that container mount the copied out stuff as a volume I considered just snapshotting the image being used by the current container, but I want a faster edit cycle than edit, snapshot, start provides. Thoughts? Michael

4 6

[infra][zuul]Run only my 3rd party CI on my environment
by Rikimaru Honjo 04 Feb '19

04 Feb '19

Hello, I have a question about Zuulv3. I'm preparing third party CI for openstack/masakari PJ. I'd like to run my CI by my Zuulv3 instance on my environment. In my understand, I should add my pipeline to the project of the following .zuul.yaml for my purpose. https://github.com/openstack/masakari/blob/master/.zuul.yaml But, as a result, my Zuulv3 instance also run existed pipelines(check & gate). I want to run only my pipeline on my environment. (And, existed piplines will be run on openstack-infra environment.) How can I make my Zuulv3 instance ignore other pipeline? Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@po.ntt-tx.co.jp

2 2

[all] Two months with openstack-discuss (another progress report)
by Jeremy Stanley 03 Feb '19

03 Feb '19

This is just a quick followup to see how things have progressed since we cut the old openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists over to openstack-discuss two months ago, as compared to my previous report[*] from the one-month anniversary. We're still seeing a fair number of posts from non-subscribers landing in the moderation queue (around one or two a day, sometimes more, sometimes less) but most of them are newcomers and many subscribe immediately after receiving the moderation notice. We're now at 830 subscribers to openstack-discuss (up from 708 in the previous report). 75% of the addresses used to send 10 or more messages to the old lists in 2018 are now subscribed to the new one (it was 70% a month ago). While posting volume is up compared to December (unsurprising given the usual end-of-year holiday slump), we only had a total of 958 posts over the month of January; comparing to the 1196 from January 2018 that's a 20% drop which (considering that right at 10% of the messages on the old lists were duplicates from cross-posting), is still less of a drop than was typical on average across the old lists over the previous five Januaries. One change worth mentioning: we noticed a rash of bounce-disabled subscriptions triggered by messages occasionally containing invalid DKIM signatures (inconsistently for some posters, fairly consistently for a few others). We're unsure as of yet whether the messages are arriving with invalid signatures or whether Mailman is modifying them in unanticipated ways prior to forwarding, but have re-enabled all affected subscribers and temporarily turned off the automatic subscription disabling feature while investigation is underway. If you missed receiving some messages which are present in the list archive, that's quite possibly the cause. Apologies for the inconvenience! [*] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001386.… -- Jeremy Stanley

1 0

[goals][upgrade-checkers] Week R-10 Update
by Matt Riedemann 03 Feb '19

03 Feb '19

There are a few open changes: https://review.openstack.org/#/q/topic:upgrade-checkers+status:open Some of those are getting a bit dusty, specifically: * aodh: https://review.openstack.org/614401 * ceilometer: https://review.openstack.org/614400 * cloudkitty: https://review.openstack.org/613076 It looks like the horizon team is moving forward with adding an upgrade check script and discussing how to enable plugin support: https://review.openstack.org/#/c/631785/ As for mistral https://review.openstack.org/#/c/611513/ and swift https://review.openstack.org/#/c/611634/ those should probably just be abandoned since they don't fit with the project plans. There are no other projects that need the framework added: https://storyboard.openstack.org/#!/story/2003657 So once we complete those mentioned above we will have the basic framework in place for teams to add non-placeholder upgrade checks for Stein, and some projects are already leveraging it. This is also a good time for projects that have completed the framework to be thinking about adding specific checks as we get closer to feature freeze on March 7. -- Thanks, Matt

1 0

Suggestions on OpenStack installer
by Maruthi Inukonda 03 Feb '19

03 Feb '19

hi All, We are planning to build a private cloud for our department at academic institution. We are a born-in public-cloud institution. Idea is to have a hybrid cloud. Few important requirements: * No vendor lock-in of hardware and software/distribution. * Preferably stable software from openstack.org. * Also need to support Accelerated instances (GPU,FPGA,Other PCIecard). * On standard rack servers with remote systems management for the nodes (IPMI based) * Need to support Instances [VMs (Qemu-KVM), Containers (Docker, LXC), Bare metal (Ubuntu)]. * Workload will be Software Development/Test (on VMs) and Benchmarking (on baremetal/container). * Smooth upgrades. Could anyone suggest stable Openstack installer for our multi-node setup (initially 40 physical machines, later around 80)? Upgrades should be smooth. Any pointers to reference architecture will also be helpful. PS: I have tried devstack recently. It works. Kolla fails. I tried packstack few years back. Appreciate any help. cheers, Maruthi Inukonda.

3 2

Re: [Openstack] [Nova][Glance] Nova imports flat images from base file despite ceph backend
by Eugen Block 02 Feb '19

02 Feb '19

Hi, I'd like to share that I found the solution to my problem in [1]. It was the config option "cache_images" in nova that is set to "all" per default. Despite changing the glance image properties of my images to raw it didn't prevent nova from downloading a local copy to /var/lib/nova/instances/_base. Setting "cache_images = none" disables the nova image cache, and after deleting all cache files in _base a new instance is not flat anymore but a copy-on-write clone like it's supposed to be. Sorry for the noise in this thread. :-) Have a nice weekend! Eugen [1] https://ask.openstack.org/en/question/79843/prefetched-and-cached-images-in… Zitat von melanie witt <melwittt(a)gmail.com>: > On Fri, 12 Oct 2018 20:06:04 -0700, Remo Mattei wrote: >> I do not have it handy now but you can verify that the image is >> indeed raw or qcow2 >> >> As soon as I get home I will dig the command and pass it on. I have >> seen where images have extensions thinking it is raw and it is not. > > You could try 'qemu-img info <image>' and get output like this, > notice "file format": > > $ qemu-img info test.vmdk > (VMDK) image open: flags=0x2 filename=test.vmdk > image: test.vmdk > file format: vmdk > virtual size: 20M (20971520 bytes) > disk size: 17M > > [1] https://en.wikibooks.org/wiki/QEMU/Images#Getting_information > > -melanie > > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack(a)lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[dev][keystone] Keystone Team Update - Week of 28 January 2019
by Colleen Murphy 01 Feb '19

01 Feb '19

# Keystone Team Update - Week of 28 January 2019 ## News ### JWS Key Rotation Since JSON Web Tokens are asymmetrically signed and not encrypted, we discussed whether we needed to implement the full rotation procedure that we have for fernet tokens and came to the conclusion that probably not[1][2]. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ### Alembic Migration Vishakha reminded us that most projects are moving away from sqlalchemy-migrate to Alembic but that we hadn't done so yet[3]. In fact we already have a spec published for it[4] but we need someone to do the work. Now might be a good time to revive our rolling upgrade testing and revisit how we manage upgrades and migrations. [3] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-01-29-1… [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/… ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 17 changes this week. Among these were changes introducing the JWS token functionality. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 75 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 2 new bugs and closed 6. Bugs opened (2) Bug #1813926 (keystone:Undecided) opened by Shrey bhatnagar https://bugs.launchpad.net/keystone/+bug/1813926 Bug #1813739 (keystonemiddleware:Undecided) opened by Yang Youseok https://bugs.launchpad.net/keystonemiddleware/+bug/1813739 Bugs closed (2) Bug #1805817 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1805817 Bug #1813926 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1813926 Bugs fixed (4) Bug #1813085 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1813085 Bug #1798184 (keystone:Medium) fixed by Corey Bryant https://bugs.launchpad.net/keystone/+bug/1798184 Bug #1804520 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804520 Bug #1798184 (ldappool:Undecided) fixed by no one https://bugs.launchpad.net/ldappool/+bug/1798184 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html This week is the feature proposal freeze, so code implementing specs should be available for review by now. ## Shout-outs Congratulations and thank you to our Outreachy intern Erus for getting CentOS supported in the keystone devstack plugin! Great work! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[openstack-dev][tripleo] TripleO CI Summary: Sprint 25
by Rafael Folco 01 Feb '19

01 Feb '19

Greetings, The TripleO CI team has just completed Sprint 25 / Unified Sprint 4 (Jan 10 thru Jan 30). The following is a summary of completed work during this sprint cycle: - Setup a Fedora-28 promotion pipeline based on the current CentOS-7 pipeline. The Fedora28 pipeline is expected not to work atm, updates from the DF are required and will be pulled in Unified Sprint 5 (Sprint 26). - Completed transition from multinode scenarios (1-4) to standalone across all TripleO projects. Standalone scenarios (1-4) have been fixed with missing services and are now voting jobs. - Continued work on our next-gen upstream TripleO CI job reproducer. Both cloud and libvirt based deployments are working but not fully merged. - Enabled CI on the new openstack-virtual-baremetal repo. The integration CI uses the same standard job as TripleO third party e.g. https://review.openstack.org/#/c/633681/. - Started moving RDO Phase 2 jobs to upstream tripleo by triggering master jobs on tripleo-ci-testing hash. The planned work for the next sprint [1] extends work on previous sprint, which includes: - Add a check job for containers build on Fedora 28 using the new tripleo-build-containers playbook. Update the promotion pipeline jobs to use the same workflow for building containers on CentOS 7 and Fedora 28. - Convert scenarios (9 and 12) from multinode to singlenode standalone. This work will enable upstream TLS CI and testing. - Improve usability of Zuul container reproducer with launcher and user documentation to merge a MVP. - Complete support of additional OVB node in TripleO jobs. - Implement a FreeIPA deployment via CI tooling (tripleo-quickstart / tripleo-quickstart-extras). The Ruck and Rover for this sprint are Felix Quique (quiquell) and Chandan Kumar (chkumar). 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-5 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint26

1 0

[nova] Per-instance serial number implementation question
by Matt Riedemann 01 Feb '19

01 Feb '19

The proposal from the spec for this feature was to add an image property (hw_unique_serial), flavor extra spec (hw:unique_serial) and new "unique" choice to the [libvirt]/sysinfo_serial config option. The image property and extra spec would be booleans but really only True values make sense and False would be more or less ignored. There were no plans to enforce strict checking of a boolean value, e.g. if the image property was True but the flavor extra spec was False, we would not raise an exception for incompatible values, we would just use OR logic and take the image property True value. The boolean usage proposed is a bit confusing, as can be seen from comments in the spec [1] and the proposed code change [2]. After thinking about this a bit, I'm now thinking maybe we should just use a single-value enum for the image property and flavor extra spec: image: hw_guest_serial=unique flavor: hw:guest_serial=unique If either are set, then we use a unique serial number for the guest. If neither are set, then the serial number is based on the host configuration as it is today. I think that's more clear usage, do others agree? Alex does. I can't think of any cases where users would want hw_unique_serial=False, so this removes that ability and confusion over whether or not to enforce mismatching booleans. [1] https://review.openstack.org/#/c/612531/2/specs/stein/approved/per-instance… [2] https://review.openstack.org/#/c/619953/7/nova/virt/libvirt/driver.py@4894 -- Thanks, Matt

9 19