February 2019 - openstack-discuss

[ptg][nova][placement] Etherpad & collector started
by Eric Fried 12 Feb '19

12 Feb '19

I needed to brain-dump some topics to be discussed at the PTG in a couple of months. I asked if there was already an etherpad and the two people who happened to hear my question weren't aware of one, so I started one [1]. I also started the collector wiki page [2], templated on the Stein one [3]. Enjoy. -efried [1] https://etherpad.openstack.org/p/nova-ptg-train [2] https://wiki.openstack.org/wiki/PTG/Train/Etherpads [3] https://wiki.openstack.org/wiki/PTG/Stein/Etherpads

1 0

[dev][keystone] Keystone Team Update - Week of 4 February 2019
by Colleen Murphy 11 Feb '19

11 Feb '19

# Keystone Team Update - Week of 4 February 2019 ## News ### Performance of Loading Fernet/JWT Key Repositories Lance noticed that it seems that token signing/encryption keys are loaded from disk on every request and is therefore not very performant, and started investigating ways we could improve this[1][2]. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 10 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 73 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 3. Bugs opened (2) Bug #1814589 (keystone:High) opened by Guang Yee https://bugs.launchpad.net/keystone/+bug/1814589 Bug #1814570 (keystone:Medium) opened by Guang Yee https://bugs.launchpad.net/keystone/+bug/1814570 Bugs fixed (3) Bug #1804483 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804483 Bug #1805406 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805406 Bug #1801095 (keystone:Wishlist) fixed by Artem Vasilyev https://bugs.launchpad.net/keystone/+bug/1801095 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Feature freeze is in four weeks. Be mindful of the gate and try to submit and review things early. ## Shout-outs Congratulations and thank you to our Outreachy intern Islam for completing the first step in refactoring our unit tests to lean on our shiny new Flask framework! Great work! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

2 1

[nova] Floppy drive support — does anyone rely on it?
by Kashyap Chamarthy 11 Feb '19

11 Feb '19

Question for operators: Do anyone rely on floppy disk support in Nova? Background ---------- The "VENOM" vulnerability (CVE-2015-3456)[1] was caused due to a Floppy Disk Controller (FDC) being initialized for all x86 guests, regardless of their configuration — so even if a guest does not explicitly have a virtual floppy disk configured and attached, this issue was exploitable. As a result of that, upstream QEMU has suppressed the FDC for modern machine types (e.g. 'q35') by default — commit ea96bc629cb; from QEMU v2.4.0 onwards. From the commit message: "It is Very annoying to carry forward an outdatEd coNtroller with a mOdern Machine type." QEMU users can still get floppy devices, but they have to ask for them explicitly on the command-line. * * * Given that, and the use of floppy drives is generally not recommended in 2019, any objection to go ahead and remove support for floppy drives? Currently Nova allows the use of the floppy drive via these two disk image metadata properties: - hw_floppy_bus=fd - hw_rescue_device=floppy Filed this blueprint[2] to track this. * * * [1] https://access.redhat.com/articles/1444903 [2] https://blueprints.launchpad.net/nova/+spec/remove-support-for-floppy-disks -- /kashyap

2 2

[keystone] adfs SingleSignOn with CLI/API?
by Fabian Zimmermann 11 Feb '19

11 Feb '19

Hi, Im currently trying to implement some way to do a SSO against our ActiveDirectory. I already tried SAMLv2 and OpenID Connect. Im able to sign in via Horizon, but im unable to find a working way on cli. Already tried v3adfspassword and v3oidcpassword, but im unable to get them working. Any hints / links / docs where to find more information? Anyone using this kind of setup and willing to share KnowHow? Thanks a lot, Fabian Zimmermann

2 1

