[openstack-dev] [ironic] usage of ironic-lib
vdrok at mirantis.com
Thu May 19 17:00:43 UTC 2016
On Thu, May 19, 2016 at 6:16 PM, Lucas Alvares Gomes <lucasagomes at gmail.com>
> > So… how does any library get ready to be used by others? Clearly it is
> > used now by the fuel-agent. Do we say ‘sorry fuel-agent, we don’t
> > yet that we won’t break you’? Or ‘fuel-agent, just so you know.
> > isn’t quite ready to be used so we cannot guarantee that we won’t break
> > 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
>  of the library which can easily be copied into fuel's repository
> and have the ironic-lib dependency dropped, here's a patch .
Agree with this, as it was not designed for general use and we proposed
a fix before breaking people, I think it's fine, maybe we need to update
the ironic-lib README to mention all the things discussed in this thread.
> > What needs to be done for ironic-lib to be officially used by anyone?
> > mentioned some things. Is that all? Do we open bugs for them? At what
> > would we feel comfortable saying ‘yes, here’s a library that can be used
> > 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(), 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.
>  https://review.openstack.org/#/c/318724/
> 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:
> Hope that helps,
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev