Re: [openstack-dev] [oslo][heat] Versioned objects backporting

[Angus Salkeld]

On Thu, Apr 30, 2015 at 9:25 PM, Jastrzebski, Michal <
michal.jastrzeb...@intel.com> wrote:

> Hello,
>
> After discussions, we've spotted possible gap in versioned objects:
> backporting of too-new versions in RPC.
> Nova does that by conductor, but not every service has something like
> that. I want to propose another approach:
>
> 1. Milestone pinning - we need to make single reference to versions of
> various objects - for example heat in version 15.1 will mean stack in
> version 1.1 and resource in version 1.5.
> 2. Compatibility mode - this will add flag to service
> --compatibility=15.1, that will mean that every outgoing RPC communication
> will be backported before sending to object versions bound to this
> milestone.
>
> With this 2 things landed we'll achieve rolling upgrade like that:
> 1. We have N nodes in version V
> 2. We take down 1 node and upgrade code to version V+1
> 3. Run code in ver V+1 with --compatibility=V
> 4. Repeat 2 and 3 until every node will have version V+1
> 5. Restart each service without compatibility flag
>
> This approach has one big disadvantage - 2 restarts required, but should
> solve problem of backporting of too-new versions.
> Any ideas? Alternatives?
>

AFAIK if nova gets a message that is too new, it just forwards it on (and a
newer server will handle it).

With that this *should* work, shouldn't it?
1. rolling upgrade of heat-engine
2. db sync
3. rolling upgrade of heat-api

-Angus


>
> Regards,
> Michał
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] [tempest] Question on time precision in auth providers

[Daryl Walleck]

Hi folks,



While running Tempest I ran into a bit of interesting behavior. As part of the 
Tempest auth client, checks are performed to assure the token in use is still 
valid. When parsing the expiry timestamp from the auth response, a very 
specific datetime format is expected for Keystone v2 and v3 respectively:



https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L232

https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L313



Each of these are formats strings are valid under ISO 8601, but a one to one 
mapping is being made between Keystone versions and their timestamp formats. 
This can be problematic if the timestamps generated by your identity provider 
are valid timestamps, but vary in the granularity (second vs. millisecond vs. 
microsecond). In my case, I cannot execute any Tempest tests as this check 
occurs early in the fixture setup, which halts any test from running.



The guidance I've observed from the API working group is that any ISO 8601 
timestamp format should be sufficient 
(https://review.openstack.org/#/c/159892/11/guidelines/time.rst). Since this 
parsing occurs in client code as opposed to a test, would it be sufficient to 
verify that the timestamp is of a valid ISO 8601 format before parsing it and 
leave explicit checking to Keystone tests if necessary? I didn't want to open 
this as a bug because I realized there might be some historical context to this 
decision. I'd be grateful for any feedback on this point.



Thanks,



Daryl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] There seems to be a bug in packstack related to iptables

[Mingyu Li]

Hi all,

The version  "packstack Juno 2014.2.dev1468.gd049ea9" seems to install
iptables and iptables-services correctly but failed to start them.
The details are on https://bugs.launchpad.net/packstack/+bug/1451228

Thanks,
Mingyu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Abandoning old specs for Nova

[Michael Still]

Hi,

I just wanted to let people know that I am going through abandoning
old specs for Nova at the moment. The criteria I am using is:

 - spec targets kilo
 - no review comments or other activity since January or February

I think its worth reinforcing that an abandon isn't a -2... An upload
of a new version of the spec will re-open reviews on it. Here's the
message I've been using while abandoning:

"Please update this spec for Liberty if you're still interested in pursuing it."

Cheers,
Michael

-- 
Rackspace Australia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering

[Zhou Zheng Sheng / 周征晟]

Hello Sergii,

Thank you for the great explanation on Galera OCF script. I replied your
question inline.

