Open Stack

Seems to me like we can keep ironic-lib git repository as a git submodule
of the ironic and ironic-python-agent repositories.  Any commit in Ironic
or Ironic-python-agent can change ironic-lib independently.  Also, looks
like our CI system supports it by automatically pushing commits in the
subscribed projects [1].  Sounds like that should be better instead of
making a new release of ironic-lib and waiting for it to be published to
make changes in Ironic or Ironic-python-agent.

[1] https://review.openstack.org/Documentation/user-submodules.html


On Tue, Jun 16, 2015 at 9:24 PM, Lucas Alvares Gomes <lucasagomes at gmail.com>
wrote:

> Hi,
>
> > I haven't paid any attention to ironic-lib; I just knew that we wanted to
> > have a library of common code so that we didn't cut/paste. I just took a
> > look[1] and there are files there from 2 months ago. So far, everything
> is
> > under ironic_lib (ie, no subdirectories to group things). Going forward,
> are
> > there guidelines as to where/what goes into this library?
>
> I don't think we have guidelines for the struct of the project, we
> should of course try to organize it well.
>
> About what goes into this library, AFAICT, this is place where code
> which is used in more than one project under the Ironic umbrella
> should go. For example, both Ironic and IPA (ironic-python-agent)
> deals with disk partitioning, so we should create a module for disk
> partitioning in the ironic-libs repository which both Ironic and IPA
> will import and use.
>
>
> > I think it would be good to note down the process wrt using this library.
> > I'm guessing that having this library will most certainly delay things
> wrt
> > development. Changes will need to be made to the library first, then
> need to
> > wait until a new version is released, then possibly update the min
> version
> > in global-requirements, then use (and profit) in ironic-related projects.
> >
> >
> > With the code in ironic, we were able to do things like change the
> arguments
> > to methods etc. With the library -- do we need to worry about backwards
> > compatibility?
>
> I would say so, those are things that we have to take in account when
> creating a shared library. But it also brings benefits:
>
> 1. Code sharing
> 2. Bug are fixed in one place only
> 3. Flexibility, I believe that more projects using the same code will
> require it to be more flexible
>
> > How frequently were we thinking of releasing a new version? (Depends on
> > whether anything was changed there that is needed really soon?)
>
> Yes, just like the python-ironicclient a release can be cut when needed.
>
> Thanks for starting this thread, it would be good to the community
> evaluate whether we should go forward with ironic-libs or not.
>
> Cheers,
> 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/20150617/39847ca1/attachment.html>