- openstack-discuss - lists.openstack.org

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

08 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 08 Feb '19

08 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 08 Feb '19

08 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 08 Feb '19

08 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 07 Feb '19

07 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 07 Feb '19

07 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 07 Feb '19

07 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 07 Feb '19

07 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 07 Feb '19

07 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