Re: [openstack-dev] [all] minimum python support version for juno
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/10/14 09:08, Osanai, Hisashi wrote: Hi, I would like to know the minimum python support version for juno. I checked the following memo. My understanding is python 2.6 support will be supported in juno and also dropped before kilo so it will be dropped in one of stable releases in juno. Is this correct understanding? All stable Juno releases will support Python 2.6. All Kilo releases are expected to drop Python 2.6 support. https://etherpad.openstack.org/p/juno-cross-project-future-of-python Want to drop 2.6 ASAP, currently blocked on SLES confirmation that 2.6 is no longer needed Declare intent that it will definitely go away by K (for services) Make sure that every *python module* (dependencies, and not only core projects) that we maintain declare non-support in 2.6 if they stop supporting it Cheers, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUK8hnAAoJEC5aWaUY1u57sVwH/1hFuICjwHD5RZ+HQnDikkr6 EN4pI/CGEJFfRRymcml2DhT5O3njZNQCB3Q49qbGrDa2PLUIds5l8s8I6jkkHd3a +yw4yshyBNCu+I8cpivKMGfdd6o2xRuI5YUaZLS4td+cfoU2Pt5+tD0M/uiJid86 rbb+RWCVtE5mHWk84iWLwIpNs72ozUwoYLOuHKI8P3nm1jTffiY8600QzGe1T3DF w+2RZ344UKfrRx9+DpJKtl5CRV6jkRMapT1j7u+KWZTwbs0xiGp0FSyKBOJup+oR fkvQMg4aZYsHSeXUqNtoXH7HHx/+P7OVMBbB20hjCy7Z/Df/5KEHHOZGYY4QZAs= =jgtp -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Taskflow for Juno RC1 effectively require Kombu 3.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/10/14 12:55, Thomas Goirand wrote: Hi, When building the latest release (eg: Juno RC1) of Taskflow 0.4, needed by Cinder, I've notice failures due to the impossibility to do: from kombu import message More in details, the failure is: == FAIL: unittest.loader.ModuleImportFailure.taskflow.tests.unit.worker_based.test_dispatcher unittest.loader.ModuleImportFailure.taskflow.tests.unit.worker_based.test_dispatcher -- _StringException: Traceback (most recent call last): ImportError: Failed to import test module: taskflow.tests.unit.worker_based.test_dispatcher Traceback (most recent call last): File /usr/lib/python2.7/unittest/loader.py, line 252, in _find_tests module = self._get_module_from_name(name) File /usr/lib/python2.7/unittest/loader.py, line 230, in _get_module_from_name __import__(name) File taskflow/tests/unit/worker_based/test_dispatcher.py, line 17, in module from kombu import message ImportError: cannot import name message Does it show up in unit tests only? The thing is, there's no message.py in the latest Kombu 2.x, this appears in version 3.0. Though in our global-requirements.txt, we only have kombu=2.5.0, which IMO is just completely wrong, considering what Taskflow does in . Changing the requirement to be kombu=3.0 means that we also need to import new dependencies, as kombu 3.x needs python-beanstalkc. So here, we have 2 choices: 1/ Fix Taskflow so that it really supports Kombu 2.5, as per our decided Juno requirements. Should be doable. 2/ Accept beanstalkc and kombu=3.0, modify our global-requirements.txt and add these 2. This will be a major pain point for both upstream and downstream. Let's stick to the first option. I don't see why we should bump the version unless there is no other way from it. Since Ubuntu is already in a deep freeze, probably 2/ isn't a very good solution. Also, python-beanstalkc fails to build in Wheezy (when doing its doc tests). I didn't investigate a lot why (yet), but that's annoying. On my test system (eg: a cowbuilder chroot), I have just added a Debian patch to completely remove taskflow/tests/unit/worker_based/test_dispatcher.py from taskflow, and everything works again (eg: no unit test errors). This is maybe a bit more drastic than what we could do, probably... :) Joshua, I've CC-ed you because git blame told me that you were the person writing these tests. Could you patch it quickly (eg: before the final release of Juno) so that it works with the older Kombu? Thoughts anyone? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUK+EBAAoJEC5aWaUY1u57IH4H+wWrENjwF0cPXBw135otTJir CNq/kdSxax6ZQHEDR3AA+7mOtaDbm6eVYutx3U8/UHxoUxHC4V3kAxxq4r5g3LFi I3+YkeQBmsx9o8n4YrApUd53enRxf5kvCK2UWt31934RCqubAjO+ytV13dHW9EUs jTK/C0+aOtvsFhs9kEYCNaRt8jMZ7JNk/aS6d34bN3bCpQO8ckaFqne+lVRMtq3x nTK2UCbRP5fOnwtSEWXM/wumzAJiwiS+VKAlr5mvab8cbIrRDtfr89WyYcDdNdTm nci4QMN4xwr9RNbS5+B0IjV7uH6HQLcsgqcjIHa7z+XUeNBxEoWIKRWQUYtRM8Y= =8FNp -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I guess the following review is meant: https://review.openstack.org/#/c/125075/ I went thru each of the failure for the patch (no dependency failures checked), and here are some damned lies (c) about those failures: - - bug 1323658: 2 failures (ssh connection timeout issue, shows up in Neutron jobs) - - bug 1331274: 2 failures (Grenade not starting services) - - bug 1375108: 4 failures (bug in Nova EC2 reboot code?) - - bug 1348204: 1 failure (Cinder volume detach failing) - - bug 1374175: 1 failure (Heat bug) Neither of those bugs are solved in master. Some of those bugs are staying opened for months. The first bug was raised as Neutron bug and marked for RC-1, but then was untargeted due to believe among Neutron developers that it's a bug in Tempest. Nevertheless, with all the hopeless state of the gate, in the Icehouse release scheduled for today stable maint team was able to merge fixes for more than 120 bugs. So, all that said, does anyone believe that it's fair to bitch about stable maintainers not doing their job? Wouldn't it be more fair to bitch about the overall hopeless state of the gate and projects feeling ok releasing Juno with major failures in gate (like in case of the very first bug in the list)? /Ihar On 02/10/14 09:21, Alan Pevec wrote: I'm on retry #7 of modifying the tox.ini file in devstack. Which review# is that so I can have a look? Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJULRESAAoJEC5aWaUY1u57xa0IAJQyvTM7ibfImE0TzXT3AuYE WWy8YmYEbXyH+dEuo6JmaLyKcPAnnlS14Rw+rU2MPtgQWIH1ePkrsrv2PELlF/QI beoVXgUdXemq5AUl3I79H/de7wOAsNhlfrfUdY1GqonVoDkyD5zjQAy4pOUP475G r2kAhIR6EBfS68MWNAJhhjUiP+m+l8kcb0ylenk1AC/JqKtHlSs8DVx25e/FaZtl 46aGKPcbRC2PvHJZ1CmeXDaKasiY3M9lFZvJDmPpNF7qGqlw3WChSRw3yMX/qvNe owLDhP6GGSI6wVQvNo2LVESZK5Fs3n2L2WhHXsjiFYEoYZ57Worm4n5mQogw6uc= =Q55h -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/10/14 18:04, Akihiro Motoki wrote: Hi, To display localized strings, we need to compile translated message catalogs (PO files) into compiled one (MO files). I would like to discuss and get a consensus who and when generate compiled message catalogs. Inputs from packagers are really appreciated. [The current status] * Horizon contains compile message catalogs in the git repo. (It is just a history and there seems no strong reason to have compiled one in the repo. There is a bug report on it.) * Other all projects do not contain compiled message catalogs and have only PO files. [Possible choices] I think there are several options. (there may be other options) (a) OpenStack does not distribute compiled message catalogs, and only provides a command (setup.py integration) to compile message catalogs. Deployers or distributors need to compile message catalogs. (b) Similar to (a), but compile message catalogs as a part of pip install. (c) OpenStack distributes compiled message catalogs as a part of the release. (c1) the git repo maintains compiled message catalogs. (c2) only tarball contains compiled message catalogs Note that the current Horizon is (c1) and others are (a). [Pros/Cons] (a) It is a simplest way as OpenStack upstream. Packagers need to compile message catalogs and customize there scripts. Deployers who install openstack from the source need to compile them too. (b) It might be a simple approach from users perspective. However to compile message catalogs during installation, we need to install required modules (like babel or django) before running installation (or require them as the first citizen in setup.py require). I don't think it is much simpler compared to option (a). (c1) Compiled message catalogs are a kind of binary files and they can be generated from PO files. There is no need to manage two same data. (c2) OpenStack is downloaded in several ways (release tarballs is not the only option), so I don't see much merits that the only tarball contains compiled message catalogs. A merit is that compiled message catalogs are available and there is no additional step users need to do. My preference is (a), but would like to know broader opinions especially from packagers. I'm for (a). There is no much sense in storing compiled catalogs in git. Just provide a setup.py command for us to invoke during build. I think it's ok for us to introduce new build time dependencies. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJULRUFAAoJEC5aWaUY1u57y7MH/iaEAKaRgaedVoEBcGwuxmHA yEO60pnIpGm6f2aD8zHc04jMDBXCLaarNdNoRP/D+5QSadrycnHNIrSWvvkb3V9+ TJqlv8JISU+zvA4gsstrk6qwu074TNyp/CI9gS6UjC9kKf65OW2ENERhCGT/pBur GGGXaryJJs07xtCD+H0Cg2xqntRx104CkUop9+queGG2by4IUgX8FhSRgq5YKmLj iTFl2FYZS8T+vdRgTYJrMq1KyZoPZhXfKM7I/4r8zqVXqJuglEgGzbgpzqqLHwjU J6qPNopVuNi+75wGLYtiQNXiv73plYjosyLuFPrcL2/trLS7CijBBdm+KtZUWwM= =dCGR -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dependency freeze exception: django-nose=1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Red Hat should be fine with the change. We're going to ship Juno for Fedora 21+ and EL7 only (no EL6), and they both have the needed versions packaged [1]. [1]: https://admin.fedoraproject.org/updates/python-django-nose On 02/10/14 16:29, Thomas Goirand wrote: Hi, murano-dashboard effectively needs django-nose=1.2. As per this: https://review.openstack.org/125651 it's not a problem for Ubuntu and Debian. Does anyone have a concern about this dependency freeze exception? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJULWKaAAoJEC5aWaUY1u57uGkIAKX/Afrtg0tCQQLFjnw1Jjvi 129wl+j7gHod1LX9Jx9EEZDbHJSJG11krgF/Kyba+xGrer1XbKqm1F77VYxs3mtl +/GfoaOQbbM4NMuyGRFcQKNYaihhOe3KGKmijOdpAhjO/LvQcF+pSFkOESzZj8D1 +vGKe001hEryJLjcvHoyy4usZOg1LfpDMbfyG+20KCa26M1jTPq8ZnXGwRlZPIKX AWq9mbB/TKBQOkLoKSJ31vZwzp22CqsYjcDtxznq8I+iCK7i3PkkSfYxaBIbchhO 57gkJjjuulVt1k6nj/z5q6h7awgHV3HLf+BxuUC6Pkz8pCYuX+V5qUDNW54g86A= =oE5D -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/10/14 18:12, Akihiro Motoki wrote: Thanks all for your input. This topic was also discussed in the I18N team meeting this week. All opinions I got so far are same and we seem to have a consensus. - not to have mo files (compile message catalogs) in our source git repository. - to provide a quick documentation on how to generate mo files and deploy them This consensus raises another question. At now Horizon is the only affected project. Is it better to apply this consensus to Juno Horizon release or to defer it to Kilo? One concern is that most distributions have already prepared packages for Kilo, so it might be better not to change now? I would like to know opinions from distributors like RDO, Debian, Ubuntu and so on. I was pointed (kudos to Alan Pevec) to the following update for RDO spec file [1] that makes it regenerate MO files from source for Juno. So for RDO, it's already handled the way we will probably go forward. [1]: http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/commit/?id=e756a1d0e401707d6d386516eef5c2af8ed5e138 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMn5lAAoJEC5aWaUY1u570KUIAJRuxXcARheAJQB8phFlarHn zzRNA7hA8WPBEVMRZCJjqqLKEeS/XaSN0Ue8XuR8bX4AOKA+Yh9S2X39kEWGquhI Xdb5OqkHXPrBRAAKIdg9sPIa5SfKF9m9vEWSH84nGDczhQTeV6XBJtrnBgL9USa7 bMmifiXg14lSNNgwwpiEkyoA1qmEsMki+yFPuvldWLvszWgl3xlTOZnY1L7auUgU DO9bWuvSa10O463+CH4SbhhwE/k8TS3B5A/Y7eKeFwLECAHQFumgFK3bQtFE7QfB Lv29eonr6NchEtGo+tu1W10ervDAoEVqMF6oLFtg+qF3hJwyumhH9pIV9PXVO5g= =fkXa -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, tl;dr we should enforce utf8 on server and client sides of db connection, and this requires changes to docs and oslo.db. The latter may require raising effective libpq version dep to 9.1+. Recently I was working on making sure we always run using utf8 on both database server and client side, and that we do it with all the proper connection options set (f.e. mysqldb requires use_unicode=0 to avoid performance drop - a thing that is not set anywhere in gate as of now, and not documented). For server side, it's a matter of how we create databases, and in devstack, it's usually utf8 (though, for unclear reason, latin1 is still enforced for nova for initial creation due to Folsom (sic!) bug; I've reverted to utf8 with [1]). For client side, it's not that clear. Though devstack enforces utf8 in SQL connection strings, we don't ask to do so in official docs [2]. There is a bug [3] in LP that seems to be relevant. I think the proper way is to enforce utf8 everywhere. The first step would be to make sure we suggest adding charset=utf8 to SQL connection strings, and configure SQL servers to use utf8. That is something to be covered by docs team. But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. Though as you can see, the patch fails on py26 postgresql unit tests. This is because I set charset_encoding for PostgreSQL via libpq connection option that is available since PostgreSQL 9.1 only. The failure is because we run py26 test suite on CentOS 6.5 that still uses PostgreSQL 8.4.*, meaning the option is not available for us. Now, there are several other ways available for us to enforce encoding without using the option. First, we may set encoding thru PGCLIENTENCODING environment variable. Second, we may execute SET CLIENT_ENCODING TO utf8 after connecting to psql server. Now, the question is whether it's worth reimplementing the feature using some of the available hacks that will work with PSQL 9.1. We're about to drop Python 2.6 support in Kilo, and that probably means that CentOS 6.5 will be dropped from gate too. Do we have any other distribution of interest that uses both python 2.7 and psql 9.1, and is going to run Kilo pieces? On Red Hat side, we're not interested in running Juno on EL6 that uses old psql. As for EL7, it has a psql version that supports the connection option. On Ubuntu side, the only LTS release that is still supported and uses psql 9.1 is Lucid, but it's based on py26, so it should not be an issue. Any other consumers that could be affected by effectively raising minimum version bar for psql to 9.1 in Kilo? Though we've (almost) decided to drop py26 support in Kilo, we didn't have similar discussions for other components that we use. So I'd like to hear what's our take on that. Do we really drop *py26* support, or maybe what we really do is we drop *CentOS 6.5* support?.. On a more general note, do we track those kind of external dependencies anywhere? There are lots of them: neutron depends on specific versions of openvswitch; oslo.db depends on specific versions of underlying backend libraries, etc. Comments? [1]: https://review.openstack.org/126267 [2]: http://docs.openstack.org/icehouse/install-guide/install/yum/content/nova-controller.html [3]: https://bugs.launchpad.net/glance/+bug/1279000 [4]: https://review.openstack.org/111236 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMotwAAoJEC5aWaUY1u57IQQIAN2yHfxbj0DYDMHE40OGbEwU 8fis/KOAxSyUEhHbbECS8ODGjHNK9SeuddUplzL5sKVbYIMZgt3wKXGT/rT5ex0C iMmc7/mb6JGGTUYvR1sF2EXxioJ3kWJSt5oQqBhVT14y2g8rwqN6tQaTusfDVZWN yZ7KCmQDc+3HMyY3EmYCp6V1ndubLbx8Oh56/jtdSGdNtc7V4IwYIF3F4WQaKBcB 54tZkAO0wvlbbRrXqEiyf99/dVLDiMquM3LNKEbYg4zjDUEX74fGJ3mscQtWdDLv 0TcqOvQ2pwLvpksf30kvBBHGcNCF9x8Ov8H4vg5wRTD4bkpjEDwmXzQXTk7xfHM= =aYRM -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 15:11, Jay Pipes wrote: On 10/06/2014 08:30 AM, Ihar Hrachyshka wrote: Hi all, tl;dr we should enforce utf8 on server and client sides of db connection, and this requires changes to docs and oslo.db. The latter may require raising effective libpq version dep to 9.1+. Recently I was working on making sure we always run using utf8 on both database server and client side, and that we do it with all the proper connection options set (f.e. mysqldb requires use_unicode=0 to avoid performance drop - a thing that is not set anywhere in gate as of now, and not documented). For server side, it's a matter of how we create databases, and in devstack, it's usually utf8 (though, for unclear reason, latin1 is still enforced for nova for initial creation due to Folsom (sic!) bug; I've reverted to utf8 with [1]). For client side, it's not that clear. Though devstack enforces utf8 in SQL connection strings, we don't ask to do so in official docs [2]. There is a bug [3] in LP that seems to be relevant. I think the proper way is to enforce utf8 everywhere. The first step would be to make sure we suggest adding charset=utf8 to SQL connection strings, and configure SQL servers to use utf8. That is something to be covered by docs team. But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. So, the subject of this email is a bit misleading :) You are suggesting a change to the UTF-8 charset enforcement here, and below you are suggesting removing libpq9.1 for related reasons. I suppose setting of utf8 on the client side, and supporting utf8 on the server side, but I do *not* recommend using a blanket policy of charset=utf8 on every text column on the database side. It really is wasteful for certain columns like uuids that are used in joins all over the schema... Maybe it is indeed wasteful, I don't have numbers; though the fact is we don't allow any migrations for databases with any non utf8 tables as of [1]. The code was copied in multiple projects (Nova, Glance among other things). Also, the same check is present in oslo.db that is used by most projects now. Also we have migration rules in multiple projects that end up with converting all tables to utf8. F.e. it's done in Nova [2]. So we already run against utf8 tables. Though we don't ever tell users to create their databases with utf8 as default charset, opening a can of worms. We also don't ever tell users to at least set use_unicode=0 when running against MySQLdb (which is the default and the only supported MySQL driver as of Juno) to avoid significant performance drop [3] (same is true for oursql driver, but that one is at least not recommended to users thru official docs). [1]: https://review.openstack.org/#/c/64764/ [2]: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1539 [3]: http://docs.sqlalchemy.org/en/rel_0_9/dialects/mysql.html#module-sqlalchemy.dialects.mysql.mysqldb Best, -jay Though as you can see, the patch fails on py26 postgresql unit tests. This is because I set charset_encoding for PostgreSQL via libpq connection option that is available since PostgreSQL 9.1 only. The failure is because we run py26 test suite on CentOS 6.5 that still uses PostgreSQL 8.4.*, meaning the option is not available for us. Now, there are several other ways available for us to enforce encoding without using the option. First, we may set encoding thru PGCLIENTENCODING environment variable. Second, we may execute SET CLIENT_ENCODING TO utf8 after connecting to psql server. Now, the question is whether it's worth reimplementing the feature using some of the available hacks that will work with PSQL 9.1. We're about to drop Python 2.6 support in Kilo, and that probably means that CentOS 6.5 will be dropped from gate too. Do we have any other distribution of interest that uses both python 2.7 and psql 9.1, and is going to run Kilo pieces? On Red Hat side, we're not interested in running Juno on EL6 that uses old psql. As for EL7, it has a psql version that supports the connection option. On Ubuntu side, the only LTS release that is still supported and uses psql 9.1 is Lucid, but it's based on py26, so it should not be an issue. Any other consumers that could be affected by effectively raising minimum version bar for psql to 9.1 in Kilo? Though we've (almost) decided to drop py26 support in Kilo, we didn't have similar discussions for other components that we use. So I'd like to hear what's our take on that. Do we really drop *py26* support, or maybe what we really do is we drop *CentOS 6.5* support?.. On a more general note, do we track those kind of external dependencies
Re: [openstack-dev] sign up for oslo liaisons for kilo cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 17:56, Doug Hellmann wrote: The Oslo team is responsible for managing code shared between projects. There are a LOT more projects than Oslo team members, so we created the liaison program at the beginning of the Juno cycle, asking each team that uses Oslo libraries to provide one volunteer liaison. Our liaisons facilitate communication and work with us to make the application code changes needed as code moves out of the incubator and into libraries. With this extra help in place, we were able to successfully graduate 7 new libraries and begin having them adopted across OpenStack. With the change-over to the new release cycle, it’s time to ask for volunteers to sign up to be liaisons again. If you are interested in acting as a liaison for your project, please sign up on the wiki page [1]. It would be very helpful to have a full roster before the summit, so we can make sure liaisons are invited to participate in any relevant discussions there. Thanks, Doug [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM= =+HC1 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 19:10, Mike Bayer wrote: On Oct 6, 2014, at 9:56 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. i would recommend that we definitely do *not* set explicit client encodings on all columns, and go with the most minimal approach for whatever the target database is.For example, with Postgresql 8.4, utf-8 is not an issue so long as client_encoding is set within postgresql.conf.I’ve had this kind of discussion many times in the past with folks who are trying to “protect” some subset of users that don’t have this setting in their conf file, either because they installed from an OSX package or some other weird reason, and generally I’m not buying it.There’s no need to build tremendous verbosity and fine-grained specificity throughout a system in order to appease very narrow edge cases like this. It’s not just about potential performance problems, it’s also just a schema and code management issue, in that it is complexity that IMHO is just not needed. - From server side, indeed, proper configuration described in documentation may be enough. Though atm we don't document PostgreSQL settings anywhere. [As for MySQL, both server and client encodings are indeed advised to be set to utf8.] That said, I wonder how we're going to manage cases when those *global* settings for the whole server should be really limited to specific databases. Isn't it better to enforce utf8 on service side, since we already know that we always run against utf8 database? For this reason I’m pretty ambivalent overall about any kind of utf-8 hardcoding within the application connection logic. IMHO this should be handled at the configurational layer as much as possible. Though as long as it’s just an application time setting, and not something hardwired throughout the schema (implying we now have to *rely* upon UTF-8 encoding explicitly for all columns everywhere…and then what happens if we are on some target database that doesn’t quite do things the same way, e.g. DB2, oracle, others?), it’s not *too* big of a deal for me if it solves some problems right now. Please let me clarify... Do you say that setting client encoding on oslo.db side is actually ok? I haven't suggested to enforce utf8 per column/table, though I guess we're already there. short answer, there should be no need to drop PG8.X support for this reason. If the client encoding setting is something we want hardcoded in the app layer and it fails for those versions (which I’m not familiar with? what is the thing that is not actually supported prior to libpq 9.1 ? psycopg2’s set_client_encoding, really? this doesn’t sound familiar two me), we can detect that and forego the setting - sqlalchemy dialect has server_version_info for this reason. Forgoing, again, means some users running with utf8 client encoding, others without it. I strive towards consistency here, that's why I try to find a way to set the setting for all clients we support (and the question is *which* of those clients we really support). The thing that is not supported in psql 9.1 is a connection option added to libpq as of: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192 As I said before, we have other ways to set client encoding for psql clients that use libpq 9.1, and the thing I try to determine is whether we consider supporting those versions of libpq. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9yfAAoJEC5aWaUY1u571T0IALBgfRSL0PY1q9PC/vpiee2B d++dVM+CU/SRhXh7zlY703K/sdRVvsPGlUNkzPjT0TGa81LbXPKtwVqPIQeUpI5i a+X9HKHksaeidgLyuOPbSic+hFSoQESoYBswLfb0+vhT9JEn2XwzEyJo83c4MDH3 grgi5Crk+xx2uAa3mnEKCkeCOiq6t6V+7s7DKM8qdAEZOvKWlY3JK5W+AF6Smjlj XJkywLXkDy+t+jMMIo2XqlR7xIVoy4wSTZRgbqrHpBqxqhL3/wzk31JnQgant8A+ 2HF8p+Goy0CxoLOYb0LCE4JiHh6aoHXCcUOXW9BmcVBxfRg7el3OcKWJb9g2Q+M= =78+Z -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 06:51, thanh le giang wrote: Hi all I want to add a plugin to the Public Neutron Repository. Although I have read the gerrit workflow and Neutron Development page (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly how we can add our plugin to neutron repository. Could you please share me the process? Note that there are discussions to move all (or most) plugins outside the neutron tree (can't find the link atm, but it's mentioned in [1]). So in the end, your plugin may end up in a separate repository. [1]: https://etherpad.openstack.org/p/kilo-neutron-summit-topics /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEaBAEBCgAGBQJUNDzwAAoJEC5aWaUY1u57O08H8Pwm93FbLr7SR9LUiVg114eJ 9jKsuhOBartQMidKHXMfCTxC6lYtqFkaZdjnHuZ6ADFAQsDEzucHxHiJZx0SmiIs uD0NJeqLrS3UR0RJZMya5InfF1wso7B3CAXuGejAuQB0D08K7qR3nSRNGqcUn3k5 RVn6JNJk5DicuXrtrOOzvlUuPNeHx9b1/YfKhiC2J1Bl1WttOXzedZMXcRhlTBGN wtWfyl4OzKLHPTvumUkT6NMoHyg0zHs/FBM7caOOzo3xsA+pq89E6q+mY5un6zUy KKQI36zhIBvVUE0eIqekm9zqV+2AJxQnb+H6U4vRrAFMxjArvjUpgnLDN70T =ow33 -END 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] Meeting time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/14 21:01, Roman Podoliaka wrote: Hi all, Last Friday we decided to find a better time for the weekly team meeting. Keeping in mind that DST ends soon (October the 26th in Europe, November the 2nd in the US), I think, we can choose from: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 Friday is beer day (especially here in Czech Republic!); Thursdays are harsh in terms of meetings in my calendar (though 1600 is bearable). I vote for Mondays. (assuming the information about meeting rooms availability provided here [0] is correct) Basically, anything earlier than 1600 UTC will be too early for those who live in CA after November the 2nd. And 1700+ UTC is beer o'clock here in Europe :) Alternatively, we could ask Infra to add the meeting bot directly to #openstack-oslo channel and have the weekly meeting there on any day we like around 1600 UTC (#openstack-oslo is not really crowded, so it shouldn't be a problem to use it for a meeting once a week). Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUND18AAoJEC5aWaUY1u57zFYIAI7xbaKnrfly6IUlJxG8Of8d n21PY05Jr/3vqq+sb+7E+a7Ty0xN1Rk2ehgUZsAMeQl59uH6JAqMoLavZjdfMkUO jxziRcR/si8wJ0LL1cXW0v5FDTYfYHoGkeJcmF1kbbOIVeezvhC2Ow7MkldIWZJk UmvUqGHshawERb0Hf1LIYnyU03mkg+F/lcdoT0xnLmI5UKEGVE9KjLsG8/mJ5aW0 uOiN0rgOR1+0sP6TWJArDD303feTcr+/ibeAgCmCEuLi0u/h54RnXRTdRScwPMdG ZMeDc/BcB3TY1wCnmMxvxLDDcIiZ6YIlpLPmmdDPXlxQf1OCgPJ24pBTSu9Hrww= =Ofcz -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/14 22:25, Dirk Müller wrote: 2014-10-02 14:19 GMT+02:00 Duncan Thomas duncan.tho...@gmail.com: Hi, What is actually needed is those who rely on the stable branch(es) existence need to step forward and dedicate resources to it. Putting the work on people not interested is just the same as killing them off, except slower, messier and creating more anger and otehr community fallout along the way. I'm paid by one of those distros that are interested in stable branch maintenance but have no idea what needs to be done other than saying I'm interested in helping out. I've been proposing patches to backport every once in a while already and being frustrated that it takes weeks if not months for someone to review them and potentially merge. What are the queries that people are supposed to look at ? How can I help in pushing patches or look for gating failures *specific* to stable/ branches? First, check out [1]. Also please subscribe to openstack-stable-maint@ mailing list [2]. You can start helping the team by applying the rules from [1] to existing backport reviews. Once team members see your work for a while, you will be able to join the team and get +2 vote for stable branches. Welcome! [1]: https://wiki.openstack.org/wiki/StableBranch [2]: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUNE5dAAoJEC5aWaUY1u57cpoH/2Y8qTTRg1IBWBB7O+VnezWc LEHEi1ydXwpu75kPMI5YWlPx4YWSFKRD6DOd30bUgSsoW7rI/d1LtelfvE3ubdS3 8D6qt1Rvlw15xpX8GbVaABlezxeQufufCMp0wioV0OkrlryyF0dvE1iopwnIjnAi hD8rfbAO8LUW8ra0hkteRFac3oPVzGBGhWu67ijxvec3Oh7p7gV4AlMj2tm2n5JE fhzxPLnPTqVa8zqJYdZBIr7nHfZtvx9bxGMPAqJP40e15x/toaVJquBEM43HaVs+ 2YX5sGWrxmZaP6w8TJRcbBqny0hfK8n3IWgY6d8NVa4FqgwibdHY22hi7jnMuoU= =hLF9 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Usage of @author tags in the header of Python files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/10/14 09:30, Christian Berendt wrote: After proposing a change to Horizon to remove the @author tags from the header of Python files (https://review.openstack.org/#/c/126656/) Matthias Runge proposed to discuss this first on the mailing list. Is it necessary to track the authorship of a file inside the file using @author tags? Git is a lot better in attributing authorship, so for me, @author tags are just a waste of precious disk bytes and cpu cycles. The copyright statement itself is unchanged and intact after the removal of the @author tags. The copyright statement is not addicted to the authorship of a file so it should be safe to remove the @author tags. The @author tag is not used in other projects. Neutron removed all @author tags some time ago and there are no @author tags e.g. in Nova, or Cinder. There are even local hacking checks in Nova, and Neutron to not use @author tags. Christian. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUNQZZAAoJEC5aWaUY1u572BEIALXeJDUKp7LLp7Vsw7n3LkhQ kDjUf/wm0ySNQ8+VLGzaI0BTGhCN4QlrCfdiRXjwI1AYMMcf7DLKGA9pah1hcoEq xn2uiFce3qGp6KVIbKldVLBfzYTQlDnGBb/uGdrIT3WOyYC6Cj1LNte1AcrNgFLc x/eDmsQUWp3cvGJReiEW7Gqtmo0DQHswwD70D4NS//nZKSIildeM5ucWpHgtI9k1 PsRNZDHr2Pyg2JRD0eEakW0nt5VICa1vOoCmsOCbVjluwU3XBXgsejHM2fbSeSNp HnppdogRuZ+30xg9Ij+WbuX5FwMIRc+UTNVektqSkQa582/DcMpMTi/ySLmTH6U= =33KY -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/14 18:05, Mike Bayer wrote: On Oct 7, 2014, at 8:29 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: That said, I wonder how we're going to manage cases when those *global* settings for the whole server should be really limited to specific databases. Isn't it better to enforce utf8 on service side, since we already know that we always run against utf8 database? I think whenever we do a ?CREATE DATABASE?, we should make sure the desired encodings are set up at that level. I?ve seen lots of migration scripts that are listing through tables and setting each table individually to utf-8, and that?s less than ideal, though I suppose that?s more of a retroactive fix. Please let me clarify... Do you say that setting client encoding on oslo.db side is actually ok? I haven't suggested to enforce utf8 per column/table, though I guess we're already there. The way we are setting client encoding now should be fine, if you could clarify what about that isn?t working for PG 8.4 that would be helpful.IMHO especially on Postgresql we should be able to get away with not having it. MySQLdb is not as nicely implemented as far as encoding (including the use_unicode speed issues) so it may be more necessary there. PostgreSQL part is more for consistency with MySQL, but also to avoid enforcing users to set utf8 globally for their SQL server. I think the less we demand on configuration level the better (assuming we decided on using utf8 globally for all our databases). But yes what I really *dont* want is the encoding set up on every column definition, e.g. ?VARCHAR(20) CHARACTER SET ?utf-8??, that?s been suggested before and that would be terrible. I don?t think Postgresql has quite the same thing available (only collation per column). Forgoing, again, means some users running with utf8 client encoding, others without it. I strive towards consistency here, that's why I try to find a way to set the setting for all clients we support (and the question is *which* of those clients we really support). The thing that is not supported in psql 9.1 is a connection option added to libpq as of: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192 OK but that is just the connection parameter, when you pass client_encoding to SQLAlchemy?s psycopg2 dialect, the encoding is set using psycopg2?s set_client_encoding() method: http://initd.org/psycopg/docs/connection.html#connection.set_client_encoding. This ultimately emits ?SET client_encoding TO ?utf8?? on the connection: conn_set_client_encoding - https://github.com/psycopg/psycopg2/blob/master/psycopg/connection_int.c#L1188 pq_set_guc_locked - https://github.com/psycopg/psycopg2/blob/master/psycopg/pqpath.c#L709 ?SET client_encoding TO value? is supported in all Postgresql versions, here?s 8.0: http://www.postgresql.org/docs/8.0/static/multibyte.html So there?s no issue with Postgresql 8.2 here as far as client encoding, the libpq feature isn?t used for that. Also, it defaults to the encoding that is set for the database (e.g. server side), so if we make sure CREATE DATABASE is emitted with the encoding, then we wouldn?t even need to set it (and perhaps we shouldn?t if the database is set to a different encoding). As was revealed during IRC discussion with Mike, libpq 'client_encoding' and SQLAlchemy 'client_encoding' are different beasts, and we have the latter into our possession when using libpq 9.1, so it's better to use that one to avoid raising a minimum version bar. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUNn5OAAoJEC5aWaUY1u57Y98H/2PGpZg4IeUKPqT2IGRtCOp3 Ln52cJ3ew/unL0n1JdBW/CAYuN2/c8jsFeWsFGG4P7zMrLh+AFUtmq/4xQShyLkM YimaCzziN3beojVjPOKCYhMNNnS83pS7FIDXdEn/cdadFliiDX7m5rjMG40l9WOD JFR5WfWPFrvura4VUDMjStmgFANxuxLboDy95xmdVomSL9m4Ms+/OZOPkcrV39Iu H3scbIgZVEd8SZ1lpEQYMO4QXgSSfgEV+3efQbZADLYO8ig82a4h+nVN1079RAos DfgxRdu1kK5NaPUFxbtbxhhTYbIuKRHf183tv6qJv6uPHgo06sLe5ie+is2q4LA= =kSU1 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ./run_tests.sh fails to create the .venv environment for neutron
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 01:55, Vasudevan, Swaminathan (PNB Roseville) wrote: Hi Folks, ./run_tests.sh fails to create the .venv with the latest neutron repo. It fails at MySQL-python. Does anyone know what is broken. You probably miss libmysqlclient-devel package installed from your distribution repos. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUNoDIAAoJEC5aWaUY1u57jo4IALh9FaEsICHxKoaNjtlmTey9 F9+DQicJOwc/Iw22U+zY9d1AnuBz7P+xLvGLqavsVdEvYdbZSlT4OKUCBiTovseV pit3WiUFjVhXcLlUS3aKfjkX4mHwHTBIWQEZvf0jEVQRTSnIAv3x0TbCuXDJ9vcB Luf4PcFoqMFW/PVFYkSXhEQ4WMrPcTcNNdy5AqdpVrkntviR+oyHONvYSizjhIda raiMtgWYZvAigXz62Bul13B42AJVIhzFMeFnN5d1enV41ZlgJje/Dgqf1e8YC87z v7aXbUiEolTZvCpjO1jL/uBmuOBkGeltrMW4XWv0WJD7SqsW9ridNuHdXV2yMfc= =TA77 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/14 10:32, Chen CH Ji wrote: There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '_https://review.openstack.org/#/c/78429/_ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot With oslo.concurrency, you don't copy-paste code, you just reuse it as any other third-party library. So if your project is not yet using the library, just port it to it first, and once a new version of oslo.concurrency is released, you will get your change magically applied. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN69RAAoJEC5aWaUY1u57sEEH/0q2HxdZkMKNDT+99hZWyyP7 qgeV77UKQ8bHNHVvMVW8vwSqemJVbJwTLrZxPkm4GodwdpF4voXeN1QdA8srU9a2 2DiAdzyrZLlUINpezXKmqOIqNYBg4uxwVCBNgShCM1ViHZkBuViG9c1dNiKyl5e/ 97AJSGV8NXa3mmlOpJJZ2KkfUCaMHo0KbBTSsdAa/td2a17IzpYl80BQB6zrtytB Ou0hYyD/rCVdekcg9ZbyR0DDO6gZR7EGHMzLoM+pWgLQ6+JAlnsaxxUR1ACLO51+ w65IYIArBZpVFyJFnHy/WiPpqitUBiHceXcykdlBFFpTnRe2SN+Ks4U5x+9QnSM= =/Y4a -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 23:44, Doug Hellmann wrote: On Oct 9, 2014, at 4:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The sqlalchemy-migrate project is basically maintenance mode and the core team [1] is kind of a weird mix of people - all great people I'm sure, but I think it's more a team of people that stepped up when OpenStack took over the project and said they'd babysit it but it's pretty idle. Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can we just have the oslo.db core team [2] own sqlalchemy-migrate now too? Here are the sqlalchemy-migrate open reviews: https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z [1] https://review.openstack.org/#/admin/groups/186,members [2] https://review.openstack.org/#/admin/groups/331,members If the oslo.db team wants to participate, that’s obviously fine, but I don’t think we want to just add everyone in bulk. AIUI, the team’s goal is to get the migration stuff in oslo.db working with alembic so we can stop using sqlalchemy-migrate. Till that time, we're left with the library used by multiple projects. I feel it's hard to get any review in meaningful time for the library, so if moving the library under the oslo.db tent will help it move, I'm both hands for that. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN7B4AAoJEC5aWaUY1u57JLIH/jn9iREgmRhvfiZosiN9knxV xrVFgEpZ35G5kGmWrnnnKvbWUIvIawwoA2OCOCMXScL5xwzLtn9+prvcujvGK3g1 /zk1aVKnKv90zR6j0ATgTq49tQQpVVe1KkaePzWRYIkU22f7KAPGmwjQlLfebV06 bWOS5HyUeueAIno67EVY3AM669JtKmS6ZqswIciEfMvsOmdDDrDje1qVUH9VVsoy UkvOQ+CPCTqwjIpbkbDrfIXJpA5qm0cCwPx8wDoYnEUN7laGjTtV0JMwGKwjBti0 y4ubs0X5xOU2ayr7xJXbeHCSB5eZKVZesbDyOCCk+lIaldih3qN6AR+Snncwjy4= =Ex7c -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN7FeAAoJEC5aWaUY1u57sq0IANSM8gKCQZbgEY62uvyhZqzN 9gRDcFbTrH/yUNMv0tt3+e2vVEbn8VIatDWG4/OYghzuI1BerKzhP7JD5J+mV8yK sB0fc6ybHmz14T962LhFkAxWKybPW3sJO/0GIy606ty0OEV8QAgPwaYvjW596MUa BAp0IRAz4/MglT/M80OkT2jFdMV+a9SAFUKvnF/21KSGo/t4qcawA/+B0c3Ownle eYt+Auk3hcgJnZAvCOwy7bcAb1b12gonk4nIwMl/Mik8IKNR5fnl1IqTiISUO2Jw PV95/7muukSrt54lY+9u4SW9o/Zf/gaNCMmK3xfDmvMug6tk0SWzkzBZLva3wNc= =04Wx -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/14 20:21, Joshua Harlow wrote: On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. Eck, this is not something people should be doing (not patching the thread module). Example for why @ https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that and see your program lock up). Once you accept/use eventlet, u shouldn't really be accepted half of it, otherwise there be dragons there; especially since openstack doesn't control what external library code does inside those libraries (and rightfully so it shouldn't), and if any library does anything like that gist code, the whole application will lock up... Real life sucks. In Neutron, we have at least two files that patch only some modules (though all of them patch threading). [Not that I mean that those files should not patch the whole library set; I have no defined view on the matter.] Though I agree that consumers with some modules unpatched are not something that should be seriosly considered, we're still left with consumers that do not patch their libraries early enough. We had an issue with tlocal when porting Neutron to oslo.messaging that resulted in the following patch: https://review.openstack.org/#/c/96791/ The issue showed up in very weird way hard to debug, so if possible, I would try to avoid similar situations with oslo.db. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUODkZAAoJEC5aWaUY1u57QrcIANLtMi1jRrfHnwV2xnwYGPOl QwZWDG6i/cdnzqrwGz+0chqRxu4KWZB5gAfMR4/ralHvGGbaa1vGp9wtzsfIJTB1 RuyE7XKXUX4rU3WoAOB7F3uF1WzFpI8ourunBG4OCE0t0YT89z9mCLfOTZNNKGxH OE89n4pnyMd3GXGtoxVINyA6pqQotYuHKG6o6LbhmTZ1UoL3P3rO+Onb1Ma2BF6Z VO84smdMnOC3yVtv4TGwrW5iBoU3RwOqxooOg4g5Jam6D++kzCKrPT9wdY7TNe+C A6IvMlad0RbygkhrLyWIWXaqCAg5VzzDvk4z6dywVkmoWS7V861mjiV4unbr0X8= =5ovh -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] periodic jobs for master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, introducing a new auxiliary feature (e.g. a new messaging backend; some specific configuration of common services, like multiple workers in neutron; a new db driver supported by oslo.db; a plugin that lacks its own third-party CI like linuxbridge in neutron...) in infra usually means creating a separate job that is gating all the patches (sometimes non-voting). It requires a lot of resources on infra side, and for voting jobs, it increases chance of the whole run to fail due to intermittent problems in the gate. So there is a push to avoid adding more gating jobs to projects. I fully support that approach, though I doubt that we should leave the code without any kind of integration testing against master. Lack of such testing means it's hard to propose a change in default components used in gate (like a switch to an eventlet aware db driver that I try to pursue [1]). For stable branches, we have so called periodic jobs that are triggered once in a while against the current code in a stable branch, and report to openstack-stable-maint@ mailing list. An example of failing periodic job report can be found at [2]. I envision that similar approach can be applied to test auxiliary features in gate. So once something is broken in master, the interested parties behind the auxiliary feature will be informed in due time. Now, we could say that functional testing for a component that includes the feature should be enough. But it doesn't seem like the approach is applicable either for system wide changes like switching to Qpid, or running all services against another db driver, or for cases when the service to be tested with a new feature is tightly coupled with core (another neutron plugin). Note that I may miss something infra side, e.g. the approach may actually already be applied in some cases unknown to me, or there are some concerns with the approach. Tell me. [1]: https://review.openstack.org/#/c/125044/ [2]: http://lists.openstack.org/pipermail/openstack-stable-maint/2014-October/002794.html Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJURoAVAAoJEC5aWaUY1u57LSkH/36lZEMQEptFgTRpbd+2yvWC 5w8kjHTRW1Imri9S1L13lNRBfdLNDMhkoSBr+bXiAJtNV19wZG5b5II4z//0By1M BRI+hwo5VSXRmUAvHuosK+AkkrTpaL0v1rkvgRR3Q7dPyA3Z3zsa2+l/Z5wjrSm2 HQXE9sOfrl2fRMvZNumzOCFq09qxDO1lfVLVyBj9u5vrdh5sbtYOTcTX81F4BkNC 2hQUZ+wvOvsC6H5vFTsTSUo3qPCPUzr8vIL0sLb0mKS7HEVrO7nym7Y6oOq9cNLE 4/xUu6v1AoPJVXpfi9Zvnq/JzyFx/xdrpO2+py3SYoN0pg8W6BjjaN8WsHrCQAk= =Sbk6 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][stable] metadata agent performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 22/10/14 02:26, Maru Newby wrote: We merged caching support for the metadata agent in juno, and backported to icehouse. It was enabled by default in juno, but disabled by default in icehouse to satisfy the stable maint requirement of not changing functional behavior. While performance of the agent was improved with caching enabled, it regressed a reported 8x when caching was disabled [1]. This means that by default, the caching backport severely impacts icehouse Neutron's performance. If I correctly follow the degradation scenario, it's caused by unneeded tokens requested from keystone each time a request hits neutron metadata agent. This should be already fixed as [1] (included in the latest 2014.1.3 release). [1]: https://review.openstack.org/#/c/118996/ So, what is the way forward? We definitely need to document the problem for both icehouse and juno. Is documentation enough? Or can we enable caching by default in icehouse? Or remove the backport entirely. If I'm correct, the issue is already solved in the latest Icehouse release, so there seems to be no need to document the regression for 2014.1.2. But yeah, sure we could put it in its release notes just in case. There is also a proposal to replace the metadata agent’s use of the neutron client in favor of rpc [2]. There were comments on an old bug suggesting we didn’t want to do this [3], but assuming that we want this change in Kilo, is backporting even a possibility given that it implies a behavioral change to be useful? We probably wouldn't consider backporting it to stable branches because it touches RPC API, and we usually avoid it there. Anyway, it shouldn't be an issue at all (as per my comment above). Thanks, Maru 1: https://bugs.launchpad.net/cloud-archive/+bug/1361357 2: https://review.openstack.org/#/c/121782 3: https://bugs.launchpad.net/neutron/+bug/1092043 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUR4XAAAoJEC5aWaUY1u57rYAH/jDqluduRLxwgHykP/NMIesj 0MnesaiFwfeHdE5z3YEnteVkxEtkDRnmTRaau9TuOJpVrUfSIA7Lpa3S79Rv4cT5 CC82FlU32fbOkCVFiXqgQvadNc3wrqHMag9FD6fpbg/MZlvV/VWHMl/z55rwhNh/ yL+CzXd9uNgZy+ng0LI1EY+u9UcLtVwF8xhLhRIu5NMRim3HeRFlFUSN41ccemRJ TdJUxMdtlYls/nCuIUk2QpSOZt1Hk2bysrBPh0etV501vsSHCq3cYZ3vjmt+jNX9 thTKlsOaFpSLWnTn5+ERXk3y7pvJxo1AGOli3sLXIDYYNYPK4Y8PRYPLm43U45o= =o7SU -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [stable] Tool to aid in scalability problems mitigation.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 24/10/14 11:56, Miguel Angel Ajo Pelayo wrote: - Original Message - Hi Miguel, while we'd need to hear from the stable team, I think it's not such a bad idea to make this tool available to users of pre-juno openstack releases. It's a great idea actually. It's great when code emerged from real life downstream support cases eventually flow up to upstream for all operator's benefit (and not just those who pay huge money for commercial service). As far as upstream repos are concerned, I don't know if this tool violates the criteria for stable branches. Even if it would be a rather large change for stable/icehouse, it is pretty much orthogonal to the existing code, so it could be ok. However, please note that stable/havana has now reached its EOL, so there will be no more stable release for it. Sure, I was mentioning havana as affected, but I understand it's already under U/S EOL, D/S distributions would always be free to backport, specially on an orthogonal change like this. About stable/icehouse, I'd like to hear from the stable maintainers. I'm for inclusion of the tool in the main neutron package. Though it's possible to publish it on pypi as a separate package, I would better apply formal review process to it, plus reduce packaging efforts for distributions (and myself). The tool may be later expanded for other useful operator hooks, so I'm for inclusion of the tool in master and backporting it back to all supported branches. Though official stable maintainership rules state that 'New features' are no-go for stable branch [1], I think they should not apply in this case since the tool does not touch production code in any way and just provides a way to heal security groups on operator demand. Also, rules are to break them. ;) Quoting the same document, Proposed backports breaking any of above guidelines can be discussed as exception requests on openstack-stable-maint list where stable-maint team will try to reach consensus. Operators should be more happy if we ship such a tool as part of neutron release and not as another third-party tool from pypi of potentially unsafe origin. BTW I wonder whether the tool can be useful for Juno+ setups too. Though we mostly mitigated the problem by RPC interface rework and ipset, some operators may still hit some limitation that could be workarounded by optimizing their rules. Also, I think the idea of having a tool with miscellaneous operator hooks in the master tree is quite interesting. I would recommend to still go with pushing it to master and then backporting to stable branches. That would also help to get more review attention from cores than stable branch requests usually receive. ;) [1]: https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes The orthogonal nature of this tool however also make the case for making it widely available on pypi. I think it should be ok to describe the scalability issue in the official OpenStack Icehouse docs and point out to this tool for mitigation. Yes, of course, I consider that as a second option, my point here is that direct upstream review time would result in better quality code here, and could certainly spot any hidden bugs, and increase testing quality. It also reduces packaging time all across distributions making it available via the standard neutron repository. Thanks for the feedback!, Salvatore On 23 October 2014 14:03, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Recently, we have identified clients with problems due to the bad scalability of security groups in Havana and Icehouse, that was addressed during juno here [1] [2] This situation is identified by blinking agents (going UP/DOWN), high AMQP load, nigh neutron-server load, and timeout from openvswitch agents when trying to contact neutron-server security_group_rules_for_devices. Doing a [1] backport involves many dependent patches related to the general RPC refactor in neutron (which modifies all plugins), and subsequent ones fixing a few bugs. Sounds risky to me. [2] Introduces new features and it's dependent on features which aren't available on all systems. To remediate this on production systems, I wrote a quick tool to help on reporting security groups and mitigating the problem by writing almost-equivalent rules [3]. We believe this tool would be better available to the wider community, and under better review and testing, and, since it doesn't modify any behavior or actual code in neutron, I'd like to propose it for inclusion into, at least, Icehouse stable branch where it's more relevant. I know the usual way is to go master-Juno-Icehouse, but at this moment the tool is only interesting for Icehouse (and Havana), although I believe it could be extended to cleanup orphaned resources, or any other cleanup tasks, in that case it could make sense to be available for K-J-I.
Re: [openstack-dev] [all] periodic jobs for master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 22/10/14 12:07, Thierry Carrez wrote: Ihar Hrachyshka wrote: [...] For stable branches, we have so called periodic jobs that are triggered once in a while against the current code in a stable branch, and report to openstack-stable-maint@ mailing list. An example of failing periodic job report can be found at [2]. I envision that similar approach can be applied to test auxiliary features in gate. So once something is broken in master, the interested parties behind the auxiliary feature will be informed in due time. [...] The main issue with periodic jobs is that since they are non-blocking, they can get ignored really easily. It takes a bit of organization and process to get those failures addressed. It's only recently (and a lot thanks to you) that failures in the periodic jobs for stable branches are being taken into account quickly and seriously. For years the failures just lingered until they blocked someone's work enough for that person to go and fix them. So while I think periodic jobs are a good way to increase corner case testing coverage, I am skeptical of our collective ability to have the discipline necessary for them not to become a pain. We'll need a strict process around them: identified groups of people signed up to act on failure, and failure stats so that we can remove jobs that don't get enough attention. There should be interest groups behind each of periodic jobs (maybe sometimes consisting of one person). Yes, jobs should be tracked, though I assume that if the group is really interested in it, it will track it on daily basis. Otherwise, we'll see it rot and eventually removed. Let's say anyone can propose a job to remove in the mailing list, and we'll assess case by case whether it's ok to remove it instead of e.g. fixing it (because we have no interested parties to track it). Another question to solve is how we disseminate state of those jobs. Do we create a separate mailing list for that? Obviously we should not reuse -dev one, and it's overkill to create one mailing list per interest group. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUSmWxAAoJEC5aWaUY1u5742kIAIIwMpTt3WL5j7RQkwtEc9qj xEHe0cC9gHtsCgxYrDkbhX2t3YmwZYg7tvzRYSJtds7hkRtiG4fjHSkdTWp3bW0m jYGoC7x4wMxjP6CPv2q/3CGdkE4+0AK9/aGurL22tcmHsqHj8COIAfuMB4np/y9n FSVyiHS86mlCx02BXIJkJwefpyO4ayM2H6IvtNjhtwYiwoH7mxQAvPpCW2vZPZOt xBSDTu0tcvlOm0xi8V8S2LDRvVaoV90w8zAh2jaNmeYVU3f/Js+X3VUa579epBOE kc0zaG1WYrcVxWkBDVGDRCBlvA9oCaQ4C8ZUFtJzGNS8Nss5/QfVndtoZSwWr5I= =L0NC -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] vm can not transport large file under neutron ml2 + linux bridge + vxlan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 27/10/14 02:18, Li Tianqing wrote: Hello, Right now, we test neutron under havana release. We configured network_device_mtu=1450 in neutron.conf, After create vm, we found the vm interface's mtu is 1500, the ping, ssh, is ok. But if we scp large file between vms then scp display 'stalled'. And iperf is also can not completed. If we configured vm's mtu to 1450, then iperf, scp all is ok. If we iperf with -M 1300, then the iperf is ok too. The vms path mtu discovery is set by default. I do not know why the vm whose mtu is 1500 can not send large file. There is a neutron spec currently in discussion for Kilo to finally fix MTU issues due to tunneling, that also tries to propagate MTU inside instances: https://review.openstack.org/#/c/105989/ /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUThORAAoJEC5aWaUY1u571u4H/3EqEVPL1Q9KgymrudLpAdRh fwNarwPWT8Ed+0x7WIXAr7OFXX1P90cKRAZKTlAEEI94vOrdr0s608ZX8awMuLeu +LB6IA7nMpgJammfDb8zNmYLHuTQGGatXblOinvtm3XXIcNbkNu8840MTV3y/Jdq Mndtz69TrjTrjn7r9REJ4bnRIlL4DGo+gufXPD49+yax1y/woefqwZPU13kO6j6R Q0+MAy13ptg2NwX26OI+Sb801W0kpDXby6WZjfekXqxqv62fY1/lPQ3oqqJBd95K EFe5NuogLV7UGH5vydQJa0eO2jw5lh8qLuHSShGcDEp/N6oQWiDzXYYYoEQdUic= =jRQ/ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] periodic jobs for master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 25/10/14 00:16, James E. Blair wrote: Andrea Frittoli andrea.fritt...@gmail.com writes: I also believe we can find ways to make post-merge / periodic checks useful. We need to do that to keep the gate to a sane scale. Yes, we have a plan to do that that we outlined at the infra/QA meetup this summer and described to this list in this email: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html Particularly this part, but please read the whole message if you have not already, or have forgotten it: * For all non gold standard configurations, we'll dedicate a part of our infrastructure to running them in a continuous background loop, as well as making these configs available as experimental jobs. The idea here is that we'll actually be able to provide more configurations that are operating in a more traditional CI (post merge) context. People that are interested in keeping these bits functional can monitor those jobs and help with fixes when needed. The experimental jobs mean that if developers are concerned about the effect of a particular change on one of these configs, it's easy to request a pre-merge test run. In the near term we might imagine this would allow for things like ceph, mongodb, docker, and possibly very new libvirt to be validated in some way upstream. * Provide some kind of easy to view dashboards of these jobs, as well as a policy that if some job is failing for some period of time, it's removed from the system. We want to provide whatever feedback we can to engaged parties, but people do need to realize that engagement is key. The biggest part of putting tests into OpenStack isn't landing the tests, but dealing with their failures. I'm glad to see people interested in this. If you're ready to contribute to it, please stop by #openstack-infra or join our next team meeting[1] to discuss how you can help. I'm sorry I've missed the email that you referred to before. Indeed, it looks like I'm not the first one who started to think about the matter. Summit wise, will there be any sessions where the subject will be discussed? -Jim [1] https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUUReJAAoJEC5aWaUY1u57H6QH/17FbSgU5vvwM03OzfSCpsZi IAG6T/UThfVQ8H08cHk6R+US9TkKdrl1QTJCDr70QhKbzLy+7OKp/H3B/PIuhaaN enqDp7ku3XQotxRTw6AW/ksLb9LCZCMMRtDiFOemC2TI6jqNXBKRz+TwFh2terY3 a9YH8IoYk2qYyLZ0fcv+OXdS7If+zD3u0PGOAJCBwKWbpUv82STdzjbDCATM779g rBC9BgYheSYPYfNjxpPKb/UN7aJZ/4TRPgK6MWktHGmqhZzZmlFPme+7x0rLdMvz 5/4m2Oh6k6Th/y1TV65jYcZID50w1esMO7tGdvmtX6Drc9lB9Y0r3fQF7R2eYpE= =FmKW -END 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.concurrency 0.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FYI we'll need the following review for oslo-incubator to merge before projects are able to consume the new library: https://review.openstack.org/#/c/122796/3 On 24/10/14 19:12, Doug Hellmann wrote: The Oslo team is pleased to announce the release of oslo.conccurrency 0.1.0, the first development release of the new library containing lockutils and processutils. Documentation for the library is available at http://docs.openstack.org/developer/oslo.concurrency/ Please report issues via launchpad: https://launchpad.net/oslo.concurrency Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUUnaGAAoJEC5aWaUY1u57hq8H/jrFMmM6a8N1aLwOIGwTlNv+ QVQZb9kC2ZzCp712U//2v8eXhxEGLIaNmnHexqyLKQuuzlpkhr+URVDjYp54AsPj RdgrYoHWm1XwCUoGjSIr2bvmaf4Lb4IVR+OVjw/ZzdWY1MoPYh+RhWNQKAFyHxD9 PY2P1M211aANP4wLaDEQfuRGVnAArep4lzDZqv9AVd7R2TTLBPO1N7WjwmVtI5Xa 8JaRq5tDQLbDX+6Q54taIBUBIcOzeGlYT/q/7Txiu+ZCNBzAqtSkc5zfBitECZ4a jB9zMLNFYxDh6wBJgloX4SsrSfsJJtMkeD5QV7z+EvO1wwdvfOF9gSYhotUt4wE= =NKei -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable][glance] Re: [Openstack-stable-maint] Stable check of openstack/glance failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The failure is due to glance_store 0.1.9 released yesterday. It's not specific to Juno. I've created a bug: https://bugs.launchpad.net/glance/+bug/1391437 and marked it as Critical. On 11/11/14 07:26, jenk...@openstack.org wrote: Build failed. - periodic-glance-docs-icehouse http://logs.openstack.org/periodic-stable/periodic-glance-docs-icehouse/ee3d10b : SUCCESS in 1m 41s - periodic-glance-python26-icehouse http://logs.openstack.org/periodic-stable/periodic-glance-python26-icehouse/867c57c : SUCCESS in 19m 38s - periodic-glance-python27-icehouse http://logs.openstack.org/periodic-stable/periodic-glance-python27-icehouse/8e6724c : SUCCESS in 16m 14s - periodic-glance-docs-juno http://logs.openstack.org/periodic-stable/periodic-glance-docs-juno/579894f : SUCCESS in 1m 30s - periodic-glance-python26-juno http://logs.openstack.org/periodic-stable/periodic-glance-python26-juno/d0ea683 : FAILURE in 21m 09s - periodic-glance-python27-juno http://logs.openstack.org/periodic-stable/periodic-glance-python27-juno/ec60681 : FAILURE in 17m 01s ___ Openstack-stable-maint mailing list openstack-stable-ma...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUYd6bAAoJEC5aWaUY1u57SIkH/1A1NvufihcNo1VIAS/U3h/l w1okw6m+IWU2B48h5pmGp9Dv2oQQ2m3XMcEVWY9O3kbTm5YUwrcqaTiDQYNBnltI 5N2IFezXnyWZkvcIrFOzYdWoDrj/5uf0iHOtQTAnEhWuBpxPhRIF696WJz5xW35r rXsc3kQ7lIFX+IO203xgX3IrTs3BUJbiHV7YVGqvyUVqLOROwLdbQTBZZ6PB8LLP LtEWrypUz18TDieAGNRM6k3Ov095QST0Ph6uCrdzh5pb/FOLf+3C+9QfsL5BBoEj YmI57ShVdWUwSxk6PZt1J01a2RnjNf7tECdpXMzOAHOQFZIurZttqChE5K7A6U8= =qFh/ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Re: [Openstack-stable-maint] Stable check of openstack/glance failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/11/14 10:41, Alan Pevec wrote: 2014-11-11 7:26 GMT+01:00 jenk...@openstack.org: - periodic-glance-python26-juno http://logs.openstack.org/periodic-stable/periodic-glance-python26-juno/d0ea683 : FAILURE in 21m 09s - periodic-glance-python27-juno http://logs.openstack.org/periodic-stable/periodic-glance-python27-juno/ec60681 : FAILURE in 17m 01s Glance Juno fails after glance-store 0.1.9 release. I see glance_store has only master branch, what's the plan for stable/juno: will there be glance_store stable/* branches or should it keep backward compatibility? (Repeating myself from another thread.) I've created a bug: https://bugs.launchpad.net/glance/+bug/1391437 and marked it as Critical. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUYd7/AAoJEC5aWaUY1u575IUH+wfTHUGLIcom47UJmIib08pt 5QJiT7PFHCU2gpkOikuQGui+WLcILiV/WOyM667Wl0dpTacW1VwHqYhhNxGAa+OL TOc98kA0R8Qebq3VoMzNzlpfLQX6eC+tClxZLoyMEdMqr6HNcrsDfYkyCdpQtwXB wjdjXvBMiEhAxzYQCUayYm31zTaW/pBbDMrb+O79N7PFGp3qMighZ+6+TNt+2pCh 8T7GEm6HWpvdpMOKSV6gayblCR9ifA91//r9CN3E+tHvy1sCwarSwhPA2TuHQARf K1lvFZH7rdkAkgZmerc6++ICddeW4jvXa9UFYtGuRYCYm/PXEnV3USsVMX1xJbA= =jy3m -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Fwd: New config options, no default change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 -- Forwarded message -- From: Dave Walker em...@daviey.com To: openstack-stable-maint openstack-stable-ma...@lists.openstack.org Date: Mon, 10 Nov 2014 21:52:23 + Subject: New config options, no default change Hi, Looking at a stable/juno cinder proposed change[0], I came across one that introduces a new config option. The default is a noop change for the behaviour, so no bad surprises on upgrade. These sort of changes feel like they are outside the 'no config changes' rule, but we have not really discussed this. What do others think? I think it's ok to introduce new config options that do not change default behaviour for major and critical issues. Quoting rules, only '*Incompatible* config file changes' are forbidden. Note that we may even change default behaviour if it exposes users to major security threats. Though the backport is SecurityImpact, it's not CVE, so usual considerations should be applied (whether the patch is self-contained, risk of regression...) I think the fix is good to go. Thanks [0] https://review.openstack.org/#/c/131987/ -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUYeOGAAoJEC5aWaUY1u57NW4H+QHdKaIaOnwGpaaV6d1hpvwp 6MCfndWrKsTq+xSQr184JiZHLLskHJ7Hp5426B5n52q80rz4VvnVixU/oSg7ivBe UV5S+i7y7IBDqlGXRYHaKa9EeDqih5YK4W6RQEWZNuWsZoQALVOON2DYflnqSOJA BgBZy9jnKyE7kqpbApHddsNLZR2SVcOMkUVBNoHM9hgmSnDigvWFSsHq7jfW88Tt 8IP9s/vPv1hReis88oRcJEgwzWYts8FoC3vFAK04VYxRNRitrQs2O3RMKgDP8TTj z1DabUapPkc8DzK8McEp46RmHO2VipCL/ErIS9p6UH8HDBdYmX5BrsJF3ziUBAc= =vqQ+ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Forwarding to openstack-dev since openstack-stable-maint is now read-only. - Forwarded Message Subject:Re: [Openstack-stable-maint] Neutron backports for security group performance Date: Tue, 11 Nov 2014 09:25:43 -0800 From: Kevin Benton blak...@gmail.com To: openstack-stable-ma...@lists.openstack.org CC: Ihar Hrachyshka ihrac...@redhat.com Hi, There are two main patches that I am interested in back-porting to improve the performance of the DB queries issued frequently by L2 agents while they are hosting VMs. These are not one-time queries during specific operations (e.g. create/delete), they also happen during normal periodic checks from the L2 agent. Due this constant background behavior, the agents start to trample the Neutron server once the deployment size scales up and will eventually exceed its resources so it can no longer service API requests even though nothing is changing. The only work-around for this right now is to abnormally scale (compared to any of the other standard OpenStack services) the Neutron server and the MySQL nodes to handle the query load. This is really discouraging to deployers (lots of extra compute power wasted as service nodes) and makes Neutron appear extremely unstable to deployers who do not know Neutron needs to be special-cased in this manner. The first patch is to batch up the ports being requested from an RPC agent before querying the database.[1] This is an internal-only change (doesn't affect the data delivered to RCP callers). Before, the server was calling the DB for each port individually so a query from a high-density port node like an L3 agent could result in 1000+ DB queries to the database. Now the service will query the database for all of the port information at once and then group it by port like the agents expect. This is probably the most significant improvement when dealing with high-density nodes and there is a rally performance graph demonstrating this in the comments. The second patch is to eliminate a join across the Neutron port table that was a completely unnecessary calculation for the DB to perform and a waste of data returned (every column from every table in the query).[2] This also doesn't change the data returned to the caller of the function (no missing dict entries, etc), so we shouldn't have to worry about out-of-tree drivers, tools, etc. being broken by this either. I will run the rally performance numbers for this one as well after the first patch gets merged since it has a higher impact than this one. Let me know if I need to elaborate on anything. 1. https://review.openstack.org/#/c/132372/ 2. https://review.openstack.org/#/c/130101/ Thanks, Kevin Benton On Wed, Oct 29, 2014 at 6:09 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: On 29/10/14 14:00, Dolph Mathews wrote: On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, there is a series of Neutron backports in the Juno queue that are intended to significantly improve service performance when handling security groups (one of the issues that are main pain points of current users): - https://review.openstack.org/130101 - https://review.openstack.org/130098 - https://review.openstack.org/130100 - https://review.openstack.org/130097 - https://review.openstack.org/130105 The first four patches are optimizing db side (controller), while the last one is to avoid fetching security group rules by OVS agent when firewall is disabled. AFAIK we don't generally backport performance improvements unless they are very significant (though I don't see anything written in stone that says so), but knowing that those patches fix pain hotspots in Neutron, and seem rather isolated, should we consider their inclusion? Should we come up with some official rule on how we handle performance enhancement backports? I'm very much in favor of backporting known performance improvements, but in my experience, not all performance improvements actually improve performance, so I'd expect an appropriate benchmark to demonstrate a real performance benefit to coincide with the proposed patch. Exactly. That's what I asked to elaborate on at: https://review.openstack.org/#/c/130101/ Also, adding Kevin into CC to make sure he is aware of the discussion. For a hypothetical example, what seems like a clear cut improvement in review 130098 (remove unused columns from a query) *might* have an unforeseen side effect later on, where another component doesn't have the data it needs, so it suddenly starts issuing a new DB query to compensate. OpenStack is certainly complicated enough that it's impossible to make accurate assumptions about performance. /Ihar ___ Openstack-stable
Re: [openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Personally, I think that enough information was provided to show that the 1st fix is critical to successful deployment of neutron without wasting nodes. I will vote +1 for now and wait for my fellow stable maintainers to give their feedback. As for the 2nd fix, let's wait for the 1st one to merge and repeat benchmarking. Cheers, /Ihar On 11/11/14 20:39, Ihar Hrachyshka wrote: Forwarding to openstack-dev since openstack-stable-maint is now read-only. Forwarded Message Subject: Re: [Openstack-stable-maint] Neutron backports for security group performance Date: Tue, 11 Nov 2014 09:25:43 -0800 From: Kevin Benton blak...@gmail.com To: openstack-stable-ma...@lists.openstack.org CC:Ihar Hrachyshka ihrac...@redhat.com Hi, There are two main patches that I am interested in back-porting to improve the performance of the DB queries issued frequently by L2 agents while they are hosting VMs. These are not one-time queries during specific operations (e.g. create/delete), they also happen during normal periodic checks from the L2 agent. Due this constant background behavior, the agents start to trample the Neutron server once the deployment size scales up and will eventually exceed its resources so it can no longer service API requests even though nothing is changing. The only work-around for this right now is to abnormally scale (compared to any of the other standard OpenStack services) the Neutron server and the MySQL nodes to handle the query load. This is really discouraging to deployers (lots of extra compute power wasted as service nodes) and makes Neutron appear extremely unstable to deployers who do not know Neutron needs to be special-cased in this manner. The first patch is to batch up the ports being requested from an RPC agent before querying the database.[1] This is an internal-only change (doesn't affect the data delivered to RCP callers). Before, the server was calling the DB for each port individually so a query from a high-density port node like an L3 agent could result in 1000+ DB queries to the database. Now the service will query the database for all of the port information at once and then group it by port like the agents expect. This is probably the most significant improvement when dealing with high-density nodes and there is a rally performance graph demonstrating this in the comments. The second patch is to eliminate a join across the Neutron port table that was a completely unnecessary calculation for the DB to perform and a waste of data returned (every column from every table in the query).[2] This also doesn't change the data returned to the caller of the function (no missing dict entries, etc), so we shouldn't have to worry about out-of-tree drivers, tools, etc. being broken by this either. I will run the rally performance numbers for this one as well after the first patch gets merged since it has a higher impact than this one. Let me know if I need to elaborate on anything. 1. https://review.openstack.org/#/c/132372/ 2. https://review.openstack.org/#/c/130101/ Thanks, Kevin Benton On Wed, Oct 29, 2014 at 6:09 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: On 29/10/14 14:00, Dolph Mathews wrote: On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, there is a series of Neutron backports in the Juno queue that are intended to significantly improve service performance when handling security groups (one of the issues that are main pain points of current users): - https://review.openstack.org/130101 - https://review.openstack.org/130098 - https://review.openstack.org/130100 - https://review.openstack.org/130097 - https://review.openstack.org/130105 The first four patches are optimizing db side (controller), while the last one is to avoid fetching security group rules by OVS agent when firewall is disabled. AFAIK we don't generally backport performance improvements unless they are very significant (though I don't see anything written in stone that says so), but knowing that those patches fix pain hotspots in Neutron, and seem rather isolated, should we consider their inclusion? Should we come up with some official rule on how we handle performance enhancement backports? I'm very much in favor of backporting known performance improvements, but in my experience, not all performance improvements actually improve performance, so I'd expect an appropriate benchmark to demonstrate a real performance benefit to coincide with the proposed patch. Exactly. That's what I asked to elaborate on at: https://review.openstack.org/#/c/130101/ Also, adding Kevin into CC to make sure he is aware of the discussion. For a hypothetical example, what
Re: [openstack-dev] [all] python-troveclient keystone v3 support breaking the world
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/11/14 15:17, Sean Dague wrote: 1) just delete the trove exercise so we can move forward - https://review.openstack.org/#/c/133930 - that will need to be backported as well. The patch is merged. Do we still need to backport it baring in mind that client revert [1] was merged? I guess no, but better check. Also, since trove client is back in shape, should we revert your devstack patch? [1]: https://review.openstack.org/#/c/133958/ /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZKC1AAoJEC5aWaUY1u57PC8IAKZSqHTNtBOUBgB8VwzUpS4Q UQZNJI8jfGjl6Eqd/H2BRvobSjKMKUnhriY4rbz0PhMUWTHrxwZFmi7i4mq5VhYq y5yv70JijVatlXjCuFps8coqvOdseprB2IugX5LJ3/4edfs1xbJ3hJti/35Iklxd 9J8FM41Whx8t62jfSmNWTah1Y+GVMDwvnwFMDqjUpzwHW1bPHgoumSh5ZwlG5hwl 3BKTNCjnYY0b6yswUKSvDafPWGSNNlQT2ZQuVTBmFq65UC5mq3SWMhZ7ikLEca2K o9gMzG5iQxpviKzHFMgZj7ZCGpjcE58GI/8D2e4btlST6blvvjqWYl1VyzJahDM= =s/Hp -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] security and swift multi-tenant fixes on stable branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13/11/14 18:17, stuart.mcla...@hp.com wrote: All, The 0.1.9 version of glance_store, and glance's master branch both contain some fixes for the Swift multi-tenant store. This security related change hasn't merged to glance_store yet: https://review.openstack.org/130200 I'd like to suggest that we try to merge this security fix and release it as as glance_store '0.1.10'. Then make glance's juno/stable branch rely on glance_store '0.1.10' so that it picks up both the multi-tenant store and security fixes. So you're forcing all stable branch users to upgrade their glance_store module, with a version that includes featureful patches, which is not nice. I think those who maintain glance_store module in downstream distributions will cherry-pick the security fix into their packages, so there is nothing to do in terms of stable branches to handle the security issue. Objections? The set of related glance stable branch patches would be: https://review.openstack.org/134257 https://review.openstack.org/134286 https://review.openstack.org/134289/ (0.1.10 dependency -- also requires a global requirements change) Does this seem ok? -Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZOouAAoJEC5aWaUY1u57aFMIAM2uhUPOLfBqNneKO89Kv3tU uE5+JP3Oh7pSCwCgw+fgnxraG9jb5QjpV8rCHewvFpyWQKwsstmNjdMeryRIX1Hn TZ42mSFUWkjDBJ/cvP2QyLXt2Il93xtqaAcLxo9enHUBR4F2lUCaZK0sm8jLkIFf TYv9jaf5QwjIWD7VO51HibwoH4f2laJv4r8MbIuyQoUpMlKpeWzmETqm5NrIUCp+ Acvbxo0EaRgAhWRIfHmFtudVjeirjc6vG9yjxFwaObYODb3sridcnr5IOBwP8jrI 1WExsAPTMU6ut2j2pABxIc0PnYAcW1uzc8w4/oPMUp0rZsaQfveCH/mRA0QnqrQ= =j14y -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Is this fix introducing another different bug to dhcp-agent?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert, Miguel, do you plan to take care of the bug and the fix, or you need help? RDO depends on the fix, also we should introduce the fix before the next Juno release that includes the bad patch, so I would be glad to step in if you don't have spare cycles. /Ihar On 13/11/14 16:44, Robert Li (baoli) wrote: Nice catch. Since it’s already merged, a new bug may be in order. —Robert On 11/13/14, 10:25 AM, Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: I believe this fix to IPv6 dhcp spawn breaks isolated metadata when we have a subnet combination like this on a network: 1) IPv6 subnet, with DHCP enabled 2) IPv4 subnet, with isolated metadata enabled. https://review.openstack.org/#/c/123671/1/neutron/agent/dhcp_agent.py I haven’t been able to test yet, but wanted to share it before I forget. Miguel Ángel ajo @ freenode.net -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZSioAAoJEC5aWaUY1u57WvIH/0pEFnXwPF9dKGbmWGvxgURW Fec0SMxl544DUyKXfhy/fEJPiedAm63TcBbBRkcLrwrGrAI23iMvAi96tCuH/eb7 uYbgoDF16b6DGUg0V2bXh8OufpgoIn4T38Vwwr0MFhfxOLbux4QfK1MshsRF1XWx LnzmLLnDuJvEYF/gq9ifAA0ekQ+OdwYaKpTEyoVXZNuSJzJOkY8BnwjPQTuRStYG M1oBsIxO9j9C/fw1/lkIKasaq9Vmy5LtG+neOyQDzM6EjZrVKO+Z9ZbJnhlkIoaF fL8dKqDBzDbFbHpE/pHcUSR5lMnBkHWjsfqC6w8NKpEKnPW6UN88oipSoB9h7U4= =NfOp -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Is this fix introducing another different bug to dhcp-agent?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 THANKS A LOT! I hope this patch will get enough attention from core reviewers to give it a chance to arrive in 2014.2.1 Juno release that is scheduled the end of the month. /Ihar On 14/11/14 04:01, Xu Han Peng wrote: I opened a new bug and submitted a fix for this problem since it was introduced by my previous patch. https://bugs.launchpad.net/neutron/+bug/1392564 https://review.openstack.org/#/c/134432/ It will be great if you can have a look at the fix and comment. Thanks! Xu Han On 11/14/2014 05:54 AM, Ihar Hrachyshka wrote: Robert, Miguel, do you plan to take care of the bug and the fix, or you need help? RDO depends on the fix, also we should introduce the fix before the next Juno release that includes the bad patch, so I would be glad to step in if you don't have spare cycles. /Ihar On 13/11/14 16:44, Robert Li (baoli) wrote: Nice catch. Since it’s already merged, a new bug may be in order. —Robert On 11/13/14, 10:25 AM, Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: I believe this fix to IPv6 dhcp spawn breaks isolated metadata when we have a subnet combination like this on a network: 1) IPv6 subnet, with DHCP enabled 2) IPv4 subnet, with isolated metadata enabled. https://review.openstack.org/#/c/123671/1/neutron/agent/dhcp_agent.py I haven’t been able to test yet, but wanted to share it before I forget. Miguel Ángel ajo @ freenode.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Xu Han ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZcBTAAoJEC5aWaUY1u57+GwIAN6ToEVtY86pDLU6uMl5yCgj KcB8zxPVCa/tRYF96vRJKFts+gnxIE321Nk7P3WBDvL/YsZnNXkGxWUEICPRb9AU dS/xXXRe2wVIzESXvjsPvc5x3E3jOMWQlOQHAEmKAAVcwbaAAOWoTuo0R9OjxVam pWbBvQd0ThWfBVCQH6JiRCtmXwy7CUVEluhN40GEhw7R5abTixIB2KazKAIU5utk dxRG9X/5uaEzCeElTIoyWHsVm10N0p6gcQVQFeaTzyQTUAgf5N2nJDNfMD0ZPuOl YAF9s5L2Eu/2Y7kgxzGWgZ3gNs7KZvBKT5UZUtElNU8v22WVoDo9eZC0qSYb1Cc= =b2/h -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][nova] Doc build failure during backport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/11/14 02:36, Fei Long Wang wrote: Greetings, Recently, I'm working on fixing Nova evacuate bugs for RBD. And both the two patches have been merged in Kilo[1,2]. But during backporting them to Juno/Icehouse, one patch got a document build failure, see http://logs.openstack.org/26/131626/3/check/gate-nova-docs/789d9bd/console.html Therefore, I have to change the docstring format a little bit. But seems there are some reviewers have concern about this. Though personally I think it's ok, given we even could resolve conflicts by changing code during backporting. So may I get some suggestion/comments about this situation? Thanks. Personally, I don't see it as a fight worth fighting. Pinning of the version in master was controversial from the start [1]. Ideally, you would patch master docstring, then meld the patch into yours. Though once final sphinx 1.3 is released, master will be forced to fix all those issues including the docstring you backport, so I don't see there is value in pushing back the backport for such a minor reason. Let's not allow the next Juno release (2014.2.1) scheduled the end of the month to miss the fix for procedural reasons. [1]: https://bugs.launchpad.net/oslotest/+bug/1379998/comments/5 [1] https://review.openstack.org/131626 [2] https://review.openstack.org/131613 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZcSJAAoJEC5aWaUY1u57F8UH/jNNErCnh+0zVdQqfPLYmgSw kQO2+w2WZvjq1N931eLM3Q6mdz053JamU3pUbD2aHjJTj0Zl6InPvJBUOTYZRfY1 uF0JU5jUWmbaZFKZ6Xqxre52ZOt7scyVlCO5dT/aP9D4eHoj6ZnBqWO8fDaIHhht PX2zf+/Rkof8oDivLccED71W0KWTRA4iZCA3/C5kpe111VaPE1AxRA+sRoe4bBTz XyCSGFvXbB9SDWv9kDt2IuiW6LNUeKTsjsCJHYNnYMwwLRhn7AH5m4pqGysscOOU /JITCYZTbfFiLKdlo4QdvDJ9TrUqrC+ilydUyVFBOTGTXP57443BRZHXlW0f6eg= =xx1Z -END 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] The right (and the wrong) way of handling module imports in oslo-incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/11/14 09:14, Flavio Percoco wrote: On 13/11/14 23:25 +, Amrith Kumar wrote: At the suggestion of Doug Hellmann, and relative to a conversation with him and Flavio at Summit. Doug suggested that I pose this question on the dev mailing list so someone from OSLO can communicate the answer to the entire community (rather than just the private email exchange that we had). Here’s the situation, I’m using loopingcall.py as an example, this is not limited to this module but serves as an example. An OSLO incubator module loopingcall depends on another OSLO incubator module timeutils. timeutils has graduated [drum-roll] and is now part of oslo.utils. There is also other project code that references timeutils. So, to handle the graduation of timeutils, the changes I’ll be making are: 1. Remove timeutils from openstack-common.conf 2. Make the project code reference oslo.utils But what of loopingcall? Should I a. Update it and change the import(s) therein to point to oslo.utils, or b. Sync the oslo-incubator code for loopingcall, picking up all changes at least upto and including the change in oslo-incubator that handles the graduation of oslo.utils. In speaking with Doug and Flavio, (after I submitted copious amounts of code that did (a)) above, I’ve come to learn that I chose the wrong answer. The correct answer is (b). This doesn’t have to be part of the same commit, and what I’ve ended up doing is this … c. Leave timeutils in project/openstack/common and let oslo-incubator depend on it while migrating the project to use oslo.utils. In a subsequent commit, a sync from oslo-incubator can happen. I’d like someone on OSLO to confirm this, and for other projects whose lead I followed, you may want to address these in the changes you have in flight or have already merged. `b` is the right answer there. As a general rule - probably the easiest way to solve the above dilema - people should *never* modify incubator modules in the project. Sticking to this rule will automatically answer the question of how to update, maintain and consume code from oslo-incubator. Crazy idea: we should have a bot that -1's all the patches that modify oslo-incubator code without being marked by some special tag (OsloSync?). We've slipped several local modifications to those files before (I know two cases in Neutron, though I hardly monitor all the patch queue). If there are projects that picked `a` as the right answer, please, update your patches and follow the already well defined workflow for oslo-incubator. Doing otherwise will just make things harder for us who maintain oslo, for stable maintenance and for your own contributors. Amrith, thanks for bringing this up and for updating your patches, I know it's a pain and I appreciate your collaboration there. Cheers, Flavio P.S: Gentle note. Oslo is not an acronym. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZcwOAAoJEC5aWaUY1u5741wH/2B/Pf56YtAaru7jAR9bN7IZ KNY2zkGIDNMZQJWz3DxW7R0myKdmHVqrM/wA+8Lkf0l/ITh1LtiXtRxx5E2sPnJP jef3ODTESooOKGcGOxvKO8tt/Bl4EorJzkX70dyJzlV7fKfZuwCFpZCp73S7npBh BYd5Dfhi+pTyIZvtWSYKJzloJ/BasvKM+pwvlVsV9JIwMNrwwaLx2yDh+D3fltEg bROJooq5J6z/pN19bZ5UkFU2z9lHNI6K6pa1eWLqQdm8WJnNmfmJjiX+vO2wp1z5 7qDsKL/dbHzXfPrBX8MqO9SEvt/jrDS8TeA2tMgAZg8+F5ST1dVHFGxWXJ4eoF4= =2v6F -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Organizational changes to support stable branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13/11/14 12:34, Thierry Carrez wrote: TL;DR: Every project should designate a Stable branch liaison. Hi everyone, Last week at the summit we discussed evolving the governance around stable branches, in order to maintain them more efficiently (and hopefully for a longer time) in the future. The current situation is the following: there is a single stable-maint-core review team that reviews all backports for all projects, making sure the stable rules are followed. This does not scale that well, so we started adding project-specific people to the single group, but they (rightfully) only care about one project. Things had to change for Kilo. Here is what we came up with: 1. We propose that integrated projects with stable branches designate a formal Stable Branch Liaison (by default, that would be the PTL, but I strongly encourage someone specifically interested in stable branches to step up). The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports are reviewed. They are also the contact point for stable branch release managers around point release times. Where is the list of liaisons tracked? Do we have a page similar to oslo liaisons one? FYI I'd step in as a formal stable liaison for neutron (unless there are objections from project PTL; added Kyle to CC). 2. We propose to set up project-specific review groups ($PROJECT-stable-core) which would be in charge of reviewing backports for a given project, following the stable rules. Originally that group should be the Stable Branch Liaison + stable-maint-core. The group is managed by stable-maint-core, so that we make sure any addition is well aware of the Stable Branch rules before they are added. The Stable Branch Liaison should suggest names for addition to the group as needed. 3. The current stable-maint-core group would be reduced to stable branch release managers and other active cross-project stable branch rules custodians. We'll remove project-specific people and PTLs that were added in the past. The new group would be responsible for granting exceptions for all questionable backports raised by $PROJECT-stable-core groups, providing backports reviews help everywhere, maintain the stable branch rules (and make sure they are respected), and educate proposed $PROJECT-stable-core members on the rules. 4. Each stable branch (stable/icehouse, stable/juno...) that we concurrently support should have a champion. Stable Branch Champions are tasked with championing a specific stable branch support, making sure the branch stays in good shape and remains usable at all times. They monitor periodic jobs failures and enlist the help of others in order to fix the branches in case of breakage. They should also raise flags if for some reason they are blocked and don't receive enough support, in which case early abandon of the branch will be considered. Adam Gandelman volunteered to be the stable/juno champion. Ihar Hrachyshka (was) volunteered to be the stable/icehouse champion. 5. To set expectations right and evolve the meaning of stable over time to gradually mean more not changing, we propose to introduce support phases for stable branches. During the first 6 months of life of a stable branch (Phase I) any significant bug may be backported. During the next 6 months of life of a stable branch (Phase II), only critical issues and security fixes may be backported. After that and until end of life (Phase III), only security fixes may be backported. That way, at any given time, there is only one stable branch in Phase I support. 6. In order to raise awareness, all stable branch discussions will now happen on the -dev list (with prefix [stable]). The openstack-stable-maint list is now only used for periodic jobs reports, and is otherwise read-only. Let us know if you have any comment, otherwise we'll proceed to set those new policies up. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZdfuAAoJEC5aWaUY1u57eusIALvXfBsEXTY8NQuaE4jQew74 PB7UkdO4lxAd6QYbqt3/0USgw7L9nLQrK8k+PZPJlCEDQkeRMwIfAyWSdpTvSK+H BnPFoOezI+lu01VT7Gut1uwNd9pKkQLxfR4/bCgDpV0Iy5fHFRWMpbBnKTuZpoh+ y9Wd2t6D1w5refrWIL7tzbwElhnp+Lee0HeaEnYyv3ktF7M6di62iANYrSeRvzDA EzQsSaUdb9joUQMijgcBtCqLOixUrWpeX+by1yOhbgJ82733V9gbg13hS1jzS9t9 KI2v2u3Xga9F43gCYEtRtbVlsFIZItds60vl7uw4aIEFhzeYm3/mQWamyrGvlrs= =B5OD -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/11/14 20:17, Jay S. Bryant wrote: All, This is a question I have been struggling with for Cinder recently. Where do we draw the line on backports. How do we handle config changes? One thing for Cinder I am also considering, in addition to whether it changes the default functionality, is whether it is specific to the submitter's driver. If it is only going to affect the driver I am more likely to consider it than something that is going to impact all of Cinder. What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I want to make sure that people use that. I'm not sure anyone tracks commit messages to create release notes. A better way to handle this is to create a draft, post it in review comments, and copy to release notes draft right before/after pushing the patch into gate. Thanks! Jay On 11/11/2014 06:50 AM, Alan Pevec wrote: New config options may not change behavior (if default value preserves behavior), they still make documentation more incomplete (doc, books, and/or blogposts about Juno won't mention that option). That's why we definitely need such changes described clearly in stable release notes. I also lean to accept this as an exception for stable/juno, I'll request relnote text in the review. Cheers, Alan ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUdI3AAAoJEC5aWaUY1u57YDkH/1LL/Y0gL2egRs1F6pgoaVbk bEREvavZMyV6JFrojfJz2HKVxeo//0AdCcr3+W7KH5pXtposhg3Xf5v6bhF+n0gO NX8u23z2zBLh6xdYcJHiRtMz1zhXT66xDhZso4bMNAL98glGOv1rrbkmkj43pR2L TKSgRyes75nEBOlvPi79Co+2Ti3Z60HbS1NwgqCTGb9yRV3o0JDMZ3+zdFKlrTTf 0ZkrqEHtDaS0wEJmi7vqDAflNBPPn4lo8mAcju9k80lwrCs7g6VdqYJec0Nb/1gJ Foj6vWRPHDH1ftph3am4yhY6Gs+dXQ1nmhEK0zFucDeLXz01Gql3vKX0xK18Rho= =6ABy -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Proposal to add Dave Walker back to stable-maint-core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 +2 On 27/11/14 10:15, Alan Pevec wrote: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUduzkAAoJEC5aWaUY1u57LqEIANo5jmbsNqMWC3EsjpNTlDyN XRlMesMKl1aPglsM9bdB7orStkkynHTyMZxIo0Z9DgLSmh3ZaB02ayog8Aj3BJ5d vXBBg06VUXSXQEl1h1wEsVvOqFsuEwXhrCz5w5gPKb+bYD4YZq5sU/KG52vcYwtw O7JJBDlrUy5MSXbqrKYQqDorJqSBUsa4FLkXuW6N+YiVv+POd4hL0VNDdOMDzPYC xmAfsa/piY5MPMXzmi9Z9A75Tyxd/Ck3VcpiSWzcO+phCRYnEzQkmX4mPiElRnSX nPA+FTNDLA6V9NCCbAdJNHNKt+e/Xe+4QsmClqKSy9BQvw8/hHvaW1ae0t3VU3U= =I7+h -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] suds-jurko, new in our global-requirements.txt: what is the point?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 27/11/14 12:09, Thomas Goirand wrote: On 11/27/2014 12:31 AM, Donald Stufft wrote: On Nov 26, 2014, at 10:34 AM, Thomas Goirand z...@debian.org wrote: Hi, I tried to package suds-jurko. I was first happy to see that there was some progress to make things work with Python 3. Unfortunately, the reality is that suds-jurko has many issues with Python 3. For example, it has many: except Exception, e: as well as many: raise Exception, 'Duplicate key %s found' % k This is clearly not Python3 code. I tried quickly to fix some of these issues, but as I fixed a few, others appear. So I wonder, what is the point of using suds-jurko, which is half-baked, and which will conflict with the suds package? It looks like it uses 2to3 to become Python 3 compatible. Outch! That's horrible. I think it'd be best if someone spent some time on writing real code rather than using such a hack as 2to3. Thoughts anyone? That sounds very subjective. If upstream is able to support multiple python versions from the same codebase, then I see no reason for them to split the code into multiple branches and introduce additional burden syncing fixes between those. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUd0wMAAoJEC5aWaUY1u57gVMIAI70aQjReaa32WVJExL18c4t QfJ3U+4yGxURIwqu/VKfpujN+KNQ7JWR+zqSUpv1gGxRTQcwFYLLKeW9XRxBnETw 0YxLvCrju3MInFDCFZrJzm3mTMlnQSosQSoK08Phn++cyRs1R/isaWPU7UHMbiSM jIqRQkLYYPoSnhiTm1LkOoWg3oP82g3vxOPQmAlTAlx38lJ81ioBq7z9rRQzW+CX DcZy+64t+iePY9w0P4mvXdl/saDAlh7Hl/nu7RKcC5ycoa2un07N6SAazycMPvln naQvaXFfjPjGP5ToLNWIDwhRWmMkUa581ng37+6LewvbFNUDttKCHobp8cvVqy8= =d0S7 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] suds-jurko, new in our global-requirements.txt: what is the point?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 27/11/14 19:10, Thomas Goirand wrote: On 11/28/2014 12:06 AM, Ihar Hrachyshka wrote: On 27/11/14 12:09, Thomas Goirand wrote: On 11/27/2014 12:31 AM, Donald Stufft wrote: On Nov 26, 2014, at 10:34 AM, Thomas Goirand z...@debian.org wrote: Hi, I tried to package suds-jurko. I was first happy to see that there was some progress to make things work with Python 3. Unfortunately, the reality is that suds-jurko has many issues with Python 3. For example, it has many: except Exception, e: as well as many: raise Exception, 'Duplicate key %s found' % k This is clearly not Python3 code. I tried quickly to fix some of these issues, but as I fixed a few, others appear. So I wonder, what is the point of using suds-jurko, which is half-baked, and which will conflict with the suds package? It looks like it uses 2to3 to become Python 3 compatible. Outch! That's horrible. I think it'd be best if someone spent some time on writing real code rather than using such a hack as 2to3. Thoughts anyone? That sounds very subjective. If upstream is able to support multiple python versions from the same codebase, then I see no reason for them to split the code into multiple branches and introduce additional burden syncing fixes between those. /Ihar Objectively, using 2to3 sux, and it's much better to fix the code, rather than using such a band-aid. It is possible to support multiple version of Python with a single code base. So many projects are able to do it, I don't see why suds would be any different. Their support matrix starts from Python 2.4. Maybe that's a reason for band-aid and not using runtime cross-version wrappers. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUeF4XAAoJEC5aWaUY1u57Ty0IALsSr5MRNvpuq9g0/GTFGynh qXraVZ/km+whgFtrheyM4+tVuwew2aY7y1Sb/ACuvjqBmtbnWPqEFgD/LIhmSe+R uraelATiECOWnHLYYfIdQp8r3NkxlI1C2bwc6UkELYVgg/4mjqZa6ZtwSIkJB/2H BrZ7Z45no0zIkAIDMPtc7GEG3aWPFLEhT7sG0JEu59z/F964wP6bXZrm3iqUxE1u ft4mQBe3DCMhVjbhCLBXid843lvPLboOIcgRswKQc1GOjFCU3DEfKdTsxDr+koS2 UPc6UkOWR9pN/X5riijrSIg2QPTtJrIjRvdgzc/TJfq3K9h1Z+FxIsmKUFHM4Ls= =Xl13 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] Re: [neutron] the hostname regex pattern fix also changed behaviour :(
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28/11/14 01:26, Angus Lees wrote: Context: https://review.openstack.org/#/c/135616 As far as I can make out, the fix for CVE-2014-7821 removed a backslash that effectively disables the negative look-ahead assertion that verifies that hostname can't be all-digits. Worse, the new version now rejects hostnames where a component starts with a digit. Thanks for raising the issue! This certainly addressed the immediate issue of that regex was expensive, but the change in behaviour looks like it was unintended. Given that we backported this DoS fix to released versions of neutron, what do we want to do about it now? I don't think we've actually *released* any stable versions with the patch included, yet (neither Icehouse nor Juno). (Adding [stable] tag to subject to raise awareness). I'm adding the mail thread to stable/juno etherpad to track the backwards incompatibility (probably a blocker for the forthcoming release): https://etherpad.openstack.org/p/StableJuno In general this regex is crazy complex for what it verifies. I can't see any discussion of where it came from nor precisely what it was intended to accept/reject when it was introduced in patch 16 of https://review.openstack.org/#/c/14219. If we're happy disabling the check for components being all-digits, then a minimal change to the existing regex that could be backported might be something like r'(?=^.{1,254}$)(^(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_-]{,61}[a-zA-Z0-9])\.)*(?:[a-zA-Z]{2,})$)' Alternatively (and clearly preferable for Kilo), Kevin has a replacement underway that rewrites this entirely to conform to modern RFCs in I003cf14d95070707e43e40d55da62e11a28dfa4e With the change, will existing instances work as before? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUeGDkAAoJEC5aWaUY1u57kG0IAMz0jVCJ3D0gr6rydW/b3niY tu7rQv/kKwfsmzCiKA8cpGoiGVm/23iwra5wU3oLSLQJDn+6XFBzseYy6F0Vy5+v D6FUu3/AH5OOj3KeeC7TR500s+eR3kPNYqd/pzNYmpeW7b+yKJZUocgHjuYmiB0e B4/JygQhox1zFdKOjsHF+x0PCeAc49VwQZkywN97TiFiwOqqr6iC3tmnOPnFbjNV dwGqlPdiaS0GJ2STDnEJ8XABz8//Q7qwHBwQvM0VSIHkUmDI228crgWImAEClbyG IIH67vjOJEFyBMRK0fMOqBT1CnUfS/OX7/OFwJVQh6fAyMKrMuXCixPUYQuSUBI= =NYrv -END 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] change to Oslo release process to support stable branch requirement caps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Are we going to have stable releases for those branches? On 01/12/14 15:19, Doug Hellmann wrote: As part of setting up version caps for Oslo and client libraries in the stable branches, we discovered that the fact that we do not always create stable branches of the Oslo libraries means the check-requirements-integration-dsvm job in stable branches is actually looking at the requirements in master branches of the libraries, and failing in a lot of cases. With the move away from alpha version numbers toward version caps and patch releases, we’re going to change the Oslo release processes so that at the end of a cycle we always create a stable branch from the final version of each library released in the cycle. Thanks to Clark and Thierry for helping by creating stable/icehouse and stable/juno branches for most of the libraries, though we’ve discovered one or two that we missed so we’re still working on a few cases. For Kilo, we will branch all of the library repositories at the end of the cycle, probably following the same process as is used for the other projects (though the details remain to be worked out). Thanks, Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUfHuyAAoJEC5aWaUY1u57yVAH/Al27yWpaEFSuRMuni+ItdTW +avoRoVgpeYLR8kJqo/P2YBdht12ddVjU/JZh1VBvcN7KHClvd6gyBBpAXlq66aQ lRG2uNSy6+ufcaE7UTyt/beEmyNpZvW/yyaknvwmAZaU1+h/9ZnFByf6WgtuwsYr o3N02GzUJkUF0MNGj14eWKGTTTO1M/xbj20ZttKLn1fifPp+pjg2dLrnXYqXdEVW rzenlcCifPLWhHRh4PPJmPrgJYjFgLp5FYEbxMAEhxOdPHR+UiLDmifrYYLzMcMy hDBjp38ej35LyfHzxxHUkm7Km4P/p/Cuib4Zw77FIVnspTBORNnPovOh/Lf/yJ8= =GJIn -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sqlalchemy-migrate call for reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It's weird: we run python33 job for gate but not checks. Adding Cyril Roelandt who ported the library to py3 to CC. On 01/12/14 23:40, Thomas Goirand wrote: On 12/01/2014 06:19 PM, Ihar Hrachyshka wrote: Indeed, the review queue is non-responsive. There are other patches in the queue that bit rot there: https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z I did +2 some of the patches which I thought were totally unharmful, but none passed the gate. Now, it looks like the Python 3.3 gate for it is broken... :( Where are those module not found issues from? Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUfY4VAAoJEC5aWaUY1u57HmsIAJku4Zt/QK2HsV8RwGfgSRSW +WpET+Kqlhcx4WJEqaUApF/+N40NwMYrOEP4Tj1R1RAtT38ABQexvi3uvbQTEb71 XIVL+fzVP99GHqHKROYDWplXZCWfxlQJN2d43c0/JgEWWExZwlGNZbjA70vuCjjt eW3IpjcwKXvmeUTqHfQXTqttzDRePh9tuHxTooZAZ+hm+HOd0WUrtHI44KnxXGt2 1LAynY848I2bxxUrD3PgZWb/N9vwQ5+gZWv4KMRHtDvZJaTa1Oyycflqn+55HBn5 VShaWyVR9zvAKKL6FxIrtnO59EZdtb12YyDecskmIYCg07ywYZGQAUxKuIZK9oI= =bULf -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Exception proposals for 2014.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/12/14 14:22, Alan Pevec wrote: Hi all, here are exception proposal I have collected when preparing for the 2014.2.1 release, stable-maint members please have a look! General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release. https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z +2, let's keep all deps in sync. Those updates do not break anything for existing users. Ceilometer (all proposed by Ceilo PTL) https://review.openstack.org/138315 Already pushed to gate (why?) https://review.openstack.org/138317 https://review.openstack.org/138320 https://review.openstack.org/138321 https://review.openstack.org/138322 Cinder https://review.openstack.org/137537 - small change and limited to the VMWare driver Glance https://review.openstack.org/137704 - glance_store is backward compatible, but not sure about forcing version bump on stable I think this one should not go in. For stable releases in downstream, it's quite common to backport fixes for bugs. We don't fix bugs by bumping versions. https://review.openstack.org/137862 - Disable osprofiler by default to prevent upgrade issues, disabled by default in other services Hm, looks more like a version incompatibility. Should we instead set glance and osprofiler versions in line? I'm probably ok with disabling debug features even in stable releases, but this one seems like a wrong fix for a rightful issue. Comments? Horizon standing-after-freeze translation update, coming on Dec 3 https://review.openstack.org/138018 - visible issue, no translation string changes https://review.openstack.org/138313 - low risk patch for a highly problematic issue Neutron https://review.openstack.org/136294 - default SNAT, see review for details, I cannot distil 1liner :) As I told in comments, this one seems to me making the code in line with official documentation, so can be considered as a bug fix. Though the change in behaviour is pretty significant to be cautious. https://review.openstack.org/136275 - self-contained to the vendor code, extensively tested in several deployments +2. Nova https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno+topic:1386236/juno,n,z - - soaked more than a week in master, makes numa actually work in Juno Sahara https://review.openstack.org/135549 - fix for auto security groups, there were some concerns, see review for details ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUfdT4AAoJEC5aWaUY1u574hoIAJtE6dIAtCPcJw4H83EsFoEh pNDHiHTBmjMCJVFtEKtBUgKT/pRZw5zyvRXYHQSk99Lqw7StcYn2gyW9sDQJSclv ak8wm5KCDtZMnkzfisDtTILx2AQj8RHw1UWVrsjqkoS0vyjUW6dfOpiyxd7o6s9n zJYgGi5uO1EZO+oLDk5NkKl6pDu4OZNbx1iLk+0EPmpjPD9ZT6AdacvtW5oM3+4c udA4CCsiAkHXvUutM0GNeftuOk4TBj6evnnzOai5mZC4QoT3/vhd1or+AEjLtEqO QhM8MT8u+mSDhhlbfblNqIf/bBHOkgZcEX4DMdPtz9R/LtqvBDhDjtyOjJ8cG6w= =bcTW -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Deprecating old security groups code / RPC.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo wrote: During Juno, we introduced the enhanced security groups rpc (security_groups_info_for_devices) instead of (security_group_rules_for_devices), and the ipset functionality to offload iptable chains a bit. Here I propose to: 1) Remove the old security_group_info_for_devices, which was left to ease operators upgrade path from I to J (allowing running old openvswitch agents as we upgrade) Doing this we can cleanup the current iptables firewall driver a bit from unused code paths. +1. I suppose this would require a major RPC version bump. 2) Remove the option to disable ipset (now it’s enabled by default and seems to be working without problems), and make it an standard way to handle “IP” groups from the iptables perspective. Is ipset support present in all supported distributions? Thoughts?, Best regards, Miguel Ángel Ajo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUgG1jAAoJEC5aWaUY1u57aK4H/1G0R0NgURf1l7WCx27VqRDR jdFlYzecMk2E6h84Fv5tJgGqAm6mGEFUrLf8MJ9+kDB33Syb+zvxJc9v6CvMw7br o+Qjk4lbHiiko1W8kDmq+onjUDHExapTR1+PsSX0HmuEvwV8yrAm/VJyccAAiqB6 XPrWG4Xft2zEp004/uT9jzJPeW4YhRNY84Sa2C1ghemzKn43QYlu8U3DfuDzfQFP 2MjzTwdP1FfBIX0jhXHrMlnHGuuxAscL9v6DM7Np2Iro6ExXK1ry9ex4/NWbdcIY sP9MkuA2wAMYE8pN1UM4LwSPg2rpEZEuwJfXyTohshcVHDoyPk81F4Q6R+ABPqM= =xzY6 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Exception proposals for 2014.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/12/14 14:22, Alan Pevec wrote: Hi all, here are exception proposal I have collected when preparing for the 2014.2.1 release, stable-maint members please have a look! General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release. https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z Ceilometer (all proposed by Ceilo PTL) https://review.openstack.org/138315 https://review.openstack.org/138317 https://review.openstack.org/138320 https://review.openstack.org/138321 https://review.openstack.org/138322 Cinder https://review.openstack.org/137537 - small change and limited to the VMWare driver Glance https://review.openstack.org/137704 - glance_store is backward compatible, but not sure about forcing version bump on stable https://review.openstack.org/137862 - Disable osprofiler by default to prevent upgrade issues, disabled by default in other services Horizon standing-after-freeze translation update, coming on Dec 3 https://review.openstack.org/138018 - visible issue, no translation string changes https://review.openstack.org/138313 - low risk patch for a highly problematic issue Neutron https://review.openstack.org/136294 - default SNAT, see review for details, I cannot distil 1liner :) https://review.openstack.org/136275 - self-contained to the vendor code, extensively tested in several deployments I'd like to request another exception for Neutron to avoid introducing regression in hostname validation for DNS nameservers: https://review.openstack.org/#/c/139061/ Nova https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno+topic:1386236/juno,n,z - - soaked more than a week in master, makes numa actually work in Juno Sahara https://review.openstack.org/135549 - fix for auto security groups, there were some concerns, see review for details ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUgG3pAAoJEC5aWaUY1u57E7gH/Ry5zrN5/1bA8M2NkkhmJ1D4 ks9sX4ivZYjSeV5/4qfLsrHAnO2+R5H3CmVHmS2Us3s5ZTU4CTiKCt9TAmWDy5pd f6YmpjzOnszusXMMibi1K7sWZGmC0P5zOSxyPZh1W3rljy7WZSeR/P3NtAqqBw3M eMb0gEDBDkyn8JNWSxM5mjYHYsYnfU6CddZWT/EoOQExttFKRyAd35ugOJnvbQoR F3Cu3k/BgsxSPYZIuLzf+W1YQBsnGpH9AK7LwTzVfsYJgX1ggiVGU8Rdh3FvccIx hV84PKMwNccIgwIMxqK83QHtV4p1FJ/TN4UmActXSgR1J+QUEFgH32zAolIMLlw= =n/d7 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/12/14 16:59, Vadivel Poonathan wrote: Hi Kyle and all, Was there any conclusion in the design summit or the meetings afterward about splitting the vendor plugins/drivers from the mainstream neutron and documentation of out-of-tree plugins/drivers?... It's expected that the following spec that covers the plugins split to be approved and implemented during Kilo: https://review.openstack.org/134680 Thanks, Vad -- On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan vadivel.openst...@gmail.com mailto:vadivel.openst...@gmail.com wrote: Hi Kyle and Anne, Thanks for the clarifications... understood and it makes sense. However, per my understanding, the drivers (aka plugins) are meant to be developed and supported by third-party vendors, outside of the OpenStack community, and they are supposed to work as plug-n-play... they are not part of the core OpenStack development, nor any of its components. If that is the case, then why should OpenStack community include and maintain them as part of it, for every release?... Wouldnt it be enough to limit the scope with the plugin framework and built-in drivers such as LinuxBridge or OVS etc?... not extending to commercial vendors?... (It is just a curious question, forgive me if i missed something and correct me!). You haven't misunderstood anything, we're in the process of splitting these things out, and this will be a prime focus of the Neutron design summit track at the upcoming summit. Thanks, Kyle At the same time, IMHO, there must be some reference or a page within the scope of OpenStack documentation (not necessarily the core docs, but some wiki page or reference link or so - as Anne suggested) to mention the list of the drivers/plugins supported as of given release and may be an external link to know more details about the driver, if the link is provided by respective vendor. Anyway, besides my opinion, the wiki page similar to hypervisor driver would be good for now atleast, until the direction/policy level decision is made to maintain out-of-tree plugins/drivers. Thanks, Vad -- On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana edgar.mag...@workday.com mailto:edgar.mag...@workday.com wrote: I second Anne’s and Kyle comments. Actually, I like very much the wiki part to provide some visibility for out-of-tree plugins/drivers but not into the official documentation. Thanks, Edgar From: Anne Gentle a...@openstack.org mailto:a...@openstack.org Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository? On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: Vad: The third-party CI is required for your upstream driver. I think what's different from my reading of this thread is the question of what is the requirement to have a driver listed in the upstream documentation which is not in the upstream codebase. To my knowledge, we haven't done this. Thus, IMHO, we should NOT be utilizing upstream documentation to document drivers which are themselves not upstream. When we split out the drivers which are currently upstream in neutron into a separate repo, they will still be upstream. So my opinion here is that if your driver is not upstream, it shouldn't be in the upstream documentation. But I'd like to hear others opinions as well. This is my sense as well. The hypervisor drivers are documented on the wiki, sometimes they're in-tree, sometimes they're not, but the state of testing is documented on the wiki. I think we could take this approach for network and storage drivers as well. https://wiki.openstack.org/wiki/HypervisorSupportMatrix Anne Thanks, Kyle On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan vadivel.openst...@gmail.com mailto:vadivel.openst...@gmail.com wrote: Kyle, Gentle reminder... when you get a chance!.. Anne, In case, if i need to send it to different group or email-id to reach Kyle Mestery, pls. let me know. Thanks for your help. Regards, Vad -- On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan vadivel.openst...@gmail.com mailto:vadivel.openst...@gmail.com wrote: Hi Kyle, Can you pls. comment on this discussion and confirm the requirements for getting out-of-tree mechanism_driver listed in the
Re: [openstack-dev] [oslo] interesting problem with config filter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/12/14 21:58, Doug Hellmann wrote: As we’ve discussed a few times, we want to isolate applications from the configuration options defined by libraries. One way we have of doing that is the ConfigFilter class in oslo.config. When a regular ConfigOpts instance is wrapped with a filter, a library can register new options on the filter that are not visible to anything that doesn’t have the filter object. Unfortunately, the Neutron team has identified an issue with this approach. We have a bug report [1] from them about the way we’re using config filters in oslo.concurrency specifically, but the issue applies to their use everywhere. The neutron tests set the default for oslo.concurrency’s lock_path variable to “$state_path/lock”, and the state_path option is defined in their application. With the filter in place, interpolation of $state_path to generate the lock_path value fails because state_path is not known to the ConfigFilter instance. It's not just unit tests. It's also in generic /etc/neutron.conf file installed with the rest of neutron: https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L23 There is nothing wrong in the way neutron sets it up, so I expect the fix to go in either oslo.concurrency or oslo.config, whichever is achievable. The reverse would also happen (if the value of state_path was somehow defined to depend on lock_path), and that’s actually a bigger concern to me. A deployer should be able to use interpolation anywhere, and not worry about whether the options are in parts of the code that can see each other. The values are all in one file, as far as they know, and so interpolation should “just work”. +1. It's not deployer's job to read code and determine which options are substitution-aware and which are not. I see a few solutions: 1. Don’t use the config filter at all. +1. And that's not just for oslo.concurrency case, but globally. 2. Make the config filter able to add new options and still see everything else that is already defined (only filter in one direction). 3. Leave things as they are, and make the error message better. Because of the deployment implications of using the filter, I’m inclined to go with choice 1 or 2. However, choice 2 leaves open the possibility of a deployer wanting to use the value of an option defined by one filtered set of code when defining another. I don’t know how frequently that might come up, but it seems like the error would be very confusing, especially if both options are set in the same config file. I think that leaves option 1, which means our plans for hiding options from applications need to be rethought. Does anyone else see another solution that I’m missing? I'm not an oslo guy, so I leave the resolution to you. Doug [1] https://bugs.launchpad.net/oslo.config/+bug/1399897 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUiHHnAAoJEC5aWaUY1u57DOsH/i+FY46YWH2lSguYPS5h+Ciu S/fwzamKrcF6Y2pipl+j55CiIyIejlnXwE+UV90k4gM9G6vl4T6u1w6N9dus67pu 6kWHty4eDGHGIuj0iGWIWUNPN6ChHNmhxoFadvZKCBWULeTvh3DL/Ply4MYx4bqF MbtpAE5Qh2OUUO977kSjcULZtgrIYeInKd5tdZkLmXf0PQnMKU9rEwa8DNZL24Ro sBZ6GKDXfa4vqk5alFiWoqxW/MUoi6Ngxm2T0OJZy20L6BL5n8sT96rinAbtGzo5 CELu91D6UeFR/rry2bI6DIS7rPN4BHCsSTZ1cXK/wxLHTqaSP50qj2phZ7zGbVA= =IuLJ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 +100. I vote -1 there and would like to point out that we *must* keep history during the split, and split from u/s code base, not random repositories. If you don't know how to achieve this, ask oslo people, they did it plenty of times when graduating libraries from oslo-incubator. /Ihar On 10/12/14 19:18, Cedric OLLIVIER wrote: https://review.openstack.org/#/c/140191/ 2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com mailto:arma...@gmail.com: By the way, if Kyle can do it in his teeny tiny time that he has left after his PTL duties, then anyone can do it! :) https://review.openstack.org/#/c/140191/ Fully cloning Dave Tucker's repository [1] and the outdated fork of the ODL ML2 MechanismDriver included raises some questions (e.g. [2]). I wish the next patch set removes some files. At least it should take the mainstream work into account (e.g. [3]) . [1] https://github.com/dave-tucker/odl-neutron-drivers [2] https://review.openstack.org/#/c/113330/ [3] https://review.openstack.org/#/c/96459/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349 PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM= =dfe/ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Lack of quota - security bug or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/12/14 22:12, Jeremy Stanley wrote: On 2014-12-10 16:07:35 -0500 (-0500), Jay Pipes wrote: On 12/10/2014 04:05 PM, Jeremy Stanley wrote: I think the bigger question is whether the lack of a quota implementation for everything a tenant could ever possibly create is something we should have reported in secret, worked under embargo, backported to supported stable branches, and announced via high-profile security advisories once fixed. Sure, fine. Any tips for how to implement new quota features in a way that the patches won't violate our stable backport policies? If we consider it a security issue worth CVE, then security concerns generally beat stability concerns. We'll obviously need to document the change in default behaviour in release notes though, and maybe provide a documented way to disable the change for stable releases (I suspect we already have a way to disable specific quotas, but we should make sure it's the case and we provide operators commands ready to be executed to achieve this). /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUiXeoAAoJEC5aWaUY1u57i3EIAMZp5XoTfayE2EblAruo+hK+ I4c8EvrhCNOVe51BsI42VFkuqp4vf9nKpHYz/PtSOp/9tLxXgpt0tFgEEOUS2xR9 rIMR0vkJSLWgT6v7aGMR7cDQ1MSGkmjCQl2SgmRgsyG0Jcx1/+El9zUToTI9hTFu Yw97cN04j/pFda7Noo91ck7htq0pSCsLtR2jRVePgcIc6UeW372aaXn8zboTtCks c03VXiZHc5TpZurZiFopT+CLbiDl5k0JvMuptP7YOhnfzzNsaaL/Bd8+9f6SGpol Dy7Ha2CDsAl1WEMx0VvAHvH5O4YRbbE0sIvY1r0pxmMQB8lJwx6KfcDwIrer2Og= =ZY3+ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/12/14 00:05, Mathieu Gagné wrote: We recently had an issue in production where a user had 2 default security groups (for reasons we have yet to identify). This is probably the result of the race condition that is discussed in the thread: https://bugs.launchpad.net/neutron/+bug/1194579 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUitR/AAoJEC5aWaUY1u57VggIALzdTLHnO7Fr8gKlWPS7Uu+o Su9KV41td8Epzs3pNsGYkH2Kz4T5obAneCORUiZl7boBpAJcnMm3Jt9K8YnTCVUy t4AbfIxSrTD7drHf3HoMoNEDrSntdnpTHoGpG+idNpFjc0kjBjm81W3y14Gab0k5 5Mw/jV8mdnB6aRs5Zhari50/04X8SZeDpQNgBHL5kY40CZ+sUtS4C8OKfj7OEAuW LNmkHgDAtwewbNdluntbSdLGVjyl/F9s+21HoajqBcGNhH8ZHpAr4hphMbZv8lBY iAD2tztxvkacYaGduBFh6bewxVNGaUJBWmmc2xqHAXXbDP3d9aOk5q0wHK3SPQY= =TDwc -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [ha] potential issue with implicit async-compatible mysql drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Reading the latest comments at https://github.com/PyMySQL/PyMySQL/issues/275, it seems to me that the issue is not to be solved in drivers themselves but instead in libraries that arrange connections (sqlalchemy/oslo.db), correct? Will the proposed connection reopening help? /Ihar On 05/12/14 23:43, Mike Bayer wrote: Hey list - I’m posting this here just to get some ideas on what might be happening here, as it may or may not have some impact on Openstack if and when we move to MySQL drivers that are async-patchable, like MySQL-connector or PyMySQL. I had a user post this issue a few days ago which I’ve since distilled into test cases for PyMySQL and MySQL-connector separately. It uses gevent, not eventlet, so I’m not really sure if this applies. But there’s plenty of very smart people here so if anyone can shed some light on what is actually happening here, that would help. The program essentially illustrates code that performs several steps upon a connection, however if the greenlet is suddenly killed, the state from the connection, while damaged, is still being allowed to continue on in some way, and what’s super-catastrophic here is that you see a transaction actually being committed *without* all the statements proceeding on it. In my work with MySQL drivers, I’ve noted for years that they are all very, very bad at dealing with concurrency-related issues. The whole “MySQL has gone away” and “commands out of sync” errors are ones that we’ve all just drowned in, and so often these are due to the driver getting mixed up due to concurrent use of a connection. However this one seems more insidious. Though at the same time, the script has some complexity happening (like a simplistic connection pool) and I’m not really sure where the core of the issue lies. The script is at https://gist.github.com/zzzeek/d196fa91c40cb515365e and also below. If you run it for a few seconds, go over to your MySQL command line and run this query: SELECT * FROM table_b WHERE a_id not in (SELECT id FROM table_a) ORDER BY a_id DESC; and what you’ll see is tons of rows in table_b where the “a_id” is zero (because cursor.lastrowid fails), but the *rows are committed*. If you read the segment of code that does this, it should be impossible: connection = pool.get() rowid = execute_sql( connection, INSERT INTO table_a (data) VALUES (%s), (a,) ) gevent.sleep(random.random() * 0.2) try: execute_sql( connection, INSERT INTO table_b (a_id, data) VALUES (%s, %s), (rowid, b,) ) connection.commit() pool.return_conn(connection) except Exception: connection.rollback() pool.return_conn(connection) so if the gevent.sleep() throws a timeout error, somehow we are getting thrown back in there, with the connection in an invalid state, but not invalid enough to commit. If a simple check for “SELECT connection_id()” is added, this query fails and the whole issue is prevented. Additionally, if you put a foreign key constraint on that b_table.a_id, then the issue is prevented, and you see that the constraint violation is happening all over the place within the commit() call. The connection is being used such that its state just started after the gevent.sleep() call. Now, there’s also a very rudimental connection pool here. That is also part of what’s going on. If i try to run without the pool, the whole script just runs out of connections, fast, which suggests that this gevent timeout cleans itself up very, very badly. However, SQLAlchemy’s pool works a lot like this one, so if folks here can tell me if the connection pool is doing something bad, then that’s key, because I need to make a comparable change in SQLAlchemy’s pool. Otherwise I worry our eventlet use could have big problems under high load. # -*- coding: utf-8 -*- import gevent.monkey gevent.monkey.patch_all() import collections import threading import time import random import sys import logging logging.basicConfig() log = logging.getLogger('foo') log.setLevel(logging.DEBUG) #import pymysql as dbapi from mysql import connector as dbapi class SimplePool(object): def __init__(self): self.checkedin = collections.deque([ self._connect() for i in range(50) ]) self.checkout_lock = threading.Lock() self.checkin_lock = threading.Lock() def _connect(self): return dbapi.connect( user=scott, passwd=tiger, host=localhost, db=test) def get(self): with self.checkout_lock: while not self.checkedin: time.sleep(.1) return self.checkedin.pop() def return_conn(self, conn): try: conn.rollback() except: log.error(Exception during rollback, exc_info=True) try: conn.close() except: log.error(Exception during close, exc_info=True) # recycle to a new connection conn = self._connect() with self.checkin_lock: self.checkedin.append(conn) def verify_connection_id(conn): cursor = conn.cursor() try:
[openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - - it will make oslo liaison life a lot easier. OK, I'm probably too selfish on that. ;) - - it will make stable maintainers life a lot easier. The main reason why stable maintainers and distributions like recent oslo graduation movement is that we don't need to track each bug fix we need in every project, and waste lots of cycles on it. Being able to fix a bug in one place only is *highly* anticipated. [OK, I'm quite selfish on that one too.] - - it's a delusion that there will be no neutron-main syncs that will break neutron-*aas repos ever. There can still be problems due to incompatibility between neutron main and neutron-*aas code resulted EXACTLY because multiple parts of the same process use different versions of the same module. That said, Doug Wiegley (lbaas core) seems to be in favour of option 3. due to lower coupling that is achieved in that way. I know that lbaas team had a bad experience due to tight coupling to neutron project in the past, so I appreciate their concerns. All in all, we should come up with some standard solution for both advanced services that are already split out, *and* upcoming vendor plugin shrinking initiative. The initial discussion is captured at: https://review.openstack.org/#/c/141427/ Thanks, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUju0NAAoJEC5aWaUY1u57n5YH/jA4l5DsLgRpw9gYsoSWVGvh apmJ4UlnAKhxzc787XImz1VA+ztSyIwAUdEdcfq3gkinP58q7o48oIXOGjFXaBNq 6qBePC1hflEqZ85Hm4/i5z51qutjW0dyi4y4C6FHgM5NsEkhbh0QIa/u8Hr4F1q6 tkr0kDbCbDkiZ8IX1l74VGWQ3QvCNeJkANUg79BqGq+qIVP3BeOHyWqRmpLZFQ6E QiUwhiYv5l4HekCEQN8PWisJoqnhbTNjvLBnLD82IitLd5vXnsXfSkxKhv9XeOg/ czLUCyr/nJg4aw8Qm0DTjnZxS+BBe5De0Ke4zm2AGePgFYcai8YQPtuOfSJDbXk= =D6Gn -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/12/14 15:15, Ihar Hrachyshka wrote: - it's a delusion that there will be no neutron-main syncs that will break neutron-*aas repos ever. OK, I've just decided to check whether my (non-native speaker) understanding of the meaning of the word 'delusion' is correct, and I need to admit that what I've found out in dictionaries is not what I really meant. :| I only meant that it's a wrong assumption. So in case anyone reads it as any kind of derogation, I'm very sorry for the bad wording. Please blame my bad English. And Richard Dawkins. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUju7sAAoJEC5aWaUY1u57XfIH/ituoB51dLLaLvryFumADvT/ dhkJyzylD/x0j++BS88KdNE9i7aiAFn2MQyvINxYV7THSsgl60YruV6xXj5X72aK EUd967OI77XuIheOP6iIC2ZoGa3ie8RGyMTxbTW5hEeDR8+mtYhQTmDZUWKtT15o jviGV9/kPftVU2U1UirwjpZY3DPee4D9CwIoJdTKvk93+NNNlMh1cAsWIR0ISJBC mm/X020SSl2wOy9d3lUge4QEi698NPYpkAAbAqL6YTkblXOFgfb7EBexGQoV388P TFb2StHyCD7hVpdx6ljLWR2mEQVavIJE9VUkvAzvoBMmlZnYFFx4TnUEu6Vu7VY= =Q+GY -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Do all OpenStack daemons support sd_notify?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/12/14 09:45, Thomas Goirand wrote: Hi, As I am slowing fixing all systemd issues for the daemons of OpenStack in Debian (and hopefully, have this ready before the freeze of Jessie), I was wondering what kind of Type= directive to put on the systemd .service files. I have noticed that in Fedora, there's Type=notify. So my question is: Do all OpenStack daemons, as a rule, support the DBus sd_notify thing? Should I always use Type=notify for systemd .service files? Can this be called a general rule with no exception? (I will talk about neutron only.) I guess Type=notify is supposed to be used with daemons that use Service class from oslo-incubator that provides systemd notification mechanism, or call to systemd.notify_once() otherwise. In terms of Neutron, neutron-server process is doing it, metadata agent also seems to do it, while OVS agent seems to not. So it really should depend on each service and the way it's implemented. You cannot just assume that every Neutron service reports back to systemd. In terms of Fedora, we have Type=notify for neutron-server service only. BTW now that more distributions are interested in shipping unit files for services, should we upstream them and ship the same thing in all interested distributions? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUjvxgAAoJEC5aWaUY1u57N1gH/RsYPqmGpyoZ8fe8CwXcnz+R Rvfo7FHpcEZ9+Idvr9qitoPhKtGjzwgJC27EIQ6NCvgZZT462f+/jYHlxW0dX5Cz Fm9Zg/Hv50ukDOC1nT3nfDKH8uMwuPMrQsfRuXTGKhwqsfgnFfExozydgVeC2XFw WB9B3tBblp+7PRzaGyN9Bpe3gQnHUm3lyXaziK+wLbf7NTROzATlVCZ4xpPWu/5C ArfzwXICp9Dk5Juy75mwYwh37gw26w0VWfvPzn2WjkSVHKymNVn9GRdflVOrV3fq wnhu08e/wup8XF1/eKkWUJyF+hEsN5E0kO2x5CvavvMS3HSTm3Viuhz5tKC6ZAs= =WiBi -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I was (rightfully) asked to share my comments on the matter that I left in gerrit here. See below. On 12/12/14 22:40, Sean Dague wrote: On 12/12/2014 01:05 PM, Maru Newby wrote: On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote: On 12/11/2014 04:16 PM, Jay Pipes wrote: On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote: On Dec 11, 2014, at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote: On Dec 11, 2014, at 8:00 AM, Henry Gessau ges...@cisco.com wrote: On Thu, Dec 11, 2014, Mark McClain m...@mcclain.xyz wrote: On Dec 11, 2014, at 8:43 AM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: I'm generally in favor of making name attributes opaque, utf-8 strings that are entirely user-defined and have no constraints on them. I consider the name to be just a tag that the user places on some resource. It is the resource's ID that is unique. I do realize that Nova takes a different approach to *some* resources, including the security group name. End of the day, it's probably just a personal preference whether names should be unique to a tenant/user or not. Maru had asked me my opinion on whether names should be unique and I answered my personal opinion that no, they should not be, and if Neutron needed to ensure that there was one and only one default security group for a tenant, that a way to accomplish such a thing in a race-free way, without use of SELECT FOR UPDATE, was to use the approach I put into the pastebin on the review above. I agree with Jay. We should not care about how a user names the resource. There other ways to prevent this race and Jay’s suggestion is a good one. However we should open a bug against Horizon because the user experience there is terrible with duplicate security group names. The reason security group names are unique is that the ec2 api supports source rule specifications by tenant_id (user_id in amazon) and name, so not enforcing uniqueness means that invocation in the ec2 api will either fail or be non-deterministic in some way. So we should couple our API evolution to EC2 API then? -jay No I was just pointing out the historical reason for uniqueness, and hopefully encouraging someone to find the best behavior for the ec2 api if we are going to keep the incompatibility there. Also I personally feel the ux is better with unique names, but it is only a slight preference. Sorry for snapping, you made a fair point. Yeh, honestly, I agree with Vish. I do feel that the UX of that constraint is useful. Otherwise you get into having to show people UUIDs in a lot more places. While those are good for consistency, they are kind of terrible to show to people. While there is a good case for the UX of unique names - it also makes orchestration via tools like puppet a heck of a lot simpler - the fact is that most OpenStack resources do not require unique names. That being the case, why would we want security groups to deviate from this convention? Maybe the other ones are the broken ones? Honestly, any sanely usable system makes names unique inside a container. Like files in a directory. Correct. Or take git: it does not use hashes to identify objects, right? In this case the tenant is the container, which makes sense. It is one of many places that OpenStack is not consistent. But I'd rather make things consistent and more usable than consistent and less. Are we only proposing to make security group name unique? I assume that, since that's what we currently have in review. The change would make API *more* inconsistent, not less, since other objects still use uuid for identification. You may say that we should move *all* neutron objects to the new identification system by name. But what's the real benefit? If there are problems in UX (client, horizon, ...), we should fix the view and not data models used. If we decide we want users to avoid using objects with the same names, fine, let's add warnings in UI (probably with an option to disable it so that we don't push the validation into their throats). Finally, I have concern about us changing user visible object attributes like names during db migrations, as it's proposed in the patch discussed here. I think such behaviour can be quite unexpected for some users, if not breaking their workflow and/or scripts. My belief is that responsible upstream does not apply ad-hoc changes to API to fix a race condition that is easily solvable in other ways (see Assaf's proposal to introduce a new DefaultSecurityGroups table in patchset 12 comments). As for the whole object identification scheme change, for this to work, it probably needs a spec and a long discussion on any possible complications (and benefits) when applying a change like that. For reference and convenience of readers, leaving the link to the
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/12/14 18:57, Doug Hellmann wrote: There may be a similar problem managing dependencies on libraries that live outside of either tree. I assume you already decided how to handle that. Are you doing the same thing, and adding the requirements to neutron’s lists? I guess the idea is to keep in neutron-*aas only those oslo-incubator modules that are used there solely (=not used in main repo). I think requirements are a bit easier and should track all direct dependencies in each of the repos, so that in case main repo decides to drop one, neutron-*aas repos are not broken. For requirements, it's different because there is no major burden due to duplicate entries in repos. On Dec 15, 2014, at 12:16 PM, Doug Wiegley do...@a10networks.com wrote: Hi all, Ihar and I discussed this on IRC, and are going forward with option 2 unless someone has a big problem with it. Thanks, Doug On 12/15/14, 8:22 AM, Doug Wiegley do...@a10networks.com wrote: Hi Ihar, I’m actually in favor of option 2, but it implies a few things about your time, and I wanted to chat with you before presuming. Maintenance can not involve breaking changes. At this point, the co-gate will block it. Also, oslo graduation changes will have to be made in the services repos first, and then Neutron. Thanks, doug On 12/15/14, 6:15 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - it will make oslo liaison life a lot easier. OK, I'm probably too selfish on that. ;) - it will make stable maintainers life a lot easier. The main reason why stable maintainers and distributions like recent oslo graduation movement is that we don't need to track each bug fix we need in every project, and waste lots of cycles on it. Being able to fix a bug in one place only is *highly* anticipated. [OK, I'm quite selfish on that one too.] - it's a delusion that there will be no neutron-main syncs that will break neutron-*aas repos ever. There can still be problems due to incompatibility between neutron main and neutron-*aas code resulted EXACTLY because multiple parts of the same process use different versions of the same module. That said, Doug Wiegley (lbaas core) seems to be in favour of option 3. due to lower coupling that is achieved in that way. I know that lbaas team had a bad experience due to tight coupling to neutron project in the past, so I appreciate their concerns. All in all, we should come up with some standard solution for both advanced services that are already split out, *and* upcoming vendor plugin shrinking initiative. The initial discussion is captured at: https
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/12/14 17:22, Doug Wiegley wrote: Hi Ihar, I’m actually in favor of option 2, but it implies a few things about your time, and I wanted to chat with you before presuming. I think split didn't mean moving project trees under separate governance, so I assume oslo (doc, qa, ...) liaisons should not be split either. Maintenance can not involve breaking changes. At this point, the co-gate will block it. Also, oslo graduation changes will have to be made in the services repos first, and then Neutron. Do you mean that a change to oslo-incubator modules is co-gated (not just co-checked with no vote) with each of advanced services? As I pointed in my previous email, sometimes breakages are inescapable. Consider a change to neutron oslo-incubator module used commonly in all repos that breaks API (they are quite rare, but still have a chance of happening once in a while). If we would co-gate main neutron repo changes with services, it will mean that we won't be able to merge the change. That would probably suggest that we go forward with option 3 and manage all incubator files separately in each of the trees, though, again, breakages are still possible in that scenario via introducing incompatibility between versions of incubator modules in separate repos. So we should be realistic about it and plan forward how we deal potential breakages that *may* occur. As for oslo library graduations, the order is not really significant. What is significant is that we drop oslo-incubator module from main neutron repo only after all other neutron-*aas repos migrate to appropriate oslo.* library. The neutron migration itself may occur in parallel (by postponing module drop later). Thanks, doug On 12/15/14, 6:15 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - it will make oslo liaison life a lot easier. OK, I'm probably too selfish on that. ;) - it will make stable maintainers life a lot easier. The main reason why stable maintainers and distributions like recent oslo graduation movement is that we don't need to track each bug fix we need in every project, and waste lots of cycles on it. Being able to fix a bug in one place only is *highly* anticipated. [OK, I'm quite selfish on that one too.] - it's a delusion that there will be no neutron-main syncs that will break neutron-*aas repos ever. There can still be problems due to incompatibility between neutron main and neutron-*aas code resulted EXACTLY because multiple parts of the same process use different versions of the same module. That said, Doug Wiegley (lbaas core) seems to be in favour of option 3. due to lower coupling
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/12/14 12:50, Doug Hellmann wrote: On Dec 16, 2014, at 5:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 15/12/14 18:57, Doug Hellmann wrote: There may be a similar problem managing dependencies on libraries that live outside of either tree. I assume you already decided how to handle that. Are you doing the same thing, and adding the requirements to neutron’s lists? I guess the idea is to keep in neutron-*aas only those oslo-incubator modules that are used there solely (=not used in main repo). How are the *aas packages installed? Are they separate libraries or applications that are installed on top of neutron? Or are their files copied into the neutron namespace? They are separate libraries with their own setup.py, dependencies, tarballs, all that, but they are free to use (public) code from main neutron package. I think requirements are a bit easier and should track all direct dependencies in each of the repos, so that in case main repo decides to drop one, neutron-*aas repos are not broken. For requirements, it's different because there is no major burden due to duplicate entries in repos. On Dec 15, 2014, at 12:16 PM, Doug Wiegley do...@a10networks.com wrote: Hi all, Ihar and I discussed this on IRC, and are going forward with option 2 unless someone has a big problem with it. Thanks, Doug On 12/15/14, 8:22 AM, Doug Wiegley do...@a10networks.com wrote: Hi Ihar, I’m actually in favor of option 2, but it implies a few things about your time, and I wanted to chat with you before presuming. Maintenance can not involve breaking changes. At this point, the co-gate will block it. Also, oslo graduation changes will have to be made in the services repos first, and then Neutron. Thanks, doug On 12/15/14, 6:15 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - it will make oslo liaison life a lot easier. OK, I'm probably too selfish on that. ;) - it will make stable maintainers life a lot easier. The main reason why stable maintainers and distributions like recent oslo graduation movement is that we don't need to track each bug fix we need in every project, and waste lots of cycles on it. Being able to fix a bug in one place only is *highly* anticipated. [OK, I'm quite selfish on that one too.] - it's a delusion that there will be no neutron-main syncs that will break neutron-*aas repos ever. There can still be problems due to incompatibility between neutron main and neutron-*aas code resulted EXACTLY because multiple parts of the same process use different versions of the same
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/12/14 12:52, Doug Hellmann wrote: On Dec 16, 2014, at 5:22 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 15/12/14 17:22, Doug Wiegley wrote: Hi Ihar, I’m actually in favor of option 2, but it implies a few things about your time, and I wanted to chat with you before presuming. I think split didn't mean moving project trees under separate governance, so I assume oslo (doc, qa, ...) liaisons should not be split either. Maintenance can not involve breaking changes. At this point, the co-gate will block it. Also, oslo graduation changes will have to be made in the services repos first, and then Neutron. Do you mean that a change to oslo-incubator modules is co-gated (not just co-checked with no vote) with each of advanced services? As I pointed in my previous email, sometimes breakages are inescapable. Consider a change to neutron oslo-incubator module used commonly in all repos that breaks API (they are quite rare, but still have a chance of happening once in a while). If we would co-gate main neutron repo changes with services, it will mean that we won't be able to merge the change. That would probably suggest that we go forward with option 3 and manage all incubator files separately in each of the trees, though, again, breakages are still possible in that scenario via introducing incompatibility between versions of incubator modules in separate repos. So we should be realistic about it and plan forward how we deal potential breakages that *may* occur. As for oslo library graduations, the order is not really significant. What is significant is that we drop oslo-incubator module from main neutron repo only after all other neutron-*aas repos migrate to appropriate oslo.* library. The neutron migration itself may occur in parallel (by postponing module drop later). Don’t assume that it’s safe to combine the incubated version and library version of a module. We’ve had some examples where the APIs change or global state changes in a way that make the two incompatible. We definitely don’t take any care to ensure that the two copies can be run together. Hm. Does it leave us with option 3 only? In that case, should we care about incompatibilities between different versions of incubator modules running in the same process (one for core code, and another one for a service)? That sounds more like we're not left with safe options. Thanks, doug On 12/15/14, 6:15 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - it will make oslo liaison life a lot easier. OK, I'm probably too selfish
Re: [openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/12/14 13:41, Doug Hellmann wrote: On Dec 16, 2014, at 7:27 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 16/12/14 12:50, Doug Hellmann wrote: On Dec 16, 2014, at 5:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 15/12/14 18:57, Doug Hellmann wrote: There may be a similar problem managing dependencies on libraries that live outside of either tree. I assume you already decided how to handle that. Are you doing the same thing, and adding the requirements to neutron’s lists? I guess the idea is to keep in neutron-*aas only those oslo-incubator modules that are used there solely (=not used in main repo). How are the *aas packages installed? Are they separate libraries or applications that are installed on top of neutron? Or are their files copied into the neutron namespace? They are separate libraries with their own setup.py, dependencies, tarballs, all that, but they are free to use (public) code from main neutron package. OK. If they don’t have copies of all of the incubated modules they use, how are they tested? Is neutron a dependency? Yes, neutron is in their requirements.txt files. I think requirements are a bit easier and should track all direct dependencies in each of the repos, so that in case main repo decides to drop one, neutron-*aas repos are not broken. For requirements, it's different because there is no major burden due to duplicate entries in repos. On Dec 15, 2014, at 12:16 PM, Doug Wiegley do...@a10networks.com wrote: Hi all, Ihar and I discussed this on IRC, and are going forward with option 2 unless someone has a big problem with it. Thanks, Doug On 12/15/14, 8:22 AM, Doug Wiegley do...@a10networks.com wrote: Hi Ihar, I’m actually in favor of option 2, but it implies a few things about your time, and I wanted to chat with you before presuming. Maintenance can not involve breaking changes. At this point, the co-gate will block it. Also, oslo graduation changes will have to be made in the services repos first, and then Neutron. Thanks, doug On 12/15/14, 6:15 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, the question arose recently in one of reviews for neutron-*aas repos to remove all oslo-incubator code from those repos since it's duplicated in neutron main repo. (You can find the link to the review at the end of the email.) Brief hostory: neutron repo was recently split into 4 pieces (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted in each repository keeping their own copy of neutron/openstack/common/... tree (currently unused in all neutron-*aas repos that are still bound to modules from main repo). As a oslo liaison for the project, I wonder what's the best way to manage oslo-incubator files. We have several options: 1. just kill all the neutron/openstack/common/ trees from neutron-*aas repositories and continue using modules from main repo. 2. kill all duplicate modules from neutron-*aas repos and leave only those that are used in those repos but not in main repo. 3. fully duplicate all those modules in each of four repos that use them. I think option 1. is a straw man, since we should be able to introduce new oslo-incubator modules into neutron-*aas repos even if they are not used in main repo. Option 2. is good when it comes to synching non-breaking bug fixes (or security fixes) from oslo-incubator, in that it will require only one sync patch instead of e.g. four. At the same time there may be potential issues when synchronizing updates from oslo-incubator that would break API and hence require changes to each of the modules that use it. Since we don't support atomic merges for multiple projects in gate, we will need to be cautious about those updates, and we will still need to leave neutron-*aas repos broken for some time (though the time may be mitigated with care). Option 3. is vice versa - in theory, you get total decoupling, meaning no oslo-incubator updates in main repo are expected to break neutron-*aas repos, but bug fixing becomes a huge PITA. I would vote for option 2., for two reasons: - most oslo-incubator syncs are non-breaking, and we may effectively apply care to updates that may result in potential breakage (f.e. being able to trigger an integrated run for each of neutron-*aas repos with the main sync patch, if there are any concerns). - it will make oslo liaison life a lot easier. OK, I'm probably too selfish on that. ;) - it will make stable maintainers life a lot easier. The main reason why stable maintainers and distributions like recent oslo graduation movement is that we don't need to track each bug fix we need in every project, and waste lots of cycles on it. Being able to fix a bug in one place only is *highly* anticipated. [OK, I'm quite
Re: [openstack-dev] [Neutron] vm can't get ipv6 address in ra mode:slaac + address mode: slaac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I suspect that's some Red Hat distro, and radvd lacks SELinux context set to allow neutron l3 agent to spawn it. On 18/12/14 15:50, Jerry Zhao wrote: It seems that radvd was not spawned successfully in l3-agent log: Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: Stderr: '/usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec qrouter-6066faaa-0e35-4e7b-8988-7337c493bad7 radvd -C /var/run/neutron/ra/6066faaa-0e35-4e7b-8988-7337c493bad7.radvd.conf -p /var/run/neutron/external/pids/6066faaa-0e35-4e7b-8988-7337c493bad7.pid.radvd (no filter matched)\n' Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent Traceback (most recent call last): Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/common/utils.py, line 341, in call Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent return func(*args, **kwargs) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/l3_agent.py, line 902, in process_router Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent self.root_helper) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/linux/ra.py, line 111, in enable_ipv6_ra Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent _spawn_radvd(router_id, radvd_conf, router_ns, root_helper) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/linux/ra.py, line 95, in _spawn_radvd Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent radvd.enable(callback, True) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/linux/external_process.py, line 77, in enable Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent ip_wrapper.netns.execute(cmd, addl_env=self.cmd_addl_env) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py, line 554, in execute Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent check_exit_code=check_exit_code, extra_ok_codes=extra_ok_codes) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent File /opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py, line 82, in execute Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent raise RuntimeError(m) Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent RuntimeError: Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-6066faaa-0e35-4e7b-8988-7337c493bad7', 'radvd', '-C', '/var/run/neutron/ra/6066faaa-0e35-4e7b-8988-7337c493bad7.radvd.conf', '-p', '/var/run/neutron/external/pids/6066faaa-0e35-4e7b-8988-7337c493bad7.pid.radvd'] Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent Exit code: 99 Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent Stdout: '' Dec 18 11:23:34 ci-overcloud-controller0-oxzkjphwfyw3 neutron-l3-agent: 2014-12-18 11:23:34.611 18015 TRACE neutron.agent.l3_agent Stderr: '/usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec
Re: [openstack-dev] Cross distribution talks on Friday
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/11/14 20:26, Thomas Goirand wrote: On 11/01/2014 11:29 PM, Kashyap Chamarthy wrote: On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. I'll be happy to discuss with Ubuntu people, but not only. I'd like to meet also guys working with RedHat and Gentoo. I'm sure we may have some interesting things to share. OpenStack release management team would also be welcome. If you are interested, please reply to this mail. You might also want to start an etherpad instance with some initial agenda notes and throw the URL here to guage interest. Here's the etherpad: https://etherpad.openstack.org/p/cross_distro_talks On a related note, a bunch of Fedora/RHEL/CentOS/Scientific Linux packagers are planning[1] to meetup at the summit to discuss RDO project packaging aspects, etc. [1] https://etherpad.openstack.org/p/RDO_Meetup_Summit Well, if you guys are only talking about RPM packaging, as I'm doing only Debian stuff [1], I'm only mildly interested. If we're going to talk more about packaging in general, then maybe. On 11/02/2014 01:45 AM, Adam Young wrote: Getting the whole PBR version issues cleared up would be huge. I'm not sure what issue you are talking about, as I believe there's none. This has been discussed for about a year and a half before we finally had the OSLO_PACKAGE_VERSION to play with, when this was designed a few years ago. I'm now very happy about the way PBR does things, and wouldn't like it to change anything. Currently, what I do in Debian is (from the debian/rules file included from openstak-pkg-tools): DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p') VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//') export OSLO_PACKAGE_VERSION=$(VERSION) Note that OSLO_PACKAGE_VERSION is not public. Instead, we should use PBR_VERSION: http://docs.openstack.org/developer/pbr/packagers.html#versioning You may not be familiar with dpkg-parsechangelog, so let me explain. Basically, if my debian/changelog has on top 2014.2~rc2, the debian/rules file will exports 2014.2~rc2 into the OSLO_PACKAGE_VERSION shell variable before doing python setup.py install, and then PBR is smart enough to use that. I am not at all a RedHat packaging specialist, but from the old time when I did some RPM porting from my Debian packages, I believe that in your .spec file, this should translate into something like this: %install export OSLO_PACKAGE_VERSION=%{version} %{__python} setup.py install -O1 --skip-build --root %{buildroot} Then everything should be ok and PBR will become your friend. I hope this helps and that I'm not writing any RPM packaging mistake! :) Cheers, Thomas Goirand (zigo) [1] Here's the list of packages I maintain in Debian (only for OpenStack): https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUlEp/AAoJEC5aWaUY1u57f7cH+wVU4GQ324bfHp01kp8aG1fh wIN6NoXnn9zuxtu1DcU+x+UhkPa9/nW61EPMJlHva+HVtmW4dY5obNSnMSP1l1cY cTgY660nwxZByheGCv97FfzFQnetuNZpJ4E7k05EzrwsyOuW8IBPYyPhaRKj18Je E5wVh6LqMQEYdrz0dWQ2YmuEkHHeOL4aNi/LCmNWP1vc5uaRTuXIIFIOz7dcvm/x tW/s4fAlBBWEsjiat/WYzbKSNyVYcJYXwpPTBaNAMGygRJwRp5gAYBHqgD6FpuEN i36hLQ6+dkDEMg0h3uHMU/UJ4qARhlZmRC/Hj9GMdDD9YGLLsDo/lzllm/iODWs= =TGl4 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 23/12/14 08:17, Thomas Goirand wrote: On 12/19/2014 11:55 PM, Ihar Hrachyshka wrote: Note that OSLO_PACKAGE_VERSION is not public. Well, it used to be public, it has been added and discussed a few years ago because of issues I had with packaging. Instead, we should use PBR_VERSION: http://docs.openstack.org/developer/pbr/packagers.html#versioning I don't mind switching, though it's going to be a slow process (because I'm using OSLO_PACKAGE_VERSION in all packages). Are we at least *sure* that using OSLO_PACKAGE_VERSION is now deprecated? I haven't said anyone should go forward and switch all existing build manifests. ;) I think Doug Hellmann should be able to answer to your question more formally. Adding him to CC. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUmVZYAAoJEC5aWaUY1u57E8UH/1lekBJpSRFQsRCvudG2dIyr lBk+W9ZsfzsOPbdOEf1xtZprU2qz6SwV6zZ6vD/qy7pXoFQe9Z8DP1K2VjPc1JGC G+maz8HWYxCjgc7UL8nKWqh1gIzSvYN0KkNJYBAHmn39bV7EjSnHJ2y7o2vG57bE nJA6DlRw3oDdfagWwZr3E2A1+WDDkoAImkj9XZeYQjzal5EMsHyMrWMWlcMvt3Sg x4SGtxxRmYOkzARpZrtCfrsm5JZAC21mX8aJJdoRVwOwCPUHZi9mG1X821NJdvh6 fLVnpu6dCFTo+oKZyESRoPu6BUZOKGxElV2pp2UrIJJEJ3t3mHrPGKXOde28KPg= =ydXr -END 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] [nova] [all] potential enginefacade adjustment - can everyone live with this?
On 01/23/2015 05:38 PM, Mike Bayer wrote: Doug Hellmann d...@doughellmann.com wrote: We put the new base class for RequestContext in its own library because both the logging and messaging code wanted to influence it's API. Would it make sense to do this database setup there, too? whoa, where’s that? is this an oslo-wide RequestContext class ? that would solve everything b.c. right now every project seems to implement RequestContext themselves. https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L35 Though not every project migrated to it yet. /Ihar __ 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] [stable][neutron] 2014.2.2 exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'd like to ask grant for exception for the following patches: - - https://review.openstack.org/#/c/149818/ (FIPs are messed up and/or not working after L3 HA failover; makes L3 HA feature unusable) - - https://review.openstack.org/152841 (ipv6: router does not advertise dhcp server for stateful subnets, making all compliant dhcp clients to fail to get ipv6 address) Thanks /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0kwwAAoJEC5aWaUY1u57AJsH+wf0B5zNb2nW9H/NpY9LkH21 alO2/ZV3EAZuGQO2rrKgNSwUyypmSuGgfETfWoM860wbQtHvBhfmStFpLbrIRvAg FSCIpetvUTp34lcHiQiELc4dubwWvlgPd/xJuH/vHZ/m7nhMQpND3mrC4S99BViR RX5b3S0NeyF8HV7bIvLiI3iD/ZI+IBR3fsYPy8N26+hY5GUmtVdYH29rsyqofRs1 1nJ2fG8Khoj+cUT4WI4sjshswWa4I3TIRix1zVlJOv0HSKsLmalxOIH0JQYbgiz/ YNvc/1Gd47Oldnedc9AUcpfr2AJv5DkeYKsfVnHNUQImaeAHIp7x3NE/aKf996s= =jts0 -END PGP SIGNATURE- __ 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] django-openstack-auth and stable/icehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2015 12:03 PM, Alan Pevec wrote: Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-openstack-auth==1.1.9 # git sha 2079383 It's because of this: 2015-01-27 19:33:44.152 | Collecting oslo.config=1.4.0 (from python-keystoneclient=0.11.1-python-openstackclient=1.0.1) After that installs 1.6.0, consequent pip runs assume that 1.6.0 is always better than 1.4.0 and disregards version cap, hence does not downgrade the library. Should we finally cap versions for clients so that they don't fetch new library versions? Clients are capped in stable/icehouse requirements but devstack in gate seems to be installing them from git master (note # git sha) So we install python-openstackclient=1.0.1 in Icehouse devstack [1] even though we have 0.5 in requirements/Icehouse [2]. This should be fixed I guess. But that would not be enough since all versions of python-openstackclient don't cap the maximum version of keystoneclient. Anyway, in the end we see that 1.4.0 is installed, so probably pip downgraded it later in the run. It looks suspicious and hacky, but it works. As for git hashes you see in freeze output, they seem to be part of pbr metadata shipped with wheels, I see them even when setting local env with 'tox -e py27 --notest' locally when I'm pretty sure git is not involved. So all in all, I still vote for disabling django_openstack_auth =1.1.9 in gate for Icehouse. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0hctAAoJEC5aWaUY1u573NEH/3e+2c1eXDaYU87qz6ZzX9vw yG/2raO3S+/4UtA2Zb3EQYdTduUHeXnqk3caGZq0hcx3XdmzO01SVueKgQAaJLij 8p6p6WwYDr2h5+DXM2g9dfoRE/mPziwwzoGUw095dUzJBIAOsdUcB/OmyAxiJFD8 dXEiwu988pZ4oJgzbL28YhyMce3TK1dY1EFpfvYxhIYySCcVFv9enQVxaj4y6+dc aCw02TyUpObNFHYSqrIwsXMNuhaQAwlZ7wdc4IAcVbggcDdpDyToJicg80OSB2aN nhdp4Y4BlZt1grx8NgWgUSe/5G+JkzHjm3K3rllxa9l99i1lc9+zNOxD2cj8e5I= =qQHZ -END PGP SIGNATURE- __ 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] [Neutron] XenAPI questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2014 07:43 AM, YAMAMOTO Takashi wrote: hi, good to hear. do you have any estimate when it will be available? will it cover dom0 side of the code found in neutron/plugins/openvswitch/agent/xenapi? We also have rootwrap script just for Xen. It would be great to have an ability to trigger Xen specific neutron based job from gerrit comments for any neutron patch. I undertand why Xen team may not want to run their CI on each neutron patch, but at least there should be a half-automated way to trigger it (either by CI machine tracking the files of interest, or responding to specially crafted gerrit comments). Thanks, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0fkkAAoJEC5aWaUY1u57bM4IAMcIPZ8AtlAhR+Jtqy+TCF9z 5+MJWzduNvvY/4AB2jUbIX3tgO2V0HnKD1EhbPYooz5Wq9dwFdlL+BR2su9dqkO+ 3PtAJf60XK4r24xaWKK0nCnxJGLzupF39UMiS3RzmMJ+fOrhGdPyJNlLIuLH2ye3 VApJ5HZkbxz/F7ikMYHfE8Uh5HN84ehXcDHIEMm1RgX3r5+kQLpuPyl2Y74I+6FR xE4vKjahbkGlXCoFUj4gnWqBk+YunawyAC/9X2uoxx6e8OwYcutn4yODS1JA6bDO oxri6fLaBaYGgnDy96gIHlrsqKH1HBqYZIjIiAwMsFYJo4LmkN5B3MWLU89imiE= =OHz/ -END PGP SIGNATURE- __ 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] django-openstack-auth and stable/icehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2015 11:20 AM, Alan Pevec wrote: Bumping minimal oslo.config version due to the issue in django-openstack-auth seems like a wrong way to do it. Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-openstack-auth==1.1.9 # git sha 2079383 It's because of this: 2015-01-27 19:33:44.152 | Collecting oslo.config=1.4.0 (from python-keystoneclient=0.11.1-python-openstackclient=1.0.1) After that installs 1.6.0, consequent pip runs assume that 1.6.0 is always better than 1.4.0 and disregards version cap, hence does not downgrade the library. Should we finally cap versions for clients so that they don't fetch new library versions? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0fpHAAoJEC5aWaUY1u57AwUIAJdW7ZBrknVyaAn0VIkty180 r49gYGEWaQCF7nMVzcnWKrs6aG3VOEJpyipAujzk0A2rF/gD9Bn9iHk2/hyjF/sZ iDmokiDuFPAB8pIpYdMNyYyKKMgCGoInyHW1PAbCIsj24qiFIzSQMbojvt8Bsgks 68gQk5CYXmi0gF6OiPUHEqj73vpPjXLNZHd2V/P87MAvsTiGRXXFWncT0F1cl5oJ i47uVOyhBK9zfZgDFfL/jPq35Ij71t9BXUQxdgxXavYbGjsnC+YEcOeAacUS4kBk hDliIq+HGPGK0eEgLe4BwHxrd5Skh60h0TPsx+BbVo8A0mydxee7XgUxEG2P2Fs= =sy8K -END PGP SIGNATURE- __ 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] [neutron] IPv6 Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2015 09:14 AM, Andreas Scheuring wrote: Hi, is there a central place where I can find a matrix (or something similar) that shows what is currently supposed to work in the sense of IPv6 Networking? I also had a look at a couple of blueprints out there, but I'm looking for a simple overview containing what's supported, on which features are people working on and what's future. I mean all the good stuff for Tenant Networks like - SNAT - FloatingIP - External Provider Networks - DVR - fwaas, vpnaas,... and also about the Host Network - e.g. vxlan/gre tunneling via ipv6 host network... AFAIK it's not supported by OVS yet. The last time I talked to a guy who worked on the feature, he told me that it will take some time, and it will probably be VXLAN only. (Unless someone steps in.) /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU00gmAAoJEC5aWaUY1u57OZEH/ia2vXIVJDRgBtbGzp7O6dyl fXhrLgitod0S7k6h7/ocacXkutQJ4qF8ab01Ry19YmbYB1xfE7ExSmt/Js9/rqn1 PANaDCvBe9iSEvgj/s/kmAwJNRRILvtZ8ZjFsGr1VGebJQmyqNvmZtRrljX7rfDl o6j7grBINc+iY9sck/f9OW8wA6nzWT1nwKJksExT6pIZ/9MkeddRn/L/ALDRC0qD 6erLS/1GyG+1ByEzFApBXvtqhF8JVkUVrePm9PDWDWMnLb6db0v9J61E/KWqy+IQ jzPnOmUlj3u3J5zFLalt6PKq2T9+58y+MziCwi9Oq8LygQWBXqeQTITmWpqD+OU= =pwN5 -END PGP SIGNATURE- __ 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] django-openstack-auth and stable/icehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2015 08:18 PM, Ryan Hsu wrote: Hi All, There was a change [1] 2 days ago in django-openstack-auth that introduces a new requirement oslo.config=1.6.0 to the project, which is now present in the 1.1.9 release of django-openstack-auth. While this change is in sync with master requirements, oslo.config=1.6.0, it does not jive with stable/icehouse requirements which is =1.2.0,1.5. Because stable/icehouse horizon does not have an upper-bound version requirement for django-openstack-auth, it currently takes this 1.1.9 release of django-openstack-auth with the conflicting oslo.config requirement. I have a bug open for this situation here [2]. My first thought was to create a patch [3] to cap the django-openstack-auth version in stable/icehouse requirements, however, a reviewer pointed out that django-openstack-auth 1.1.8 has a security fix that would be desired. My other thought was to decrease the minimum required version in django-openstack-auth to equal that of stable/icehouse requirements but this would then conflict with master requirements. Does anyone have thoughts on how to best resolve this? I personally don't believe we should be responsible for fetching all security fixes in external libraries that don't maintain stable branches and hence just break their consumers. In ideal world, django-openstack-auth would have a stable branch where the security fix would be backported. But since the library does not follow best practices, I think we should just cap it at whatever version is compatible with other requirements, and allow deployers to locally patch their django-openstack-auth with security fixes. Bumping minimal oslo.config version due to the issue in django-openstack-auth seems like a wrong way to do it. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0KiPAAoJEC5aWaUY1u57uE0IAMrK8iupadmoE7c9gkO6otK/ JiccHV/O0Ov7pZY16NG20G8lkzapE2MWx4X3IYdc5Dxc4N7fBqUUpSwmEmWWbf5K NWrUYGkWQc7jvScsEg0Xb2qChQjrI0DupRZcfzm19ymqqO325WuEcoLU13YVigFT sin4BGwd6xk5G4dzRagXfo6sxGWdjd6/px7TEHeevTQ0sPH4mbyNgNn05qUqB69z +wQN2tZ2hecoY1ouxa3ThOcS+iiiyvGtiA3b9+QRFgp4vdgmV8SwPUE8bb5MvEen Gkei1K1zH6YI1Dgw9YWKeZuURUAnpTCfGwcP8cqGdOUDGDHtoD/aci9HWk8Y4UQ= =UAk1 -END PGP SIGNATURE- __ 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] [neutron][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?
On 01/20/2015 05:40 PM, Paul Michali wrote: Review https://review.openstack.org/#/c/146508/ is adding support for StrongSwan VPN, which needs mount bind to be able to specify different paths for config files. The code, which used some older patch, does a test for /proc/1/ns/net, instead of /proc/1/ns/mnt, because it stated that the latter is only supported in kernel 3.8+. That was a while ago, and I'm wondering if the condition is still true. If we know that for Kilo and on, we'll be dealing with 3.8+ kernels, we could use the more accurate test. Can we require 3.8+ kernel for this? I think we can but it's better to check with distributions. Red Hat wise, we ship a kernel that is newer than 3.8. If so, how and where do we ensure that is true? Ideally, you would implement a sanity check for the feature you need from the kernel. Though it opens a question of whether we want to ship multiple sanity check tools for each of repos (neutron + 3 *aas repos). Also, if you can kindly review the code here: https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py, I'd really appreciate it, as I'm not versed in the Linux proc files at all. Thanks! PCM (Paul Michali) IRC pc_m (irc.freenode.com http://irc.freenode.com) Twitter... @pmichali __ 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
[openstack-dev] [stable][neutron] backports vs. vendor decomposition
Hi all, as per: https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst, neutron is going to spin off vendor plugins into separate trees outside of neutron core team control. This raises several questions on how we are going to handle stable branches that will still include plugin code for several cycles. 1) If a plugin is already spinned off and a patch is applicable for stable branches, there are two cases: - patch is not merged into vendor repo; - patch is merged into the vendor repo. My take is: - if it's merged in the vendor repo, then we just cherry-pick from there (it should just work if vendor repo was created with the whole master history saved). - if it's not merged into the repo, I would recommend the author to propose and merge it there first. If there are any justifiable issues with proposing it for vendor repo inclusion, then we can consider stable-only merge. 2) If a plugin is in the middle of spinning off and a patch is applicable for stable branch, then there are two options: - require plugin to spin off first and then apply the patch to vendor repo, or - allow some types of patches to be merged into master while vendors are working on spinning off the code. Examples of those patches are: - https://review.openstack.org/#/c/147976/ - https://review.openstack.org/#/c/148369/ Currently the patches above are blocked for master inclusion assuming the spin off must take place first, and then bugs should be fixed in vendor repo. At the same time, we usually avoid backports unless the code is not in master anymore, but that's not the case here. So the current approach effectively blocks any bug fixes for plugins in stable branches. If we would be sure that a plugin is out of the tree till Kilo, then it would indeed be a waste of time to review the code for neutron/master since it would be guaranteed to be released as a separate packagr e anyway. In that case, it would be ok to forbid any patches for the plugin code till its spin off from master, and the patch would go directly to stable branches. That said, it would potentially introduce regressions if we consider upgrades from Juno to Kilo + vendor repo. We may say that since the regression would be on vendor plugin side, and neutron team does not have anything to do with spinned off plugins, that would be fine for us. But: we cannot guarantee that a plugin wil leave the neutron tree this cycle. The spec explicitly gives permission to stay in the tree till L-cycle, and in that case it will be our responsibility to handle regressions in Kilo that we may introduce by blocking master fixes. I think we should try to set procedure that would avoid potential regressions even if they will come from vendor repos. We allow fixes that are not applicable for final releases for master if it's to be backported in stable branches. F.e. see https://review.openstack.org/#/c/127633/ that was merged into master while pecan migration should make it useless for Kilo. It's my belief plugin code bug fixes in stable branches should be treated the same way. That said, we should expect vendors to run third party CI for stable branches if they want to see backports merged in. *** I think the correct approach here is: - once a plugin is spinned off, consider it is a 'master' for the code, and backport to stable branches directly from there; - before a plugin is spinned off, assume that it's not going to be spinned off in Kilo, and hence allow bug fixes in neutron/master (but not new features); - once we get to L release that requires all vendor plugin to go out, forbid any fixes for the code, assuming they will either spin off or will be dropped anyway. *** The approach is pretty similar to how oslo project handles new library spin-offs from oslo-incubator. Yes, there is a difference here: in neutron, we loose any control on spinned off repos. Though I don't feel it justifies stable-only fixes while we can easily add value to vendor code by asking people to consider fixing the bug there first. More importantly, nothing should justify blocking bug fixing for stable branches. Thoughts? /Ihar __ 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] [neutron][oslo] plan till end-of-Kilo
Hi Kyle/all, (we were going to walk thru that on Mon, but since US is on vacation today, sending it via email to openstack-dev@.) So I've talked to Doug Hellmann from oslo, and here is what we have in our oslo queue to consider: 1. minor oslo.concurrency cleanup for *aas repos (we need to drop lockutils-wrapper usage now that base test class sets lockutils fixture); 2. migration to namespace-less oslo libraries (this is blocked by pending oslo.messaging release scheduled this week, will revive patches for all four branches the end of the week) [1]; 3. oslo/kilo-2: graduation of oslo.policy; 4. oslo/kilo-3: graduation of oslo.cache, oslo.versionedobjects. I believe 1. and 2. should be handled in Kilo-2 neutron side. The 2. part will introduce some potential friction in gate due to merge conflicts and new hacking rule applied, so we may want to synchronize it with other refactoring activities. For 3., I'm not sure we want to go with such a change this cycle. On the other side, while that is potentially unsafe, it may free us from later patching our local policy module copy due to security issues that could be revealed later in the incubator module. Taking into account that we claim support for 15 months for all stable branches, and who knows where it will lead later, earlier reducing our area of responsibility can be a good thing. For 4., this will definitely need to wait for L. The oslo.cache migration can easily go with in L-1 (the module is used in single place only - metadata agent); as for oslo.versionedobjects, this will need to follow a proper spec process (we had someone willing to post a spec for that, but I don't remember his/her name). Does the plan sound ok? [1]: https://review.openstack.org/#/q/If0dce29a0980206ace9866112be529436194d47e,n,z /Ihar __ 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] [Openstack] Openstack Havana installation using devstack
On 01/15/2015 01:42 PM, Sean Dague wrote: The stable/havana branch of devstack was deleted when the stable/havana branches of the projects were end of lifed. That said, tag is still there: http://git.openstack.org/cgit/openstack-dev/devstack/tag/?id=havana-eol __ 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] [stable][neutron] backports vs. vendor decomposition
There is a proposal from Armando to clear this up: https://review.openstack.org/#/c/148745/ On 01/22/2015 03:53 PM, Sukhdev Kapur wrote: Hi Ihar, I have added this on the agenda for next neutron core meeting to discuss. This email gives an excellent context to the issue at hand. Only one thing I would like to add is that the deadline for stable/juno is only one week away - hence, it raises the urgency to call for action. Thanks -Sukhdev On Jan 21, 2015 1:43 PM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, as per: https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst, neutron is going to spin off vendor plugins into separate trees outside of neutron core team control. This raises several questions on how we are going to handle stable branches that will still include plugin code for several cycles. 1) If a plugin is already spinned off and a patch is applicable for stable branches, there are two cases: - patch is not merged into vendor repo; - patch is merged into the vendor repo. My take is: - if it's merged in the vendor repo, then we just cherry-pick from there (it should just work if vendor repo was created with the whole master history saved). - if it's not merged into the repo, I would recommend the author to propose and merge it there first. If there are any justifiable issues with proposing it for vendor repo inclusion, then we can consider stable-only merge. 2) If a plugin is in the middle of spinning off and a patch is applicable for stable branch, then there are two options: - require plugin to spin off first and then apply the patch to vendor repo, or - allow some types of patches to be merged into master while vendors are working on spinning off the code. Examples of those patches are: - https://review.openstack.org/#/c/147976/ - https://review.openstack.org/#/c/148369/ Currently the patches above are blocked for master inclusion assuming the spin off must take place first, and then bugs should be fixed in vendor repo. At the same time, we usually avoid backports unless the code is not in master anymore, but that's not the case here. So the current approach effectively blocks any bug fixes for plugins in stable branches. If we would be sure that a plugin is out of the tree till Kilo, then it would indeed be a waste of time to review the code for neutron/master since it would be guaranteed to be released as a separate packagr e anyway. In that case, it would be ok to forbid any patches for the plugin code till its spin off from master, and the patch would go directly to stable branches. That said, it would potentially introduce regressions if we consider upgrades from Juno to Kilo + vendor repo. We may say that since the regression would be on vendor plugin side, and neutron team does not have anything to do with spinned off plugins, that would be fine for us. But: we cannot guarantee that a plugin wil leave the neutron tree this cycle. The spec explicitly gives permission to stay in the tree till L-cycle, and in that case it will be our responsibility to handle regressions in Kilo that we may introduce by blocking master fixes. I think we should try to set procedure that would avoid potential regressions even if they will come from vendor repos. We allow fixes that are not applicable for final releases for master if it's to be backported in stable branches. F.e. see https://review.openstack.org/#/c/127633/ that was merged into master while pecan migration should make it useless for Kilo. It's my belief plugin code bug fixes in stable branches should be treated the same way. That said, we should expect vendors to run third party CI for stable branches if they want to see backports merged in. *** I think the correct approach here is: - once a plugin is spinned off, consider it is a 'master' for the code, and backport to stable branches directly from there; - before a plugin is spinned off, assume that it's not going to be spinned off in Kilo, and hence allow bug fixes in neutron/master (but not new features); - once we get to L release that requires all vendor plugin to go out, forbid any fixes for the code, assuming they will either spin off or will be dropped anyway. *** The approach is pretty similar to how oslo project handles new library spin-offs from oslo-incubator. Yes, there is a difference here: in neutron, we loose any control on spinned off repos. Though I don't feel it justifies stable-only fixes while we can easily add value to vendor code by asking people to consider fixing the bug there first. More importantly, nothing should justify blocking bug fixing for stable branches. Thoughts? /Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ
[openstack-dev] [infra] Re: [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found
Hi all, Any updates from infra on why it occurs? It's still one of the issues that make periodic stable jobs fail. We also have other failures due to missing packages on nodes. F.e., keystone python-ldap installation failing due to missing devel files for openldap: http://logs.openstack.org/periodic-stableperiodicx-keystone-docs-icehouse/30c89e8/console.html http://logs.openstack.org/periodic-stableperiodic-keystone-python27-icehouse/2a77792/console.html /Ihar On 01/19/2015 09:17 AM, Alan Pevec wrote: - periodic-nova-docs-icehouse http://logs.openstack.org/periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ : FAILURE in 1m 15s Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161 which is marked as Fix released, could infra team check if all images are alright? This showed up in 3 periodic icehouse jobs over weekend, all on bare-precise-hpcloud-b2 nodes, I've listed them in https://etherpad.openstack.org/p/stable-tracker Cheers, Alan __ 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] [neutron] Question on functional tests
Unit tests should run successfully in a very limited environment, with no sudo, namespaces etc. Some packagers even run unit tests as part of their build process in hardened environment (I know Debian does, and some teams from Red Hat consider it too, like Neutron). So if it really needs to interact with outside world like that, please implement it in functional test namespace. On 01/20/2015 09:02 PM, Kevin Benton wrote: I don't believe we have any unit tests that create namespaces or veth pairs. This sounds like it belongs with functional tests. On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique numan.siddi...@enovance.com mailto:numan.siddi...@enovance.com wrote: Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function (OpenSwanProcess._get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ 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] Use of egg snapshots of neutron code in neutron-*aas projects/distributing openstack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/16/2015 04:13 PM, James Page wrote: Hi Folks The split-out drivers for vpn/fw/lb as-a-service all make use of a generated egg of the neutron git repository as part of their unit test suite dependencies. This presents a bit of a challenge for us downstream in distributions, I am packaging neutron for RDO, but I fail to understand your issue. as we can't really pull in a full source egg of neutron from git.openstack.org; we have the code base for neutron core available (python-neutron), but that does not appear to be enough (see [0]). Don't you ship egg files with python-neutron package? I think this should be enough to get access to entry points. I would appreciate if dev's working in this area could a) review the bug and the problems we are seeing a b) think about how this can work for distributions - I'm happy to create a new 'neutron-testing' type package from the neutron codebase to support this stuff, but right now I'm a bit unclear on exactly what its needs to contain! Cheers James [0] https://bugs.launchpad.net/neutron/+bug/1422376 __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU4hLIAAoJEC5aWaUY1u57+QEH/1ZaBmuEpIHiW1/67Lh452PU o2dXy3fy23fns/9GUHbXn6ASRPi5usEqe4Qa+Z0jaVnipIQcdjvGZg8RET2KQsyo RsmLJlOJHA2USJP62PvbkgZ5bmIlFSIi0vgNs75904tGp+UqGkpW4VZ/KTYyzVL2 kpBaMfJxHdjmEnPAdfk14u5kHkblavGqQO7plmjCRncFkUy63m/qWQ2zjQbpUxCZ wZJ1FTNqA16mo4ThFzdn/br5Mqeopfkcwht7EQV/cCYz6b9Y0oU4qXmL5qy/k8Xz yyU9hLagPrffLf0hJWdf3Zt0K3FqYDND1GJRvjgGvKSri4ylRt1zG07RG1ZdiWg= =QffD -END PGP SIGNATURE- __ 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] [neutron] monkey patching strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, there were some moves recently to make monkey patching strategy sane in neutron. This was triggered by some bugs found when interacting with external oslo libraries [1], and a cross project spec to make eventlet usage sane throughout the project [2]. Specifically, instead of monkey patching stdlib in each of services and agents (and forgetting to do so for some of them [3]), we should monkey patch it as part of a common import (ideally, it would be any neutron.* import). Initially, we've tried to patch it inside neutron/__init__.py [4], but it didn't place nice with some advanced services importing from neutron while not expecting stdlib to be patched, and so was reverted. So an alternative that I currently look into is the Nova way. Specifically, moving all main() functions for all agents and services into neutron/cmd/... and monkey patching stdlib thru neutron/cmd/__init__.py. I've sent a series of patches to do just that [5]. It was rightfully blocked by Mark to seek for broader agreement. I encourage community to say your word on the direction. [1]: https://bugs.launchpad.net/oslo.concurrency/+bug/1418541 [2]: https://review.openstack.org/154642 [3]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/mlnx/agent/eswitch_neutron_agent.py [4]: https://review.openstack.org/153699 [5]: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1418541,n,z Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU3P4QAAoJEC5aWaUY1u57A/cH/AuKbkewZy5Z0Hus2m4bClGp 4DJ37ygcY9HwGmJTLpvUyfRcDWnaO9S+6sj28Ebv49MN1w9qJ4MuQmaYA1xsFERb aR6uKgnkiIT0FS8CVjbClEC7gN5elHCe2dcB8cakrk7uUsTJ2LP5A6rdNQqly/uN 2hkdfa1WBcAYMX6raFWD8DJ49R1MhbPr09YXXU9ApoflMY6ZywvNBzwIZEw5gqPO Vpjb9DwevaFZ9kqzjHTrXk47CqOSYS7ZXQjS1bOGUOJFOBqNRLzl2qPX7wkBiA2N 12U4Qe3/3MvWwBig0O+mY2RwN2OtnxhK8X5tP6kbrybyOKLGUe4ZgIlvfQHI33Q= =8pX5 -END PGP SIGNATURE- __ 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] [neutron] monkey patching strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2015 04:19 PM, Salvatore Orlando wrote: My opinions inline. On 17 February 2015 at 16:04, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi, response was huge so far :) so to add more traction, I have a question for everyone. Let's assume we want to move entry points for all services and agents into neutron/cmd/... If so, I don't have anything again this assumption. Also it seems other projects are already doing it this way so there is no divergence issue here. - Do we want all existing tools stored in the path to be monkey patched too? I would say 'yes', to make sure we run our unit tests in the same environment as in real life; I say yes but mildly here. If you're referring to the tools used for running flake8 or unit tests in theory it should not really matter whether they're patched or not. However, I'm aware of unit tests which spawn eventlet threadpools, so it's definitely better to ensure all these tools are patched. No, I mean ovs_cleanup, sanity_check, usage_audit that are located in the neutron/cmd path but not patched. - Which parts of services we want to see there? Should they include any real main() or register_options() code, or should they be just a wrappers to call actual main() located somewhere in other parts of the tree? I lean toward leaving just a one liner main() under neutron/cmd/... that calls to 'real' main() located in a different place in the tree. My vote is for the one-liner. Comments? /Ihar On 02/13/2015 04:37 PM, Ihar Hrachyshka wrote: On 02/13/2015 02:33 AM, Kevin Benton wrote: Why did the services fail with the stdlib patched? Are they incompatible with eventlet? It's not like *service entry points* are not ready for neutron.* to be monkey patched, but tools around it (flake8 that imports neutron.hacking.checks, setuptools that import hooks from neutron.hooks etc). It's also my belief that base library should not be monkey patched not to put additional assumptions onto consumers. (Though I believe that all the code in the tree should be monkey patched, including those agents that currently run without the library patched - for consistency and to reflect the same test environment for unit tests that will be patched from neutron/tests/__init__.py). /Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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://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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU429PAAoJEC5aWaUY1u57IkcH/1HCRHYzeXfWE3I3ZamAJufI /1/CPcrzW3w3pJebfSLXDNbdv9ziQXwZogcM7JcDMeeYfWA42OexhFQJqerkoJnr oL3eqUOgh19pgVUgAah1n7yQEHxyzbnVR0TcdVOvMlxno8I3hUXy78WvBWQPYIpr NRDSbT+SiQv/OP6/zTkKLkk2SA88lJlKQpGg5Q0iRQTnqiNtF3REBdUTM/32aJyh h9ZxmR8wyrXJv6oEUfGj210vJHUvmPHk3SsH2udQjCG0MdbIQTIZJwgzMVxD4aIs 3uQ9ONqn8Fd2LKzfawHVwT0azd6kCkQjEalZx9Tn/58NPuQ4WERhHcCzBT8pNyI= =DGy3 -END PGP SIGNATURE- __ 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] [neutron] monkey patching strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, response was huge so far :) so to add more traction, I have a question for everyone. Let's assume we want to move entry points for all services and agents into neutron/cmd/... If so, - - Do we want all existing tools stored in the path to be monkey patched too? I would say 'yes', to make sure we run our unit tests in the same environment as in real life; - - Which parts of services we want to see there? Should they include any real main() or register_options() code, or should they be just a wrappers to call actual main() located somewhere in other parts of the tree? I lean toward leaving just a one liner main() under neutron/cmd/... that calls to 'real' main() located in a different place in the tree. Comments? /Ihar On 02/13/2015 04:37 PM, Ihar Hrachyshka wrote: On 02/13/2015 02:33 AM, Kevin Benton wrote: Why did the services fail with the stdlib patched? Are they incompatible with eventlet? It's not like *service entry points* are not ready for neutron.* to be monkey patched, but tools around it (flake8 that imports neutron.hacking.checks, setuptools that import hooks from neutron.hooks etc). It's also my belief that base library should not be monkey patched not to put additional assumptions onto consumers. (Though I believe that all the code in the tree should be monkey patched, including those agents that currently run without the library patched - for consistency and to reflect the same test environment for unit tests that will be patched from neutron/tests/__init__.py). /Ihar __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU41iWAAoJEC5aWaUY1u57zBYIAIuobIYMZ1NJmm+7sV+NW6LS ZS4PNKlwcYRrdfArGliUq7GLVi/ZRNPNgilF9RIJXQAiOXEc6PmKqpKw1JnwkQ7v l3/NeciYmkMhSNRv1vIrOBHegAYx9Js6o2lOBCF7BFKIpu88OsC95oobcLGtcrYU BxoBUM7DYvHssDhRp3NujNbyMrRkg4roer7+4qGE3a449tv4xViTcoUWg5MoNalY vD1ld/Gg8LfKPt7v7FbF2YnHkMG+UJSk47rRd0yv9KGABS69TkNuvJXeJ14sgw0O YqIY3oMO0nza+T8tdQGTrYv9N4rWOMFsJMyrOLIvoUyq526QQZ/K7Hrijj1IQjE= =ZtVP -END PGP SIGNATURE- __ 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] [neutron][neutron-*aas] Is lockutils-wrapper needed for tox.ini commands?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/2015 11:13 PM, Paul Michali wrote: I see that in tox.ini, several commands have lockutils-wrapper prefix on them in the neutron-vpnaas repo. Seems like this was added as part of commit 88e2d801 for Migration to oslo.concurrency. Those would be interesting for unit tests only. And now that neutron BaseTestCase uses proper fixture [1], we can just remove the wrapper call from all *aas repos. That was actually one of the things I was going to do as a oslo liaison during Kilo [2] (see the 1st entry in the todo list.) But if you want to go with this before I reach this cleanup, I will be glad to review the changes. :) [1]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n89 [2]: http://lists.openstack.org/pipermail/openstack-dev/2015-January/054753.html /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU4e21AAoJEC5aWaUY1u57zKcH/iZ3SFi3BmyYaEwch5jipbzw Byxn2QxyjRNcQ6m/dr6ihpvXS2bIo75mrNajc+mdnKTqAdXebceSQRPAw4EX3c9r qtlaGzSrBqmSiyl/YnbqUiUf2zcXpFIpiTJswbdhv10P5Gi/Q64m6d+ipQsIUaMP 4sY/0sjAV5Gn9cpkBZn9LY1/CrWnP7eqFMBYvFTsyEpGHdgJ4heAx2dLCqY2DE9H bVFexZK1yMqLzEIwmHtzSyifcFZkC39fa6bsxCVlLkbfU7+KC56FOOHARsjf+grd ReQuGH4QIS0aTMkrd7qmJRkaK7BudkX1yfOY68jsYSwrpKoia7pMZ+tbPosfUbk= =+HKf -END PGP SIGNATURE- __ 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] [Devstack] Devstack Install broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2015 12:02 PM, Eduard Matei wrote: Hi, I'm trying to install devstack and it keeps failing with: 2015-02-20 07:26:12.693 | ++ is_fedora 2015-02-20 07:26:12.693 | ++ [[ -z Ubuntu ]] 2015-02-20 07:26:12.693 | ++ '[' Ubuntu = Fedora ']' 2015-02-20 07:26:12.693 | ++ '[' Ubuntu = 'Red Hat' ']' 2015-02-20 07:26:12.693 | ++ '[' Ubuntu = CentOS ']' 2015-02-20 07:26:12.693 | ++ '[' Ubuntu = OracleServer ']' 2015-02-20 07:26:12.693 | + [[ -d /var/cache/pip ]] 2015-02-20 07:26:12.693 | + [[ ! -d /opt/stack/.wheelhouse ]] 2015-02-20 07:26:12.693 | + source tools/build_wheels.sh 2015-02-20 07:26:12.693 | /opt/devstack/stack.sh: line 688: tools/build_wheels.sh: No such file or directory 2015-02-20 07:26:12.693 | ++ exit_trap 2015-02-20 07:26:12.693 | ++ local r=1 2015-02-20 07:26:12.693 | +++ jobs -p 2015-02-20 07:26:12.693 | ++ jobs= 2015-02-20 07:26:12.693 | ++ [[ -n '' ]] 2015-02-20 07:26:12.694 | ++ kill_spinner 2015-02-20 07:26:12.694 | ++ '[' '!' -z '' ']' 2015-02-20 07:26:12.694 | ++ [[ 1 -ne 0 ]] 2015-02-20 07:26:12.694 | ++ echo 'Error on exit' 2015-02-20 07:26:12.694 | Error on exit 2015-02-20 07:26:12.694 | ++ [[ -z /opt/stack/logs ]] 2015-02-20 07:26:12.694 | ++ /opt/devstack/tools/worlddump.py -d /opt/stack/logs 2015-02-20 07:26:12.767 | ++ exit 1 Any ideas how to get around this? build_wheels.sh script is included into devstack as of Idff1ea69a5ca12ba56098e664dbf6924fe6a2e47. Do you have the commit in your checkout? Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com http://www.cloudfounders.com/ | eduard.ma...@cloudfounders.com mailto:eduard.ma...@cloudfounders.com __ __ __ __ *CloudFounders, The Private Cloud Software Company* __ __ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. Please avoid sending those disclaimers to public mailing lists. ^^ /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5xZTAAoJEC5aWaUY1u57lfIH/0u7daEg9PotXku0k1UctExq JKQOXSLGWE+pdmB9kvxMCUuaMe6ABNCkVpJB+qn1RP5gL4sQnB3+KyoYn10iM1Ck EKZuPuXk6CzVRlyIavUxBBkQcApjyHTJgNCTePTYkSHVGNGf/Lm+d1UjiGdVLEm+ kG7sU5xvby3oUAdGNcZcqSY77IqJE9slBqBpwYcaOwoegnUI4zlS2NKU5Eda+kAk +jw6pFogyFNoF09f1FnSjwP26zCsAI2cvukrs65gfRGYFtIBnExp+WoqcEiyMTrh xfJsu1rr6TPsSCbhWC0ronphYStheuUFTGsHIv2SJYAzYwkN8W+M/1WIqffsKbo= =q8TL -END PGP SIGNATURE- __ 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] The root-cause for IRC private channels (was Re: [all][tc] Lets keep our community open, lets fight for it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 05:07 PM, Michael Krotscheck wrote: You got my intention right: I wanted to understand better what lead some people to create a private channel, what were their needs. I'm in a passworded channel, where the majority of members work on OpenStack, but whose common denominator is We're in the same organizational unit in HP. We talk about openstack, we talk about HP, we talk about burning man, we talk about movies, good places to drink - it's a nice little backchannel of idle chatter. There have been a few times when things related to OpenStack came up, and in that case we've booted the topic to a public channel (There was an example just yesterday). Either way, in this case a private channel was created because we could potentially be discussing corporate things, it's more analogous to your Teams' internal Hipchat or IRC server (in fact, it started in HipChat, and then we were all 'why do we have to use another chat client' and that ended that). So there's one use case. Michael I think the use case is very valid. I think most (all?) companies have internal channels. That said, those should be concerned about downstream only work and burning men. If an upstream topic arises, people should have discipline to move discussion to upstream channels. AFAIK that's what we try to do in Red Hat, and I guess it's a valid approach that helps both a company in question to get attention to issues downstream teams are interested in, and the community. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5Lp+AAoJEC5aWaUY1u57xDAIAJisbHHDsm1CAAWpi+eb+Bsg /QeVotuBDj1dNsSeIHU42/eI7S36Rlwfv8700YQcomwQPNTgXhiQU0y6F3anC62c rg1nXGpmSY0JFg9VaKzwZGfhN0tAMLK/IdgqSooyJwBGGGnasZCYcVQrcNyPgCjY q7vHd+1d1QEaYeJbO/CQNN9cjjVtjkclXg8DBU+yL6M1i+z60aPExEVE/b9VnrTB VfttbOi1WH6tm5bkBR4tmsGGy8UsVZ/VEEgcLOCryIy0kuJYAJ6i61Fs+AcSySyr lEPJCNTjn4t73DkGBD5NIM78wxorJ9nvNTxGyb3VdDYwnkWMpjloBTv9/DBSSCU= =fxQR -END PGP SIGNATURE- __ 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] [Neutron] per-agent/driver/plugin requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 08:14 AM, YAMAMOTO Takashi wrote: hi, On Wednesday, 18 de February de 2015 at 07:00, yamam...@valinux.co.jp wrote: hi, i want to add an extra requirement specific to OVS-agent. (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1] but the question is not specific to the blueprint.) to avoid messing deployments without OVS-agent, such a requirement should be per-agent/driver/plugin/etc. however, there currently seems no standard mechanism for such a requirement. Awesome, I was thinking of the same a few days ago, we make lots and lots of calls to ovs-ofctl, and we will do more if we change to security groups/routers in OF, if that proves to be efficient, and we get CT. CT? After this change, what would be the differences of ofagent to ovs-agent ? I guess OVS set’s rules in advance, while ofagent works as a normal OF controller? the basic architecture will be same. actually it was suggested to merge two agents during spec review. i think it's a good idea for longer term. (but unlikely for kilo) some ideas: a. don't bother to make it per-agent. add it to neutron's requirements. (and global-requirement) simple, but this would make non-ovs plugin users unhappy. I would simply go with a, what’s the ryu’s internal requirement list? is it big? no additional requirements as far as we use only openflow part of ryu. The I suggest to just go with a. If you want to make distributions happier, just make sure you mark appropriate entries in requirements.txt with some metadata to suggest its an ovs plugin only dependency. b. make devstack look at per-agent extra requirements file in neutron tree. eg. neutron/plugins/$Q_AGENT/requirements.txt IMHO that would make distribution work a bit harder because we may need to process new requirement files, but my answer could depend on what I asked for a. probably. i guess distributors can speak up. I am packaging neutron for RDO, and I speak up. I don't think maintaining multiple requirements files is a good option, for it will require updating packaging tools not to miss updates for the files. Also, how would you make sure those dependencies stay consistent with openstack/requirements repo? Do you plan to update tooling around the bot that proposes updates to requirements.txt files in each project? I think this option requires too much from those who will implement it in all the tools around, and does not seem to justify itself in comparison with trivial option a. c. move OVS agent to a separate repository, just like other after-decomposition vendor plugins. and use requirements.txt there. for longer term, this might be a way to go. but i don't want to block my work until it happens. That's a proper direction long term, but as it was already suggested here, it's not going to happen shortly, so no need to block your work on it. We’re not ready for that yet, as co-gating has proven as a bad strategy and we need to keep the reference implementation working for tests. i agree that it will not likely be ready in near future. YAMAMOTO Takashi d. follow the way how openvswitch is installed by devstack. a downside: we can't give a jenkins run for a patch which introduces an extra requirement. (like my patch for the mentioned blueprint [2]) i think b. is the most reasonable choice, at least for short/mid term. any comments/thoughts? YAMAMOTO Takashi [1] https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python [2] https://review.openstack.org/#/c/153946/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe (mailto: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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5J9FAAoJEC5aWaUY1u57eJwH/2+O55t7VjOS0qwM2txpMDV4 MnvMeucX5MBvpcTZ4UuE1gHMxiMHFTmhr5i5Cv+05Pnv7sbyPju+I2Ksi2kdAHlz 4Y5WiJpvrHbEtT2SdJ3OWvjvFUuhz6NM8XMhcCViVBXE3rdLzBVf864Y/8pwZt7d dR6qiyxIQB+4BbhEqe3G0YWZdULWOBKEH7TM5uXiUewA1p0v14Yt3ysfpGd7Z5t9 HY9Ty1t4JOMB5s0BTGF2LubcaRGNh6Aj596mRCo9OryKy5NR95A/SFBx2B0CIIgV i58f+PqHlFcoMHp1Qv3H4LUcxfZXitxjheSXA2cAsWDTW6kulnsYMfnSpjfVE0Q= =4fro -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)
On 01/28/2015 09:50 AM, Kevin Benton wrote: Hi, Approximately a year and a half ago, the default DHCP lease time in Neutron was increased from 120 seconds to 86400 seconds.[1] This was done with the goal of reducing DHCP traffic with very little discussion (based on what I can see in the review and bug report). While it it does indeed reduce DHCP traffic, I don't think any bug reports were filed showing that a 120 second lease time resulted in too much traffic or that a jump all of the way to 86400 seconds was required instead of a value in the same order of magnitude. I guess that would be a good case for FORCERENEW DHCP extension [1] though after digging thru dnsmasq code a bit, I doubt it supports the extension (though e.g. systemd dhcp client/server from networkd module do). Le sigh. [1]: https://tools.ietf.org/html/rfc3203 Why does this matter? Neutron ports can be updated with a new IP address from the same subnet or another subnet on the same network. The port update will result in anti-spoofing iptables rule changes that immediately stop the old IP address from working on the host. This means the host is unreachable for 0-12 hours based on the current default lease time without manual intervention[2] (assuming half-lease length DHCP renewal attempts). Why is this on the mailing list? In an attempt to make the VMs usable in a much shorter timeframe following a Neutron port address change, I submitted a patch to reduce the default DHCP lease time to 8 minutes.[3] However, this was upsetting to several people,[4] so it was suggested I bring this discussion to the mailing list. The following are the high-level concerns followed by my responses: * 8 minutes is arbitrary o Yes, but it's no more arbitrary than 1440 minutes. I picked it as an interval because it is still 4 times larger than the last short value, but it still allows VMs to regain connectivity in 5 minutes in the event their IP is changed. If someone has a good suggestion for another interval based on known dnsmasq QPS limits or some other quantitative reason, please chime in here. * other datacenters use long lease times o This is true, but it's not really a valid comparison. In most regular datacenters, updating a static DHCP lease has no effect on the data plane so it doesn't matter that the client doesn't react for hours/days (even with DHCP snooping enabled). However, in Neutron's case, the security groups are immediately updated so all traffic using the old address is blocked. * dhcp traffic is scary because it's broadcast o ARP traffic is also broadcast and many clients will expire entries every 5-10 minutes and re-ARP. L2population may be used to prevent ARP propagation, so the comparison between DHCP and ARP isn't always relevant here. Please reply back with your opinions/anecdotes/data related to short DHCP lease times. Cheers 1. https://github.com/openstack/neutron/commit/d9832282cf656b162c51afdefb830dacab72defe 2. Manual intervention could be an instance reboot, a dhcp client invocation via the console, or a delayed invocation right before the update. (all significantly more difficult to script than a simple update of a port's IP via the API). 3. https://review.openstack.org/#/c/150595/ 4. http://i.imgur.com/xtvatkP.jpg -- Kevin Benton __ 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] [all][oslo] oslo namespace package releases are done
On 01/29/2015 01:00 AM, Doug Hellmann wrote: You will all, I am sure, be relieved to know that the oslo.vmware release today was the last library that needed to be released with namespace package changes. There are a few more patches to land to the requirements list to update the minimum required version of the oslo libs, and of course the work to update projects to actually use the new package name is still ongoing. Those requirements updates are: - https://review.openstack.org/150529 - https://review.openstack.org/150556 I hope those get attention and go merged in reasonable time. /Ihar __ 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] [oslo.db] PyMySQL review
On 01/29/2015 05:57 PM, Roman Podoliaka wrote: Jeremy, I don't have exact numbers, so yeah, it's just an assumption based on looking at the nova-api/scheduler logs with connection_debug set to 100. But that's a good point you are making here: it will be interesting to see what difference enabling of PyMySQL will make for tempest/rally workloads, rather than just running synthetic tests. I'm going to give it a try on my devstack installation. Yeah, also realistic testing would mean a decent level of parallelism in requests. If you compare serial scenarios, then yes, of course mysqldb-python will be quicker. /Ihar __ 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] [neutron] [rhel7] minimal dnsmasq version
Hi Andreas, On 01/26/2015 10:58 AM, Andreas Scheuring wrote: Hi Ihar, we're currently running stable/juno devstack on rhel7 base. But I see troubles to get it running on the master branch due to bug 1408297. The fix for this bug increases the minimal dnsmasq version for master branch up to 2.67. I also recognized the stable/juno item that leaves a warning if this version level is not reached - that's why it is working fine for us so far. You mentioned in the following thread http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html , that redhat plans to backport the mac-ip matching feature to version 2.66. Not exactly. I only said that for some conservative distributions that strictly control any version bumps, simple bump of dnsmasq to 2.67 may be not an option, and hence they may consider backporting the feature they miss as an alternative. I haven't mentioned which route Red Hat will go though. You may be interested in tracking the following Red Hat bug to see how it goes: https://bugzilla.redhat.com/show_bug.cgi?id=1179756 Are you planning any additional Neutron code changes to also allow the version 2.66 or an older one of dnsmasq or may this new version for rhel come with the kilo rdo release? At least for IPv4 Use cases the 2.67 version is not required Yes, I have a patch in review to move the version check from DHCP agent to sanity_check tool [1]. I will update it today since it seems the issue gets a lot of traction and attention recently (f.e. see [2]). Note that at the moment, there is no RDO Kilo release yet. Though you may find some packages for Kilo in Delorean (RDO based on master) [3]. We hope that EL7 will receive an update for dnsmasq to allow it to serve IPv6 stateful subnets in the near future, as far as I know teams are actively working on delivering it. Once we get the update, we'll be ok to disable the warning in Juno [4] (in Red Hat repos, not upstream). [1]: https://review.openstack.org/148577 [2]: https://bugs.launchpad.net/bugs/1413042 [3]: http://209.132.178.33/repos/report.html [4]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/dhcp.py?h=stable/juno#n334 The only workaround I could imagine so far is to install a fedora package. Yes, that's a way to go for now. Sorry for any inconvenience due to that. Thanks! __ 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] [Openstack-stable-maint] Stable check of openstack/horizon failed
Proposed the version skip in master: https://review.openstack.org/#/c/149996/ On 01/26/2015 11:49 AM, Ihar Hrachyshka wrote: On 01/26/2015 11:00 AM, Julie Pichon wrote: On 26/01/15 06:34, A mailing list for the OpenStack Stable Branch test reports. wrote: Build failed. - periodic-horizon-docs-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-docs-icehouse/9382030/ : SUCCESS in 4m 14s - periodic-horizon-python26-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-python26-icehouse/b39cce4/ : FAILURE in 2m 53s - periodic-horizon-python27-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-python27-icehouse/2381739/ : FAILURE in 3m 09s - periodic-horizon-docs-juno http://logs.openstack.org/periodic-stableperiodic-horizon-docs-juno/3e9efb0/ : SUCCESS in 5m 01s - periodic-horizon-python26-juno http://logs.openstack.org/periodic-stableperiodic-horizon-python26-juno/efc60ca/ : FAILURE in 3m 19s - periodic-horizon-python27-juno http://logs.openstack.org/periodic-stableperiodic-horizon-python27-juno/59627d3/ : FAILURE in 2m 22s This is being debugged at https://bugs.launchpad.net/horizon/+bug/1413876 , the patch for django_openstack_auth is merging. Once a new version of the library is released that includes the fix, this should resolve the problem on all branches without the need for backports. Should we also update openstack/requirements for all branches not to pick the failing version of the library? /Ihar __ 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] [Openstack-stable-maint] Stable check of openstack/horizon failed
On 01/26/2015 11:00 AM, Julie Pichon wrote: On 26/01/15 06:34, A mailing list for the OpenStack Stable Branch test reports. wrote: Build failed. - periodic-horizon-docs-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-docs-icehouse/9382030/ : SUCCESS in 4m 14s - periodic-horizon-python26-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-python26-icehouse/b39cce4/ : FAILURE in 2m 53s - periodic-horizon-python27-icehouse http://logs.openstack.org/periodic-stableperiodic-horizon-python27-icehouse/2381739/ : FAILURE in 3m 09s - periodic-horizon-docs-juno http://logs.openstack.org/periodic-stableperiodic-horizon-docs-juno/3e9efb0/ : SUCCESS in 5m 01s - periodic-horizon-python26-juno http://logs.openstack.org/periodic-stableperiodic-horizon-python26-juno/efc60ca/ : FAILURE in 3m 19s - periodic-horizon-python27-juno http://logs.openstack.org/periodic-stableperiodic-horizon-python27-juno/59627d3/ : FAILURE in 2m 22s This is being debugged at https://bugs.launchpad.net/horizon/+bug/1413876 , the patch for django_openstack_auth is merging. Once a new version of the library is released that includes the fix, this should resolve the problem on all branches without the need for backports. Should we also update openstack/requirements for all branches not to pick the failing version of the library? /Ihar __ 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] pip 6.0.6 breaking py2* jobs - bug 1407736
On 01/06/2015 03:09 AM, Matt Riedemann wrote: On 1/5/2015 2:16 PM, Doug Hellmann wrote: On Jan 5, 2015, at 12:22 PM, Doug Hellmann d...@doughellmann.com wrote: On Jan 5, 2015, at 12:00 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: There is a deprecation warning in pip 6.0.6 which is making the py26 (on stable branches) and py27 jobs hit subunit log sizes of over 50 MB which makes the job fail. A logstash query shows this started happening around 1/3 which is when pip 6.0.6 was released. In Nova alone there are nearly 18 million hits of the deprecation warning. Should we temporarily block so that pip 6.0.6? https://bugs.launchpad.net/nova/+bug/1407736 I think this is actually a change in pkg_resources (in the setuptools dist) [1], being triggered by stevedore using require=False to avoid checking dependencies when plugins are loaded. Doug [1] https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502 After some discussion with Jason Coombs and dstufft, a version of setuptools with a split API to replace the deprecated option was released. I have a patch up to teach stevedore about the new methods[1]. Doug [1] https://review.openstack.org/#/c/145042/1 -- Thanks, Matt Riedemann ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The stevedore patch was merged. Do we need a release of stevedore and a global-requirements update to then get the deprecation warnings fixed in nova (on master and stable/juno)? I guess so. Also, Icehouse is affected too. I've checked Nova requirements.txt for Icehouse, and we don't cap steverore version, so a new release will be automatically propagated to all new jobs. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack][Neutron]Neutron with External DHCP server
On 01/06/2015 12:04 PM, foss geek wrote: Dear All, Is it possible to configure neutron to take VM ip from external DHCP server? I am having All In One openstack env deployed using devstack icehouse. I am looking for an option to integrate it with external DHCP server. At the moment, there is no way to achieve this, though the option was discussed as part of Pluggable IPAM effort that was approved for Kilo: http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo/neutron-ipam.rst Quoting the spec: Out-of-Scope Items [...] Pluggable DHCP would require a separate effort, or must be addressed within the individual drivers. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] dropping namespace packages
You rock, man. Thanks, I'll steal those. :) /Ihar On 01/11/2015 09:39 PM, Davanum Srinivas wrote: Jay, I have a hacking rule in nova already [1] and am updating the rule in the 3 reviews i have for oslo_utils, oslo_middleware and oslo_config [2] in Nova thanks, dims [1] https://github.com/openstack/nova/blob/master/nova/hacking/checks.py#L452 [2] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove-oslo-namespace,n,z On Sat, Jan 10, 2015 at 9:26 PM, Jay S. Bryant jsbry...@electronicjungle.net wrote: Ihar, I agree that we should do something to enforce using the appropriate namespace so that we don't have the wrong usage sneak in. I haven't gotten any rules written yet. Have had to attend to a family commitment the last few days. Hope that I can tackle the namspace changes next week. Jay On 01/08/2015 12:24 PM, Ihar Hrachyshka wrote: On 01/08/2015 07:03 PM, Doug Hellmann wrote: I’m not sure that’s something we need to enforce. Liaisons should be updating projects now as we release libraries, and then we’ll consider whether we can drop the namespace packages when we plan the next cycle. Without a hacking rule, there is a chance old namespace usage will sneak in, and then we'll need to get back to updating imports. I would rather avoid that and get migration committed with enforcement. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org 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 __ 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] [stable] Proposal to add Flavio Percoco to stable-maint-core
On 01/06/2015 08:32 PM, Adam Gandelman wrote: Hiya- Flavio has been actively involved in stable branch maintenance for as long as I can remember, but it looks like his +2 abilities were removed after the organizational changes made to the stable maintenance teams. He has expressed interest in continuing on with general stable maintenance and I think his proven understanding of branch policies make him a valuable contributor. I propose we add him to the stable-maint-core team. +2. His involvement in stable branch maintainership is much appreciated. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] release notes for 2014.2.2
Hi, FYI I've created draft release notes for 2014.2.2: https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.2 I assume that Trove will be released for 2014.2.2, so I've added it to the list of projects. Feel free to add more notes there. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev