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