Re: [openstack-dev] [oslo][context] oslo.context repository review request
On Wed, Nov 05 2014, Davanum Srinivas wrote: Please see notes from Doug on the etherpad on why leaving it in oslo.log or oslo.utils was not considered. https://etherpad.openstack.org/p/kilo-oslo-library-proposals I only get that it might be related to db at some point, but I only skimmed through the linked blueprint at it's not clear to me how that prevent this to be in oslo.utils for example. Sorry to be a pain. :) -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
jd__, No sweat, we can talk in the next oslo weekly meeting -- dims On Thu, Nov 6, 2014 at 11:13 AM, Julien Danjou jul...@danjou.info wrote: On Wed, Nov 05 2014, Davanum Srinivas wrote: Please see notes from Doug on the etherpad on why leaving it in oslo.log or oslo.utils was not considered. https://etherpad.openstack.org/p/kilo-oslo-library-proposals I only get that it might be related to db at some point, but I only skimmed through the linked blueprint at it's not clear to me how that prevent this to be in oslo.utils for example. Sorry to be a pain. :) -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
On Nov 6, 2014, at 11:13 AM, Julien Danjou jul...@danjou.info wrote: On Wed, Nov 05 2014, Davanum Srinivas wrote: Please see notes from Doug on the etherpad on why leaving it in oslo.log or oslo.utils was not considered. https://etherpad.openstack.org/p/kilo-oslo-library-proposals I only get that it might be related to db at some point, but I only skimmed through the linked blueprint at it's not clear to me how that prevent this to be in oslo.utils for example. Sorry to be a pain. :) The main reasons for splitting code into its own library are dependency management, API ownership, the logical separation of the contents of the library within the application stack and between other libraries, and review ACLs within gerrit. We have a couple of libraries (oslo.log and oslo.messaging) that want to specify an API via the context base class, so the class can’t live in either of those places. The utils library is actually used by some of the clients now, so we need to be conscious of adding dependencies there. I don’t think context will bring in any real dependencies for now, but it also doesn’t seem to be a general-purpose utility. We’re going to need to add some thread-local caches for setting and fetching the current context, I think, either within context or in some of the other libraries with callbacks invoked by the context constructor. So for logical separation, a different library seemed to make more sense. It’s also possible that the applications will find other uses for a shared context base class, and so we’ll want to build a review team for it that isn’t limited to the oslo-core team, but that’s less important than the logical considerations in my mind. Doug -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
On Thu, Nov 06 2014, Doug Hellmann wrote: The main reasons for splitting code into its own library are dependency management, API ownership, the logical separation of the contents of the library within the application stack and between other libraries, and review ACLs within gerrit. We have a couple of libraries (oslo.log and oslo.messaging) that want to specify an API via the context base class, so the class can’t live in either of those places. The utils library is actually used by some of the clients now, so we need to be conscious of adding dependencies there. I don’t think context will bring in any real dependencies for now, but it also doesn’t seem to be a general-purpose utility. We’re going to need to add some thread-local caches for setting and fetching the current context, I think, either within context or in some of the other libraries with callbacks invoked by the context constructor. So for logical separation, a different library seemed to make more sense. It’s also possible that the applications will find other uses for a shared context base class, and so we’ll want to build a review team for it that isn’t limited to the oslo-core team, but that’s less important than the logical considerations in my mind. Ok, I can agree with all of that. I'm just not sure the burden of having yet another lib/repo/team is worth it for this lib. But you seem pretty confident about it and I don't have any massive objection. (And anyway I'll still have this mailing list thread to refer in a few months for an I-told-you-so just in case. :-) So that repo LGTM dims. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
LOL. thanks jd__ :) On Thu, Nov 6, 2014 at 11:44 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Nov 06 2014, Doug Hellmann wrote: The main reasons for splitting code into its own library are dependency management, API ownership, the logical separation of the contents of the library within the application stack and between other libraries, and review ACLs within gerrit. We have a couple of libraries (oslo.log and oslo.messaging) that want to specify an API via the context base class, so the class can’t live in either of those places. The utils library is actually used by some of the clients now, so we need to be conscious of adding dependencies there. I don’t think context will bring in any real dependencies for now, but it also doesn’t seem to be a general-purpose utility. We’re going to need to add some thread-local caches for setting and fetching the current context, I think, either within context or in some of the other libraries with callbacks invoked by the context constructor. So for logical separation, a different library seemed to make more sense. It’s also possible that the applications will find other uses for a shared context base class, and so we’ll want to build a review team for it that isn’t limited to the oslo-core team, but that’s less important than the logical considerations in my mind. Ok, I can agree with all of that. I'm just not sure the burden of having yet another lib/repo/team is worth it for this lib. But you seem pretty confident about it and I don't have any massive objection. (And anyway I'll still have this mailing list thread to refer in a few months for an I-told-you-so just in case. :-) So that repo LGTM dims. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
FWIW, this looks good to me - looking forward to using it in keystonemiddleware Steve From: Davanum Srinivas dava...@gmail.com To: openstack-dev@lists.openstack.org Date: 11/05/2014 09:46 AM Subject:[openstack-dev] [oslo][context] oslo.context repository review request Hello all, At the Design Summit session for Oslo Library Graduation for Kilo, we decided that oslo.context was a high priority item since oslo.log was blocked. So here's a git repo [2], please take a look to see if this is good enough for us to open up a infra request. thanks, dims [1] https://etherpad.openstack.org/p/kilo-oslo-library-proposals [2] https://github.com/dims/oslo.context -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
On Wed, Nov 05 2014, Davanum Srinivas wrote: Sorry I missed the session (had a talk at that time). At the Design Summit session for Oslo Library Graduation for Kilo, we decided that oslo.context was a high priority item since oslo.log was blocked. So here's a git repo [2], please take a look to see if this is good enough for us to open up a infra request. A few comments, considering that: - https://github.com/dims/oslo.context/blob/master/oslo/context/context.py#L28 should switch to use oslo.utils.uuidutils to generate the UUID. - The list of dependency is very short - oslo.log (will) depends on oslo.utils - oslo.log is the only user of that (out of the projects themselves) What about just moving this into oslo.log or oslo.utils? That would avoid the burden of having yet-another-lib for a 100 SLOC long file. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][context] oslo.context repository review request
jd__, No issues. I followed the process in the wiki for creating a library with minimal changes required to get the test running as documented. we can do some of these in the openstack git when the project gets created. Please see notes from Doug on the etherpad on why leaving it in oslo.log or oslo.utils was not considered. https://etherpad.openstack.org/p/kilo-oslo-library-proposals Yes, i had the same concern about yet-another-oslo-lib concern! thanks, dims On Wed, Nov 5, 2014 at 5:02 PM, Julien Danjou jul...@danjou.info wrote: On Wed, Nov 05 2014, Davanum Srinivas wrote: Sorry I missed the session (had a talk at that time). At the Design Summit session for Oslo Library Graduation for Kilo, we decided that oslo.context was a high priority item since oslo.log was blocked. So here's a git repo [2], please take a look to see if this is good enough for us to open up a infra request. A few comments, considering that: - https://github.com/dims/oslo.context/blob/master/oslo/context/context.py#L28 should switch to use oslo.utils.uuidutils to generate the UUID. - The list of dependency is very short - oslo.log (will) depends on oslo.utils - oslo.log is the only user of that (out of the projects themselves) What about just moving this into oslo.log or oslo.utils? That would avoid the burden of having yet-another-lib for a 100 SLOC long file. -- Julien Danjou # Free Software hacker # http://julien.danjou.info -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
