February 2019 - openstack-discuss

Rally verify issue
by shokoofa Hosseini 05 Feb '19

05 Feb '19

Dear Sir / Madam, I recently install Rally version: 1.3.0 with Installed Plugins: rally-openstack :1.3.0 by python 34. on centos 7 It work property. I benchmark my openstack environment correctly with scenarios of rally. But I have some issue with rally verification create, according to the link bellow: https://docs.openstack.org/developer/rally/quick_start/tutorial/step_10_ver… I run the command: " rally verify create-verifier --type tempest --name tempest-verifier " but I get the bellow error message: "TypeError: startswith first arg must be bytes or a tuple of bytes, not str" What should I do? I will appreciate if you could help me your sincerely shokoofa Attachments area

1 0

OpenStack code and GPL libraries
by Ilya Shakhat 05 Feb '19

05 Feb '19

Hi, I am experimenting with automatic verification of code licenses of OpenStack projects and see that one of Rally dependencies has GPL3 license [1]. I'm not a big expert in licenses, but isn't it a violation of GPL? In particular what concerns me is: [2] - " If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL) Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. " and [3] - " This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0. We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. " [1] http://paste.openstack.org/show/744483/ [2] https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL [3] https://www.apache.org/licenses/GPL-compatibility.html Should this issue be fixed? If yes, should we have a gate job to block adding of such dependencies? Thanks, Ilya

4 4

[tripleo][openstack-ansible] collaboration on os_tempest role update IX - Feb 05, 2019
by Chandan kumar 05 Feb '19

05 Feb '19

