Open Stack

Attempting to submit code to Nova, I got the following error from Jenkins:

2013-08-21 17:23:55.604 | pep8 runtests: commands[0] | flake8
2013-08-21 17:23:55.615 |   /home/jenkins/workspace/gate-nova-pep8$ /home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8
2013-08-21 17:25:44.400 | ./nova/tests/compute/test_compute_api.py:535:10: H202  assertRaises Exception too broad
2013-08-21 17:25:44.879 | ERROR: InvocationError: '/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'
2013-08-21 17:25:44.880 | pep8 runtests: commands[1] | /home/jenkins/workspace/gate-nova-pep8/tools/config/check_uptodate.sh
2013-08-21 17:25:44.884 |   /home/jenkins/workspace/gate-nova-pep8$ /home/jenkins/workspace/gate-nova-pep8/tools/config/check_uptodate.sh
2013-08-21 17:25:48.466 | ___________________________________ summary ____________________________________
2013-08-21 17:25:48.466 | ERROR:   pep8: commands failed


Since I did not modify test_compute_api.py it seems that the problem is 
with the Nova master branch. My code was branched from commit 8f47cb6399.

Dan

On 08/08/2013 07:01 PM, Adam Young wrote:
> On 08/08/2013 07:05 AM, Mark McLoughlin wrote:
>> On Thu, 2013-08-08 at 11:49 +0100, Daniel P. Berrange wrote:
>>> On Thu, Aug 08, 2013 at 11:39:44AM +0100, Mark McLoughlin wrote:
>>>> What do you mean by "dangerous code merging" in the subject? The body of
>>>> your mail doesn't make any reference to whatever "danger" you're seeing.
>>>>
>>>> On Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote:
>>>>> Hi All,
>>>>>
>>>>> Could somebody answer me, why we are merging oslo code in other projects
>>>>> and don't use
>>>>> git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)
>>>> The idea of using submodules has come a few times. I don't have a
>>>> fundamental objection to it, except any time I've seen submodules used
>>>> in a project they've been extremely painful for everyone involved.
>>>>
>>>> I'd be happy to look at a demo of a submodule based system for projects
>>>> to use code from oslo-incubator.
>>> submodules certainly could work as a way to avoid the cut+paste
>>> approach we currently do. I agree though that they do add an
>>> extra layer of pain & suffering for developers who don't fully
>>> understand what they're doing. We use them in libvirt and try
>>> to hide the pain behind clever scripts which attempt to keep
>>> the submodule properly synced, but we still get pretty frequent
>>> problem reports from devs who've managed to get themselves into
>>> a mess with the submodule state.
>> Yes, libvirt forms part of my negative experience of submodules :)
>>
>>> If we want to improve our interaction with oslo then IMHO more
>>> effort should be spent on turning bits of oslo-incubator into
>>> stable, standalone modules, removing the cut+paste need entirely.
>> Totally. Code is not intended to live in oslo-incubator forever and
>> we're having increasing success in moving stuff out:
>>
>> https://wiki.openstack.org/wiki/Oslo#Libraries
> Keystone has, I think, validated the set of oslo libraries that it
> uses:  gettext, jsontutils, importutils, crypto, and policy.
>
> gettext and jsontutils I'd be OK with these in the same library, but
> split is fine. I think  we sync down gettext and jsontutils, more often
> than any others.
>
> Should importutils stand alone?  Seems reasonable.
>
> Crypto is a pretty strong contender as well.  I think it might make
> sense to move it to a single file instead of a subdir.
>
> Would it be possible for Keystone core to be considered the maintaners
> of oslo.policy?  We seem to have the most people focused on RBAC and
> policy enforcement, and it seems to be a natural fit. Policy was
> origianlly under Keystone.
>
> We should also have an auth library.  I could see huge pieces of
> python-keystone client ending up in there.  Again, this would probably
> be best owned by the Keystone team, at least to start.
>
>> Cheers,
>> Mark.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130821/e91b5277/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130821/e91b5277/attachment.bin>