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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
