I understand chasing global rrequirements is a bit painful, but they exist so that the entire release (Newton for example) operate correctly together. I don't want to be in the business of defining custom requirement version numbers just because upstream is 'too fast".
Regards -steve From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 6, 2016 at 2:56 AM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Subject: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [daisycloud-core] [kolla] Kolla Mitakarequirementssupported by CentOS Steve, I agree with you on that Kolla can use EPEL, because Kolla is not a function part of OpenStack but a deployment tool. In the same vein, is that means Kolla do not need to catch up with the global requirements of OpenStack? For example, instead of using oslo required by OpenStack, can Kolla be more open to be compatible with an old oslo? This is a big deal because if installers such as daisycloud-core want to use Kolla as underlying deployment tool, they should keep the same requirements updating cadence as kolla, but sometimes that is not necessary for OpenStack installers. 发件人: "Steven Dake (stdake)" <[email protected]<mailto:[email protected]>> 收件人: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>>, 日期: 2016-07-06 02:03 主题: [probably forge email可能是仿冒邮件]Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitakarequirementssupported by CentOS ________________________________ Hu, I am open to not using EPEL in the containers themselves. I didn't even know all the dependencies were available without EPEL. I am on vacation at present, but I'll try a build without EPEL and see if it actually builds correctly. This does raise the question were ansible, docker, and git tools come from. I am not keen to pull them from COPRs because I want them distributed via the CDN for HA purposes. Are you planning to pull ansible, docker, and the git tools into delorean-deps? One thing I am not keen on doing is yum install with an URL. Also for source builds we absolutely require EPEL because we need gcc and other development tools. As for the deployment host, we do require EPEL which is perfectly normal. From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: Monday, July 4, 2016 at 1:02 AM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka requirementssupported by CentOS > As one of RDO maintainer, I strongly invite kolla, not to use EPEL. > It's proven very hard to prevent EPEL pushing broken updates, or push > updates to fit OpenStack requirements. > Actually, all the dependency above but ansible, docker and git python > modules are in CentOS Cloud SIG repositories. > If you are interested to work w/ CentOS Cloud SIG, we can add missing > dependencies in our repositories. I added [kolla] key word in the mail subject. Hope can get response from Kolla team about how to choose repos. Thanks, Zhijiang 发件人: Haïkel <[email protected]<mailto:[email protected]>> 收件人: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>>, 日期: 2016-07-03 05:18 主题: [probably forge email可能是仿冒邮件]Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirementssupported by CentOS ________________________________ 2016-07-02 20:42 GMT+02:00 jason <[email protected]<mailto:[email protected]>>: > Pip Package Name Supported By Centos CentOS Name Repo > Name > ====================================================================================================================== > ansible yes > ansible1.9.noarch epel > docker-py yes > python-docker-py.noarch extras > gitdb yes > python-gitdb.x86_64 epel > GitPython yes > GitPython.noarch epel > oslo.config yes > python2-oslo-config.noarch centos-openstack-mitaka > pbr yes > python-pbr.noarch epel > setuptools yes > python-setuptools.noarch base > six yes > python-six.noarch base > pycrypto yes > python2-crypto epel > graphviz no > Jinja2 no (Note: Jinja2 2.7.2 will be installed as > dependency by ansible) > As one of RDO maintainer, I strongly invite kolla, not to use EPEL. It's proven very hard to prevent EPEL pushing broken updates, or push updates to fit OpenStack requirements. Actually, all the dependency above but ansible, docker and git python modules are in CentOS Cloud SIG repositories. If you are interested to work w/ CentOS Cloud SIG, we can add missing dependencies in our repositories. > > As above table shows, only two (graphviz and Jinja2) are not supported > by centos currently. As those not supported packages are definitly not > used by OpenStack as well as Daisy. So basicaly we can use pip to > install them after installing other packages by yum. But note that > Jinja2 2.7.2 will be installed as dependency while yum install > ansible, so we need to using pip to install jinja2 2.8 after that to > overide the old one. Also note that we must make sure pip is ONLY used > for installing those two not supported packages. > > But before you trying to use pip, please consider these: > > 1) graphviz is just for saving image depend graph text file and is not > used by default and only used in build process if it is configured to > be used. > > 2) Jinja2 rpm can be found at > http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I > think is suitable for CentOS. I have tested it. > > So, as far as Kolla deploy process concerned, there is no need to use > pip to install graphviz and Jinja2. Further more, if we do not install > Kolla either then we can get ride of pip totally! > > I encourage all of you to think about not using pip any more for > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files > may be overide back and force if not using them carefully. So not > using pip will make things easier and make jump server more cleaner. > Any ideas? > > > Thanks, > Zhijiang > > -- > Yours, > Jason > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]<mailto:[email protected]>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
