- openstack-discuss - lists.openstack.org

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

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

10 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 09 Feb '19

09 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 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