On Wed, May 29, 2019 at 10:51 PM Nadathur, Sundar <sundar.nadathur@intel.com> wrote:
We are trying to understand the pros and cons of doing the OSC plugin vs integrating directly into OSC repo.
1. Consistency requirements are fine. Presumably we should follow [1]. They seem to be loose guidelines than specific requirements. I suppose the command syntax would look like: $ openstack accelerator create device-profile <args>
Yes, that is the standard. I did not write it using RFC-style 'MUST' language, but I do consider the command structure a hard requirement for in-repo commands. That is the entire point of OSC's existence.
2. When you say, " This is a significant change for OSC ", could you tell us what the risks are for direct integration? The repo [2] seems to have entries for compute, network, identity, etc. So, it doesn’t look like uncharted waters.
Without reciting the entire history, what is in the repo is all that existed when I initially developed the command set, we later added Network API support. Everything else has been plugins since then for various reasons. The risk is that you lose absolute control over your CLI. Everything from the naming of resources (this is the hardest part by far) to the option names and verbs used must follow the guidelines. Not all teams want or can accept that. Others found freedom there, including the freedom to be heavily involved in OSC directly (Keystone is the prime example) and set their path within those guidelines. Neutron also spent a large amount of time and effort getting their core commands implemented in-repo, plus there is a Neutron plugin for a number of extensions. dt -- Dean Troyer dtroyer@gmail.com