on 2015/05/03 04:49, Sergii Golovatiuk wrote:
> Hi Zhou,
>
> Galera OCF script is a bit special. Since MySQL keeps the most
> important data we should find the most recent data on all nodes across
> the cluster. check_if_galera_pc is specially designed for that. Every
> server registers the latest status from grastate.dat to CIB. Once all
> nodes are registered, the one with the most recent data will be
> selected as Primary Component. All others should join to that node. 5
> minutes is a time for all nodes to appear and register position from
> grastate.dat to CIB. Usually, it takes much faster. Though there are
> cases when node is stuck on fsck or grub or power outlet or some other
> cases. If all nodes are registered there shouldn't be 5 minute penalty
> timeout. If one node is stuck (at least present in CIB), then all
> other nodes will be waiting for 5 minutes then will assemble cluster
> without it.
>
> Concerning dependencies, I agree that RabbitMQ may start in parallel
> to Galera cluster assemble procedure. It makes no sense to start other
> services as they are dependent on Galera and RabbitMQ.
>
> Also, I have a quick question to you. Shutting down all three
> controllers is a unique case, like whole power outage in whole
> datacenter (DC). In this case, 5 minute delay is very small comparing
> to DC recovery procedure. Reboot of one controller is more optimistic
> scenario. What's a special case to restart all 3-5 at once?

Sorry, I am not very clear about what "3-5" refers to. Is the question
about why we want to make the full reassemble time short, and why this
case is important for us?

We have some small customers forming a long-tail in local market. They
have neither dedicated datacenter houses nor dual power supply. Some of
them would even shutdown all the machines when they go home, and start
all of the machines when they start to work. Considering of data
privacy, they are not willing to put their virtual machines on the
public cloud. Usually, this kind of customer don't have IT skills to
troubleshoot a full reassemble process. We want to make this process as
simple as turning on all the machines roughly at the same time and wait
about several minutes, so they don't call our service team.

>
> Also, I would like to say a big thank for digging it out. It's very
> useful to use your findings in our next steps.
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Apr 29, 2015 at 9:38 AM, Zhou Zheng Sheng / 周征晟
> mailto:zhengsh...@awcloud.com>> wrote:
>
> Hi!
>
> Thank you very much Vladimir and Bogdan! Thanks for the fast
> respond and
> rich information.
>
> I backported MySQL and RabbitMQ ocf patches from stable/6.0 and tested
> again. A full reassemble takes about 5mins, this improves a lot.
> Adding
> the "force_load" trick I mentioned in the previous email, it takes
> about
> 4mins.
>
> I get that there is not really a RabbitMQ master instance because
> queue
> masters spreads to all the RabbitMQ instances. The pacemaker master is
> an abstract one. However there is still an mnesia node from which
> other
> mnesia nodes sync table schema. The exception
> "timeout_waiting_for_tables" in log is actually reported by mnesia. By
> default, it places a mark on the last alive mnesia node, and other
> nodes
> have to sync table from it
> (http://www.erlang.org/doc/apps/mnesia/Mnesia_chap7.html#id78477).
> RabbitMQ clustering inherits the behavior, and the last RabbitMQ
> instance shutdown must be the first instance to start. Otherwise it
> produces "timeout_waiting_for_tables"
> (http://www.rabbitmq.com/clustering.html#transcript search for
> "the last
> node to go down").
>
> The 1 minute difference is because without "force_load", the abstract
> master determined by pacemaker during a promote action may not be the
> last RabbitMQ instance shut down in the last "start" action. So
> there is
> chance for "rabbitmqctl start_app" to wait 30s and trigger a RabbitMQ
> exception "timeout_waiting_for_tables". We may able to see table
> timeout
> and mnesa resetting for once during a reassemble process on some
> of the
> RabbitMQ instances, but it only introduces 30s of wait, which is
> acceptable for me.
>
> I also inspect the RabbitMQ resource agent code in latest master
> branch.
> There are timeout wrapper and other improvements which are great. It
> does not change the master promotion process much, so it may still run
> into the problems I described.
>
> Please see the inline reply below.
>
> on 2015/04/28/ 21:15, Bogdan Dobrelya wrote:
> >> Hello,
> > Hello, Zhou
> >
> >> I using Fuel 6.0.1 and find that RabbitMQ recover time is long
> after
> >> powe

Re: [openstack-dev] [nova][api] API working group liaisons and responsibilities

[Alex Xu]

2015-05-02 5:12 GMT+08:00 Everett Toews :

> On Apr 30, 2015, at 9:54 AM, Jay Pipes  wrote:
>
> > Hi Stackers,
> >
> > OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova
> team's liaisons to the API working group. Big thank you to Matthew and Alex
> for volunteering for this important role.
> >
> > I've created a wiki page [1] that details the responsibilities of these
> liaisons. If these duties work out for Nova, we'll recommend other projects
> pick them up.
> >
> > Here are the responsibilities that the Nova/API working group liaisons
> have:
> >
> > 1. Monitor the active patch queue in nova (and nova-specs) and look out
> for any patch that adds or changes the REST API
> >
> > 2. For each patch collected in #1, determine if the constructs used in
> the patch (or proposed spec) match the guidance currently laid out in the
> API working group repo's guidance documents.
> >
> > 3. If the patch does NOT match the guidance from the API working group,
> do a code review on the patch pointing to the guidance from the API working
> group, and ask the author to align with that guidance. Include in your
> research patches to the API working group that may actually be in review
> and not merged. (An example of this recently occurred with Sergey Nikitin's
> re-proposed instance tagging spec:
> https://review.openstack.org/#/c/177112/. See Ryan Brown's reference to
> an in-progress API working group guidance on tagging)
> >
> > 4. If there is NO guidance in the API working group repo for a
> particular proposed API change or addition, the liaison should **either**
> create a proposed patch to the API working group with guidance that
> clarifies the missing functionality that is introduced in the new Nova
> patch or spec patch, and bring the proposed guidance to the attention of
> the API working group. **or** the liaison should working with a member of
> the API working group to draft such a guideline. The liaison should mark
> the corresponding Nova patch with a -1 Code Review vote with a link to the
> proposed guideline, noting that the patch should be put on hold (Work In
> Progress) until the guideline is merged.
> >
> > Best,
> > -jay
> >
> > [1] https://wiki.openstack.org/wiki/Nova/APIWGLiaisons
>
> This is great. I’ve added a link to that page from the Cross-Project
> Liaisons page [2]. I also added Matthew and Alex as liaisons there.
>
> giiard and alex_xu: feel free to join us in #openstack-api on freenode
> too!
>

Everett, Thanks! Just joined!


>
> Everett
>
> [2] https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] OpenStack project testing, gating etc

[Robert Collins]

On 4 May 2015 at 11:42, Adam Lawson  wrote:

> Can someone please point me to where OpenStack testing processes are
> explained? Which systems is/are used, how it tied into Jenkins, what gates
> are, etc. I'm not a developer but this stuff has been an area that I
> haven't explored for far too long. I keep running into URL's that are
> labeled obsolete.
>


http://ci.openstack.org/

Cheers,
Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] OpenStack project testing, gating etc

