Revision as of 14:43, 11 February 2016

Weekly Manila team meeting

NOTE MEETING TIME: Thursday at 15:00 UTC

If you're interested in management of shared filesystems for OpenStack, we have a weekly meetings in #openstack-meeting-alt, on Thursdays at 15:00 UTC. Please feel free to add items to the agenda below. NOTE: When adding topics please include your IRC name so we know who's topic it is and how to get more info.

Next meeting

NOTE:Include your IRC nickname next to agenda items so that you can be called upon in the meeting and arrive at the meeting promptly if placing items in agenda. You might want to put this on your calendar if you are adding items.

The most of the driver already report the "'QoS_support': False" to scheduler. Does we need to remove it or save it as Qos support flat? and write 'QoS_support' to capabilities_and_extra_specs.rst?(zhongjun)

Mostly for awareness, this is now merged and should be backwards compatible.

Cinder could benefit from a similar treatment. And with the incubator gone, we could explore a common library with the Cinder team, since the heretofore shared components are certain to diverge over time, but I'm not sure how receptive they would be. Xing?

CI reliability

Why should we merge patches for drivers whose CI systems consistently fail? This negates the value of CI. I think that accepting patches that aren't proven by CI does a disservice to everyone, most of all to the driver owners themselves. Refusing to merge driver patches without a good CI result for that driver seems like a gentler and more uniform-over-time approach than threatening to throw out a driver near the end of a release. And why make our illustrious and overworked PTL be the CI policeman when all core reviewers could simply glance at the corresponding CI result before giving +A? (cknight)