Open Stack

Hi,

> So… how does any library get ready to be used by others? Clearly it is being
> used now by the fuel-agent. Do we say ‘sorry fuel-agent, we don’t guarantee
> yet that we won’t break you’? Or ‘fuel-agent, just so you know. Ironic-lib
> isn’t quite ready to be used so we cannot guarantee that we won’t break you
> but we will try our best not to do so’? Or… ?
>

Yes, I think we should say sorry for not communicating this well and
then fix our stuff, i.e Add a note to the ironic-lib README, indicate
that it's ironic use only in the governance description, send an email
to the ML, etc... Fortunately, fuel-agent only uses a tiny function
[0] of the library which can easily be copied into fuel's repository
and have the ironic-lib dependency dropped, here's a patch [1].


> What needs to be done for ironic-lib to be officially used by anyone? Lucas
> mentioned some things. Is that all? Do we open bugs for them? At what point
> would we feel comfortable saying ‘yes, here’s a library that can be used by
> anyone?’
>

I think the library should then be architect with that in mind, the
methods should be flexible so they can be extended, methods should be
less opinionated (i.e see work_on_disk()[2], it does partition the
disk for the ironic use case), we should have a proper documentation,
should be independent of the Ironic project (e.g ironic-lib _right
now_ depends on the ironic-rootwrap command, which is create by
installing ironic), etc... IMO That would be a good starting point.

If it is agreed that we want this library to be generic, then yes we
should open bugs against it.

[0] https://github.com/openstack/fuel-agent/blob/master/contrib/ironic/ironic-fa-deploy/ironic_fa_deploy/modules/fuel_agent.py#L288
[1] https://review.openstack.org/#/c/318724/
[2] https://github.com/openstack/ironic-lib/blob/adedae3915b5f4e9104b2a3f1f5d0413457fa8db/ironic_lib/disk_utils.py#L387

As a note and not OpenStack specific, here's a great talk by Michael
Kerrisk about the (ideal) process of designing a Linux kernel
interfaces. It's not a tech talk, it's just about the process and
common errors and how they can be avoided:
http://bofh.nikhef.nl/events/FOSDEM/2016/janson/how-to-design-a-linux-kernel-api.mp4

Hope that helps,
Lucas