[Adam Lawson]

Can someone please point me to where OpenStack testing processes are
explained? Which systems is/are used, how it tied into Jenkins, what gates
are, etc. I'm not a developer but this stuff has been an area that I
haven't explored for far too long. I keep running into URL's that are
labeled obsolete.

Many thanks!

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Elections] TC Election analysis

[Adam Lawson]

Keep in mind also there is an increasing interest with potentially
integrating Operators in some manner.Judging from the candidates statements
anyway. Whatever we pursue to improve engagement, it will be interesting to
see how an expressed desire to represent the Operator community actually
translates into tangible steps. Not from a disinterest but because some
logistics approaches are easier than others to adopt.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Sun, May 3, 2015 at 12:35 PM, Cody A.W. Somerville <
cody-somervi...@ubuntu.com> wrote:

> On Thu, Apr 30, 2015 at 4:00 PM, Joe Gordon  wrote:
>
>> On Thu, Apr 30, 2015 at 1:28 PM, Maish Saidel-Keesing <
>> mais...@maishsk.com> wrote:
>>
>>> On 04/30/15 21:48, Joe Gordon wrote:
>>>
 As others have done for past elections, here is a brief breakdown of
 the TC election ballot data.

 analysis: http://paste.openstack.org/show/213831
 source code: http://paste.openstack.org/show/213830

 