Re: [TripleO][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes: UPDATE
by Bogdan Dobrelya 11 Feb '19

11 Feb '19

Good news: so the %systemd_ordering macro works well for containers images to build it w/o systemd & deps pulled in, and the changes got accepted for RDO and some of the base packages for f29! Bad news: [0] is a show stopper for removing systemd off the base RHEL/Fedora containers in Kolla. To mitigate that issue for the remaining dnf and puppet, and as well for the less important* to have it fixed iscsi-initiator-utils and kuryr-kubernetes-distgit, we need to consider using microdnf instead of dnf for installing RPM packages in Kolla. Or alternatively somehow to achieve a trick with _tmpfiles to be split off the main spec files into sub-packages [1]: if the tmpfiles and such were split out into a subpackage that'd be required if and only if the kernel was installed or being installed, that might work. * it is only less important as those do not belong to the Kolla base/openstack-base images and impacts only its individual containers images. [0] https://bugs.launchpad.net/tripleo/+bug/1804822/comments/17 [1] https://github.com/rpm-software-management/dnf/pull/1315#issuecomment-46232… > Here is an update. > The %{systemd_ordering} macro is proposed for lightening containers > images and removing the systemd dependency for containers. Please see & > try patches in the topic [0] for RDO, and [1][2][3][4][5] for generic > Fedora 29 rpms. I'd very appreciate if anyone building Kolla containers > for f29/(rhel8 yet?) could try these out as well. > > PS (somewhat internal facing but who cares): I wonder if we could see > those changes catched up automagically for rhel8 repos as well? > >> I'm tracking systemd changes here [0],[1],[2], btw (if accepted, >> it should be working as of fedora28(or 29) I hope) >> >> [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1668688 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1668687 > [5] https://bugzilla.redhat.com/show_bug.cgi?id=1668678 -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[cinder][nova][os-brick] os-brick initiator rename
by Kulazhenkov, Yury 11 Feb '19

11 Feb '19

Hi all, Some time ago Dell EMC software-defined storage ScaleIO was renamed to VxFlex OS. I am currently working on renaming ScaleIO to VxFlex OS in Openstack code to prevent confusion with storage documentation from vendor. This changes require patches at least for cinder, nova and os-brick repos. I already submitted patches for cinder(634397) and nova(634866), but for now code in these patches relies on os-brick initiator with name SCALEIO. Now I'm looking for right way to rename os-brick initiator. Renaming initiator in os-brick library and then make required changes in nova and cinder is quiet easy, but os-brick is library and those changes can break someone else code. Is some sort of policy for updates with breaking changes exist for os-brick? One possible solution is to rename initiator to new name and create alias with deprecation warning for old initiator name(should this alias be preserved more than one release?). What do you think about it? Thanks, Yury

3 2

Horizon extremely slow with 400 instances
by Satish Patel 11 Feb '19

11 Feb '19

folks, we have mid size openstack cloud running 400 instances, and day by day its getting slower, i can understand it render every single machine during loading instance page but it seems it's design issue, why not it load page from MySQL instead of running bunch of API calls behind then page? is this just me or someone else also having this issue? i am surprised why there is no good and robust Web GUI for very popular openstack? I am curious how people running openstack in large environment using Horizon. I have tired all kind of setting and tuning like memcache etc.. ~S

3 2

[infra][upstream-institute] Bot to vote on changes in the sandbox
by Tony Breeds 11 Feb '19

11 Feb '19

Hi All, During the Berlin forum the idea of running some kinda of bot on the sandbox [1] repo cam up as another way to onboard/encourage contributors. The general idea is that the bot would: 1. Leave a -1 review on 'qualifying'[2] changes along with a request for some small change 2. Upon seeing a new patchset to the change vote +2 (and possibly +W?) on the change Showing new contributors approximately what code review looks like[2], and also reduce the human requirements. The OpenStack Upstream Institute would make use of the bot and we'd also use it as an interactive tutorial from the contributors portal. I think this can be done as a 'normal' CI job with the following considerations: * Because we want this service to be reasonably robust we don't want to code or the job definitions to live in repo so I guess they'd need to live in project-config[4]. The bot itself doesn't need to be stateful as gerrit comments / meta-data would act as the store/state sync. * We'd need a gerrit account we can use to lodge these votes, as using 'proposal-bot' or tonyb would be a bad idea. My initial plan would be to develop the bot locally and then migrate it into the opendev infra once we've proven its utility. So thoughts on the design or considerations or should I just code something up and see what it looks like? Yours Tony. [1] http://git.openstack.org/cgit/openstack-dev/sandbox [2] The details of what counts as qualifying can be fleshed out later but there needs to be something so that contributors using the sandbox that don't want to be bothered by the bot wont be. [3] So it would a) be faster than typical and b) not all new changes are greeted with a -1 ;P [4] Another repo would be better as project-config is trusted we can't use Depends-On to test changes to the bot itself, but we need to consider the bots access to secrets

6 11

D&I WG Meeting Reminder
by Amy Marrich 11 Feb '19

11 Feb '19

The Diversity & Inclusion WG will hold it's next meeting Monday(2/11) at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Including the discuss list to invite potential new members! Thanks, Amy (spotz)

1 0

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

10 Feb '19

The only change since last week [1] is the swift patch was abandoned. The next closest patches to merge should be cloudkitty, ceilometer and aodh so if someone from those teams is reading this please check the open reviews [2]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002328… [2] https://review.openstack.org/#/q/topic:upgrade-checkers+status:open -- Thanks, Matt

1 0

[tripleo] puppet failing with "cannot load such file -- json"
by Lars Kellogg-Stedman 09 Feb '19

09 Feb '19

Our "openstack tripleo deploy" is failing during "step 1" while trying to configure swift. It looks like the error comes from puppet apply. Looking at the ansible output, the command is: /usr/bin/puppet apply --summarize --detailed-exitcodes \ --color=false --logdest syslog --logdest console \ --modulepath=/etc/puppet/modules:/usr/share/openstack-puppet/modules \ --tags file,file_line,concat,augeas,cron,swift_config,swift_proxy_config,swift_keymaster_config,swift_config,swift_container_config,swift_container_sync_realms_config,swift_account_config,swift_object_config,swift_object_expirer_config,rsync::server \ /etc/config.pp And the error is: "cannot load such file -- json" We're running recent delorean packages: so, python-tripleoclient @ 034edf0, and puppet-swift @ bc8dc51. -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

2 2

[nova][dev] 4 weeks until feature freeze
by melanie witt 09 Feb '19

09 Feb '19

Hey all, We've 4 weeks left until feature freeze milestone s-3 on March 7. I've updated the blueprint status tracking etherpad: https://etherpad.openstack.org/p/nova-stein-blueprint-status For our Cycle Themes: Multi-cell operational enhancements: We have good progress going on handling of down cells and cross-cell resize. Counting quota usage from placement is still a WIP and I will be pushing updates this week. Compute nodes able to upgrade and exist with nested resource providers for multiple vGPU types: This effort has stalled during the cycle but the libvirt driver reshaper patch has updates coming soon. The xenapi driver reshaper patch has a -1 from Nov 28 and has not been updated yet in response. Help is needed here. The patches for multiple vGPU types (libvirt and xenapi) are stale since Rocky (as they depend on the reshapers). Volume-backed user experience and API improvement: The ability to specify volume type during server create is complete since 2018-10-16. However, the patches for being able to detach a boot volume and volume-backed server rebuild are in merge conflict/stale. Help is needed here. If you are the owner of an approved blueprint, please: * Add the blueprint if I've missed it * Update the status if it is not accurate * If your blueprint is in the "Wayward changes" section, please upload and update patches as soon as you can, to allow maximum time for review * If your patches are noted as Merge Conflict or WIP or needing an update, please update them and update the status on the etherpad * Add a note under your blueprint if you're no longer able to work on it this cycle Let us know if you have any questions or need assistance with your blueprint. Cheers, -melanie

2 2

[cinder][qa] Cinder 3rd party CI jobs and multiattach tests
by Matt Riedemann 09 Feb '19

09 Feb '19

With tempest change [1] the multiattach tests are enabled in tempest-full, tempest-full-py3 and tempest-slow job configurations. This was to allow dropping the nova-multiattach job and still retain test coverage in the upstream gate. There are 3rd party CI jobs that are basing their job configs on these tempest job configs, and as a result they will now fail if the storage backend driver does not support multiattach volumes and the job configuration does not override and set: ENABLE_VOLUME_MULTIATTACH: false in the tempest job config, like was done in the devstack-plugin-ceph-tempest jobs [2]. Let me know if there are any questions. [1] https://review.openstack.org/#/c/606978/ [2] https://review.openstack.org/#/c/634977/ -- Thanks, Matt

1 0

[telemetry][cloudkitty][magnum][solum][tacker][watcher][zun][release] Switching to cycle-with-rc
by Sean McGinnis 09 Feb '19

09 Feb '19

Following up from [1], I have proposed changes to a few cycle-with-intermediary service releases to by cycle-with-rc. We've already received some feedback from the affected projects, but just posting here to make sure there's an easy reference and to make sure others are aware of the changes. The patches proposed are: aodh - https://review.openstack.org/635656 ceilometer panko tricircle cloudkitty - https://review.openstack.org/635657 magnum - https://review.openstack.org/635658 solum - https://review.openstack.org/635659 tacker - https://review.openstack.org/635660 watcher - https://review.openstack.org/635662 zun - https://review.openstack.org/635663 If there are any questions, just let us know here or in the #openstack-release channel Thanks! Sean [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002502…

1 0

[TripleO] containers logging to stdout
by Juan Antonio Osorio Robles 08 Feb '19

08 Feb '19

Hello! In Queens, the a spec to provide the option to make containers log to standard output was proposed [1] [2]. Some work was done on that side, but due to the lack of traction, it wasn't completed. With the Train release coming, I think it would be a good idea to revive this effort, but make logging to stdout the default in that release. This would allow several benefits: * All logging from the containers would en up in journald; this would make it easier for us to forward the logs, instead of having to keep track of the different directories in /var/log/containers * The journald driver would add metadata to the logs about the container (we would automatically get what container ID issued the logs). * This wouldo also simplify the stacks (removing the Logging nested stack which is present in several templates). * Finally... if at some point we move towards kubernetes (or something in between), managing our containers, it would work with their logging tooling as well. Any thoughts? [1] https://specs.openstack.org/openstack/tripleo-specs/specs/queens/logging-st… [2] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog

7 11

[openstack-dev] [neutron] Cancelling Drivers meeting on February 8th
by Miguel Lavalle 08 Feb '19

08 Feb '19

Hi Neutron Drivers, We don't have RFEs ready to be discussed during our weekly meeting. On top of that, some of you are traveling. So let's cancel this week's meeting. We will resume on the 15th. Best regards and safe travels for those of you returning home Miguel

1 0

[storyboard] sandbox to play with
by Jason Grosso 08 Feb '19

08 Feb '19

Hello Storyboard, Is there a sandbox where I can test some of the functionality compared to launchpad? Any help would be appreciated! Thanks, Jason Grosso Senior Quality Engineer - Cloud Red Hat OpenStack Manila jgrosso(a)redhat.com

2 2

[TC] [UC] Volunteers for Forum Selection Committee
by Jimmy McArthur 08 Feb '19

08 Feb '19

Hello! We need 2 volunteers from the TC and 2 from the UC for the Denver Forum Selection Committee. For more information, please see: https://wiki.openstack.org/wiki/Forum Please reach out to myself or knelson(a)openstack.org if you're interested. Volunteers should respond before Feb 15, 2019. Note: volunteers are required to be currently serving on either the UC or the TC. Cheers, Jimmy

1 0

[release] Release countdown for week R-8, February 11-15
by Sean McGinnis 08 Feb '19

08 Feb '19

Your long awaited countdown email... Development Focus ----------------- It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly so avoid any last minute rushes to get key functionality in. General Information ------------------- We have a few deadlines coming up as we get closer to the end of the cycle: * Non-client libraries (generally, any library that is not python-${PROJECT}client) must have a final release by February 28. Only critical bugfixes will be allowed past this point. Please make sure any important feature works has required library changes by this time. * Client libraries must have a final release by March 7. We will be proposing a few patches to switch some cycle-with-intermediary deliverables over to cycle-with-rc if they are not actually doing intermediary releases. PTLs and release liaisons, please watch for being added to any of those reviews. If the switch is not desired, this is a good time to do an intermediary release if you have been putting it off. More information can be found in our post to the mailing list back in December: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… It is also a good time to start planning what highlights you want for your project team in the cycle highlights: Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Stein-3 milestone: March 7 -- Sean McGinnis (smcginnis)

1 0

[nova][dev] project self-evaluation against TC technical vision
by melanie witt 08 Feb '19

08 Feb '19

Howdy everyone, About a month ago, the TC sent out a mail [1] asking projects to complete a self-evaluation exercise against the technical vision for OpenStack clouds, published by the TC [2]. The self-evaluation is to be added to our in-tree docs as a living document to be updated over time as things change. To paraphrase from [1], the intent of the exercise is to help projects identify areas they can work on to improve alignment with the rest of OpenStack. The doc should be a concise, easily consumable list of things that interested contributors can work on. Here are examples of vision reflection documents: * openstack/ironic: https://review.openstack.org/629060 * openstack/placement: https://review.openstack.org/630216 I have created an etherpad for us to use to fill in ideas for our vision reflection document: https://etherpad.openstack.org/p/nova-tc-vision-self-eval I'd like to invite everyone in the nova community including operators, users, and developers to join the etherpad and share their thoughts on how nova can improve its alignment to the technical vision for OpenStack clouds. Feel free to add or modify sections as you like. And once we've collected ideas for the doc, I (or anyone) can propose a doc patch to openstack/nova, to be included with our in-tree documentation. Cheers, -melanie [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.… [2] https://governance.openstack.org/tc/reference/technical-vision.html

1 0

OpenStack Foundation 2018 Annual Report
by Allison Price 08 Feb '19

08 Feb '19

Hi everyone, Today, we have published the OpenStack Foundation 2018 Annual Report [1], a yearly report highlighting the incredible work and advancements being achieved by the community. Thank you to all of the community contributors who helped pull the report together. Read the latest on: The Foundation’s latest initiatives to support Open Infrastructure Project updates from the OpenStack, Airship, Kata Containers, StarlingX, and Zuul communities Highlights from OpenStack Workings Groups and SIGs Community programs including OpenStack Upstream Institute, the Travel Support Program, Outreachy Internship Programs, and Contributor recognition OpenStack Foundation events including PTGs, Forums, OpenStack / OpenInfra Days, and the OpenStack Summit With almost 100,000 individual members, our community accomplished a lot last year. If you would like to continue to stay updated in the latest Foundation and project news, subscribe to the bi-weekly Open Infrastructure newsletter [2]. We look forward to another successful year in 2019! Cheers, Allison [1] https://www.openstack.org/foundation/2018-openstack-foundation-annual-report <https://www.openstack.org/foundation/2018-openstack-foundation-annual-report> [2] https://www.openstack.org/community/email-signup <https://www.openstack.org/community/email-signup> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[ironic] Hardware leasing with Ironic
by Lars Kellogg-Stedman 08 Feb '19

08 Feb '19

Howdy. I'm working with a group of people who are interested in enabling some form of baremetal leasing/reservations using Ironic. There are three key features we're looking for that aren't (maybe?) available right now: - multi-tenancy: in addition to the ironic administrator, we need to be able to define a node "owner" (someone who controls a specific node) and a node "consumer" (someone who has been granted temporary access to a specific node). An "owner" always has the ability to control node power or access the console, can mark a node as available or not, and can set lease policies (such as a maximum lease lifetime) for a node. A "consumer" is granted access to power control and console only when they hold an active lease, and otherwise has no control over the node. - leasing: a mechanism for marking nodes as available, requesting nodes for a specific length of time, and returning those nodes to the available pool when a lease has expired. - hardware only: we'd like the ability to leave os provisioning up to the "consumer". For example, after someone acquires a node via the leasing mechanism, they can use Foreman to provisioning an os onto the node. For example, a workflow might look something like this: - The owner of a baremetal node makes the node part of a pool of available hardware. They set a maximum lease lifetime of 5 days. - A consumer issues a lease request for "3 nodes with >= 48GB of memory and >= 1 GPU" and "1 node with >= 16GB of memory and >= 1TB of local disk", with a required lease time of 3 days. - The leasing system finds available nodes matching the hardware requirements and with owner-set lease policies matching the lease lifetime requirements. - The baremetal nodes are assigned to the consumer, who can then attach them to networks and make use of their own provisioning tools (which may be another Ironic instance?) to manage the hardware. The consumer is able to control power on these nodes and access the serial console. - At the end of the lease, the nodes are wiped and returned to the pool of available hardware. The previous consumer no longer has any access to the nodes. Our initial thought is to implement this as a service that sits in front of Ironic and provides the multi-tenancy and policy logic, while using Ironic to actually control the hardware. Does this seem like a reasonable path forward? On paper there's a lot of overlap here between what we want and features provided by things like the Nova schedulers or the Placement api, but it's not clear we can leverage those at the baremetal layer. Thanks for your thoughts, -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

7 21

[tc] agenda for upcoming TC meeting on 7 Feb
by Doug Hellmann 07 Feb '19

07 Feb '19

TC Members, Our next meeting will be on Thursday, 7 Feb at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. * corrections to TC member election section of bylaws are completed (fungi, dhellmann) * status update for project team evaluations based on technical vision (cdent, TheJulia) * defining the role of the TC (cdent, ttx) * keeping up with python 3 releases (dhellmann, gmann) * status update of Train cycle goals selection update (lbragstad, evrardjp) * TC governance resolution voting procedures (dhellmann) * upcoming TC election (dhellmann) * review proposed OIP acceptance criteria (dhellmann, wendar) * TC goals for Stein (dhellmann) [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee -- Doug

1 1

[nova] [placement] extraction checkin meeting at 1700 UTC today
by Chris Dent 07 Feb '19

07 Feb '19

A reminder that as discussed at the last placement extraction checkin meeting [1] we've got another one today at 1700 UTC. Join the #openstack-placement IRC channel around then if you are interested, and a google hangout url will be provided. In the thread with the notes, there was a question that didn't get answered [2] in email and remains open as far as I know. There's an etherpad [3] with pending extraction related tasks. If you've done some of the work on there, please make sure it is up to date. From that, it appears that the main pending things are deployment (with upgrade) and the vgpu reshaper work (which is close). Note that the main question we're trying to answer here is "when can we delete the nova code?", which is closely tied to the unanswered question [2] mentioned above. We are already using the extracted code in the integrate gate and we are not testing the unextracted code anywhere. [1] notes from the last meeting are at http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001789.… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001805.… [3] https://etherpad.openstack.org/p/placement-extract-stein-5 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[charms][zuul] State of external GitHub dependencies
by Frode Nordahl 07 Feb '19

07 Feb '19

Hello all, <tl;dr> The Charms projects are increasingly heavy users of external GitHub dependencies, and we are facing intermittent issues with this at the gate. Does anyone have ideas as to how we should handle this from the point of view of Charm teams? Anyone from Zuul have ideas/pointers on how we could help improve the external GitHub dependency support? </tl;dr> As many of you know the OpenStack Charms project is in the process of replacing the framework for performing functional deployment testing of Charms with ``Zaza`` [0]. Two of the key features of the Zaza framework is reusability of tests simply by referencing already written tests with a Python module path in a test definition in a YAML file, and general applicability across other Charms, not just OpenStack specific ones. Because of this the Zaza project, which also contains the individual functional test modules, is hosted on GitHub and not on the OpenStack Infrastructure. Whenever a change is proposed to a charm that require new or changes to existing functional tests, we need a effective way for the individual contributor to have their Charm change (which is proposed on OpenStack Infrastructure) tested with code from their Zaza change (which is proposed as a PR on GitHub). We have had some success with adding ``Depends-On:`` and the full URL to the GitHub PR in the commit message. There is experimental support for using that as a gate check in Zuul, and Canonical's third party Charm CI is configured to pull the correct version of Zaza based on Depends-On referencing GitHub PRs. However, we often have to go through extra hoops to land things as the gate code appears to not always successfully handle GitHub PR references in Depends-On. For reference, after discussion in #openstack-infra I got a log excerpt [1] and a reference to a WIP PR [2] that might be relevant. 0: https://zaza.readthedocs.io/en/latest/ 1: http://paste.openstack.org/show/744664/ 2: https://review.openstack.org/#/c/613143/ -- Frode Nordahl

1 1