[openstack-dev] [ironic] usage of ironic-lib

Vladyslav Drok 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>
wrote:

> 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].
>

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?
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160519/cdb0ae26/attachment.html>


More information about the OpenStack-dev mailing list