>
>>  Thanks Joe for the analysis. It is quite interesting. Another thing that
>>> I find interesting is the low participation rate.
>>>
>>> Out of 2169 eligible voters, 548 participated - that is 25.26%.
>>>
>>
>> According to [0] there were 369 ”Regular” contributors in 2014, and in
>> Kilo there were only 748 contributors with 5 or more patches out of
>> the 1886 contributors [1]. So measuring participation from eligible votes
>> is a misleading. Well over half of the eligible voters have only
>> contributed a few patches, and we had more voters participate then we have
>> 'regular' contributors.  So I think our turnout is actually really good.
>>
>> [0] https://www.openstack.org/assets/reports/osf-annual-report-2014.pdf
>> [1] http://stackalytics.com/?release=kilo&metric=commits
>>
>>
>>>
>>> Comparing to previous elections
>>> Oct. 2014 - 1893 eligible voters, 506 participated - 26.73%
>>> Apr. 2014 - 1510 eligible voters, 408 participated - 29.66%
>>>
>>> I am wondering why the participation level is so low. This is really one
>>> of the few opportunities a contributor has to define the direction of
>>> OpenStack as a whole. And yet it goes down each election.
>>>
>>
> I would also hypothesize that contributors who are eligible but less
> regular in their contribution may not pay as much attention (or even be
> subscribed? -- would be an interesting metric to see I imagine) to the
> mailing list where a majority of the promotion and election activity occur.
>
> Where do all code contributors visit? Gerrit. If we were able to put up
> Clippy on Gerrit for April Fools, maybe we could put something up to raise
> awareness during the next election cycle? This could include linking people
> to the election wiki page and reminding eligible folks to ensure they have
> their correct e-mail address in Gerrit in order to receive a ballot.
>
> --
> Cody A.W. Somerville
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

[Robert Collins]

On 4 May 2015 at 08:59, Steve Baker  wrote:
> On 02/05/15 07:06, Robert Collins wrote:
>>
>> On 2 May 2015 at 04:17, Doug Hellmann  wrote:
>>>
>>> Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:

 pbr 0.11 is finally released (now that Kilo is out :).

 This brings in more support to ensure that our version numbers are
 monotonically increasing.

 Mostly this should be unintrusive (but please do read the docs -
 http://docs.openstack.org/developer/pbr/#version).
>>
>> ...
>>
>>> It would be good to make sure this is in the pbr documentation, too.
>>
>> It is, at the link I gave. If its not clear enough, please do help me
>> understand how, since having clear docs is kindof important :)
>>
>> I'd also like to do a little postmortem - here's the fallout I've
>> heard of from pbr's 0.11 release (which is > 1yr of inventory, so
>> kindof a big deal).
>>
> ...
>>
>>
>> Lastly, and still unresolved, heat's contrib plugin versions
>> (introduced in March) are deliberately different to the git history,
>> and thats a use case that pbr hasn't ever supported (multiple version
>> timelines in one git tree). https://review.openstack.org/#/c/162311/
>> introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
>> is the bug for this.
>
> Our contrib plugins are not distributed with the heat release and are come
> with a very limited notion of being supported. Operators who want to install
> any are expected to git-clone to the desired revision and either cp -r to
> /usr/lib/heat (our original plugin mechanism) or pip-install (so the plugin
> can be picked up by stevedore).
>
> Specifying the version in setup.cfg was added to stop pbr complaining about
> the lack of version, and to give operators some way of managing what version
> of what they have installed.
>
> We would prefer to keep the contrib plugins in-tree since it lets us run
> their unit tests in the standard gate job, and allows them to evolve with
> internal API additions. I fully realize that having mini packages in
> sub-directories is ... unique.
>
> What I think I would like is a way to tell pbr to ignore git and take the
> overridden version from setup.cfg. Having declarative setup is nice, but
> another option would be to just switch to plain setuptools - these are not
> complicated packages.

So, we've got a design requirements mismatch here, and should give
this the same care we do other decisions - I've set up
https://etherpad.openstack.org/p/heat-plugin-pbr to start capturing
your desires, and also to summarise the pbr constraints that led to
where we are today, from there we can work forward.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

[Steve Baker]

On 02/05/15 07:06, Robert Collins wrote:

On 2 May 2015 at 04:17, Doug Hellmann  wrote:

Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:

pbr 0.11 is finally released (now that Kilo is out :).

This brings in more support to ensure that our version numbers are
monotonically increasing.

Mostly this should be unintrusive (but please do read the docs -
http://docs.openstack.org/developer/pbr/#version).

...


It would be good to make sure this is in the pbr documentation, too.

It is, at the link I gave. If its not clear enough, please do help me
understand how, since having clear docs is kindof important :)

