Re: [openstack-dev] [Ironic] ironic-lib library
Thanks everyone for the valuable feedback. Few folks in the Ironic meeting agreed as well releasing often is better idea than git submodules, and we will go ahead with that if no one has any objection. On Wed, Jun 17, 2015 at 9:50 PM, Jeremy Stanley wrote: > On 2015-06-17 10:10:22 -0400 (-0400), Doug Hellmann wrote: > > 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. > [...] > > Also, while the software we use does support Git submodules, our > infrastructure admins are not supporting use of Git submodules in > projects we host for a variety of reasons. The benefits of a > submodule over a completely separate Git repository are slim, and > usually a sign that you're working around poor design in the > involved repos. Further, submodules pose significant potential for > confusion among developers, especially those for whom this is their > first experience interacting with Git--it's confusing enough--we > should strive to keep things as simple as possible for them when the > cost of doing so is not particularly high. > -- > Jeremy Stanley > > __ > 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
Re: [openstack-dev] [Ironic] ironic-lib library
On 2015-06-17 10:10:22 -0400 (-0400), Doug Hellmann wrote: > 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. [...] Also, while the software we use does support Git submodules, our infrastructure admins are not supporting use of Git submodules in projects we host for a variety of reasons. The benefits of a submodule over a completely separate Git repository are slim, and usually a sign that you're working around poor design in the involved repos. Further, submodules pose significant potential for confusion among developers, especially those for whom this is their first experience interacting with Git--it's confusing enough--we should strive to keep things as simple as possible for them when the cost of doing so is not particularly high. -- Jeremy Stanley __ 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
Re: [openstack-dev] [Ironic] ironic-lib library
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 > 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
Re: [openstack-dev] [Ironic] ironic-lib library
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 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
Re: [openstack-dev] [Ironic] ironic-lib library
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-dev] [Ironic] ironic-lib library
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 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? How frequently were we thinking of releasing a new version? (Depends on whether anything was changed there that is needed really soon?) Anything else that we should keep in mind when making changes to the library? --ruby [1] https://github.com/openstack/ironic-lib __ 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
