On Wed, Nov 1, 2023 at 3:44 AM Stephen Finucane <stephenfin@redhat.com> wrote:
Hi all,
Just announcing that at the vPTG, the Ironic core team came to a consensus about the future of the metalsmith project. It was originally created to improve the user experience around provisioning Ironic nodes when using Ironic's API directly. At this, it was mostly successful and has completed this task.
It's our intention to work on the Ironic API and python-ironicclient to
On Tue, 2023-10-31 at 15:22 -0700, Jay Faulkner wrote: provide a similarly simple deployment user experience, even for users without nova, integrating lessons learned from the metalsmith project. To this end; we are letting the overall community know we no longer expect to add additional functionality to metalsmith. We will ensure it remains maintained and well-tested until it's functionality has been duplicated, but all new work in this area will be directed at the primary Ironic API and Ironic client projects.
Just to satisfy my own personal curiosity, does this suggest the Ironic core team plans to maintain both the CLI and library binding aspects of python- ironicclient long-term?
This has so far been the plan.
I know that Nova and Neutron (and possibly more) have deprecated the former (in favour of OSC) and I think there's an ambition to deprecate the latter also (in favour of SDK), but obviously that doesn't work for a project that can exist outside of a full-fledged OpenStack deployment like Ironic (and Cinder, fwiw) can.
Ironic contributors have long pointed out the overall challenge we create with a single unified command with regards to projects which can be used entirely outside of the OpenStack use context. I think we reached something semi-elegant ~5 years ago in this regard where our OSC plugin comes from the existing client library we have which loads it's own command and has the same surface as OSC with just a shorter command line. In other words, there is no need to type openstack out with each command then and that limits the user's interaction to what should be there and available. I'm curious what the long-term vision for these
projects is wrt standalone configurations.
The overall plan is just to continue. That doesn't mean there is code in our client library we would rather clean-up/replace with code from the SDK, or potentially vice-versa, but it is a matter of time/capacity and pressing need. For us right now, it is just not a pressing need to force change in that area.
On a related note, how _does_ SDK work with standalone Ironic currently? I've never used that Ironic configuration, but I assume there's no Keystone and in- turn no service catalogue, which likely means SDK simply doesn't work?
No keystone is correct, no service catalog as well. The SDK works well if you supply appropriate configuration which points directly to the service in question. Since we're not doing any sort of dynamic URLs from the service catalog, this generally "just works", and the SDK has been used in bifrost with ansible modules for ages to help ensure this doesn't suddenly break on us. That might not apply to every project's support in the SDK, but Ironic has been a strong proponent of supporting the "stand alone" use case for the last 9 years and so it was relatively easy for us to increment in that direction. Hopefully that provides clarity for your curiosity! Have a wonderful day! -Julia
Cheers, Stephen
To this end, and as discussed at the PTG, I've proposed a change to the
Metalsmith readme, notifying users of this state. https://review.opendev.org/c/openstack/metalsmith/+/899761 This change, or this mailing list post, is a great place to comment if you have any comments on this decision.
Thanks, Jay Faulkner Ironic PTL