I'd also like to do a little postmortem - here's the fallout I've
heard of from pbr's 0.11 release (which is > 1yr of inventory, so
kindof a big deal).


...


Lastly, and still unresolved, heat's contrib plugin versions
(introduced in March) are deliberately different to the git history,
and thats a use case that pbr hasn't ever supported (multiple version
timelines in one git tree). https://review.openstack.org/#/c/162311/
introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
is the bug for this.
Our contrib plugins are not distributed with the heat release and are 
come with a very limited notion of being supported. Operators who want 
to install any are expected to git-clone to the desired revision and 
either cp -r to /usr/lib/heat (our original plugin mechanism) or 
pip-install (so the plugin can be picked up by stevedore).


Specifying the version in setup.cfg was added to stop pbr complaining 
about the lack of version, and to give operators some way of managing 
what version of what they have installed.


We would prefer to keep the contrib plugins in-tree since it lets us run 
their unit tests in the standard gate job, and allows them to evolve 
with internal API additions. I fully realize that having mini packages 
in sub-directories is ... unique.


What I think I would like is a way to tell pbr to ignore git and take 
the overridden version from setup.cfg. Having declarative setup is nice, 
but another option would be to just switch to plain setuptools - these 
are not complicated packages.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Elections] TC Election analysis

[Cody A.W. Somerville]

On Thu, Apr 30, 2015 at 4:00 PM, Joe Gordon  wrote:

> On Thu, Apr 30, 2015 at 1:28 PM, Maish Saidel-Keesing  > wrote:
>
>> On 04/30/15 21:48, Joe Gordon wrote:
>>
>>> As others have done for past elections, here is a brief breakdown of the
>>> TC election ballot data.
>>>
>>> analysis: http://paste.openstack.org/show/213831
>>> source code: http://paste.openstack.org/show/213830
>>>
>>> 

>  Thanks Joe for the analysis. It is quite interesting. Another thing that
>> I find interesting is the low participation rate.
>>
>> Out of 2169 eligible voters, 548 participated - that is 25.26%.
>>
>
> According to [0] there were 369 ”Regular” contributors in 2014, and in
> Kilo there were only 748 contributors with 5 or more patches out of
> the 1886 contributors [1]. So measuring participation from eligible votes
> is a misleading. Well over half of the eligible voters have only
> contributed a few patches, and we had more voters participate then we have
> 'regular' contributors.  So I think our turnout is actually really good.
>
> [0] https://www.openstack.org/assets/reports/osf-annual-report-2014.pdf
> [1] http://stackalytics.com/?release=kilo&metric=commits
>
>
>>
>> Comparing to previous elections
>> Oct. 2014 - 1893 eligible voters, 506 participated - 26.73%
>> Apr. 2014 - 1510 eligible voters, 408 participated - 29.66%
>>
>> I am wondering why the participation level is so low. This is really one
>> of the few opportunities a contributor has to define the direction of
>> OpenStack as a whole. And yet it goes down each election.
>>
>
I would also hypothesize that contributors who are eligible but less
regular in their contribution may not pay as much attention (or even be
subscribed? -- would be an interesting metric to see I imagine) to the
mailing list where a majority of the promotion and election activity occur.

Where do all code contributors visit? Gerrit. If we were able to put up
Clippy on Gerrit for April Fools, maybe we could put something up to raise
awareness during the next election cycle? This could include linking people
to the election wiki page and reminding eligible folks to ensure they have
their correct e-mail address in Gerrit in order to receive a ballot.

-- 
Cody A.W. Somerville
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 R

[Thomas Goirand]

Hi,

According to Paul Tagliamonte, who is from the Debian FTP master team 
(which peer-reviews NEW packages in Debian before they reach the 
archive) python-xstatic-angular-bootstrap cannot be uploaded as-is to 
Debian because it doesn't include an Expat LICENSE file, which is in 
direct violation of the license itself (ie: anything which is shipped 
using the MIT / Expat license *must* include the said license). Below is 
a copy of reply to me, after the package was rejected.


Maxime, since you're the maintainer of this xstatic package, could you 
please include the Expat (aka: MIT) license inside 
xstatic-angular-bootstrap, then retag and re-release the package?


