Re: [openstack-dev] [all] minimum python support version for juno

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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.

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?!?

[Ihar Hrachyshka]

-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?!?

[Ihar Hrachyshka]

-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 :(

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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.

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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?

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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)

[Ihar Hrachyshka]

-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

[Ihar Hrachyshka]

-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???)

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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

[Ihar Hrachyshka]

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