<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Attempting to submit code to Nova, I
got the following error from Jenkins:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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</pre>
<br>
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.<br>
<br>
Dan<br>
<br>
On 08/08/2013 07:01 PM, Adam Young wrote:<br>
</div>
<blockquote cite="mid:52042343.70803@redhat.com" type="cite">
<pre wrap="">On 08/08/2013 07:05 AM, Mark McLoughlin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 2013-08-08 at 11:49 +0100, Daniel P. Berrange wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Aug 08, 2013 at 11:39:44AM +0100, Mark McLoughlin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
Could somebody answer me, why we are merging oslo code in other projects
and don't use
git submodules (<a class="moz-txt-link-freetext" href="http://git-scm.com/book/en/Git-Tools-Submodules">http://git-scm.com/book/en/Git-Tools-Submodules</a>)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Yes, libvirt forms part of my negative experience of submodules :)
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Totally. Code is not intended to live in oslo-incubator forever and
we're having increasing success in moving stuff out:
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Oslo#Libraries">https://wiki.openstack.org/wiki/Oslo#Libraries</a>
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
Cheers,
Mark.
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>