Also, when this is done, I would strongly suggest fixing the 
global-requirements.txt to force using the correct package, then remove 
license infringing version from PyPi. This wont change anything for me 
as long as there's a new package which fixes the licensing issue, but 
legally, I don't think it's right to leave downloadable what has already 
been released.


 Forwarded Message 
Subject: Re: [PKG-Openstack-devel] 
python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes REJECTED

Date: Sat, 2 May 2015 17:21:10 -0400
From: Paul Tagliamonte 
Reply-To: Tracking bugs and development for OpenStack 


To: Thomas Goirand 
CC: Paul Richards Tagliamonte , PKG 
OpenStack 


On Sat, May 02, 2015 at 11:07:51PM +0200, Thomas Goirand wrote:

Hi Paul!

First of all, thanks a lot for all the package review. This is simply
awesome, and helps me really a lot in my work!


np :)


Well, for all XStatic projects, the habit is to use the same licensing as
for the javascript that is packaged as Python module. So in this file:

xstatic/pkg/angular_bootstrap/__init__.py

you can see:

LICENSE = '(same as %s)' % DISPLAY_NAME

then in xstatic/pkg/angular_bootstrap/data/angular-bootstrap.js, in the
header of the file, you may see:

 * angular-ui-bootstrap
 * http://angular-ui.github.io/bootstrap/

 * Version: 0.11.0 - 2014-05-01
 * License: MIT

So, python-xstatic-angular-bootstrap uses the same Expat license.

Is this enough?


So, I trust this *is* MIT/Expat licensed, but if you look at the terms
they're granting us::

| Permission is hereby granted, free of charge, to any person obtaining 
a copy
| of this software and associated documentation files (the "Software"), 
to deal
| in the Software without restriction, including without limitation the 
rights

| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
| copies of the Software, and to permit persons to whom the Software is
| furnished to do so, subject to the following conditions:
|
| The above copyright notice and this permission notice shall be included in
| all copies or substantial portions of the Software.
|
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
| IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
| FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
SHALL THE

| AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
| LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM,

| OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
| THE SOFTWARE.

The critical bit here --

| The above copyright notice and this permission notice shall be included in
| all copies or substantial portions of the Software.

The source distribution is non-complient. They can do that since they
can't infringe on themselves. We would be infringing by distributed the
source tarball.

Just do a DFSG repack and include the license in it. That'll be great
and enough.


Can I upload again the package? Or should I ask for a more
clear statement from upstream (which by the way, I have met face to face,
and I know how to ping him on Freenode...)?


Cheers,
  Paul

--
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 R

[Thomas Goirand]

Hi,

According to Paul Tagliamonte, who is from the Debian FTP master team 
(which peer-reviews NEW packages in Debian before they reach the 
archive) python-xstatic-angular-bootstrap cannot be uploaded as-is to 
Debian because it doesn't include an Expat LICENSE file, which is in 
direct violation of the license itself (ie: anything which is shipped 
using the MIT / Expat license *must* include the said license). Below is 
a copy of reply to me, after the package was rejected.


Maxime, since you're the maintainer of this xstatic package, could you 
please include the Expat (aka: MIT) license inside 
xstatic-angular-bootstrap, then retag and re-release the package?


Also, when this is done, I would strongly suggest fixing the 
global-requirements.txt to force using the correct package, then remove 
license infringing version from PyPi. This wont change anything for me 
as long as there's a new package which fixes the licensing issue, but 
legally, I don't think it's right to leave downloadable what has already 
been released.


 Forwarded Message 
Subject: Re: [PKG-Openstack-devel] 
python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes REJECTED

Date: Sat, 2 May 2015 17:21:10 -0400
From: Paul Tagliamonte 
Reply-To: Tracking bugs and development for OpenStack 


To: Thomas Goirand 
CC: Paul Richards Tagliamonte , PKG 
OpenStack 


On Sat, May 02, 2015 at 11:07:51PM +0200, Thomas Goirand wrote:

Hi Paul!

First of all, thanks a lot for all the package review. This is simply
awesome, and helps me really a lot in my work!


np :)


Well, for all XStatic projects, the habit is to use the same licensing as
for the javascript that is packaged as Python module. So in this file:

xstatic/pkg/angular_bootstrap/__init__.py

you can see:

LICENSE = '(same as %s)' % DISPLAY_NAME