Hello, Here is the 9 th update (Jan 29 to Feb 05, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: It was a great week, * we unblocked the os_tempest centos gate failure thanks to slaweq (neutron) and jrosser (OSA) to fixing the tempest container vlan issue. * TripleO is now using os_tempest for standalone job and os_tempest is also getted with the same job: -> http://zuul.openstack.org/builds?job_name=tripleo-ci-centos-7-standalone-os… * Few other improvements: * generate stackviz irrespective of tempest tests failure * Port security is now enabled in tempest.conf * Cirros Image got updated from 3.5 to 3.6 * Use tempest run command with --test-list option Things got merged: os_tempest: * Update all plugin urls to use https rather than git - https://review.openstack.org/625670 * Add an ip address to eth12 in OSA test containers - https://review.openstack.org/633732 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 * Enable port security - https://review.openstack.org/617719 * Use tempest_cloud_name in tempestconf - https://review.openstack.org/631708 * Always generate stackviz irrespective of tests pass or fail - https://review.openstack.org/631967 * Update cirros from 3.5 to 3.6 - https://review.openstack.org/633208 * Disable nova-lxd tempest plugin - https://review.openstack.org/633711 * Only init a workspace if doesn't exists - https://review.openstack.org/633549 * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/633931 Tripleo: * Enable standalone-full on validate-tempest role - https://review.openstack.org/634644 Things IN-Progress: os_tempest: * Ping router once it is created - https://review.openstack.org/633883 * Improve overview subpage - https://review.openstack.org/633934 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Use the correct heat tests - https://review.openstack.org/630695 Tripleo: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Goal of this week: * Finish ongoing patches and reusing of skip list in TripleO from validate-tempest which will allow to move standalone scenario jobs to os_tempest Here is the 8th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002151.… Thanks, Chandan Kumar

1 0

[ironic] [thirdparty-ci] BaremetalBasicOps test
by Michael Turek 05 Feb '19

05 Feb '19

Hello all, Our ironic job has been broken and it seems to be due to a lack of IPs. We allocate two IPs to our job, one for the dhcp server, and one for the target node. This had been working for as long as the job has existed but recently (since about early December 2018), we've been broken. The job is able to clean the node during devstack, successfully deploy to the node during the tempest run, and is successfully validated via ssh. The node then moves to clean failed with a network error [1], and the job subsequently fails. Sometime between the validation and attempting to clean, the neutron port associated with the ironic port is deleted and a new port comes into existence. Where I'm having trouble is finding out what this port is. Based on it's MAC address It's a virtual port, and its MAC is not the same as the ironic port. We could add an IP to the job to fix it, but I'd rather not do that needlessly. Any insight or advice would be appreciated here! Thanks, Mike Turek <mjturek> [1] http://paste.openstack.org/show/743191/

3 3

[neutron] CI meeting this week cancelled
by Slawomir Kaplonski 05 Feb '19

05 Feb '19

Hi, I’m traveling this week and I will not be able to run Neutron CI meeting on Tuesday, 5.02. As some other people usually involved in this meeting are also traveling, lets skip it this week. We will have next meeting as usual on Tuesday, 12.02.2019. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[cinder] Proposed mid-cycle schedule available
by Jay Bryant 04 Feb '19

04 Feb '19

All, I have put together a proposed schedule for our mid-cycle that starts tomorrow. You can see the schedule here: https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning I have tried to keep the topics that are of interest to people in Europe/Asia earlier in the day. If anyone has concerns with the schedule, please add notes in the etherpad. Look forward to meeting with you all tomorrow. Jay

1 0

[karbor][goals][python3] looking for karbor PTL
by Doug Hellmann 04 Feb '19

04 Feb '19

I am trying to reach the Karbor PTL, Pengju Jiao, to ask some questions about the status of python 3 support. My email sent to the address on file in the governance repository has bounced. Does anyone have a current email address? -- Doug

2 1

[goal][python3] week R-9 update
by Doug Hellmann 04 Feb '19

04 Feb '19

This is the periodic update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html) == Current Status == We still have a fairly large number of projects without a python 3 functional test job running at all: adjutant aodh ceilometer cloudkitty cyborg freezer horizon karbor magnum masakari mistral monasca-agent monasca-ui murano murano-agent neutron-vpnaas qinling rally searchlight storlets swift tricircle watcher zaqar networking-l2gw and several with the job listed as non-voting: designate neutron-fwaas sahara senlin tacker I have contacted the PTLs of all of the affected teams directly to ask for updates. == Ongoing and Completed Work == There are still a handful of open patches to update tox, documentation, and python 3.6 unit tests. +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | Team | tox defaults | Docs | 3.6 unit | Failing | Unreviewed | Total | Champion | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | adjutant | 1/ 1 | - | + | 0 | 1 | 2 | Doug Hellmann | | barbican | + | 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | heat | 1/ 8 | + | 1/ 7 | 0 | 0 | 21 | Doug Hellmann | | InteropWG | 2/ 3 | + | + | 0 | 0 | 9 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 | 35 | Doug Hellmann | | magnum | 1/ 5 | + | + | 0 | 0 | 10 | | | masakari | 1/ 4 | + | - | 0 | 1 | 5 | Nguyen Hai | | monasca | 1/ 17 | + | + | 0 | 1 | 34 | Doug Hellmann | | neutron | 2/ 17 | + | + | 1 | 1 | 44 | Doug Hellmann | | OpenStack Charms | 8/ 73 | - | - | 7 | 2 | 73 | Doug Hellmann | | Quality Assurance | 2/ 10 | + | + | 0 | 1 | 31 | Doug Hellmann | | rally | 1/ 3 | + | - | 1 | 1 | 5 | Nguyen Hai | | sahara | 1/ 6 | + | + | 0 | 0 | 13 | Doug Hellmann | | swift | 2/ 3 | + | + | 1 | 1 | 6 | Nguyen Hai | | tacker | 2/ 4 | + | + | 1 | 0 | 9 | Nguyen Hai | | Telemetry | 1/ 7 | + | + | 0 | 1 | 19 | Doug Hellmann | | tripleo | 1/ 54 | + | + | 0 | 1 | 92 | Doug Hellmann | | trove | 1/ 5 | + | + | 0 | 0 | 11 | Doug Hellmann | | User Committee | 3/ 3 | + | - | 0 | 2 | 5 | Doug Hellmann | | | 43/ 61 | 56/ 57 | 54/ 55 | 12 | 14 | 1071 | | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ == Next Steps == We need to be wrapping up work on this goal by approving or abandoning the patches listed above (assuming they aren't needed) and adding the functional test jobs to the projects that don't have them. == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Ve… 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug

1 0

[kolla] Magnum K8s cluster creation time out due to "Failed to contact endpoint at https ... certificate verify failed" error in magnum-conductor
by Giuseppe Sannino 04 Feb '19

04 Feb '19

Hi all, this is my first post on this mailing list especially for "kolla" related issues. Hope you can help and hope this is the right channel to reuqest support. I have a problem with Magnum during the creation of a K8S cluster. The request gets timed out. Looking at the magnum-conductor logs I can see: Failed to contact the endpoint at https://<External IP>:5000 for discovery. Fallback to using that endpoint as the base url.: SSLError: SSL exception connecting to https:// <External IP> :5000: HTTPSConnectionPool(host=' <External IP> ', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),)) I had a similar issue with Kuryr. the service is trying to contact keystone over the external IP address without certificates. In kuryr, the workaround was to set the "endpoint_type" for neutron to "internal". In magnum.conf that's already the situation. Any suggestion on how to address this issue ? Here you can find some details about the deployment: --------------------------- Host nodes: Baremetal OS: Queens kolla-ansible: 6.1.0 Deployment: multinode (1+1). Kolla installed on the controller host kolla_install_type: source kolla_base_distro: ubuntu External/internal interfaces: separated kolla_enable_tls_external: "yes" Services: enable_cinder: "yes" enable_cinder_backend_lvm: "yes" enable_etcd: "yes" enable_fluentd: "yes" enable_haproxy: "yes" enable_heat: "yes" enable_horizon: "yes" enable_horizon_magnum: "{{ enable_magnum | bool }}" enable_horizon_zun: "{{ enable_zun | bool }}" enable_kuryr: "yes" enable_magnum: "yes" enable_openvswitch: "{{ neutron_plugin_agent != 'linuxbridge' }}" enable_zun: "yes" glance_backend_file: "yes" nova_compute_virt_type: "qemu" --------------------------- BR and many thanks in advance /Giuseppe

1 0

Regarding supporting version of Nova-Docker Driver
by Nehal Bansal 04 Feb '19

04 Feb '19

Hi, I have done a manual installation of OpenStack Queens version and wanted to run docker containers on it using Nova-Docker driver. But the git repository says it is no longer a maintained project. Could you tell me if it supports the Queens release. Thank you. Regards, Nehal Bansal

2 1

[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 02 Feb '19

02 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 01 Feb '19

01 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