<div dir="ltr">Emma,<div><br></div><div>the plugin itself is licensed under Apache 2.0.</div><div><br></div><div>As to the ownership issue: developer stays the owner.</div><div><br></div><div>There is no contributor license agreement to sign yet.</div><div><br></div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, May 6, 2015 at 3:00 PM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [neutron][api] Extensions out, Micro-versions in<br>
(Salvatore Orlando)<br>
2. Re: [PKG-Openstack-devel][horizon][xstatic]<br>
XStatic-Angular-Bootstrap in violation of the MIT/Expat license<br>
(forwarded from:<br>
python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes<br>
REJECTED) (Thomas Goirand)<br>
3. Re: How to turn tempest CLI tests into python-*client in-tree<br>
functional tests (Robert Collins)<br>
4. Re: [TripleO] Core reviewer update proposal (Jan Provaznik)<br>
5. Re: [Nova][Ironic] Large number of ironic driver bugs in nova<br>
(Lucas Alvares Gomes)<br>
6. Re: [Fuel] Transaction scheme (Alexander Kislitsky)<br>
7. Re: How to turn tempest CLI tests into python-*client in-tree<br>
functional tests (Chris Dent)<br>
8. Re: [Fuel] Transaction scheme (Lukasz Oles)<br>
9. Re: How to turn tempest CLI tests into python-*client in-tree<br>
functional tests (Sean Dague)<br>
10. Re: [all] cross project communication: periodic developer<br>
newsletter? (Thierry Carrez)<br>
11. Re: [Nova][Ironic] Large number of ironic driver bugs in nova<br>
(John Garbutt)<br>
12. Re: [Fuel] Transaction scheme (Igor Kalnitsky)<br>
13. Re: [all] cross project communication: periodic developer<br>
newsletter? (Thierry Carrez)<br>
14. Re: [Fuel] Transaction scheme (Alexander Kislitsky)<br>
15. Re: [nova] Which error code should we return when OverQuota<br>
(Sean Dague)<br>
16. [Fuel][Plugin] Contributor license agreement for fuel plugin<br>
code? (Emma Gordon (<a href="http://projectcalico.org" target="_blank">projectcalico.org</a>))<br>
17. Re: [nova] Which error code should we return when OverQuota<br>
(Chris Dent)<br>
18. [Fuel] LBaaS in version 5.1 (Daniel Comnea)<br>
19. Re: [TripleO] Core reviewer update proposal (Dan Prince)<br>
20. Re: [Fuel][Plugin] Contributor license agreement for fuel<br>
plugin code? (Jeremy Stanley)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 6 May 2015 08:53:37 +0200<br>
From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][api] Extensions out,<br>
Micro-versions in<br>
Message-ID:<br>
<CAGR=i3jgaQ9Y3eC3QMGPZNpBF-8ThojR=<a href="mailto:ipjA6%2BApiXgNWrAGA@mail.gmail.com">ipjA6+ApiXgNWrAGA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Kevin,<br>
<br>
answers inline.<br>
<br>
On 6 May 2015 at 00:28, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
<br>
> so... as an operator looking at #3, If I need to support lbaas, I'm<br>
> getting pushed to run more and more services, like octavia, plus a<br>
> neutron-lbaas service, plus neutron? This seems like an operator<br>
> scalability issue... What benifit does splitting out the advanced services<br>
> into their own services have?<br>
><br>
<br>
You have a valid point here. In the past I was keen on insisting that<br>
neutron was supposed to be a management layer only service for most<br>
networking services.<br>
However, the consensus seems to move toward a microservices-style<br>
architecture. It would be interesting to get some feedback regarding the<br>
additional operational burden of managing a plethora of services, even if<br>
it is worth noting that when one deploys neutron with its reference<br>
architecture there are already plenty of moving parts.<br>
<br>
Regardless, I need to slaps your hand because this discussion is not really<br>
pertinent to this thread, which is specifically about having a strategy for<br>
the Neutron API.<br>
I would be happy to have a separate thread for defining a strategy for<br>
neutron services. I'm pretty sure Doug will be more than happy to slap your<br>
hands too.<br>
<br>
<br>
> Thanks,<br>
> Kevin<br>
> ------------------------------<br>
> *From:* Salvatore Orlando [<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>]<br>
> *Sent:* Tuesday, May 05, 2015 3:13 PM<br>
> *To:* OpenStack Development Mailing List<br>
> *Subject:* [openstack-dev] [neutron][api] Extensions out, Micro-versions<br>
> in<br>
><br>
> There have now been a few iterations on the specification for Neutron<br>
> micro-versioning [1].<br>
> It seems that no-one in the community opposes introducing versioning. In<br>
> particular API micro-versioning as implemented by Nova and Ironic seems a<br>
> decent way to evolve the API incrementally.<br>
><br>
> What the developer community seems not yet convinced about is moving<br>
> away from extensions. It seems everybody realises the flaws of evolving the<br>
> API through extensions, but there are understandable concerns regarding<br>
> impact on plugins/drivers as well as the ability to differentiate, which is<br>
> something quite dear to several neutron teams. I tried to consider all<br>
> those concerns and feedback received; hopefully everything has been<br>
> captured in a satisfactory way in the latest revision of [1].<br>
> With this ML post I also seek feedback from the API-wg concerning the<br>
> current proposal, whose salient points can be summarised as follows:<br>
><br>
> #1 extensions are not part anymore of the neutron API.<br>
><br>
> Evolution of the API will now be handled through versioning. Once<br>
> microversions are introduced:<br>
> - current extensions will be progressively moved into the Neutron<br>
> "unified" API<br>
> - no more extension will be accepted as part of the Neutron API<br>
><br>
> #2 Introduction of "features" for addressing diversity in Neutron plugins<br>
><br>
> It is possible that the combination of neutron plugins chosen by the<br>
> operator won't be able to support the whole Neutron API. For this reason a<br>
> concept of "feature" is included. What features are provided depends on the<br>
> plugins loaded. The list of features is hardcoded as strictly dependent on<br>
> the Neutron API version implemented by the server. The specification also<br>
> mandates a minimum set of features every neutron deployment must provide<br>
> (those would be the minimum set of features needed for integrating Neutron<br>
> with Nova).<br>
><br>
> #3 Advanced services are still extensions<br>
><br>
> This a temporary measure, as APIs for load balancing, VPN, and Edge<br>
> Firewall are still served through neutron WSGI. As in the future this API<br>
> will live independently it does not make sense to version them with Neutron<br>
> APIs.<br>
><br>
> #4 Experimenting in the API<br>
><br>
> One thing that has plagued Neutron in the past is the impossibility of<br>
> getting people to reach any sort of agreement over the shape of certain<br>
> APIs. With the proposed plan we encourage developers to submit experimental<br>
> APIs. Experimental APIs are unversioned and no guarantee is made regarding<br>
> deprecation or backward compatibility. Also they're optional, as a deployer<br>
> can turn them off. While there are caveats, like forever-experimental APIs,<br>
> this will enable developer to address user feedback during the APIs'<br>
> experimental phase. The Neutron community and the API-wg can provide plenty<br>
> of useful feeback, but ultimately is user feedback which determines whether<br>
> an API proved successful or not. Please note that the current proposal goes<br>
> in a direction different from that approved in Nova when it comes to<br>
> experimental APIs [3]<br>
><br>
> #5 Plugin/Vendor specific APIs<br>
><br>
> Neutron is without doubt the project with the highest number of 3rd<br>
> party (OSS and commercial) integration. After all it was mostly vendors who<br>
> started this project.<br>
> Vendors [4] use the extension mechanism to expose features in their<br>
> products not covered by the Neutron API or to provide some sort of<br>
> value-added service.<br>
> The current proposal still allows 3rd parties to attach extensions to the<br>
> neutron API, provided that:<br>
> - they're not considered part of the Neutron API, in terms of versioning,<br>
> documentation, and client support<br>
> - they do not redefine resources defined by the Neutron API.<br>
> - they do not live in the neutron source tree<br>
> The aim of the provisions above is to minimize the impact of such<br>
> extensions on API portability.<br>
><br>
> Thanks for reading and thanks in advance for your feedback,<br>
> Salvatore<br>
><br>
> The title of this post has been inspired by [2] (the message in the<br>
> banner may be unintelligible to readers not fluent in european football)<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/136760/" target="_blank">https://review.openstack.org/#/c/136760/</a><br>
> [2]<br>
> <a href="http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc" target="_blank">http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc</a><br>
> [3]<br>
> <a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html</a><br>
> [4] By "vendor" here we refer either to a cloud provider or a company<br>
> providing Neutron integration for their products.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/1e3ca3d4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/1e3ca3d4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 06 May 2015 09:26:37 +0200<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic]<br>
XStatic-Angular-Bootstrap in violation of the MIT/Expat license<br>
(forwarded from:<br>
python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes REJECTED)<br>
Message-ID: <<a href="mailto:5549C22D.1050603@debian.org">5549C22D.1050603@debian.org</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
<br>
<br>
On 05/05/2015 05:05 PM, Michael Krotscheck wrote:<br>
> The real question seems to be whether packagers have a disproportionate<br>
> amount of power to set development goals, tools, and policy. This is a<br>
> common theme that I've encountered frequently, and it leads to no small<br>
> amount of tension.<br>
><br>
> This tension serves no-one, and really just causes all of us stress. How<br>
> about we start a separate thread to discuss the roles of package<br>
> maintainers in OpenStack?<br>
><br>
> Michael<br>
<br>
Mostly, everyone has been super friendly in the OpenStack community, and<br>
reactions are almost always very constructive, plus my concerns are<br>
almost always addressed (and when they are not, either their's a real<br>
reason why, or it's hard to do). I haven't felt tension so much as<br>
you're claiming, apart maybe with a very low amount of individuals, but<br>
that's unavoidable in such large community.<br>
<br>
Thomas<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 6 May 2015 19:59:11 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] How to turn tempest CLI tests into<br>
python-*client in-tree functional tests<br>
Message-ID:<br>
<CAJ3HoZ3S4HGkmUKAxGv7KtAQXJ1_9ygT+Hvtzzm3g=<a href="mailto:XFz3Kddg@mail.gmail.com">XFz3Kddg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 14 February 2015 at 10:26, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>
> Digging through the logs this originated from this bug:<br>
> <a href="https://bugs.launchpad.net/tempest/+bug/1260710" target="_blank">https://bugs.launchpad.net/tempest/+bug/1260710</a><br>
><br>
> Its probably not needed everywhere and in all the clients.<br>
<br>
So I've looked more closely at this.<br>
<br>
Its actually an antipattern. It tells testr that tests are appearing<br>
and disappearing depending on what test entry point a user runs each<br>
time.<br>
<br>
testr expects the set of tests to only change when code changes.<br>
<br>
So, I fully expect that this pattern is going to lead to wtf moments<br>
now, and likely more in future.<br>
<br>
Whats the right forum for discussing the pressures that lead to this<br>
hack, so we can do something that works better with the underlying<br>
tooling, rather than in such a disruptive fashion?<br>
<br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 06 May 2015 10:18:44 +0200<br>
From: Jan Provaznik <<a href="mailto:jprovazn@redhat.com">jprovazn@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [TripleO] Core reviewer update proposal<br>
Message-ID: <<a href="mailto:5549CE64.3030304@redhat.com">5549CE64.3030304@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 05/05/2015 01:57 PM, James Slagle wrote:<br>
> Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core.<br>
><br>
> Giulio has been an active member of our community for a while. He<br>
> worked on the HA implementation in the elements and recently has been<br>
> making a lot of valuable contributions and reviews related to puppet<br>
> in the manifests, heat templates, ceph, and HA.<br>
><br>
> Steve Hardy has been instrumental in providing a lot of Heat domain<br>
> knowledge to TripleO and his reviews and guidance have been very<br>
> beneficial to a lot of the template refactoring. He's also been<br>
> reviewing and contributing in other TripleO projects besides just the<br>
> templates, and has shown a solid understanding of TripleO overall.<br>
><br>
> 180 day stats:<br>
> | gfidente | 208 0 42 166 0 0 79.8% |<br>
> 16 ( 7.7%) |<br>
> | shardy | 206 0 27 179 0 0 86.9% |<br>
> 16 ( 7.8%) |<br>
><br>
> TripleO cores, please respond with +1/-1 votes and any<br>
> comments/objections within 1 week.<br>
><br>
<br>
+1 Congrats!<br>
<br>
> Giulio and Steve, also please do let me know if you'd like to serve on<br>
> the TripleO core team if there are no objections.<br>
><br>
> I'd also like to give a heads-up to the following folks whose review<br>
> activity is very low for the last 90 days:<br>
> | tomas-8c8 ** | 8 0 0 0 8 2 100.0% | 0 ( 0.0%) |<br>
> | lsmola ** | 6 0 0 0 6 5 100.0% | 0 ( 0.0%) |<br>
> | cmsj ** | 6 0 2 0 4 2 66.7% | 0 ( 0.0%) |<br>
> | jprovazn ** | 1 0 1 0 0 0 0.0% | 0 ( 0.0%) |<br>
<br>
I've shifted my focus in a slightly different area, although I plan to<br>
contribute to some parts of TripleO I don't have overall overview of all<br>
major parts of the project which is necessary for core reviews - feel<br>
free to remove me from the core team.<br>
<br>
Jan<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 6 May 2015 09:39:35 +0100<br>
From: Lucas Alvares Gomes <<a href="mailto:lucasagomes@gmail.com">lucasagomes@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Ironic] Large number of ironic<br>
driver bugs in nova<br>
Message-ID:<br>
<<a href="mailto:CAB1EZBpu0NEfaZ2pH8khFvCAEU-kyikVWnUKUCxO3svrSzQ7Aw@mail.gmail.com">CAB1EZBpu0NEfaZ2pH8khFvCAEU-kyikVWnUKUCxO3svrSzQ7Aw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi<br>
<br>
> I noticed last night that there are 23 bugs currently filed in nova<br>
> tagged as ironic related. Whilst some of those are scheduler issues, a<br>
> lot of them seem like things in the ironic driver itself.<br>
><br>
> Does the ironic team have someone assigned to work on these bugs and<br>
> generally keep an eye on their driver in nova? How do we get these<br>
> bugs resolved?<br>
><br>
<br>
Thanks for this call out. I don't think we have anyone specifically<br>
assigned to keep an eye on the Ironic<br>
Nova driver, we would look at it from time to time or when someone ask<br>
us to in the Ironic channel/ML/etc...<br>
But that said, I think we need to pay more attention to the bugs in Nova.<br>
<br>
I've added one item about it to be discussed in the next Ironic<br>
meeting[1]. And in the meantime, I will take a<br>
look at some of the bugs myself.<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting" target="_blank">https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting</a><br>
<br>
Thanks again,<br>
Lucas<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 6 May 2015 11:51:33 +0300<br>
From: Alexander Kislitsky <<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Transaction scheme<br>
Message-ID:<br>
<CAHWr6f=<a href="mailto:HT70zh9To1uVzHA87hkqbWEMQpDFj3ZkqyminSfjnFA@mail.gmail.com">HT70zh9To1uVzHA87hkqbWEMQpDFj3ZkqyminSfjnFA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi!<br>
<br>
The refactoring of transactions management in Nailgun is critically<br>
required for scaling.<br>
<br>
First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
decorator.<br>
After that we should introduce transactions wrapping decorator into Task<br>
execute/message calls.<br>
And the last one is the wrapping of receiver calls.<br>
<br>
As result we should have begin/commit/rollback calls only in transactions<br>
decorator.<br>
<br>
Also I propose to separate working with DB objects into separate lair and<br>
use only high level Nailgun objects in the code and tests. This work was<br>
started long time ago, but not finished yet.<br>
<br>
On Thu, Apr 30, 2015 at 12:36 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
<br>
> Hi folks!<br>
><br>
> Recently I faced a pretty sad fact that in Nailgun there?s no common<br>
> approach to manage transactions. There are commits and flushes in random<br>
> places of the code and it used to work somehow just because it was all<br>
> synchronous.<br>
><br>
> However, after just a few of the subcomponents have been moved to<br>
> different processes, it all started producing races and deadlocks which are<br>
> really hard to resolve because there is absolutely no way to predict how a<br>
> specific transaction is managed but by analyzing the source code. That is<br>
> rather an ineffective and error-prone approach that has to be fixed before<br>
> it became uncontrollable.<br>
><br>
> Let?s arrange a discussions to design a document which will describe where<br>
> and how transactions are managed and refactor Nailgun according to it in<br>
> 7.0. Otherwise results may be sad.<br>
><br>
><br>
> - romcheg<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/58072349/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/58072349/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 6 May 2015 09:57:17 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:chdent@redhat.com">chdent@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] How to turn tempest CLI tests into<br>
python-*client in-tree functional tests<br>
Message-ID: <alpine.OSX.2.11.1505060952230.9820@seed.local><br>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br>
<br>
On Wed, 6 May 2015, Robert Collins wrote:<br>
<br>
> Its actually an antipattern. It tells testr that tests are appearing<br>
> and disappearing depending on what test entry point a user runs each<br>
> time.<br>
><br>
> testr expects the set of tests to only change when code changes.<br>
><br>
> So, I fully expect that this pattern is going to lead to wtf moments<br>
> now, and likely more in future.<br>
><br>
> Whats the right forum for discussing the pressures that lead to this<br>
> hack, so we can do something that works better with the underlying<br>
> tooling, rather than in such a disruptive fashion?<br>
<br>
I'd appreciate here (that is on this list) because from my<br>
perspective there are a lot of embedded assumptions in the way testr<br>
does things and wants the environment to be that aren't immediately<br>
obvious and would perhaps be made more clear if you could expand on<br>
the details of what's wrong with this particular hack.<br>
<br>
I tried to come up with a specific question here to drive that<br>
illumination a bit more concretely but a) not enough coffee yet b)<br>
mostly I just want to know more detail about the first three<br>
paragraphs above.<br>
<br>
Thanks.<br>
--<br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 6 May 2015 11:15:02 +0200<br>
From: Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Transaction scheme<br>
Message-ID:<br>
<<a href="mailto:CAOoSAzK82SBds05MWcmZ_R2DDGZDaFGtpB2Ur0NO9sAFo8hnDQ@mail.gmail.com">CAOoSAzK82SBds05MWcmZ_R2DDGZDaFGtpB2Ur0NO9sAFo8hnDQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky<br>
<<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>> wrote:<br>
> Hi!<br>
><br>
> The refactoring of transactions management in Nailgun is critically required<br>
> for scaling.<br>
><br>
> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
> decorator.<br>
> After that we should introduce transactions wrapping decorator into Task<br>
> execute/message calls.<br>
> And the last one is the wrapping of receiver calls.<br>
><br>
> As result we should have begin/commit/rollback calls only in transactions<br>
> decorator.<br>
<br>
Big +1 for this. I always wondered why we don't have it.<br>
<br>
><br>
<br>
> Also I propose to separate working with DB objects into separate lair and<br>
> use only high level Nailgun objects in the code and tests. This work was<br>
> started long time ago, but not finished yet.<br>
><br>
> On Thu, Apr 30, 2015 at 12:36 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
>><br>
>> Hi folks!<br>
>><br>
>> Recently I faced a pretty sad fact that in Nailgun there?s no common<br>
>> approach to manage transactions. There are commits and flushes in random<br>
>> places of the code and it used to work somehow just because it was all<br>
>> synchronous.<br>
>><br>
>> However, after just a few of the subcomponents have been moved to<br>
>> different processes, it all started producing races and deadlocks which are<br>
>> really hard to resolve because there is absolutely no way to predict how a<br>
>> specific transaction is managed but by analyzing the source code. That is<br>
>> rather an ineffective and error-prone approach that has to be fixed before<br>
>> it became uncontrollable.<br>
>><br>
>> Let?s arrange a discussions to design a document which will describe where<br>
>> and how transactions are managed and refactor Nailgun according to it in<br>
>> 7.0. Otherwise results may be sad.<br>
>><br>
>><br>
>> - romcheg<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
?ukasz Ole?<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 06 May 2015 05:43:29 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] How to turn tempest CLI tests into<br>
python-*client in-tree functional tests<br>
Message-ID: <<a href="mailto:5549E241.9080706@dague.net">5549E241.9080706@dague.net</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 05/06/2015 04:57 AM, Chris Dent wrote:<br>
> On Wed, 6 May 2015, Robert Collins wrote:<br>
><br>
>> Its actually an antipattern. It tells testr that tests are appearing<br>
>> and disappearing depending on what test entry point a user runs each<br>
>> time.<br>
>><br>
>> testr expects the set of tests to only change when code changes.<br>
>><br>
>> So, I fully expect that this pattern is going to lead to wtf moments<br>
>> now, and likely more in future.<br>
>><br>
>> Whats the right forum for discussing the pressures that lead to this<br>
>> hack, so we can do something that works better with the underlying<br>
>> tooling, rather than in such a disruptive fashion?<br>
><br>
> I'd appreciate here (that is on this list) because from my<br>
> perspective there are a lot of embedded assumptions in the way testr<br>
> does things and wants the environment to be that aren't immediately<br>
> obvious and would perhaps be made more clear if you could expand on<br>
> the details of what's wrong with this particular hack.<br>
><br>
> I tried to come up with a specific question here to drive that<br>
> illumination a bit more concretely but a) not enough coffee yet b)<br>
> mostly I just want to know more detail about the first three<br>
> paragraphs above.<br>
<br>
There are 2 reasons that pattern exists.<br>
<br>
1) testr discovery is quite slow on large trees, especially if your<br>
intent is to run a small subset of tests by sending an argument<br>
<br>
2) testr still doesn't have an exclude facility, so top level test<br>
exclusion has to be done by quite complicated negative asserting regex,<br>
which are very error prone (and have been done incorrectly many times).<br>
Especially if you *still* want to support partial test passing.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 06 May 2015 11:54:32 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all] cross project communication:<br>
periodic developer newsletter?<br>
Message-ID: <<a href="mailto:5549E4D8.5060201@openstack.org">5549E4D8.5060201@openstack.org</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
Hugh Blemings wrote:<br>
> +2<br>
><br>
> I think asking LWN if they have the bandwidth and interest to do this<br>
> would be ideal - they've credibility in the Free/Open Source space and a<br>
> proven track record. Nice people too.<br>
<br>
On the bandwidth side, as a regular reader I was under the impression<br>
that they struggled with their load already, but I guess if it comes<br>
with funding that could be an option.<br>
<br>
On the interest side, my past tries to invite them to the OpenStack<br>
Summit so that they could cover it (the way they cover other<br>
conferences) were rejected, so I have doubts in that area as well.<br>
<br>
Anyone having a personal connection that we could leverage to pursue<br>
that option further ?<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 6 May 2015 10:55:42 +0100<br>
From: John Garbutt <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Ironic] Large number of ironic<br>
driver bugs in nova<br>
Message-ID:<br>
<<a href="mailto:CABib2_ozzkd__CMuDe-qzvmukzCKqvibQEfu1kWW-sqhM3vFjQ@mail.gmail.com">CABib2_ozzkd__CMuDe-qzvmukzCKqvibQEfu1kWW-sqhM3vFjQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 6 May 2015 at 09:39, Lucas Alvares Gomes <<a href="mailto:lucasagomes@gmail.com">lucasagomes@gmail.com</a>> wrote:<br>
> Hi<br>
><br>
>> I noticed last night that there are 23 bugs currently filed in nova<br>
>> tagged as ironic related. Whilst some of those are scheduler issues, a<br>
>> lot of them seem like things in the ironic driver itself.<br>
>><br>
>> Does the ironic team have someone assigned to work on these bugs and<br>
>> generally keep an eye on their driver in nova? How do we get these<br>
>> bugs resolved?<br>
>><br>
><br>
> Thanks for this call out. I don't think we have anyone specifically<br>
> assigned to keep an eye on the Ironic<br>
> Nova driver, we would look at it from time to time or when someone ask<br>
> us to in the Ironic channel/ML/etc...<br>
> But that said, I think we need to pay more attention to the bugs in Nova.<br>
><br>
> I've added one item about it to be discussed in the next Ironic<br>
> meeting[1]. And in the meantime, I will take a<br>
> look at some of the bugs myself.<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting" target="_blank">https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting</a><br>
<br>
Thanks to you both for raising this and pushing on this.<br>
<br>
Maybe we can get a named cross project liaison to bridge the Ironic<br>
and Nova meetings. We are working on building a similar pattern for<br>
Neutron. It doesn't necessarily mean attending every nova-meeting,<br>
just someone to act as an explicit bridge between our two projects?<br>
<br>
I am open to whatever works though, just hoping we can be more<br>
proactive about issues and dependencies that pop up.<br>
<br>
Thanks,<br>
John<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 6 May 2015 12:57:37 +0300<br>
From: Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Transaction scheme<br>
Message-ID:<br>
<<a href="mailto:CACo6NWDvxXphm0WgeC%2BzDGaUWzE4F1OZLOpdv2CR%2BBN7JmYUug@mail.gmail.com">CACo6NWDvxXphm0WgeC+zDGaUWzE4F1OZLOpdv2CR+BN7JmYUug@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
<br>
I don't know what you are talking about, but we do wrap handlers in<br>
transaction for a long time. Here's the code<br>
<a href="https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84" target="_blank">https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84</a><br>
<br>
The issue is that we sometimes perform `.commit()` inside the code<br>
(e.g. `task.execute()`) and therefore it's hard to predict which data<br>
are committed and which are not.<br>
<br>
In order to avoid this, we have to declare strict scopes for different<br>
layers. Yes, we definitely should base on idea that handlers should<br>
open transaction on the begin and close it on the end. But that won't<br>
solve all problems, because sometimes we should commit data before<br>
handler's end. For instance, commit some task before sending message<br>
to Astute. Such cases complicate the things.. and it would be cool if<br>
could avoid them by re-factoring our architecture. Perhaps, we could<br>
send tasks to Astute when the handler is done? What do you think?<br>
<br>
Thanks,<br>
igor<br>
<br>
On Wed, May 6, 2015 at 12:15 PM, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
> On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky<br>
> <<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>> wrote:<br>
>> Hi!<br>
>><br>
>> The refactoring of transactions management in Nailgun is critically required<br>
>> for scaling.<br>
>><br>
>> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
>> decorator.<br>
>> After that we should introduce transactions wrapping decorator into Task<br>
>> execute/message calls.<br>
>> And the last one is the wrapping of receiver calls.<br>
>><br>
>> As result we should have begin/commit/rollback calls only in transactions<br>
>> decorator.<br>
><br>
> Big +1 for this. I always wondered why we don't have it.<br>
><br>
>><br>
><br>
>> Also I propose to separate working with DB objects into separate lair and<br>
>> use only high level Nailgun objects in the code and tests. This work was<br>
>> started long time ago, but not finished yet.<br>
>><br>
>> On Thu, Apr 30, 2015 at 12:36 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
>>><br>
>>> Hi folks!<br>
>>><br>
>>> Recently I faced a pretty sad fact that in Nailgun there?s no common<br>
>>> approach to manage transactions. There are commits and flushes in random<br>
>>> places of the code and it used to work somehow just because it was all<br>
>>> synchronous.<br>
>>><br>
>>> However, after just a few of the subcomponents have been moved to<br>
>>> different processes, it all started producing races and deadlocks which are<br>
>>> really hard to resolve because there is absolutely no way to predict how a<br>
>>> specific transaction is managed but by analyzing the source code. That is<br>
>>> rather an ineffective and error-prone approach that has to be fixed before<br>
>>> it became uncontrollable.<br>
>>><br>
>>> Let?s arrange a discussions to design a document which will describe where<br>
>>> and how transactions are managed and refactor Nailgun according to it in<br>
>>> 7.0. Otherwise results may be sad.<br>
>>><br>
>>><br>
>>> - romcheg<br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> ?ukasz Ole?<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 06 May 2015 11:59:04 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [all] cross project communication:<br>
periodic developer newsletter?<br>
Message-ID: <<a href="mailto:5549E5E8.5050508@openstack.org">5549E5E8.5050508@openstack.org</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
Joe Gordon wrote:<br>
> On Tue, May 5, 2015 at 9:53 AM, James Bottomley wrote:<br>
> On Tue, 2015-05-05 at 10:45 +0200, Thierry Carrez wrote:<br>
> > The issue is, who can write such content ? It is a full-time job to<br>
> > produce authored content, you can't just copy (or link to) content<br>
> > produced elsewhere. It takes a very special kind of individual to write<br>
> > such content: the person has to be highly technical, able to tackle any<br>
> > topic, and totally connected with the OpenStack development community.<br>
> > That person has to be cross-project and ideally have already-built<br>
> > legitimacy.<br>
><br>
> Here, you're being overly restrictive. Lwn.net isn't staffed by top<br>
> level kernel maintainers (although it does solicit the occasional<br>
> article from them). It's staffed by people who gained credibility via<br>
> their insightful reporting rather than by their contributions. I see no<br>
> reason why the same model wouldn't work for OpenStack.<br>
><br>
> ++. I have a hunch that like many things (in OpenStack) if you make a<br>
> space for people to step up, they will.<br>
<br>
I guess being burnt trying to set that up in the past makes me overly<br>
pessimistic. Let's see... Anyone interested in producing that kind of<br>
"OpenStack Developer Community Digest" ?<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 6 May 2015 13:22:40 +0300<br>
From: Alexander Kislitsky <<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Transaction scheme<br>
Message-ID:<br>
<<a href="mailto:CAHWr6fmSiU1yY_zK0Van_9mcXLeXomJ7ja8wQfJDnTkQEB8NMA@mail.gmail.com">CAHWr6fmSiU1yY_zK0Van_9mcXLeXomJ7ja8wQfJDnTkQEB8NMA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I mean, that we should have explicitly wrapped http handlers. For example:<br>
<br>
@transaction<br>
def PUT(...):<br>
...<br>
<br>
We don't need transactions, for example, in GET methods.<br>
<br>
I propose to rid of complex data flows in our code. Code with 'commit' call<br>
inside the the method should be split into independent units.<br>
<br>
I like the solution with sending tasks to Astute at the end of handler<br>
execution.<br>
<br>
On Wed, May 6, 2015 at 12:57 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
wrote:<br>
<br>
> > First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
><br>
> I don't know what you are talking about, but we do wrap handlers in<br>
> transaction for a long time. Here's the code<br>
><br>
> <a href="https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84" target="_blank">https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84</a><br>
><br>
> The issue is that we sometimes perform `.commit()` inside the code<br>
> (e.g. `task.execute()`) and therefore it's hard to predict which data<br>
> are committed and which are not.<br>
><br>
> In order to avoid this, we have to declare strict scopes for different<br>
> layers. Yes, we definitely should base on idea that handlers should<br>
> open transaction on the begin and close it on the end. But that won't<br>
> solve all problems, because sometimes we should commit data before<br>
> handler's end. For instance, commit some task before sending message<br>
> to Astute. Such cases complicate the things.. and it would be cool if<br>
> could avoid them by re-factoring our architecture. Perhaps, we could<br>
> send tasks to Astute when the handler is done? What do you think?<br>
><br>
> Thanks,<br>
> igor<br>
><br>
> On Wed, May 6, 2015 at 12:15 PM, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
> > On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky<br>
> > <<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>> wrote:<br>
> >> Hi!<br>
> >><br>
> >> The refactoring of transactions management in Nailgun is critically<br>
> required<br>
> >> for scaling.<br>
> >><br>
> >> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
> >> decorator.<br>
> >> After that we should introduce transactions wrapping decorator into Task<br>
> >> execute/message calls.<br>
> >> And the last one is the wrapping of receiver calls.<br>
> >><br>
> >> As result we should have begin/commit/rollback calls only in<br>
> transactions<br>
> >> decorator.<br>
> ><br>
> > Big +1 for this. I always wondered why we don't have it.<br>
> ><br>
> >><br>
> ><br>
> >> Also I propose to separate working with DB objects into separate lair<br>
> and<br>
> >> use only high level Nailgun objects in the code and tests. This work was<br>
> >> started long time ago, but not finished yet.<br>
> >><br>
> >> On Thu, Apr 30, 2015 at 12:36 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>><br>
> wrote:<br>
> >>><br>
> >>> Hi folks!<br>
> >>><br>
> >>> Recently I faced a pretty sad fact that in Nailgun there?s no common<br>
> >>> approach to manage transactions. There are commits and flushes in<br>
> random<br>
> >>> places of the code and it used to work somehow just because it was all<br>
> >>> synchronous.<br>
> >>><br>
> >>> However, after just a few of the subcomponents have been moved to<br>
> >>> different processes, it all started producing races and deadlocks<br>
> which are<br>
> >>> really hard to resolve because there is absolutely no way to predict<br>
> how a<br>
> >>> specific transaction is managed but by analyzing the source code. That<br>
> is<br>
> >>> rather an ineffective and error-prone approach that has to be fixed<br>
> before<br>
> >>> it became uncontrollable.<br>
> >>><br>
> >>> Let?s arrange a discussions to design a document which will describe<br>
> where<br>
> >>> and how transactions are managed and refactor Nailgun according to it<br>
> in<br>
> >>> 7.0. Otherwise results may be sad.<br>
> >>><br>
> >>><br>
> >>> - romcheg<br>
> >>><br>
> >>><br>
> >>><br>
> __________________________________________________________________________<br>
> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > ?ukasz Ole?<br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/d27289fa/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/d27289fa/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 06 May 2015 06:43:05 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova] Which error code should we return<br>
when OverQuota<br>
Message-ID: <<a href="mailto:5549F039.1060205@dague.net">5549F039.1060205@dague.net</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
It does, however I looked through the history of that repo, and that's<br>
just in one of Jay's documents that predates the group. I'm a little<br>
cautious to give it a lot of weight without rationale.<br>
<br>
Honestly, there is this obsession of assuming that there *are* good fits<br>
for HTTP status codes for non webbrowser interaction patterns. There are<br>
not. The error code set was based around a specific expected web browser<br>
/ website model from 20 years ago.<br>
<br>
I honestly think we'd be better served by limiting our use of non 200 or<br>
400 codes to really narrow conditions (the ones that you'd expect from<br>
the browser interaction pattern). This would approach the whole problem<br>
from the "least surprise" perspective.<br>
<br>
404 - resource doesn't exist (appropriate for GET /foo/ID_NUMBER where<br>
the thing isn't there)<br>
<br>
403 - permissions error. Appropriate for a resource that exists, but you<br>
do not have enough permissions for it. I.e. it's an admin URL or someone<br>
else's resource.<br>
<br>
All other client errors, just be a 400. And use the emerging error<br>
reporting json to actually tell the client what's going on.<br>
<br>
-Sean<br>
<br>
<br>
On 05/05/2015 09:48 PM, Alex Xu wrote:<br>
> From API-WG guideline, exceed quota should be 403<br>
><br>
> <a href="https://github.com/openstack/api-wg/blob/master/guidelines/http.rst" target="_blank">https://github.com/openstack/api-wg/blob/master/guidelines/http.rst</a><br>
><br>
> 2015-05-06 3:30 GMT+08:00 Chen CH Ji <<a href="mailto:jichenjc@cn.ibm.com">jichenjc@cn.ibm.com</a><br>
> <mailto:<a href="mailto:jichenjc@cn.ibm.com">jichenjc@cn.ibm.com</a>>>:<br>
><br>
> In doing patch [1], A suggestion is submitted that we should return<br>
> 400 (bad Request) instead of 403 (Forbidden)<br>
> I take a look at [2], seems 400 is not a good candidate because<br>
> /'//The request could not be understood by the server due to<br>
> malformed syntax. The client SHOULD NOT repeat the request without<br>
> modifications. //'/<br>
><br>
> may be a 409 (conflict) error if we really don't think 403 is a good<br>
> one?<br>
> Thanks<br>
><br>
><br>
> [1] <a href="https://review.openstack.org/#/c/173985/" target="_blank">https://review.openstack.org/#/c/173985/</a><br>
> [2] <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" target="_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a><br>
><br>
> Best Regards!<br>
><br>
> Kevin (Chen) Ji ? ?<br>
><br>
> Engineer, zVM Development, CSTL<br>
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: <a href="mailto:jichenjc@cn.ibm.com">jichenjc@cn.ibm.com</a><br>
> <mailto:<a href="mailto:jichenjc@cn.ibm.com">jichenjc@cn.ibm.com</a>><br>
> Phone: +86-10-82454158 <tel:%2B86-10-82454158><br>
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian<br>
> District, Beijing 100193, PRC<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 6 May 2015 11:02:42 +0000<br>
From: "Emma Gordon (<a href="http://projectcalico.org" target="_blank">projectcalico.org</a>)" <<a href="mailto:emma@projectcalico.org">emma@projectcalico.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Joe Marshall <<a href="mailto:Joe.Marshall@metaswitch.com">Joe.Marshall@metaswitch.com</a>><br>
Subject: [openstack-dev] [Fuel][Plugin] Contributor license agreement<br>
for fuel plugin code?<br>
Message-ID:<br>
<<a href="mailto:0365813DA4F34A468C57038EAA5F396FE387AACA@ENFICSMBX1.datcon.co.uk">0365813DA4F34A468C57038EAA5F396FE387AACA@ENFICSMBX1.datcon.co.uk</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
If fuel plugin code is checked into a stackforge repository (as suggested in the fuel plugin wiki <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Repo" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins#Repo</a>), who owns that code? Is there a contributor license agreement to sign? (For example, contributors to OpenStack would sign this <a href="https://review.openstack.org/static/cla.html" target="_blank">https://review.openstack.org/static/cla.html</a>)<br>
<br>
Thanks,<br>
Emma<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/06c39ae9/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/06c39ae9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 6 May 2015 12:11:06 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:chdent@redhat.com">chdent@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] Which error code should we return<br>
when OverQuota<br>
Message-ID: <alpine.OSX.2.11.1505061159290.9820@seed.local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Wed, 6 May 2015, Sean Dague wrote:<br>
<br>
> All other client errors, just be a 400. And use the emerging error<br>
> reporting json to actually tell the client what's going on.<br>
<br>
Please do not do this. Please use the 4xx codes as best as you<br>
possibly can. Yes, they don't always match, but there are several of<br>
them for reasons? and it is usually possible to find one that sort<br>
of fits.<br>
<br>
Using just 400 is bad for a healthy HTTP ecosystem. Sure, for the<br>
most part people are talking to OpenStack through "official clients"<br>
but a) what happens when they aren't, b) is that the kind of world<br>
we want?<br>
<br>
I certainly don't. I want a world where the HTTP APIs that OpenStack<br>
and other services present actually use HTTP and allow a diversity<br>
of clients (machine and human).<br>
<br>
Using response codes effectively makes it easier to write client code<br>
that is either simple or is able to use generic libraries effectively.<br>
<br>
Let's be honest: OpenStack doesn't have a great record of using HTTP<br>
effectively or correctly. Let's not make it worse.<br>
<br>
In the case of quota, 403 is fairly reasonable because you are in<br>
fact "Forbidden" from doing the thing you want to do. Yes, with the<br>
passage of time you may very well not be forbidden so the semantics<br>
are not strictly matching but it is more immediately expressive yet<br>
not quite as troubling as 409 (which has a more specific meaning).<br>
<br>
400 is useful fallback for when nothing else will do.<br>
<br>
--<br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Wed, 6 May 2015 12:12:12 +0100<br>
From: Daniel Comnea <<a href="mailto:comnea.dani@gmail.com">comnea.dani@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Fuel] LBaaS in version 5.1<br>
Message-ID:<br>
<<a href="mailto:CAOBAnZM4RBX3psG2zQ0%2B0Tdr696CoJMBiapNqT7wc6Mb%2BwMPgg@mail.gmail.com">CAOBAnZM4RBX3psG2zQ0+0Tdr696CoJMBiapNqT7wc6Mb+wMPgg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
HI all,<br>
<br>
Recently i used Fuel 5.1 to deploy Openstack Icehouse on a Lab (PoC) and a<br>
request came with enabling Neutron LBaaS.<br>
<br>
I have looked up on Fuel doc to see if this is supported in the version i'm<br>
running but failed ot find anything.<br>
<br>
Anyone can point me to any docs which mentioned a) yes it is supported and<br>
b) how to update it via Fuel?<br>
<br>
Thanks,<br>
Dani<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/8e77b718/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/8e77b718/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Wed, 06 May 2015 07:20:35 -0400<br>
From: Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] Core reviewer update proposal<br>
Message-ID: <<a href="mailto:1430911235.13747.1.camel@redhat.com">1430911235.13747.1.camel@redhat.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Tue, 2015-05-05 at 07:57 -0400, James Slagle wrote:<br>
> Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core.<br>
><br>
> Giulio has been an active member of our community for a while. He<br>
> worked on the HA implementation in the elements and recently has been<br>
> making a lot of valuable contributions and reviews related to puppet<br>
> in the manifests, heat templates, ceph, and HA.<br>
<br>
+1 Giulio has become one of our resident HA experts.<br>
<br>
><br>
> Steve Hardy has been instrumental in providing a lot of Heat domain<br>
> knowledge to TripleO and his reviews and guidance have been very<br>
> beneficial to a lot of the template refactoring. He's also been<br>
> reviewing and contributing in other TripleO projects besides just the<br>
> templates, and has shown a solid understanding of TripleO overall.<br>
<br>
+1 Steve's Heat expertise has been invaluable.<br>
<br>
><br>
> 180 day stats:<br>
> | gfidente | 208 0 42 166 0 0 79.8% |<br>
> 16 ( 7.7%) |<br>
> | shardy | 206 0 27 179 0 0 86.9% |<br>
> 16 ( 7.8%) |<br>
><br>
> TripleO cores, please respond with +1/-1 votes and any<br>
> comments/objections within 1 week.<br>
><br>
> Giulio and Steve, also please do let me know if you'd like to serve on<br>
> the TripleO core team if there are no objections.<br>
><br>
> I'd also like to give a heads-up to the following folks whose review<br>
> activity is very low for the last 90 days:<br>
> | tomas-8c8 ** | 8 0 0 0 8 2 100.0% | 0 ( 0.0%) |<br>
> | lsmola ** | 6 0 0 0 6 5 100.0% | 0 ( 0.0%) |<br>
> | cmsj ** | 6 0 2 0 4 2 66.7% | 0 ( 0.0%) |<br>
> | jprovazn ** | 1 0 1 0 0 0 0.0% | 0 ( 0.0%) |<br>
> | jonpaul-sullivan ** | <no activity><br>
> Helping out with reviewing contributions is one of the best ways we<br>
> can make good forward progress in TripleO. All of the above folks are<br>
> valued reviewers and we'd love to see you review more submissions. If<br>
> you feel that your focus has shifted away from TripleO and you'd no<br>
> longer like to serve on the core team, please let me know.<br>
><br>
> I also plan to remove Alexis Lee from core, who previously has<br>
> expressed that he'd be stepping away from TripleO for a while. Alexis,<br>
> thank you for reviews and contributions!<br>
><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Wed, 6 May 2015 11:58:15 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license<br>
agreement for fuel plugin code?<br>
Message-ID: <<a href="mailto:20150506115815.GT2347@yuggoth.org">20150506115815.GT2347@yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2015-05-06 11:02:42 +0000 (+0000), Emma Gordon (<a href="http://projectcalico.org" target="_blank">projectcalico.org</a>) wrote:<br>
> If fuel plugin code is checked into a stackforge repository (as<br>
> suggested in the fuel plugin wiki<br>
> <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Repo" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins#Repo</a>), who owns that<br>
> code?<br>
<br>
I am not a lawyer, but my understanding is that the individual<br>
copyright holders mentioned in comments at the tops of various<br>
files, listed in an AUTHORS file (if included) and indicated within<br>
the repository's Git commit history retain rights over their<br>
contributions in a project relying on the Apache License (or those<br>
rights may belong to their individual respective employers in a<br>
work-for-hire situation as well).<br>
<br>
> Is there a contributor license agreement to sign? (For<br>
> example, contributors to OpenStack would sign this<br>
> <a href="https://review.openstack.org/static/cla.html" target="_blank">https://review.openstack.org/static/cla.html</a>)<br>
<br>
If Fuel is planning to apply for inclusion in OpenStack, then it may<br>
make sense to get all current and former contributors to its source<br>
repositories to agree to the OpenStack Individual Contributor<br>
License Agreement. Note that it does _not_ change the ownership of<br>
the software (copyrights), it's intended to simply reinforce the<br>
OpenStack Foundation's ability to continue to redistribute the<br>
software under the Apache License by affirming that the terms of the<br>
license are applied correctly and intentionally.<br>
<br>
More detailed questions are probably best posed to the<br>
<a href="mailto:legal-discuss@lists.openstack.org">legal-discuss@lists.openstack.org</a> mailing list, or to your own<br>
private legal representation.<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 37, Issue 12<br>
*********************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Best regards,<br></div><br>Irina</div><div><br></div><div>PI Team Technical Writer</div><div>skype: ira_live<br></div><div>Trello board: <a href="https://trello.com/b/3nxd5wFq/irina-povolotskaya-tasks-tracking-board" target="_blank">https://trello.com/b/3nxd5wFq/irina-povolotskaya-tasks-tracking-board</a></div><div><i><font color="#004080" face="Arial"><span style="font-style:italic;font-family:Arial;color:rgb(0,64,128);font-size:10pt" lang="EN-US"><br><br></span></font></i></div><div><br></div><br><br></div></div></div></div></div></div></div>
</div></div></div>