then in xstatic/pkg/angular_bootstrap/data/angular-bootstrap.js, in the
header of the file, you may see:

 * angular-ui-bootstrap
 * http://angular-ui.github.io/bootstrap/

 * Version: 0.11.0 - 2014-05-01
 * License: MIT

So, python-xstatic-angular-bootstrap uses the same Expat license.

Is this enough?


So, I trust this *is* MIT/Expat licensed, but if you look at the terms
they're granting us::

| Permission is hereby granted, free of charge, to any person obtaining 
a copy
| of this software and associated documentation files (the "Software"), 
to deal
| in the Software without restriction, including without limitation the 
rights

| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
| copies of the Software, and to permit persons to whom the Software is
| furnished to do so, subject to the following conditions:
|
| The above copyright notice and this permission notice shall be included in
| all copies or substantial portions of the Software.
|
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
| IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
| FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
SHALL THE

| AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
| LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM,

| OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
| THE SOFTWARE.

The critical bit here --

| The above copyright notice and this permission notice shall be included in
| all copies or substantial portions of the Software.

The source distribution is non-complient. They can do that since they
can't infringe on themselves. We would be infringing by distributed the
source tarball.

Just do a DFSG repack and include the license in it. That'll be great
and enough.


Can I upload again the package? Or should I ask for a more
clear statement from upstream (which by the way, I have met face to face,
and I know how to ping him on Freenode...)?


Cheers,
  Paul

--
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mellanox request for permission for Nova CI

[Lenny Verkhovsky]

Hi Dan and the team,

Here you can see full logs and tempest.conf  
http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_PORT_20150503_1854/
( suspend-resume test is skipped and we are checking this issue )

Except of running Tempest API on Mellanox flavor VM we are also running 
tempest.scenario.test_network_advanced_server_ops.TestNetworkAdvancedServerOps
With configured port_vnic_type = direct

We will add more tests in the future.

Thanks in advance.
Lenny Verkhovsky
SW Engineer,  Mellanox Technologies
www.mellanox.com 

Office:+972 74 712 9244
Mobile:  +972 54 554 0233
Fax:+972 72 257 9400

-Original Message-
From: Dan Smith [mailto:d...@danplanet.com] 
Sent: Friday, April 24, 2015 7:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI

Hi Lenny,

> Is there anything missing for us to start 'non-voting' Nova CI ?

Sorry for the slow response from the team.

The results that you've posted look good to me. A quick scan of the tempest 
results don't seem to indicate any new tests that are specifically testing 
SRIOV things. I assume this is mostly implied because of the flavor you're 
configuring for testing, right?

Could you also persist the tempest.conf just so it's easy to see?

Regardless of the above, I think that the results look clean enough to start 
commenting on patches, IMHO. So, count me as +1.

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStackClient 1.2.0 release

[Dean Troyer]

On Sun, May 3, 2015 at 6:37 AM, Daniel Comnea  wrote:

> will i be able to run this new client against Icehouse too ?
>

Yes, you should. OSC ultimately depends on the client libraries to do the
actual REST communication (except for object-store) so the compatibility
depends on them.  But if it doesn't work it is a bug.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] os-ansible-deplpoyment has released Kilo

[Daniel Comnea]

Great job Kevin & co !!

Are there any plans in supporting configure the baremetal as well ?

Dani

On Thu, Apr 30, 2015 at 11:46 PM, Liu, Guang Jun (Gene) <
gene@alcatel-lucent.com> wrote:

