On Fri, 2021-12-03 at 17:37 +0800, Rico Lin wrote:
Dear all
The pain point collection etherpad [1] seems to get good attention from teams.
We plan to host a one-hour video meeting to keep the discussion going.
Please fill in the doodle to select your preferred time if you can join us:
The discussion will be hosted in video format.
Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on.
- General Pain point: RabbitMQ
- General Pain point: OpenStackClient support
I will try to join for this discussion, but one point on this for anyone else attending: please take the time before this discussion to try out a recent version of OSC. At the moment, our focus is on switching the underlying library used in OSC compute-related commands from novaclient to SDK and we plan to do the same for cinder next. We're doing this because afaict, there aren't any significant CLI gaps left for most of the core services. My understanding of the feature parity situation is as follows:
- neutronclient ✅ full feature parity since...a long time ago
- Kudos, neutron team, for your long-term investment here
- novaclient ✅ full feature parity since 5.5.0
- We finally introduced a proper '--block-device' option for 'server create' in 5.5.0, which closed our remaining RFE. There have been bugfixes since but it's feature complete, if not bug free.
- cinderclient ✅ (effectively) full feature parity
- The only remaining gap that I'm aware of is for configurable filters and volume service clusters. There are patches open for these here and here respectively that we simply need to merge to complete this, but it's consider low-ish priority
- glanceclient ⍰ not sure, as I've yet to investigate this. I suspect there are a few gaps here.
- keystoneclient ⍰ not sure, as I've yet to investigate this. I suspect we're very close if not there already though.
So in summary, I don't think the OSC problem that has existed historically is still a real thing. If there are gaps that I'm not aware of, please be sure to communicate them here or on the Etherpad so we can track them and encourage people (future students, other contributors) to close them.
Stephen
- General project pain point discussion: How to encourage teams to work/reply on pain points.
Meanwhile, we encourage all to check the etherpad and provide your feedback.
Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated.
[1]
https://etherpad.opendev.org/p/pain-point-elimination