Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
But I'm not sure the real problem to move the modules. My understanding is - the ceilometer package has dependency with ceilometerclient so it is easy to move them - all callers for using the moved modules must change paths. The modules you are talking about are part of Ceilometer's core functionality, we can't move them to a completely separate code-tree that is meant only for client functionality. Besides the conceptual difference, python-ceilometerclient is not tightly coupled with Ceilometer and has its own release schedule among other things. Regards, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On Friday, August 22, 2014 2:55 PM, Dean Troyer wrote: As one data point, the keystone middleware (auth_token) was just recently moved out of keystoneclient and into its own repo, partially because it had dependencies that otherwise were not required for pure client installations. Thank you for this info. I understand that pure client installations are required for future deployment so I need to take care of it for a spec. (https://github.com/openstack/keystonemiddleware) I don't know what your middleware dependencies are, but I think it would be good to consider the effect that move would have on client-only installations. We are talking about the swift middleware (swift_middleware) that is only for the swift proxy so it is better to have own repo. Cheers, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On Friday, August 22, 2014 4:15 PM, Nejc Saje wrote: The modules you are talking about are part of Ceilometer's core functionality, we can't move them to a completely separate code-tree that is meant only for client functionality. Thank you for the explanation! I understand your point of the real problem. Besides the conceptual difference, python-ceilometerclient is not tightly coupled with Ceilometer and has its own release schedule among other things. I checked the requirement.txt in the ceilometer package and saw the line of python-ceilometerclient so we may have a chance to control the level of ceilometerclient when the ceilometer released. Cheers, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On 08/21/2014 07:50 AM, Osanai, Hisashi wrote: Folks, I wrote the following BP regarding repackaging ceilometer and ceilometerclient. https://blueprints.launchpad.net/ceilometer/+spec/repackaging-ceilometerclient I need to install the ceilometer package when the swift_middlware middleware uses. And the ceilometer package has dependencies with the following: - requirements.txt in the ceilometer package ... python-ceilometerclient=1.0.6 python-glanceclient=0.13.1 python-keystoneclient=0.9.0 python-neutronclient=2.3.5,3 python-novaclient=2.17.0 python-swiftclient=2.0.2 ... From maintenance point of view, these dependencies are undesirable. What do you think? I don't think there's any way the modules you mention in the BP can be moved into ceilometerclient. I think the best approach to resolve this would be to rewrite swift middleware to use oslo.messaging notifications, as discussed here: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041628.html Cheers, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
Thank you for your quick response. On Thursday, August 21, 2014 3:12 PM, Nejc Saje wrote: I don't think there's any way the modules you mention in the BP can be moved into ceilometerclient. I think the best approach to resolve this would be to rewrite swift middleware to use oslo.messaging notifications, as discussed here: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041628. html I understand your point that solve almost unnecessary dependencies. I would like to make sure that remained the dependencies of context and timeutils after rewriting. Does the rewriting include removing the dependencies? === copy from the BP === - swift_middleware.py 61 from ceilometer.openstack.common import context 62 from ceilometer.openstack.common import timeutils 63 from ceilometer import pipeline 64 from ceilometer import sample 65 from ceilometer import service On the other hand, I'm really interested in the mail thread you pointed out:D https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg30880.html Best Regards, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
Hi, The main purpose of the BP is move swift_middleware.py in the ceilometer package to the ceilometerclinet package. In order to achieve this moving, we need to solve dependencies which the swift_middleware.py has. We have the following two ideas to remove the dependencies: (1) rewrite swift_middleware with oslo.messaging http://lists.openstack.org/pipermail/openstack-dev/2014-July/041628.html (2) move modules which has the dependencies to ceilometerclient I wrote this idea in the BP. And you pointed out this approach is not possible. I would like to realize moving swift_middleware.py from the ceilometer package to the ceilometerclient package. For me it is very difficult to convince users of installing the ceilometer package on Proxy Nodes for just using the swift middleware because of maintenance costs. Operators in users must check security patches for installed packages on Proxy Nodes even if these are not used on the nodes. I think that both ideas for removing the dependencies realize the purpose and also understand your thought is a way which the ceilometer spec. is going to. Here I asked you the following minor question. On Thursday, August 21, 2014 3:59 PM, Osanai, Hisashi wrote: I understand your point that solve almost unnecessary dependencies. I would like to make sure that remained the dependencies of context and timeutils after rewriting. Does the rewriting include removing the dependencies? On Thursday, August 21, 2014 3:12 PM, Nejc Saje wrote: I don't think there's any way the modules you mention in the BP can be moved into ceilometerclient. But I'm not sure the real problem to move the modules. My understanding is - the ceilometer package has dependency with ceilometerclient so it is easy to move them - all callers for using the moved modules must change paths. If the above approach can work, we can proceed this BP and rewriting swift_middleware with oslo.messaging separately. I will take a bit strong stand on moving the swift_middleware.py from the ceilometer package to the ceilometerclient package but for how to remove the dependencies I will take a middle-of-the-road position.:) Best Regards, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
I would like to realize moving swift_middleware.py from the ceilometer package to the ceilometerclient package. For me it is very difficult to convince users of installing the ceilometer package on Proxy Nodes for just using the swift middleware because of maintenance costs. Operators in users must check security patches for installed packages on Proxy Nodes even if these are not used on the nodes. this idea sounds so familiar. i feel like i may have tried to move this in the past but gave up. i actually prefer having the middleware reside in ceilometerclient... it really doesn't make sense for the entire ceilometer package to be pulled in for just a middleware although i feel like that might require the oslo.messaging feature as well could you create a spec[1] and we can maybe hash out idea there. [1]https://github.com/openstack/ceilometer-specs cheers,gord ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On Friday, August 22, 2014 1:14 PM, Gordon chung wrote: could you create a spec[1] and we can maybe hash out idea there. [1]https://github.com/openstack/ceilometer-specs Thank you for your response. I will create a spec for this. Thank you very much! Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On Thu, Aug 21, 2014 at 11:14 PM, gordon chung g...@live.ca wrote: this idea sounds so familiar. i feel like i may have tried to move this in the past but gave up. i actually prefer having the middleware reside in ceilometerclient... it really doesn't make sense for the entire ceilometer package to be pulled in for just a middleware although i feel like that might require the oslo.messaging feature as well As one data point, the keystone middleware (auth_token) was just recently moved out of keystoneclient and into its own repo, partially because it had dependencies that otherwise were not required for pure client installations. I don't know what your middleware dependencies are, but I think it would be good to consider the effect that move would have on client-only installations. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
Folks, I wrote the following BP regarding repackaging ceilometer and ceilometerclient. https://blueprints.launchpad.net/ceilometer/+spec/repackaging-ceilometerclient I need to install the ceilometer package when the swift_middlware middleware uses. And the ceilometer package has dependencies with the following: - requirements.txt in the ceilometer package ... python-ceilometerclient=1.0.6 python-glanceclient=0.13.1 python-keystoneclient=0.9.0 python-neutronclient=2.3.5,3 python-novaclient=2.17.0 python-swiftclient=2.0.2 ... From maintenance point of view, these dependencies are undesirable. What do you think? # To fix this we need to touch some repos so I wrote the BP instead of a bug report. Best Regards, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
