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 <lucasago...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev