[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [all] [tc] [osc] [glance] [train] [ptls] Legacy client CLI to OSC review 639376

On Fri, Aug 23, 2019, at 3:12 PM, Michael Johnson wrote:
> For Octavia, implementing an OSC plugin has worked out exceptionally
> well. I have also got good feedback from users that OSC is much better
> than the legacy clients in functionality and ease of use.
> That said, I have spent some quality time with Dean (thank you again)
> making sure we didn't stray from the OSC vision.
> I think like any other guideline or standard in OpenStack we just need
> to focus on documenting those guidelines and standards well (there are
> already pretty good documents for this, thank you again to the OSC
> team). Then it is up to us to pay attention to them and correct our
> mistakes when we make them.
> Personally I think all projects should be implemented as plugins. This
> makes it "obvious" to users when they need a service functionality
> they need to install the correct plugin. Currently we get "Why doesn't
> the client support Octavia?" questions when we were one of the early
> plugins. This also has the advantage of limiting the footprint of the
> client install for deployments that don't need all of the services.
> For example, I don't need object nor block storage. It would be nice
> to not use the disk and tab completion space for those. One of the
> nice things about the project team owning the plugin is you don't get
> rogue patches merging that don't align to the project team vision ('-'
> vs. "_" anyone?).

Since you've brought up optimizations here it is worth pointing out that much of OSC's slowness is due to its plugin system. Basically the way python entrypoints work is pkg_resources scans the python path for all packages, sorts them all by name and version, and checks them for entrypoint metadata to know what it can load as an entrypoint. This is slow. Unfortunately that means that the more we get tied to the plugin system the harder it becomes to potentially fix this problem.

Personally I'd much rather lose a few megabytes of disk to avoid major startup overhead.

That said, the user experience with OSC tends to be much better than that of the python-*clients even when you factor in some slowness. In fact I have to fight very strong urges to give up any time I have to interact with an API that isn't yet supported by OSC.

> Michael