Open Stack

Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530:
> 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.

Please don't do this. It's similar to the incubator model used in Oslo,
but the benefits there (being able to evolve the API of code formerly
tightly coupled to an application) don't apply here. You're writing new
code, and can create a library directly. Releasing libraries is easy. We
do it often enough that people complain about the extra email.

Doug

> 
> [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
> >