[openstack-dev] Fuel][Plugin] Contributor license agreement for fuel plugin code?
Irina Povolotskaya
ipovolotskaya at mirantis.com
Wed May 6 12:32:24 UTC 2015
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, <openstack-dev-request at lists.openstack.org>
wrote:
> Send OpenStack-dev mailing list submissions to
> openstack-dev at lists.openstack.org
>
> 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
> openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at lists.openstack.org
>
> 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 <sorlando at nicira.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][api] Extensions out,
> Micro-versions in
> Message-ID:
> <CAGR=i3jgaQ9Y3eC3QMGPZNpBF-8ThojR=
> ipjA6+ApiXgNWrAGA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Kevin,
>
> answers inline.
>
> On 6 May 2015 at 00:28, Fox, Kevin M <Kevin.Fox at pnnl.gov> 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 [sorlando at nicira.com]
> > *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:
> OpenStack-dev-request at lists.openstack.org?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 <zigo at debian.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> 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: <5549C22D.1050603 at debian.org>
> 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 <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] How to turn tempest CLI tests into
> python-*client in-tree functional tests
> Message-ID:
> <CAJ3HoZ3S4HGkmUKAxGv7KtAQXJ1_9ygT+Hvtzzm3g=
> XFz3Kddg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 14 February 2015 at 10:26, Joe Gordon <joe.gordon0 at gmail.com> 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 <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 06 May 2015 10:18:44 +0200
> From: Jan Provaznik <jprovazn at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [TripleO] Core reviewer update proposal
> Message-ID: <5549CE64.3030304 at redhat.com>
> 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 <lucasagomes at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Ironic] Large number of ironic
> driver bugs in nova
> Message-ID:
> <
> CAB1EZBpu0NEfaZ2pH8khFvCAEU-kyikVWnUKUCxO3svrSzQ7Aw at 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 <akislitsky at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Transaction scheme
> Message-ID:
> <CAHWr6f=
> HT70zh9To1uVzHA87hkqbWEMQpDFj3ZkqyminSfjnFA at mail.gmail.com>
> 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 <me at romcheg.me>
> 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:
> OpenStack-dev-request at lists.openstack.org?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 <chdent at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] How to turn tempest CLI tests into
> python-*client in-tree functional tests
> Message-ID: <alpine.OSX.2.11.1505060952230.9820 at seed.local>
> 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 <loles at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Transaction scheme
> Message-ID:
> <
> CAOoSAzK82SBds05MWcmZ_R2DDGZDaFGtpB2Ur0NO9sAFo8hnDQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky
> <akislitsky at mirantis.com> 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 <me at romcheg.me>
> 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:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?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 <sean at dague.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] How to turn tempest CLI tests into
> python-*client in-tree functional tests
> Message-ID: <5549E241.9080706 at dague.net>
> 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 <thierry at openstack.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] cross project communication:
> periodic developer newsletter?
> Message-ID: <5549E4D8.5060201 at openstack.org>
> 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 <john at johngarbutt.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Ironic] Large number of ironic
> driver bugs in nova
> Message-ID:
> <
> CABib2_ozzkd__CMuDe-qzvmukzCKqvibQEfu1kWW-sqhM3vFjQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 6 May 2015 at 09:39, Lucas Alvares Gomes <lucasagomes at gmail.com> 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 <ikalnitsky at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Transaction scheme
> Message-ID:
> <
> CACo6NWDvxXphm0WgeC+zDGaUWzE4F1OZLOpdv2CR+BN7JmYUug at 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 <loles at mirantis.com> wrote:
> > On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky
> > <akislitsky at mirantis.com> 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 <me at romcheg.me>
> 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:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > ?ukasz Ole?
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?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 <thierry at openstack.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [all] cross project communication:
> periodic developer newsletter?
> Message-ID: <5549E5E8.5050508 at openstack.org>
> 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 <akislitsky at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Transaction scheme
> Message-ID:
> <
> CAHWr6fmSiU1yY_zK0Van_9mcXLeXomJ7ja8wQfJDnTkQEB8NMA at 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 <ikalnitsky at mirantis.com>
> 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 <loles at mirantis.com> wrote:
> > > On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky
> > > <akislitsky at mirantis.com> 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 <me at romcheg.me>
> > 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:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>>
> > >>
> > >>
> > >>
> >
> __________________________________________________________________________
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > >
> > > --
> > > ?ukasz Ole?
> > >
> > >
> >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?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 <sean at dague.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Which error code should we return
> when OverQuota
> Message-ID: <5549F039.1060205 at dague.net>
> 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 <jichenjc at cn.ibm.com
> > <mailto:jichenjc at cn.ibm.com>>:
> >
> > 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 at IBMCN Internet: jichenjc at cn.ibm.com
> > <mailto:jichenjc at cn.ibm.com>
> > 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:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?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)" <emma at projectcalico.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: Joe Marshall <Joe.Marshall at metaswitch.com>
> Subject: [openstack-dev] [Fuel][Plugin] Contributor license agreement
> for fuel plugin code?
> Message-ID:
> <0365813DA4F34A468C57038EAA5F396FE387AACA at ENFICSMBX1.datcon.co.uk>
> 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 <chdent at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] Which error code should we return
> when OverQuota
> Message-ID: <alpine.OSX.2.11.1505061159290.9820 at seed.local>
> 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 <comnea.dani at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Fuel] LBaaS in version 5.1
> Message-ID:
> <
> CAOBAnZM4RBX3psG2zQ0+0Tdr696CoJMBiapNqT7wc6Mb+wMPgg at 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 <dprince at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Core reviewer update proposal
> Message-ID: <1430911235.13747.1.camel at redhat.com>
> 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 <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license
> agreement for fuel plugin code?
> Message-ID: <20150506115815.GT2347 at yuggoth.org>
> 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
> legal-discuss at lists.openstack.org mailing list, or to your own
> private legal representation.
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/93afa490/attachment.html>
More information about the OpenStack-dev
mailing list