> cool!
> 
> From: Kevin Carter [kevin.car...@rackspace.com]
> Sent: Thursday, April 30, 2015 4:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] os-ansible-deplpoyment has released Kilo
>
> Hello Stackers,
>
> The OpenStack Ansible Deployment (OSAD) project is happy to announce our
> stable Kilo release, version 11.0.0. The project has come a very long way
> from initial inception and taken a lot of work to excise our original
> vendor logic from the stack and transform it into a community-driven
> architecture and deployment process. If you haven’t yet looked at the
> `os-ansible-deployment` project on StackForge, we'd love for you to take a
> look now [ https://github.com/stackforge/os-ansible-deployment ]. We
> offer an OpenStack solution orchestrated by Ansible and powered by upstream
> OpenStack source. OSAD is a "batteries included" OpenStack deployment
> solution that delivers OpenStack as the developers intended it: no
> modifications to nor secret sauce in the services it deploys. This release
> includes 436 commits that brought the project from Rackspace Private Cloud
> technical debt to an OpenStack community deployment solution. I'd like to
> recognize the following people (from Git logs) for all of their hard work
> in making the OSAD project successful:
>
> Andy McCrae
> Matt Thompson
> Jesse Pretorius
> Hugh Saunders
> Darren Birkett
> Nolan Brubaker
> Christopher H. Laco
> Ian Cordasco
> Miguel Grinberg
> Matthew Kassawara
> Steve Lewis
> Matthew Oliver
> git-harry
> Justin Shepherd
> Dave Wilde
> Tom Cameron
> Charles Farquhar
> BjoernT
> Dolph Mathews
> Evan Callicoat
> Jacob Wagner
> James W Thorne
> Sudarshan Acharya
> Jesse P
> Julian Montez
> Sam Yaple
> paul
> Jeremy Stanley
> Jimmy McCrory
> Miguel Alex Cantu
> elextro
>
>
> While Rackspace remains the main proprietor of the project in terms of
> community members and contributions, we're looking forward to more
> community participation especially after our stable Kilo release with a
> community focus. Thank you to everyone that contributed on the project so
> far and we look forward to working with more of you as we march on.
>
> —
>
> Kevin Carter
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStackClient 1.2.0 release

[Daniel Comnea]

Dean, quick question:

will i be able to run this new client against Icehouse too ?

Thanks,
Dani

On Thu, Apr 30, 2015 at 9:24 PM, Dean Troyer  wrote:

> OpenStackClient 1.2.0 has been released to PyPI.
>
> python-openstackclient can be installed from the following locations:
>
> PyPI: https://pypi.python.org/pypi/python-openstackclient
> OpenStack tarball: http://tarballs.openstack.org/python-openstackclient
> /python-openstackclient-1.2.0.tar.gz
> 
>
> Please report issues through launchpad: https://bugs.launchpad.net/python-
> openstackclient
>
> 1.2.0 (30 Apr 2015)
> ===
>
> * Fix error in ``security group create`` command when ``--description`` is
> not supplied.
> * Correct ``image list`` pagination handling, all images are now correctly
> returned.
> * Do not require ``--dst-port`` option with ``security group rule create``
> when ``--proto ICMP`` is selected.
> * Correctly pass ``--location`` arguemnt in ``image create`` command.
> * Correctly handle use of ``role`` commands for project admins.  Using IDs
> will work for project admins even when names will not due to non-admin
> contraints.
> * Correctly exit with an error when authentication can not be completed.
> * Fix ``backup create`` to correctly use the ``--container`` value if
> supplied.
> * Document the backward-compatibility-breaking changes in
>   :doc:`backwards-incompatibile`.
> * Add `--parent`` option to `projct create` command.
>
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] time based auto scaling

[Ildikó Váncsa]

Hi,

I like the base idea to trigger scaling based on other information than what we 
have from the current Ceilometer alarms.

Although I think this functionality should live somewhere else than under the 
responsibility of Ceilometer. This type of scaling is usually based on trend 
analysis and other application specific data, which is out of the scope for 
Ceilometer, even if it has the capability of triggering Heat.

Best Regards,
Ildiko

Feladó: Julien Danjou [jul...@danjou.info]
Küldve: 2015. április 29. 9:29
Címzett: ZhiQiang Fan
Másolatot kap: OpenStack Development Mailing List
Tárgy: Re: [openstack-dev] [ceilometer] time based auto scaling

On Wed, Apr 29 2015, ZhiQiang Fan wrote:

> However, current ceilometer only provide time constraint alarm, which will
> only evaluate but not guarantee it will be triggered. And heat cannot
> provide something like timer, but just can wait for the signal.
>
> So I propose to add a new type of alarm, which will definitely send a
> signal to action when it is evaluated (with or without repeat, it will work
> well with time constraint)
>
> Any suggestion?

I've proposed exactly that around 18-24 years go I think during a
summit, and nobody was really interested back then and was worried to
have yet another cron system – though OpenStack didn't have one.

I still think it's a good idea and it will be a nice addition to the
alarming system, so if you want to write a spec for that I'll be all
yours. :)

--
Julien Danjou
# Free Software hacker
# http://julien.danjou.info

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev