[openstack-dev] [Ironic] ironic-lib library
rameshg87.openstack at gmail.com
Wed Jun 17 07:20:25 UTC 2015
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 . 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.
On Tue, Jun 16, 2015 at 9:24 PM, Lucas Alvares Gomes <lucasagomes at gmail.com>
> > 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 and there are files there from 2 months ago. So far, everything
> > under ironic_lib (ie, no subdirectories to group things). Going forward,
> > 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
> > 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
> > 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
> > 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.
> 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